特性驱动开发 FDD

特性驱动开发简介

驱动开发(FDD)是一种面向过程、以客户为中心的敏捷软件开发模型,它根据客户价值的特征开发软件。与其他敏捷模型一样,它也具有自适应和增量性质,可以在短迭代中实现所需的功能。FDD主要关注软件开发的设计和构建方面,更强调质量。

FDD最初由Jeff De Luca设计,以满足1997年新加坡一家大型银行为期15个月、团队规模50人的软件开发项目的特定需求。这产生包括整体模型开发、功能的列出、规划、设计和构建在内的一组过程。第一个过程在很大程度上受到Peter Coad的对象建模方法的影响。第二个过程结合了Coad的思想,即使用特性列表来管理功能需求和开发任务。其他过程是杰夫·德·卢卡经验的结果。自从FDD在新加坡项目中成功使用以来,它已经实施很多次。

FDD的描述最早是在Peter Coad、Eric Lefebvre和Jeff De Luca于1999年出版的《Java Modeling in Color with UML》一书的第6章中介绍给世界的。后来,在Stephen Palmer和Mac Felsing的《功能驱动开发实用指南》(2002年出版)一书中,对FDD进行了更一般的描述,将其与Java建模脱离

FDD中的活动

FDD包含了每个迭代都要执行的5个关键的活动。

全局建模

在一位经验丰富的对象建模师(首席架构师)的指导下,与领域专家和开发成员一起进行的项目维度初始活动。最初要以系统范围以及背景的顶层走查开始,然后对每个要建模的区域进行详细的域遍历,并面向对象构建全局模型,目标是识别和理解目标待构建系统所处理的特定领域的基础信息。

在每次领域演练之后,由领域和开发人员组成的小组将组成,然后他们组成自己的模型来支持该领域演练。每个小组都展示了他们的模型,供同行评审和讨论。通过协商一致的方式选择所提出的模型之一或模型的合并,从而成为该领域的模型。执行域区域模型到整体模型的合并,根据需要调整模型形状。

然后通过特征设计过程#4用内容迭代地更新对象模型。

  • 准入条件:

领域专家、首席程序员以及首席架构师就位。

  • 任务:

组建建模团队

项目经理

必须

建模团队由来自领域专家和开发团队的常驻成员组成,特别是领域专家和首席程序员。然后,其他项目工作人员轮流参加建模会议,这样每个人都有机会参与并看到过程的进展。

领域遍历

建模团队

必须

领域专家对要建模的领域区域进行概述。这还应包括与该领域相关的信息,但不一定包含执行层面的信息

研究文档

建模团队

可选

团队研究可用的参考或需求文档,如对象模型、功能需求(传统或用例格式)、数据模型和用户指南。

构建模型

分组后的建模团队

必须

划分不超过三个小组,每个小组将构建一个模型来支持领域需求。首席架构师可以提出一个“strawman”模型来促进团队的进展。每个小组中的一名成员向该小组展示针对业务领域提出的模型。首席架构师还可以提出进一步的模型替代方案。建模团队选择一个模型提案,或者通过合并模型提案中的想法来构建模型。

细化全局对象模型

首席架构师,建模团队

必须

每隔一段时间,全局对象模型就会用上述构建模型”任务,基于迭代产生的新模型进行更新。

编写模型记录

首席架构师,首席程序员

必须

对详细或复杂的模型形态以及重要的模型备选方案进行记录,以供项目未来参考。

  • 审查

内、外部评估

建模团队,业务

必须

内部或自我评估是通过领域专家的积极参与来实现的。在必要的基础上,外部评估是通过向企业(用户)提交对影响模型的问题的批准或澄清来进行。

  • 准出标准
  • 过程的输出物是对象模型
  • 以模型形态的类图。也就是说,域中有哪些类,它们是如何相互连接的,以及在什么约束下。
  • 已识别的方法和属性被放置在类中。
  • 序列图(如有)。
  • 模型注释,以捕捉选择特定模型形态的原因和/或考虑了哪些替代方案。

构建特性清单

基于初始建模过程中汇集的信息,通过把功能从业务领域分解为更小的主题域生成一份特性清单。特性清单根据主题域中的业务活动以及其中的各个步骤进行分类。特性通过‘行为’‘结果’‘目标’这样的格式来体现功能所承载的用户价值,并且完成它的时间不应该超过2周,否则就需要拆分成更小的切片。

  • 准入条件:

