目标读者
本文读者主要是从事或关心敏捷开发的工作者，他们相信敏捷代表了软件交付方式的重大进步，并且希望敏捷管理会变得更好。
前言
众所周知，敏捷的优点是更快地交付、更好地满足不断发展的客户需求。然而，赋予各个团队管理自己流程的自由使得高层管理者管理敏捷团队之间的活动变得困难——我们称之为管理“大规模敏捷”。
具体地说，敏捷度量指标，如故事点，可以管理单个团队的活动，但对于计划和监控跨团队的进度、绩效以及评估未来开发的工作量帮助很小。
高层管理者负责制定预算和优化资源分配，以便为组织交付最大的价值，并负责根据整个组织的预算跟踪进度。对于只使用典型敏捷流程的软件开发团队来说，如果没有跨团队的工作绩效数据比对，以上管理工作是无法准确完成的。对于将软件开发外包给使用敏捷但没有任何绩效度量标准的供应商来说，这些管理任务会更加困难。
本文首先阐述了管理者在面对敏捷度量指标管理受限时所面临的挑战，其次展示了如何将ISO软件功能规模度量标准融入敏捷流程，从而使管理者能够大规模地评估和控制敏捷交付。在不改变敏捷基础流程的情况下，继续获得敏捷团队在交付业务价值的速度和灵活性方面带来的好处。
1、敏捷的好处
敏捷宣言引起了软件交付的变革。敏捷的好处包括：
更早地交付；
更快地响应需求。
也有证据表明，敏捷降低了开发成本和项目完全失败的可能性。
2、敏捷度量的问题
敏捷度量的目标是使用内部团队指标规划和控制开发进度，其中最常见的是“故事点”。然而“故事点”并没有相对客观的定义。一个故事点代表了一个用户故事的 “规模或开发难度”。这混合了两个独立的概念，并没有给敏捷实践者或管理者提供什么是一个故事点以及如何度量。
因此，每个团队自行定义“什么是一个故事点”以及它所表示的“任务有多大”。在实践中，这解释为“我们估计需要多少工作量来处理这个任务”。
为给定的用户故事确定故事点大小的过程——例如“规划扑克”——是有价值的，主要是帮助团队理解需求。就团队而言，可以将故事点用于评估下一次迭代的工作量，但是故事点的“规模”并不适合个体团队以外的绩效评价和任务评估，也就是说，不适合管理“大规模敏捷”。
为了更准确的管理开发任务，一个组织需要一种客观的、标准化的方法进行评估和度量，这种方法对所有类型项目都应该是有效的并且独立于开发技术和开发人员的效率。
3、使用软件功能规模测量标准方法管理 “大规模敏捷”
3.1 软件功能规模测量方法概述
软件功能规模测量方法（即功能点法），如IFPUG、Nesma、COSMIC等均有相关国际标准，本文不再过多赘述。
3.2 在敏捷中度量软件规模
在讨论何时进行软件规模度量前，首先需要识别三个层级的度量指标。参见下图，该图从敏捷管理SAFe框架衍生而来。
图 1 大规模敏捷管理框架
简单来说，只有使用标准化的功能规模测量方法，才能在系统和发布级别进行适当的估算、计划和控制。新建系统早期的功能规模估算可以采用类比法。
在团队级别，可以选择软件功能规模测量标准或继续使用现有的故事点。对于敏捷团队来说，多种方法的组合可能是最成功和最可接受的。例如：
●使用标准的软件功能规模测量方法评估整体系统，有助于目标项目规划和资源分配；
●在回顾期间（或者在每月一次的DevOps环境中）,使用标准的软件功能规模测量方法,在发布或迭代级别评估已交付或完成的规模以评价团队绩效，并为未来的评估需求积累历史数据；
●允许团队使用已经建立的敏捷过程来进行短期的（迭代）工作评估，例如 “规划扑克”估算故事点。
一些组织已经开始使用软件功能规模测量标准方法来评估已交付的软件，并评估从单个用户故事一直到迭代或发布级別的整个可交付成果。每个组织都应该选择自己认为最适合的方法来度量团队层面的用户故事（故事点或功能点）。
3.3 使用功能规模估算
在评估系统、发布或迭代级別的工作量时，首先需要在该级別上评估要交付的软件产品规模，并结合同一级别的以前交付的相似软件的“实际”生产率（而不是“速度”）数据。
建立这些评估过程应谨慎,特别是以下几点：
●通过测算大量具有共同特征的历史开发项目的规模和工作量来建立规模/工作量模型。虽然生产率数据可以从外部基准测试服务中获得，但我们建议每个组织收集自己的历史数据，因为敏捷活动中有很多变量会影响生产率；
●在项目早期评估新建系统的规模，可以使用标准的软件功能规模测量方法；
●在项目早期，当软件需求不明确时，可通过类比法和专家判断进行评估，但估算结果仍然需要保持相同的度量单位。
3.4 在敏捷合同中使用软件规模度量
当客户和供应商存在合同关系时,具有敏捷开发能力的供应商通常会主张签订基于时间和材料 (T&M)的合同。供应商的理由可能是，如果客户希望在需求明确之前就开始敏捷开发，那么投标价格除了包含不同级别开发人员薪资外，就没有其他任何可参考的信息了。
然而纯粹的T&M合同是极不平衡的。一份T&M合同对供应商来说是100%安全的——无论交付什么都能得到报酬——但留给客户的只有通过总预算来控制成本。客户没有管理机制来判断付款进度、供应商绩效以及供应商的服务是否物有所值。
一种有助于平衡客户和供应商之间谈判优势的解决方案就是根据“价格/单位规模”来签订合同,其中交付(或开发) 的功能规模可用标准的软件功能规模测量方法来评估。然后客户在其需求的总规模上承担风险；供应商承担报价单价的风险。此外，客户也必须在供应商合理地给出单价之前明确相关要求，并确保交付的功能可以转化为业务价值（只有在使用该功能时才可能实现）。最终，双方需要就“完成”的功能何时可以度量和结算达成一致。
4、标准化的软件规模度量方法
很明显,自组织敏捷团队的价值观与更高管理者的价值观和合理控制需求之间存在着“文化冲突”。因此，如果管理层希望在现有的敏捷开发团队中引入一种标准化的软件功能规模测量方法，就必须仔细考虑敏捷文化，以免破坏团队，丧失敏捷开发带来的好处。
最重要的问题是什么时候度量（见上文3.2）以及由谁来度量。“谁”这个问题的答案取决于组织的规模以及客户和敏捷团队之间的关系（合同或非正式的）。
实际上，团队应该自我度量，并将软件规模度量视为对敏捷过程不可或缺的帮助，而不是额外的任务。（经验发现，使用标准化软件规模度量方法可以有效保障需求的质量和完整性。）
在项目早期，大型组织在发布开发计划或签署合同时引入软件规模度量方法，组建度量专家小组是非常有益的，比如：
●内部：项目管理办公室；
●外部：提供功能规模度量服务的外部专家供应商。
成立度量专家组的优势在于其度量的客观性、准确性和效率。
组织无论采用哪种解决方案，定期收集度量数据并作为组织学习的基础都是至关重要的。
至于如何向缺乏这些方法经验的组织引入软件规模度量方法，以“自底向上”的方式进行肯定是更好的。换句话说，在一个试点项目中，首先在团队层面引入软件规模度量方法，当获得满意的结果并且组织获得信心时，再横向扩展然后向上（到发布和系统级別）。
5、总结：功能点与故事点对比
6、结论
设定目标和预算并据此进行绩效评价是每个组织的标准做法。本文并不是把敏捷软件开发活动排除在这些标准的业务实践之外。
“故事点”对于控制或评估单个团队以上级别的敏捷活动几乎没有帮助。而功能点方法可以很容易在更高级別上替代故事点，而且不会对敏捷过程的价值产生任何负面影响。在单个用户故事和迭代的层面上，每个组织可以自行决定是使用标准化的软件规模度量方法或故事点进行短期评估。
在已建立的敏捷开发的团队中引入标准功能点法应谨慎处理。本文旨在不破坏敏捷文化的前提下，让组织相信使用客观控制和度量方法的好处，同时也不会失去敏捷在交付软件时的速度和灵活性。（本文由北京中基数联科技有限公司翻译，仅供学习参考使用，版权归原作者所有，转载请标明出处。若有侵权请联系我们删除。本文内容原文链接：https://www.isbsg.org/2021/10/18/2021-it-confidence-conference/）
以上就是软件造价评估公司中基数联为您带来的“使用功能点法管理敏捷活动”所有内容，更多软件开发成本估算知识敬请关注中基数联！
