面對需求相對復雜以及合作方眾多的情況下，產品經理該如何處理這些需求？作者結合行業資料及其自身經驗，與大家探討如何利用FDD框架，管理我們的需求管理和研發構建的流程。

2022年，我司承接了兩個車廠的軟件項目，中國與歐洲團隊深度合作，旨在做好項目交付的同時，打造公司級的產品平臺。

針對這樣需求相對復雜（兩個項目需求、一個產品平臺化需求）、合作方眾多（多國多地、以及多個供應商）的情況，歐洲團隊提出了用FDD（Feature Driven Development，特性驅動開發）的框架，管理我們的需求管理和研發構建的流程。

什么是FDD、為什么用FDD，本文將結合行業資料和實際操作，加以闡述。

一、敏捷和精益的管理框架

近些年，敏捷和精益已經越來越深入人心，FDD是其核心方法之一。

敏捷精益核心方法：

• Scrum：單一團隊的管理實踐
• 看板：豐田生產系統的“招牌”
• XP：極限編程，輕量級、迭代的軟件開發過程，強調人與人的合作
• FDD：特性驅動開發，著重迭代和增量

敏捷精益輔助方法：

• Scrum Of Scrum
• Scaled Agile Framework
• Crystal
• Behaviour Driven Development
• Disciplined Agile
• Agile Unified Process
• Large Scale Scrum
• Dynamic Systems Delivery Method

二、什么是FDD

針對中小型軟件開發項目的開發模式，強調簡化、易用、易于被開發團隊接受，適用于需求經常變化的項目。FDD 是一個以架構（Architecture）為中心，采用短迭代期，特性（Feature）驅動的開發過程。

FDD在實踐上，分以下五個步驟：

1. 開發一個全局的模型：在有經驗的組件/對象建模專家（首席架構師）的指導下，業務領域需求人員與開發人員一起協調工作。業務領域需求人員提供一個初始的、具有一定高度的、可以覆蓋整個系統和業務場景的介紹。業務人員和開發人員依此產生初始的模型，然后組成單獨小組，進入詳細討論階段。將模型描繪出來，最后豐富之前產生的初始模型。
2. 建立特性列表：將這些特性進行分類、合并和整理。如功能需求中有用戶注冊、用戶修改注冊資料和用戶用于登錄功能，難么輸入特性列表中之后就可能是圍繞對象模型用戶（User）的新增、修改、刪除及查詢等功能。
3. 依據特性制定計劃：將這些特性排序和計劃，然后分配相應的程序員組。
4. 依據特性進行設計：程序員組針對自己的特性列表按迭代進行設計。
5. 依據特性進行構建：程序員依據特性進行構建。

圖片來源：https://www.geeksforgeeks.org/fdd-full-form/

三、FDD的歷史

Jeff De Luca 是全球信息技術戰略家和軟件開發方法論領域的作者。他被認為是功能驅動開發 (FDD) 的主要架構師。 Jeff 于 1993 年從 IBM 辭職，擔任高級系統戰略師。在 IBM 之后，Jeff 成立了自己的咨詢公司 Nebulon Pty Ltd，總部位于澳大利亞墨爾本，并使用 Java、UML 對象建模和 FDD 開發了廣泛、復雜的軟件系統。

1997年，FDD 是Jeff De Luca 為滿足新加坡一家大型銀行為期 15 個月、50 人的軟件開發項目的特定需求而設計的。這個項目里誕生出FDD的5個流程——overall model，feature listing，plan by feature， design by feature，build by feature。

第二次使用是在一個250人、為期18個月的項目上。此后，FDD在多個項目上得以實施。 1999 年，Peter Coad、Eric Lefebvre 和 Jeff De Luca 在 Java modeling in Color with UML一書的第 6 章首次向世界介紹了 FDD 的描述。后來，在 Stephen Palmer 和 Mac Felsing 的書 A Practical Guide to Feature-Driven Development[2]（2002 年出版），對 FDD 進行了更一般的描述，與 Java 建模分離。

