在本文中，我将重点介绍如何有效地评估软件开发性能，并举例说明如何在FXStreet上实现它们。
多年来，已经进行了许多尝试来衡量软件团队绩效的困难。问题在于大多数模型都存在两个主要缺陷：
- 他们专注于产出而不是结果。
- 他们专注于个人绩效而不是团队或公司绩效。
在辉煌的过去中，一些公司使用许多代码行来衡量性能和生产率。这种方法的缺陷是显而易见的，通常可以维护的行数更少，但是另一方面，几行代码可能很难理解。因此，在大多数情况下，此KPI都不理想。
随着敏捷方法的引入，流行的度量指标是速度。尽管比代码行更好，但它仍然很棘手，仅适用于团队成员变化不大的孤立团队或公司。在大型组织中，此度量可用于比较团队之间的生产率，从而提高其估计值。
Nicole Forsgren的Accelerate提供了一种科学的方法来提高现代软件开发中的生产率。在回顾了2000家组织之后，Forsgren概述了有关如何改善公司文化和绩效的关键要点。在Accelerate中，Forsgren，Humble和Kim确定了4个度量标准，这些度量标准解决了前面解释的2个常见陷阱。
- 交付时间
- 部署频率
- 更改失败百分比
- 平均恢复时间（MTTR）
交付时间
交付时间可以告诉您从提出请求的客户到得到满足所需的时间。为了简单起见，我们对定义进行了一些更改，对于我们来说，定义是从开始一项任务到为客户提供价值（生产中）以来，需要花费多少时间。
我们使用Jira作为我们的任务管理工具，幸运的是，Jira拥有“控制图”报告。它向您显示任务（故事，错误等）处于特定状态的时间。因此，在每次冲刺之后，我们都使用此图表得出交付时间。
部署数量
部署数量告诉您一段时间内软件开发已部署到生产中的次数，通常是sprint。
由于我们使用Azure DevOps来管理CI和CD的管道，因此我们在发布过程中创建了一个步骤（PowerShell），该步骤存储了部署内容和部署时间。
更改失败百分比
变更失败百分比告诉您生产失败的变更百分比，包括修补程序，回滚，修复前瞻等。
这是最棘手的指标，可以采用多种策略来记录此KPI：
- 每次部署到生产中并且某些单元/集成/ ui /系统测试失败时，都在表中记录。
- 如果您有部署前的批准，则当有人拒绝部署时，会自动记录下来。
- 如果有人在部署后发现错误，则可以创建与部署关联的错误，并在每次冲刺之后对它进行计数。
在这种情况下，我们的方法是手动的，我们只查看sprint中的所有部署，以查找在短时间内两次部署相同服务的情况，并记下某个功能发布后是否有人发现了错误。
平均恢复时间
平均恢复时间告诉您解决紧急情况（如服务中断）所需的时间。
结论
在阅读了Accelerate之后，我决定将这四个指标付诸实践，看看是否可以作为一个团队来改善我们的软件交付流程。在过去的3个月中，我们一直在使用这种方法，我看到了2个优点：
- 最后，我可以向管理委员会中的非技术主管以及股东大会上的所有员工介绍有意义且易于理解的内容，仅因为这四个指标对每个人都很容易理解。
- 更好的是，由于我们的团队非常有竞争力，我们希望尽可能减少生产的交货时间。这使我们找到了一种新的更好的方式来拆分SCRUM故事。来自积压工作的每个子任务必须能够独立地部署到生产中。