我大概是在2003年接觸敏捷軟件開(kāi)發(fā)這個(gè)概念，之前無(wú)論是在學(xué)校的小打小鬧項(xiàng)目，還是工作后的項(xiàng)目都是典型的瀑布式開(kāi)發(fā)模式， 設(shè)計(jì)上自頂向下逐層分解， 設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試、上線(xiàn)有條不紊。這不是一篇介紹敏捷開(kāi)發(fā)的入門(mén)文章， 而是我學(xué)習(xí)、實(shí)施敏捷的一些感想， 如果你沒(méi)有實(shí)踐過(guò)敏捷軟件開(kāi)發(fā)， 不妨到文末看看書(shū)籍推薦。

我大概是在2003年接觸敏捷軟件開(kāi)發(fā)這個(gè)概念，之前無(wú)論是在學(xué)校的小打小鬧項(xiàng)目，還是工作后的項(xiàng)目都是典型的瀑布式開(kāi)發(fā)模式， 設(shè)計(jì)上自頂向下逐層分解， 設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試、上線(xiàn)有條不紊。

除了大學(xué)時(shí)做的某個(gè)人項(xiàng)目， 客戶(hù)在不停的提需求之外， 基本上沒(méi)遇到多少需求劇烈變更的情況（可能和做的項(xiàng)目有關(guān)，不是定制化軟件開(kāi)發(fā)），所以覺(jué)得瀑布也挺好啊， 大學(xué)里《軟件工程》這么課講的瀑布開(kāi)發(fā)還是很有用的嘛。

但是看到敏捷宣言以后，內(nèi)心還是被狠狠的震撼了一下： 原來(lái)軟件開(kāi)發(fā)還可以這么做！

這個(gè)宣言是這么說(shuō)的：

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

這17位軟件開(kāi)發(fā)的領(lǐng)軍人物所做出的吶喊絕對(duì)刷新了我的軟件開(kāi)發(fā)三觀： 

我們的***目標(biāo)是按時(shí)高質(zhì)量的交付可以工作的軟件， 不是編寫(xiě)那些非常容易過(guò)時(shí)的文檔，也不是遵循嚴(yán)格的評(píng)審流程。  

客戶(hù)要深度的參與到開(kāi)發(fā)中來(lái)，我們會(huì)經(jīng)常的給他們做演示，獲取他們的及時(shí)反饋， 而不是到***一刻才得知，我們做的并不是客戶(hù)想要的。

我們歡迎需求變化(即使在項(xiàng)目的后期！) ，為了達(dá)到這個(gè)目標(biāo)， 我們會(huì)采用迭代化的開(kāi)發(fā)方式，經(jīng)常的交付可以工作的軟件。

了解理念之后， 很快我就接觸到敏捷開(kāi)發(fā)的一個(gè)重要流派： 

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

測(cè)試不是很好嗎？ 那我們就測(cè)試先行， 用測(cè)試來(lái)驅(qū)動(dòng)代碼的生成， 這就是TDD。

代碼評(píng)審不是很好嗎？ 那我們就一邊編程，一邊評(píng)審， 兩個(gè)人同時(shí)在一個(gè)電腦上編程，這就是結(jié)對(duì)編程。

......

我被XP給迷住了， 開(kāi)始自學(xué)JUnit,   測(cè)試驅(qū)動(dòng)開(kāi)發(fā)， 重構(gòu)代碼這些編程層面的實(shí)踐。

毫無(wú)疑問(wèn)，這些實(shí)踐確實(shí)能提升代碼的質(zhì)量，但是一直沒(méi)有機(jī)會(huì)在一個(gè)團(tuán)隊(duì)中大規(guī)模的鋪開(kāi)使用。

到了2008年， 公司突然間要做敏捷轉(zhuǎn)型，要實(shí)施Scrum, 于是又開(kāi)始了新一輪學(xué)習(xí)，我這個(gè)XP粉絲剛開(kāi)始還有點(diǎn)小抵觸， 后來(lái)發(fā)現(xiàn)Scrum僅僅是一個(gè)框架而已， 我以前學(xué)的一些敏捷實(shí)踐仍然可以運(yùn)用到其中去。

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

