特性驱动开发(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处理复杂问题的强大，就是从这里开始的。

3. 按照《 action 》《 result 》《 object 》创建特征列表。习惯上我们将feature翻译为特征，这里更加体现了这个feature是《object》的一些能力，而不是软件的一些功能。软件的功能往往需要一些特征集体发生作用。 实际上在操作的时候，如果整体模型按照正确的原则进行了构造，那么出现一个肥胖的 feature 的机会是很少的。基本上每一个feature的完成都会在2-3天以下，有很多可能就是几个小时，更少的只有几分钟。

4. 主程序员所负责的往往是自己熟悉的和有兴趣的分析类，项目经理没有权利去去给他们分配工作，而不能去指定他们去负责什么类。实际上FDD存在3个主要的关键的管理方面的角色，项目经理、主设计师、开发经理。这3个角色可以由3个人负责，也可以由2个人负责，当然也可以由一个人负责。但是不管如何，这3个角色的任务和工作都是不同的，必须加以注意。而feature必须有具体的人负责，但是注意这必须是在类都有了主人的情况下。

5.上一条我已经表明类的所有者的来历，关键是大家必须理解，任何的agile都不会存在什么详细设计。其实这个阶段的所谓设计，更多的是要找出一个feature是会涉及到什么类，而各个的类主人会按照什么协议参加到这个feature的建造中来，什么时间这些人可以参加到这个feature中来，以及他们之间的协议如何可以得到检查实施。

6.这个阶段相对任务比较明确，但是切记不要把所谓的传统软件工程的方法影响到其中，所谓的复审和评审都是不应该进行的，而是应该使用tdd和pp这样更加有效率的做法。特别是由于存在主程序员，pp完全可以在上一个阶段的头脑风暴中进行。可以说设计和构造阶段其实更多的时候不是没有明确的区分界限的，或者说设计阶段更多的时候是没有一个明确的阶段的。这其实体现了agiler一般喜欢的持续设计风格。

 

至于作者最后问的问题，根本就不是问题，是他对于FDD的角色和迭代不理解造成的误解。 至于里程碑，在 FDD 中是很容易确定的，每一次迭代都应该是一个里程碑，而每一次提交给客户更加应该是一个大的里程碑。所谓的计划，其实就是确定 feature 优先实现级别，而这个优先实现级别其实就是来着客户的功能优先列表。这里的两个列表都是动态的，是会经常性的做出调整的，并且很多复杂情况下分析模型也是会有调整的，可能会出现更多的分析类，也就是说主程序员的负责的类会根据情况进行调整。

FDD其实是一个比较复杂的体系，至少我认为比RUP并不简单。FDD中有许多策略和技术方面的问题，不是那么容易理解。可以说FDD是为职业程序员预备的专业开发方法。其实任何一直agile都是职业程序员的开发方法，一般情况下应该存在一个教练的角色，主设计师往往就是承担这个角色。

 

我强调整体模型不是需求模型，是基于几点考虑。

1、一个项目是否允许你在开始的时候能从容的建立一个整体的模型？至少从我面前对于国内的软件开发行业的客户来看，他们是不会给你这个机会的。因此绝大多数情况下，是在你开始进行这个项目前，这个模型就应该已经存在了。那么这个模型显然不是来自于具体化了的“需求”，而是来自更加宽泛化的“领域”。实际上我更加愿意称他为领域模型或者领域分析模型。

2、由于1的观点，同时再考虑到大多数的开发团体，都是在一个比较固定的领域范围内部进行工作。他们的工作应该能，也应该进行一定程度的积累。而这个领域分析模型，就是一个很好的介质。

3、由于领域分析模型非常强调于领域中出现的概念，因此以此为基础可以更加好的而简单的建立其对于领域的认识。而如果过多的从更加关注流程的需求入手，则复杂性和可认识性会大幅度降低。同时也应该明白，由于领域分析模型是FDD团队组织结构的基础性依赖，保持一个相对稳定的模型是非常必要的。

 

而这里一个关键的容易产生错误认识的点就在于， 将这领域模型系统化到具体的软件结构系统中去，也就是你说的所谓“系统模型图”。

而在我们具体的实践中，往往开发团队的所使用的系统构架architecture是另外一个相对稳定的体系，并且这个体系也如同那个领域分析模型一样有很多类似的特点。因此完全可以在他们两个的基础上进行总计和提炼，建立一个更加针对化的快速开发框架。而一旦将两种结构混淆，那么本已经复杂的业务和系统结构，将会变得更加复杂和难于认识。同时也应该明确，如果业务同具体的技术实现过于紧密的耦合在一起，将会在今后的开发过程中造成业务的改变必须调整技术结构的后果。

 

而如你看我上面关于FDD的阐述，你会发现 FDD 在实现和实施层面有大量的陷阱和必须使用的技巧。这些方式和方法，是仅仅凭看书和思维不能体会到的。而即使有这个方面的培训，如果没有真正熟悉这个方法操作的人做现场过程的指导，也是很难一下子体会到其中的奥妙的。

同时我们也应该明白，agile的方法体系，很多说法所代表的内容和传统的观念还是有些区别。特别是FDD，方法的精致和结构的规整，很容易让使用者在本身固有的重型思维方式的引导下，走入于agile背道而驰的泥坑。这本身也是其复杂性的一个表现。