与所有技术性或创造性工作一样，软件工程团队的效率是不能以数量来衡量的。如果仅衡量软件开发的生产力和跟踪团队的绩效，那么只需要简单地计算一下代码行数或工作时间即可。工作的质量和团队的协作会对生产力产生直接和持久的影响。软件开发效率正变得日益灵活且相互之间具有千丝万缕的联系，加之敏捷性的不断增强，传统的关键绩效指标(KPI)如今已经失效。
为了适应发展趋势，我们需要重新考虑KPI，扩大团队并重新定义当前大多数软件开发所需要的敏捷性。如果生产效率不再以代码的多少进行衡量，那么我们应当以什么进行衡量呢?如果计时指标很难有效衡量一个Scrum(Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括一系列实践和预定义角色的过程骨架。)的进展情况，那么正确的衡量指标又是什么呢?
下列这些KPI方案或许可以帮助我们更好地了解和衡量软件团队的进展和效率。我们要在整个产品生命周期中以一种可接受和可预测的速度不断进行改进以实现KPI的终极目标。
解决问题
软件开发如今兼具了高度的战略性和高度的创造性。每次迭代都会带来新的洞察力、新的注意事项和新的客户需求。那么软件团队是如何高效地解决这些问题的呢?
这需要一个能够评估出现/解决率的KPI，即问题出现的频率以及软件开发团队如何高效地管理它们。这已经不再是简单地以团队出现了多少生产问题进行衡量了。新的指标应当与质量挂钩，即团队如何高效地解决了这些问题。如果问题长期没有解决，那么团队应当致力于解决这些问题。如果问题在出现时就能够被及时解决，那么团队在问题解决环节将会得到很高的评分，这也意味着团队在协作方面非常成功。
速度
尽管敏捷项目很难通过预算和时间进行评估，但是团队仍在朝着关键的最终目标而努力。实现这些目标的速度是衡量生产效率的一个重要指标。适合类似瀑布式时间表的里程碑可能并不适合灵活多变的敏捷性，不过它们仍可以用来评估进展和速度。在敏捷性方面，速度可以用于评估每一个Sprint(Sprint指Scrum团队完成一定数量工作所需的短暂、固定的周期。通常为15-30天)，看看团队解决了多少用户问题。这一衡量方法并不是以个人完成了多少任务而论，而是看团队解决了多少用户问题(即用户想要的东西)。在衡量每一个解决用户问题的Sprint当中，我们可以用一个进度值来展现软件开发团队的完成和交付速度。
工作流程稳定性
软件团队的工作流在稳定性方面如何?由于稳定的工作流可以增强预测性，因此这是一个重要的KPI。如果跨Sprint的工作流不稳定，那么用户将难以预测下一步工作和最终交付情况。稳定的工作流可以证明团队和项目正在步入正轨，并且能够有效管理工作负载。
工作流的稳定性并不是一个简单的指标，而是一个包含了多个方面的KPI。用户需要查看多个指标才能评估团队的稳定情况。例如：
- 正在进行的工作——已开始但尚未完成的项目数。
- 周期时间——任务从开始到完成需要多长时间。
- 效率——已完成的项目/时间单位。
对这些工作流的指标进行分析可以获得一张团队运作效率的整体图。如果团队工作稳定，那么他们的产出和进度将会更加准确，对可发布产品的预测也将变得更加可靠。
团队士气
很少有人会把团队士气当成一个衡量指标，但是士气也是影响每个KPI的一个重要因素，因为它们会影响到每名团队成员的努力程度和创造力。如果团队成员对自己的工作有自豪感，知道珍惜，有自主决策权，并且能够理解项目的目标，那么他们将会成为优秀的贡献者。他们开发的软件也会变得更好，更具创新性。
公司只需要深入到团队当中就可以评估出团队的士气情况。例如，对每个sprint进行观察就不难发现员工对沟通、团队合作、压力的感觉，甚至是他们在工作中的自豪感和乐趣。如果在多个sprint中，员工的自豪感都很低，那么公司可以展开更深层次的调查。例如，为什么团队成员感到沮丧?是否存在需要解决的质量、压力或管理问题?全面了解团队士气的一个重要举措是展开更为深入的谈话。谈话可以促进理解，提高团队成员的参与度和协作能力。
与所有的KPI一样，士气也不是一个简单的一次性指标，其要求在一段时间内进行广泛的全面评估。与敏捷本身一样，每次迭代评估都让软件开发中的KPI变得更加好用。正确的KPI并不是以高压手段全力压榨本已承受压力且疲惫的团队，而是帮助对高点和低点进行平衡，从而实现均衡发展。
