敏捷开发FDD过程

FDD过程

阶段一：开发一个总体模型

    本阶段一个最基本的项目范围内的活动，就是在一个有经验的对象建模人员即主架构师的指导下，业务人员和开发小组成员一起工作。

    业务专家们完成一个贯穿整个系统及其内外关系的高层次走查，然后完成建模领域中每一区域的详细走查。每一次业务走查之后，成立有业务人员和开发成员参加的工作小组。每个工作小组构造自己用于支持业务走查的模型，提供其结果用于详细复查和讨论。根据多数人的意见，从所提出的模型或一组模型中选择一个模型，并使它成为这个领域区域的模型。各个领域区域的模型被合并成整理模型，并根据需要对模型进行调整。

    关于对象模型的内容会在第4阶段的"基于功能进行设计"进行迭代更新。

Entry Criteria
    确立项目的业务专家，主程序员，主架构师。

Tasks
1、组建建模团队           项目经理                            必须
---------------------------------------------------------------------
建模团队是由精通业务和开发方面的固定人员组成，特别是业务专家和主程序员应该。轮换项目其他成员参加建模会议，使每个人都有机会参与和了解过程的情况。

2、业务分析               建模团队                            必须
------------------------------------------------------------------
业务专家给出将要建模的业务区域的概要，它应该包括于这个业务领域有关的信息，而这些信息不必成为实现中的一部分。

3、研究资料               建模团队                            可选
------------------------------------------------------------------
学习有用的参考文献或者需求文档，比如对象模型、功能需求（传统的或者用例格式）和用户指南。

4、开发业务模型           建模团队中的工作小组                必须
----------------------------------------------------------------------------
组成不超过3人的工作小组，每个工作小组构造一个支持这个业务区域的模型。主架构师可能提出一个"稻草人"模型以推动建模小组的进展。各个工作小组偶尔也可能草拟一个或更多的非正式的顺序图来测试模型。

5、精化整体对象模型       主架构师、建模团队                  必须
-----------------------------------------------------------------------------
利用对前面开发业务模型任务的迭代所产生的新的模型，建模团队经常更新整体对象模型。

6、写模型注释             主架构师、主程序员                  必须
--------------------------------------------------------------------------
对详细或复杂的模型以及重要的可选模型进行注释，以备项目将来参考之用。

Verification
内部和外部评估            建模团队、业务人员                  必须
--------------------------------------------------------------------------
有积极参加开发过程的业务专家提供内部或自我评估。外部评估则根据提供给业务代表（用户）认可或澄清影响模型的一些问题的需要进行。

Exit Criteria
    为了退出过程，建模小组必须生成一个令架构师满意的对象模型，对象模型包括如下内容：
    1) 类图重点关注模型的形状。也就是，哪些类是属于业务中的，他们彼此之间的关系，以及存在哪些约束，类中的方法和属性被标注出来。
    2) 顺序图（如果有的话）.
    3) 说明为什么某个特定的模型被选取，以及考虑什么样的替代模型。

阶段二：构造功能列表

   本阶段一个最基本的项目范围内的活动，就是确定所有用于支持需求的功能列表。
   通常仅由阶段一中的主程序员们组成一个小组，并由这个小组对业务需求进行功能分解。根据业务专家在阶段一中对业务的划分，将整个业务分成一定数量的主题（主要功能集），每个主题在细分为一定数量的活动（功能集）。活动中的每一步被定为一个特征。其结果是形成具有层次结构的功能分解表。

Entry Criteria
    建模团队已成功地完成了FDD第一阶段的工作，开发出了系统的整体模型。

Tasks
1、组建功能分解小组                项目经理、开发经理           必须
-------------------------------------------------------------------------------
功能表小组由阶段一中的主程序员组成。

2、建立功能列表                    功能分解小组                 必须
-------------------------------------------------------------------------------
   功能表小组使用从阶段一所获得的知识来标示功能集，可能也使用一些现有的参考资料或需求文档，比如对象模型、功能需求（传统的或用例格式）和用户向导，对以这种方式确定的功能用源文档进行注释。
   这种任务是从业务划分开始的简单的功能分解，在阶段一中业务专家也用这种业务划分进行业务领域的走查。业务被分解成区域（主要功能集），然后被分解成活动（功能集），最后被分解成功能。每一个功能代表一个活动里的一步。
