敏捷开发--特性驱动开发(FDD)

什么是Feature:

The unit of development and thus an increment in an FDD project - a feature - is tiny; … Features (tiny, granular pieces of client-valued function) are being completed every week in an FDD project。特性Feature作为一个开发单位，也是FDD项目中的一个增量，是指“用户眼中最小的有用的功能”， 可以在1周内实现。

特征驱动开发定义：

特征驱动开发（FDD-Feature Driven Development）方法是敏捷软件开发过程中的一种，是由Jeff de Luca 、Eric Lefebvre、Peter Coad共同开发的。 它强调特性驱动，快速迭代，即能保证快速开发，又能保证适当文档和质量，非常适合中小型团队开发管理。它提出的每个功能开发时间不超过两周，为每个用例 user case 限定了粒度，具有良好可执行性，也可以对项目的开发进程进行精确及时地监控。它抓住了软件开发的核心问题领域，即正确和及时地构造软件。 FDD 还打破了传统的将领域和业务专家 / 分析师与设计者和实现者隔离开来的壁垒。 分析师被从抽象的工作中解脱出来，直接参与到开发人员和用户所从事的系统构造工作中。

FDD过程：

FDD 是一个模型驱动 ( model-driven) 、短期迭代 (short-iteration) 的过程。 注意，FDD是一个开发过程，过程总是有起点和终点，FDD的起点是起源于创建一个全局的模型轮廓（不要求很精确，大概模样就可以），然后是周期低于两周的一系列的"design by feature, build by feature"的迭代，逐渐丰富模型功能内容。一个FDD开发过程如附件1图所示。
其由5个活动组成：

1. 开发一个全局的模型 （Develop an Overall Model）
       四色原型（http://www.jdon.com/mda/archetypes.html）
       领域驱动设计

2. 建立特征列表（Build Feature List）

在此采用下述格式进行描述：

- 针对功能： <action>the<result><by | for | of | to>a(n)<object>

- 针对功能集：<action><-ing>a(n)<object>

- 针对主功能集：<object>management

3. 依据特征规划(Plan by Feature)
      
4. 依据特征设计(Design By Feature)

5. 依据特征构建(Build By Feature)

FDD中的角色

1. Domain expert(s) ：领域专家

2. Chief Architect(s) ：首席架构师

3. Chief Programmer(s) ：主程序员

Feature Team一般由Domain expert ，Chief Programmers，Class Owners组成，一个Chief Programmers可以带领多个Class Owners。

FDD相关的度量

采用FDD方式进行开发时，各阶段成本的分配大致如下所示：

1. 开发一个全局的模型 （Develop an Overall Model）10% Initial, 4% on-going

2. 建立特征列表（Build Feature List） 4% initial, 1% on-going

3. 依据特征规划(Plan by Feature) 2% initial, 2% on-going

4. 依据特征设计和依据特征构建 77%（2周迭代一次）

FDD的最佳实践

• 持续集成Continuous Integration.

• 对领域（业务）对象建模Domain Object Modeling.

• 按特性开发Developing By Feature.

• 类的所有者Individual Class ownership.

• 按特性组织团队Feature Teams.

• 源代码控制Source Control.

• 汇报/结果可见性Reporting/Visibility of results

观点汇集：

1.        在FDD中，它认为： 只有良好定义的并且简单的过程才能被很好地执行。
2.        不过FDD由于必须有2个关键的人物—— 首席构架师和首席程序员，因此门槛并不低。同时由于FDD的客户参与度可以做的很高，那么团队的文化很容易受到其客户的文牍主义的影响。 并且由于 FDD 的前期工作可能会很长，因此也很容易被人们搞成一场打着敏捷旗帜的重型方法会展。不过好在如果你提前意识到这三个方面的问题，它们就可以预防。

Ozzzzzz：

首先FDD没有强求你使用color UML，但是我实在找不出比这个方法更加简单明了的领域建模的方法了。 问题领域内被认为存在四种类的模版，粉红的 Moment/Interval, 黄色的 Role ，绿色的 PPT （ Party,Place,Thing ），蓝色的 Description 。而 Domain Neutral Component 是一种在业务系统中反复出现的模式，用我的话来说就是什么人在一个什么时间以一种什么身份做什么样的事情。我相信有的人可能不知道什么是名词，但是他也能把一件事情按照上面的格式来表达。当初我曾经交给我的客户使用CRC卡片建模，他们并没有觉得有什么复杂。而当我给他们color UML的时候，客户觉得比CRC还简单明了，并且感觉自己也可以做一个程序员。

