Scrum和功能点：朋友还是敌人

Posted 2021-04-25 精益企业教练

本文字数约2349， 阅读约需8分钟。

本文由Jolijn Onvlee原创，由徐东伟翻译。

功能点有多敏捷？

许多组织已经意识到，他们可以使用功能点对软件项目进行估算，从而更好地掌控软件项目。同时，我们也看到越来越多的组织采用敏捷的工作方式，通常是使用Scrum。那么最大的问题来了：在敏捷环境中，功能点还能用吗？Scrum会把功能点扔一边儿去吗？功能点在敏捷世界中还有价值吗？在该博客中，Jolijn Onvlee和Rini van Solingen展示了敏捷和功能点的相爱相杀。

敏捷/Scrum

敏捷（以Scrum为最常用的方法），作为解决大型IT项目失败境况的一剂良方，被越来越多的组织所接受。通过直接开始交付软件（译者注：而不是先花数月写上300页的需求文档），每两周客户就可以直接了解项目进度，能够看到交付的价值。用户不再为了能够用上最高业务价值的功能而进行漫长的等待。此外，持续的反馈信息流，能够让我们更快地交付更有价值的可用系统。事实上，随着Scrum的使用，一个大的IT项目被分成许多小项目，这样就能够更容易对新的想法做出响应，并能够大大降低整个项目的复杂性。

Scrum以完全不同的方式处理系统规格说明。在Scrum中，仅仅使用一个笼统的术语（我们称之为产品待办事项列表）来描述产品。然后呢，只对那些具有最高业务价值的部分进行详细设计，并且快速交付。在这之后，确定剩余工作中具有最高业务价值的部分，然后开发和交付，周而复始，这样就可以进行持续的调整。这颠覆了原来期待项目只是交付预先定义的工作的想法。在这种情况下，对整个交付范围进行估算就不靠谱了，因为我们无法在最开始就能够将整个范围拆解的那么细。

分歧

Scrum处理估算和预算的方式与更传统和系统的方法不同。传统的方法通常使用功能点分析（FPA）进行量化，FPA用于估算软件开发成本和交付时间，功能点是用于度量系统规模的一个指标。这个规模的估算基于系统的功能规格说明书。要使用FPA，就需要对系统的细节了解到一定程度。

因此，功能点和Scrum看起来是没有办法好好在一起玩耍了。毕竟一个想要提前得到完整的需求规格说明书，而另一个又希望在任何时候都能够对需求规格提出质疑并进行更新，还不想搞得太详细。Scrum方法中的Sprint实在太短，变化又太大，根本没有办法基于功能点进行估算。可是呢，在敏捷组织中，也是需要控制成本啊。“别着急，活干完了就知道成本是多少了”对于大多数组织来说是不可接受的。这就意味着敏捷会在IT支出上造成无政府状态，这可不成。即使使用Scrum，客户也是需要掌控的，怎么可以裸奔。产品负责人需要对所有工作投入（目标）的产出以及最终花费的时间和金钱（预算）了然于胸。而这正是传统FPA能够解决的。 

相似之处

如果你仔细研究FPA和Scrum的结合，就会发现它们相互加强而不是相互削弱。毕竟，FPA有助于确定总体范围和适当的预算。Scrum能够帮助我们在预算内首先实现具有最高业务价值的功能。这样，对于系统的反馈能够以最快的速度进入到交付过程中。反馈有两个方面：一是总体范围是否正确，二是整个问题能否在预算内解决。

实际上，这意味着项目的待办事项列表是在全局级别上确定的。在Scrum中，通常的做法是，产品中具有最高业务价值的部分具有大量的细节，拥有这些细节信息的工作（最好是好几个Sprint的工作）通常足以进行功能点分析。接下来，就可以使用这个分析结果来推测整个待办事项列表的功能点总数。在FPA方法中，这是允许的。

Scrum和FPA是朋友

总之，Scrum和FPA可以很好地相互帮助和加强。功能点帮助你控制总开支，而使用Scrum，你可以基于新的洞察保持灵活性。最终你就可以解决整个问题。简直是多快好省！在这方面，功能点和Scrum的目标是相同的。

