Feature-Driven Development(特征驱动开发)

板桥里人 https://www.jdon.com 2006/4/3(转载请保留)

  Feature Driven Development(简称FDD)首先是在《Java Modeling in Color with UML》[Coad]的第六章中介绍的,我们已经在“四色原型”两篇文章中介绍了该书的前几章主要思想,现在我们来谈谈深刻影响我们项目工程的开发方式:特征驱动开发。

为什么需要FDD?

  FDD没有传统工程中冗长的设计过程,而是通过边设计边开发进行迭代完善,因此它非常适合项目的快速开发,由于不断的竞争,现在一个项目的交货周期越来越短,需要在极短的时间内开发一个可维护、可拓展的高质量软件系统已经是形势所逼。

  软件开发人员喜欢新的事情,使用FDD每两周就有新的事情可做,而且每两周就可以交货完成一些工作,离目标越来越近,这种 Closure感觉在开发队伍中是很重要的,可以让大家万众一心,有一种拧在一起的冲劲,从而潜在地提高开发人员的积极性。

  同时,项目经理也会喜欢FDD,通过FDD,他们能够知道规划什么、以及确立关键开发阶段,经理们可以频繁参与项目协调和管理,同时掌握大家的工作成果,从而了解整个项目完成的百分比进度,例如是完成了57%还是其他数字。

  软件系统的客户也回喜欢FDD,他们能够参与或看到开发过程中的关键阶段,能够看见前一阶段的开发结果,以确认和他们要的是否一致,并提出下一步修改意见。

FDD是什么?

  FDD是一个模型驱动( model-driven)、短期遍历(short-iteration)的过程. 注意,FDD是一个开发过程,过程总是有起点和终点,FDD的起点是起源于创建一个全局的模型轮廓(不要求很精确,大概模样就可以),然后大概是两周的一系列的"design by feature, build by feature"的迭代,逐渐丰富模型功能内容,features是指小的、以软件用户的视角看是有用的特征功能,一个FDD开发过程都下图(引自FDD和XP一文)。

  以JiveJdon3.0为例子,它的起初建模是Forum、ForumMessage几个Model,然后我们立即开始开发围绕这些Domain Model的特征功能,这些特征功能一些是以Service形式对外开放的,一些是供内部调用的Manager特征功能,在设计和开发这些Service或Manager时,会反过来修改丰富Domain Model,我们需要分辨哪些特征功能是一种属性Attribute操作,属于属性Attribute的在Domain Model中实现;还要分辨哪些属于Operations行为功能,这些则在Service或Manager中实现,这个过程就是属于下图的“design by feature, build by feature”过程,JiveJdon3.0源码包的大包名主要是Model/Service等,Service相当于分类的特征功能列表,也就是在下图的第二步设计产生的。

  下面详细描述FDD这几个步骤:

1. 开发一个全局的模型

  在一个有经验的组件/对象建模专家(首席架构师)指导下,业务领域需求人员与开发人员一起协调工作,业务领域人员提供一个初始的、具有一定高度的、可以覆盖整个系统和业务场景的介绍,领域人员和开发人员会依此产生初始的模型,然后再结成单独小组,进入详细继续讨论阶段,将模型轮廓描绘出来,然后丰富之前产生的初始模型。