而 Feature——<action><resule><object> ，也非常简单明了。不过很多人会误解Feature是一种表达需求的手段，就如同Use Case和Usestoris一样， 其实他们都是对于需要的分析手段。只不过Feature更加靠近程序，而Use Case更加靠近业务，Usestory则可以被使用在这两种风格——但是一个Usestory只有一个风格。也就是说 一个 Use Case 或者 Usestory 可以用几个 Feature 来进行构造。更加奇妙的是使用Feature可以很量化的表示你的开发进度，领域走查1%，设计40%，设计审查3%，编码45%，代码审查10%，提交构造1%。当然你可以根据你组织的具体情况来调整这个数据，不过只要你不是太频繁的调整，那么任何人都能够即时的知道你究竟过的好不好。 使用 Feature 你会发现客户可以直接理解你程序的结构和进度，而不仅仅是通过你提交的文档的估计。当然这个能力对于很多习惯作假的人是深恶痛绝的。

同时我们会发现 如果长期使用 FDD 在一个领域或者几个相关领域进行程序开发，那么领域模型会愈来愈固定，而以此为基础的人员会愈来愈成为某个方面的专家。同时更多类似的Feature，会频繁的出现。以至于当你仅仅使用以前的Feature就可以分析出现在的客户业务存在的问题。也就是说使用color UML和Feature不仅仅可以对需求进行整理，还可以对业务进行整理。

而且如果你够敏感，你会发现FDD被称为Processes。确实FDD第一次的使用就是在一个大型的项目，并且最后结果很成功。并且就 如同 Lean 一样， FDD 这里大型项目的例子非常多 —— 无论是从代码的数量，需求的复杂，参与的人员数量，进行的时间，这些方面来说大型项目并不是 FDD 所欠缺的。而在小型和中型项目上，FDD由于可以很好的记录经验，也可以取得很好的效果。同时 由于 FDD 的过程太少了（才 10 页 A4 ），因此很少有人有对他做裁剪的欲望。同时这个方法使用的技术也够简单明了，也很少能够被人所非议是不是不容易学习掌握。不过确实FDD的内容没有包括SCM和coding方面的内容，但是你可以结合XP的持续集成，TDD，重构来完善他。而且由于Feature的结构统一，以其为基础构造Test Case是更有指引性。况且由于FDD使用温和的代码责任，你也不会产生过分重构的问题。而由于Feature的粒度统一，对于控制check in和check out也方便，因此至少做到每日构建是容易做到的。

colorUML其实可以用一句话来表达。

任何的需求（其实任何的事情）都可以表现为 :
什么人（或者事物） 在一个什么时间（或者什么时间段） 以一种什么方式 做了一种什么样的行为。
当然你还可以使用不同的时态来构造这个表达。其实这是我们语言上陈述句子的基本形式，当然你可以使用oo的方式来构造。不过我觉得fp的基本要素也孕育在其中了。也就是说这个基本的模式，其实oop和fp都是这个基本现实形态的一个投影。

开发一个全面模型

Jeff De Luca认为，与其它敏捷方法相比， FDD 在初始阶段（开发一个全面模型）允许项目团队掌握整个项目，以便回答诸如“项目还剩多少没完成”之类的问题：
如果我们完全是纯粹的增量迭代开发——即仅限于迭代内的需求与分析——那么，我们当然很难回答“整个项目我们进行了多少”，以及“项目还有多少没完成”。因为我们还没有浏览过剩下的需求呢。所以一开始一定要做一些信息收集或分析活动，以便我们了解并设定可以跟踪和反馈的基线，这样我们就可以回答上面的问题了。 FDD 是唯一一个能够正确做到这一点的敏捷方法。
在这一阶段的这个问题上可以看作是 大量预先设计（ Big Design Up-Front ， BDUF ）：
并不是做BDUP那种被人鄙视的“全面预先设计”，而是做“ 恰好够用的设计”。同时还应注意，在FDD中的这个第一项活动不但包括高层次的设计，也包括需求及需求分析。

Ozzzzzz：

1. FDD 是迭代开发，这一点必须加以强调。
2. 整体模型更大程度上是分析模型，而不是需求模型。更多的涉及的是会出现什么东西，而不是会实现什么能力。这个模型是更多的是从业务分析角度出发，而不是从软件系统实现角度出发。这个整体模型不是构架，而只是部门内容是构架的一个部分。这一点非常重要，基本上FDD处理复杂问题的强大，就是从这里开始的。