如何使用看板发布?

8
在Scrum中,每个迭代结束后我们可以很明显地制作演示文稿。但是在Kanban中,由于没有迭代概念(我可能错了),我不知道如何制作演示文稿。请问你能否告诉我如何在Kanban中发布版本?感谢您的帮助和时间。
5个回答

6
当我们在上一份工作中实施看板时,发布会有以下三种情况:
  1. 按照时间表每两周发布一次。
  2. 如果足够多的便利贴被移到“完成”桶中,以至于需要一个额外的发布,就通知业务部门我们将要发布,这样我们就可以避免过度不同步。
  3. 业务部门需要针对特定功能或一组需要立即使用的功能进行额外的发布。
实际上,这相当自由。

如何知道当前“完成”下的卡片是否形成有效的发布? 它们可能形成无关的功能,这是不可能的吗? - Chiron
这在很大程度上取决于质量保证流程。对我们来说,“完成”意味着该功能已在质量保证环境中经过质量保证测试,并得到了在模型(生产的克隆)环境中请求该功能的业务用户的批准。由于在模型中对整个系统进行回归测试成本过高,因此存在功能对其他功能产生不利影响的风险,所以我们在工作中必须非常谨慎。这些功能可能是无关的,但一旦获得批准,就被视为批准。大型功能可以分解并分阶段发布,具体情况要具体分析。 - David

6
看板方法是如何管理工作流和限制在进行中的工作的数量,它并没有明确说明发布频率。然而,这种方法要求始终保持产品的一个工作集成版本,并在完成新功能后立即添加(完成,看板上的最后一列)。这是相当严格的要求。
经常使用的概念是“节奏” - 定期将这个“准备好的产品”拿出来,并实际部署到现场系统/发货。然而,我认为,在Scrum中非常清晰的一个概念在这里也可以起到帮助作用。在Scrum中明确指出,每个迭代结束时都需要一个 “可出货的产品增量” (符合定义),但是否实际交付/部署则不属于开发过程的范畴,因为这最终是一个业务决策。同样,我认为这也适用于看板方法,一个准备好的、集成好的产品随时可用,是否实际使用则是开发过程及其管理范围之外的业务决策。

2

没有一个单一的定义。通常在看板中,我们会添加最小可销售特性(MMFs),这意味着每个特性都应该为客户增加价值,因此您应该能够独立发布每个特性。

这并不意味着您必须分别发布每个特性,因此您会发现有许多方法(David提到了其中一些)。我发现看板团队通常比他们遵循时间框架方法时更频繁地发布。

Kanban中的演示是可选的,但如果客户愿意,您可以在部署时演示功能,即使您独立发布每个功能。理论上,每个功能都应该增加价值,因此这种方法应该很有效。


0
我们将演示作为将功能从“测试”移至“准备发布”状态的条件。因此,这是逐个功能而不是逐个迭代完成的,而功能的性质将决定演示的性质。在开发过程中业务参与越多,这个问题就越不成问题。

0

你可以尝试在你的DOD中添加一个签署步骤,安排一个快速演示。但是不同之处在于,这将是一对一的演示,而在Scrum冲刺回顾中,演示是为所有与会者准备的。

关于发布周期,它已经在以前的答案中提到了。我想再补充一点,你可以设置未发布项目的限制。例如,如果你有10个MMF已经准备好发布,那么发布流程就可以立即启动。

这种方法可能有助于以某种方式跟踪吞吐量。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接