節選<敏捷軟件開發> 章

領測軟件測試網 讀了agile development一書后,感慨甚多,所以在此充水一下!!!

第Ⅰ部分 敏 捷 開 發

人與人之間的交互是復雜的，并且其效果從來都難以預期，但卻是工作中最為重要的方面。
??Tom DeMacro 和Timothy Lister
《人件》，第5頁

原則（principle）、模式（pattern）和實踐（practice）都是重要的，但是使它們發揮作用的是人。正如Alistair Cockburm 所說的①，“過程和方法對于項目的結果只有次要的影響。首要的影響是人�！比绻�把程序員團隊看做是由過程驅動的組件（component）所組成的系統，那么就無法對它們進行管理。人不是“插入即兼容的編程裝置�！雹谌绻�想要項目取得成功，就必須構建起具有合作精神的、自組織（self-organizing）的團隊。那些鼓勵構建這種團隊的公司比那些認為軟件團隊不過是由無關緊要的、雷同的一群人堆砌的公司具有大得多的競爭優勢。有凝聚力的團隊將具有最強大的軟件開發力量。

① 私人交談。
② 此語出自Kent Beck。

第1 章 敏 捷 實 踐

教堂尖頂上的風標，即使由鋼鐵制成，如果不懂得順應風勢的藝術，一樣會被暴風立即摧毀。
??海因里希?海涅（1797－1856，德國詩人）

許多人都經歷過由于沒有實踐的指導而導致的項目噩夢。缺乏有效的實踐會導致不可預測性、重復的錯誤以及努力的白白浪費。延期的進度、增加的預算和低劣的質量致使客戶對我們喪失信心。更長時間的工作卻生產出更加低劣的軟件產品，也使得開發人員感到沮喪。一旦經歷了這樣的慘敗，就會害怕重蹈覆轍。這種恐懼激發我們創建一個過程來約束我們的活
動、要求有某些人為制品（artifacts ）輸出。我們根據過去的經驗來規定這些約束和輸出，挑選那些在以前的項目中看起來好像工作得不錯的方法。我們希望這些方法這次還會有效，從而消除我們的恐懼。然而，項目并沒有簡單到使用一些約束和人為制品就能夠可靠地防止錯誤的地步。當連續地犯錯誤時，我們會對錯誤進行診斷，并在過程中增加更多的約束和人為制品來防止以后重犯這樣的錯誤。經過多次這樣的增加以后，我們就會不堪巨大、笨重的過程的重負，極大地削弱我們完成工作的能力。一個大而笨重的過程會產生它本來企圖去解決的問題。它降低了團隊的開發效率，使得進度延期，預算超支。它降低了團隊的響應能力，使得團隊經常創建錯誤的產品。遺憾的是，許多團隊認為，這種結果是因為他們沒有采用更多的過程方法引起的。因此，在這種失控的過程膨脹中，過程會變得越來越龐大。用失控的過程膨脹來描述公元2000 年前后的許多軟件公司中的情形是很合適的。雖然有許多團
隊在工作中并沒有使用過程方法，但是采用龐大、重型的過程方法的趨勢卻在快速地增長，在大公司中尤其如此（參見附錄C）。

第1章 敏 捷 實 踐 3

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）�！岸绦〉摹币馑际钦f，最多有一二十頁�！爸黝}突出的”意思是說，應該僅論述系統的高層結構和概括的設計原理。如果全部擁有的僅僅是一份簡短的系統原理和結構方面的文檔，那么如何來培訓新的團隊成員，使他們能夠從事與系統相關的工作呢？我們會非常密切地和他們在一起工作。我們緊挨著他們坐下來幫助他們，把我們的知識傳授給他們。我們通過近距離的培訓和交互使他們成為團隊的一部分。在給新的團隊成員傳授知識方面，最好的兩份文檔是代碼和團隊。代碼真實地表達了它所做的事情。雖然從代碼中提取系統的原理和結構信息可能是困難的，但是代碼是惟一沒有二義性的信息源。在團隊成員的頭腦中，保存著時常變化的系統的脈絡圖（road map）。人和人之間的交互是把這份脈絡圖傳授給他人的最快、最有效的方式。
許多團隊因為注重文檔而非軟件，導致進度拖延。這常常是一個致命的缺陷。有一個叫做“Martin文檔 定律（Martin’s first law of document）”的簡單規則可以預防該缺陷的發生：直到迫切需要并且意義重大時，才來編制文檔。