學(xué)習(xí)把需求改成用戶(hù)故事，拆分task,  創(chuàng)建燃盡圖。

開(kāi)Sprint計(jì)劃會(huì)議， 每日站會(huì)，Sprint評(píng)審會(huì)，反思會(huì)等等符合Scrum的東西。

當(dāng)然自動(dòng)化測(cè)試，  自動(dòng)化Build這些工程層面的東西也少不了。

熱乎勁兒過(guò)了以后，我不由的困惑起來(lái)：這真的

是敏捷嗎？

我們并沒(méi)有因?yàn)椴捎肧crum而變得更好更快的交付軟件，仍然是按照原來(lái)的節(jié)奏每年發(fā)布幾個(gè)release。

我非常期待的特性團(tuán)隊(duì)，即一個(gè)團(tuán)隊(duì)中既有需求人員， 又有開(kāi)發(fā)人員，還有測(cè)試人員，文檔人員等并沒(méi)有建立起來(lái)。負(fù)責(zé)需求的業(yè)務(wù)分析師和開(kāi)發(fā)團(tuán)隊(duì)若即若離，測(cè)試團(tuán)隊(duì)還是按照自己的步點(diǎn)來(lái)干活， 無(wú)法深度的參與到完成一個(gè)用戶(hù)故事的活動(dòng)中來(lái)。

每個(gè)Sprint結(jié)束以后很難產(chǎn)生一個(gè)可供客戶(hù)演示、甚至發(fā)布到產(chǎn)品環(huán)境的軟件。

開(kāi)發(fā)團(tuán)隊(duì)的本質(zhì)仍然是老一套，還是依賴(lài)項(xiàng)目經(jīng)理、或者team leader 去驅(qū)動(dòng)各個(gè)developer去干活， 看不到自組織（self-directive）的力量。

對(duì)用戶(hù)故事進(jìn)行工作量評(píng)估的時(shí)候，大家還是關(guān)注資深開(kāi)發(fā)和架構(gòu)師的意見(jiàn)，做不到全員參與。

那個(gè)每日站會(huì)完全變成了一個(gè)匯報(bào)會(huì)，向項(xiàng)目經(jīng)理匯報(bào)。

Sprint 說(shuō)的是橄欖球比賽中的沖刺， 大家團(tuán)結(jié)一致，為了完成該Sprint的目標(biāo)瘋狂向前沖。 實(shí)際開(kāi)發(fā)中卻很難體會(huì)到。

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

2009年和2010年， 我也有幸走出去實(shí)施了幾次敏捷咨詢(xún)服務(wù)，包括工行廣州開(kāi)發(fā)中心，華為杭州研究所，鼎橋等等。 我發(fā)現(xiàn)不僅是我們， 大家都有類(lèi)似的問(wèn)題， 實(shí)施了敏捷形式而缺乏靈魂。

聽(tīng)起來(lái)很美好的敏捷軟件開(kāi)發(fā)很難落地，生根發(fā)芽，開(kāi)花結(jié)果， 這些情況引起我的反思： 難道理想中的敏捷開(kāi)發(fā)根本就不存在？  為什么敏捷開(kāi)發(fā)這么難于實(shí)施？

經(jīng)過(guò)一段時(shí)間的思考，我覺(jué)得實(shí)施敏捷最重要的有以下幾點(diǎn)， 如果做不到這幾點(diǎn)，敏捷是很難真正成功的：

1.  組織結(jié)構(gòu)一定得變革

如果還是維持那種需求/產(chǎn)品團(tuán)隊(duì)， 開(kāi)發(fā)團(tuán)隊(duì)，測(cè)試團(tuán)隊(duì)的方式，各個(gè)團(tuán)隊(duì)各自為政，老死不相往來(lái)的方式，敏捷肯定要失敗。

由多種技能人員組成的特性團(tuán)隊(duì)是非常重要的，對(duì)小公司來(lái)說(shuō)， 建立特性團(tuán)隊(duì)相對(duì)容易， 但對(duì)大公司來(lái)說(shuō)，這簡(jiǎn)直就是一場(chǎng)革命，肯定要觸動(dòng)不少人的利益，有既得利益者的阻撓， 這是非常難的。

