衡量工程生产力是一个复杂的过程——很难全面了解开发人员如何度过他们的时间。衡量生产力的常见方法是分析 DORA 或 SPACE 等系统指标。这些是非常有用的指标，可以帮助您了解团队与行业标准相比的生产力。深入研究每个指标还可以深入了解是什么拖慢了团队的速度。 但有时，开发人员一天中也会花费一些“隐藏的”时间，这些时间可能不会被视为影响生产力。然而，当我们开始把这些东西加起来时，数字可能会令人震惊。 例如，考虑一下开发人员花费多少时间调试一个不稳定的测试，试图找出它是否因为他们的更改而失败。或者开发人员尝试解决主线构建失败所花费的时间。 为了提供这种视角，我们构建了一个计算器来评估工程效率。这决不能提供对您的工程团队效率的全面分析。 它确实提供了对浪费时间的“隐藏部分”的一瞥，这些时间通常不会出现在更常见的生产力指标中。 该计算器重点关注您和您的团队由于开发人员工作流程中的构建和测试失败而损失了多少时间。 如果将此与 DORA 指标进行比较，就会发现构建和测试不稳定性对变更的交付时间有显着影响。 可以使用此计算器来评估这种影响。 怎么运行的 我们要求您根据您的 GitHub 活动以及使用 GitHub 分支的方式输入数据。为了解释下面的实际计算，让我们为每个变量分配变量： M – 每天合并的 PR X – 一周内主线故障 T – 平均 CI 时间 F——片状系数% 根据这些输入，我们估计您的工程团队每周在管理构建失败和处理不稳定测试上浪费了多少时间。让我们一一看一下结果。 修复浪费了几个小时 这会计算在检测到主线构建失败时浪费了多少时间来识别、分类、修复以及再次构建通过。通常，在大型团队中，有人会注意到并报告损坏的主线构建。 我们假设主线构建失败平均需要 1-3 名开发人员进行调试和修复。如果我们考虑报告问题和推送修复所需的平均时间为一小时，那么我们将花费 来跟踪、调查和解决问题。 (2*T + 1) 小时 这意味着如果每周发生 X 次失败，我们每天都会花费 (( 开发人员时间来应对主线构建失败。 2 devs * X/5 * (2*T + 1)) 小时的 解决合并冲突浪费了几个小时 回滚和合并冲突可能会导致进一步的问题。假设在损坏的构建时间窗口内大约有 2% PR 存在合并冲突 ，并且每小时出现 PR，我们将花费 浪费在解决这些冲突上。 ((2*T + 1) * X/5) M/8 ((2* T + 1) * X/5) * 0.02 * M/8 由于构建损坏而导致每周 CI 失败 如果团队没有使用黄金分支作为其功能分支的基础，他们可能会在失败的主线分支之上创建功能分支。由于任何时间创建的 PR 数量与基于主线的功能分支的平均数量相似，这将导致每天发生 次 CI 失败。 (2*T + 1 小时) * X/5 * M/8 是时候解决 CI 问题了 大约需要 15 分钟的上下文切换来处理每次构建失败，即 小时的开发人员时间每天浪费在 CI 失败上。 (2*T + 1 小时) * X/5 * M/8 * 0.25 重新运行片状测试所花费的时间。 类似地，对于片状测试，调查测试是否片状或真实所需的上下文切换时间以及重新运行测试本身每次运行平均需要十五分钟。根据片状因素，开发人员每天会浪费 小时。 (0.25 * M * F / 100) 提高效率 尽管其中大多数都会影响与 在衡量工程团队工作流程的低效率方面，我们仍然只触及表面。构建和测试失败的影响还会导致延迟发布，从而影响其他 DORA 指标，例如 以及系统中不稳定测试的持续性，这可能会导致更高的故障率。 。 变更交付时间相关的 DORA 指标，但 部署频率、恢复服务的时间 了解有关 DORA 指标的更多信息 或者更多地了解他们的缺点。 我们构建 是为了解决大型工程团队面临的一些隐藏挑战。如今，使用 Aviator MergeQueue，许多工程组织可以在不破坏构建的情况下扩展其合并工作流程。与 这样的片状测试抑制系统相结合，团队每周可以节省数百个工程时间。 Aviator TestDeck 也发布 。 在这里
