敏捷開發之熱門已達到任何一個開發人員都至少聽過，并覺得敏捷方法很好，然而并不是所有的人都學習和實踐過，以致于大家談敏捷的時候其實理解的基準是不一樣的，也導致“敏捷”泛濫成災“，有些看似很敏捷的開發其實并不敏捷。

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

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

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

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

合同談判　

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

產品開發 在早期市場不成熟的時候一般為公司領導（產品經理、LPDT）驅動，后期轉變 為用戶驅動、銷售驅動、服務驅動，在矩陣式管理模式下，產品事業部和開發管理部作為兩個部門時，在做產品開發的時候就會類似在進行合同談判，從一開始就會 在兩個部門之間產生爭執而不是合作，這勢必會影響產品的開發。

遵循計劃

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

　　軟件復雜度有三個主要因素：業務、技術和人員。

　　關于業務和技術的關系我已經寫了一些博文，有興趣的可以去看看 （ 從橫向領域和縱向領域來談業務和技術的關系 ）

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

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

技術和業務最終都需要人來執行，而每個人擁有不同的技能、經驗和觀點，當這些人在一起合作時又會使得開發過程變得復雜。

這些復雜性將導致開發過程中存在很多不確定性，所以項目初期制定的計劃其實基本上不能真正的堅持下來。而當項目開發遇到困難時，項目組可能會為了表明自己做計劃的能力，或者不想經歷復雜的變更過程，而繼續努力的堅持這個已經錯誤的計劃。范圍、時間和成本，這 個金三角幾乎沒有領導不知道，而項目組為了保證”遵循計劃“，對外宣稱項目組運行狀況良好，保證當前人員在預計時間肯定能保質保量的完成開發。而代碼質量 只有開發人員知道，領導們容易忽略和難以控制這個環節，所以最后一味的遵循計劃就勢必導致提供給客戶的是一個不滿意的產品。

過程與工具

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

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

面面俱到的文檔

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

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

• Waterfall VS Agile

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

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

而 敏捷開發 是 價值驅動 ，通過 自組織團隊 在 短期迭代 過程中不斷的交付對用后有用的 功能 來進行產品開發。

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

• 個體與交互、可以工作的軟件、客戶協作、響應變化

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

　　客戶協作 勝過 合同談判

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

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

響應變化 勝過 遵循計劃

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

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

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

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

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

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

　　雖然我們致力于個體和交互，但并不是不需要過程與工具了。Scrum、XP等方法本身也有一些方法和過程，每日構造等敏捷實踐也需要工具的支持，需要哪些過程和工具由自組織團隊制定，而不是由領導制定。

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

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

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

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

　　這四句價值觀用語句表達就是：

自組織團隊與客戶緊密協作，通過高度迭代式、增量式的軟件開發過程響應變化，并在每次迭代結束時交付經過編碼與測試的有價值的軟件

　　 勝過

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

敏捷開發之 4句敏捷宣言