敏捷開發(fā)之熱門已達(dá)到任何一個(gè)開發(fā)人員都至少聽過(guò)，并覺(jué)得敏捷方法很好，然而并不是所有的人都學(xué)習(xí)和實(shí)踐過(guò)，以致于大家談敏捷的時(shí)候其實(shí)理解的基準(zhǔn)是不一樣的，也導(dǎo)致“敏捷”泛濫成災(zāi)“，有些看似很敏捷的開發(fā)其實(shí)并不敏捷。

　　最近在一個(gè)項(xiàng)目中準(zhǔn)備采用Scrum開發(fā)方法來(lái)解決以往開發(fā)方法中遇到的一些問(wèn)題，所以近期將發(fā)表一些個(gè)人對(duì)敏捷的一些看法，歡迎和大家交流。

• 　 過(guò)程與工具、面面俱到的文檔、合同談判、遵循計(jì)劃

　　　　 　　個(gè)體與交互          勝過(guò)     過(guò)程與工具
　　　　　　    　 可以工作的軟件   勝過(guò)     面面俱到的文檔
　　　　　　　 　 客戶協(xié)作              勝過(guò)     合同談判
　　　　　　　 　 響應(yīng)變化              勝過(guò)     遵循計(jì)劃

　　2001年2月由17位世界輕量級(jí)方法學(xué)家提出了一份敏捷聯(lián)盟宣言，這個(gè)宣言只是簡(jiǎn)單的四句話，但卻是敏捷 方法的精髓，在談敏捷方法 之前就必須先對(duì)敏捷宣言有所理解。在和一些人員交流中，我發(fā)現(xiàn)大家都知道敏捷，但是能說(shuō)出這個(gè)簡(jiǎn)單的敏捷宣言的并不多，都說(shuō)當(dāng)時(shí)知道，過(guò)了一陣子就忘記 了。究其原因是靠死記硬背是不行的，需要通過(guò)自己的思考形成自己的理解才能夠真正記住。上面的敏捷宣言非常簡(jiǎn)單，僅僅四句話而已，有的項(xiàng)目會(huì)出現(xiàn)上面這個(gè) 漫畫所描述的狀況，領(lǐng)導(dǎo)說(shuō)“我們開始嘗試使用一種叫做敏捷的方法了，這就代表不再需要計(jì)劃并且不再需要文檔，只需要開始編碼”。這其實(shí)就是簡(jiǎn)單記住敏捷宣 言的幾個(gè)字而出現(xiàn)的嚴(yán)重誤解，下面我將對(duì)這四句話進(jìn)行解釋，希望大家跟 隨我的講解也能對(duì)這個(gè)宣言有所認(rèn)識(shí)。

　合同談判　　

　　項(xiàng)目開發(fā)一般都是跟隨著合同開始的。由 客戶經(jīng)理同客戶交談，在合同中確定一些法律條文以及交付產(chǎn)品包含的功能，然后客戶經(jīng)理拿著合同回到公司由開發(fā)小組經(jīng)過(guò)長(zhǎng)時(shí)間開發(fā)后再交付給客戶。在開發(fā)期 間，如果需要變更合同，則需要經(jīng)過(guò)一系列流程。開發(fā)過(guò)程中，有些客戶可能只是簡(jiǎn)單的詢問(wèn)一下進(jìn)度，有的甚至是到最后交付日了直接來(lái)問(wèn)你要東西，當(dāng)產(chǎn)品不能 滿足合同規(guī)定時(shí)就需要和客戶談判進(jìn)行解決。僅僅通過(guò)合同談判來(lái)開發(fā)產(chǎn)品，客戶在開發(fā)過(guò)程中就不會(huì)進(jìn)行實(shí)質(zhì)性的反饋，導(dǎo)致最終的產(chǎn)品不滿意也就很正常了。

   　產(chǎn)品開發(fā)在 早期市場(chǎng)不成熟的時(shí)候一般為公司領(lǐng)導(dǎo)（產(chǎn)品經(jīng)理、LPDT）驅(qū)動(dòng)，后期轉(zhuǎn)變?yōu)橛脩趄?qū)動(dòng)、銷售驅(qū)動(dòng)、服務(wù)驅(qū)動(dòng)，在矩陣式管理模式下，產(chǎn)品事業(yè)部和開發(fā)管理部 作為兩個(gè)部門時(shí)，在做產(chǎn)品開發(fā)的時(shí)候就會(huì)類似在進(jìn)行合同談判，從一開始就會(huì)在兩個(gè)部門之間產(chǎn)生爭(zhēng)執(zhí)而不是合作，這勢(shì)必會(huì)影響產(chǎn)品的開發(fā)。

