FDD; 它的过程和与其他敏捷方法论的比较

我们已经讨论过测试驱动开发和行为驱动开发 ,所以我想,为什么不涵盖功能驱动开发主题? 实际上,关于FDD的讨论并不多,可以说极限编程,Scrum和测试驱动开发绝对是当前最受欢迎的敏捷方法,但是在Apiumhub上 ,我们也非常重视FDD。

从显而易见的功能驱动开发开始?

首先,我要提到FDD是Jeff Luca在90年代后期创建的。 他实际上是在尝试向银行提供软件开发解决方案。

FDD是一个开发过程,与所有敏捷方法一样,它是迭代的和增量的,目的是交付工作软件。 FDD结合了最佳实践,这些最佳实践都是由对客户重要的事物驱动的。 这意味着开发人员专注于客户端重视的功能,他们期望的功能。

假设使用FDD,功能对于Scrum来说和用户故事一样重要。 在计划工作时,这将对开发人员有所帮助。

正如我前面提到的,Jeff Luca是FDD的创建者。 他提出了一个包含五个过程的解决方案,涵盖了模型的开发,模型的列出,设计,计划以及功能的构建。 因此,为了更好地理解FDD的5个基本过程,显然会有所帮助。

FDD的5个流程的更详细概述

一旦我们完成了整个过程,您将很快意识到首席程序员在功能驱动开发中扮演着非常重要的角色。 首席程序员几乎与首席开发人员相当,需要具备技术技能和领导才能,才能领导跨职能的开发团队。 另一个非常重要的角色是域专家,因为他与Scrum中的产品所有者的职责非常相似,尽管并不完全相同。

第一步:建立整体模型

在第一个过程中,FDD推动团队构建领域问题的对象模型。 与其他不同,FDD建模是跨功能,迭代和协作的活动。 团队成员(开发人员,领域专家和首席程序员)一起工作,以组成领域领域的模型,并由首席架构师指导。 想法是让不同的团队提出不同的模型,然后在经过审查后,选择一个选项或将它们混合在一起。 最后,领域区域模型将合并到整体模型中。

实际上,这是启动项目的好方法,因为它使团队能够对项目有深入的了解并保持良好的沟通。

第二步:建立功能列表

在这里,您可以将功能列表与scrum中的产品待办事项列表进行比较,而该功能将是某种用户故事。 在准备好总体模型之后,根据在该阶段获得的知识,我们将必须确定对客户有价值的功能,这些功能将从根本上指导项目。 完成功能的时间不应超过两周,如果完成,则应将其放入多个功能中。 它们通常表示为动作,结果和对象。

第三步:按功能规划

顾名思义,在第三阶段中,它或多或少与计划功能实现的顺序有关,而与组织有关。 然后将功能集分配给程序员。

显然,在规划时,我们考虑了不同方面,例如风险,复杂性依赖性,团队工作量等。

第四步:按功能设计

在所有过程中,我们都使用从第一个建模过程中获得的知识。 首席程序员负责选择下一步应开发的一组功能。 他还必须确定将涉及的域类。 组建功能团队后,他们将开始共同努力以完成工作,领域专家将负责分析和设计每个功能的解决方案。

第五步:按特征建造

领域专家完成工作并基于按要素进行设计过程中完成的工作后,

类所有者必须实施所有必要的项目以支持设计。 因此,我们处理已经开发的代码,并对其进行单元测试,并对其进行检查,以确保所有代码正确无误并得到首席程序员的认可,然后才可以开始构建。

如何比较FDD,XP编程和Scrum?

因此,我们使用Scrum, XP proramming ,FDD等,所以我认为对这三者进行简要比较可能很有趣。Feature Driven Design 既有一些极限编程,也有一些Scrum,但增加了一些域驱动设计技术。 很棒的是,使用FDD在大型团队中工作非常容易。 实际上,它具有极高的可扩展性。

如果您有兴趣,这里是 Scrum,Kanban和Scrumban 的比较

通讯; 口头和书面

我们都知道,敏捷方法非常重视团队与其他参与人员之间的沟通。

在XP编程和Scrum中,文档很重要,但是它并不会促使团队付出很大的努力,也不会促使他们更努力地与项目中暗示的其他人员进行口头交流。 使用FDD有点不同,因为他们实际上认为应该对文档进行处理。

以用户为中心的方法?

软件或至少应该以用户为中心的方法来设计和开发软件。 例如,使用XP编程,您需要在开发过程中需要用户的参与,因为我们的迭代很短,而工作软件总是由用户测试的。

在功能驱动开发中,最终用户也参与了该过程,但是以不同的方式,它实际上是在报告过程中。 在Scrum中,最终用户并没有真正参与其中,而是产品所有者被视为最终用户。

冲刺的长度

这当然不是一般的规则,但是总的来说,正如我们在FDD中提到的,短路越好。 假设一次冲刺将在2到10天之间。 这与Scrum(需要2到4周)和XP编程(最多可以持续6周)不同!

会议呢?

显然,由于沟通很重要,因此会议对于敏捷方法很重要。 使用Scrum&XP编程,每天都有所有团队成员参与的会议,他们讨论项目并共同决定项目的进行方式。 这些会议通常是非正式的和快捷的。

与FDD的区别很大,因为通常信息将通过文档进行传达。

该项目能发展到多大?

在选择敏捷方法论时,实际上这完全取决于项目要求。 例如,对于不复杂的小型项目,可以轻松进行XP编程。 当涉及到更复杂,更大的软件项目时,建议使用Scum&FDD。

那么FDD有什么优点呢?

  • FDD对于大型项目而言是惊人的,实际上具有相当的可扩展性,并且很容易获得成功。
  • FDD在帮助处于紧急状态的复杂项目方面非常有效。
  • 前面提到的5个过程在使新成员加入团队方面有帮助,特别是在短时间内。
  • 功能驱动开发基于业界公认的最佳实践,并考虑了开发人员的优缺点。
  • 使用FDD进行常规构建的事实确保了系统始终是最新的,并且可以显示给客户端。 您可以轻松地识别功能源代码中的错误。
  • 在整个过程中,由于在项目的各个级别上都会进行频繁的进度报告,因此您对进度和结果的关注度很高
  • 开发总体模型的第一个过程使我们对项目的范围和上下文有深入的了解。
  • 您对需求和期望有了更深入的了解,我们进行了小规模的迭代,并逐个构建了较小的零件,这实际上意味着降低了风险。 减少不必要的惊喜!