2.10 敏捷開發

敏捷開發是一種從1990年開始逐漸引起廣泛關注的新型軟件開發方法，是一種應對快速變化的需求的一種軟件開發能力。相對于“非敏捷開發”，敏捷開發更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊，能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發中人的作用。

2001年，Kent Beck和其他16位知名軟件開發者、軟件工程專家及軟件咨詢師（稱為敏捷聯盟）共同簽署了“敏捷軟件開發宣言”。該宣言聲明：

我們正在通過親身實踐以及幫助他人實踐的方式來揭示更好的軟件開發之路，通過這項工作，我們認識到：

個人和這些個人之間的交流勝過了開發過程和工具

可運行的軟件勝過了寬泛的文檔

客戶合作勝過了合同談判

對變更的良好響應勝過了按部就班地遵循計劃

也就是說，雖然上述右邊的各項很有價值，但我們認為左邊的各項具有更大的價值。

從本質上講，敏捷方法是為了克服傳統軟件工程中認識和實踐的弱點而形成的。敏捷開發可以帶來多方面的好處，但它并不適用于所有的項目、所有的產品、所有的人和所有的情況。它也并不完全與傳統軟件工程實踐對立。

在現代經濟生活中，通常很難甚至無法預測一個基于計算機的系統（如基于網絡的應用）如何隨時間推移而演化。市場環境飛快變化，最終用戶需求不斷變更，新的競爭威脅毫無征兆地出現。在很多情況下，項目實施之前，無法充分定義需求。因此，必須足夠敏捷地去響應不斷變化、無法確定的商業環境。

不確定性意味著變更，而變更意味著付出昂貴的成本，特別是在軟件工程失去控制或疏于管理的情況下。而敏捷方法最具強制性的特點之一就是它能夠通過軟件過程來降低由變更所引起的代價，可以通過改進軟件工程本身來適應敏捷帶來的挑戰。

2.10.1 什么是敏捷

就軟件工程工作而言，敏捷已經成為當今描述現代軟件過程的時髦用詞。每個人都是敏捷的。敏捷團隊是能夠適當響應變化的靈活團隊。變化就是軟件開發本身，軟件構建有變化、團隊成員在變化、使用新技術會帶來變化，各種變化都會對開發的軟件產品及項目本身造成影響。必須接受“支持變化”的思想，它應當根植于軟件開發的每一件事中，因為它是軟件的心臟與靈魂。敏捷團隊意識到軟件是由團隊中所有人共同開發完成的，這些人的個人技能和合作能力是項目成功的關鍵所在。可見，普遍存在的變化是敏捷的基本動力，軟件工程師必須加快步伐以適應這種快速變化。

但是，敏捷不僅僅是有效地響應變化，它還鼓勵能夠使溝通（組員之間、技術和商務人員之間、軟件工程師和經理之間）更便利的團隊結構和協作態度。它強調可運行軟件的快速交付而不十分看重中間產品（這并不總是好事情）；它將客戶作為開發團隊的成員以消除一直普遍存在于多數軟件項目中的“區分你我”的態度；它意識到在不確定的世界里計劃是有局限性的，項目計劃必須是可以靈活調整的。

敏捷可以應用于任何一個軟件過程。但是，為了實現這一目標，非常重要的一點是：過程的設計應使項目團隊適應于任務，并且使任務流水線化，在了解敏捷開發方法的流動性的前提下進行計劃的制訂，并精簡軟件開發過程，強調這樣一個增量交付策略：根據具體的產品類型和運行環境，盡可能快地將切實可行的軟件交付給用戶。

2.10.2 敏捷及變更的成本費用

軟件開發的傳統方法中（有幾十年的開發經驗做支持），變化的成本費用隨著計劃的進展成非線性增長（見圖2-16，實黑曲線）。這種方法在軟件開發團隊收集需求時（在項目的早期）相對容易適應變化。應用場景需要修改，功能表應該擴充，或者書面說明書需要編輯。這項工作的費用是最小的，所需的時間不會嚴重影響項目的結果。但是，如果在經過數月的開發之后將會怎么樣？團隊在進行確認測試的過程中（也許是在項目后期的某個活動中），一個重要的干系人要求變更一個主要的功能。這一變更需要對軟件的體系結構設計進行修改，包括設計和構建3個新組件，修改另外5個組件，以及設計新的測試等。費用會迅速升級，所需的時間和費用完全是為了保證變化不會引起非預期的副作用，而這方面的開銷則是可觀的。

