1 软件开发度量
在多数行业中，决策基于数据而产生。重要的 KPI 一般是随时间测量的，数 据表示某种事件或模式，该事件或模式是某个操作的触发因素。举一个简单的例 子:工厂中一条重要装配线的吞吐量(即每分钟装配的产品数量)。当吞吐量低 于某个阈值时，说明出现了问题。因此，维修人员将确定问题并进行维修。
在软件行业中，人们经常提到“软件工厂”。这些团队专注于软件开发，为 客户提供相应价值。例如:移动应用程序中的新功能、网站上的新功能或 ERP 系 统的更改。
那么如何衡量开发团队的产出呢?为了解决这个问题，制定了功能规模度量 的 ISO 标准。目前有 5 种方法(按字母顺序排列)。
• COSMIC-FFP (ISO/IEC 19761)
• FiSMA (ISO/IEC 29881)
• IFPUG (ISO/IEC 20926)
• Nesma (ISO/IEC 24570)
• UKSMA-Mark II (ISO/IEC 20968)
在这些方法中，IFPUG、Nesma 和 COSMIC 是最常用的方法。这些方法不 考虑技术层面或非功能需求，而是通过量化软件的功能点来度量软件的功能规模。正如 100 平方米的砖墙具有与 100 平方米玻璃墙具有相同的表面积一样，用 Java编写的 1000 个功能点的软件系统与用 Cobol 开发的 1000 个功能点的应用程序 提供的功能数量相同。
功能点分析师对一组功能用户需求(例如用户故事、用例、功能设计等)进 行分析，并确定这些需求的功能规模，还可以确定在特定时间段(一个 sprint 或 一个版本)内添加、修改或删除的功能规模。这是由 Nesma 开发的，也是其标准 的一部分。Nesma 将其称为“项目规模”，度量单位为“增强功能点(EFP)”。因此，有两种功能规模:
• 应用程序规模:应用程序在某一时刻的功能规模。例如，应用程序 X 当 前为 1000 FP。
• 项目规模:在一定时间内添加、修改或删除的功能规模。比如，在 SprintY 中，添加了 25 个 FP，修改了 15 个，删除了 5 个。项目规模为 25+15+5=45个增强功能点(EFP)。
2 团队绩效指标
通过测试每个Sprint或者每个版本的EFP 数量，可以比较不同团队的生产率 差异。例如，当获取到所花费的工时、这些工时的成本以及发现的缺陷数量等数 据时，就可以确定以下指标:
• 项目交付率:每个 EFP 花费的工时;
• 成本效率:每个 EFP 花费的工时成本;
• 程序质量:每 1000 EFP 中的缺陷;
• 交付速度:每月 EFP。
对每个团队的上述指标进行监控，就可以知晓团队情况。当开发的 EFP 较少时，则可能存在问题。功能点是产生价值的代表，团队开发的功能越多，用户 使用该功能的机会就越多。通过上述指标可以进行团队之间的对比，管理层可以了解到效率更高，更具 价值的团队。
人们通常用生产率进行比较，因为它独立于费率或内部成本。在 ISBSG 术 语中，经常使用生产率，而不使用正确的术语—项目交付率(PDR)。对于大多数 人来说，很难处理有很多小数的数字，而在计算每小时的功能点时得到的结果就 是这样的数字，因此将这个计算结果反转为每个功能点的小时数，称为 PDR。即PDR 是每个功能点花费的工时。图 1 为不同团队之间的 PDR 对比。
例如，团队 A 是一个 8 人的 Java 团队，而团队 C 是一个 5 人的 Cobol 团队。团队的生产率很大程度上取决于技术环境。因此，将每个团队的生产率与行业的 市场平均水平进行比较是有意义的。
在多数行业中，决策基于数据而产生。重要的 KPI 一般是随时间测量的，数 据表示某种事件或模式，该事件或模式是某个操作的触发因素。举一个简单的例 子:工厂中一条重要装配线的吞吐量(即每分钟装配的产品数量)。当吞吐量低 于某个阈值时，说明出现了问题。因此，维修人员将确定问题并进行维修。
在软件行业中，人们经常提到“软件工厂”。这些团队专注于软件开发，为 客户提供相应价值。例如:移动应用程序中的新功能、网站上的新功能或 ERP 系 统的更改。
那么如何衡量开发团队的产出呢?为了解决这个问题，制定了功能规模度量 的 ISO 标准。目前有 5 种方法(按字母顺序排列)。
• COSMIC-FFP (ISO/IEC 19761)
• FiSMA (ISO/IEC 29881)
• IFPUG (ISO/IEC 20926)
• Nesma (ISO/IEC 24570)
• UKSMA-Mark II (ISO/IEC 20968)
在这些方法中，IFPUG、Nesma 和 COSMIC 是最常用的方法。这些方法不 考虑技术层面或非功能需求，而是通过量化软件的功能点来度量软件的功能规模。正如 100 平方米的砖墙具有与 100 平方米玻璃墙具有相同的表面积一样，用 Java编写的 1000 个功能点的软件系统与用 Cobol 开发的 1000 个功能点的应用程序 提供的功能数量相同。
功能点分析师对一组功能用户需求(例如用户故事、用例、功能设计等)进 行分析，并确定这些需求的功能规模，还可以确定在特定时间段(一个 sprint 或 一个版本)内添加、修改或删除的功能规模。这是由 Nesma 开发的，也是其标准 的一部分。Nesma 将其称为“项目规模”，度量单位为“增强功能点(EFP)”。因此，有两种功能规模:
• 应用程序规模:应用程序在某一时刻的功能规模。例如，应用程序 X 当 前为 1000 FP。
• 项目规模:在一定时间内添加、修改或删除的功能规模。比如，在 SprintY 中，添加了 25 个 FP，修改了 15 个，删除了 5 个。项目规模为 25+15+5=45个增强功能点(EFP)。
2 团队绩效指标
通过测试每个Sprint或者每个版本的EFP 数量，可以比较不同团队的生产率 差异。例如，当获取到所花费的工时、这些工时的成本以及发现的缺陷数量等数 据时，就可以确定以下指标:
• 项目交付率:每个 EFP 花费的工时;
• 成本效率:每个 EFP 花费的工时成本;
• 程序质量:每 1000 EFP 中的缺陷;
• 交付速度:每月 EFP。
对每个团队的上述指标进行监控，就可以知晓团队情况。当开发的 EFP 较少时，则可能存在问题。功能点是产生价值的代表，团队开发的功能越多，用户 使用该功能的机会就越多。通过上述指标可以进行团队之间的对比，管理层可以了解到效率更高，更具 价值的团队。
人们通常用生产率进行比较，因为它独立于费率或内部成本。在 ISBSG 术 语中，经常使用生产率，而不使用正确的术语—项目交付率(PDR)。对于大多数 人来说，很难处理有很多小数的数字，而在计算每小时的功能点时得到的结果就 是这样的数字，因此将这个计算结果反转为每个功能点的小时数，称为 PDR。即PDR 是每个功能点花费的工时。图 1 为不同团队之间的 PDR 对比。
图1 不同团队的项目交付率对比
例如，团队 A 是一个 8 人的 Java 团队，而团队 C 是一个 5 人的 Cobol 团队。团队的生产率很大程度上取决于技术环境。因此，将每个团队的生产率与行业的 市场平均水平进行比较是有意义的。
