特性驱动开发 FDD

全局建模

是在一位经验丰富的对象建模师（首席架构师）的指导下，与领域专家和开发成员一起进行的项目维度初始活动。最初要以系统范围以及背景的顶层走查开始，然后对每个要建模的区域进行详细的域遍历，并面向对象构建全局模型，目标是识别和理解目标待构建系统所处理的特定领域的基础信息。

在每次领域演练之后，由领域和开发人员组成的小组将组成，然后他们组成自己的模型来支持该领域演练。每个小组都展示了他们的模型，供同行评审和讨论。通过协商一致的方式选择所提出的模型之一或模型的合并，从而成为该领域的模型。执行域区域模型到整体模型的合并，根据需要调整模型形状。

然后通过特征设计过程#4用内容迭代地更新对象模型。

• 准入条件：

领域专家、首席程序员以及首席架构师就位。

• 任务：

建模团队由来自领域专家和开发团队的常驻成员组成，特别是领域专家和首席程序员。然后，其他项目工作人员轮流参加建模会议，这样每个人都有机会参与并看到过程的进展。

领域专家对要建模的领域区域进行概述。这还应包括与该领域相关的信息，但不一定包含执行层面的信息。

团队研究可用的参考或需求文档，如对象模型、功能需求（传统或用例格式）、数据模型和用户指南。

划分不超过三个小组，每个小组将构建一个模型来支持领域需求。首席架构师可以提出一个“strawman”模型来促进团队的进展。每个小组中的一名成员向该小组展示针对业务领域提出的模型。首席架构师还可以提出进一步的模型替代方案。建模团队选择一个模型提案，或者通过合并模型提案中的想法来构建模型。

每隔一段时间，全局对象模型就会用上述“构建模型”任务，基于迭代产生的新模型进行更新。

对详细或复杂的模型形态以及重要的模型备选方案进行记录，以供项目未来参考。

• 审查

内部或自我评估是通过领域专家的积极参与来实现的。在必要的基础上，外部评估是通过向企业（用户）提交对影响模型的问题的批准或澄清来进行。

• 准出标准
• 该过程的输出物是对象模型
• 以模型形态为主的类图。也就是说，域中有哪些类，它们是如何相互连接的，以及在什么约束下。
• 已识别的方法和属性被放置在类中。
• 序列图（如有）。
• 模型注释，以捕捉选择特定模型形态的原因和/或考虑了哪些替代方案。

构建特性清单

基于初始建模过程中汇集的信息，通过把功能从业务领域分解为更小的主题域生成一份特性清单。特性清单根据主题域中的业务活动以及其中的各个步骤进行分类。特性通过‘行为’‘结果’‘目标’这样的格式来体现功能所承载的用户价值，并且完成它的时间不应该超过2周，否则就需要拆分成更小的切片。

• 准入条件：

领域专家、首席程序员以及首席架构师就位。

• 任务：

团队包含了在步骤#1中建模团队的首席程序员。

团队应使用从步骤#1由领域专家对业务领域的划分获得的知识进行简单的功能分解以构建特性清单。它被分解为包括业务活动的主题域，这些业务活动包括业务活动步骤，并使用此命名模板以客户价值术语表示：＜action＞＜result＞＜object＞

根据一个特性不超过两周完成的规则，特性的颗粒度是较小的。两周是上限，大多数特性所需的时间都少于此时间。当业务活动步骤看起来大于两周时，该步骤会被分解为较小的步骤，然后转化为特性。

• 审查

内部或自我评估是通过建模团队的积极参与来实现的。在必要的基础上，外部评估是通过向企业（用户）提交对影响特性清单的问题的批准或澄清来进行。

• 准出标准

该过程的输出是特性清单：

• 主题域清单
• 每个主题域内的业务活动清单
• 满足上述业务活动的特性

基于特性规划

在特性清单完成后，下一步就是产出交付计划并且为每个特性（或者特性集）指定负责人，为类指定开发者。

25%

项目经理、开发经理和首席程序员根据功能依赖、整个开发团队的负载以及要实现的功能的复杂性来规划功能的实现顺序。这个过程中的主要任务并不是产出一个严格的开发序列。像许多计划活动一样，它们作为整体考虑，但是是一个或多个任务的梳理完成后再考虑其他任务。一个典型的场景是考虑开发顺序，然后考虑将业务活动分配给首席程序员，在这样做的过程中，仅考虑将哪些关键类分配给哪些开发人员（记住，首席程序员也是开发人员）。当实现了这种平衡，业务活动的开发顺序和分配就基本上完成了，类的负责人也指明了。

• 准入条件：

特性清单完成。

• 任务：

团队包含了开发经理和首席程序员。

计划团队应指定完成每项业务活动的日期（具体到月份和年份即可）。业务活动和完成日期以及开发顺序的识别是基于：

• 根据所涉及的类，功能之间的依赖关系
• 平衡类负责人之间的负载
• 要实现特性的复杂性
• 推进处理高风险或复杂业务的活动
• 考虑可见的任何外部里程碑，如测试版、预览、反馈检查点和满足各个里程碑的“整个产品”。

规划小组应基于下述条件指定首席程序员作为对应业务活动的负责人：

• 开发顺序
• 所涉及的类，特性之间的依赖关系
• 平衡类负责人之间的负载（记住，首席程序员也是类所有者）
• 要实现的特性的复杂性。

规划团队应基于以下条件将开发人员指定为类所有者，开发人员可以拥有多个类：

