作为软件交付的一个重要环节，程序开发需要所有团队成员都不断关注每一个细节。任何稍许的代码级缺陷都会影响整个项目进程和产品质量。据相关研究统计，在常规项目开发完毕后，只有三分之一的软件被认为成功实现了预期的功能与性能，而其他的软件则不是被认为存在问题，就是被视为完全失败了。
众所周知，软件项目失败背后的主要原因包括：各种产品缺陷、需求上的歧义、产品测试不足、程序中的无效代码、和其他性能上的问题。通常，衡量软件产品开发团队的生产力是防止项目失败的关键方法之一。我们可以通过许多软件开发的相关指标，来衡量团队的生产力。下面，让我们一起来详细讨论有哪些关键指标，可以协助我们尽早发现软件项目中的风险，进而避免后期出现软件故障。
1.客户满意度
客户满意度是衡量软件开发团队生产力的一项关键指标。业界常说的爽点和痛点是满意度的直接体现，客户只有使用满意了才会将您的产品推荐给其他人，并成为软件的忠实用户。相反，客户一旦觉得不满意，就会立刻转用竞争对手的产品。
衡量客户满意度的方法有很多，常见的标准方法有如下三种：
- 净推荐值(Net Promoter Score，NPS)：它根据客户向他人推荐您产品的可能性，以1-10的等级，对客户进行评分。例如，觉得满意的客户会给出9或10分，而不满意的客户则会给出1或2分。NPS是满意客户与不满意客户数量的比率。由于它的整体范围可以从-100到100，因此任何高于6的NPS分数都被认为是良好的，即表示客户认为满意。也就是说，软件开发团队的目标是要让NPS的分值达到6分以上。
- 客户反馈：衡量客户满意度的另一种方法是通过客户提供的反馈和建议。您可以要求客户根据他们对产品的体验，提供从1到5的产品评级。就产品与服务而言，您最好在订阅期结束之前，以电子邮件或消息推送的形式发送反馈请求。当然，您也可以通过Twitter和Facebook等第三方社交媒体网站去获取反馈。
- 客户调查：这是获得产品客户满意度或客户体验指标的第三种有效方式。您应该在一定的时间间隔，比如在购买产品一个月后，根据客户的购买与使用情况，发送一封调查电子邮件。调查的内容可以包括：有关客户对于产品的体验、他们向他人推荐本产品的可能性、以及对现有问题的任何建议等。
2.冲刺燃尽(Sprint Burndown)
冲刺燃尽是一次冲刺中已完成工作的图形表示。它可以被用来跟踪团队的进度，并确定他们是否可以实现冲刺的目标。
创建冲刺燃尽图背后的思想是，找出在冲刺中已完成的工作量，并将其与实际完成的工作进行比较。如下图所示，x轴代表时间，而y轴代表剩余的工作量。斜线率代表了团队如何完成工作。
冲刺燃尽图通常由两条线组成：一条表示预计进展，另一条表示实际进展。此外，它还包含如下六的方面：
- 起点：是冲刺时间的开始，剩余工作为100%。
- 终点：是冲刺结束的时间，剩余工作为0。
- 零线：在y轴上绘制零线，可以指示在起点和终点处剩余的工作。
- 实际进度线：是显示冲刺中已完成工作量的线。
- 理想进度线：理想线显示了如果一切按计划进行的话，冲刺中应当完成的工作量。
- 燃尽率：燃尽率是实际进度线的斜率。
3.团队速度
团队速度可以衡量一个团队在一定的时间内，可以完成的工作量。我们既然可以根据故事点(story points)来衡量，也可以根据理想天数来衡量。此处的理想天数是指所有团队成员在某个项目上协同工作的总天数。它虽然根据所有团队成员的100%出勤率来进行计算，但也包括了周末、节假日或任何其他类型的缺勤。显然，更高的速度意味着团队可以在更短的时间内，完成更多的工作。我们通常使用该指标，来跟踪团队在一段时间内的进度。
4.发布燃尽图(Release Burndown)
发布燃尽图是软件开发团队用来预测完成进度的工具。它使用速度作为预测项目完成所剩余天数的基础。它有时也称为发布计划，调度的是需要的时间而不是任务。其基本原理是：速度乘以迭代次数，得到完成的故事点的总数。您可以通过将剩余的故事点乘以团队的平均速度，来转换为天数。
5.周期时间
周期时间是问题从开始到完成所需的平均时间。您可以在几天、几小时甚至是几分钟之内对其进行测算。周期时间的通用公式为：T=T+d(t)。其中，T是以小时或天为单位，表示花费在特定项目上的总时间;d(t)表示工作流中每个阶段的问题所持续时间。
例如，QA团队的Alice在1月1日创建了一个问题，并将其分配给了开发团队的John。他在In Progress阶段花费了两天，在Completed阶段花费了一天。那么该问题的总周期时间就是四天。
减少周期时间的目标就是要提高问题从开始到完成的速度。该指标可用于衡量团队工作流程的效率，并有针对性地寻找改进方法。
6.交付周期(Lead Time)
交付周期是指某个问题被分配给特定团队或成员之后，从开始到完成的平均时间。您还可以按天、小时或分钟为单位进行测算。交付周期的一般公式为：L=L+d(t)。其中，L是完成一个问题所需的交付周期，以小时或天为单位;d(t)则表示进入每个工作流程阶段的持续时间。
例如，QA团队的Alice在1月1日创建了一个问题，并将其分配给开发团队的John。他从In Progress到Completed需要五天的时间，那么此问题的总交付周期就是五天。
交付周期通常被作为一种指标，跟踪问题的解决速度。该指标反应并衡量了团队工作流程的效率，进而协助寻找改进方法。显然，缩短交付周期可以改进问题的解决方式。
7.平均修复时间(Mean Time to Repair，MTTR)
平均修复时间是衡量在检测到错误或问题后，开发团队需要多长时间才能解决的指标。它也可以用天、小时或分钟来衡量。MTTR的一般公式为：MTTR=T+d(t)。其中，T是以小时或天为单位计算的、花费在特定项目上的总时间，而d(t)则表示工作流中每个阶段的问题所持续的时间。
例如，开发团队的John在1月1日创建了一个问题，并将其分配给QA团队的Joanne。她在Progress阶段花费了两天时间，并在Debugging阶段花费了四天时间。那么该问题的总MTTR为六天。
该指标旨在减少发现错误或问题后，需要解决的时间。因此，它可被用于跟踪问题解决的速度，进而协助寻找改进方法。
8.代码审查
作为一种衡量软件质量并防止代码库中出现缺陷的实践，开发人员通过检查彼此代码的方式，提出改进或替代方案，并启动实施此类更改的计划。代码审查的主要目标是提高代码库的整体质量，并防止向生产环境引入缺陷。
9.错误率
错误率是对软件应用程序中发现到的缺陷或问题数量的衡量。您可以用它来衡量每个单元、每天、每周或每月的错误占比。错误率的一般公式为：R=N/t。其中，R是错误率，N是在特定时段内发现的错误数，t是该时段持续的时间。
例如，QA团队的Joanne在2月1日发现了10个缺陷，并将它们分配给同为QA团队的Bob。如果她花费了八天的时间，才重现所有发现的问题，那么这个期间的总错误率为每天0.8个错误。
该指标旨在衡量随着时间的推移，QA团队能够在软件程序中发现到的缺陷或问题数量。当然，该指标也常被用作比较工具，以确定测试过程是否有待改进，进而协助发现提高产品测试质量的方法。
10.任务量(Task Volume)+平均估计
任务量可以衡量有多少任务量需要被发送到产品环境中。它也可以按天、小时或分钟来衡量。任务量的一般公式为：TV=TV+d(t)。其中，TV为总任务量，TV是任务总数，d(t)表示工作流中每个阶段的工作时间的持续时间。
例如，来自QA团队的Alex在1月1日创建了一个问题并将其分配给John。从InProgress到ReadyforDev需要五天时间。此问题的总任务量现在为15天。
任务量的目标是衡量交付产品所需完成的任务数量并确定减少它们的方法。该指标可识别工作流程中的潜在瓶颈，使团队能够在这些问题严重延迟项目之前解决这些问题。它还可以比较组、项目甚至软件开发工作流程。
结论
本文中提到的指标对于衡量软件开发生产力至关重要。虽然并非所有指标都适用于每个项目，但这些指标为评估团队绩效提供了一个很好的起点。衡量和跟踪这些指标有助于确定提高生产力和质量的领域。
译者介绍
陈 峻 (Julian Chen)，51CTO社区编辑，具有十多年的IT项目实施经验，善于对内外部资源与风险实施管控，专注传播网络与信息安全知识与经验;持续以博文、专题和译文等形式，分享前沿技术与新知;经常以线上、线下等方式，开展信息安全类培训与授课。
原文标题：10 Important Software Development Metrics That Every Project Manager Should Know，作者:Rita Roy