四、FDD的最佳實踐

FDD建立在一組核心的軟件工程最佳實踐之上，旨在從客戶價值的feature角度出發。

1. 領域對象建模（Domain Object modelling）。 領域對象建模包括探索和解釋要解決的問題的領域。 生成的域對象模型提供了一個用于添加功能的總體框架。

2. 按功能開發（Developing by Feature）。 任何過于復雜而無法在兩周內實現的功能將進一步分解為更小的功能，直到每個子問題都小到足以稱為一個功能。 這使得交付正確的功能以及擴展或修改系統變得更加容易。

3. 單一類別（代碼）所有權（Individual Class (Code) Ownership）。 單人類所有權意味著將不同的代碼片段或代碼組分配給單個所有者。 所有者負責類的一致性、性能和概念完整性。

4. 特色團隊（Feature Teams）。 功能團隊是一個小型的、動態組建的團隊，負責開發小型活動。 每個設計決策始終采用多種思想，并且在選擇一個之前會評估多個設計選項。

5. 檢查（Inspections）。 執行檢查主要是通過檢測缺陷來確保良好的設計和代碼質量。

6. 配置管理（Configuration Management）。 配置管理有助于識別迄今為止已完成的所有功能的源代碼，并在功能團隊增強類時維護類更改的歷史記錄。

7. 定期構建（Regular Builds）。 定期構建確保始終有一個可以向客戶演示的最新系統，并有助于及早突出顯示功能源代碼的集成錯誤。

8. 進展和結果的可見性（Visibility of progress and results）。 管理人員根據已完成的工作，使用來自項目內外各個級別的頻繁、適當和準確的進度報告來指導項目。

五、FDD與Scrum對比

六、FDD的優劣勢

優勢：

FDD適合復雜、中長期項目。它的五步相對簡單的流程，可以指導團隊，將復雜問題拆解為更小的問題，用預定義的開發標準，實現快速融入項目、快速開發交付。 FDD為團隊成員提供了更有效的溝通機會，另一方面鼓勵團隊創造和創新。它使得團隊可以定期更新他們的項目，觀察任何錯誤，并隨時為用戶/客戶提供有價值的信息。

劣勢：

FDD對于較小的項目效率不高，也不適用于開發人員較少的團隊。它高度依賴于首席開發人員或程序員，它他需要充當新團隊成員的協調員、領導、設計師和導師。 它可能不適用于遺留系統維護，因為已經有一個系統并且沒有定義它的整體模型。因此，它需要一個團隊重新開始并從頭開始工作。

總結

FDD是行業里成熟的、有成功案例的管理理論。它適合中大型復雜項目，化繁為簡，從而實現迭代、增量交付，減少團隊的混亂和返工。

縱觀我司歐洲團隊的FDD，與行業里FDD的概念與實踐也有較高的匹配度：比如領域對象建模（Domain Object Modelling），歐洲團隊有架構圖來解構產品全局，運用“Thin Slice” Customer Function，切分功能，形成Feature list， 然后強調Feature team的Leadership和Ownership，實現Plan by feature、Design by feature和Build by feature。同時利用Jira的Structure插件也是項目進度可視化的較好方案。

FDD成立之初，在領域建模部分，是與Java建模耦合的，設想這其中不乏豐富的工程實踐值得探究。在2002年，FDD與Java建模分離，成為更普適、更容易接近業務的管理框架。關于領域對象建模（Domain Object modelling），業界里另一個被討論得比較熱烈并被一些大公司采用的是DDD（Domain Driven Design領域驅動設計）。

FDD和DDD珠聯璧合，或許是解決復雜項目的一把利刃。

更多閱讀材料

1. 敏捷開發的常見框架
2. Feature Driven Development Explained with Examples
3. Jeff DeLuca on FDD and Transforming Large Organisations to Product Thinking
4. Feature-Driven Development: Best Practices
5. Archive of previous discussion about Feature Driven Development