3．客戶合作勝過合同談判

不能像訂購日用品一樣來訂購軟件。你不能夠僅僅寫下一份關于你想要的軟件的描述，然后就讓人在固定的時間內以固定的價格去開發它。所有用這種方式來對待軟件項目的嘗試都以失敗而告終。有時，失敗是慘重的。告訴開發團隊想要的東西，然后期望開發團隊消失一段時間后就能夠交付一個滿足需要的系統來，這對于公司的管理者來說是具有誘惑力的。然而，這種操作模式將導致低劣的質量和失敗。成功的項目需要有序、頻繁的客戶反饋。不是依賴于合同或者關于工作的陳述，而是讓軟件的客戶和開發團隊密切地在一起工作，并盡量經常地提供反饋。一個指明了需求、進度以及項目成本的合同存在根本上的缺陷。在大多數的情況下，合同中指明的條款遠在項目完成之前就變得沒有意義。①那些為開發團隊和客戶的協同工作方式提供指導的合同才是最好的合同。我在1994 年為一個大型的、需要多年完成的、有50 萬行代碼的項目達成的合同，可以作為一個成功合同的樣例。作為開發團隊的我們，每個月的報酬相對是比較低的。大部分的報酬要在我們交付了某些大的功能塊后才支付。那些功能塊沒有在合同中詳細地指明。合同中僅僅聲稱在一個功能塊通過了客戶的驗收測試時才支付該功能塊的報酬。那些驗收測試的細節也沒有在合同中指明。在這個項目開發期間，我們和客戶緊密地在一起工作。幾乎每個周五，我們都會把軟件提交給客戶。到下一周的周一或者周二，客戶會給我們一份關于軟件的變更列表。我們會把這些變更放在一起排定優先級，然后把它們安排在隨后幾周的工作中�？蛻艉臀覀內绱司o密地在一起工作，以至
于驗收測試根本就不是問題。因為他們周復一周地觀察著每個功能塊的演進，所以他們知道何時這個功能塊能夠滿足他們的需要。這個項目的需求基本處于一個持續變化的狀態。大的變更是很平常的。在這期間，也會出現整個功能塊被減掉，而加進來另外一些功能塊。然而，合同和項目都經受住了這些變更，并獲得成功。成功的關鍵在于和客戶之間真誠的協作，并且合同指導了這種協作，而不是試圖去規定項目范圍的細節和固定成本下的進度。

4．響應變化勝過遵循計劃

響應變化的能力常常決定著一個軟件項目的成敗。當我們構建計劃時，應該確保計劃是靈活的并且易于適應商務和技術方面的變化。計劃不能考慮得過遠。首先，商務環境很可能會變化，這會引起需求的變動。其次，一旦客戶看到系統開始運作，他們很可能會改變需求。最后，即使我們熟悉需求，并且確信它們不會改變，我們仍然不能很好地估算出開發它們需要的時間。對于一個缺乏經驗的管理者來說，創建一張優美的PERT 或者Gantt 圖并把他們貼到墻上是很有誘惑力的。他們也許覺得這張圖賦予了他們控制整個項目的權力。他們能夠跟蹤單個人的任務，并在任務完成時將任務從圖上去除。他們可以對實際完成的日期和計劃完成的日期進行比較，并對出現的任何偏差做出反應。實際上發生的是這張圖的組織結構不再適用。當團隊增加了對于系統的認識，當客戶增加了對于需求的認識，圖中的某些任務會變得可有可無。另外一些任務會被發現并增加到圖中。簡而言之，計劃將會遭受形態（shape）上的改變，而不僅僅是日期上的改變。較好的做計劃的策略是：為下兩周做詳細的計劃，為下三個月做粗略的計劃，再以后就做極為粗糙的計劃。我們應該清楚地知道下兩周要完成的任務，粗略地了解一下以后三個月要實現的需求。至于系統一年后將要做什么，有一個模糊的想法就行了。計劃中這種逐漸降低的細致度，意味著我們僅僅對于迫切的任務才花費時間進行詳細的計劃。一旦制定了這個詳細的計劃，就很難進行改變，因為團隊會根據這個計劃啟動工作并有了相應的投入。然而，由于計劃僅僅支配了幾周的時間，計劃的其余部分仍然保持著靈活性。
① 有時是遠在合同簽署之前就變得沒有意義。


