团队软件库_领导敏捷团队的十大软件工程指标

我与CTO、工程经理和技术负责人进行的每次对话最终都会涉及到 “我们应该衡量哪些指标”的讨论。

经理们往往担心团队成员在引入新的衡量指标时可能会感到不安和抵触。

为此，我总是解释说，有一些非常有用，易于收集的衡量指标，可以帮助整个团队理解下一步应该关注和改进的地方。

什么是敏捷指标？

敏捷度量标准是一个涵盖性术语，它涉及你的软件团队可能已经在使用的潜在敏捷方法，无论是Scrum、看板，还是从待办事项管理软件(如Jira、Trello、Clubhouse等)中获得这些指标。

使用者：敏捷教练、产品经理、CTO、CPO、工程经理

以下是我推荐的十大软件工程团队衡量指标(源自我过去12年的从业经验)。

1.用户故事交付时间

衡量用户故事从开始到结束的时间。

我建议在将用户故事移到“In Development”栏时定义为“开始”，而在“release”栏时定义为“完成”。

重要的是使用一个可以帮助你解决这个问题的backlog管理软件，通常在它们的API和UI中有starting_at和finished_at字段。Jira和Clubhouse就是最好的例子。

尽管你可以将每个单独的交付时间绘制在图表上，但我更喜欢用百分比(更直观)，然后在每周的基础上把它们画出来。

2.用户故事产能

汇总每周或每月发布给客户的所有用户故事。

我还喜欢根据用户故事的类型(通常是“错误”、“功能”或“杂务”)将其分组，并在一段时间内将其可视化。

3. CFD(累积流程图)

我认为CFD是燃尽图的更好版本。在CFD中，你可以快速分析已完成的工作量，正在进行的工作量以及要达到预定义的里程碑还需要完成的工作量。

要构建CFD，你需要按时间序列(每星期效果最好)绘制每列中的用户故事总数。

工程指标

如果我们认为敏捷衡量指标与敏捷过程和用户故事有更多关系，那么工程衡量指标会告诉我们另一个故事：如何在内部完成工作以满足敏捷过程的要求。或者换一种说法，我们如何解释敏捷指标？

敏捷衡量指标可以告诉我们部分情况，但我们还需要掌握软件工程过程。质量是如何随着时间变化的?部署过程如何解释我们在CFD层面上看到的情况?我们的新员工入职流程有多好?

我遇到的一些最好的CTO手上都有一些工程指标，可以在C级董事会会议上很好地解释他们的团队正在执行的项目。

负责人：技术主管、工程经理、CTO

4. Pull 请求交付时间

关闭或合并一个Pull请求需要多长时间?

就像用户故事交付时间一样，最好使用百分比进行汇总，并按周或月进行分组。

这对于提出问题和及时查漏补缺尤其有用。我还喜欢将“Pull请求的交付时间”和“产能”合并到一个图表中，如下所示：

5. Pull 请求的产能

请考虑每周合并几个Pull请求。

你会很高兴看到团队活动水平的快速变化。

6.从提交到部署的时间

尽管你可以拥有高产能，但有时候在部署中交付的内容是“旧的”。

也许你没有任何现成的自动化部署实践。也许人们会花很长时间才打开一个Pull 请求。计算从提交到部署的时间是一种衡量整个软件开发过程的好方法。

7.部署频率

未投入生产的代码只是“旧库存”。

将代码发布到生产环境中应该是每个人的责任，并且有一个衡量标准来显示你每天执行了多少部署，这一点非常关键。

8. Rollbacks频率

监视要处理的Rollbacks次数与整个软件工程过程的质量密切相关。

9.编码测试比率

编码测试比率是衡量质量的另一种方法。但要注意这种方法很容易被开发人员操纵。

10.代码质量问题

每个代码库都存在技术债务、不干净的代码、花招和仓促的工作。

零代码质量问题并不重要，重要的是要理解随着团队规模的扩大，这个数字是如何随时间变化的，以及有更多的代码和存储库需要维护。

你可以发现代码中有问题的部分，这些部分可以解释Rollbacks、较长的交付时间和瓶颈问题。

在过去的12年中，这些指标已帮助我N多次在与我合作的每个团队中达到我的个人目标：持续改进。

作者：乔治·吉马良斯

SourceLevel首席执行官