我如何开始相信周期时间超过估算

循环时间是产生值所需的时间。在软件工程中，这是团队开始开发功能并向客户提供此功能之间的时间。大多数积压工具跟踪此数据并在控制图中显示。您可以使用循环时间数据来预测单个项目需要多长时间。您可以在此处找到更多的解释。

当我看到在每个人都知道估计是一个夏时，我一直在讲述以下故事。所以我以为我可以把它写下来并分享它。我相信这样的故事将解释这个理论，循环时间如何比以更生动的方式更好地估计。

在故事的时候，我与一个艰难的时间计划的团队合作。我加入了电梯和amp;转移到AWS和公司让我帮助控制。该平台由多种遗留系统组成，全部以复杂的方式工作。在迁移之前，将托管平台外包导致开发人员在之前未在管道和维护性上花费的时间。

由于许多操作事件，我们遇到了消耗我们平台的其他开发团队的问题。大多数新功能的工作都停滞不前。当我们完成新功能时，我们永远不会估计，因为工作可能会被生产突然消防所扰乱。经过一段时间并通过应用工程来提高可靠性，我们开始建立功能，人们再次开始请求预期的日期。我们估计这些日期，但由于不可预见的复杂性，我们没有使这些日期和时间再次。

当团队开始谈论一个新项目时，我们对我来说显而易见。我问了它是关于什么，团队表示他们已经在一年多里炼制了它，但从未来过它。该公司预计该团队将提供这一大项目，这将是未来的战略性。但这是不可想象的，我们将在即将到来的时间在这方面做任何进展。

所以我提出了我们推出这个项目，并有一个新的团队工作。新团队在一些增加时间后开始提供，但这支新团队仍然需要我们的平台上一些小功能的一些支持。

这支新团队要求在我们的平台和＃39; S的关键组件中有一个重要的功能。我们已经建立了这个功能，并在接受几个月内运行它。它通过一个特征标志在生产中关闭。生成此功能将是我们配置的简单变化，作为代码，并将其推动到生产。

在星期五下午结束时，项目经理问我们的团队何时提供此功能。在前几周，他已经给出了一些我们没有做出的估计。因此他不愿提供估计。当时，我告诉团队，我们应该停止估算，而应该做更深入的数据驱动计划。所以他问我：＆＃34;嘿，你会说什么？＆＃34;

我回答：让我们拉起控制图以查看我们的周期时间。在这里，我们靠显示器：项目经理，团队负责人和我。我将鼠标移到控制图上。弹出窗口显示我们的滚动平均值：＆＃39; 5d 6小时。我笔直站起来说：＆＃34;我们的平均时间是5天6个小时，标准差最多为2周。

从团队负责人的眼神中我可以看出混乱。我怎么能说我们估计需要10分钟才能完成五天的更改！我没有真正的答案，但我只是说，平均来说，这需要我们花费时间。但是不知何故，感觉确实不错。我们一致认为这将是星期一的第一件事。项目经理满意我们至少会为此工作，因此接受了答案。无论如何，这可能是他的目标，从我们以前的表现来看，我们并没有期望得到任何真实的约会。

在星期一，我们从站起来开始，并讨论了如何完成这项任务。另一位工程师建议先打开另一个组件上的错误，然后再打开标志。通过打开功能标记，我们会产生很多额外的负载。我们无法在接受环境中对此进行测试。此错误与负载有关。该组件将更可能通过修复它来处理它。我们决定这样做是因为，如果该组件发生故障，则整个平台都会崩溃。因此，这已经是一天的延迟。

归根结底，我看了看板，却没有发现该错误转移到“发布”列中。我聚集了团队，并询问几个小时后是否已准备好部署该错误修复程序。该错误修复程序已经过审查和测试，可以部署。但是由于它是整个平台的关键组成部分，因此有人提醒我们必须要询问发布经理。

因此，我们询问发布经理是否可以部署它。他爆炸了：＆＃34;我们无法部署它！我们需要要求所有团队测试此更改！如果我们对该组件进行任何更改，我必须通知管理层！这需要一整天。＆＃34;因此，我们计划在第二天发布它。

周二，我们将所有更改通知了所有团队，并要求他们进行测试。他们在白天进行了验收测试。他们发现没有问题，因此可以在合并的发行版中发布该错误修复程序。我们几乎不知道另一个团队的功能也包含在组合变更集中。此功能将中断生产。发布后，客户开始致电，因此发布工程师还原了发布。另一个团队第二天不得不修复此错误。

在星期三，另一个团队发现该发行版由于其新错误而失败，并开始对其进行修复。那天晚上计划了一个新版本，其中包含他们和我们的错误修复程序。因此，我们的错误修复终于在生产中。

因此，我们的错误修复程序终于在星期四投入生产。我们打开了功能标志。该功能开始在生产中可用，并且可以正常工作。

我们估计10分钟会导致4天5小时的循环时间。实践水平，系统的复杂性以及团队之间的协作的结合导致了这种延迟，并且存在于任何社会技术系统中。所有这些都可以改进，但这不是本文的重点。这需要时间和工作，而同时需要交付某些功能。作为人类，不可能考虑所有潜在的复杂性。这就是为什么我们无法正确估计。但是周期时间数据可以并且可以。

我们没有考虑具有错误和扩展问题的旧系统。但是我们在执行其他任务之前就遇到了这一问题。这种复杂性被记录在数据中。

我们没有考虑使用发布管理器来组合发布过程。但是之前的版本由于其他团队引入的错误而未能通过。但是跟踪工具确实可以测量先前任务完成时间中的这些延迟。

这个故事使我成为坚定的信徒，将周期时间用作计划工具。之后，我看到同一故事一次又一次地播放，但由于复杂性不同：第三方的成熟度，CISO等等。我现在不再给出任何估计。不使用估计值需要培训。但是计划是如此重要，以至于使用像估计这样的伪装是有害的。但是计划是如此重要，以至于使用像Estimation这样的伪装是有害的。

非常感谢Stanislav Pogrebnyak向我介绍#NoEstimates。所有照片均来自未飞溅。