　　遵循計(jì)劃

　　當(dāng)拿到合同時(shí)，公司就開始組建項(xiàng)目組進(jìn)行開發(fā)。此時(shí)需要項(xiàng)目經(jīng)理制定出明確的計(jì)劃，必須詳細(xì)列出需求、設(shè)計(jì)、開發(fā)、測(cè)試、部署的各項(xiàng)任務(wù)。當(dāng)項(xiàng) 目組提交看似完整齊全的計(jì)劃后，公司就視這個(gè)不變的計(jì)劃作為項(xiàng)目組對(duì)公司的承諾，沒(méi)有特殊情況時(shí)必須遵循制定的計(jì)劃，如果想要變化，則需要經(jīng)過(guò)公司評(píng)審。

　　軟件復(fù)雜度有三個(gè)主要因素：業(yè)務(wù)、技術(shù)和人員。

　　關(guān)于業(yè)務(wù)和技術(shù)的關(guān)系我已經(jīng)寫了一些博文，有興趣的可以去看看（從橫向領(lǐng)域和縱向領(lǐng)域來(lái)談業(yè)務(wù)和技術(shù)的關(guān)系 ）

    《agile project management with scrum》（中文書名：Scrum敏捷項(xiàng)目管理）一書中有一個(gè)復(fù)雜度的圖。

X軸表示技術(shù)（成熟度），Y軸表示業(yè)務(wù)（一致度）。從圖中可以看到，業(yè)務(wù)和技術(shù)是正交的，各自對(duì)復(fù)雜度都有影響，我們?cè)陂_發(fā)過(guò)程中需要做的通過(guò)各種辦法盡量確保從Anarchy－Complex－Complicated－Simple進(jìn)行轉(zhuǎn)移。

技術(shù)和業(yè)務(wù)最終都需要人來(lái)執(zhí)行，而每個(gè)人擁有不同的技能、經(jīng)驗(yàn)和觀點(diǎn)，當(dāng)這些人在一起合作時(shí)又會(huì)使得開發(fā)過(guò)程變得復(fù)雜。

這些復(fù)雜性將導(dǎo)致開發(fā)過(guò)程中存在很多不確定性，所以項(xiàng)目初期制定的計(jì)劃其實(shí)基本上不能真正的堅(jiān)持下來(lái)。而當(dāng)項(xiàng)目開發(fā)遇到困難時(shí)，項(xiàng)目組可能會(huì)為了表明自己做計(jì)劃的能力，或者不想經(jīng)歷復(fù)雜的變更過(guò)程，而繼續(xù)努力的堅(jiān)持這個(gè)已經(jīng)錯(cuò)誤的計(jì)劃。范圍、時(shí)間和成本，這 個(gè)金三角幾乎沒(méi)有領(lǐng)導(dǎo)不知道，而項(xiàng)目組為了保證”遵循計(jì)劃“，對(duì)外宣稱項(xiàng)目組運(yùn)行狀況良好，保證當(dāng)前人員在預(yù)計(jì)時(shí)間肯定能保質(zhì)保量的完成開發(fā)。而代碼質(zhì)量 只有開發(fā)人員知道，領(lǐng)導(dǎo)們?nèi)菀缀雎院碗y以控制這個(gè)環(huán)節(jié)，所以最后一味的遵循計(jì)劃就勢(shì)必導(dǎo)致提供給客戶的是一個(gè)不滿意的產(chǎn)品。

　　過(guò)程與工具

　　計(jì)劃制定后，項(xiàng)目組需要在類似ISO9000、CMMI、NPD等一些常用的項(xiàng)目管理方法下進(jìn)行開發(fā)管理。工欲善其事，必先利其器，可以找到很 多工具來(lái)支持開發(fā)，需求階段有原型工具、需求管理跟蹤工具，設(shè)計(jì)階段有Rose、PD，開發(fā)階段有各種IDE和輔助插件，測(cè)試階段有TD等。