• 平衡开发人员之间的负载
• 类的复杂性
• 类的使用情况（例如高使用率）开发顺序。
• 审查

规划是一项团队活动，通过首席程序员、开发经理和项目经理的积极参与来实现自我评估。

• 准出标准

该过程的输出是开发计划，包括：

• 具有完成日期的业务活动（月和年）
• 分配给业务活动的首席程序员
• 主题域的完成日期（月和年）源自其各自业务活动的最后完成日期
• 类和对应负责人的列表

基于特性设计

首席开发者为后续两周的选择一组要完成开发的特性，与类的负责人一起为每个特性绘制详细的序列图并且细化整体模型，完成类和方法的简介并最终完成设计评审。

这是按每个特性来产出对应特性设计包的活动，通过将特性清单分配给首席程序员来制定开发计划。

首席程序员从被分配特性的“收件箱”中选择要开发的特性。他可能会选择碰巧使用相同类的多个特性，通常情况下，首席程序员会安排一次开发“一组”特性，这样的集合被称为首席程序员工作包。

然后，首席程序员通过确定可能参与开发他选择用于开发的特性的类（开发人员）的负责人，组成一个特性团队。然后，该团队为被指派的特性生成序列图。其次，首席程序员根据序列图的内容细化对象模型。最后，开发人员编写类和方法的简介，以进行设计检查。

• 准入条件：

规划活动完成。

• 任务：

首席程序员确定可能进入设计的一组特性中的类，并相应地更新特征数据库。从类负责人列表中，首席程序员确定了组建Feature团队所需的开发人员。作为该步骤的一部分，首席程序员为特性创建一个新的设计包，作为工作包的一部分。

领域专家针对要设计的特性的业务领域提供概要的信息。这还应该包括与特性相关但不一定要实现的业务领域信息。这是一项基于功能复杂性和或其对应的交互可选任务。

特性团队研究要设计的功能的参考文件，包括所有确认过的备忘录、界面设计、外部系统接口规范和任何其他支持文件。这是一项基于功能复杂性和/或其交互的可选任务。

开发即将设计的特性所需的序列图。应将图表文件检入版本控制系统。任何备选设计、设计决策、需求澄清和注释也记录在设计包的设计备选部分中。

首席程序员为特性创建一个特性团队区域。该区域是文件服务器上的一个目录，或者是由首席程序员根据需要备份到服务器或使用版本控制系统中的工作区域支持的他们的PC上。特性团队区域的目的是可以共享正在进行的工作，并且仅在特性团队中可见，对项目的其他部分不可见。

首席程序员根据为特征定义的序列图，对模型进行细化，以添加额外的类、方法、属性和/或对现有类、方法或属性进行更改。首席程序员以可发布的格式创建模型图。这些文件应检入版本控制系统，并提交在项目内部网上发布。

使用共享特性团队区域中“细化对象模型”任务中更新过的实现语言源文件，每个类的开发负责人为特性和序列图定义的每个项编写类和方法序言。这包括参数类型、返回类型、异常和消息。每个开发人员完成此任务后，首席程序员使用＜您的工具＞生成API文档，并将其提交到项目内联网上发布。。

• 审查

与特性团队成员或其他项目成员一起进行设计评审。是否在特性团队内部还是与其他项目团队成员一起检查由首席程序员决定。接受后，每个受影响的类都会生成一个待办事项列表，每个团队成员都会将自己的任务添加到日历任务列表中。首席程序员还必须将共享特性团队区域的变更合并到变更控制系统中。。

• 准出标准

该过程的输出是一个通过评审的设计包，包括：

• 一份包含了备忘录或文档，对设计包进行整合和描述，使其可以独立供评审。
• 文件形式的需求参考（如有）以及所有相关的确认备忘录和援引文件。
• 序列图。设计备选方案（如有）
• 具有最新的/更新过的类、方法和属性的对象模型。
• 基于设计创建或修改的类和方法简述。
• 每个团队成员的受影响类上的操作项目的日历/待办任务列表条目。

基于特性构建

设计评审通过以后将产出特性计划，类的负责人完成代码开发、单元测试以及通过代码评审，完成的特性将合并入主分支。

按特性进行的活动，目标是产生一个完整的客户价值功能（特性）。

从设计包开始，类负责人实现其类所需的各项内容，以支持此特性的设计。开发的代码随后进行单元测试和代码检查，其顺序由首席程序员决定。通过代码评审后，代码将升级为内部版本。

• 准入条件：

“按特性设计”过程已完成。也就是说，设计包已经成功地通过评审。

• 任务：

类负责人实现必要的项，以满足特性中类的具体需求。

在单元测试任务之前或之后，将与特性团队成员或其他项目成员一起进行代码评审，如何实施由首席程序员决定。

类负责人测试他们的代码，以确保其满足类的所有需求。如果必要，首席程序员需要确定需要特性团队级的单元测试。也就是说，如果需要为完成特性需求所开展的任何跨类测试。

只有在成功通过代码评审之后，才能将类合并到版本中。作为整个特性的集成结点，首席程序员通过开发人员的反馈来跟踪正在合并的各个类

• 审查

成功的代码检查加上成功完成单元测试就是对该过程输出的验证。代码检查和单元测试任务如上所述。

• 准出标准

该过程的产出是：

• 已成功进行代码检查的类和/或方法。
• 已升级到内部版本的类。
• 完成的具有客户价值功能（特性）。