如何发布看板[[关闭]

当我在上一份工作中实施看板时,发布采用了以下三种方式之一:

1. 按计划每两周发布一次。
3. 业务单元需要一个周期外版本,用于立即需要的一组功能的特定功能。

看板说明了如何管理工作流程和限制正在进行的工作,但没有说明发布的频率。然而,这是相当苛刻的,因为它要求始终保持产品的工作集成版本,新特性一旦被认为是完整的(完成,在黑板上的最后一列)就被添加。

一个经常使用的概念是有一个“节奏”——当这个“现成的产品”被获取并实际部署到实时系统/发货时的一个固定间隔。

然而,我认为Scrum中非常清晰的一个概念在这里也可能有所帮助。在Scrum中,有人明确地说Scrum要求在每个sprint结束时进行“可交付的产品增量”(符合DONE的定义)。是否实际发布/部署它超出了开发过程的范围,因为这最终是一个业务决策。我认为看板也是一样的,一个现成的、集成的产品在任何时候都是可用的,是否真的把它作为一个业务决策来使用,这超出了开发过程及其管理的范围。

没有单一的定义。通常在看板中,我们添加mmf(Minimal Marketable Features),根据定义,mmf意味着每个特性都应该为客户增加价值,因此您应该能够独立地发布每个特性。

这并不意味着你必须分别发布每一个特性,所以你会发现各种各样的方法(David提到了其中的一些)。我发现一个常见的情况是看板团队发布的频率比他们遵循一种时间限制的方法要高。

看板中的演示是可选的,但如果客户愿意,您可以在部署时演示功能,即使您独立地发布每个功能。理论上,每个特性都应该增加价值,所以这种方法应该很好地工作。

我们将演示作为将功能从“测试”移动到“准备发布”的条件。所以它是一个特性一个特性地运行,而不是一个特性一个特性地运行,特性的性质将决定演示的性质。开发过程中的业务参与越多,问题就越少。

关于发布周期,在前面的回答中已经提到了。我想补充一点,你可能有一个尚未发布的项目限制。例如,如果你有10个MMF在板上准备发布,那么发布过程可以随时启动。

这种方法可以帮助您在某种程度上跟踪吞吐量。