在当今敏捷驱动的世界中，传统的kpi已经不是软件开发生产力的最佳衡量指标。以下是用于评估团队绩效、产出和士气的重新定义的衡量标准。
如果衡量软件开发生产力和跟踪团队绩效就像计算代码行或工作时间一样简单那就好了，但是软件工程团队的效率，就像任何技术或创造性工作一样，不能仅用数量来衡量。
工作质量和团队协作以直接和持久的方式影响生产力。此外，敏捷的迭代、技术的发展，以及软件开发生产力的易变和相互关联，因此无法用传统的关键性能指标（kpi）来衡量。其凯发在线的解决方案是重新考虑kpi，以适应当今定义大多数软件开发的发展趋势、扩大的团队和所需的敏捷性。如果计算代码行数不能对生产力进行准确地衡量，那么在软件开发中还能用什么衡量呢？如果计时很少能洞察到scrum已经前进了多远，那么衡量进展的正确标准是什么呢？
以下是更好地理解和衡量软件团队的进度和效率，以及实现在整个产品生命周期中以可接受和可预测的速度持续改进的4个重要的kpi。
问题解决
今天的软件开发既是一个高度战略性的过程，也是一个高度创造性的过程。每一次迭代都会带来来自客户的新见解、新考虑和新请求。软件团队解决这些问题的才智如何？
这是一个可以通过打开/关闭比率来评估的kpi：问题多久打开一次，软件开发团队管理它们的效率如何？这不是衡量团队生产问题的数量。衡量标准应该是关于更大的质量趋势：团队解决问题的效率如何？如果问题长期悬而未决，团队就很难解决问题。如果问题（多个或几个）在出现时得到有效处理，团队在创造性地解决问题方面得分很高，这意味着他们在合作中取得了成功。
速度
当涉及到预算和时间表时，敏捷项目可能更难预测，但团队仍在朝着关键的最终目标前进。了解他们实现这些目标的速度是衡量生产率的重要指标。与瀑布一样的时间线相适应的里程碑在灵活的、迭代的敏捷世界中不起作用，但是仍然有可能衡量进度及其速度。在敏捷中，通过查看团队满足了多少用户需求来评估每次冲刺的速度。它不是关于个人完成的任务数量，而是团队满足的用户需求（用户表示需要/想要的功能）。在衡量每个冲刺中满足的用户需求时，你可以得到一个比率，该比率表明软件开发团队朝着完成和发布日期前进的速度有多快。
工作流稳定性
软件团队的工作流有多稳定？这是一个重要的kpi，因为工作流的稳定性有助于提高可预测性。如果工作流程不稳定，那么预测下一步和最终交付就变得更加困难。稳定的工作流显示团队和项目已步入正轨，并能够管理工作负载。
工作流的稳定性通过将多个度量指标放在一起来评估，以查看团队的工作方式是否具有稳定性，例如：
• 正在进行的工作-已开始但未完成的项目数。
• 周期时间-任务从开始到完成需要多长时间。
• 吞吐量-已完成的工作项目/时间单位。
将这些工作流度量放在一起分析，可以全面了解团队是如何运作的。如果团队稳定地工作，他们的产出和进度会更可靠，发布预测也会更可靠。
团队士气
虽然很少有人认为士气可以作为衡量标准来考虑，但士气是每个kpi中的一个因素，因为它影响每个团队成员的努力和创造力。如果团队成员为自己的工作感到自豪，感到有价值和见多识广，被授权采取行动，并在项目中看到目标，他们将是更好的贡献者。他们将会开发出更好、更具创新性的软件。
企业可以简单地通过与他们的团队签到来衡量士气。例如，针对每一次冲刺的调查可以调查员工对沟通、团队合作、压力水平的感受，甚至他们在工作中感到的自豪感和趣味性。如果他们的工作自豪感在几次冲刺中都很低，这是一个更深入挖掘的机会。为什么团队成员会感到沮丧？是否有质量、压力或管理问题需要解决？了解更广泛的团队士气可以开启重要对话的大门。这些对话可以引发提高团队参与度和协作的知情行动。
士气，就像所有这些kpi一样，不是一个简单的一步衡量的标准。它需要对一段时间内的趋势进行更广泛地集体评估。就像敏捷本身一样，软件开发中的kpi随着每次迭代评估而变得更好、更有见识。好消息是，正确的关键绩效指标可以帮助平衡高点和低点，而不是开始时活力四射，结束时疲惫不堪。
凯发在线的版权声明：本文为企业网d1net编译，转载需注明出处为：企业网d1net，如果不注明出处，企业网d1net将保留追究其法律责任的权利。