特征驱动开发

FDD 方法来自于一个大型的新加坡银行项目。FDD 的创立者 Jeff De Luca 和 Peter Coad 分别是这个项目的项目经理和首席架构设计师。在 Jeff 和 Peter 接手项目时，客户已经经历了一次项目的失败，从用户到高层都对这个项目持怀疑的态度，项目组士气低落。随后， Jeff 和 Peter 采用了特征驱动、彩色建模等方法，最终获得了巨大成功。
FDD 是也是一个迭代的开发模型。FDD的每一步都强调质量，不断地交付可运行的软件，并以很小的开发提供精确的项目进度报告和状态信息。同敏捷方法一样，FDD 弱化了过程在软件开发中的地位。虽然 FDD 中也定义了开发的过程，不过一个几页纸就能完全描述的过程深受开发者的喜爱。
1．FDD 角色定义
FDD 认为，有效的软件开发不可缺少的三个要素是：人、过程和技术。软件开发不能没有过程，也不能没有技术，但软件开发中最重要的是人。个人的生产率和人的技能将会决定项目的成败。为了让项目团队能够紧密地工作在一起，FDD 定义了 6 种关键的项目角色：
（1）项目经理。项目经理是开发的组织者，但项目经理不是开发的主宰。对于项目团队来说，项目经理应该是团队的保护屏障。他将同团队外界（如高层领导、人事甚至写字楼的物业管理员）进行沟通，努力为团队提供一个适宜的开发环境。
（2）首席架构设计师。不难理解，首席架构设计师负责系统架构的设计。
（3）开发经理。开发经理负责团队日常的开发，解决开发中出现的技术问题与资源冲突。
（4）主程序员。主程序员将带领一个小组完成特征的详细设计和构建的工作，一般要求主程序员具有一定的工作经验，并能够带动小组的工作。
（5）程序员。若干个程序员在主程序员的带领下形成一个开发小组，按照特征开发计划完成开发。
（6）领域专家。领域专家是对业务领域精通的人，一般由客户、系统分析员等担当。领域专家作为关键的项目角色正是敏捷宣言中“业务人员同开发人员紧密合作”的体现。
根据项目规模的大小，有些角色是可以重复的。例如在一个小规模项目中，项目经理自身的能力很强，他就可以同时担当项目经理、首席架构设计师和开发经理的角色。
2．核心过程
FDD 共有 5 个核心过程，如图 6-6 所示。

（1）开发整体对象模型。开发整体对象模型也就是业务建模的阶段。不过 FDD 强调的是系统地完整地面向对象建模，这种做法有助于把握整个系统，而不仅仅关注系统中的若干个点。在这一阶段，领域专家和首席架构设计师相互配合，完成整体对象模型。
（2）构造特征列表。完成系统建模后，需要构造一个完整的特征列表。所谓特征指的是一个小的、对客户有价值的功能。采用动作、结果和目标来描述特征，特征的粒度最好可以在两周之内实现。在这一阶段中，可以整理出系统的需求。
（3）计划特征开发。很少看到有哪个软件在开发过程中明确包含计划过程，其实任何一个软件项目都必须有计划——无论是重载方法还是敏捷方法。在这一阶段中，项目经理根据构造出的特征列表、特征间的依赖关系进行计划，安排开发任务。
（4）特征设计。在这一阶段，主程序员将带领特征小组对特征进行详细设计，为后面的构建做准备。
（5）特征构建。特征构建和特征设计这两个阶段合并起来可以看做特征的实现阶段，这两个阶段反复地迭代，直到完成全部的开发。
3．最佳实践
组成 FDD 的最佳实践包括：领域对象建模、根据特征进行开发、类的个体所有、组成特征小组、审查、定期构造、配置管理、结果的可见性。
其中，最有特色的莫过于类的个体所有。几乎所有的开发模型都是代码共有，程序员们负责开发系统中的全部代码，并通过配置管理和变更控制来保持代码的一致性。在 FDD 中，将类分配给特定的任何小组，分配给 A 成员的代码将全部由 A 来维护，除 A 外的角色都不能修改它，只能使用它。这样做当然有它的优点：个人对所分配的类很容易保持概念的完整性；开发类代码的人肯定是最熟悉这个类的主人；而对这个类的支配感会促使开发人员产生自豪感，从而更出色地完成任务。不过 FDD 也提到了类个体所有的缺陷：项目中的依赖关系增强、当 A 需要 B 修改他自己的类时，必须等待 B 完成修改才能使用；类的个体所有增加了员工离职的损失。面对这些优点和缺陷，显然 FDD 认为类的个体所有对系统开发更有帮助。
除类的个体所有外，审查也是 FDD 中很具特色的一项实践。不少人都认为审查是非常严格的软件过程所特有的，因为进行审查不但要花费不少的人力和时间，对审查者本身的素质也有要求。然而在 FDD 中，明确地将审查作为一项最佳实践提出。审查是一种很有效的发现缺陷的手段，但经常被忽视，国内的软件组织中很少有严格审查制度保证软件质量。有效的审查可以发现很多潜在的问题，而这些问题往往是无法通过测试发现的，例如建模、需求和设计期的缺陷。这些潜在的缺陷大多要到系统测试甚至发布后才能发现，修正这些缺陷的代价是很大的。