2. 建立特征列表(Feature List)

  当初始模型产生以后,有一个单独小组成员将开始构建复杂的特征(feature)功能列表,特征feature的意思是一段有价值的小功能,体现为下面形式:

  <action> the <result> <by|for|of|to> a(n) <object>

  翻译:什么对象发生了什么结果/什么结果发生在什么对象上/为什么对象发生什么结果/发生了什么的对象的结果。

  说白了,就是动作行为的发生,每个动作行为发生都是由一个对象为主体的,例如:计算订单总和;XX数据的增删改查等,当然,需求文档中的用例或功能要求都是可以作为输入为特征功能列表。

  从这里我们可以看出,特征feature不同于通常一般意义上的功能function,特征feature虽然也是属于功能,但是它是围绕一个对象模型(Object Model)发生的功能,而不是需求文档中混乱的、没有经过整理的功能列表。

  建立特征列表就是将这些功能进行分类、合并和整理,例如功能需求中有:用户注册、用户修改注册资料和用户登录等功能,那么输入到特征功能列表中以后就可能是:围绕对象模型User的新增、修改和删除以及查询等特征功能。

  特征功能是一个个从软件用户角度看有价值的结果,注意是短而有用,比如“建立一个用户子系统”就显得需要很长时间才能完成,不够短,而象“建立表现层”就对于软件用户没有意义,他不懂什么是表现层或业务层等技术术语,他更关心他的功能是否完成,所以建立表现层对于软件用户是没有价值的结果,也不属于特征功能。

  特征功能是软件用户提出的切实的有效的功能,软件用户知道这个软件干什么用,他会识别它的,小的特征功能是在两周内可理解的、可衡量的、可实现的一些功能。

  例如,如下四色图表示了一个特征功能集合:

  特征功能集合是:将一个商品销售给一个客户

  特征功能是一个个小方法:

  1. 计算销售总数
  2. 估算完成销售的时间底线。
  3. 计算被一个客户购买的总数。

  有过JdonFramework等现代框架开发经验的程序员一看就知道,其实四色图中的粉红色MI大部分是使用Service来实现的,或者供内部调用的Manager实现,如围绕Customer模型有CustomerService、围绕User模型有UserService、围绕Message有MessageService等等。

3. 依据特征规划(Plan By Feature)

  下一步工作就是将主要的特征功能集合进行排序和计划,然后分配给主要程序员组长,这时,程序员也会跟着他们在全局对象模型中所负责的类进入相应的程序员小组。例如张三开始是参与Message这个Model构建和规划,那么与Message这个对象模型相关的特征功能列表被分类出来并分配到特定程序员小组时,张三也就是跟着进入这个程序员小组。

4.依据特征设计/依据特征构建(Design By Feature / Build By Feature)

  当每个程序员小组领到自己的特征功能集合后,召集4-5个程序员开会,组长挑选一小组适合2周内完成的特征功能集合,然后执行 'Design By Feature (DBF)' 和 'Build By Feature (BBF)'. 组长将相应的一些类和特征功能分配给小组Team,特征Team进行详细的顺序图设计, 然后写出类和方法逻辑。

  下面是进入依据特征构建阶段,也就是代码的编译调试测试阶段,在进入BBF阶段之前,Team小组要进行设计代码复核,在进入后,类的作者进行类的整合、测试和复核,一旦程序员组长满意,完整的特征功能实现将被提交到主要的Build过程,也就是进入集成测试阶段。

  每个程序员组长可以并行负责带领2-3特征小组Team运转,特征小组中任何人任何时候都可以成为类的作者(编写类的具体实现代码)。

与XP区别

  FDD非常类似极限编程XP,但是有如下区别:

  1. Team的大小:XP设计成2-10人;而FDD设计成16-20人
  2. 建模方式不同:XP是写Story在一个个Index卡片上,项目所有的人(客户经理和开发人员都能知晓系统是如何工作的);FDD使用domain walkthroughs(业务领域通概介绍)和特征任务来替代Story,最大的不同是,FDD多了一个Domain Model对象的设计和开发,Domain Model成为整个项目的指示灯,就象革命队伍中的宝塔红灯。这可注意:这个Domain Model作用可不小,可以减少误解、驱动开发人员进行更加完整、更加丰富下阶段开发,类似革命航线的引路人。
  3. 还有更多区别,可见 FDD和XP一文

参考文章

[book][UML][Peter Coad]Java Modeling in Color with UML

http://www.step-10.com/notes/index.html

更多关于DDD讨论

更多软件工程讨论

发表讨论