使用功能点法管理敏捷活动

目标读者
　　本文读者主要是从事或关心敏捷开发的工作者，他们相信敏捷代表了软件交付方式的重大进步，并且希望敏捷管理会变得更好。
前言
　　众所周知，敏捷的优点是更快地交付、更好地满足不断发展的客户需求。然而，赋予各个团队管理自己流程的自由使得高层管理者管理敏捷团队之间的活动变得困难——我们称之为管理“大规模敏捷”。
　　具体地说，敏捷度量指标，如故事点，可以管理单个团队的活动，但对于计划和监控跨团队的进度、绩效以及评估未来开发的工作量帮助很小。
　　高层管理者负责制定预算和优化资源分配，以便为组织交付******的价值，并负责根据整个组织的预算跟踪进度。对于只使用典型敏捷流程的软件开发团队来说，如果没有跨团队的工作绩效数据比对，以上管理工作是无法准确完成的。对于将软件开发外包给使用敏捷但没有任何绩效度量标准的供应商来说，这些管理任务会更加困难。
　　本文首先阐述了管理者在面对敏捷度量指标管理受限时所面临的挑战，其次展示了如何将ISO软件功能规模度量标准融入敏捷流程，从而使管理者能够大规模地评估和控制敏捷交付。在不改变敏捷基础流程的情况下，继续获得敏捷团队在交付业务价值的速度和灵活性方面带来的好处。
  　　1、敏捷的好处
　　敏捷宣言引起了软件交付的变革。敏捷的好处包括：
　　更早地交付；
　　更快地响应需求。
　　也有证据表明，敏捷降低了开发成本和项目完全失败的可能性。
　　2、敏捷度量的问题
　　敏捷度量的目标是使用内部团队指标规划和控制开发进度，其中最常见的是“故事点”。然而“故事点”并没有相对客观的定义。一个故事点代表了一个用户故事的 “规模或开发难度”。这混合了两个独立的概念，并没有给敏捷实践者或管理者提供什么是一个故事点以及如何度量。
　　因此，每个团队自行定义“什么是一个故事点”以及它所表示的“任务有多大”。在实践中，这解释为“我们估计需要多少工作量来处理这个任务”。
　　为给定的用户故事确定故事点大小的过程——例如“规划扑克”——是有价值的，主要是帮助团队理解需求。就团队而言，可以将故事点用于评估下一次迭代的工作量，但是故事点的“规模”并不适合个体团队以外的绩效评价和任务评估，也就是说，不适合管理“大规模敏捷”。
　　为了更准确的管理开发任务，一个组织需要一种客观的、标准化的方法进行评估和度量，这种方法对所有类型项目都应该是有效的并且独立于开发技术和开发人员的效率。
　　3、使用软件功能规模测量标准方法管理 “大规模敏捷”
　　3.1 软件功能规模测量方法概述
　　软件功能规模测量方法（即功能点法），如IFPUG、Nesma、COSMIC等均有相关国际标准，本文不再过多赘述。
　　3.2 在敏捷中度量软件规模
　　在讨论何时进行软件规模度量前，首先需要识别三个层级的度量指标。参见下图，该图从敏捷管理SAFe框架衍生而来。