圖2-16 變更成本是開發時間的一個函數

敏捷的擁護者認為，一個設計良好的敏捷過程“拉平”了變更成本曲線（見圖2-16，虛線），使軟件開發團隊在沒有超常規的時間和費用影響的情況下，在軟件項目后期能夠適應各種變化。大家已經學習過，敏捷過程包括增量交付。當增量交付與其他敏捷實踐耦合時，例如連續單元測試及結對編程，引起變更的費用會衰減。雖然關于拉平曲線的程度的討論仍然在進行，但是證據表明，變更費用顯著降低。

2.10.3 什么是敏捷過程

任何一個敏捷過程都可以由所強調的3個關鍵假設來識別，這3個假設可適用于大多數軟件項目。

1）提前預測哪些需求是穩定的而哪些需求變更非常困難。同樣，預測項目進行中客戶優先級的變更也很困難。

2）對很多軟件來說，設計和構建是交錯進行的。也就是說，兩種活動應當順序開展以保證通過構建實施來驗證設計模型，而在通過構建驗證之前很難估計應該設計到什么程度。

3）從制訂計劃的角度來看，分析、設計、構建和測試并不像人們所設想的那么容易預測。

給出這3個假設，同時也就提出一個重要的問題：如何建立一種能解決不可預測性的過程？正如前文所述，答案就在于過程（對于飛快變化的項目和技術條件）的可適應性。因此，敏捷過程必須具有可適應性。

但是原地踏步式的連續適應性變化收效甚微，因而，敏捷軟件過程必須增量地適應。為了達到這一目的，敏捷團隊需要客戶的反饋（以做出正確的適應性改變），可執行原型或部分實現的可運行系統是客戶反饋的最有效媒介。因此，應當使用增量式開發策略，必須在很短的時間間隔內交付軟件增量（可執行原型或部分實現的可運行系統）來適應（不可預測的）變更的步伐。這種迭代方法使客戶能夠：周期性地評價軟件增量，向軟件項目組提出必要的反饋，影響能夠接受反饋的過程的適應性變更。

敏捷聯盟為希望達到敏捷的人們定義了12條原則。

1）最優先要做的是通過盡早、持續地交付有價值的軟件來使客戶滿意。

2）即使在開發的后期，也歡迎需求變更。敏捷過程利用變更為客戶創造競爭優勢。

3）經常交付可運行軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。

4）在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。

5）圍繞有積極性的個人構建項目。給他們提供所需的環境和支持，并且信任他們能夠完成工作。

6）在團隊內部，最富有效果和效率的信息傳遞方法是面對面交談。

7）可運行軟件是進度的首要度量標準。

8）敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠長期保持穩定的開發速度。

9）不斷地關注優秀的技能和好的設計會增強敏捷能力。

10）簡單（使不必做的工作最大化的藝術）是必要的。

11）最好的架構、需求和設計出自自組織團隊。

12）每隔一定時間，團隊會反省如何才能更有效地工作，并相應地調整自己的行為。

并不是每一個敏捷模型都同等使用這12項原則，一些模型可以選擇忽略（或至少淡化）一個或多個原則的重要性。然而，上述原則定義了一種敏捷精神，應該在每一個過程模型中都維護這種精神。

敏捷軟件開發強調“人的因素”在其中的重要性?！懊艚蓍_發關注個人的才智和技巧，根據特定人員和團隊來塑造過程。”這一描述的關鍵點在于“構造可以滿足人員及團隊需求的過程模型”，而非其他可選的過程模型。

如果敏捷開發團隊成員希望努力維護所使用的過程的特性，則該團隊成員及團隊本身必須具備以下一些特點。

1）基本能力。同在傳統軟件工程中一樣，在敏捷開發中，“能力”一詞包含了個人內在才能、特定的軟件相關技能，以及對所選過程的全局知識。關于過程的技能和知識可以而且應該教給敏捷團隊的每一位成員。

2）共同目標。雖然敏捷團隊成員能完成不同的任務，為項目提供不同的技能，但是所有人必須瞄準同一個目標，即在承諾的時間內向客戶提交可運行的軟件增量。為了實現這一目標，項目組還應當做出或大或小的連續的適應性變化，以使過程更適合于團隊的需要。