领域专家、首席程序员以及首席架构师就位。

  • 任务:

组建特性清单团队

项目经理,开发经理

必须

团队包含了在步骤#1中建模团队的首席程序员。

构建特性清单

特性清单团队

必须

团队应使用从步骤#1领域专家对业务领域的划分获得的知识进行简单功能分解以构建特性清单。它被分解为包括业务活动的主题域,这些业务活动包括业务活动步骤,并使用此命名模板以客户价值术语表示:<action><result><object>

根据一个特性不超过两周完成的规则,特性的颗粒度是较小的。两周是上限大多数特性所需的时间都少于此时间。当业务活动步骤看起来大于两周时,该步骤会被分解为较小的步骤,然后转化特性

  • 审查

内、外部评估

特性清单团队,业务

必须

内部或自我评估是通过建模团队的积极参与来实现的。在必要的基础上,外部评估是通过向企业(用户)提交对影响特性清单的问题的批准或澄清来进行。

  • 准出标准

该过程的输出特性清单:

  • 主题域清单
  • 每个主题域内的业务活动清单
  • 满足上述业务活动特性

基于特性规划

在特性清单完成后,下一步就是产出交付计划并且为每个特性(或者特性集)指定负责人,为类指定开发者。

25%

项目经理、开发经理和首席程序员根据功能依赖、整个开发团队的负载以及要实现的功能的复杂性来规划功能的实现顺序。这个过程中的主要任务并不是产出一个严格的开发序列。像许多计划活动一样,它们作为整体考虑但是是一个或多个任务的梳理完成后再考虑其他任务。一个典型的场景是考虑开发顺序,然后考虑将业务活动分配给首席程序员,在这样做的过程中,考虑将哪些关键类分配给哪些开发人员(记住,首席程序员也是开发人员)。当实现了这种平衡,业务活动的开发顺序和分配基本上完成了,类的负责人也指明了。

  • 准入条件:

特性清单完成。

  • 任务:

组建规划团队

项目经理

必须

团队包含了开发经理和首席程序员。

决定开发序列

计划团队

必须

计划团队应指定完成每项业务活动的日期(具体到月份和年份即可)。业务活动和完成日期以及开发顺序的识别基于

  • 根据所涉及的类,功能之间的依赖关系
  • 平衡类负责人之间的负载
  • 要实现特性的复杂性
  • 推进处理高风险或复杂业务活动
  • 考虑可见的任何外部里程碑,如测试版、预览、反馈检查点和满足各个里程碑的“整个产品”。

将业务活动指派给首席程序员

计划团队

必须

规划小组应基于下述条件指定首席程序员作为对应业务活动的负责人:

  • 开发顺序
  • 所涉及的类,特性之间的依赖关系
  • 平衡类负责人之间的负载(记住,首席程序员也是类所有者)
  • 要实现的特性的复杂性。

将类指派给开发者

计划团队

必须

规划团队应基于以下条件将开发人员指定为类所有者开发人员可以拥有多个类

  • 平衡开发人员之间的负载
  • 类的复杂性
  • 类的使用情况(例如高使用率)开发顺序。
  • 审查

自评估

计划团队

必须

规划是一项团队活动,通过首席程序员、开发经理和项目经理的积极参与来实现自我评估。

  • 准出标准

该过程的输出是开发计划,包括

  • 具有完成日期的业务活动(月和年)
  • 分配给业务活动的首席程序员
  • 主题域的完成日期(月和年)源自其各自业务活动的最后完成日期
  • 类和对应负责人的列表

基于特性设计

首席开发者为后续两周的选择一组要完成开发的特性,与类的负责人一起为每个特性绘制详细的序列图并且细化整体模型,完成类和方法的简介并最终完成设计评审。

这是按每个特性来产出对应特性设计包的活动,通过将特性清单分配给首席程序员来制定开发计划。

首席程序员从被分配特性的“收件箱”中选择要开发的特性。他可能会选择碰巧使用相同类的多个特性,通常情况下,首席程序员会安排一次开发“一组”特性,这样的集合被称为首席程序员工作包。

