上篇文章中，我們探討了什麼是XP極限程式設計，以及極限程式設計的管理思想、核心價值觀等等。在敏捷開發之旅的第三站，我想要和大家一起分享FDD特徵驅動開發方法。 特徵驅動開發——Feature Driven Development 還是老規矩，討論之前，我們先了解一下什麼是Feature？什麼是FDD？

Feature

在FDD中，Feature（特徵）是一個基本的開發單位，是（FDD）專案中的一個增量，是指使用者眼中最小的有用的功能，可以在很短時間內實現（一般在兩週之內）。

• 特徵是小的

特徵之所以是小的，是因為他可以在兩週之內實現，任何一個過於複雜而無法在兩週之內完成的功能，可進一步唄分解小到足以被稱為一個特徵。使特徵小一些也意味著客戶能經常看到可測量的進度。

• 特徵是具有客戶價值的

在業務系統中，一個特徵對映到業務過程中某些活動的一個步驟。在其他系統中，特徵等同於由使用者完成的一項任務中的一個步驟。

FDD

特徵驅動開發（FDD），是敏捷開發方法中的一種，他來源與新加坡的一個大型軟體開發專案，由著名軟體專家Jeff de Luca 、Eric Lefebvre、Peter Coad共同提出的。它強調特徵驅動，快速迭代，即能保證快速開發，又能保證適當文件和質量。 他提出的每個功能開發時間不超過兩週，為每個用例user case限定了粒度，具有良好可執行性，也可以對專案的開發程序進行精確及時地監控。他抓住了軟體開發的核心問題領域，即正確和及時地構造軟體。 FDD還打破了傳統的將領域和業務專家/分析師與設計者和實現者隔離開來的壁壘。分析師被從抽象的工作中解脫出來，直接參與到開發人員和使用者所從事的系統構造工作中。

開發過程

FDD方法包括5個過程，其中的按照功能設計和構建是反覆的迭代過程。

• 開發整體模型

這是FDD開始一個專案的初始工作，在主設計師的指導下，帶領領域專家和開發小組成員一起工作。主要是收集系統的功能需求，然後使用四色原型進行域建模。我個人認為，在此階段中，能夠得出系統的架構設計圖。

• 構建功能列表

這個過程確定所有用於支援需求的功能。由領域專家和開發小組進行功能分解。根據領域專家對領域的劃分，將整個領域分成一定數量的區域（主要功能集），每個區域再細化為一定數量的活動。活動中的每一步被劃分稱為一個功能。形成了具有層次結構的分類功能列表。個人認為，在此階段中，能夠形成系統的概要設計。

• 計劃功能開發

專案經理、開發經理和開發小組根據功能的依賴性、開發小組的工作負荷以及要實現的功能的複雜性，計劃實現功能的順序，完成一個功能開發計劃。它提供了對專案的高層檢視，讓業務代表瞭解功能開發、測試和釋出日期，以便業務代表和部署小組能夠計劃交付哪些功能的日期。本階段的主要成果是，能夠形成專案開發計劃。

• 按照功能設計

專案經理和上一階段指定的各個功能集的主要程式設計師一起對功能進行詳細設計。同時在域模型的基礎上進行分析、設計，得出分析模型、設計模型。由於一次設計並不全面，因此也可以直接進入設計模型。根據設計的結果制定出專案的里程碑。這裡會有一個設計評審的環節。本階段的成果應該包括了：詳細設計、專案里程碑計劃等。

• 按照功能構建

按照設計進行編碼實現，由程式設計師實現各自負責的類。在程式碼完成後有必要的組織程式碼複查、評審。在測試和檢查通過後檢入到配置管理庫中進行構建。第5和第4 階段是一個迭代的過程，迭代週期一般為2個星期。這樣經過不斷的迭代，不斷的實現功能集中的功能。每一個里程碑的時候進行評估、回顧。並考慮下一個里程碑 的繼續，直到最後專案的完成。

最佳實踐

• 領域物件建模

是物件分解的一種形式，主要包括構造類圖，用於描述問題領域中重要物件的型別及其相互關係，為系統設計提供了一種整體框架，使得系統可以按照特徵迭代增量地進行開發。

• 按照特徵開發

