特征驱动开发——Feature Driven Development
还是老规矩，讨论之前，我们先了解一下什么是Feature？什么是FDD？
在FDD中，Feature（特征）是一个基本的开发单位，是（FDD）项目中的一个增量，是指用户眼中最小的有用的功能，可以在很短时间内实现（一般在两周之内）。
特征是小的
特征之所以是小的，是因为他可以在两周之内实现，任何一个过于复杂而无法在两周之内完成的功能，可进一步呗分解小到足以被称为一个特征。使特征小一些也意味着客户能经常看到可测量的进度。
特征是具有客户价值的
在业务系统中，一个特征映射到业务过程中某些活动的一个步骤。在其他系统中，特征等同于由用户完成的一项任务中的一个步骤。
特征驱动开发（FDD），是敏捷开发方法中的一种，他来源与新加坡的一个大型软件开发项目，由著名软件专家Jeff de Luca 、Eric Lefebvre、Peter Coad共同提出的。它强调特征驱动，快速迭代，即能保证快速开发，又能保证适当文档和质量。
他提出的每个功能开发时间不超过两周，为每个用例user case限定了粒度，具有良好可执行性，也可以对项目的开发进程进行精确及时地监控。他抓住了软件开发的核心问题领域，即正确和及时地构造软件。
FDD还打破了传统的将领域和业务专家/分析师与设计者和实现者隔离开来的壁垒。分析师被从抽象的工作中解脱出来，直接参与到开发人员和用户所从事的系统构造工作中。
FDD方法包括5个过程，其中的按照功能设计和构建是反复的迭代过程。
开发整体模型
这是FDD开始一个项目的初始工作，在主设计师的指导下，带领领域专家和开发小组成员一起工作。主要是收集系统的功能需求，然后使用四色原型进行域建模。我个人认为，在此阶段中，能够得出系统的架构设计图。
构建功能列表
这个过程确定所有用于支持需求的功能。由领域专家和开发小组进行功能分解。根据领域专家对领域的划分，将整个领域分成一定数量的区域（主要功能集），每个区域再细化为一定数量的活动。活动中的每一步被划分称为一个功能。形成了具有层次结构的分类功能列表。个人认为，在此阶段中，能够形成系统的概要设计。
计划功能开发
项目经理、开发经理和开发小组根据功能的依赖性、开发小组的工作负荷以及要实现的功能的复杂性，计划实现功能的顺序，完成一个功能开发计划。它提供了对项目的高层视图，让业务代表了解功能开发、测试和发布日期，以便业务代表和部署小组能够计划交付哪些功能的日期。本阶段的主要成果是，能够形成项目开发计划。
按照功能设计
项目经理和上一阶段指定的各个功能集的主要程序员一起对功能进行详细设计。同时在域模型的基础上进行分析、设计，得出分析模型、设计模型。由于一次设计并不全面，因此也可以直接进入设计模型。根据设计的结果制定出项目的里程碑。这里会有一个设计评审的环节。本阶段的成果应该包括了：详细设计、项目里程碑计划等。
按照功能构建
按照设计进行编码实现，由程序员实现各自负责的类。在代码完成后有必要的组织代码复查、评审。在测试和检查通过后检入到配置管理库中进行构建。第5和第4 阶段是一个迭代的过程，迭代周期一般为2个星期。这样经过不断的迭代，不断的实现功能集中的功能。每一个里程碑的时候进行评估、回顾。并考虑下一个里程碑 的继续，直到最后项目的完成。
领域对象建模
是对象分解的一种形式，主要包括构造类图，用于描述问题领域中重要对象的类型及其相互关系，为系统设计提供了一种整体框架，使得系统可以按照特征迭代增量地进行开发。
按照特征开发
按照一组小功能、对客户有价值的功能列表进行开发并跟踪过程。FDD将需求问题分解成可以解决的小问题，对每个问题分解为分层列表的功能需求，即特征。然后，开始设计并实现每一个特征。一旦系统的功能特征被标识以后，它们通常在FDD方法中用于驱动和跟踪开发过程。
类（代码）拥有权
FDD规定每一个类都有一个指定的人/角色负责类代码的一致性、性能和概念的完整性。FDD方法采用的开发技术是面向对象，类定义一个单一的概念和实体，最合适作为最小的代码分配要素，代码的所有权即为类的所有权。
特征小组
FDD把类即特征分配给一个确定的开发者。由于一个特征的实现会涉及到多个类及其所有者，因此，特征的所有者（特征组长）需要协调多个开发人员的工作。特征小组与开发小组类似。但有一个重要的区别：特征小组的组长更像是教练而不是超级程序员。
审查
指的是检查软件错误的复审方法，这是FDD确保软件设计和代码质量的一个关键技术。审查将开发小组和FDD以主程序元为主的结构完美地结合起来，这种混合是一种新型的开发方式。
定期构建
定期地取出已完成功能的全部源代码和它所依赖的库、组件，组成完整的可以运行的系统。构建增加功能的基线，确保总是有一个可以运行、向客户演示的软件系统，可以使客户观察到系统开发的进度和实现的功能是否是需要的。
配置管理
一个FDD项目只需要保证对完成的代码文件最新版本的确认和历史追踪。根据开发软件的复杂性，分析制品、设计制品以及测试用例、测试脚本等也应该受控于版本控制。
可视性进度报告
项目成员应该根据完成的工作向各级管理报告工作进度，FDD提供了一个简单、低开销地收集准确和可靠项目信息的方法，提供了大量直观、直接的报告样式，向项目所有相关人员报告项目进度。
隐寓和模型
XP过程以在卡片上记录故事开始业务分析。每个故事就是系统要做的事情。整个项目在“每个人——客户、程序员和经历——能够讲出系统如何工作的整体故事”隐寓的指导下进行的。
FDD使用特征，执行领域走查，同时要建立一个全面的领域对象模型，以便特征小组对每一组特征产生更好的设计。
开发团队
在开发队伍规模上，XP通常不超过10人；FDD的理想团队成员数在16~20人，也有更大团队的实际经验。
代码拥有权
XP鼓励集体拥有代码，任何人都可以在需要时添加或修改代码。与之相反，在FDD中，整个开发团队拥有代码的集体所有权。当需要集体验证譬如说软件架构的设计或用户界面构造的时候，FDD就将类所有者与特征小组和审查结合起来满足需要。
测试
XP利用双人结对编程来不断地在设计和代码层执行走查和非形式化审查。FDD则提倡采用结构化的形式化审查技术。
XP中的正确性是由运行单元和功能测试来定义的。在FDD中，单元测试是“按照功能构建”过程的一个部分。FDD没有定义参与测试的形式化等级，由主程序员决定做什么更适合。
项目追踪
XP让项目经理决定项目追踪方法，鼓励减少数据搜集的工作量，鼓励使用大型图表。在FDD中的按特征追踪项目的方法，描述了工作量小、准确度量项目进度的手段，提供了用数据构造多种使用的进度图表。
作为敏捷开发的方法之一，特征驱动开发很好的实现了敏捷的思想，它强调的是整体模型，是从全局观的角度考虑问题的。同时，我们也要认识到一点，特征驱动开发相对于其他的方法，还是比较复杂的。其方法的精致和结构的规整，很容易让使用者在本身固有的重型思维方式的引导下，走入于agile背道而驰的泥坑。这本身也是其复杂性的一个表现。
因此，要想使用FDD并不容易，但不可否认的一点，FDD的确是一种非常好的敏捷开发方法论。而它具体的实施效果最终还是要看领导者以及实施者、使用者的具体实践。
