敏捷軟體工程是哲學理念和一系列開發指南的綜合。這種哲學理念推崇：讓客戶滿意且儘早的增量釋出；小而高度自主的專案團隊；非正式的方法；最小化軟體工程工作產品以及整體精簡開發。開發的指導方針強調超越分析和設計（儘管並不排斥這類活動）的釋出，以及開發人員和客戶之間主動和持續的溝通。
  敏捷開發可以帶來多方面的好處，但它並不適用於所有的專案、所有的產品、所有的人和所有的情況。它並不完全對立與傳統軟體工程實踐，也不能作為超越一切的哲學理念而用於所有軟體工作。

一、什麼是敏捷

  敏捷不僅僅是有效地響應變更，它還包含著對本章開頭的宣言中提及哲學觀念的信奉。它鼓勵能夠使溝通（團隊成員之間、技術和商務人員之間、軟體工程師和經理之間）更便利的團隊結構和協作態度。它強調和執行軟體的快速交付而不那麼看重中間產品；它將客戶作為開發團隊的一部分開展工作，以消除持續、普遍存在於多數軟體專案中的“區分我們和他們”的態度；它意識到在不確定的世界裡計劃是有侷限性的，專案計劃必須是可以靈活調整的。

二、敏捷及變更成本

  軟體開發的傳統方法中（有幾十年的開發經驗作支援），變更成本隨著計劃的進展成非線性增長。而敏捷的擁護者認為，一個設計良好的敏捷過程“拉平”了變更曲線，似的軟體開發團隊在沒有超常規的時間和費用影響的情況下， 在軟體專案後期能夠適應各種變更。

三、什麼是敏捷過程

  任何敏捷軟體過程的特徵都是以某種方式提出若干關鍵假設，這些假設可適用於大多數軟體專案。

1. 提前預測哪些需求是穩定的以及哪些需求會變更是非常困難的。同樣，預測專案進行中客戶優先順序的變更也很困難。
2. 對很多軟體來說，設計和構建是交錯進行的。也就是兩種活動應當順序開展以保證構建實施來驗證設計模型，而在通過構建驗證之前很難估計應該設計到什麼程度。
3. 分析、設計、構建和測試並不像我們所設想的那麼容易預測。

  這三個假設提出了一個重要的問題：如何剪力能解決不可預測性的過程？答案就在於過程的可適應性。故敏捷過程必須具有可適應性。

  應當使用增量式開發策略，必須在很短的時間間隔內教輔軟體增量（可執行原型或部分實現的可執行系統）來適應（不可預測的）變更的步伐。這種迭代方法允許客戶：週期性地評價軟體增量，向軟體專案組提出必要的反饋，影響為適應反饋而對過程進行的適應性修改。

• 敏捷原則

  敏捷聯盟定義了12條原則：

1. 我們最優先要做的是通過儘早、持續交付有價值的軟體來使客戶滿意。
2. 即使在開發的後期，也歡迎需求變更。敏捷過程利用變更為客戶創造競爭優勢。
3. 經常交付可執行的軟體，交付的間隔可以從幾個星期到幾個月， 交付的時間間隔越短越好。
4. 在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。
5. 圍繞有積極性的個人構建專案。給他們提供所需的環境和支援，並且信任他們能夠完成工作。
6. 在團隊內部，最富有效果和效率的資訊傳遞方法是面對面交談。
7. 可執行軟體是進度的首要度量標準。
8. 敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠長期保持穩定的開發速度。
9. 不斷地關注優秀的技能和好的設計會增強敏捷能力。
10. 簡單——使不必做的工作最大化的藝術——是必要的。
11. 最好的架構、需求和設計出自自組織團隊。
12. 每隔一定時間，團隊會反省如何才能更有效地工作，並相應調整自己的行為。

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

四、極限程式設計

  極限程式設計（XP）是敏捷軟體開發中使用的最廣泛的一種方法。

