在眾多敏捷方法裡，功能驅動開發（FDD）常被忽略，卻特別適合一種情境——團隊不小、需求偏複雜，又希望有清楚的進度可回報。它不像 Scrum 那樣圍繞衝刺，而是圍繞一個個「有客戶價值的小功能」推進。這篇帶你了解 FDD，並一步步在軟體開發團隊導入它。
什麼是功能驅動開發（FDD）
功能驅動開發（Feature-Driven Development, FDD）是一種以「功能」為核心、由模型驅動、短迭代的開發方法。它把系統拆解成許多小而具體、對客戶有價值的「功能（feature）」，再依功能逐一設計與建置。它的一大特色，是強調前期的領域建模，讓團隊對系統有共同的理解，再據此展開後續工作。
FDD 的五個核心流程
FDD 由五個流程構成：建立整體模型（讓團隊對領域有共同認知）、建立功能清單（把系統拆成一份完整的功能列表）、依功能規劃（安排功能的開發順序與負責人）、依功能設計、依功能建置。前兩個奠定基礎，後三個則是針對每個功能反覆進行的短循環。
為什麼軟體團隊適合 FDD
FDD 特別適合中大型、需求複雜的軟體專案。它有幾個吸引人的特質：進度清楚可衡量——每個功能是小而明確的單位，「完成了幾個功能」是很誠實的進度指標；責任明確——功能有清楚的擁有者；兼顧結構與敏捷——前期建模帶來結構，功能迭代帶來彈性。對於覺得「純 Scrum 太鬆、瀑布太硬」的團隊，FDD 是個務實的中間選擇。
導入 FDD 的步驟
一、建立領域模型
召集開發與領域專家，一起釐清系統的核心概念與關係，建立一個共同的模型。這一步讓團隊「講同一種語言」，是後續一切的基礎。
二、拆解出功能清單
把系統拆解成一份完整的功能清單。好的功能命名遵循「動作 + 結果 + 對象」——例如「計算一筆訂單的總金額」「驗證使用者的登入憑證」。每個功能都應小到能在幾天內完成。
三、依功能規劃與分派
把功能分組、排定開發順序，並指定每個功能的負責人。相依關係在此浮現——哪些功能必須先於哪些。
四、依功能設計與建置
針對每個功能，進行細部設計、開發、程式碼審查與測試，完成後整合。這個短循環反覆進行，直到功能清單被逐一消化。
導入時的注意事項
別跳過建模。 FDD 的價值有一半來自前期的共同模型。急著開工、跳過建模，往往導致後期各做各的。
功能要切得夠小。 一個「功能」該小到能在數天內完成、且有明確的客戶價值。切得太大，就失去了 FDD「進度清楚」的優勢。
善用「頻繁整合」。 FDD 強調定期建置與整合，讓問題在小範圍就被發現。
用 Meegle 落實功能驅動開發
FDD 的核心是「管理一份龐大的功能清單，並追蹤每個功能的進度」——這正是 Meegle 的強項。你可以把功能清單建成視覺化工作流上的工作項，每個功能走過設計、開發、審查到建置的節點；相依關係讓功能之間的先後一目了然，負責人清楚標示在每個功能上，儀表板則以「完成的功能數」呈現真實進度。當功能清單被結構化地管理，FDD 「進度清楚、責任明確」的優勢，才能充分發揮。
結語
功能驅動開發，為那些「需求複雜、又想要清楚進度」的軟體團隊，提供了一條務實的路。它用前期建模帶來結構，用功能迭代帶來敏捷，用「完成的功能數」帶來誠實的進度。掌握它的五個流程、把功能切得夠小、別跳過建模，再用一套能管理龐大功能清單的工具支撐——FDD 就能讓你的軟體開發，既有章法又不失彈性。