　　合適的工具能很好的幫助開發(fā)，但當(dāng)在開發(fā)人員面前出現(xiàn)大量龐大笨重甚至不好用的工具和開發(fā)環(huán)境時(shí)，就會(huì)像缺少工具一樣，都是不好的。在開發(fā)過(guò)程中，可能會(huì)出現(xiàn)夸大了工具的作用,當(dāng)反應(yīng)說(shuō)開發(fā)工具對(duì)開發(fā)起起決定性的影響時(shí)， 這很有可能是在計(jì)劃階段就開始錯(cuò)了，就像衣服扣錯(cuò)的時(shí)候，一般都是扣第一個(gè)扣子的時(shí)候，而不是你發(fā)現(xiàn)扣錯(cuò)的那個(gè)扣子。

　　面面俱到的文檔

　　瀑布式開發(fā)下，文檔承載著各階段之間的信息傳遞。需求文檔中定義詳細(xì)用例，每個(gè)細(xì)節(jié)，原型中定義界面表現(xiàn)，甚至每個(gè)控件的具體位置，設(shè)計(jì)中的UML圖，數(shù)據(jù)庫(kù)設(shè)計(jì)圖，測(cè)試用例文檔等等，如果沒(méi)有文檔，開發(fā)將不能在過(guò)程中順利依次展開。

　　編寫和維護(hù)一份詳盡的需求文檔總是一個(gè)好主意，然而就像前面所說(shuō)業(yè)務(wù)復(fù)雜性帶來(lái)的不確定性，除非給我們充足的時(shí)間，否則我們不可能一開始就想清 楚所有細(xì)節(jié)。另一方面，編寫文檔需要花費(fèi)大量的時(shí)間，如果考慮和代碼的同步時(shí)，工作量更是急速上升，如果不考慮同步時(shí)，過(guò)多的文檔反而比過(guò)少的文檔還糟。 當(dāng)我們花大部分時(shí)間浪費(fèi)的文檔，仍舊只能以降低質(zhì)量來(lái)遵循計(jì)劃的執(zhí)行。

• Waterfall VS Agile

　     在一個(gè)ppt中看到一張Waterfall和Agile對(duì)比的圖。

瀑布式開發(fā)是計(jì)劃驅(qū)動(dòng)的，合同談判后項(xiàng)目組制定計(jì)劃并且遵循計(jì)劃，在過(guò)程與工具支持下通過(guò)面面俱到的文檔來(lái)定義不變的需求和其他文檔，在時(shí)間不夠時(shí)可以通過(guò)增加人員來(lái)緩解壓力。

而敏捷開發(fā)是價(jià)值驅(qū)動(dòng)，通過(guò)自組織團(tuán)隊(duì)在短期迭代過(guò)程中不斷的交付對(duì)用后有用的功能來(lái)進(jìn)行產(chǎn)品開發(fā)。

從上圖的正反三角形圖形可以看出兩者的驅(qū)動(dòng)是不同的，雖然宣言中右項(xiàng)（過(guò)程與工具、面面俱到的文檔、合同談判、遵循計(jì)劃）也很有價(jià)值，但是我們認(rèn)為左項(xiàng)（個(gè)體與交互、可以工作的軟件、客戶協(xié)作、響應(yīng)變化）更有價(jià)值，同時(shí)為了防止有些人學(xué)了敏捷之后而認(rèn)為右邊的沒(méi)有價(jià)值了，我會(huì)在每條說(shuō)明后重申一下右邊的仍舊需要。以下我將繼續(xù)對(duì)敏捷宣言中的左項(xiàng)內(nèi)容進(jìn)行解釋。

• 個(gè)體與交互、可以工作的軟件、客戶協(xié)作、響應(yīng)變化 

  　　　         個(gè)體與交互           勝過(guò)     過(guò)程與工具
　　　　　　   　  可以工作的軟件   勝過(guò)     面面俱到的文檔
　　　　　　　 　 客戶協(xié)作               勝過(guò)     合同談判
　　　　　　　 　 響應(yīng)變化               勝過(guò)     遵循計(jì)劃

