我大概是在2003年接觸敏捷軟件開發這個概念，之前無論是在學校的小打小鬧項目，還是工作后的項目都是典型的瀑布式開發模式， 設計上自頂向下逐層分解， 設計、實現、測試、上線有條不紊。這不是一篇介紹敏捷開發的入門文章， 而是我學習、實施敏捷的一些感想， 如果你沒有實踐過敏捷軟件開發， 不妨到文末看看書籍推薦。

我大概是在2003年接觸敏捷軟件開發這個概念，之前無論是在學校的小打小鬧項目，還是工作后的項目都是典型的瀑布式開發模式， 設計上自頂向下逐層分解， 設計、實現、測試、上線有條不紊。

除了大學時做的某個人項目， 客戶在不停的提需求之外， 基本上沒遇到多少需求劇烈變更的情況（可能和做的項目有關，不是定制化軟件開發），所以覺得瀑布也挺好啊， 大學里《軟件工程》這么課講的瀑布開發還是很有用的嘛。

但是看到敏捷宣言以后，內心還是被狠狠的震撼了一下： 原來軟件開發還可以這么做！

這個宣言是這么說的：

注意下面的小字：盡管右項有其價值，我們更重視左項的價值。

這17位軟件開發的領軍人物所做出的吶喊絕對刷新了我的軟件開發三觀： 

我們的***目標是按時高質量的交付可以工作的軟件， 不是編寫那些非常容易過時的文檔，也不是遵循嚴格的評審流程。  

客戶要深度的參與到開發中來，我們會經常的給他們做演示，獲取他們的及時反饋， 而不是到***一刻才得知，我們做的并不是客戶想要的。

我們歡迎需求變化(即使在項目的后期！) ，為了達到這個目標， 我們會采用迭代化的開發方式，經常的交付可以工作的軟件。

了解理念之后， 很快我就接觸到敏捷開發的一個重要流派： 

XP(極限編程)， 提出者是Kent Beck, 這哥們搞的更絕：如果一個編程實踐很好， 我們就把它做到***！

測試不是很好嗎？ 那我們就測試先行， 用測試來驅動代碼的生成， 這就是TDD。

代碼評審不是很好嗎？ 那我們就一邊編程，一邊評審， 兩個人同時在一個電腦上編程，這就是結對編程。

......

我被XP給迷住了， 開始自學JUnit,   測試驅動開發， 重構代碼這些編程層面的實踐。

毫無疑問，這些實踐確實能提升代碼的質量，但是一直沒有機會在一個團隊中大規模的鋪開使用。

到了2008年， 公司突然間要做敏捷轉型，要實施Scrum, 于是又開始了新一輪學習，我這個XP粉絲剛開始還有點小抵觸， 后來發現Scrum僅僅是一個框架而已， 我以前學的一些敏捷實踐仍然可以運用到其中去。

有了新東西，大家忙活的熱火朝天，設立product owner, scrum master。

學習把需求改成用戶故事，拆分task,  創建燃盡圖。

開Sprint計劃會議， 每日站會，Sprint評審會，反思會等等符合Scrum的東西。

當然自動化測試，  自動化Build這些工程層面的東西也少不了。

熱乎勁兒過了以后，我不由的困惑起來：這真的

是敏捷嗎？

我們并沒有因為采用Scrum而變得更好更快的交付軟件，仍然是按照原來的節奏每年發布幾個release。

我非常期待的特性團隊，即一個團隊中既有需求人員， 又有開發人員，還有測試人員，文檔人員等并沒有建立起來。負責需求的業務分析師和開發團隊若即若離，測試團隊還是按照自己的步點來干活， 無法深度的參與到完成一個用戶故事的活動中來。

每個Sprint結束以后很難產生一個可供客戶演示、甚至發布到產品環境的軟件。

開發團隊的本質仍然是老一套，還是依賴項目經理、或者team leader 去驅動各個developer去干活， 看不到自組織（self-directive）的力量。

