zhb8015

在一家以敏捷開發和咨詢著稱的公司工作了一年了，以下是我當前對敏捷的認識：

1. 敏捷宣言：

個體與交互      勝過     過程與工具
可以工作的軟件    勝過     面面俱到的文檔
客戶協作       勝過     合同談判
響應變化       勝過     遵循計劃

以上是大家熟悉的四句箴言，但還有一句話也許常被忽略：“即，雖然右側條目有其價值，但我們更重視左側條目”。這句話也放在了宣言不顯著的地方。宣言的官網背景是幾位敏捷先賢討論問題的畫面，中間的大胡子應該是老馬（Martin Fowler）。這副背景畫頗有宗教油畫的風格。

2. CMMI

一 個叫德里克·布魯克斯的人曾經領導開發過一個失敗的大型計算機操作系統：System/360。他離開這個項目后寫出了古典名著《人月神話》。接替布魯克 斯來擦項目屁股的人叫做瓦茨·漢弗里。漢弗里驚訝的發現這么大的項目居然沒有正式嚴格的計劃，不知道漢弗里到底經歷的多少麻煩，他退休后加入了一個五角大 樓開辦的軟件工程學院，在那兒他和同事們建立了軟件成熟度模型（CMM），其中最有名的是其五個臺階：

臺階一：組織基本沒做啥
臺階二：組織做一些計劃，跟蹤，配置管理工作，也討論質量保證等話題
臺階三：組織為各種活動定義了過程
臺階四：組織有了準繩，活動可以跟蹤和度量
臺階五：組織有持續改進的過程

有時，敏捷和CMMI被人們一起談論作對比，從我對它們目前的了解來看，兩者似乎沒太多聯系。而且CMM5的“持續改進的過程”似乎比“敏捷”還敏捷。

3. Scrum

我第一次真正對敏捷產生興趣是兩年前聽說了這個詞，隨后參加了公司的Scrum的興趣小組，也讀了些Scrum的書，其中對這本印 象深刻。有一陣子還傻乎乎的自己給自己寫Backlog，Sprint和Story，還關注下Burning down chart。對于很多人，或許Scrum就是敏捷，敏捷就是Scrum。依我看來，Scrum像是CMM3 + 敏捷，或者是基于敏捷理念的開發流程。有趣的是：幾乎每本Scrum的書和文章都要提到一雞和豬的故事。Scrum之所以流行可能是其提供一整套可操作的 過程，容易上手，如同方便面一般方便。但是教條的執行Scrum我看還真一點都不敏捷。

4. 極限編程（XP）

極限編程的名字起得頗有邪教的感覺。XP要比Scrum歷史悠久，但沒有Scrum那么流行。XP中的TDD和結對編程常常引起很大的爭議。在我一年的XP實踐中，我卻很對這兩個玩意產生了極大的興趣。、

反感TDD的人往往是沒有真正嘗試過TDD的人，想玩玩TDD的最佳方式也許是跟一個熟悉TDD程序員結對一會兒。很多場合下，用TDD開發非常有趣并且能寫出高質量的代碼。但是任何時候都教調的使用TDD不一定能帶來多大好處，測試代碼也有維護成本的。

對 于結對編程，大多數人都是很難理解的。有些擁有結對編程經驗的程序員對它又愛又恨。結對最大的好處或許是知識傳播，想學習某種技術時和一個高手結對是效率 非常高的方式。新人加入團隊，和老成員結對能非常迅速的進入狀態。但是兩個水平差異不大，但開發習慣迥異的人坐在一起結隊是一種煎熬。一個經常發生的事情 是：經過長時間無意義的討論甚至爭吵后，雙方妥協寫出一段折中的代碼，這段代碼僅僅是折中的而不是最好的代碼。

5. 精益（Lean）

敏 捷宣言已經發布十年了，已經不是新鮮玩意了。業界需要點新潮點的詞匯。精益來自于豐田公司的生產模式。在朝鮮戰爭時期，豐田汽車公司為了為美軍提供更多品 種的汽車，來自豐田紡織公司的大野耐一根據以往的經驗并通過不斷的實踐發明了豐田生產方式。這種生產方式在學術界被稱為精益生產。精益生產中有不少實踐跟 一些敏捷開發實踐不謀而合，如自動化，可視化等。但是生搬硬套精益思想中的一些理念到軟件開發中多少有些別扭。

6. 敏捷實踐

以下是我接觸過的敏捷實踐：
結對編程：尤其適合老人帶新人，和老藝人傳幫帶很像，和高手結對真是職業生涯的幸事
TDD：有趣，值得嘗試
站立會議：不錯的交流方式，站會講究簡短不展開，有問題會后交流
故事卡：一種很有效的需求分析方式
故事墻：可視化項目進展，很有趣，但我個人認為作用不大
燃燒曲線：沒感覺，或許客戶喜歡看
回顧會議：回顧會議的召開需要些技巧，需要個好的主持方式，確實能暴露問題
Show Case:需要客戶配合才有作用
重構：啥也不說了，最爽的事

迭代開發：討厭僵化的迭代開發，迭代計劃還是有彈性的好

看板方式：來自精益生產，能夠取消迭代，減少浪費，贊
持續集成：見7

7. 持續集成

每當Build成功，就有小鳥唱歌；Build失敗就是一聲悶雷，團隊中必須有人站出來為此負責。這種開發模式我去年才剛剛接觸到，但恐怕我的職業生涯會離不開它了，我認為它是最有用的敏捷開發實踐。甚至有些同事對持續集成的評價是持續集成就是敏捷。

8. 傳說中的敏捷團隊

傳說中的敏捷團隊，每個人都是多面手，溝通暢通，有效協作，共同成長并且持續改進，心心相通，眾志成城，快速響應變化，為客戶帶來最大的價值。我相信這樣的團隊是存在的，因為我現在所處的項目團隊已經讓我看到了敏捷團隊的雛形。

9. Martin Fowler

有幸和老馬有了一次面對面的交流，和老馬介紹了下我們的項目，但他也沒有給出什么建議。
最后我問了兩個問題：
我：您是我的偶像，請問我如何才能成為一個像您這樣的軟件開發高手？
老馬：我無法回答，我不是開發者了，我只是個演說者。
我：項目中和客戶交流，客戶說你們不用搞太多測試和TDD之類，我們希望你們做的更快些，多實現功能為主。我認為我們的主要目的是為客戶多交付價值，所以我們確實應該減少測試的力度，您怎么看？
老馬：你需要權衡（Trade off），但在我看來寫測試只會讓我更快些。

10. 對敏捷的質疑

一篇對敏捷諷刺的帖子，的確，如果教條的使用一些敏捷實踐恐怕沒什么好處。在公司內部，也有很多質疑敏捷的聲音，我想如果沒有質疑和反饋來促使改進，敏捷就不是敏捷了。

11. 技術 > 任何方法論

我到現在還一直持有這個偏激的觀點：軟件開發不是工程而是藝術，開發者的技術水平決定了軟件的水平。敏捷實踐能夠幫助優秀的發者們做的更好更快。但追求更高的技術才是軟件開發的王道。