按照一組小功能、對客戶有價值的功能列表進行開發並跟蹤過程。FDD將需求問題分解成可以解決的小問題，對每個問題分解為分層列表的功能需求，即特徵。然後，開始設計並實現每一個特徵。一旦系統的功能特徵被標識以後，它們通常在FDD方法中用於驅動和跟蹤開發過程。

• 類（程式碼）擁有權

FDD規定每一個類都有一個指定的人/角色負責類程式碼的一致性、效能和概念的完整性。FDD方法採用的開發技術是面向物件，類定義一個單一的概念和實體，最合適作為最小的程式碼分配要素，程式碼的所有權即為類的所有權。

• 特徵小組

FDD把類即特徵分配給一個確定的開發者。由於一個特徵的實現會涉及到多個類及其所有者，因此，特徵的所有者（特徵組長）需要協調多個開發人員的工作。特徵小組與開發小組類似。但有一個重要的區別：特徵小組的組長更像是教練而不是超級程式設計師。

• 審查

指的是檢查軟體錯誤的複審方法，這是FDD確保軟體設計和程式碼質量的一個關鍵技術。審查將開發小組和FDD以主程式元為主的結構完美地結合起來，這種混合是一種新型的開發方式。

• 定期構建

定期地取出已完成功能的全部原始碼和它所依賴的庫、元件，組成完整的可以執行的系統。構建增加功能的基線，確保總是有一個可以執行、向客戶演示的軟體系統，可以使客戶觀察到系統開發的進度和實現的功能是否是需要的。

• 配置管理

一個FDD專案只需要保證對完成的程式碼檔案最新版本的確認和歷史追蹤。根據開發軟體的複雜性，分析製品、設計製品以及測試用例、測試指令碼等也應該受控於版本控制。

• 可視性進度報告

專案成員應該根據完成的工作向各級管理報告工作進度，FDD提供了一個簡單、低開銷地收集準確和可靠專案資訊的方法，提供了大量直觀、直接的報告樣式，向專案所有相關人員報告專案進度。

與XP的比較

• 隱寓和模型

XP過程以在卡片上記錄故事開始業務分析。每個故事就是系統要做的事情。整個專案在“每個人——客戶、程式設計師和經歷——能夠講出系統如何工作的整體故事”隱寓的指導下進行的。 FDD使用特徵，執行領域走查，同時要建立一個全面的領域物件模型，以便特徵小組對每一組特徵產生更好的設計。

• 開發團隊

在開發隊伍規模上，XP通常不超過10人；FDD的理想團隊成員數在16~20人，也有更大團隊的實際經驗。

• 程式碼擁有權

XP鼓勵集體擁有程式碼，任何人都可以在需要時新增或修改程式碼。與之相反，在FDD中，整個開發團隊擁有程式碼的集體所有權。當需要集體驗證譬如說軟體架構的設計或使用者介面構造的時候，FDD就將類所有者與特徵小組和審查結合起來滿足需要。

• 測試

XP利用雙人結對程式設計來不斷地在設計和程式碼層執行走查和非形式化審查。FDD則提倡採用結構化的形式化審查技術。 XP中的正確性是由執行單元和功能測試來定義的。在FDD中，單元測試是“按照功能構建”過程的一個部分。FDD沒有定義參與測試的形式化等級，由主程式設計師決定做什麼更適合。

• 專案追蹤

XP讓專案經理決定專案追蹤方法，鼓勵減少資料蒐集的工作量，鼓勵使用大型圖表。在FDD中的按特徵追蹤專案的方法，描述了工作量小、準確度量專案進度的手段，提供了用資料構造多種使用的進度圖表。

結束語

作為敏捷開發的方法之一，特徵驅動開發很好的實現了敏捷的思想，它強調的是整體模型，是從全域性觀的角度考慮問題的。同時，我們也要認識到一點，特徵驅動開發相對於其他的方法，還是比較複雜的。其方法的精緻和結構的規整，很容易讓使用者在本身固有的重型思維方式的引導下，走入於agile背道而馳的泥坑。這本身也是其複雜性的一個表現。 因此，要想使用FDD並不容易，但不可否認的一點，FDD的確是一種非常好的敏捷開發方法論。而它具體的實施效果最終還是要看領導者以及實施者、使用者的具體實踐。