功能点有多敏捷？

许多组织已经了解到，通过使用功能点对其进行估计，他们可以更好地控制软件项目。同时，我们看到越来越多的组织采用敏捷的工作方式，通常是通过应用 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 的力量》一书的作者；现在还以法文、德文和英文出版。