假裝的敏捷，我好累

原文地址：
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 瀑布流的結果，而是一種明智的由上到下的瀑布流性戰略方針，和由下到上的經驗驅動戰術相輔相成的管理方式。

因此人們應該在乎結果，而不只僅是產出量；更注重戰略上的佈局而不是一個個規劃出來的里程碑。研發團隊應該成爲真正被信任的產品團隊而不只僅是被看成一個項目團隊來看待。給予研發團隊如下自主性，讓他們勇於去探索達成目標的最佳途徑。

最後總結一下，雖然吐槽了這麼多，是否就意味着敏捷已經開始沒落了呢？其實否則，這僅僅是我對如今各個組織或企業在實踐敏捷時出現的一些問題的觀察，再說若是沒有敏捷運動，那我今天在這裏所說的大部分結論也都失去了意義。因此我也不但願敏捷就這麼沒落，我僅僅是但願做爲敏捷的實踐者，咱們能更勇於直面其中的問題。