原文地址：
https://medium.com/columbus-egg/dear-agile-im-tired-of-pretending-d39ab6a12003
翻譯君：CODING 敏傑小王子
“敏捷已死”，人們一直這麼說，但緊接着他們又說：“我們只是開個玩笑”。其實這些人真正想表達的是你實踐敏捷的方式已經過時並且愚不可及，而“真正的”敏捷未死，只不過大家實踐敏捷的方式是錯誤的。因此，我認爲理論上的敏捷是“真正的”敏捷。
最近我在網上也蒐集到了很多古老的辯解：“但是有問題的是 Water-Scrum-Fall，而不是宣言當中的敏捷。” 緊接着 Bob Marshall 直言不諱道：“這位同學請你閉嘴吧，敏捷宣言就是老調重彈。”他還說了一些我不得不同意的觀點，我思考了一下，下面就是我思考的結論。
閱讀參考：
Water-Scrum-fall
https://www.infoq.cn/article/delivering-software-water-scrum-fall
這裏有一個對你的測驗：敏捷宣言的第一句是什麼？不許偷看。不記得了的話，我來告訴你：“我們正在探索開發軟件更好的方式……”就此打住，注意到了嗎，它說的是“開發軟件”，並沒有說到“傾斜你的組織”、“償還轉型債務”、“用這種命令和控制廢話切斷它”、“專注於結果並且在發現領域的工作”、“修復你的中世紀預算系統”，或任何其它人們試圖掩蓋的更多有價值的東西。但問題是，當人們說敏捷屬於整個組織時，它就是修正主義的歷史，這是不誠實的。
在宣言開始的部分是：“我們正在發現……”，它並沒有說：“我們已從非常……獲得……”。你不覺得我們從 2001 年開始意識到，大多數大型組織仍然停留在 1987 年。與流行的看法相反，下面的照片實際上並非來自 Snowbird 簽署的宣言，我們是不是可以終於停止僞裝的敏捷了呢？
宣言有它的目標，但它不會讓你直接到達你要去的地方，所以我們需要學習。我們的知識是有保質期的，有時不像我們預想的那麼長。我們身邊總有些同事（通常是領導者）聲稱他們“沒有時間學習”，而你知道他們只是對自己的認知過於自信。所以找一個豐富的書單，關注一些優質的博客，這是一個開始：如果你還沒有閱讀《Sense ＆ Respond》、《精益企業》、《A Seat at the Table》以及《Everyone Is a Change Agent》，我建議你花時間學一學，也建議你的領導也讀一讀。
譯者注：
《Sense & Respond》探討了企業必須如何發展意識和應對戰略，以利用這個網絡化時代的機遇。
《A Seat at the Table》詮釋了傳統的 CIO 角色是如何與軟件開發的敏捷方法相沖突的，探討了在敏捷環境中 IT 領導人應該是什麼樣的。
《Everyone Is a Change Agent》介紹了在組織中如何進行變更以及推動變動。
開始閱讀 John Cutler，Melissa Perri，Bob Marshall，Allen Holub，Laura Klein，Erika Hall，Neil Killick 以及由他們延伸開來的帖子。他們都相互認同（或與我認同）嗎？不 —— 但他們很聰明，他們也會讓你更聰明。閱讀，並且鼓勵他人。Fast Company 表示，CEO 平均每年閱讀 60 本書，你的領導讀過幾本書？並且他們平時都在讀些什麼呢？（HBR 的文章，Gartner 的報道，以及 Maeve Binchy 的小說都不算數）讓我們面對現實吧，如果你的領導者還在試圖通過第六感意會 Scrum，那麼你們的組織就會卡在 80 年代和 90 年代無法動彈。
所以讓我們達成共識，敏捷並不是研發管理的銀彈，團隊要做到持續學習。需要說明的是：敏捷一直關注的都是本地優化，爲系統帶來的收益其實微乎其微。敏捷其實意味着把軟件研發團隊放到了顯微鏡下，僅從很多細節的角度去解讀研發團隊，很多時候這樣是不公平的，而且這其實一點都不能提升組織的敏捷程度。有趣的是，Ken Schwaber 想過撤銷瀑布流式開發方式帶來的傷害，然而敏捷從來沒有爲企業或者組織提供一個整體可行的替代方案。這其中也有實踐和理論存在差距的原因，在實踐中我們需要務實，這也導致敏捷在實踐中經常名存實亡，這似乎也是整個敏捷運動本身存在的問題。無論如何，還有更重要的事情可以學習，包括但不限於 DevOps、Lean UX、精益創業、Design Thinking 等等。
你可能會好奇爲什麼 Lean UX 會在這個列表上，因爲 Lean UX 注重最後的結果。如果你不知道想要創建什麼樣的改變，那麼你將不知道該如何轉變。如果沒有明確的改變信號，那麼你首先就不能真正“敏捷”，畢竟改變纔是敏捷最關注的。也有人說敏捷主要需要即時觀察和調整，但是我看到大部分敏捷團隊都僅僅停留在機械地往已有工作中增加一些水泥，在 Jira 和 Rally 裏倒騰，就像他們之前在其他地方建造磚牆一樣。
敏捷本質上傾向於掩蓋核心問題，這是一種系統性的，雙向都缺乏垂直信任。事情在敏捷教練離開後會變得更糟糕，管理層和研發團隊由於屁股決定腦袋，雙方的溝通變成了雞同鴨講。研發團隊會覺得管理層根本什麼都不懂，然而管理層們卻在關注任務的精細程度、deadlines 和效率，忽略了很多時候 deadline 和工時預估都是拍腦門定的，其實毫無用處。
那你猜猜哪邊會贏呢？兩個陣營有兩個截然不同的視角，但有一個陣營得接受另一個陣營的績效評估。如果說研發團隊就像是在盲人摸象，並討論大象到底是什麼樣的，那管理層就像是盲象踩人，並一致認爲人就是扁的。唯一的出路就是認識到管理體系其實也是團隊的一部分，別老搞那些本地的細節優化，而是要意識到信任纔是第一要素。所以不要僅僅把研發團隊放到顯微鏡下面看，而其他人都躲在小黑屋裏不知道在做什麼。
再者，在嘗試敏捷的時候，必須停止像對待工廠工人一樣對待研發團隊。我們不是在製造塑料餐具，我們是在創建新的軟件，我們需要停止像開一個披薩店一樣的管理方式，那種一直使用同一種配方來做披薩的方式是不適用的，我們是在設計新的配方，是具有創新性的工作，而不僅僅是按部就班那麼簡單。忽視這份工作的創造性將會導致大量浪費：沒人用的功能和無法帶來結果的代碼。這也暴露了敏捷的另一個深層缺陷，它假設可以像對待小白鼠一樣對待用戶：“hey，你現在就用這個沒什麼用的功能吧，先用着我們後面會改進的“ ，然後用戶就頭也不回地走了，未來的產品改進就成了無意義的浪費。
有人會說敏捷也可以作爲創造性工作的工作方式，但是就像我剛剛說的，理論和實踐是有鴻溝的。如果你真的想爲團隊做一些創造性的工作，想想你跟敏捷團隊的經歷，你是會被團隊認可並幫助團隊更加精進，還是經常被領導詢問 “能否展示你做這個事情的意義”？就像 Alan Cooper 說的那樣，當你經常被要求證明自己的價值時，你要清楚他們是在告訴你，當下的環境是不認可你的價值的。請注意，管理者要求個人貢獻者證明自己的價值 —— 但不會問他的代碼中有多少實際上會產生的正向結果。換句話說，他們仍然專注於人而不是工作本身，他們可能仍然專注於成本，而不是實際產出的價值。
所以如果你在一個敏捷團隊中想做一些創造性的工作，下次被問到如何展示你的價值的時候，試着反問他如下問題：你知道項目延遲的成本是多少麼？你使用哪些維度來測算？這個項目想實現哪些實質性的成果？項目中到底哪些資源和代碼轉化成了實際的成果？如果他們回答不清，可以繼續問如果有更快、更便宜的方式來學習構建，而不是機械性的輸出代碼，你們是否有興趣學習？你們現在的流水線效率如何？一天要花多少時間參加各種會議？如果有思維訓練和團建活動能在更短的時間內推動更好的決策，你們是否會感興趣？因爲我不會只告訴你我有多重要 —— 我會教你在每件事上創造更多的價值。
這要求的是另外一種思維，形式上更加關注戰略層面。就像 Austion Govella 說的那樣，敏捷和瀑布流的方式都過於關注構建，而不關注結果評估。如果你所在的組織無法正確的評估產出，你可能需要挪挪窩了。如果他們只是每天埋頭苦幹，成批的輸出代碼，僅僅關注成本，那他們僅僅是一個輸出功能的工廠而已，假裝只是在創造塑料餐具而不是生產，他們也無法理解你的哪些行爲能爲團隊帶來更多增益。因爲真正的價值是由研發工作中創造的選擇來決定的，而這些選擇則是由日常工作的持續學習和探索產生的。你能選擇的東西越多則工作彈性越大，相應就會有更多種方法來創造價值。這個項目到底是想達到什麼目標？有沒有尋找 3 到 5 種新的方法來實現這個目標？這些都需要通過更長期的規劃來推動更好的決策。當只有一種選擇時只能埋頭苦幹，兩種選擇是兩難，但第三種選擇的出現代表着可以正視利弊，團隊纔會真正前進。
而且這也是有理論支持的，你是否聽過必要多樣性理論（Law of Requisite Variety）：在一個系統中，擁有最多選擇的那個組件將能決定整個系統的走向。領導者試圖將系統控制在最頂層，同時敏捷團隊卻試圖將價值推向更靠近實際用戶和客戶，擺脫這種內戰的方法是要讓人們在各個層面都能擁有選擇。出路並不是尋求敏捷 VS 瀑布流的結果，而是一種明智的由上到下的瀑布流性戰略方針，和由下到上的經驗驅動戰術相輔相成的管理方式。
所以人們應該在意結果，而不僅僅是產出量；更注重戰略上的佈局而不是一個個規劃出來的里程碑。研發團隊應該成爲真正被信任的產品團隊而不僅僅是被當作一個項目團隊來看待。給予研發團隊以下自主性，讓他們敢於去探索達成目標的最佳途徑。
最後總結一下，雖然吐槽了這麼多，是否就意味着敏捷已經開始沒落了呢？其實不然，這僅僅是我對現在各個組織或企業在實踐敏捷時出現的一些問題的觀察，再說如果沒有敏捷運動，那我今天在這裏所說的大部分結論也都失去了意義。所以我也不希望敏捷就這麼沒落，我僅僅是希望作爲敏捷的實踐者，我們能更敢於直面其中的問題。