對用戶故事進行工作量評估的時候，大家還是關注資深開發和架構師的意見，做不到全員參與。

那個每日站會完全變成了一個匯報會，向項目經理匯報。

Sprint 說的是橄欖球比賽中的沖刺， 大家團結一致，為了完成該Sprint的目標瘋狂向前沖。 實際開發中卻很難體會到。

總而言之，我們似乎只是改了形式， 而沒有改變精神。

2009年和2010年， 我也有幸走出去實施了幾次敏捷咨詢服務，包括工行廣州開發中心，華為杭州研究所，鼎橋等等。 我發現不僅是我們， 大家都有類似的問題， 實施了敏捷形式而缺乏靈魂。

聽起來很美好的敏捷軟件開發很難落地，生根發芽，開花結果， 這些情況引起我的反思： 難道理想中的敏捷開發根本就不存在？  為什么敏捷開發這么難于實施？

經過一段時間的思考，我覺得實施敏捷最重要的有以下幾點， 如果做不到這幾點，敏捷是很難真正成功的：

1.  組織結構一定得變革

如果還是維持那種需求/產品團隊， 開發團隊，測試團隊的方式，各個團隊各自為政，老死不相往來的方式，敏捷肯定要失敗。

由多種技能人員組成的特性團隊是非常重要的，對小公司來說， 建立特性團隊相對容易， 但對大公司來說，這簡直就是一場革命，肯定要觸動不少人的利益，有既得利益者的阻撓， 這是非常難的。

所以很多大公司也了解敏捷的好處， 在小范圍內做了試點，然后說敏捷不錯， 但現階段還不適合我們， ***不了了之。

2. 人的技能和意識一定得提高

先說技能，敏捷開發對團隊成員的要求是提高了，而不是降低了。

開發人員要能寫代碼、寫測試、做重構、做Build， 還得具備處理遺留代碼的能力。 

寫出的代碼質量一定得高，擴展性強， 這樣才能“擁抱”客戶的變化，這比以前隨便寫代碼，完成功能的要求不知道要高了多少。 

敏捷之前的團隊有人專門做設計， 有人專門做開發， 敏捷之后這個界限模糊了， 大部分人設計和開發都得做， 對那些習慣做最基本開發的程序員是重大挑戰。 

同樣，開發角色和測試角色的界限也開始模糊，開發人員要能做些測試工作， 測試人員也要能協助做點開發工作。這樣才能夠在打仗的時候互相掩護， 奮勇沖鋒。 一個人出了狀況很快就有人能補上去。 

特性團隊中的成員，***是像軍隊中的特種兵那樣強悍。

其次是意識，正如我前邊所提到的，現在的很多團隊成員主動性并不強，都是在被動的等待任務的分配， 也不敢大膽的提出自己的觀點和見解， 這和敏捷開發的要求是相悖的。

有些公司在大量使用外包人員參與開發， 這些人在工作中就會出現上面的情況，  并不是貶低外包， 我也見過非常優秀的外包人員，  但是大部分人的主動性都不夠，  敏捷開發是搞不起來的。

我記得華為有個很強悍的小團隊，就幾個人， 總是能把事情做的漂漂亮亮， 我相信無論用什么樣的開發方法對他們來說都不是問題。 歸根結底，還是人的問題。

對于想了解敏捷開發的同學，推薦幾本書：

《硝煙中的Scrum和XP》：短小精悍，迅速了解敏捷軟件開發。

《敏捷軟件開發：原則、模式、實踐》： 除了面向對象的設計之外，里邊那個打保齡球的例子是個非常好的TDD案例。

《重構 : 改善既有代碼的設計》： 敏捷編程實踐中最基本技能。

《解析極限編程：擁抱變化》：XP的大師Kent beck的經典。

《用戶故事與敏捷開發》 ： 描述用戶故事的經典圖書。

《敏捷估計與規劃》： 主講如何規劃一個敏捷項目

《持續集成》：有點老，但是了解下敏捷開發的基石還是不錯的。