主要的敏捷方法

極限程式設計（ XP ）

　　極限程式設計（ XP ）的主要目的是降低需求變化的成本。它引入一系列優秀的軟體開發方法，並將它們發揮到極致。比如，為了能及時得到使用者的反饋， XP 要求客戶代表每天都必須與開發團隊在一起。同時， XP 要求所有的程式設計都採用結對程式設計（ pair-programming ）的方式。這種方式是傳統的同行審查（ peer review ）的一種極端表現，或者可以說是它的替代方式。

過程：

XP 定義了一套簡單的開發流程，包括：編寫使用者案例，架構規範，實施規劃，迭代計劃，程式碼開發，單元測試，驗收測試等等。

思想：

　　像所有其他敏捷方法一樣， XP 預期並積極接受變化。它具有以下的價值觀或原則：

Ø 互動交流。團隊成員不是通過文件來交流，文件不是必須的。團隊成員之間通過日常溝通，簡單設計，測試，系統隱喻以及程式碼本身來溝通產品需求和系統設計。

Ø 反饋。反饋是一種資訊的交流，能使系統更加完善。反饋與交流密切相關，客戶使用或功能測試，單元測試等都能為開發團隊提供反饋資訊。同時，開發團隊也可以通過估計和設計使用者案例的方式將資訊反饋給客戶。

Ø 簡單。 XP 提倡簡單的設計，簡單的解決方案。 XP 總是從一個簡單的系統入手，並且只建立今天，而不是明天，需要的功能模組。因為它認為，建立明天需要的功能模組可能會由於需求的變化而成為浪費。

Ø 勇氣。 XP 在這一點所要達到的目的（我們認為）是鼓勵一些有較高風險的良好的做法。例如，它要求程式設計師儘可能頻繁地重構程式碼，必須刪除過時的程式碼，不解決技術難題就不罷休，等等。

Ø 團隊。 XP 提倡團隊合作，相互尊重。 XP 以建立並激勵團隊為一項重要任務。同時它把互相尊重和實際的開發習慣相結合。比如，為了尊重其他團隊成員的勞動成果，每個人不得將未通過單元測試的程式碼整合到系統中。因此，每個人的程式碼質量必須過關。

核心做法：

Ø 小規模，頻繁的版本釋出，短迭代週期。

Ø 測試驅動開發（ Test-driven development ）。

Ø

Ø 持續整合（ Continuous integration ）。

Ø 每日站立會議（ Daily stand-up meeting ）。

Ø 共同擁有程式碼 Collative code ownership.

Ø 系統隱喻（ System metaphor ）。

Scrum

Scrum 是一個敏捷開發框架，它由一個開發過程，幾種角色以及一套規範的實施方法組成。它可以被運用於軟體開發，專案維護，也可以被用來作為一種管理敏捷專案的框架。

　　在 Scrum 中，產品需求被定義為產品需求積壓（ product backlogs ）。產品需求積壓可以是使用者案例，獨立的功能描述，技術要求等。所有的產品需求積壓都是從一個簡單的想法開始，並逐步被細化，直到可以被開發。

過程：

Scrum 將開發過程分為多個 Sprint 週期， Sprint 代表一個 2-4 周的開發週期。每個 Sprint 有固定的時間長度。首先，產品需求被分成不同的產品需求積壓條目。然後，在 Sprint 計劃會議（ Sprint planning meeting ）上，最重要或者是最具價值的產品需求積壓被首先安排到下一個 Sprint 週期中。同時，在 Sprint 計劃會上，將會對所有已經分配到 Sprint 週期中的產品需求積壓進行估計，並對每個條目進行設計和任務分配。在 Sprint 週期過程中，這些計劃的產品需求積壓都會被實現並且被充分測試。每天，開發團隊都會進行一次簡短的 Scrum 會議（ Daily Scrum Meeting ）。會議上，每個團隊成員需要彙報各自的進展情況，同時提出目前遇到的各種障礙。每個 Sprint 週期結束後，都會有一個可以被使用的系統交付給客戶，同時進行 Sprint 審查會議（ Sprint review meeting ）。審查會上，開發團隊將會向客戶或終端使用者演示新的系統功能。同時，客戶會提出意見以及一些需求變化。這些可以以新的產品需求積壓的形式保留下來，並在隨後的 Sprint 週期中得以實現。 Sprint 回顧會隨後會總結上次 Sprint 週期中有哪些不足需要改進，以及有哪些值得肯定的方面。最後整個過程將從頭開始，開始一個新的 Sprint 計劃會議。

角色：

Scrum 定義了 4 種主要的角色：

Ø 產品擁有者（ Product Owner ）：該角色負責產品的遠景規劃，平衡所有利益相關者（ stakeholder ）的利益，同時確定產品需求積壓的優先順序等。它是開發團隊和客戶或終端使用者之間的聯絡點。

Ø 利益相關者（ Stakeholder ）：該角色與產品之間有直接的利益關係，通常也是由客戶或終端使用者代表組成。他們負責收集編寫產品需求，審查專案成果等。

Ø Scrum 專家（ Scrum Master ）： Scrum 專家負責指導開發團隊進行 Scrum 開發與實踐。它是開發團隊與產品擁有者之間交流的聯絡點。

Ø 團隊成員（ Team Member ）：即為專案做實際開發工作的開發人員。

Scrum 提供一個敏捷開發框架，其他許多敏捷方法都可以被整合到 Scrum 中。比如測試驅動開發（ test-driven development ）和結對程式設計（ pair programming ）等都可以被整合到 Scrum 中。

精益開發（ Lean Development ）

　　精益軟體開發模式是從豐田公司的產品系統開發方法中演化而來。它主要包括兩個部分：一部分是核心思想及原則，另外一部分由一些在相應的工具構成。

