【产品经理修炼之道】-需求太复杂？试试FDD框架管理流程

面对需求相对复杂以及合作方众多的情况下，产品经理该如何处理这些需求？作者结合行业资料及其自身经验，与大家探讨如何利用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在实践上，分以下五个步骤：

开发一个全局的模型：在有经验的组件/对象建模专家（首席架构师）的指导下，业务领域需求人员与开发人员一起协调工作。业务领域需求人员提供一个初始的、具有一定高度的、可以覆盖整个系统和业务场景的介绍。业务人员和开发人员依此产生初始的模型，然后组成单独小组，进入详细讨论阶段。将模型描绘出来，最后丰富之前产生的初始模型。
建立特性列表：将这些特性进行分类、合并和整理。如功能需求中有用户注册、用户修改注册资料和用户用于登录功能，难么输入特性列表中之后就可能是围绕对象模型用户（User）的新增、修改、删除及查询等功能。
依据特性制定计划：将这些特性排序和计划，然后分配相应的程序员组。
依据特性进行设计：程序员组针对自己的特性列表按迭代进行设计。
依据特性进行构建：程序员依据特性进行构建。

图片来源：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珠联璧合，或许是解决复杂项目的一把利刃。