特征驱动开发 Feature-Driven Development - FDD
FDD是Agile的流程之一，与Scrum和XP有所区别。FDD可运用于小项目和大型项目
敏捷团队对Iteration Zero应当比较熟悉，他包括一系列初始化工作，为后续迭代做好启动准备。敏捷社区认为Iteration Zero很重要，Scrum和XP则不这样认为。
FDD由5个过程组成，前3个过程属于Iteration Zero的范围，但FDD不使用Iteration Zero这种叫法。对这5个过程的进入标准、任务、检验标准、退出标准，以及参与角色等详细描述，参考：The Latest FDD Processes
FDD Process #1: Develop an Overall Model
首先是针对整体问题域的walkthrough，然后将问题域分组，并分组对子域进行walkthrough，创建对象模型并细化，添加备注等
Big Design Up Front中，建模由项目骨干使用重型的CASE工具，经历较长的时间完成，最终模型将形成大型文档丢给一堆开发者
FDD跟Big Design Up Front不一样，他的建模是一个比较激烈、高度交互、协作，且有趣的过程。业务人员和开发者都参与，由经验丰富的建模专家担任首席架构师角色，建模一般采用Peter Coad的彩色建模方法（非必要）。主要目的是通过讨论，团队中业务人员和开发者都清楚的了解业务概念、之间的关系、业务处理的交互过程，可以使用共同的语言（业务概念词汇等）进行交流。相比较之下，对象模型只是粗浅的、比较简单的、"just enough"就成，通过后续的迭代精细化，在后续的整个迭代过程中，这个对象模型作为讨论、澄清需求的主要手段
共同语言有利于避免在大型项目中，业务人员对相同的东西使用不同的称呼，或者同样的词汇却指的是不同的东西
Tasks:
1. Form the Modelling Team - Project Manager
2. Domain Walk-through - Modelling Team
3. Study Documents - Modelling Team
4. Develop the Model - Modelling Team in Small Groups
5. Refine the Overall Object Model - Chief Architect, Modelling Team
6. Write Model Notes - Chief Architect, Chief Programmers
示例对象模型：
FDD Process #2: Build a Features List
FDD并非模型驱动的开发方式，虽然对象模型在整个项目周期中起着非常重要的作用，但他是需求驱动开发方式的一种。他由特征（小的，客户层面的需求）驱动开发，模型只是产生特征的一个指导。每个特征的工作量上限不应当超过2周
与Scrum和XP不同，FDD并不使用扁平化的user stories，他的特征列表由业务模块（Subject Areas）、业务活动（Business Activities）、活动步骤（Steps）3个层级组成，这有利于大型项目中对众多特征的管理。最上层的Subject Area基本直接由项目范围分解而来
特征列表中的问题都在对象建模期间讨论过，由Chief Programmer创建，业务人员进行检验，这样也有利于Chief Programmer彻底清楚真正的需求
Tasks
1. Form the Features List Team - Project Manager, Development Manager
2. Build Features List - Features List Team
Features List Team由Chief Programmer组成
FDD Process #3: Plan by Feature
建立进度计划，分派职责，特征被分派给各个负责人
综合考虑特征间的依赖关系、Feature Team的工作量、特征的复杂度等因素，确定特征的开发顺序、分派给哪些Chief Programmer、Class Onwer等
与传统敏捷思想不同，FDD采用individual class ownership，而非collective方式管理源码，当然随着团队规模的扩大可以灵活加入collective ownership方式。当然FDD中并不会让individual class ownership而影响特征的完成进度。首先在FDD中，code ownership意味着职责而不是不让别人修改，代码所有者应当清楚自己负责的代码被修改了哪些东西，并负责检查，确保采用了正确的修改方式。另外在individual class ownership方式下提高写作开发效率的另一措施是依据实际情况动态构建feature team
Tasks:
1. Form the Planning Team - Project Manager
2. Determine the DevelopmentSequence - Planning Team
3. Assign Business Activities to ChiefProgrammers - Planning Team
4. Assign Classes to Developers - Planning Team
Planning Team由Development Manager和Chief Programmer组成
Planning Team为每个业务规则指定一个日期（到年或者月，很粗的一个计划）
Milestones:
Plan:
Plan on the Wall:
最重要的一点，类似iteration zero的过程在什么时间点算是结束，FDD中仍然采用"just enough"原则，并不必在这一过程中得到完善的模型，清楚需求的方方面面，只是在寻求一个足够启动的基础，模型、特征列表、计划都是灵活的，随着迭代的进展而细化。当然结束点的判断需要经验，经验丰富的建模专家担任首席架构师角色将承担起这一责任
有些项目前期可能需要评估、选择、安装相关工具，设置开发环境，决定采用哪些基础组件等，FDD流程中并不讨论这些，"just enough"，可以启动项目开发就行
FDD Process #4: Design By Feature
Features在阶段3中被分派给各Chief Programmer，阶段4中Chief Programmer按照计划将每次需要开发的Features取出来，确定需要使用到哪些class，这些class owner组成Feature Team。Feature Team细化设计，完成Sequence Diagram等，Chief Programmer负责在这些基础上完善模型（包括添加class、修改已有class的方法、属性等），最后开发者完成类和方法的prologue
Tasks:
1. Form Feature Team - Chief Programmer
2. Domain Walk-through - Domain Expert
3. Study the Referenced Documents - Feature Team
4. Develop the Sequence Diagram(s) - Feature Team
5. Refine the Object Model - Chief Programmer
6. Write Class and Method Prologues - Feature Team
Feature Team划分:
FDD Process #5: Build By Feature
开发员以特征为单位进行开发、单元测试，Chief Programmer进行代码审查，对通过审查的代码进行构建
Tasks:
1. Implement Classes and Methods - Feature Team
2. Code Inspection - Feature Team
3. Unit Test - Feature Team
4. Promote to the Build - Chief Programmer, Feature Team
进度管理
总体进度：
进度完成趋势：
进度完成趋势图：
参考：
An Introduction to Feature-Driven Development - Part 1
The Latest FDD Processes
FDD Overview Presentation
FDD Implementations
敏捷团队对Iteration Zero应当比较熟悉，他包括一系列初始化工作，为后续迭代做好启动准备。敏捷社区认为Iteration Zero很重要，Scrum和XP则不这样认为。
FDD由5个过程组成，前3个过程属于Iteration Zero的范围，但FDD不使用Iteration Zero这种叫法。对这5个过程的进入标准、任务、检验标准、退出标准，以及参与角色等详细描述，参考：The Latest FDD Processes
FDD Process #1: Develop an Overall Model
首先是针对整体问题域的walkthrough，然后将问题域分组，并分组对子域进行walkthrough，创建对象模型并细化，添加备注等
Big Design Up Front中，建模由项目骨干使用重型的CASE工具，经历较长的时间完成，最终模型将形成大型文档丢给一堆开发者
FDD跟Big Design Up Front不一样，他的建模是一个比较激烈、高度交互、协作，且有趣的过程。业务人员和开发者都参与，由经验丰富的建模专家担任首席架构师角色，建模一般采用Peter Coad的彩色建模方法（非必要）。主要目的是通过讨论，团队中业务人员和开发者都清楚的了解业务概念、之间的关系、业务处理的交互过程，可以使用共同的语言（业务概念词汇等）进行交流。相比较之下，对象模型只是粗浅的、比较简单的、"just enough"就成，通过后续的迭代精细化，在后续的整个迭代过程中，这个对象模型作为讨论、澄清需求的主要手段
共同语言有利于避免在大型项目中，业务人员对相同的东西使用不同的称呼，或者同样的词汇却指的是不同的东西
Tasks:
1. Form the Modelling Team - Project Manager
2. Domain Walk-through - Modelling Team
3. Study Documents - Modelling Team
4. Develop the Model - Modelling Team in Small Groups
5. Refine the Overall Object Model - Chief Architect, Modelling Team
6. Write Model Notes - Chief Architect, Chief Programmers
示例对象模型：
FDD Process #2: Build a Features List
FDD并非模型驱动的开发方式，虽然对象模型在整个项目周期中起着非常重要的作用，但他是需求驱动开发方式的一种。他由特征（小的，客户层面的需求）驱动开发，模型只是产生特征的一个指导。每个特征的工作量上限不应当超过2周
与Scrum和XP不同，FDD并不使用扁平化的user stories，他的特征列表由业务模块（Subject Areas）、业务活动（Business Activities）、活动步骤（Steps）3个层级组成，这有利于大型项目中对众多特征的管理。最上层的Subject Area基本直接由项目范围分解而来
特征列表中的问题都在对象建模期间讨论过，由Chief Programmer创建，业务人员进行检验，这样也有利于Chief Programmer彻底清楚真正的需求
Tasks
1. Form the Features List Team - Project Manager, Development Manager
2. Build Features List - Features List Team
Features List Team由Chief Programmer组成
FDD Process #3: Plan by Feature
建立进度计划，分派职责，特征被分派给各个负责人
综合考虑特征间的依赖关系、Feature Team的工作量、特征的复杂度等因素，确定特征的开发顺序、分派给哪些Chief Programmer、Class Onwer等
与传统敏捷思想不同，FDD采用individual class ownership，而非collective方式管理源码，当然随着团队规模的扩大可以灵活加入collective ownership方式。当然FDD中并不会让individual class ownership而影响特征的完成进度。首先在FDD中，code ownership意味着职责而不是不让别人修改，代码所有者应当清楚自己负责的代码被修改了哪些东西，并负责检查，确保采用了正确的修改方式。另外在individual class ownership方式下提高写作开发效率的另一措施是依据实际情况动态构建feature team
Tasks:
1. Form the Planning Team - Project Manager
2. Determine the DevelopmentSequence - Planning Team
3. Assign Business Activities to ChiefProgrammers - Planning Team
4. Assign Classes to Developers - Planning Team
Planning Team由Development Manager和Chief Programmer组成
Planning Team为每个业务规则指定一个日期（到年或者月，很粗的一个计划）
Milestones:
Plan:
Plan on the Wall:
最重要的一点，类似iteration zero的过程在什么时间点算是结束，FDD中仍然采用"just enough"原则，并不必在这一过程中得到完善的模型，清楚需求的方方面面，只是在寻求一个足够启动的基础，模型、特征列表、计划都是灵活的，随着迭代的进展而细化。当然结束点的判断需要经验，经验丰富的建模专家担任首席架构师角色将承担起这一责任
有些项目前期可能需要评估、选择、安装相关工具，设置开发环境，决定采用哪些基础组件等，FDD流程中并不讨论这些，"just enough"，可以启动项目开发就行
FDD Process #4: Design By Feature
Features在阶段3中被分派给各Chief Programmer，阶段4中Chief Programmer按照计划将每次需要开发的Features取出来，确定需要使用到哪些class，这些class owner组成Feature Team。Feature Team细化设计，完成Sequence Diagram等，Chief Programmer负责在这些基础上完善模型（包括添加class、修改已有class的方法、属性等），最后开发者完成类和方法的prologue
Tasks:
1. Form Feature Team - Chief Programmer
2. Domain Walk-through - Domain Expert
3. Study the Referenced Documents - Feature Team
4. Develop the Sequence Diagram(s) - Feature Team
5. Refine the Object Model - Chief Programmer
6. Write Class and Method Prologues - Feature Team
Feature Team划分:
FDD Process #5: Build By Feature
开发员以特征为单位进行开发、单元测试，Chief Programmer进行代码审查，对通过审查的代码进行构建
Tasks:
1. Implement Classes and Methods - Feature Team
2. Code Inspection - Feature Team
3. Unit Test - Feature Team
4. Promote to the Build - Chief Programmer, Feature Team
进度管理
总体进度：
进度完成趋势：
进度完成趋势图：
参考：
An Introduction to Feature-Driven Development - Part 1
The Latest FDD Processes
FDD Overview Presentation
FDD Implementations
