聊聊功能点分析FPA︱敏捷软件开发
2022-12-20
来源：徐东伟敏捷教练
Scrum的使用，一个大的IT项目被分成许多小项目，这样就能够更容易对新的想法做出响应，并能够大大降低整个项目的复杂性。
Scrum以完全不同的方式处理系统规格说明。在Scrum中，仅仅使用一个笼统的术语（我们称之为产品待办事项列表）来描述产品。然后呢，只对那些具有最高业务价值的部分进行详细设计，并且快速交付。在这之后，确定剩余工作中具有最高业务价值的部分，然后开发和交付，周而复始，这样就可以进行持续的调整。这颠覆了原来期待项目只是交付预先定义的工作的想法。在这种情况下，对整个交付范围进行估算就不靠谱了，因为我们无法在最开始就能够将整个范围拆解的那么细。
分歧
Scrum处理估算和预算的方式与更传统和系统的方法不同。传统的方法通常使用功能点分析（FPA）进行量化，FPA用于估算软件开发成本和交付时间，功能点是用于度量系统规模的一个指标。这个规模的估算基于系统的功能规格说明书。要使用FPA，就需要对系统的细节了解到一定程度。
因此，功能点和Scrum看起来是没有办法好好在一起玩耍了。毕竟一个想要提前得到完整的需求规格说明书，而另一个又希望在任何时候都能够对需求规格提出质疑并进行更新，还不想搞得太详细。Scrum方法中的Sprint实在太短，变化又太大，根本没有办法基于功能点进行估算。可是呢，在敏捷组织中，也是需要控制成本啊。“别着急，活干完了就知道成本是多少了”对于大多数组织来说是不可接受的。这就意味着敏捷会在IT支出上造成无政府状态，这可不成。即使使用Scrum，客户也是需要掌控的，怎么可以裸奔。产品负责人需要对所有工作投入（目标）的产出以及最终花费的时间和金钱（预算）了然于胸。而这正是传统FPA能够解决的。
相似之处
如果你仔细研究FPA和Scrum的结合，就会发现它们相互加强而不是相互削弱。毕竟，FPA有助于确定总体范围和适当的预算。Scrum能够帮助我们在预算内首先实现具有最高业务价值的功能。这样，对于系统的反馈能够以最快的速度进入到交付过程中。反馈有两个方面：一是总体范围是否正确，二是整个问题能否在预算内解决。
实际上，这意味着项目的待办事项列表是在全局级别上确定的。在Scrum中，通常的做法是，产品中具有最高业务价值的部分具有大量的细节，拥有这些细节信息的工作（最好是好几个Sprint的工作）通常足以进行功能点分析。接下来，就可以使用这个分析结果来推测整个待办事项列表的功能点总数。在FPA方法中，这是允许的。
Scrum和FPA是朋友
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