1.極限程式設計過程

  XP使用物件導向方法作為推薦的開發範型，它包含了策劃、設計、編碼和測試4個框架活動的規則和實踐。

  策劃。策劃活動開始與傾聽，這是一個需求收集活動，該活動要使XP團隊技術成員理解軟體的商業背景，充分感受要求的輸出和主要特性及主要功能。傾聽產生一些列“故事”（又稱為使用者故事）描述將要開發的軟體所需要的輸出、特性以及功能。每個故事由客戶書寫並置於一張索引卡上，客戶根據對應特徵或功能的綜合業務價值標明故事的權值（即優先順序）。XP團隊成員評估每一個故事，並給出以開發週數為度量單位的成本。如果某個故事的成本超過了3個開發周，則將請客戶把該故事進一步細分，重新賦予權值並計算成本。重要的是應注意到新故事可以在任何時刻書寫。
  客戶和XP團隊共同決定如何將故事分組，並置於XP團隊將要開發的下一個發行版本（軟體增量）中。一旦認可對想一個釋出版本的基本承諾（就包括的故事、 交付日期和其他專案事項），XP團隊將以下述三種方式之一對有待開發的故事進行排序：（1）所有選定故事將盡快實現；（2）具有最高價值的故事將移到專案進度表的前面並首先實現；（3）高風險故事將首先實現。
  專案速度是第一個發行版本中是i西安的客戶故事個數。專案速度將用於：（1）幫助估計後續發行版本的釋出日期和進度安排；（2）確定是否對整個開發專案中的所有故事有過分承諾。一旦發生過分承諾，則調整軟體發行版本內容或者改變最終交付日期。
  在開發過程中，客戶可以增加故事、改變故事的權值、分解或者去掉故事。接下來由XP團隊重新考慮所有剩餘的發行版本並相應修改計劃。

  設計。XP設計嚴格遵循KIS原則，即使用簡單的設計，而不是複雜的表述。設計為故事提供恰好可實現的指導，而不鼓勵額外功能性設計。
  XP鼓勵使用CRC卡作為在物件導向環境中考慮軟體的有效機制。CRC（類-職責-協作者）卡確定和組織與當前軟體增量相關的物件導向的類。CRC卡也是作為XP過程一部分的唯一設計工作產品。
  如果在某個故事設計中碰到困難，XP推薦立即建立這部分設計的可執行原型。實現並評估設計原型被稱為spike解決方案。其目的是在真正實現開始時就降低風險，對可能存在設計問題的故事確認其最初的估計。
  XP鼓勵鼓勵的重構既是構建技術又是設計技術。

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

  重構的目的是控制那些“可以根本改進設計”的小的設計變更所要進行的修改。重構所需的工作量隨著應用軟體規模的增長而急劇增長。
  XP的中心觀念是設計可以在編碼開始前後同時進行，重構意味著設計隨著系統的構建而連續進行。實際上，構建活動本身將給XP團隊提供關於如何改進設計的指導。

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

  編碼活動中的關鍵概念是結對程式設計。XP建議兩個人面對同一臺計算機共同為一個故事開發程式碼。這一方案提供了實時解決問題和實時質量保證的機制，同時也使得開發者能集中精力於手頭的問題。
  當結對的兩人完成其工作後，他們所開發程式碼將於其他人的工作整合起來。

  測試。所建立的單元測試應當使用一個自動實施的框架，這種方式支援每當程式碼修改之後即時的迴歸測試策略。
  一旦將個人的單元測試組織到一個“通用測試集”，便每天都可以進行系統的整合和單元測試。這可以為XP團隊提供連續的進展指，也可在一旦發生問題的時候及早提出預警。

  每幾個小時修改一些小問題，要比僅僅在最後截止期之前修正大問題要節省時間。 ——Wells

  XP驗收測試也稱為客戶測試，由客戶規定技術條件， 並且著眼於客戶可見的、可評審的系統級的特性和功能，驗收測試根據本次軟體釋出中所實現的該使用者故事而確定。

