第Ⅰ部分敏捷開發
人們之間的交互是複雜的並且從來都沒有很明確的效果，但是它們卻是工作中最爲重要的方面。
——Tom DeMacro 和Timothy Lister
《人件》，第5頁
原則（principle）、模式（pattern）和實踐（practice）都是重要的，但是使它們發揮作用的是人。
正如Alistair Cockburm 所說的①，“過程和方法對於項目的結果只有次要的影響。首要的影響是人。”
如果把程序員團隊看作是由過程驅動的組件（component）所組成的系統，那麼就無法對它們進行管理。人不是“插入即兼容的編程裝置。”②如果想要項目取得成功，就必須構建起具有合作精神的、自組織（self-organizing）的團隊。
那些鼓勵構建這種團隊的公司比那些認爲軟件團隊不過是由無關緊要的、雷同的一羣人的堆砌的公司具有大得多的競爭優勢。有凝聚力的團隊將具有最強大的軟件開發力量。
-----------------------
① 私人交談。
② 此語出自Kent Beck。
第1 章敏捷實踐
教堂尖頂上的風標，即使由鋼鐵製成，如果不懂得順應風勢的藝術，一樣會立即被暴風所摧毀。
——海因裏希Ÿ海涅（1797-1856，德國詩人）
許多人都經歷過由於沒有實踐的指導而導致的項目噩夢。缺乏有效的實踐會導致不可預測性、重複的錯誤以及努力的白白浪費。延期的進度、增長的預算和低劣的質量致使客戶對我們喪失信心。更長時間的工作卻生產出更加低劣的軟件產品，也使得開發人員感到沮喪。
一旦經歷了這樣的慘敗，就會害怕重蹈覆轍。這種恐懼激發我們創建一個過程來約束我們的活動、要求某些中間製品（artifacts ）輸出。我們根據過去的經驗來規定這些約束和輸出，挑選那些在以前的項目中看起來好像工作得不錯的方法。我們希望這些方法這次還會有效，從而消除我們的恐懼。
然而，項目並沒有簡單到使用一些約束和中間製品就能夠可靠地防止錯誤的地步。當連續地犯錯誤時，我們會對錯誤進行診斷，並在過程中增加了更多的約束和中間製品來防止以後重犯這樣的錯誤。經過多次這樣的增加以後，我們就會不堪巨大、笨重的過程的重負，極大地削弱我們完成工作的能力。
一個大而笨重的過程會產生它本來企圖去解決的問題。它降低了團隊的開發效率，使得進度延期，預算超支。它降低了團隊的響應能力，使得團隊經常創建錯誤的產品。遺憾的是，許多團隊認爲，這種結果是因爲他們沒有采用更多的過程方法引起的。因此，在這種失控的過程膨脹中，過程會變得越來越龐大。
用失控的過程膨脹來描述公元2000 年間許多軟件公司中的情形是很合適的。雖然有許多團隊在工作中並沒有使用過程方法，但是採用龐大、重型的過程方法的趨勢卻在快速地增長，在大公司中尤其如此（參見附錄C）。
1.1 敏捷聯盟
2001 年初，由於看到許多公司的軟件團隊陷入了不斷增長的過程的泥潭，一批業界專家聚集在一起概括出了一些可以讓軟件開發團隊具有快速工作、響應變化能力的價值觀（value）和原則。他們稱自己爲敏捷（Agile）聯盟①。在隨後的幾個月中，他們創建出了一份價值觀聲明。也就是敏捷聯盟宣言（The Manifesto of the Agile Alliance）。
敏捷聯盟宣言
敏捷軟件開發宣言
我們通過親身實踐以及幫助他人實踐，找到了更好的軟件開發方法。通過這項工作，我們認爲：
l 個體和交互 勝過 過程和工具
l 可以工作的軟件 勝過 面面俱到的文檔
l 客戶合作 勝過 合同談判
l 響應變化 勝過 遵循計劃
雖然右項也有價值，但是我們認爲左項具有更大的價值。
Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick
1．個體和交互勝過過程和工具
人是獲得成功的最爲重要的因素。如果團隊中沒有優秀的成員，那麼就是使用好的過程也不能從失敗中挽救項目，但是，不好的過程卻可以使最優秀的團隊成員失去效用。如果不能作爲一個團隊進行工作，那麼即使擁有一批優秀的成員也一樣會慘敗。
一個優秀的團隊成員未必就是一個一流的程序員。一個優秀的團隊成員可能是一個平均水平的程序員，但是卻能夠很好地和他人合作。合作、溝通以及交互能力要比單純的編程能力更爲重要。一個由平均水平程序員組成的團隊，如果具有良好的溝通能力，將要比那些雖然擁有一批高水平程序員，但是成員之間卻不能進行交流的團隊更有可能獲得成功。
合適的工具對於成功來說是非常重要的。像編譯器、IDE、源代碼控制系統等，對於團隊的開發者正確地完成他們的工作是至關重要的。然而，工具的作用可能會被過分地誇大。使用過多的龐大、笨重的工具就像缺少工具一樣，都是不好的。
我的建議是從使用小工具開始。嘗試一個工具，直到發現它無法適用時纔去更換它。不是急着去購買那些先進的、價格昂貴的源代碼控制系統，相反先使用一個免費的系統直到能夠證明該系統已經不再適用。在決定爲團隊購買最好的CASE 工具許可證（license）前，先使用白板和方格紙，直到有足夠的理由表明需要更多的功能。在決定使用龐大的、高性能的數據庫系統前，先使用平面文件（flat file）。不要認爲更大的、更好的工具可以自動地幫你做的更好。通常，它們造成的障礙要大於帶來的幫助。
記住，團隊的構建要比環境的構建重要的多。許多團隊和管理者就犯了先構建環境，然後期望團隊自動凝聚在一起的錯誤。相反，應該首先致力於構建團隊，然後再讓團隊基於需要來配置環境。
2．可以工作的軟件勝過面面俱到的文檔
沒有文檔的軟件是一種災難。代碼不是傳達系統原理和結構的理想媒介。團隊更需要編制易於閱讀的文檔，來對系統及其設計決策的依據進行描述。
然而，過多的文檔比過少的文檔更糟。編制衆多的文檔需要花費大量的時間，並且要使這些文檔和代碼保持同步，就要花費更多的時間。如果文檔和代碼之間失去同步，那麼文檔就會變成龐大的、複雜的謊言，會造成重大的誤導。
對於團隊來說，編寫並維護一份系統原理和結構方面的文檔將總是一個好主意，但是那份文檔應該是短小的（short）並且主題突出的（salient）。“短小的”意思是說，最多有一二十頁。“主題突出的”意思是說，應該僅論述系統的高層結構和概括的設計原理。
如果全部擁有的僅僅是一份簡短的系統原理和結構方面的文檔，那麼如何來培訓新的團隊成員，使他們能夠從事系統相關的工作呢？我們會非常密切地和他們工作在一起。我們緊挨着他們坐下來幫助他們，把我們的知識傳授給他們。我們通過近距離的培訓和交互使他們成爲團隊的一部分。
在給新的團隊成員傳授知識方面，最好的兩份文檔是代碼和團隊。代碼真實地表達了它所做的事情。雖然從代碼中提取系統的原理和結構信息可能是困難的，但是代碼是唯一沒有二義性的信息源。在團隊成員的頭腦中，保存着時常變化的系統的脈絡圖（road map）。人和人之間的交互是把這份脈絡圖傳授給他人的最快、最有效的方式。
許多團隊因爲注重文檔而非軟件，導致進度拖延。這常常是一個致命的缺陷。有一個叫做“Martin文檔第一定律（Martin’s first law of document）”的簡單規則可以預防該缺陷的發生：
直到迫切需要並且意義重大時，纔來編制文檔。
3．客戶合作勝過合同談判
不能像訂購日用品一樣來訂購軟件。你不能夠僅僅寫下一份關於你想要的軟件的描述，然後就讓人在固定的時間內以固定的價格去開發它。所有用這種方式來對待軟件項目的嘗試都以失敗而告終。有時，失敗是慘重的。
告訴開發團隊想要的東西，然後期望開發團隊消失一段時間後就能夠交付一個滿足需要的系統來，這對於公司的管理者來說是具有誘惑力的。然而，這種操作模式將導致低劣的質量和失敗。
成功的項目需要有序、頻繁的客戶反饋。不是依賴於合同或者關於工作的陳述，而是讓軟件的客戶和開發團隊密切地工作在一起，並儘量經常地提供反饋。
一個指明瞭需求、進度以及項目成本的合同存在根本上的缺陷。在大多數的情況下，合同中指明的條款遠在項目完成之前就變得沒有意義①。那些爲開發團隊和客戶的協同工作方式提供指導的合同纔是最好的合同。
我在1994 年爲一個大型的、需要多年完成的、有50 萬行代碼的項目達成的合同，可以作爲一個成功合同的樣例。作爲開發團隊的我們，每個月的報酬相對是比較低的。大部分的報酬要在我們交付了某些大的功能塊後才支付。那些功能塊沒有在合同中詳細的指明。合同中僅僅聲稱在一個功能塊通過了客戶的驗收測試時才支付該功能塊的報酬。那些驗收測試的細節也沒有在合同中指明。
在這個項目開發期間，我們和客戶緊密的工作在一起。幾乎每個週五，我們都會把軟件提交給客戶。到下一週的週一或者週二，客戶會給我們一份關於軟件的變更列表。我們會把這些變更放在一起排定優先級，然後把它們安排在隨後幾周的工作中。客戶和我們如此緊密的工作在一起，以至於驗收測試根本就不是問題。因爲他們周復一週地觀察着每個功能塊的演進，所以他們知道何時這個功能塊能夠滿足他們的需要。
這個項目的需求基本處於一個持續變化的狀態。大的變更是很平常的。在這期間，也會出現整個功能塊被去掉，而另外的功能塊被加進來的情況。然而，合同和項目都經受住了這些變更，並獲得成功。成功的關鍵在於和客戶之間認真的協作，並且合同指導了這種協作，而不是試圖去規定項目範圍的細節和固定成本下的進度。
4．響應變化勝過遵循計劃
響應變化的能力常常決定着一個軟件項目的成敗。當我們構建計劃時，應該確保計劃是靈活的並且易於適應商務和技術方面的變化。
計劃不能考慮得過遠。首先，商務環境很可能會變化，這會引起需求的變動。其次，一旦客戶看到系統開始運作，他們很可能會改變需求。最後，即使我們熟悉需求，並且確信它們不會改變，我們仍然不能很好地估算出開發它們需要的時間。
對於一個缺乏經驗的管理者來說，創建一張優美的PERT 或者Gantt 圖並把他們貼到牆上是很有誘惑力的。他們也許覺得這張圖賦予了他們控制整個項目的權力。他們能夠跟蹤單個人的任務，並在任務完成時將任務從圖上去除。他們可以對實際完成的日期和計劃完成的日期進行比較，並對出現的任何偏差做出反應。
實際上發生的是這張圖的組織結構不再適用。當團隊增加了對於系統的認識，當客戶增加了對於需求的認識，圖中的某些任務會變得沒有必要。另外一些任務會被發現並增加到圖中。簡而言之，計劃將會遭受形態（shape）上的改變，而不僅僅是日期上的改變。
較好的做計劃的策略是：爲下兩週做詳細的計劃，爲下三個月作粗略的計劃，再以後就作極爲粗糙的計劃。我們應該清楚地知道下兩週要完成的任務，粗略的瞭解一下以後三個月要實現的需求。至於系統一年後將要做什麼，有一個模糊的想法就行了。
計劃中這種逐漸降低的細緻度，意味着我們僅僅對於迫切的任務才花費時間進行詳細的計劃。一旦制定了這個詳細的計劃，就很難進行改變，因爲團隊會根據這個計劃啓動工作並有了相應的投入。然而，由於計劃僅僅支配了幾周的時間，計劃的其餘部分仍然保持着靈活性。
1.2 原則
從上述的價值觀中引出了下面的12 條原則，它們是敏捷實踐區別於重型過程的特徵所在。
1．我們最優先要做的是通過儘早的、持續的交付有價值的軟件來使客戶滿意。
MIT Sloan 管理評論雜誌刊登過一篇論文，分析了對於公司構建高質量產品方面有幫助的軟件開發實踐①。該論文發現了很多對於最終系統質量有重要影響的實踐。其中一個實踐表明，儘早地交付具有部分功能的系統和系統質量之間具有很強的相關性。該論文指出，初期交付的系統中所包含的功能越少，最終交付的系統的質量就越高。
該論文的另一項發現是，以逐漸增加功能的方式經常性地交付系統和最終質量之間有非常強的相關性。交付得越頻繁，最終產品的質量就越高。
敏捷實踐會盡早地、經常地進行交付。我們努力在項目剛開始的幾周內就交付一個具有基本功能的系統。然後，我們努力堅持每兩週就交付一個功能漸增的系統。
如果客戶認爲目前的功能已經足夠了，客戶可以選擇把這些系統加入到產品中。
或者，他們可以簡單地選擇再檢查一遍已有的功能，並指出他們想要做的改變。
2．即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來爲客戶創造競爭優勢。
這是一個關於態度的聲明。敏捷過程的參與者不懼怕變化。他們認爲改變需求是好的事情，因爲那些改變意味着團隊已經學到了很多如何滿足市場需要的知識。
敏捷團隊會非常努力地保持軟件結構的靈活性，這樣當需求變化時，對於系統造成的影響是最小的。在本書的後面部分，我們會學習一些面向對象設計的原則和模式，這些內容會幫助我們維持這種靈活性。
3．經常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
我們交付可以工作的軟件（working software ），並且儘早地（項目剛開始很少的幾周後）、經常性地（此後每隔很少的幾周）交付它。我們不贊成交付大量的文檔或者計劃。我們認爲那些不是真正要交付的東西。我們關注的目標是交付滿足客戶需要的軟件。
4．在整個項目開發期間，商務人員和開發人員必須天天都工作在一起。
爲了能夠以敏捷的方式進行項目的開發，客戶、開發人員以及涉衆之間就必須要進行有意義的、頻繁的交互。軟件項目不像發射出去就能夠自動導航的武器，必須要對軟件項目進行持續不斷地引導。
5．圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，並且信任他們能夠完成工作。
在敏捷項目中，人被認爲是項目取得成功的最重要的因素。所有其他的因素——過程、環境、管理等等——都被認爲是次要的，並且當它們對於人有負面的影響時，就要對它們進行改變。
例如，如果辦公環境對團隊的工作造成阻礙，就必須對辦公環境進行改變。如果某些過程步驟對團隊的工作造成阻礙，就必須對那些過程步驟進行改變。
6．在團隊內部，最具有效果並且富有效率的傳遞信息的方法，就是面對面的交談。
在敏捷項目中，人們之間相互進行交談。首要的溝通方式就是交談。也許會編寫文檔，但是不會企圖在文檔中包含所有的項目信息。敏捷團隊不需要書面的規範、書面的計劃或者書面的設計。團隊成員可以去編寫文檔，如果對於這些文檔的需求是迫切並且意義重大的，但是文檔不是默認的溝通方式。默認的溝通方式是交談。
7．工作的軟件是首要的進度度量標準。
敏捷項目通過度量當前軟件滿足客戶需求的數量來度量開發進度。它們不是根據所處的開發階段、已經編寫的文檔的多少或者已經創建的基礎設施（ infrastructure）代碼的數量來度量開發進度的。只有當30%的必須功能可以工作時，纔可以確定進度完成了30%。
8．敏捷過程提倡可持續的開發速度。責任人（sponsors）、開發者和用戶應該能夠保持一個長期的、恆定的開發速度。
敏捷項目不是50 米短跑；而是馬拉松長跑。團隊不是以全速啓動並試圖在項目開發期間維持那個速度；相反，他們以快速但是可持續的速度行進。
跑得過快會導致團隊精力耗盡、出現短期行爲以致崩潰。敏捷團隊會測量他們自己的速度。他們不允許自己過於疲憊。他們不會借用明天的精力來在今天多完成一點工作。他們工作在一個可以使在整個項目開發期間保持最高質量標準的速度上。
9．不斷地關注優秀的技能和好的設計會增強敏捷能力。
高的產品質量是獲取高的開發速度的關鍵。保持軟件儘可能的清潔、健壯是快速開發軟件的途徑。因而，所有的敏捷團隊成員都致力於只編寫他們能夠編寫的最高質量的代碼。他們不會製造混亂然後告訴自己等有更多的時間時再來清理它們。如果他們在今天製造了混亂，他們會在今天把混亂清理乾淨。
10．簡單——使未完成的工作最大化的藝術——是根本的。
敏捷團隊不會試圖去構建那些華而不實的系統，他們總是更願意採用和目標一致的最簡單的方法。他們並不看重對於明天會出現的問題的預測，也不會在今天就對那些問題進行防衛。相反，他們在今天以最高的質量完成最簡單的工作，深信如果在明天發生了問題，也會很容易進行處理。
11．最好的構架、需求和設計出自於自組織的團隊。
敏捷團隊是自組織的團隊。任務不是從外部分配給單個團隊成員，而是分配給整個團隊，然後再由團隊來確定完成任務的最好方法。
敏捷團隊的成員共同來解決項目中所有方面的問題。每一個成員都具有項目中所有方面的參與權力。不存在單一的團隊成員對系統構架、需求或者測試負責的情況。整個團隊共同承擔那些職責，每一個團隊成員都能夠影響它們。
12．每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行爲進行調整。
敏捷團隊會不斷地對團隊的組織方式、規則、規範、關係等進行調整。敏捷團隊知道團隊所處的環境在不斷的變化，並且知道爲了保持團隊的敏捷性，就必須要隨環境一起變化。
1.3 結論
每一個軟件開發人員、每一個開發團隊的職業目標，都是給他們的僱主和客戶交付最大可能的價值。可是，我們的項目以令人沮喪的速度失敗，或者未能交付任何價值。雖然在項目中採用過程方法是出於好意的，但是膨脹的過程方法對於我們的失敗至少是應該負一些責任的。敏捷軟件開發的原則和價值觀構成了一個可以幫助團隊打破過程膨脹循環的方法，這個方法關注的是可以達到團隊目標的一些簡單的技術。
在撰寫本書的時候，已經有許多的敏捷過程可供選擇。包括：SCRUM①，Crystal②，特性驅動軟件開發（ Feature Driven Developmen，簡稱FDD）③，自適應軟件開發（Adaptive software Development，簡稱ADP）④，以及最重要的極限編程（eXtreme Programming，簡稱XP）⑤。
參考文獻
1. Beck, Kent. Extreme Programming Explained: Embracing Changes. Reading, MA: Addison-Wesley, 1999.
2. Newkirk, James, and Robert C. Martin. Extreme Programming in Practice. Upper Saddle River, NJ: Addsion-Wesley, 2001.
3. Highsmith, James A. Adapting Software Development: A Collaborative Approach to Managing Complex System. New York, NY: Dorset House, 2000.