所以Scrum和FPA是朋友，失控和超支是（共同的）敌人！

速赢

在Scrum和功能点的结合中速赢：

1

产品待办事项列表更快变得具体

产品待办事项列表描述了所有未实现的需求。在产品待办事项列表的顶部，是对业务来说最重要的条目，只有这些条目才会进行细粒度拆解。使用FPA，可以让产品待办事项列表的规模变得更加具体，因为FPA能够展示我们要做的功能都是什么。因此，FPA是从功能角度对产品待办事项列表进行了总结。

2

目标可度量

前6个Sprint的详细产品待办事项列表足以用来做FPA估算（ISO/IEC 24570 Nesma功能规模度量方法），估算出来的功能点数量可以用于推测总功能点数。这样，可以对最终目标进行量化，最终结果也是明确的，无需整个产品的详细规格说明书。

3

交付的价值更容易度量

团队交付软件的速度是以故事点来衡量的，这是对工作规模的相对估算。我们千万不要把故事点和功能点搞混，它们甚至长得都不像（当然，名字还是挺像的）。功能点是外向型的，考虑整个项目；故事点是内向型的，有助于防止Scrum团队吃得太多。然而，在Scrum中，很难表达交付的价值，而这正是功能点所擅长的，它可以完美搞定！

4

帮助确定功能的优先级

Scrum的一个重要方面是确定最高业务价值的功能，下一个Sprint的工作就从这些功能中选择。根据估算的FPA来度量整个愿望列表（以及在这个愿望列表中的下几个Sprint）就变得很容易了，这种方法也可用于功能分组。这样，我们就能记录下来总体情况，并且所有的改变都是可追踪的。

5

协助做估算

估算是团队的任务。做估算总是一件棘手的事情，毕竟团队没有魔法水晶球（译者注：用通天的法力预测未来），而且你也知道，以前大家把估算当承诺来用。Scrum使用故事点进行估算，但这些都是相对估算：团队可以用故事点和自己比，但是不能和其他团队比。然而，功能点是绝对估算，能够和其他团队进行比较。功能点在不同的项目之间可以进行比较，不仅可以事先度量，还可以在项目期间以及完成之后进行度量。因此，团队在进行估算时会从功能点得到额外的帮助。

6

看出改进

因为FPA提供了客观的度量，所以在Scrum回顾会中，我们可以借助功能点来彰显改进的状况。所以你可以因此帮助团队相互学习，找出阻碍改进的主要因素。

7

为Scrum确认商业案例

虽然许多组织都对Scrum充满热情，但是通过小道消息，我们也能听到很多流言蜚语，说Scrum流程带来了更多的返工（因为用户看到软件后又提出很多新的想法和修改意见），这让Scrum流程的代价变得更加高昂。我们通过度量新增以及改进功能的功能点数量，就能够对整个过程中以及不断调整中的生产力心中有底。这样就可以对商业案例客观地进行准确的计算。

该博客最初是作为一篇评论文章发表在AutomatiseringGids （使用荷兰语发表）上的。

关于作者

Jolijn Onvlee（[e-mail]）是质量、预算和生产力管理领域的独立FPA专家和顾问、审计师和讲师。Jolijn还曾担任Nesma的董事长和董事多年。

Rini van Solingen是Prowareness的首席技术官（[e-mail]），并且是代尔夫特技术大学的教授。Rini是《The Power of Scrum》一书的作者，该书已翻译成法语、德语和英语出版。

---

关于译者

徐东伟，资深企业级敏捷教练，经历过外企、国企、民企，干过软件攻城狮、传统大项目经理、敏捷教练和咨询顾问，2008年开始践行敏捷，对敏捷、精益、SAFe、DevOps等非常着迷！希望能够为中国企业的发展贡献自己的微薄之力，同时交到好多好多志同道合的小伙伴！

同时非常欢迎单独骚扰，加好友请注明：姓名+公司+职位！

你可能感兴趣的文章