2.工業極限程式設計

  工業極限程式設計（IXP）：IXP是XP的一種有機進化，它由XP的最低限要求、y以客戶為中心和測試驅動精神組成。IXP與原來的XP主要差別在於其管理具有更大的包容性，它擴大了使用者角色，升級了技術實踐。

  準備評估。 IXP團隊確定該專案社群的所有成員（例如利益相關者、開發者、管理者）是否都準備就緒，是否建立了合適的環境，以及是否理解所涉及的技術水平。
  專案社群。 IXP團隊確定人員及其所具有的技能是否合適，是否針對該專案已進行了階段性培訓。該“社群”包括技術專家和其他利益相關者。
  專案特許。 IXP團隊通過對專案本身進行評估來確定對於專案的合適的商業調整是否存在，以及是否可以進一步深化組織機構的整體目標和目的。
  測試驅動管理。 IXP團隊建立一系列可測量的“目標”以評估迄今為止的進展情況，然後定義一些機制來確定是否已經實現了這些目標。
  *回顧。**IXP團隊在一個軟體增量交付之後要實施特定的技術評審。這種評審稱為回顧*，評審通過軟體增量或者全部軟體的釋出過程複查“問題、事件以及經驗教訓”。
  持續學習。鼓勵XP團隊的成員去學習新的方法和技術，從而獲得高質量的軟體產品。

五、其他敏捷過程模型

  四種常見的敏捷方法：Scrum、DSSD、敏捷建模（AM）以及敏捷統一過程（AUP）。

1.Scrum

  Scrum原則與敏捷宣言是一致的，應用Scrum原則指導過程中的開發活動，過程由“需求、分析、設計、演化和交付”等框架性活動組成。每一個框架活動中，發生於一個過程模式中的工作任務稱為一個衝刺。衝刺中進行的工作（每一個框架活動中衝刺的數目根據產品複雜度和規模大小而有所不同）適用於當前的問題，由Scrum團隊規定並常常進行實時修改。
  Scrum強調使用一組“軟體過程模式”，這些過程模式被證實在時間緊張的需求變更的業務關鍵的專案中是有效的。每一個過程模式定義一系列開發活動。

  待定項——一個能為使用者提供商業價值的專案需求或特性的優先順序列表。待定項中可以隨時加入新項。產品經理根據需要評估待定項並修改優先順序。
  衝刺——由一些工作單元組成，這些工作單元是達到待定項中定義的需求所必需的，並且必須能在預定的時間段內完成。衝刺過程中不允許有變更。因此，衝刺給開發團隊的工作提供了短期但穩定的環境。
  Scrum例會——Scrum團隊每天召開的短會，會上所有成員都要回答三個問題：

• 上次例會後做了什麼？
• 遇到了什麼困難？
• 下次例會前計劃做什麼？

  團隊領導（也稱為Scrum主持人）主持回憶並評價每個團隊成員的表現。Scrum會議幫助團隊儘早發現潛在的問題。同時，每日例會能夠促進“知識社會化交流”以及自我組織團隊的建設。
  演示——向客戶交付軟體增量，為客戶演示所實現的功能並由客戶對其進行評價。演示不需要包含計劃內的所有功能，但那是規定該時間段內的可交付功能必須完成。

2.動態系統開發方法

  動態系統開發方法（DSDM）是一種敏捷軟體開方法，該方法提供一種框架， 使其“通過在可控仙姑環境中使用增量原型開發模式以完全滿足對事件有約時的系統的構建和維護”。
  DSDM使用迭代軟體過程， 每一個迭代都遵循80%原則，即每個增量只完成能夠保證順利進入下一增量的工作，剩餘的細節則可以在知道更多業務需求或者提出並同意變更之後完成。
  DSDM定義了一下3個不同迭代週期：

  功能模型迭代——為客戶開發一系列可證明其功能的增量原型（注意：所有DSDM原型都傾向於逐漸演化為可交付的應用系統）。這一迭代週期的意圖是在使用者使用原型系統時引匯出反饋資訊以獲取補充的需求。
  設計和構建迭代——在功能模型中，重新構建原型以確保每一個原型都以工程化方式實現，並能為終端使用者提供可操作的業務價值。有些情況下， 功能模型迭代、設計和構建迭代可同步進行。
  實現——將最終軟體增量（一個可操作的原型）置於執行環境中。應當注意：（1）增量不見得100%完成；（2）增量置於執行環境以後可能需要變更。在這兩種情況，DSDM開發轉向功能模型迭代活動繼續進行。