然后,首席程序员通过确定可能参与开发他选择用于开发的特性的类(开发人员)的负责人,组成一个特性团队。然后,该团队为被指派特性生成序列图。其次,首席程序员根据序列图的内容细化对象模型。后,开发人员编写类和方法的简介,以进行设计检查。

  • 准入条件:

规划活动完成。

  • 任务:

组建特性团队

首席程序员

必须

首席程序员确定可能进入设计的一组特性中的类,并相应地更新特征数据库。从类负责人列表中,首席程序员确定了组建Feature团队所需的开发人员。作为该步骤的一部分,首席程序员为特性创建一个新的设计包,作为工作包的一部分

领域遍历

领域专家

可选

领域专家针对要设计的特性业务领域提供概要的信息。这还应该包括与特性相关但不一定要实现业务领域信息。这是一项基于功能复杂性和或其对应的交互可选任务。

研究参考文档

特性团队

可选

特性团队研究要设计的功能的参考文件,包括所有确认过的备忘录、界面设计、外部系统接口规范和任何其他支持文件。这是一项基于功能复杂性和/或其交互的可选任务。

开发序列图

规划团队

必须

开发即将设计的特性所需的序列图。应将图表文件检入版本控制系统。任何备选设计、设计决策、需求澄清和注释也记录在设计包的设计备选部分中

细化目标模型

首席程序员

必须

首席程序员为特性创建一个特性团队区域。该区域是文件服务器上的一个目录,或者是由首席程序员根据需要备份到服务器或使用版本控制系统中的工作区域持的他们的PC上。特性团队区域的目的是可以共享正在进行的工作,并且特性团队中可见,对项目的其他部分不可见。

首席程序员根据为特征定义的序列图,对模型进行细化,以添加额外的类、方法、属性和/或对现有类、方法或属性进行更改。首席程序员以可发布的格式创建模型图。这些文件应检入版本控制系统,并提交在项目内部网上发布

编写类和方法简介

特性团队

必须

使用共享特性团队区域中“细化对象模型”任务中更新的实现语言源文件,每个类的开发负责人特性和序列图定义的每个项编写类和方法序言。这包括参数类型、返回类型、异常和消息。每个开发人员完成此任务后,首席程序员使用<您的工具>生成API文档,并将其提交到项目内联网上发布。

  • 审查

设计评审

特性团队

必须

特性团队成员或其他项目成员一起进行设计评审是否特性团队内部还是与其他项目团队成员一起检查由首席程序员决定。接受后,每个受影响的类都会生成一个待办事项列表,每个团队成员都会将自己的任务添加到日历任务列表中。首席程序员还必须将共享特性团队区域的变更合并到变更控制系统中。。

  • 准出标准

该过程的输出是一个通过评审的设计包包括

  • 一份包含了备忘录或文档,对设计包进行整合和描述,使其可以独立供评审。
  • 文件形式的需求参考(如有)以及所有相关的确认备忘录和援引文件。
  • 序列图。设计备选方案(如有)
  • 具有新的/更新的类、方法和属性的对象模型。
  • 基于设计创建或修改的类和方法简述
  • 每个团队成员的受影响类上的操作项目的日历/待办任务列表条目。

基于特性构建

设计评审通过以后将产出特性计划,类的负责人完成代码开发、单元测试以及通过代码评审,完成的特性将合并入主分支。

按特性进行的活动,目标是产生一个完整的客户价值功能特性)

从设计包开始,类负责人实现其类所需的各项内容,以支持此特性的设计。开发的代码随后进行单元测试和代码检查,其顺序由首席程序员决定。通过代码评审后,代码将升级为内部版本。

  • 准入条件:

“按特性设计”过程已完成。也就是说,设计包已经成功地通过评审。

  • 任务:

实现类和方法

特性团队

必须

负责人实现必要的项,以满足特性中的具体需求。

代码评审

特性团队

必须

在单元测试任务之前或之后,将与特性团队成员或其他项目成员一起进行代码评审,如何实施由首席程序员决定。

单元测试

特性团队

必须

负责人测试他们的代码,以确保类的所有需求。如果必要,首席程序员需要确定需要特性团队级单元测试。也就是说,如果需要为完成特性需求所开展的任何跨类测试。

升级到内部版本

首席程序员,特性团队

必须

