現在“敏捷開發”已經成為了一個非常“時髦”的詞匯，很多的團隊和公司都聲稱自己正在“做敏捷”，但是作為一個跑過很多公司，見過很多項目和團隊的敏捷教練來講，我卻很悲哀地發現，很多團隊的做法卻沒有真正理解敏捷開發背后的意義，甚至早已和敏捷宣言所倡導的價值觀背道而馳了。
重讀敏捷宣言
“2001年2月11日至13日，在美國猶他州瓦薩奇山雪鳥滑雪勝地，17個人聚到一起，交談、滑雪、休閑，當然還有聚餐。他們試圖找到共識，最終的成果就是《敏捷軟件開發宣言》（Manifesto for Agile Software Development）。參會者們包括來自于極限編程、Scrum、DSDM、自適應軟件開發、水晶系列、特征驅動開發、實效編程的代表們，還包括了希望找到文檔驅動、重型軟件開發過程的替代品的一些推動者?！薄猦istory of agile manifesto
我想不用太多我個人的贅述，在敏捷宣言的官網上就已經有了非常明確的描寫，只是似乎人們都不太擅長學習，對于敏捷開發的誤解很多也就來源于此。
什么是敏捷？
敏捷是快嗎？似乎是，也似乎不是。如果敏捷是快的話，為什么當年他們把這種開發方法叫做“Agile”，而不是“Fast”或者“Rapid”呢？
我們看一下這兩種動物：大象和猴子，如果說“快”的話，猴子的奔跑速度怎么也不會比大象更快，但很顯然，相比于大象，猴子是更加“敏捷”的。
敏捷不敏捷，取決于一個動物或者一個系統是否能夠察覺到周邊環境細微的變化，但是光察覺到還不夠，主要還得看是否能夠作出應對。你說：“其實我早就知道了，就是沒有做到?！蹦且彩遣粔蛎艚?。
所以所謂的敏捷，涉及兩個方面：敏銳的感覺和矯健的身手。
為什么要敏捷？
在過去的幾十年間，人類商業環境的變化和科技水平的發展正以指數級的趨勢在增長，于是商業組織和個人是否能夠在這樣劇烈的變化中生存下來，就變得非常重要，正是因為如此，敏捷開發所倡導的“響應變化”的價值觀才應運而生，也在過去的15年間得以發揚光大。
關于人類科技水平的變化，雷·庫茲韋爾提出了一個很有意思的定律，叫做“加速回報法則”，網絡上有一個更加通俗易懂的翻譯是“嚇尿單位”，下文轉自《人工智能革命：人類將永生或者滅絕》。
想象一下坐時間機器回到1750年的地球，那個時代沒有電，暢通通訊基本靠吼，交通主要靠動物拉著跑。你在那個時代邀請了一個叫老王的人到2015年來玩，順便看看他對“未來”有什么感受。我們可能沒有辦法了解1750年的老王內心的感受——金屬鐵殼在寬敞的公路上飛馳，和太平洋另一頭的人聊天，看幾千公里外正在發生進行的體育比賽，觀看一場發生于半個世紀前的演唱會，從口袋里掏出一個黑色長方形工具把眼前發生的事情記錄下來，生成一個地圖然后地圖上有個藍點告訴你現在的位置，一邊看著地球另一邊的人的臉一邊聊天，以及其它各種各樣的黑科技。別忘了，你還沒跟他解釋互聯網、國際空間站、大型強子對撞機、核武器以及相對論。
這時候的老王會是什么體驗？驚訝、震驚、腦洞大開這些詞都太溫順了，我覺得老王很可能直接被嚇尿了。
但是，如果老王回到了1750年，然后覺得被嚇尿是個很囧的體驗，于是他也想把別人嚇尿來滿足一下自己，那會發生什么？于是老王也回到了250年前的1500年，邀請生活在1500年的小李去1750年玩一下。小李可能會被250年后的很多東西震驚，但是至少他不會被嚇尿。同樣是250來年的時間，1750和2015年的差別，比1500年和1750年的差別，要大得多了。1500年的小李可能能學到很多神奇的物理知識，可能會驚訝于歐洲的帝國主義旅程，甚至對于世界地圖的認知也會大大的改變，但是1500年的小李，看到1750年的交通、通訊等等，并不會被嚇尿。
所以說，對于1750年的老王來說，要把人嚇尿，他需要回到更古老的過去——比如回到公元前12000年，第一次農業革命之前。那個時候還沒有城市，也還沒有文明。一個來自狩獵采集時代的人類，只是當時眾多物種中的一個罷了，來自那個時代的小趙看到1750年龐大的人類帝國，可以航行于海洋上的巨艦，居住在“室內”，無數的收藏品，神奇的知識和發現——他很有可能被嚇尿。
小趙被嚇尿后如果也想做同樣的事情呢？如果他會到公元前24000年，找到那個時代的小錢，然后給他展示公元前12000年的生活會怎樣呢。小錢大概會覺得小趙是吃飽了沒事干——“這不跟我的生活差不多么，呵呵”。小趙如果要把人嚇尿，可能要回到十萬年前或者更久，然后用人類對火和語言的掌控來把對方嚇尿。
所以，一個人去到未來，并且被嚇尿，他們需要滿足一個“嚇尿單位”。滿足嚇尿單位所需的年代間隔是不一樣的。在狩獵采集時代滿足一個嚇尿單位需要超過十萬年，而工業革命后一個嚇尿單位只要兩百多年就能滿足。
現在所有人對于人工智能的警覺也來源于此，因為也許我們下一個面對的“嚇尿單位”只有幾十年或者幾年了。
明確了敏捷開發價值觀的本意是“靈活應對變化”，以及敏捷開發的本質是追求“對變化敏銳的感覺”和“能夠跟上變化的矯健身手”之后，我們再來看看對敏捷開發常見的一些誤解。
誤解一：我們現在工期很緊，是不是可以嘗試一下敏捷開發？
在上文中我們提到，敏捷并不是“快”，目的也并非是“提升效率”。敏捷的目的是能夠做到“快速響應變化”。
如果說采用了敏捷方法之后，提升了效率和質量，那也只是我們做到“快速響應變化”之后的一個副產品罷了。
誤解二：敏捷開發就是沒有計劃，指哪兒打哪兒。
事實上，在之前階段式開發占據主流的年代，即使是最出色的技術人員，面對一個長達半年或一年的項目，讓他去估算，也很難做到準確無誤。甚至有數據表明，在一個三個月周期的開始階段，做出的估算上下誤差高達400%。
這么看來，在那個年代，我們估算并做出來的工作計劃只不過是自欺欺人罷了。
敏捷開發也并非采用了什么新的估算和計劃方法，只不過更加面對現實罷了，事實上，在敏捷宣言的網頁上有這樣一段話：
敏捷運動并不是反方法論的，事實上，我們中的大多數人正在試圖恢復方法論的名聲。我們希望能重歸平衡。我們樂于建模，但目的不是給無人問津的企業資源庫增加幾篇圖表存檔。我們要寫文檔，但那些從不維護、并很少用到的長篇大論不算在內。我們得做計劃，但同時也要認識到在劇烈變化的環境中計劃的局限。
不論是Scrum框架也好，Kanban方法也好，都不是沒有計劃。Scrum作為一個極度輕量級的開發框架，也把迭代計劃會作為保留下來的4個會議之一。Kanban方法背后的精益開發更是把計劃放到了每一次卡片拉動的過程中。
所以在敏捷開發中，并非是不做計劃，而是將過去的“長計劃”轉變為了“常計劃”，面對現實，不去做自欺欺人的長期計劃，而是經常性地、頻繁地調整計劃并做出預測。
誤解三：我們非常想嘗試敏捷開發，但不要改變任何現狀，也沒有時間投入到改進工作
在軟件工程的名著《人月神話》中，布魯克斯就已經下了一個斷言：軟件開發沒有銀彈。不存在什么放之四海而皆準的方法論和工具，應用之后就可以瞬間強身健體吃嘛嘛香，每一次改進和前進都是需要團隊和個人付出汗水和努力的。
如果什么也不做，那么什么也不會發生。
事實上，在敏捷轉型的過程之中，我們希望得到的更多是遠期的一些收益，短期之內開發效率、表現反而還會出現一些下降。其實這并不難理解：團隊需要時間去進行學習、適應新的工作方式和流程，當一切磨合好了之后，我們才會逐漸收回投資，我們把這種效應叫做“J-curve”，如下圖所示，橫軸是時間軸，縱軸是進行改進過程中團隊的效率和績效。
誤解四：我們現在有了迭代和站會，所以我們現在是敏捷的了。
上文中提到了敏捷開發被提出來的時候的目標是為了“更快地響應變化”。所以我們做了什么其實并不重要，重要的是我們做的這些事情有沒有使我們能夠敏銳地感覺到外界的變化，有沒有使我們能夠更快更可靠地對這些變化做出應對和反應。如果有的話，那你就踏上了“變敏捷”的道路，如果沒有，那我勸你要么調整姿勢，看看如何能夠得到這些收益，要么干脆就別折騰了。
畢竟，不看廣告，得看療效啊。
有的團隊在每個迭代的計劃會上，一不看上迭代結束之后干系人提出的反饋，二不看自己團隊上迭代完成的故事點數，直接蒙著眼睛做下迭代的計劃。
最終的結果是：每個迭代的計劃達成率都很低，而且也沒有及時將干系人的反饋意見調整到交付計劃中。
如果沒有收集到有效反饋，那么迭代演示會就是沒有效果的。
如果沒有根據上迭代的速率進行新迭代的計劃，那么計劃會就是失敗的。
誤解五：敏捷是好的，PMBOK/CMMI是壞的。
很多次我在給團隊一些改進意見的方案的時候，會聽到聲音說：“這也不是什么新鮮東西嘛?！薄斑@不是PMBOK里的東西嗎？”
舉個例子：我見過有一個幾百人的產品開發團隊，這個項目在前期風險管理做得非常不好。風險要么沒有識別出來，要么識別出的風險缺乏跟蹤，到項目執行中仍然會像放炮仗一樣一個接一個的爆炸。其實風險管理作為PMBOK九大知識領域之一，管理和應對手段都很成熟了。
應對的思路就有“轉移、接受、緩解、消除”四種，而我看到的情況通常都以“接受”為應對手段，賭這個風險不會發生，或者等一個Risk變成了Issue再去想應對方案。
風險識別不論是在需求優先級排序還是在架構設計上都是非常重要的一環，我們之所以把高價值、高風險的需求視作第一優先級，是因為我們希望盡早釋放風險，盡早緩解風險。我們提的“簡單設計”簡單到什么程度，也是由是否能夠涵蓋最重大的風險作為邊界的。
對于這種事情，我只能說，解決這類問題還沒到需要敏捷轉型才能解決的份兒上……
最后：在這篇文章里，我沒有寫到如何才能做到敏捷，只是希望看這篇文章的團隊和個人能夠真正理解敏捷所倡導的價值觀和我們做敏捷轉型所期望達到的效果，如果理解了這些，我相信每個人都能夠做出判斷：自己正在做的究竟是不是敏捷。