1.2 原 則

從上述的價值觀中引出了下面的12 條原則，它們是敏捷實踐區別于重型過程的特征所在。
1．我們最優先要做的是通過盡早的、持續的交付有價值的軟件來使客戶滿意。
MIT Sloan 管理評論雜志刊登過一篇論文，分析了對于公司構建高質量產品方面有幫助的軟件開發實踐。①該論文發現了很多對于最終系統質量有重要影響的實踐。其中一個實踐表明，盡早地交付具有部分功能的系統和系統質量之間具有很強的相關性。該論文指出，初期交付的系統中所包含的功能越少，最終交付的系統的質量就越高。該論文的另一項發現是，以逐漸增加功能的方式經常性地交付系統和最終質量之間有非常強的相關性。交付得越頻繁，最終產品的質量就越高。敏捷實踐會盡早地、經常地進行交付。我們努力在項目剛開始的幾周內就交付一個具有基本功能的系統。然后，我們努力堅持每兩周就交付一個功能漸增的系統。如果客戶認為目前的功能已經足夠了，客戶可以選擇把這些系統加入到產品中�；蛘�，他們可以簡單地選擇再檢查一遍已有的功能，并指出他們想要做的改變。
2．即使到了開發的后期，也歡迎改變需求。
敏捷過程利用變化來為客戶創造競爭優勢。這是一個關于態度的聲明。敏捷過程的參與者不懼怕變化。他們認為改變需求是好的事情，因為那些改變意味著團隊已經學到了很多如何滿足市場需要的知識。敏捷團隊會非常努力地保持軟件結構的靈活性，這樣當需求變化時，對于系統造成的影響是最小的。 在本書的后面部分，我們會學習一些面向對象設計的原則和模式，這些內容會幫助我們維持這種靈活性。
3．經常性地交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。
我們交付可以工作的軟件working software ），并且盡早地（項目剛開始很少的幾周后）、經常性地（此后每隔很少的幾周）交付它。我們不贊成交付大量的文檔或者計劃。我們認為那些不是真正要交付的東西。我們關注的目標是交付滿足客戶需要的軟件。
4．在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。
為了能夠以敏捷的方式進行項目的開發，客戶、開發人員以及涉眾之間就必須要進行有意義的、頻繁的交互。軟件項目不像發射出去就能自動導航的武器，必須要對軟件項目進行持續不斷地引導。
5．圍繞被激勵起來的個人來構建項目。
給他們提供所需要的環境和支持，并且信任他們能夠完成工作。在敏捷項目中，人被認為是項目取得成功的最重要的因素。所有其他的因素??過程、環境、管理等等??都被認為是次要的，并且當它們對于人有負面的影響時，就要對它們進行改變。例如，如果辦公環境對團隊的工作造成阻礙，就必須對辦公環境進行改變。如果某些過程步驟對團隊的工作造成阻礙，就必須對那些過程步驟進行改變。
6．在團隊內部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談。
在敏捷項目中，人們之間相互進行交談。首要的溝通方式就是交談。也許會編寫文檔，但是不會企圖在文檔中包含所有的項目信息。敏捷團隊不需要書面的規范、書面的計劃或者書面的設計。
團隊成員可以去編寫文檔，如果對于這些文檔的需求是迫切并且意義重大的，但是文檔不是默認的溝通方式。默認的溝通方式是交談。
7．工作的軟件是首要的進度度量標準。
敏捷項目通過度量當前軟件滿足客戶需求的數量來度量開發進度。它們不是根據所處的開發階段、已經編寫的文檔的多少或者已經創建的基礎結構（infrastructure）代碼的數量來度量開發進度的。只有當30%的必須功能可以工作時，才可以確定進度完成了30%。
8．敏捷過程提倡可持續的開發速度。
責任人、開發者和用戶應該能夠保持一個長期的、恒定的開發速度。敏捷項目不是50 米短跑；而是馬拉松長跑。團隊不是以全速啟動并試圖在項目開發期間維持那個速度；相反，他們以快速但是可持續的速度行進。跑得過快會導致團隊精力耗盡、出現短期行為以致于崩潰。敏捷團隊會測量他們自己的速度。他們不允許自己過于疲憊。他們不會借用明天的精力來在今天多完成一點工作。他們工作在一個可以使在整個項目開發期間保持最高質量標準的速度上。
9．不斷地關注優秀的技能和好的設計會增強敏捷能力。
高的產品質量是獲取高的開發速度的關鍵。保持軟件盡可能的簡潔、健壯是快速開發軟件的途徑。因而，所有的敏捷團隊成員都致力于只編寫他們能夠編寫的最高質量的代碼。他們不會制造混亂然后告訴自己等有更多的時間時再來清理它們。如果他們在今天制造了混亂，他們會在今天把混亂清理干凈。
10．簡單??使未完成的工作最大化的藝術??是根本的。
敏捷團隊不會試圖去構建那些華而不實的系統，他們總是更愿意采用和目標一致的最簡單的方法。他們并不看重對于明天會出現的問題的預測，也不會在今天就對那些問題進行防衛。相反，他們在今天以最高的質量完成最簡單的工作，深信如果在明天發生了問題，也會很容易進行處理。
11．最好的構架、需求和設計出自于自組織的團隊。
敏捷團隊是自組織的團隊。任務不是從外部分配給單個團隊成員，而是分配給整個團隊，然后再由團隊來確定完成任務的最好方法。敏捷團隊的成員共同來解決項目中所有方面的問題。每一個成員都具有項目中所有方面的參與權力。不存在單一的團隊成員對系統構架、需求或者測試負責的情況。整個團隊共同承擔那些責任，每一個團隊成員都能夠影響它們。