功能是用对客户有价值的术语进行描述的细小操作，使用如下命名模板：
<action><result><object>
比如，"计算总销售额"和"计算一种商品的零售总量"。

功能是细小的，完成一个功能应该不超过2周，但它也不能仅仅像赋值操作那么简单。2周是一个上限，大多数功能不需要这么长时间。当某一步看起来太大时，功能分解小组会把它分成更小的步，使其成为功能。

Verification
内部和外部评审                     功能分解小组，业务人员        必须
-------------------------------------------------------------------------------
由积极参与的建模团队成员进行内部或自我评审。外部评审则根据提供给来自建模团队的业务专家或业务代表（用户）认可或澄清影响功能清单的一些问题的需要进行。

Exit Criteria
    为了退出本阶段，功能分解小组必须生成令项目经理和开发经理满意的功能列表，功能列表包括：
    1) 一张主要功能集（区域）表
    2) 与每个主要功能集对应的一张功能集（活动）表
    3) 与每个功能集（活动）分别对应的一张功能表
    4) 每个功能分别对应一个业务活动的步骤

阶段三：根据功能制定计划

    本阶段一个最基本的项目活动就是产生一个开发计划。

     项目经理、开发经理和主程序员根据功能的相关性、开发小组的工作负荷以及功能的复杂性，计划实现功能的优先级。这一阶段中的主要任务没有严格的顺序。像许多其他计划活动一样，这些任务被一起考虑，精化一个或多个任务之后，需要重新考虑其他任务。一个典型的场景是首先考虑开发顺序，然后考虑将功能集分配给主程序员。通过这样做，可以考虑将哪个关键类（惟一）分配给哪个开发人员（记住主程序员同样也是一个开发人员）。当达到了这样的平衡，并且确定了开发顺序和将功能集分配给主程序员的任务基本上完成后，类的所有权也确定了（除了那些已经考虑了所有权的关键类）。

Entry Criteria
  构造功能列表的阶段已经完成。

Tasks
1、组建计划小组      项目经理                       必须
-------------------------------------------------------------------------------
计划小组由项目经理、开发经理和主程序员组成。

2、确定开发优先级              计划小组                       必须
-------------------------------------------------------------------------------
计划小组为完成每一个功能集指定一个日期（年月日），并基于以下因素确定功能集和完成日期以及优先级：
  1) 由功能中所包含的类确定的功能之间的依赖关系
  2) 类所有者工作负荷的平衡
  3) 要实现的特征的复杂性
  4) 所提出的高风险或复杂的功能集
  任何外部（可视的）里程碑的有关考虑，比如β测试、预览、反馈检查点和符合这种里程碑的"完整产品"

3、为主程序员分配功能集          计划小组                       必须
-------------------------------------------------------------------------------
计划小组将主程序员指定为功能集的所有者，指定基于以下因素：
  1) 开发顺序
  2) 由功能中所包含的类确定的功能之间的依赖关系
  3) 类所有者工作负荷的平衡（记住主程序员同样也是一个开发人员）
  4) 要实现的特征的复杂度
 
4、为开发人员分配类              计划小组                       必须
-------------------------------------------------------------------------------
计划小组将开发人员指定为类所有者，开发人员拥有多个类。将类指定给开发人员基于以下因素：
  1) 开发人员工作负荷的平衡
  2) 类的复杂性
  3) 类的预计使用情况（例如大量使用）
  4) 开发顺序

Verification
自我评审                      计划小组                       必须
--------------------------------------------------------------------------------
计划是一个小组活动，因此自我评估应该由项目经理、开发经理积极参与，与主程序员共同完成，而主程序员将使用在阶段一中所获取的知识来做出更好和更合理的决策。

Exit Criteria
为了退出过程，计划小组必须生成令项目经理和开发经理满意的开发计划。开发计划包括如下内容：
  1) 功能集及其完成日期
  2) 将功能集分配给主程序员
  3) 主要特征集及其完成日期，该日期来自于功能集最后的完成日期
  4) 类别和拥有它们的开发人员（类所有者）