　　客戶協(xié)作  勝過(guò)   合同談判

　　尋求客戶合作的價(jià)值重于對(duì)合同的談判。軟件開發(fā)的最終目標(biāo)是提供給客戶滿意的軟件，而只有客戶才更清楚怎么樣才能滿意，敏捷開發(fā)提倡客戶和開發(fā) 團(tuán)隊(duì)密切的在一起工作，并盡量經(jīng)常行得提供反饋。各種不同的敏捷方法都會(huì)利用短期迭代，通過(guò)盡早提供軟件來(lái)達(dá)到與客戶頻繁溝通和反饋的，這也可以把問(wèn)題及 早暴露出來(lái)，以免隱藏的問(wèn)題在后期造成更大的影響。

　　雖然我們致力于客戶協(xié)作，但為了雙方利益和需要仍舊需要進(jìn)行合同談判。

      響應(yīng)變化  勝過(guò)    遵循計(jì)劃

　　計(jì)劃趕不上變化，敏捷項(xiàng)目承認(rèn)開發(fā)過(guò)程中的不確定性，所以不會(huì)在開發(fā)中制定長(zhǎng)時(shí)間的復(fù)雜計(jì)劃，它們的成功都是建立在現(xiàn)實(shí)反饋的基礎(chǔ)上的。 Scrum依照一組簡(jiǎn)單實(shí)踐及規(guī)則，實(shí)施經(jīng)驗(yàn)性過(guò)程控制方法的檢查、適應(yīng)和保證可視性等步驟，處理軟件開發(fā)項(xiàng)目中的復(fù)雜問(wèn)題。通過(guò)迭代開發(fā)，每次迭代都是 基于上一迭代的完善基礎(chǔ)之上進(jìn)行的，通過(guò)不斷的響應(yīng)變化來(lái)消除開發(fā)中的不確定性。

　　雖然我們致力于響應(yīng)變化，但并不是像上面漫畫所說(shuō)的不需要計(jì)劃了,反而我們需要更多的規(guī)劃。

　　《Agile Estimating and Planning》（中文書名：敏捷估計(jì)與規(guī)劃）一書對(duì)如何做規(guī)劃進(jìn)行詳細(xì)的講解。它認(rèn)為規(guī)劃是困難的，而且作出的計(jì)劃常常會(huì)出錯(cuò)，面對(duì)這樣的問(wèn)題，開發(fā) 小組往往會(huì)走上兩個(gè)極端：要么根本不做任何規(guī)劃，要么在計(jì)劃中投入大量的精力直到自己確信計(jì)劃是正確的。不做規(guī)劃的小組對(duì)一些最基本的問(wèn)題，例如“你們什 么時(shí)候能完成？”以及“我們可以在6月份安排產(chǎn)品發(fā)布嗎？”都無(wú)法回答。而做了大量計(jì)劃的小組會(huì)自欺欺人地認(rèn)為某個(gè)計(jì)劃是“正確的”。他們的計(jì)劃也許更全 面，但這并不一定意味著它更準(zhǔn)確或更有用。這兩種極端都是敏捷需要避免的，最開始漫畫所說(shuō)的“我們實(shí)施敏捷，不再需要計(jì)劃和文檔了”的論調(diào)是及其錯(cuò)誤的。

　　敏捷不是不需要計(jì)劃，相反它需要更多的規(guī)劃。不確定性是影響計(jì)劃正確的主要因素，對(duì)大部分不確定而言，在獲取知識(shí)、減少不確定性的唯一辦法是通 過(guò)執(zhí)行－作一些事情、構(gòu)建一些東西或模擬一些東西－然后獲得反饋。許多項(xiàng)目管理方法是“規(guī)劃、規(guī)劃。規(guī)劃－執(zhí)行”，而敏捷開發(fā)方法是“規(guī)劃－執(zhí)行－調(diào) 整”、“規(guī)劃－執(zhí)行－調(diào)整”。一個(gè)項(xiàng)目的不確定性越高，敏捷開發(fā)方法對(duì)取得成功就越是至關(guān)重要，不斷學(xué)習(xí)和調(diào)整是敏捷開發(fā)的核心。

      個(gè)體與交互   勝過(guò)    過(guò)程與工具

