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

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

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

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

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

合同談判　

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

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

遵循計(jì)劃

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

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

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

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

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

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

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

過程與工具

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

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

面面俱到的文檔

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

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

• Waterfall VS Agile

在一個ppt中看到一張Waterfall和Agile對比的圖。

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

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

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

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

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

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

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

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

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

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

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

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

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

個體與交互 勝過 過程與工具

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

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

可以工作的軟件 勝過 面面俱到的文檔

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

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

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

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

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

　　 勝過

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

敏捷開發(fā)之 4句敏捷宣言