容

阶段四：根据功能进行设计

每一个功能集都产生一个功能的设计包。

一定数量的功能通过分配给主程序员被列入开发时间表。主程序员从分配给他（或她）的任务中选出功能进行开发。从实现上看，主程序员通常一次选择一组功能进行开发。他（或她）可能碰巧使用相同类（也就是相同开发人员）的多个功能。这样一组功能构成了主程序员的工作包。

主程序员随后通过确定那些拥有可能用于开发所选功能的类的所有者，来构成一个功能小组。这个小组为选中的功能生成详细的顺序图。主程序员随后基于顺序图内容，进一步精化对象模型，开发人员写出类和方法的序言，然后进行设计审查。

Entry Criteria

  根据功能制定计划的工作已经完成。

Tasks
1、成立功能小组                         主程序员           必须
--------------------------------------------------------------------------
主程序员确定在设计这组功能时可能用到的类。根据类的所有者表，主程序员确定所需的开发人员，组建功能小组。作为这一步的一部分，主程序员为功能开启一个新的设计包作为工作包的一部分。

2、进行业务走查                         业务专家           可选
--------------------------------------------------------------------------
应主程序员的请求，业务专家会详细走查功能小组内将要设计的功能的算法、规则、公式和数据元素。这是一个基于功能及其交互的复杂性的可选任务。

3、研究参考文档                         功能小组           可选
--------------------------------------------------------------------------
功能小组研究在功能表中引用的那些与将要设计的功能有关的文档和其他相关文档，包括任何备忘录、用户界面设计和系统外部接口说明。这是一个基于功能及其交互的复杂性以及是否存在这类文档的可选任务。

4、开发顺序图                         功能小组           必须
--------------------------------------------------------------------------
功能小组为每个正在设计的功能开发所需要的详细的顺序图，这些文件必须有版本管理系统管理起来。任何可替代的设计、设计决策、假设、需求澄清以及注释都必须记录下来，并写入到设计方案和设计包的可选章节中。

5、精化对象模型                         主程序员           必须
--------------------------------------------------------------------------
主程序员为功能创建一个功能小组区域。这个区域或许是一个文件服务器上的一个目录、个人电脑上的一个目录，并由主程序员负责备份；或者这个区域由项目的版本控制系统确定。这个区域在功能小组中是可见的，而对其他功能小组不可见。通过这个区域可以让小组内获得工作的进度状况。
主程序员精化模型以便添加其他的类、操作和属性，同时基于为功能定义的顺序图来改变现有的类、操作或属性。相关的实现语言源文件在功能小组的共享区域中进行更新。主程序员以公共的格式建立模型图。这些文件必须提交到版本管理系统中并在项目内部发布。

6、编写类和方法的序言                 功能小组           必须
--------------------------------------------------------------------------
通过使用由功能小组共享区域中"精化对象模型"任务（上一任务）所更新的用实现语言编写的源文件，每一个类所有者为功能和顺序图所定义的每一项写下类的方法的序言，包括参数类型、返回类型、例外和消息。一旦开发人员完成这项工作，主程序员通过使用工具产生API文档，并在项目范围内发布。

Verification
设计评审                             功能小组           必须
--------------------------------------------------------------------------
主程序员决定是在功能小组内或是与其他开发小组成员一期来完成审查。如果审查结论获得通过，为每一个受影响的类产生一个待做任务的清单，每一个小组成员将他（或她）的任务加入其中。主程序员将本功能小组内的变更合并到整个项目的变更控制系统中。

Exit Criteria
这个阶段的成果是一个成功通过评审后的设计包。这个设计包包括：
  1) 集成和描述设计包的备忘录或文件，供审查人员使用
  2) 文档形式的参考性需求（如果有的话），以及所有相关的备忘录和支持文档
  3) 顺序图
  4) 可替代的设计方案（如果有的话）
  5) 包含有新/更新的类、方法和属性的对象模型
  6) 本阶段设计中新建或者修改的类和方法的序言，通过你的工具产生的输出物
  7) 提供给每一个小组成员的修改受影响的类所需的待做任务清单和修改日程