如何确定最大吞吐量的最佳释放频率？

Question

我的工作是一个大型软件程序--金融服务的100名开发人员。

连续积分的共同智慧是从您的更改中尽早获得反馈。

连续交付的普遍观点是，通过善于释放小块，可以减少失败的风险，因为您可以轻松地回滚--因此，释放小块可以帮助您快速和经常地交付到生产中。

精益中的业务价值图允许我们看到从左到右的业务价值流(类似于生产线)，由此您可以确定您的更改项被卡在哪里，以及流程中的瓶颈在哪里。

软件开发的挑战是准确地确定生产线上的小部件是什么。

如果您阅读了凤凰工程，那么这些更改就是在系统中流动的变更记录(尽管这是以IT基础设施为重点的)。如果你和一个Scrum大师交谈--那么整个系统的变化都是故事。如果您与开发人员交谈，则在系统中进行的更改是GIT提交。(这可以而且应该与故事相一致)。

简单的现实是，由于回归测试的事务成本，我们每个月做一次小版本，每三个月做一次大版本。(Don的书“产品开发流程原理”对循环时间和交易成本的权衡是惊人的。

因此，在我看来，在试图识别系统上的约束时，批处理大小本身就是一个约束，而不是找到一个项目正在堆积的工作区。所谓批次大小，我指的是一个版本中可交付的数量。每个月都有大量开发人员发布，将会有大量的故事/提交。我在试着量化这个。

我们知道，批量规模的经济性是一个u曲线优化问题，回归测试和发布的交易成本是相当大的。

我的问题是:如何确定最大吞吐量的最佳发布频率？

Answer 1

我也一直在考虑这个问题，为了做到这一点，我认为你首先需要一个假设。我想从这里开始：

回归开销

您受回归测试的最短时间的约束。我要断言，你不能比这更快地释放。我认为这方面的基本公式将基于以下组成部分：

• 测试所有未更改的功能所需的时间
• 更新/添加功能所需的时间
• 测试新特性/更改功能所需的时间

随着时间的推移，回归的时间会随着时间的推移而增加，但边际增长率会随着时间的推移而减小。你的情况可能会有所不同，但我想我们可以假设这是固定的。如果它显著增长，在任何固定频率上释放都是不可持续的。

缺陷与修复

的时间

假设1

让我们假设在发行版中发现的缺陷数量与版本中的特性数量成正比。我们还将假设修复和重新测试这些缺陷的时间与缺陷的数量成正比。

假说2

同样，我们假设在发行版中发现的缺陷数量与版本中的特性数量成正比。但是现在我们假设修复和重新测试这些缺陷的时间是一些缺陷数的函数，而不是一个直接的倍数。原因是，如果您发现了一些缺陷并修复了它，那么必须再次运行回归测试。这些缺陷阻止了其他一些缺陷被发现。这就为修复缺陷创造了一个准备时间。

检验假设

为了确定这两种方法是否符合实际情况，我认为您需要确定/猜测回归测试一切的最小时间。你不能跑得比那快。然后，您需要尝试不同的发布计划。这可能需要一些尖峰。然后，开始对功能的数量进行回归时间分解。你可能会看到这样的东西：

或者看起来是这样：

绿色是你回归基线的时间。或者看起来完全不同。根据我的经验，这更像是后者。

如果是前者，它将建议您应该使用非常长的发布周期，因为这样可以将基线回归的开销降到最低。然而，还有一个你没有提到的因素:业务价值。如果某项功能为公司产生价值(如果不这样做，为什么要这样做)，那么投入生产所需的时间越长，增加的价值就越少。因此，即使这是一个直线成本，你需要考虑这一点。

一旦您理解了这种关系，那么我认为您很可能希望使一组特性的开发时间与这些功能的QA时间相匹配(考虑到修复缺陷、更新测试、磨锯子等其他开销活动)。