上篇文章中，我們探討了什么是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的確是一種非常好的敏捷開發方法論。而它具體的實施效果最終還是要看領導者以及實施者、使用者的具體實踐。

總結

以上是生活随笔為你收集整理的敏捷开发系列之旅 第三站（认识FDD特征驱动开发）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。