3.敏捷建模

  AM是一種基於實踐的方法學， 用於對基於軟體的系統實施有效建模和文件編制。在軟體開發專案中，AM是可以有效並以輕量級方式用於軟體建模的標準、原則和實踐。由於敏捷模型只是大致完善，而不要求完美，因此敏捷模型比傳統的模型更有效。
  AM採納了與敏捷宣言一致的全部標準。敏捷建模的指導思想認為，敏捷團隊必須又做出決定的勇氣，哪怕這些決定可能否決的當前的設計並導致重新構建。敏捷團隊也必須保持奇拿需作風，應當意識到技術並不能解決所有問題，要虛心尊重並採納業務專家或其他利益相關者的意見。

  有目的的模型。在構建模型之前，使用AM的開發者心中應當有明確的目標（如與客戶溝通訊息，或有助於更好的理解軟體的某些方面），一旦確定模型的目標，則該用哪種型別的表達方式以及所需要的具體細節程度都是顯而易見的。
  使用多個模型。 AM建議從需要的角度看，每一種模型應當表達系統的不同側面，並且應使用能夠為預期讀者提供價值的那些模型。
  輕裝上陣。只保留那些能提供長期有價值的模型，拋棄其餘的模型。每次決定保留一個模型，你都要在以抽象方式使用資訊的便利性和敏捷性方面做權衡（即團隊內部、團隊與利益相關者增強溝通）。
  內容重於表述形式。建模應當向預期的讀者分享重要的資訊。一個有用內容很少到哪語法完美的模型不如一個帶有缺陷但能向讀者提供有用內容的模型更有價值。
  理解模型及工具。理解每一個模型及其構建工具的優缺點。
  適應本地需要。建模方法應該適應敏捷團隊的需要。

4.敏捷統一過程

  敏捷統一過程（AUP）採用了一個“在大型上連續”以及“在小型上迭代”的原理來構建基於計算機的系統。採用經典UP階段性活動——起始、細化、構建和轉換——AUP提供了一系列活動(例如軟體工程活動的一個線性序列)，能夠使團隊為軟體專案構想出一個全面的過程流。每個AUP迭代執行以下活動：

• 建模。建立對商業和問題域的UML表述。
• 實現。將模型翻譯成原始碼。
• 測試。像XP一樣，團隊設計和執行一系列的測試來發現錯誤以保證原始碼滿足需求。
• 部署。重點仍然是對軟體增量的交付以及獲取終端使用者的反饋資訊。
• 配置及專案管理。配置管理著眼於變更管理、風險管理以及對開發團隊的任意產品的控制。專案管理追蹤和空盒子開發團隊的工作進展並協調團隊活動。
• 環境管理環境管理協調過程基礎設施，包括標準、工具以及適用於開發團隊的支援技術。

5.敏捷過程工具集

  敏捷開發工具的目標是輔助敏捷開發的一個或多個方面，強調便利地快速構建可執行軟體。敏婕工具集包括專案計劃、用例和需求收集、快速設計、程式碼生成和測試的自動支援。代表性工具有OnTime、Ideogramic UML、Together Tool Set。

  自動軟體工具應當被看作是對開發團隊活動的小小的補充，而不是團隊成功的關鍵。敏捷團隊強調使用工具可以達到快速理解的目的。有些工具是社會性的，甚至開始於租賃階段。有些工具是技術性的，可以幫助使用者團隊模擬物理現狀。很多工具是物理性的，允許人們在工作場所操作這些工具。