面對(duì)需求相對(duì)復(fù)雜以及合作方眾多的情況下，產(chǎn)品經(jīng)理該如何處理這些需求？作者結(jié)合行業(yè)資料及其自身經(jīng)驗(yàn)，與大家探討如何利用FDD框架，管理我們的需求管理和研發(fā)構(gòu)建的流程。

2022年，我司承接了兩個(gè)車廠的軟件項(xiàng)目，中國(guó)與歐洲團(tuán)隊(duì)深度合作，旨在做好項(xiàng)目交付的同時(shí)，打造公司級(jí)的產(chǎn)品平臺(tái)。

針對(duì)這樣需求相對(duì)復(fù)雜（兩個(gè)項(xiàng)目需求、一個(gè)產(chǎn)品平臺(tái)化需求）、合作方眾多（多國(guó)多地、以及多個(gè)供應(yīng)商）的情況，歐洲團(tuán)隊(duì)提出了用FDD（Feature Driven Development，特性驅(qū)動(dòng)開(kāi)發(fā)）的框架，管理我們的需求管理和研發(fā)構(gòu)建的流程。

什么是FDD、為什么用FDD，本文將結(jié)合行業(yè)資料和實(shí)際操作，加以闡述。

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

近些年，敏捷和精益已經(jīng)越來(lái)越深入人心，F(xiàn)DD是其核心方法之一。

敏捷精益核心方法：

• Scrum：?jiǎn)我粓F(tuán)隊(duì)的管理實(shí)踐
• 看板：豐田生產(chǎn)系統(tǒng)的“招牌”
• XP：極限編程，輕量級(jí)、迭代的軟件開(kāi)發(fā)過(guò)程，強(qiáng)調(diào)人與人的合作
• FDD：特性驅(qū)動(dòng)開(kāi)發(fā)，著重迭代和增量

敏捷精益輔助方法：

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

二、什么是FDD

針對(duì)中小型軟件開(kāi)發(fā)項(xiàng)目的開(kāi)發(fā)模式，強(qiáng)調(diào)簡(jiǎn)化、易用、易于被開(kāi)發(fā)團(tuán)隊(duì)接受，適用于需求經(jīng)常變化的項(xiàng)目。FDD 是一個(gè)以架構(gòu)（Architecture）為中心，采用短迭代期，特性（Feature）驅(qū)動(dòng)的開(kāi)發(fā)過(guò)程。

FDD在實(shí)踐上，分以下五個(gè)步驟：

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

圖片來(lái)源：https://www.geeksforgeeks.org/fdd-full-form/

三、FDD的歷史

Jeff De Luca 是全球信息技術(shù)戰(zhàn)略家和軟件開(kāi)發(fā)方法論領(lǐng)域的作者。他被認(rèn)為是功能驅(qū)動(dòng)開(kāi)發(fā) (FDD) 的主要架構(gòu)師。 Jeff 于 1993 年從 IBM 辭職，擔(dān)任高級(jí)系統(tǒng)戰(zhàn)略師。在 IBM 之后，Jeff 成立了自己的咨詢公司 Nebulon Pty Ltd，總部位于澳大利亞墨爾本，并使用 Java、UML 對(duì)象建模和 FDD 開(kāi)發(fā)了廣泛、復(fù)雜的軟件系統(tǒng)。

1997年，F(xiàn)DD 是Jeff De Luca 為滿足新加坡一家大型銀行為期 15 個(gè)月、50 人的軟件開(kāi)發(fā)項(xiàng)目的特定需求而設(shè)計(jì)的。這個(gè)項(xiàng)目里誕生出FDD的5個(gè)流程——overall model，feature listing，plan by feature， design by feature，build by feature。

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

四、FDD的最佳實(shí)踐

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

1. 領(lǐng)域?qū)ο蠼＃―omain Object modelling）。 領(lǐng)域?qū)ο蠼０ㄌ剿骱徒忉屢鉀Q的問(wèn)題的領(lǐng)域。 生成的域?qū)ο竽Ｐ吞峁┝艘粋€(gè)用于添加功能的總體框架。

2. 按功能開(kāi)發(fā)（Developing by Feature）。 任何過(guò)于復(fù)雜而無(wú)法在兩周內(nèi)實(shí)現(xiàn)的功能將進(jìn)一步分解為更小的功能，直到每個(gè)子問(wèn)題都小到足以稱為一個(gè)功能。 這使得交付正確的功能以及擴(kuò)展或修改系統(tǒng)變得更加容易。

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