　　方法和工具是死的，人是活的，如何沒(méi)有優(yōu)秀個(gè)人和團(tuán)隊(duì)協(xié)作，再?gòu)?qiáng)大的方法和工具都是擺設(shè)。一個(gè)使用普通工具的優(yōu)秀人員會(huì)比使用優(yōu)秀工具的普通人 員做得更好，一個(gè)具有合作精神、自組織的團(tuán)隊(duì)比通過(guò)過(guò)程規(guī)范的團(tuán)隊(duì)工作得更好。敏捷項(xiàng)目首先擁有一個(gè)小規(guī)模但擁有各種不同職能的成員，每個(gè)成員都需要定時(shí) 和團(tuán)隊(duì)的其他成員一起查看團(tuán)隊(duì)的整體進(jìn)度，計(jì)劃下一步工作，并一起探討所遭遇問(wèn)題的解決方案。自組織團(tuán)隊(duì)通過(guò)個(gè)人能力和協(xié)作能力，可以自發(fā)的通過(guò)各種途徑 解決開發(fā)過(guò)程中遇到的問(wèn)題。

　　雖然我們致力于個(gè)體和交互，但并不是不需要過(guò)程與工具了。Scrum、XP等方法本身也有一些方法和過(guò)程，每日構(gòu)造等敏捷實(shí)踐也需要工具的支持，需要哪些過(guò)程和工具由自組織團(tuán)隊(duì)制定，而不是由領(lǐng)導(dǎo)制定。

      可以工作的軟件   勝過(guò)     面面俱到的文檔

      在合同中有時(shí)會(huì)看到分別在需求、設(shè)計(jì)、開發(fā)、測(cè)試階段提供什么文檔，支付多少金額等內(nèi)容，而這些文檔對(duì)用戶來(lái)說(shuō)是不是真的有價(jià)值呢？面面俱到的文檔對(duì)客戶 來(lái)說(shuō)確并不重要，用戶需要的是一個(gè)能夠運(yùn)行起來(lái)，能夠?qū)嵸|(zhì)解決工作中問(wèn)題的可以工作的軟件。面面俱到的文檔對(duì)開發(fā)團(tuán)隊(duì)也不重要，上百頁(yè)的報(bào)告沒(méi)有人愿意 寫，更沒(méi)有人愿意去讀，對(duì)開發(fā)團(tuán)隊(duì)來(lái)說(shuō)最好的兩份文檔就是代碼和團(tuán)隊(duì)。通過(guò)頻繁的提供可以工作的軟件，我們也可以更為頻繁的搜集對(duì)產(chǎn)品和開發(fā)過(guò)程的反饋， 保證開發(fā)小組始終是在處理最具有價(jià)值的功能，而且這些功能可以滿足用戶的需要。

　　雖然我們致力于提供可供做的軟件，但并不是不要文檔。我們?cè)陂_發(fā)過(guò)程中仍然需要進(jìn)行內(nèi)部交流， 也需要和客戶交流，我們?nèi)耘f可能需要制作原型，書寫一些主要需求和算法，只要自組織團(tuán)隊(duì)認(rèn)為足夠就行了。

　　　　　　  個(gè)體與交互           勝過(guò)     過(guò)程與工具
　　　　　　   　  可以工作的軟件   勝過(guò)     面面俱到的文檔
　　　　　　　 　 客戶協(xié)作               勝過(guò)     合同談判
　　　　　　　 　 響應(yīng)變化               勝過(guò)     遵循計(jì)劃

　　這四句價(jià)值觀用語(yǔ)句表達(dá)就是：

　　　　自組織團(tuán)隊(duì)與客戶緊密協(xié)作，通過(guò)高度迭代式、增量式的軟件開發(fā)過(guò)程響應(yīng)變化，并在每次迭代結(jié)束時(shí)交付經(jīng)過(guò)編碼與測(cè)試的有價(jià)值的軟件

　　     勝過(guò)

　　　　與客戶確定合同后在初期制定并遵循基于活動(dòng)的完整計(jì)劃，在重型過(guò)程和工具指導(dǎo)下，通過(guò)完成大量文檔進(jìn)行知識(shí)傳遞，最后交付需求