前言： 這不是一篇介紹敏捷開發的入門文章， 而是我學習、實施敏捷的一些感想， 如果你沒有實踐過敏捷軟件開發， 不妨到文末看看書籍推薦。

       我大概是在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的經典。
　　《用戶故事與敏捷開發》 ： 描述用戶故事的經典圖書。
　　《敏捷估計與規劃》： 主講如何規劃一個敏捷項目
　　《持續集成》：有點老，但是了解下敏捷開發的基石還是不錯的。
　　（完）