4. 特色團(tuán)隊(duì)（Feature Teams）。 功能團(tuán)隊(duì)是一個(gè)小型的、動(dòng)態(tài)組建的團(tuán)隊(duì)，負(fù)責(zé)開(kāi)發(fā)小型活動(dòng)。 每個(gè)設(shè)計(jì)決策始終采用多種思想，并且在選擇一個(gè)之前會(huì)評(píng)估多個(gè)設(shè)計(jì)選項(xiàng)。

5. 檢查（Inspections）。 執(zhí)行檢查主要是通過(guò)檢測(cè)缺陷來(lái)確保良好的設(shè)計(jì)和代碼質(zhì)量。

6. 配置管理（Configuration Management）。 配置管理有助于識(shí)別迄今為止已完成的所有功能的源代碼，并在功能團(tuán)隊(duì)增強(qiáng)類時(shí)維護(hù)類更改的歷史記錄。

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

8. 進(jìn)展和結(jié)果的可見(jiàn)性（Visibility of progress and results）。 管理人員根據(jù)已完成的工作，使用來(lái)自項(xiàng)目?jī)?nèi)外各個(gè)級(jí)別的頻繁、適當(dāng)和準(zhǔn)確的進(jìn)度報(bào)告來(lái)指導(dǎo)項(xiàng)目。

五、FDD與Scrum對(duì)比

六、FDD的優(yōu)劣勢(shì)

優(yōu)勢(shì)：

FDD適合復(fù)雜、中長(zhǎng)期項(xiàng)目。它的五步相對(duì)簡(jiǎn)單的流程，可以指導(dǎo)團(tuán)隊(duì)，將復(fù)雜問(wèn)題拆解為更小的問(wèn)題，用預(yù)定義的開(kāi)發(fā)標(biāo)準(zhǔn)，實(shí)現(xiàn)快速融入項(xiàng)目、快速開(kāi)發(fā)交付。 FDD為團(tuán)隊(duì)成員提供了更有效的溝通機(jī)會(huì)，另一方面鼓勵(lì)團(tuán)隊(duì)創(chuàng)造和創(chuàng)新。它使得團(tuán)隊(duì)可以定期更新他們的項(xiàng)目，觀察任何錯(cuò)誤，并隨時(shí)為用戶/客戶提供有價(jià)值的信息。

劣勢(shì)：

FDD對(duì)于較小的項(xiàng)目效率不高，也不適用于開(kāi)發(fā)人員較少的團(tuán)隊(duì)。它高度依賴于首席開(kāi)發(fā)人員或程序員，它他需要充當(dāng)新團(tuán)隊(duì)成員的協(xié)調(diào)員、領(lǐng)導(dǎo)、設(shè)計(jì)師和導(dǎo)師。 它可能不適用于遺留系統(tǒng)維護(hù)，因?yàn)橐呀?jīng)有一個(gè)系統(tǒng)并且沒(méi)有定義它的整體模型。因此，它需要一個(gè)團(tuán)隊(duì)重新開(kāi)始并從頭開(kāi)始工作。

總結(jié)

FDD是行業(yè)里成熟的、有成功案例的管理理論。它適合中大型復(fù)雜項(xiàng)目，化繁為簡(jiǎn)，從而實(shí)現(xiàn)迭代、增量交付，減少團(tuán)隊(duì)的混亂和返工。

縱觀我司歐洲團(tuán)隊(duì)的FDD，與行業(yè)里FDD的概念與實(shí)踐也有較高的匹配度：比如領(lǐng)域?qū)ο蠼＃―omain Object Modelling），歐洲團(tuán)隊(duì)有架構(gòu)圖來(lái)解構(gòu)產(chǎn)品全局，運(yùn)用“Thin Slice” Customer Function，切分功能，形成Feature list， 然后強(qiáng)調(diào)Feature team的Leadership和Ownership，實(shí)現(xiàn)Plan by feature、Design by feature和Build by feature。同時(shí)利用Jira的Structure插件也是項(xiàng)目進(jìn)度可視化的較好方案。

FDD成立之初，在領(lǐng)域建模部分，是與Java建模耦合的，設(shè)想這其中不乏豐富的工程實(shí)踐值得探究。在2002年，F(xiàn)DD與Java建模分離，成為更普適、更容易接近業(yè)務(wù)的管理框架。關(guān)于領(lǐng)域?qū)ο蠼＃―omain Object modelling），業(yè)界里另一個(gè)被討論得比較熱烈并被一些大公司采用的是DDD（Domain Driven Design領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)）。

FDD和DDD珠聯(lián)璧合，或許是解決復(fù)雜項(xiàng)目的一把利刃。

更多閱讀材料

1. 敏捷開(kāi)發(fā)的常見(jiàn)框架
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