程序员的发际线它们来守护

势，我们需要重新考虑KPI，扩大团队并重新定义当前大多数软件开发所需要的敏捷性。如果生产效率不再以代码的多少进行衡量，那么我们应当以什么进行衡量呢?如果计时指标很难有效衡量一个Scrum(Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括一系列实践和预定义角色的过程骨架。)的进展情况，那么正确的衡量指标又是什么呢?

下列这些KPI方案或许可以帮助我们更好地了解和衡量软件团队的进展和效率。我们要在整个产品生命周期中以一种可接受和可预测的速度不断进行改进以实现KPI的终极目标。

解决问题

软件开发如今兼具了高度的战略性和高度的创造性。每次迭代都会带来新的洞察力、新的注意事项和新的客户需求。那么软件团队是如何高效地解决这些问题的呢?

这需要一个能够评估出现/解决率的KPI，即问题出现的频率以及软件开发团队如何高效地管理它们。这已经不再是简单地以团队出现了多少生产问题进行衡量了。新的指标应当与质量挂钩，即团队如何高效地解决了这些问题。如果问题长期没有解决，那么团队应当致力于解决这些问题。如果问题在出现时就能够被及时解决，那么团队在问题解决环节将会得到很高的评分，这也意味着团队在协作方面非常成功。

速度

尽管敏捷项目很难通过预算和时间进行评估，但是团队仍在朝着关键的最终目标而努力。实现这些目标的速度是衡量生产效率的一个重要指标。适合类似瀑布式时间表的里程碑可能并不适合灵活多变的敏捷性，不过它们仍可以用来评估进展和速度。在敏捷性方面，速度可以用于评估每一个Sprint(Sprint指Scrum团队完成一定数量工作所需的短暂、固定的周期。通常为15-30天)，看看团队解决了多少用户问题。这一衡量方法并不是以个人完成了多少任务而论，而是看团队解决了多少用户问题(即用户想要的东西)。在衡量每一个解决用户问题的Sprint当中，我们可以用一个进度值来展现软件开发团队的完成和交付速度。

工作流程稳定性

软件团队的工作流在稳定性方面如何?由于稳定的工作流可以增强预测性，因此这是一个重要的KPI。如果跨Sprint的工作流不稳定，那么用户将难以预测下一步工作和最终交付情况。稳定的工作流可以证明团队和项目正在步入正轨，并且能够有效管理工作负载。

（编辑：江门站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!