在 Scrum 中,很明显我们可以在每个 sprint 之后制作一个演示。
我不知道如何在看板中制作演示,因为它没有 sprint 概念(我可能错了)。
你能告诉我如何在看板中发布吗?
感谢您的帮助和时间。
看板说明了如何管理工作流程和限制进行中的工作,它没有说明发布频率本身。但是,它要求很高,因为它要求始终保留产品的工作集成版本,并在新功能被认为完成后立即添加(完成,板上的最后一列)。
一个经常使用的概念是有一个“节奏”——这个“现成产品”被采用并实际部署到实时系统/交付时的固定间隔。
但是,我认为 Scrum 中非常明确的一个概念在这里也可能有所帮助。在 Scrum 中,明确表示 Scrum 要求在每个 sprint 结束时进行“可交付产品增量”(确认 DONE 的定义)。是否实际发布/部署它超出了开发过程的范围,因为它最终是一个业务决策。我认为同样适用于看板,随时都可以使用现成的集成产品,无论是否将其实际用作超出开发过程及其管理范围的业务决策。
当我们在我上一份工作中实施看板时,发布采用了以下三种方式之一:
这是非常开放的,真的。
没有单一的定义。通常在看板中,我们添加 MMF(最小可销售功能),根据定义,这意味着每个功能都应该为客户增加价值,因此您应该能够独立发布每个功能。
这并不意味着您必须单独发布每个功能,因此您会发现各种方法(David 提到了其中的一些)。我发现看板团队发布的频率高于他们遵循时间盒方法之一的常见情况。
看板中的演示是可选的,但如果客户愿意拥有它们,即使您独立发布每个功能,您也可以在部署时演示功能。从理论上讲,每个功能都应该增加价值,因此这种方法应该可以很好地工作。
我们将演示作为将功能从“测试”转移到“准备发布”的条件。所以它是逐个特性的,而不是逐个冲刺的,特性的性质将决定演示的性质。开发过程中业务参与越多,问题就越少。
您可以尝试在 DOD 中添加签核步骤,您可以在其中安排快速演示。但不同的是,这将是一个一对一的演示,而在 scrum sprint 审查中,该演示适用于所有与会者。
关于发布周期,在之前的答案中已经提到过。我想再补充一点,您可能对尚未发布的项目有限制。例如,如果您有 10 个 MMF 在板上准备好发布,那么发布过程可以立即启动。
此方法可以帮助您以某种方式跟踪吞吐量。