大多数敏捷团队每月至少进行一次冲刺回顾，以迭代和改善其软件开发流程和工作流程。 但是，许多相同的团队仅依靠自己的感觉来“知道”他们是否真的有所进步。 但是，如果要比较两个sprint的运行方式，则需要一个无偏的参考系统。
根据您关注的重点，您可能会感兴趣一些指标。例如，如果您的团队使用估算值，那么跟踪这些估算值的结果可能确实值得，并且比较各个冲刺的方差可以提供这样的指标。
在本文中，我将不着重于作为您的工程团队的输出的指标，而是着重于显示团队合作状况的指标，这些指标将直接影响输出。 在您的Sprint回顾期间可能值得考虑它们。
本文实际上是软件工程指标高级指南的摘录。 无论您选择使用哪种指标，如果您想以无毒且有效的方式使用工程指标，都需要遵循一些规则。 有关该主题的更多信息，我建议阅读这篇文章 。
让我们先回顾一下什么是软件工程指标，哪些不是。
什么是软件工程指标？
在软件中，度量标准分为2类，我们为它们使用不同的名称：
软件工程指标 ，也称为软件开发指标，或软件交付性能，似乎每个团队都有不同的名称。 在这里重要的是这些指标可以衡量软件的构建方式和工程团队的生产率。 软件或应用程序性能指标是所交付软件的指标，应用程序的响应时间等。NewRelic通常是此类指标的主要提供者之一。 您还可以根据客户满意度指标（通常是净促销值）来考虑这一点。
在本指南中，我们重点介绍第一组指标。 这些是有助于组织扩展的因素，实际上会影响第二组，这是团队完成工作的最终结果之一。
要了解软件工程指标，我们需要了解跟踪和分析它们的主要目标：
确定当前软件交付过程的质量和生产率，并确定改进的领域；预测软件开发项目的质量和进度；更好地管理团队和团队成员之间的工作量和优先级。
总体而言，工程指标通过评估每个决策对项目，流程和绩效目标的影响，将帮助团队提高工程投资回报。
流程或工作流程指标
1. Lead Time and Cycle Time
前置时间是项目开发开始到交付给客户的时间。 您的软件开发团队的前置时间历史记录可以帮助您在项目准备就绪时以更高的准确性进行预测。 即使您的团队没有提供估算，该数据也很有用，因为这些预测可以基于类似项目的交货时间。
如果您想对客户做出更快的反应，通常可以通过简化决策和减少等待时间来缩短交货时间。 提前期包括周期时间。
周期时间描述了更改软件系统并在生产中实施更改所需的时间。 使用连续交付的团队可以将周期时间以分钟甚至数秒（而不是几个月）来衡量。
什么时候使用它们？
如果您的首要任务是实现连续交付，或者使您的流程更精简并更频繁地以较小的批次部署到生产中，那么这两个指标将非常有用。 在准备时间内，您还可以更深入地了解大部分时间在何处。
2. Deployment Frequency
跟踪部署频率是一个很好的DevOps指标。 最终，目标是尽可能多地进行更小的部署。 减少部署的规模使测试和发布变得更加容易。
部署到质量检查或预生产环境的频率也很重要。 您需要尽早且经常在质量保证中进行部署，以确保测试时间。 找到质量检查中的错误对于降低缺陷逃逸率很重要。 但是您可能想要分别计算生产和非生产部署。
什么时候使用？
从度量意义上来说，它可以很好地补充交货时间和生产周期。
3. Commit Frequency or Active Days
提交频率和活动天数具有相同目的。 活动日是指工程师为项目贡献代码的一天，其中包括诸如编写和检查代码的特定任务。
如果您想引入每天提交的最佳实践，则这两个替代指标很有趣。 这也是查看中断隐患的好方法。 诸如计划，会议和制定规范之类的非编码任务是不可避免的。 团队通常每周至少损失一天的时间进行这些活动。 通过监视提交频率，您可以查看哪些会议对您的团队推送代码的能力有影响。 切记， 推动代码实际上是团队为公司提供价值的主要方式 ，这一点很重要。
管理人员应努力保护团队的注意力，并确保过程开销不会成为负担。
什么时候使用它们？
您是否听说过“经常提交，以后完善，发布一次”？ 如果您没有提交，然后做一些周密的考虑，就会遇到麻烦。 承诺是团队内部协作的共同标准。 因此，如果您推动工作流提交的次数比团队当前的提交次数更多，那么跟踪此指标可能会很有用。 另外，如上所述，如果您想了解中断的影响，则此指标可能是一个很好的起点。
4. Pull Requests-Related Velocity
有几个指标可能会让您感兴趣。
每周打开的拉取请求数，每周合并的拉取请求数，平均合并时间。 一些替代方案可以是在特定时间下合并的拉取请求的百分比。 这在某种程度上等于周期时间（代码从提交到部署到部署所花费的时间：在此之间，它可能要经过测试，QA和登台，具体取决于您的组织）。 这是一个非常有趣的指标，它向您显示工作流程中遇到的障碍。
什么时候使用？
这些指标可以使您了解工程团队的持续吞吐量。 例如，如果雇用更多人时这个数字没有增加，则可能存在与新流程或需要解决的技术债务有关的问题。 但是，如果它增加得太快，则可能存在质量问题。
5. Work In Progress (WIP)
进行中工作是您的团队已打开且正在处理的票证总数。 它是衡量团队速度的客观指标，类似于吞吐量，是一种实时指标（而不是落后的指标）。
该指标有助于理解团队当前的工作量趋势。 理想情况下，人数会随着时间的推移保持稳定，因为WIP的增加意味着您的团队面临着无法解决的阻碍者/瓶颈（当然，除非您添加了团队成员）。 WIP还是一种识别低效流程的方法。
您可能还考虑创建一个指标，该指标将WIP除以贡献者数量，以获得每个开发人员的平均WIP数量。 理想情况下，该数字将接近一对一的比率。
什么时候使用？
该指标有助于避免倦怠并提高效率，因为一次完成一件事情已被证明可以改善注意力。
6. Commit or Pull Request Risks
您可以通过以下方法确定提交或请求中的风险：
更改中的代码量对旧代码进行编辑的工作量更改的表面积（请考虑``编辑位置数''）受影响的文件数修改旧代码时更改的严重性与以前的代码相比，此更改与其他代码相比项目历史
它显示了提交过程中的反思和工作量，因此，如果不进行代码审查就进行部署，则可能会对产品产生潜在影响。
什么时候使用？
监视平均提交或请求请求风险可以帮助您了解团队的工作方式，以及是否应该争取更频繁，更简单的代码更改。
请注意，某些指标可能未列入列表，因为它们不够流行，或者仅适用于某些情况（例如估算值）。 我试图主要关注所有团队可能通用的指标。
您可能要记住的某些指标也可能是我在其他文章中谈到的与速度相关的指标和与质量相关的指标的一部分 。
如果我错过了任何事情，请告诉我您的想法。 最终目标是建立有关软件工程指标的最佳实践的全面列表，以帮助团队改进自己的流程。
最后，如果您想让您的团队拥有软件工程数据以支持更好的协作和决策，请查看我们在Anaxi建立的软件工程管理平台，该平台可将您的系统，数据和人员聚集在一起。
最初于 2019年7月30日 发布在 https://anaxi.com 。本文是系列文章的第一部分。 阅读更多：
From: https://hackernoon.com/how-to-use-data-to-improve-your-sprint-retrospectives-k0y630qx
3380
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
