功能点有多敏捷?

许多组织已经了解到，通过使用功能点对其进行估算，他们可以更好地掌握软件项目. 与此同时, 我们看到越来越多的组织采用敏捷的工作方式, 通常通过应用Scrum. 最大的问题是功能点是否仍然存在. Scrum 是否将他们抛弃了？? 或者功能点在敏捷世界中仍然有价值吗? 在这篇博客中，Jolijn Onvlee 和 Rini van Solingen 展示了其中存在哪些摩擦和相似之处.

敏捷/Scrum

敏捷 (Scrum 是最常用的方法) 被越来越多的组织视为大型 IT 项目失败的解决方案. 开始直接交付软件, 每两周，客户就会直接了解进度和附加值. 用户不再需要等待具有最高商业价值的功能. 此外, 持续的反馈流会带来有价值的系统, 快多了. 事实上, 使用 Scrum, 一个大型IT项目被分割成许多小项目. 这使得响应新见解变得更容易，并极大地降低了整个项目的复杂性.

Scrum 以完全不同的方式处理系统规范. 该产品仅作一般性描述 (叫做 产品积压).然后, 首先，只详细制定那些具有最高商业价值的部分，并且这些部分可以快速交付. 本次交付后，再次确定最高商业价值, 开发并交付, 等等. 通过这种方式可以不断调整. 这取代了提供预定义结果的项目的最初想法. 整个交付范围的估计不再有意义, 仅仅因为整个范围不再详细制定. 地平线上的位置随时可能发生变化.

摩擦

Scrum 处理估算和预算的方式与更传统和系统的方法不同. 传统方法通常使用功能点分析 (FPA) 用于量化. FPA 用于估算制作软件的成本以及交付该软件需要多长时间. 功能点用作确定系统规模的度量. 该尺寸是根据功能规格确定的. FPA 需要对您要制作的内容进行一定程度的详细说明.

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

相似之处

如果你仔细研究一下 FPA 和 Scrum 的结合, 你会发现它们是互相加强而不是互相削弱. 毕竟, FPA 有助于确定总体范围 (地平线上的那个地方) 以及适当的预算. Scrum 有助于首先在预算范围内实现具有最高商业价值的功能. 尽快将反馈反馈到交付流程中. 两方面反馈: 第一的, 总体范围是否正确以及, 第二, 整个问题能否在预算内得到解决.

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

Scrum 和 FPA 是朋友

简而言之, Scrum 和 FPA 可以很好地互相帮助和加强. 功能点帮助您掌控总支出. 通过使用 Scrum，您可以根据见解保持灵活性. 最终还是要你来解决整体问题. 一样快, 尽可能好又便宜. 在那个地区, 功能点和Scrum有一个共同的目标.
所以 Scrum 和 FPA 是朋友. 失去控制并超出预算是 (常见的) 敌人!

快速获胜

Scrum 和功能点组合的快速获胜

1. 产品待办事项列表更快具体化
   产品待办事项列表是对必须提出的所有未实现需求的描述. 产品待办事项列表的顶部是对业务最重要的项目，并且只有这些项目才会被详细制定. 产品待办事项列表的大小可以通过使用 FPA 来具体化. FPA显示 什么 需要功能性. 因此，FPA 提供了产品待办事项列表的功能摘要.
2. 可衡量的目标
   前六个冲刺的详细产品待办事项列表足以制作估计的 FPA (ISO / IEC 24570 Nesma 功能尺寸测量方法). 然后可以将功能点的数量推断为总数. 因此, 最终目标 (地平线上的那个地方) 可以量化, 最终结果变得有形, 无需整个产品的详细规格.
3. 更容易衡量“附加值”’
   团队交付软件的速度以故事点来衡量. 这些是工作规模的相对估计. 这些故事点不应与功能点混淆. 他们甚至长得都不像 (除了名字之外, 当然). 功能点朝外，考虑项目整体. 故事点面向内，有助于防止 Scrum 团队贪多嚼不烂. 然而在 Scrum 中, 很难表达所交付的价值. 然而, 这可以很好地完成: 功能点!
4. 帮助确定功能的优先级
   Scrum 的一个重要方面是确定具有最高业务价值的所需功能, 然后将在下一个冲刺中被拾取. 根据预估的 FPA，总愿望清单 – 并在其中, 下一个冲刺 – 可以用简单的方法测量, 还有关于功能的分组. 整体画面保留，变化可追溯.
5. 协助进行估算
   估算是团队的任务. 做出估计总是 (并仍然存在) 棘手的事情. 毕竟, 团队没有水晶球，在你知道之前, 估计的使用就好像它是保证一样. 使用故事点进行 Scrum 估算, 但这些都是相对的: 与团队相当但不超过. 功能点, 然而, 是绝对且具有可比性的. 功能点在项目之间具有可比性，不能只提前测量, 而且也在项目期间和之后. 因此, 团队在进行估算时获得额外帮助.
6. 检测改进
   由于 FPA 提供了客观的衡量标准，因此可以在 Scrum 流程的回顾中使用它来显示改进情况. 因此您可以帮助团队互相学习并发现主要的抑制因素.
7. 确认 Scrum 的业务案例
   尽管许多组织都热衷于 Scrum, 小道消息称 Scrum 流程包含更多返工 (通过提高洞察力) 这会让它们更贵. 可以确定新功能和增强功能的功能点数量，从而确定适应和整个过程的生产率. 然后可以客观地确定业务案例.

该博客最初作为评论文章发布于 Automatiseringsgids (在荷兰).

 

作者简介

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

Rini van Solingen 是 Prowareness 的首席技术官 (rini@scrum.nl) 代尔夫特理工大学教授. 里尼是这本书的作者 “Scrum 的力量”; 现在也以法语出版, 德语和英语.