12．每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調整。
敏捷團隊會不斷地對團隊的組織方式、規則、規范、關系等進行調整。敏捷團隊知道團隊所處的環境在不斷地變化，并且知道為了保持團隊的敏捷性，就必須要隨環境一起變化。
1.3 結 論
每一位軟件開發人員、每一個開發團隊的職業目標，都是給他們的雇主和客戶交付最大可能的價值�？墒�，我們的項目以令人沮喪的速度失敗，或者未能交付任何價值。雖然在項目中采用過程方法是出于好意的，但是膨脹的過程方法對于我們的失敗至少是應該負一些責任的。敏捷軟件開發的原則和價值觀構成了一個可以幫助團隊打破過程膨脹循環的方法，這個方法關注的是可以達到團隊目標的一些簡單的技術。

在撰寫本書的時候，已經有許多的敏捷過程可供選擇。包括：SCRUM①，Crystal②，特征驅動軟
件開發（Feature Driven Development，簡稱FDD）③，自適應軟件開發（Adaptive Software Development，
簡稱ADP）④，以及最重要的極限編程（eXtreme Programming，簡稱XP）。⑤
參考文獻
1. Beck, Kent. Extreme Programming Explained: Embracing Change. 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
Systems. New York, NY: Dorset House, 2000.
① www.controlchaos.com。
② crystalmethodologies.org。
③ Java Modeling In Color With UML: Enterprise Components and Process, Peter Coad, Eric Lefebvre, and Jeff De Luca, Prentice
Hall, 1999。
④ [Highsmith2000]。
⑤ [Beck 1999], [Newkirk2001]。

延伸閱讀

文章來源于領測軟件測試網 http://www.kjueaiud.com/