3）精誠合作。拋開過程而言，軟件工程就是在項目組溝通中評估、分析和使用信息；產生能夠幫助所有干系人了解項目組工作的信息；構建對客戶具有業務價值的軟件和相關數據庫等信息。為了實現這些任務，項目組成員之間、項目組與所有其他干系人之間必須精誠合作。

4）決策能力。包括敏捷團隊在內，任何一個好的軟件項目組必須有能夠掌握自身命運的自由。這意味著應當賦予項目組在技術和項目問題上的自主決策權。

5）模糊問題解決能力。軟件項目經理應當認識到：敏捷項目組被迫不斷面對不確定的事情，被迫不斷和變更做斗爭。有時，項目組不得不接受今天正在解決的問題明天根本不需解決這樣的現實，然而，今后的項目將會從任何解決問題的活動（包括解決錯誤問題的活動）中學習到經驗。

6）相互信任和尊重。敏捷團隊必須成為具有凝聚力的團隊，這樣的團隊展現出的相互信任和尊重使其形成“一個強有力的組織，確保整體實力大于各部分實力之和”。

7）自組織。自組織在敏捷開發中具有三重含義：①敏捷團隊組織自身以完成工作；②團隊組織最能適應當前環境的過程；③團隊組織最好的進度安排以完成軟件增量交付。自組織具有一些技術上的好處，但是更為重要的是它能促進合作，鼓舞士氣。本質上，這也就是項目組的自我管理。

2.10.4 極限編程

為了更詳盡地說明敏捷過程，下面來看看極限編程（eXtreme Programming，XP）的論述，它是敏捷軟件開發使用最廣泛的一個方法。極限編程相關的思想和方法最早出現于20世紀80年代后期，近年來，XP的變種—工業XP（IXP）被提了出來。IXP細化了XP，目標是在龐大的組織內部使用敏捷過程。

Beck為實施XP的全部工作定義了5個有重要意義的要素，即溝通、簡明、反饋、鼓勵和尊重。這5個要素中的每一個都是完成特定的XP活動、動作和任務的驅動力。

為了在軟件工程師和其他干系人之間獲得有效的溝通（例如，為軟件建立所需的特性和功能），XP強調在用戶和開發者之間進行緊密的、非正規的（口頭的）合作，建立交流重要理念的有效隱喻和連續的反饋，避免以大量的文檔作為交流媒介。

為了做到簡明，XP限制開發者只對即時需求做設計，而不考慮長遠需求。這樣做的目的是為了使代碼設計簡單化。如果設計需要改進，那么以后能夠實現重構。重構可以讓軟件工程師在不改變外部功能和行為的情況下改進設計的內部結構（或是源代碼）。實際上，重構可以用來提高設計的效能、可讀性或性能，或改進實現設計的代碼。

反饋來自以下3項：已實現的軟件本身、客戶和其他軟件團隊成員。通過設計和完成一個有效的測試策略，軟件（通過測試結果）給敏捷團隊提供反饋信息。XP使用單元測試作為主要的測試策略。每進行一級開發，開發團隊就設計一個單元測試來測試每個操作是否按照規定功能完成。當一個增量提交給客戶時，經增量完成的用戶故事或用例就作為用于驗收測試的一個基礎。軟件完成輸出、功能和用例行為的程度構成了一種反饋。最后，當新需求作為迭代計劃的一部分而提出時，團隊就把費用和進度影響的反饋信息提供給客戶。

敏捷團隊還應在團隊成員之間，在其他干系人和團隊成員之間，間接地（包括軟件本身）灌輸相互尊重的思想。當團隊成功交付了軟件增量時，他們對XP過程的尊重也會增加。

XP使用面向對象的方法作為推薦的開發范型，它包含了策劃、設計、編碼和測試4個框架活動的規則和實踐。圖2-17描述了XP過程，并指出與各框架活動相關的關鍵概念和任務。下面將概括XP關鍵的活動。

1.策劃

