敏捷(Scrum)和功能点(FPA):朋友还是敌人?

2021-11-22 12:18:23 浏览数 (2)

功能点有多敏捷?

许多组织已经了解到,通过使用功能点对其进行估计,他们可以更好地控制软件项目。同时,我们看到越来越多的组织采用敏捷的工作方式,通常是通过应用 Scrum。最大的问题是功能点是否仍然存在。

  • Scrum 是否将他们抛到了一边?
  • 或者功能点在敏捷世界中仍然有价值吗?

敏捷/Scrum

越来越多的组织采用敏捷(Scrum 作为最常用的方法)作为大型 IT 项目的解决方案。通过开始直接交付软件,客户每两周就会直接了解进度和附加值。用户不再需要等待具有最高业务价值的功能。

此外,持续的反馈流导致有价值的系统运行得更快。事实上,通过使用 Scrum,一个重大的 IT 项目被切割成许多小项目。这使得对新见解的响应变得更容易,并极大地降低了整个项目的复杂性。

Scrum 以截然不同的方式处理系统规范。产品只用一般术语描述(称为产品待办列表)。然后,首先只详细制定那些具有最高商业价值的部分,并快速交付这些部分。在此交付之后,再次确定、开发和交付最高业务价值,依此类推。以这种方式可以进行不断的调整。这取代了交付预定义结果的项目的原始想法。对整个交付范围的估计不再有意义,仅仅是因为不再详细计算整个范围。地平线上的位置可以随时移动。

摩擦

Scrum 处理估算和预算的方式与更传统和系统的方法不同。传统方法通常使用功能点分析 (FPA) 进行量化。FPA 用于估算制作软件的成本以及交付所需的时间。功能点用作衡量系统规模的指标。这种调整是根据功能规范完成的。FPA 需要一定程度的详细说明您将要制作的内容。

所以看起来功能点和 Scrum 不适合在一起。毕竟,第一个想要提前完整的规范,另一个想要随时质疑和更新规范,并没有详细说明。Scrum 方法中的冲刺太短且变化太大,无法根据功能点进行估计。这意味着敏捷会在 IT 支出中造成无政府状态,在敏捷组织内部,也需要控制成本。“我们最终会看到它的成本是多少”对于大多数组织来说是不可接受的,客户也需要控制。产品负责人希望保持对所有这些努力的结果(目标)以及最终花费了多少时间和金钱(预算)的概览。而这正是传统 FPA 提供解决方案的地方。

相似之处

如果您仔细研究 FPA 和 Scrum 的组合,您会发现它们相互加强而不是相互削弱。毕竟,FPA 有助于确定总体范围(即将出现的地点)和适当的预算。Scrum 有助于首先实现该预算内具有最高业务价值的功能。尽快将反馈反馈到交付过程中。两个方面的反馈:

  • 第一,总体范围是否正确;
  • 第二,整个问题是否可以在预算内解决。

实际上,这意味着项目的积压是在全球范围内确定的。在 Scrum 中,通常的做法是,具有最高业务价值的产品部分已经具有大量细节。这种详细程度(最好是针对多个冲刺)通常足以进行功能点分析。然后,您可以使用该分析通过外推来确定整个积压工作的功能点总数。在 FPA 方法中,这是允许的。

Scrum 和 FPA 是朋友

简而言之,Scrum 和 FPA 可以很好地相互帮助和加强。功能点可帮助您控制总费用。通过使用 Scrum,您可以根据洞察力保持灵活性。最终是由你来解决整体问题。尽可能快,尽可能好,尽可能便宜。在那个领域,功能点和 Scrum 有一个共同的目标。 所以 Scrum 和 FPA 是朋友。失控和超出预算是(共同的)敌人!

快速取胜

在 Scrum 和功能点组合中快速取:

  • 产品待办列表

更快、更具体化的产品待办列表是对所有必须提出的未实现需求的描述。产品待办列表的顶部是对业务最重要的项目,只有这些项目才被详细制定。

Product Backlog 的大小可以通过使用 FPA 来具体化。FPA 显示需要哪些功能。因此,FPA 在功能方面提供了产品待办列表的摘要。

  • 可衡量的目标

sprint 的详细产品待办列表足以制作估计的 FPA(ISO/IEC 24570 Nesma 功能尺寸测量方法)。然后可以将功能点的数量外推到总数。

因此,最终目标(地平线上的点)可以量化,最终结果是有形的,不需要对整个产品进行详细的规格说明。

  • 更轻松地衡量“附加值”

团队交付软件的速度以故事点来衡量。这些是对工作规模的相对估计。这些故事点不应与功能点混淆。他们甚至看起来都不像(当然,除了名字)。

功能点朝外,考虑整体项目。

故事点面向内,有助于防止Scrum 团队咬得比他们能咀嚼的多。

然而,在 Scrum 中,很难表达交付的价值。然而,这在以下方面可以做得很好:功能点!

  • 帮助确定功能

优先级Scrum 的一个重要方面是确定具有最高业务价值的所需功能,然后将在下一个冲刺中采用。

使用 Estimated FPA,总的愿望清单——以及在其中的下一个冲刺——可以用简单的方式来衡量,也包括功能分组。保持整体画面,班次可追溯。

  • 协助进行估算

估算是团队的任务。进行估算总是(并且仍然)是一件棘手的事情。毕竟,一个团队没有水晶球,在您知道之前,估计值就好像是保证一样。S

crum 估计有故事点,但这些是相对的:与团队相当,但不能超越。然而,功能点是绝对可比的。

功能点在项目之间具有可比性,不仅可以提前衡量,还可以在项目期间和之后进行衡量。因此,团队在进行估算时会得到额外的帮助。

  • 检测改进

因为 FPA 提供了一个客观的度量,它可以用于 Scrum 过程的回顾以显示改进。因此,您可以帮助团队相互学习并检测主要的抑制因素。

  • 确认 Scrum 的商业案例

虽然许多组织对 Scrum 充满热情,但可以通过小道消息传出 Scrum 流程包括更多返工(通过提高洞察力),这将使它们变得更加昂贵。可以确定新功能和增强功能的功能点数量,从而可以确定适应整个过程的生产力。然后可以客观地确定业务案例。


该博客最初是作为AutomatiseringGids(荷兰语)中的评论文章发布的。

关于作者

Jolijn Onvlee (jolijn@onvlee.com) 是质量、预算和生产力管理领域的独立 FPA 专家和顾问、审计师和讲师。Jolijn 还担任 Nesma 董事长和董事会成员多年。

Rini van Solingen 是 Prowareness (rini@scrum.nl) 的 CTO 和代尔夫特技术大学的教授。Rini 是《Scrum 的力量》一书的作者;现在还以法文、德文和英文出版。

0 人点赞