所以很多大公司也了解敏捷的好處， 在小范圍內(nèi)做了試點(diǎn)，然后說(shuō)敏捷不錯(cuò)， 但現(xiàn)階段還不適合我們， ***不了了之。

2. 人的技能和意識(shí)一定得提高

先說(shuō)技能，敏捷開(kāi)發(fā)對(duì)團(tuán)隊(duì)成員的要求是提高了，而不是降低了。

開(kāi)發(fā)人員要能寫(xiě)代碼、寫(xiě)測(cè)試、做重構(gòu)、做Build， 還得具備處理遺留代碼的能力。 

寫(xiě)出的代碼質(zhì)量一定得高，擴(kuò)展性強(qiáng)， 這樣才能“擁抱”客戶(hù)的變化，這比以前隨便寫(xiě)代碼，完成功能的要求不知道要高了多少。 

敏捷之前的團(tuán)隊(duì)有人專(zhuān)門(mén)做設(shè)計(jì)， 有人專(zhuān)門(mén)做開(kāi)發(fā)， 敏捷之后這個(gè)界限模糊了， 大部分人設(shè)計(jì)和開(kāi)發(fā)都得做， 對(duì)那些習(xí)慣做最基本開(kāi)發(fā)的程序員是重大挑戰(zhàn)。 

同樣，開(kāi)發(fā)角色和測(cè)試角色的界限也開(kāi)始模糊，開(kāi)發(fā)人員要能做些測(cè)試工作， 測(cè)試人員也要能協(xié)助做點(diǎn)開(kāi)發(fā)工作。這樣才能夠在打仗的時(shí)候互相掩護(hù)， 奮勇沖鋒。 一個(gè)人出了狀況很快就有人能補(bǔ)上去。 

特性團(tuán)隊(duì)中的成員，***是像軍隊(duì)中的特種兵那樣強(qiáng)悍。

其次是意識(shí)，正如我前邊所提到的，現(xiàn)在的很多團(tuán)隊(duì)成員主動(dòng)性并不強(qiáng)，都是在被動(dòng)的等待任務(wù)的分配， 也不敢大膽的提出自己的觀點(diǎn)和見(jiàn)解， 這和敏捷開(kāi)發(fā)的要求是相悖的。

有些公司在大量使用外包人員參與開(kāi)發(fā)， 這些人在工作中就會(huì)出現(xiàn)上面的情況，  并不是貶低外包， 我也見(jiàn)過(guò)非常優(yōu)秀的外包人員，  但是大部分人的主動(dòng)性都不夠，  敏捷開(kāi)發(fā)是搞不起來(lái)的。

我記得華為有個(gè)很強(qiáng)悍的小團(tuán)隊(duì)，就幾個(gè)人， 總是能把事情做的漂漂亮亮， 我相信無(wú)論用什么樣的開(kāi)發(fā)方法對(duì)他們來(lái)說(shuō)都不是問(wèn)題。 歸根結(jié)底，還是人的問(wèn)題。

對(duì)于想了解敏捷開(kāi)發(fā)的同學(xué)，推薦幾本書(shū)：

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

《敏捷軟件開(kāi)發(fā)：原則、模式、實(shí)踐》： 除了面向?qū)ο蟮脑O(shè)計(jì)之外，里邊那個(gè)打保齡球的例子是個(gè)非常好的TDD案例。

《重構(gòu) : 改善既有代碼的設(shè)計(jì)》： 敏捷編程實(shí)踐中最基本技能。

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

《用戶(hù)故事與敏捷開(kāi)發(fā)》 ： 描述用戶(hù)故事的經(jīng)典圖書(shū)。

《敏捷估計(jì)與規(guī)劃》： 主講如何規(guī)劃一個(gè)敏捷項(xiàng)目

《持續(xù)集成》：有點(diǎn)老，但是了解下敏捷開(kāi)發(fā)的基石還是不錯(cuò)的。