策劃活動（也稱為策劃比賽）開始于傾聽，這是一個需求獲取活動，該活動要使XP團隊技術成員理解軟件的商業背景，充分感受要求的輸出和主要特征及主要功能。傾聽產生一系列“故事”（也稱為“用戶故事”），描述即將建立的軟件所需要的輸出、特征及功能。每個故事（類似于用例）由客戶書寫并置于一張索引卡上，客戶根據對應特征或功能的綜合業務價值標明故事的權值（即優先級）。XP團隊成員評估每一個故事并給出以開發周數為度量單位的成本。如果某個故事的成本超過了3個開發周，則將請客戶把該故事進一步細分，重新賦予權值并計算成本。重要的是應注意到新故事可以在任何時刻書寫。

圖2-17 極限編程過程

客戶和XP團隊共同決定如何把故事分組并置于XP團隊將要開發的下一個發行版本中（下一個軟件增量）。一旦認可對下一個發布版本的基本承諾（所包括的故事、交付日期和其他項目事項），XP團隊將以下述3種方式之一對有待開發的故事進行排序：①所有選定故事將在幾周之內盡快實現；②具有最高權值的故事將移到進度表的前面并首先實現；③高風險故事將首先實現。

項目的第一個發行版本（也稱為一個軟件增量）交付之后，XP團隊計算項目的速度。簡而言之，項目速度是第一個發行版本中實現的客戶故事個數。項目速度將用于：①幫助估計后續發行版本的發布日期和進度安排；②確定是否對整個開發項目中的所有故事有過分承諾。一旦發生過分承諾，則調整軟件發行版本的內容或者改變最終交付日期。

XP并不強調設計的重要性。這一點不是所有人都會同意的。事實上，有時設計還是應該強調的。

在開發過程中，客戶可以增加故事，改變故事的權值，分解或者去掉故事。接下來由XP團隊重新考慮所有剩余的發行版本并相應地修改計劃。

2.設計

XP設計嚴格遵循簡潔原則，即使用簡單而不是復雜的表述。另外，設計為故事提供不多也不少的實現原則，不鼓勵額外功能性（因開發者假定以后會用到）設計。

XP鼓勵使用CRC（類—責任—協作者）卡作為在面向對象環境中考慮軟件的有效機制。CRC卡確定和組織與當前軟件增量相關的面向對象的類。XP團隊使用過程來管理設計工作。CRC卡也是作為XP過程一部分的唯一的設計工作產品。

如果在某個故事設計中遇到困難，XP推薦立即建立這部分設計的可執行原型，實現并評估設計原型，在真正地實現開始時降低風險，對可能存在設計問題的故事確認其最初的估計。XP鼓勵既是構建技術又是設計優化方法的“重構”。

重構是以不改變代碼外部行為而改進其內部結構的方式來修改軟件系統的過程。這是一種凈化代碼（并修改或簡化內部設計）以盡可能減少引入錯誤的嚴格方法。實質上，重構就是在編碼完成之后改進代碼設計。

因為XP設計實際上不使用符號并且幾乎不產生工作產品，所以設計會被當做可以并且應當在構建過程中連續修改的臨時的人工產品。重構的目的是控制那些由于提出“可以根本改進設計”的小設計修改而造成的（代碼）改動。然而應當注意的是，重構所需的工作量隨著應用軟件規模的增長而急劇增長。

XP的中心觀念是設計可以在編碼開始前后同時進行，重構意味著設計隨著系統的構建而連續進行。實際上，構建活動本身將給XP團隊提供關于如何改進設計的指導。

3.編碼

XP推薦在故事開發和初步設計完成之后，團隊不是直接開始編碼，而是開發一系列用于檢測本次（軟件增量）發布的包括所有故事的單元測試，一旦建立了單元測試，開發者就更能夠集中精力于必須實現的內容以通過單元測試。不需要加任何額外的東西（保持簡潔）。一旦編碼完成，就可以立即完成單元測試，從而向開發者提供即時反饋。

XP編碼活動中的關鍵概念（也是討論最多的方面）之一是結對編程。XP建議兩個人面對同一臺計算機共同為一個故事開發代碼。這一方案提供了實時解決問題（兩個人總比一個人強）和實時質量保證的機制（在代碼寫出后及時得到復審），同時也使得開發者能集中精力于手頭的問題。實施中不同成員擔任的角色略有不同，例如，一名成員考慮設計特定部分的編碼細節，而另一名成員確保編碼遵循特定的標準（XP所要求的那些）或者確保故事相關的代碼能夠通過相對于故事而開發的單元測試。

