敏捷開發(fā)之熱門已達到任何一個開發(fā)人員都至少聽過，并覺得敏捷方法很好，然而并不是所有的人都學(xué)習(xí)和實踐過，以致于大家談敏捷的時候其實理解的基準(zhǔn)是不一樣的，也導(dǎo)致“敏捷”泛濫成災(zāi)“，有些看似很敏捷的開發(fā)其實并不敏捷。
最近在一個項目中準(zhǔn)備采用Scrum開發(fā)方法來解決以往開發(fā)方法中遇到的一些問題，所以近期將發(fā)表一些個人對敏捷的一些看法，歡迎和大家交流。
個體與交互 勝過 過程與工具
可以工作的軟件 勝過 面面俱到的文檔
客戶協(xié)作 勝過 合同談判
響應(yīng)變化 勝過 遵循計劃
2001年2月由17位世界輕量級方法學(xué)家提出了一份敏捷聯(lián)盟宣言，這個宣言只是簡單的四句話，但卻是敏捷方法的精髓，在談敏捷方法之前就必須先對敏捷宣言有所理解。在和一些人員交流中，我發(fā)現(xiàn)大家都知道敏捷，但是能說出這個簡單的敏捷宣言的并不多，都說當(dāng)時知道，過了一陣子就忘記了。究其原因是靠死記硬背是不行的，需要通過自己的思考形成自己的理解才能夠真正記住。上面的敏捷宣言非常簡單，僅僅四句話而已，有的項目會出現(xiàn)上面這個漫畫所描述的狀況，領(lǐng)導(dǎo)說“我們開始嘗試使用一種叫做敏捷的方法了，這就代表不再需要計劃并且不再需要文檔，只需要開始編碼”。這其實就是簡單記住敏捷宣言的幾個字而出現(xiàn)的嚴重誤解，下面我將對這四句話進行解釋，希望大家跟隨我的講解也能對這個宣言有所認識。
合同談判
項目開發(fā)一般都是跟隨著合同開始的。由客戶經(jīng)理同客戶交談，在合同中確定一些法律條文以及交付產(chǎn)品包含的功能，然后客戶經(jīng)理拿著合同回到公司由開發(fā)小組經(jīng)過長時間開發(fā)后再交付給客戶。在開發(fā)期間，如果需要變更合同，則需要經(jīng)過一系列流程。開發(fā)過程中，有些客戶可能只是簡單的詢問一下進度，有的甚至是到最后交付日了直接來問你要東西，當(dāng)產(chǎn)品不能滿足合同規(guī)定時就需要和客戶談判進行解決。僅僅通過合同談判來開發(fā)產(chǎn)品，客戶在開發(fā)過程中就不會進行實質(zhì)性的反饋，導(dǎo)致最終的產(chǎn)品不滿意也就很正常了。
產(chǎn)品開發(fā)在早期市場不成熟的時候一般為公司領(lǐng)導(dǎo)（產(chǎn)品經(jīng)理、LPDT）驅(qū)動，后期轉(zhuǎn)變?yōu)橛脩趄?qū)動、銷售驅(qū)動、服務(wù)驅(qū)動，在矩陣式管理模式下，產(chǎn)品事業(yè)部和開發(fā)管理部作為兩個部門時，在做產(chǎn)品開發(fā)的時候就會類似在進行合同談判，從一開始就會在兩個部門之間產(chǎn)生爭執(zhí)而不是合作，這勢必會影響產(chǎn)品的開發(fā)。
遵循計劃
當(dāng)拿到合同時，公司就開始組建項目組進行開發(fā)。此時需要項目經(jīng)理制定出明確的計劃，必須詳細列出需求、設(shè)計、開發(fā)、測試、部署的各項任務(wù)。當(dāng)項目組提交看似完整齊全的計劃后，公司就視這個不變的計劃作為項目組對公司的承諾，沒有特殊情況時必須遵循制定的計劃，如果想要變化，則需要經(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敏捷項目管理）一書中有一個復(fù)雜度的圖。
X軸表示技術(shù)（成熟度），Y軸表示業(yè)務(wù)（一致度）。從圖中可以看到，業(yè)務(wù)和技術(shù)是正交的，各自對復(fù)雜度都有影響，我們在開發(fā)過程中需要做的通過各種辦法盡量確保從Anarchy－Complex－Complicated－Simple進行轉(zhuǎn)移。
技術(shù)和業(yè)務(wù)最終都需要人來執(zhí)行，而每個人擁有不同的技能、經(jīng)驗和觀點，當(dāng)這些人在一起合作時又會使得開發(fā)過程變得復(fù)雜。
這些復(fù)雜性將導(dǎo)致開發(fā)過程中存在很多不確定性，所以項目初期制定的計劃其實基本上不能真正的堅持下來。而當(dāng)項目開發(fā)遇到困難時，項目組可能會為了表明自己做計劃的能力，或者不想經(jīng)歷復(fù)雜的變更過程，而繼續(xù)努力的堅持這個已經(jīng)錯誤的計劃。范圍、時間和成本，這個金三角幾乎沒有領(lǐng)導(dǎo)不知道，而項目組為了保證”遵循計劃“，對外宣稱項目組運行狀況良好，保證當(dāng)前人員在預(yù)計時間肯定能保質(zhì)保量的完成開發(fā)。而代碼質(zhì)量只有開發(fā)人員知道，領(lǐng)導(dǎo)們?nèi)菀缀雎院碗y以控制這個環(huán)節(jié)，所以最后一味的遵循計劃就勢必導(dǎo)致提供給客戶的是一個不滿意的產(chǎn)品。
過程與工具
計劃制定后，項目組需要在類似ISO9000、CMMI、NPD等一些常用的項目管理方法下進行開發(fā)管理。工欲善其事，必先利其器，可以找到很多工具來支持開發(fā)，需求階段有原型工具、需求管理跟蹤工具，設(shè)計階段有Rose、PD，開發(fā)階段有各種IDE和輔助插件，測試階段有TD等。
合適的工具能很好的幫助開發(fā)，但當(dāng)在開發(fā)人員面前出現(xiàn)大量龐大笨重甚至不好用的工具和開發(fā)環(huán)境時，就會像缺少工具一樣，都是不好的。在開發(fā)過程中，可能會出現(xiàn)夸大了工具的作用,當(dāng)反應(yīng)說開發(fā)工具對開發(fā)起起決定性的影響時， 這很有可能是在計劃階段就開始錯了，就像衣服扣錯的時候，一般都是扣第一個扣子的時候，而不是你發(fā)現(xiàn)扣錯的那個扣子。
面面俱到的文檔
瀑布式開發(fā)下，文檔承載著各階段之間的信息傳遞。需求文檔中定義詳細用例，每個細節(jié)，原型中定義界面表現(xiàn)，甚至每個控件的具體位置，設(shè)計中的UML圖，數(shù)據(jù)庫設(shè)計圖，測試用例文檔等等，如果沒有文檔，開發(fā)將不能在過程中順利依次展開。
編寫和維護一份詳盡的需求文檔總是一個好主意，然而就像前面所說業(yè)務(wù)復(fù)雜性帶來的不確定性，除非給我們充足的時間，否則我們不可能一開始就想清楚所有細節(jié)。另一方面，編寫文檔需要花費大量的時間，如果考慮和代碼的同步時，工作量更是急速上升，如果不考慮同步時，過多的文檔反而比過少的文檔還糟。當(dāng)我們花大部分時間浪費的文檔，仍舊只能以降低質(zhì)量來遵循計劃的執(zhí)行。
在一個ppt中看到一張Waterfall和Agile對比的圖。
瀑布式開發(fā)是計劃驅(qū)動的，合同談判后項目組制定計劃并且遵循計劃，在過程與工具支持下通過面面俱到的文檔來定義不變的需求和其他文檔，在時間不夠時可以通過增加人員來緩解壓力。
而敏捷開發(fā)是價值驅(qū)動，通過自組織團隊在短期迭代過程中不斷的交付對用后有用的功能來進行產(chǎn)品開發(fā)。
從上圖的正反三角形圖形可以看出兩者的驅(qū)動是不同的，雖然宣言中右項（過程與工具、面面俱到的文檔、合同談判、遵循計劃）也很有價值，但是我們認為左項（個體與交互、可以工作的軟件、客戶協(xié)作、響應(yīng)變化）更有價值，同時為了防止有些人學(xué)了敏捷之后而認為右邊的沒有價值了，我會在每條說明后重申一下右邊的仍舊需要。以下我將繼續(xù)對敏捷宣言中的左項內(nèi)容進行解釋。
個體與交互 勝過 過程與工具
可以工作的軟件 勝過 面面俱到的文檔
客戶協(xié)作 勝過 合同談判
響應(yīng)變化 勝過 遵循計劃
客戶協(xié)作 勝過 合同談判
尋求客戶合作的價值重于對合同的談判。軟件開發(fā)的最終目標(biāo)是提供給客戶滿意的軟件，而只有客戶才更清楚怎么樣才能滿意，敏捷開發(fā)提倡客戶和開發(fā)團隊密切的在一起工作，并盡量經(jīng)常行得提供反饋。各種不同的敏捷方法都會利用短期迭代，通過盡早提供軟件來達到與客戶頻繁溝通和反饋的，這也可以把問題及早暴露出來，以免隱藏的問題在后期造成更大的影響。
雖然我們致力于客戶協(xié)作，但為了雙方利益和需要仍舊需要進行合同談判。
響應(yīng)變化 勝過 遵循計劃
計劃趕不上變化，敏捷項目承認開發(fā)過程中的不確定性，所以不會在開發(fā)中制定長時間的復(fù)雜計劃，它們的成功都是建立在現(xiàn)實反饋的基礎(chǔ)上的。Scrum依照一組簡單實踐及規(guī)則，實施經(jīng)驗性過程控制方法的檢查、適應(yīng)和保證可視性等步驟，處理軟件開發(fā)項目中的復(fù)雜問題。通過迭代開發(fā)，每次迭代都是基于上一迭代的完善基礎(chǔ)之上進行的，通過不斷的響應(yīng)變化來消除開發(fā)中的不確定性。
雖然我們致力于響應(yīng)變化，但并不是像上面漫畫所說的不需要計劃了,反而我們需要更多的規(guī)劃。
《Agile Estimating and Planning》（中文書名：敏捷估計與規(guī)劃）一書對如何做規(guī)劃進行詳細的講解。它認為規(guī)劃是困難的，而且作出的計劃常常會出錯，面對這樣的問題，開發(fā)小組往往會走上兩個極端：要么根本不做任何規(guī)劃，要么在計劃中投入大量的精力直到自己確信計劃是正確的。不做規(guī)劃的小組對一些最基本的問題，例如“你們什么時候能完成？”以及“我們可以在6月份安排產(chǎn)品發(fā)布嗎？”都無法回答。而做了大量計劃的小組會自欺欺人地認為某個計劃是“正確的”。他們的計劃也許更全面，但這并不一定意味著它更準(zhǔn)確或更有用。這兩種極端都是敏捷需要避免的，最開始漫畫所說的“我們實施敏捷，不再需要計劃和文檔了”的論調(diào)是及其錯誤的。
敏捷不是不需要計劃，相反它需要更多的規(guī)劃。不確定性是影響計劃正確的主要因素，對大部分不確定而言，在獲取知識、減少不確定性的唯一辦法是通過執(zhí)行－作一些事情、構(gòu)建一些東西或模擬一些東西－然后獲得反饋。許多項目管理方法是“規(guī)劃、規(guī)劃。規(guī)劃－執(zhí)行”，而敏捷開發(fā)方法是“規(guī)劃－執(zhí)行－調(diào)整”、“規(guī)劃－執(zhí)行－調(diào)整”。一個項目的不確定性越高，敏捷開發(fā)方法對取得成功就越是至關(guān)重要，不斷學(xué)習(xí)和調(diào)整是敏捷開發(fā)的核心。
個體與交互 勝過 過程與工具
方法和工具是死的，人是活的，如何沒有優(yōu)秀個人和團隊協(xié)作，再強大的方法和工具都是擺設(shè)。一個使用普通工具的優(yōu)秀人員會比使用優(yōu)秀工具的普通人員做得更好，一個具有合作精神、自組織的團隊比通過過程規(guī)范的團隊工作得更好。敏捷項目首先擁有一個小規(guī)模但擁有各種不同職能的成員，每個成員都需要定時和團隊的其他成員一起查看團隊的整體進度，計劃下一步工作，并一起探討所遭遇問題的解決方案。自組織團隊通過個人能力和協(xié)作能力，可以自發(fā)的通過各種途徑解決開發(fā)過程中遇到的問題。
雖然我們致力于個體和交互，但并不是不需要過程與工具了。Scrum、XP等方法本身也有一些方法和過程，每日構(gòu)造等敏捷實踐也需要工具的支持，需要哪些過程和工具由自組織團隊制定，而不是由領(lǐng)導(dǎo)制定。
可以工作的軟件 勝過 面面俱到的文檔
在合同中有時會看到分別在需求、設(shè)計、開發(fā)、測試階段提供什么文檔，支付多少金額等內(nèi)容，而這些文檔對用戶來說是不是真的有價值呢？面面俱到的文檔對客戶來說確并不重要，用戶需要的是一個能夠運行起來，能夠?qū)嵸|(zhì)解決工作中問題的可以工作的軟件。面面俱到的文檔對開發(fā)團隊也不重要，上百頁的報告沒有人愿意寫，更沒有人愿意去讀，對開發(fā)團隊來說最好的兩份文檔就是代碼和團隊。通過頻繁的提供可以工作的軟件，我們也可以更為頻繁的搜集對產(chǎn)品和開發(fā)過程的反饋，保證開發(fā)小組始終是在處理最具有價值的功能，而且這些功能可以滿足用戶的需要。
雖然我們致力于提供可供做的軟件，但并不是不要文檔。我們在開發(fā)過程中仍然需要進行內(nèi)部交流， 也需要和客戶交流，我們?nèi)耘f可能需要制作原型，書寫一些主要需求和算法，只要自組織團隊認為足夠就行了。
個體與交互 勝過 過程與工具
可以工作的軟件 勝過 面面俱到的文檔
客戶協(xié)作 勝過 合同談判
響應(yīng)變化 勝過 遵循計劃
這四句價值觀用語句表達就是：
自組織團隊與客戶緊密協(xié)作，通過高度迭代式、增量式的軟件開發(fā)過程響應(yīng)變化，并在每次迭代結(jié)束時交付經(jīng)過編碼與測試的有價值的軟件
勝過
與客戶確定合同后在初期制定并遵循基于活動的完整計劃，在重型過程和工具指導(dǎo)下，通過完成大量文檔進行知識傳遞，最后交付需求
