软件开发项目 衡量指标
您是否听说过通过度量标准来管理团队，例如错误关闭率或每周生成的代码行？ 根据这些指标，最差的表现者将被放任。 接下来发生什么？ 团队将只关注那些毫无意义的易于修复的错误，以“ 欺骗统计数据 ”！ 最终，产品质量变差，而不是变好，也许还会有一些有价值的开发人员离开。 难怪开发人员不信任生产力指标。 “我从来没有见过使用过的功能正常的指标。”
在本文中，我想揭穿软件开发效率度量标准的神话。 我们将看一下以下列表：
- 您应该谨慎使用的指标-这意味着它们在特定条件下以及以特定方式使用时可能会很有趣；
- 无论您是贡献者，主管还是经理，您都应该在团队中真正引入有用的建议。
好吧，让我们做吧！
您应谨慎使用的指标
1）门票关闭率
如果您不包括故事点或类似内容，则这可能是您可以使用的最具误导性的指标。 使用此度量标准假设所有票证的工作量大致相同，而事实并非如此。 您永远不要使用此指标来评估开发人员的个人绩效 。 开发人员可以修复一个没人能解决的错误，该错误会影响产品性能的各个方面，并且可能需要花费整整一周的时间。 而另一位开发人员可以同时修复20个详细的错误。 哪一个对您的团队和公司影响最大？
即使您有故事点，在上述情况下的最佳情况下，该错误的故事点也将为5，或者20个错误的故事点将分别为1。 但这并没有考虑到大多数团队都不会将漏洞用于漏洞，而只会用于功能。
话虽如此，您可以使用此指标来确定问题，例如开发人员被困在特定任务上。 关键不是要用它来评估开发人员的绩效，否则您的团队将在不做任何有意义的工作的情况下衡量指标 。 仅将此度量用作了解您作为经理的方式可以如何更好地帮助您的团队的一种方式。
2）产生的代码行（LoC）
在上面的同一示例中，巨大的错误修复可能是一行代码的更改。 您如何将其与导入库或更改每个文件的每个标头的开发人员进行比较？ 你不能。 同样，您永远不应使用此指标来评估开发人员的个人绩效。 您可以以相同的方式使用LoC-了解您的团队何时遇到困难，或者可能出于项目质量的考虑而导入过多的库！
有些人根据更改中的代码数量，更改的严重性以及更改影响的文件数量来计算“影响”量度。 总体目标是对LoC进行改进。 这很有趣，但是我强烈建议不要将它们用于个人绩效评估。 实际上，正如许多其他现实生活中的例子所示，上面提到的单行错误修复示例仍然无法正常工作。
3）代码搅动与代码吞吐量
关于什么是代码搅动，有许多不同的定义。 通常用开发人员自己的代码（代表对自己最近工作的编辑）的百分比来衡量。 流失率的突然增加可能表明开发人员在解决特定问题时遇到困难。
有些人认为代码搅动是非生产性的工作，不在“代码吞吐量”之内，这就是危险所在。 确实，代码变更可能表明开发人员正在优化部分代码以获得更好的性能。 或者，产品团队只是优柔寡断，让开发人员围成一圈。 规则是监视所有重大更改，以识别开发人员可能遇到的潜在问题，以帮助团队更快地工作。
您可以将任何指标用于个人表演吗？
好吧，既然您（好吧……我）提出了一个问题：不！ 是的，您可以在此引用我的信息。
指标是主观的和信息性的。 您无法根据指标对个人表现做出任何判断。 它们只会帮助您进行查询，以了解实际发生的情况，从而更好地了解项目和团队管理的复杂性。
现实情况是，管理是困难的，总是与环境相关的。 您需要更深入地了解问题的根本原因。 有时您会发现，实际上，开发人员实际上是一个绩效不佳的人，但这是因为您努力了解您的团队并了解他们如何协同工作，因此您可以确定是否有一个成员将其拖了下来。 这就是您成为一名更好的经理的原因，他致力于提高生产率和团队内的忠诚度。
而且，如果您有这样的想法，则可以正确使用上述前三种指标。 您还将途中使用更有用的指标，这将有助于您对团队的工作流程速度和质量有很好的了解。
您应绝对使用的指标
我将在两个不同的类别中列出这些指标：速度和质量。 让我知道是否忘记了； 我很乐意更新这篇文章。
速度相关指标
这些度量标准最具争议性，因为许多人（包括我）学会了讨厌敏捷的故事点。 但是，我希望这里有一些替代方法，希望它们使您三思而后行，不应该测量“速度”。
4）提交频率
如果您想引入每天提交的最佳实践，则此指标很有趣。 这也是查看中断隐性成本的好方法。 诸如计划，会议和追踪规格之类的非编码任务是不可避免的。 团队通常每周至少损失一天的时间进行这些活动。 通过监视提交频率，您可以查看哪些会议对您的团队推送代码的能力有影响。
管理人员应努力保护团队的注意力，并确保过程开销不会成为负担。
5）服务水平协议（SLA）
每个团队都有自己的SLA定义。 但是，这是Airbnb使用的一种，我个人觉得非常有趣。 SLA是您的团队在特定时间内修复和部署的阻止程序错误的百分比（例如，阻止程序错误为24小时，严重错误为5天）。 我真正喜欢这个指标的地方是，它可以让您从用户的角度深入了解产品质量 。
请注意，在我看来，该指标与速度相关，因为它显示的是团队的速度，而不是所生产软件的质量。
6）拉取请求相关的速度
- 每周打开的拉取请求数
- 每周合并的拉取请求数
- 每周生产部署的数量
- 平均合并时间（或在特定阈值下合并的合并请求（PR）的百分比）。 这在某种程度上等于“提交到部署的时间”（代码从提交到部署所花费的时间：在此之间，它可能要经过测试，QA和登台，具体取决于您的组织）。 这是一个非常有趣的指标，向您显示您在工作流程中遇到的障碍。
这些指标可以使您了解工程团队的持续吞吐量。 例如，如果雇用更多人时该数字没有增加，则可能存在与现有新流程或需要解决的技术债务有关的问题。 但是，如果它增加得太快，则可能存在质量问题。
不要忘记，在不评估工作质量的情况下衡量团队的速度可能会极具误导性，并且非常危险。
与质量相关的指标
质量本身并不是目标。 重要的是能够以安全的方式发展和改变行为的信心。
7）测试覆盖率
当然，您不需要100％的覆盖率。 但是，了解自己的位置并对其进行跟踪有助于查看您是否以速度为质量。
8）拉要求质量
拉取请求可以使您对代码库的整体复杂性有很好的了解。 代码库越复杂，以下度量标准变高的可能性就越高：
- 拉取请求中断构建或无法通过测试套件的时间百分比；
- 合并与拒绝拉取请求的百分比；
- 拉取请求的评论数-您不希望数字太低，但也不要数字太高。
9）项目中的错误数量
通常，错误的数量将在项目生命周期的中期开始增加。 在截止日期之前的几天或几周内（取决于项目的大小），团队将集中精力减少bug的数量，直到bug的数量达到渐近线为止。 该渐近线最终代表了项目产品的整体质量。 因此，跟踪错误的总数 （区分其优先级）是一个很好的指标。
另一个指标可以是每周或每月发现的错误或错误修复与所提供功能的数量。 它应该指出实施的质量水平。
10）依赖年龄
技术债务的另一个指标是代码库中使用的依赖项过时的程度。 跟踪这一点可能会很有趣。
技术债务是正常现象，将出现在每个项目中，质量概念是主观的。 使用度量标准（例如我在本文中讨论过的度量标准）可以帮助您与团队一起定义一组标准，这将有助于您对团队的工作质量有所了解。
-
本文的重点是，如果您在项目或团队级别衡量指标，则开发人员将不会使用这些指标。 正如@raffi所说 ：“您不能玩自己无法衡量的东西。” 游戏指标始终是肤浅的。
如果您不同意我列出的任何指标，或者我错过任何指标，请告诉我。 让我们考虑将本文作为对话的起点。
你走之前…
学到了什么？ 不要犹豫，分享它以帮助他人找到它！
如果您对有关工程和产品领导力，生产力以及如何扩大团队规模的文章感兴趣，请订阅我们的新闻通讯！
或加入我们的工程领导社区 。
您还可以查看我的最新文章：
您也可以在Twitter上关注我以保持联系。 谢谢！
最初于 2018 年11月25日 在 anaxi.com 上 发布 。
翻译自: https://hackernoon.com/do-not-measure-developers-measure-projects-12e8bdd41064
软件开发项目 衡量指标
3844
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