當結對的兩人完成其工作后，他們所開發的代碼將與其他人的工作集成起來。有些情況下，這種集成作為集成團隊的日常工作實施。還有一些情況下，結對者自己負責集成，這種“連續集成”策略有助于避免兼容性和接口問題，建立能及早發現錯誤的“冒煙測試”環境。

4.測試

正如已經指出的，在編碼開始之前建立單元測試是XP方法的關鍵因素。所建立的單元測試應當使用一個可以自動實施的框架（因此易于執行并可重復），這種方式支持代碼修改之后即時的回歸測試策略。

一旦將個人的單元測試組織到一個“通用測試集”，每天都可以進行系統的集成和確認測試。這可以為XP團隊提供連續的進展指示，也可在一旦發生問題的時候及早提出預警。

XP驗收測試，也稱為客戶測試，由客戶規定技術條件，并且著眼于客戶可見的、可評審的、系統級的特征和功能。驗收測試根據本次軟件發布中所實現的用戶故事而確定。

2.10.5 工業極限編程

工業極限編程（IXP）是XP的一種有機進化，它由XP的最低限要求、以客戶為中心和測試驅動精神組成。IXP與原來的XP的主要差別在于其具有更大的包容性，它擴大了用戶角色，升級了技術實踐。IXP合并了6個新實踐，這些新實踐的設計是為了有助于確保在一個龐大的組織內一些重要項目中XP工作能成功地實施。

1）準備評估。在IXP項目開始執行前，組織機構應進行準備評估。評估應確定是否：①存在支持IXP的適合的開發環境；②開發團隊由合適的干系人組成；③組織機構具有清晰的質量大綱并且支持連續的改進；④組織文化會支持一個敏捷團隊的新的權值；⑤組成較為廣泛的項目社區。

2）項目社區。經典XP建議選擇適合的人員組成敏捷團隊可以確保成功。也就是說，團隊成員必須經過良好的訓練，具有良好的適應性和技能，以及適宜的性格為自組織團隊做出貢獻。當在一個大型組織內將XP應用于重要的項目，團隊的概念就變成社區。一個社區可能擁有一個技術專家和處于項目成功核心地位的客戶們，以及其他干系人（如法律人員、質量檢驗員、生產或銷售人員），“他們通常位于IXP計劃的周邊，但在項目中他們扮演著重要的角色”。在IXP內，應明確定義社區成員和他們的角色，應建立社區成員之間的交流和合作機制。

3）項目承租。IXP團隊通過對項目本身進行評估來確定對于項目的合適的商業調整是否存在，以及是否可以進一步深化組織機構的全部目標和目的。承租也要檢查項目環境來決定項目如何完成，如何擴展，或者如何替代現在的系統或過程。

4）測試驅動管理。一個IXP項目需要可測量的標準來評估項目的狀態和迄今為止的進展情況。測試驅動管理建立一系列可測量的“目標”，然后定義一些機制來確定目標是否可以實現。

5）回顧。IXP團隊在一個軟件增量交付之后要實施特定的技術評審。這種評審稱為回顧，它在軟件增量過程中，以及/或者全部軟件的發布過程中復查“問題、事件及教訓”。這樣做的目的是為了改善IXP過程。

6）持續學習。由于學習是持續過程改進中至關重要的組成部分，因此，應鼓勵（或激勵）XP團隊的成員學習新的方法和技術來提高軟件產品質量。

除了以上討論的6個新實踐，IXP還修改了大量已有的XP實踐。故事驅動開發（SDD）主張驗收測試的故事寫在所有代碼生成之前。領域驅動設計（DDD）是XP中“系統隱喻”概念的改進。DDD建議漸進建立域模型，“域模型可以精確表示領域專家如何考慮課題”。結對擴展了XP結對編程的概念，包括管理者和其他干系人，目的是提高那些可能不直接參與技術開發的XP團隊成員間的知識共享程度。迭代可用性并不鼓勵前載接口部件設計，其用意在于支持可用性設計，從而有利于軟件增量交付，以及用戶與在研軟件的交互。

IXP對其他XP實踐進行了少量的修改，并重新確定某些角色和責任，使他們擔負起大型組織重要項目的責任。