只有在成功通过代码评审之后,才能将类合并到版本中作为整个特性的集成首席程序员通过开发人员的反馈来跟踪正在合并的各个类

  • 审查

代码评审以及单元测试

首席程序员,特性团队

必须

成功的代码检查加上成功完成单元测试就是对该过程输出的验证。代码检查和单元测试任务如上所述。

  • 准出标准

该过程的产出

  • 已成功进行代码检查的类和/或方法。
  • 已升级到内部版本的类。
  • 完成的具有客户价值功能(特性

 

最佳实践

领域对象建模。领域对象建模包括探索和解释要解决的问题的领域。由此产生的域对象模型为后续添加功能提供了一个整体框架。

基于特性开发。任何过于复杂而无法在两周内实现的功能都会被进一步分解为更小的功能,直到每个子问题都小到可以称为特性。这使得提供正确的功能以及扩展或修改系统变得更容易。

独立类(代码)专属负责独立的类专属负责意味着将不同的代码片段或代码分组分配给单一的负责人,其负责类的一致性、性能和概念完整性。

特性团队特性团队是一个动态组成的小型团队。每个设计决策总是要考虑多个因素,并且在选择最终方案之前要评估多个设计提案

检视。主要通过检测缺陷来确保良好的设计和规范质量。

配置管理。配置管理有助于识别迄今为止已完成的所有功能的源代码,并在功能团队增强类时维护类变更的历史记录。

定期构建。定期构建确保始终有一个最新的系统可以向客户演示,并有助于尽早暴露特性源代码集成错误。

进度和结果的可见性管理层根据已完成的工作,从项目内外的各个层面使用频繁、恰当和准确的进度报告来指导项目。

FDD中的角色职责

FDD定义了6个关键的项目角色:

  • 项目经理。作为项目的行政领导,负责汇报进度、管理预算、争取人员、管理装备、空间和资源等。
  • 首席架构师。负责系统的顶层设计。在FDD中,架构师需要负责在团队共创系统设计师组织设计环节的研讨,并最终确认架构设计。作为资深的技术角色,需要优秀的技术和建模能力,同样也需要良好的引导技巧。
  • 开发经理。负责管理日常的开发活动。开发经理兼具引导和技术能力,负责在首席程序员无法在团队中处理时,解决每天的资源冲突。在某些项目中,这个角色会有与项目经理或者首席架构师兼任的情况。
  • 首席程序员。作为经验丰富的开发者在软件开发全生命周期中贯穿始终。既要参加顶层需求分析和设计活动,也负责领导3~6人开发者组成的小团队进行新特性的细节分析、设计和开发工作。首席程序员也要与其他的首席程序员一起解决日常的技术和资源问题。
  • 类负责人。作为小型开发团队的开发人员,按照首席程序员提供的规范对于新软件系统的特性需求进行设计、编码、测试和归档等工作。
  • 领域专家。是用户、客户、投资人、业务分析师或者融这些角色于一身的人。他们用其掌握的深度业务知识向开发者针对不同层面的需求细节进行澄清。他们是开发者交付正确系统所依赖的基础信息来源,对于构建系统成功与否他们的知识和参与度非常重要。

支持性角色:

  • 领域经理。
  • 发布经理。
  • 语言权威。
  • 构建工程师。
  • 工具专家。
  • 系统管理员

额外的角色:

  • 测试工程师。
  • 部署工程师。
  • 技术文档工程师。

 

 

本文编者:钟润杰(Roger)

参考文献:

https://www.se-radio.net/2008/01/episode-83-jeff-deluca-on-feature-driven-development/

http://www.featuredrivendevelopment.com/

https://curlie.org/Computers/Programming/Methodologies/Agile/Feature_Driven_Development

https://agilemodeling.com/essays/fdd.htm

Palmer, S.R., & Felsing, J.M. (2002). A Practical Guide to Feature-Driven Development

Zahid Nawaz, Shabib Aftab, Faiza Anwer. September 2017International Journal of Modern Education and Computer Science 9(9):53-59DOI:10.5815/ijmecs.2017.09.06. Simplified FDD Process Model 

 

火爆 售票中
Scrum.Org 主办
搜索
近期公开班
safe scrum master
8月10-11日
SAFe ScrumMaster 官方认证公开班
Eric Liao 廖靖斌 授课