　　精益開發的核心思想是查明和消除浪費。在軟體開發過程中，錯誤（ bugs ），沒用的功能，等待以及其他任何對實現結果沒有益處的東西都是浪費。浪費及其源頭必須被分析查明，然後設法制止。精益開發的其它原則包括 :

Ø 強調學習。軟體開發過程是一個不斷學習的過程。每個團隊成員都需要從日常的失敗，互動，交流以及資訊反饋中學習，不斷改進所開發的產品和效率。

Ø 不做長久的計劃。儘量不要在可能改變的事情上做無謂的努力，這樣才能有效的避免浪費。

Ø 儘量縮短迭代週期。較短的迭代週期能夠加速產品的開發及交付，加快交流，提高生產力。

Ø 充分的自主權。激勵團隊並讓所有團隊成員自我管理始終是所有敏捷方法獲得成功的基本因素之一。

Ø 完整性。確保整個系統正常工作，同時真正滿足客戶的需求是整個團隊需要努力實現的完整性。

Ø 全域性觀。精益開發強調整體優化的系統。無論開發的組織還是被開發的產品， 從整體上考慮優化比從各個區域性去優化更高效。

　　對於上述的每個原則，都有一些相應的工具對其加以實現。這些工具包括價值流圖（ Value Stream Mapping ），基於集合的開發（ set-based development ），拉系統（ pull system ），排隊論（ queuing theory ），等等。

　　精益軟體更重要的是不斷完善開發過程的一種思維方式。因此，將精益模式與其他敏捷開發模式一起使用將會取得很好的效果。

其它敏捷方法

　　動態系統開發方法（ DSDM ）是由快速應用程式開發（ RAD ）方法演變而來的敏捷開發模式。 DSDM 在普遍的敏捷價值和原則的基礎上，定義了更加詳細的流程，以涵蓋更完整的專案生命週期。它們包括專案前期活動（ pre-project activities ），專案可行性研究，功能建模，設計和開發，實施或部署，專案後期維護（ post-project maintenance ），等等。同時，每個過程都定義了諸如如何將每個功能模型轉化為實際程式碼，如何將原型交付終端使用者使用並審查，如何處理反饋資訊等的詳細步驟。因此， DSDM 相比於其它敏捷方法在過程上顯得比較繁重。

　　特徵驅動開發（ FDD ）是另一種敏捷開發方式，它將使用者的功能需求劃分成更小的功能特徵，然後逐步地在每個迭代週期中開發實現這些產品特徵。與 DSDM 方式一樣， FDD 仍然會在專案初期對整個專案做較大的規劃和建模，以獲得對該系統的全面瞭解。但是相比較 DSDM 來說， FDD 在這些方面更簡捷。

Crystal Clear 是另一種形式的敏捷方法。 Crystal Clear 更專注於人。相比於其他的敏捷方法，它可使人獲得更大的解放。據稱這種方法更適合於較小規模的開發小組（由 2-8 個人組成）和非關鍵專案。 Crystal Clear 定義了七種屬性。前 3 個屬性 - 頻繁的交付（ frequent delivery ），滲透交流（ osmotic communication ），反思提高（ reflective improvement ） - 反映出基本的敏捷開發做法和價值，如週期較短的迭代式開發，自我管理的開發團隊和反饋帶動增量發展等等。另外的 4 個屬性分別是：個人安全（ personal safety ），集中（ focus ），容易接觸專家使用者（ easy access to expert users ）和技術環境（ technical environment ）。其中，容易接觸專家使用者實際就是敏捷方法中提到的客戶持續參與，但 Crystal Clear 對此要求較寬鬆。 Crystal Clear 也提供了一些通用的做法，比如，它提供了三種回顧分析的方法：訪談，問卷調查和工作組。 Crystal Clear 的過程也是相當簡單，其中涉及短的迭代週期，日常會議及持續整合等。

　　還有其他一些敏捷方法如敏捷統一過程（ Agile Unified process ），上下文驅動開發（ Context Driven Development ）， Getting Real 等。敏捷方法都是增量和迭代開發過程，並且強調人多過於整個過程。各種敏捷方法的區別在於它們對敏捷的不同闡釋和不同側重。理解他們可以幫助我們從多個角度理解敏捷開發，並且蒐集更多的最佳應用。

如何選擇一種敏捷方法

　　選擇一種合適的方法取決於多種因素。在做出決定之前，我們需要充分考慮以下這些方面：

Ø 方法的複雜度。確保你的團隊或組織能夠應付這種複雜度。

Ø 社群支援。流行的方法可能並不是你最理想的選擇，但流行的方法至少有較多的社群及行業支援，可以使你受益匪淺。

Ø 實用工具。選擇一種可以為你提供許多支援工具的方法。一個良好的自動化工具可以幫助團隊有效的處理日常工作，促進團隊協作，並減少管理成本。

Ø 你目前的開發方式和你目前團隊關於敏捷方法的認識程度。選擇一些與你當前開發方式比較接近的敏捷方法將有助於推動該方法的實施。

Ø 你的團隊規模。較小規模的團隊最好從簡單的方式入手。當然，這並不意味著你必須選擇那些本身就比較簡單的方法如 Crystal Clear 。你可以選擇一些相對比較全面的方法，但從簡單入手。當你的團隊規模逐漸擴大，再增加相應的細節。

Ø 你不需要只遵從一種方法。你可以為團隊選擇一個主要的方法（如 Scrum ），然後從其他方法中借鑑對你的團隊或組織有所幫助的其他方式加以整合。

敏捷總是在不斷髮展演變，因此，沒有一個人能保證目前的敏捷方法都是正確的。每個採用敏捷開發的團隊都可以通過發現並形成自己的想法和最佳實踐，對敏捷開發做出自己的貢獻。