如何用看板发布？ [关闭]答案

【问题标题】：How to release with Kanban? [closed]如何用看板发布？ [关闭]
【发布时间】：2010-08-09 00:33:25
【问题描述】：

在 Scrum 中，很明显我们可以在每个 sprint 之后制作一个演示。

我不知道如何在看板中制作演示，因为它没有 sprint 概念（我可能错了）。

您能告诉我如何在看板中发布版本吗？

感谢您的帮助和时间。

【问题讨论】：

标签： scrum kanban

【解决方案1】：

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

按计划每两周发布一次。
如果有足够多的便笺最终在板上的“已完成”存储桶中，值得进行非周期发布，请通知业务部门我们正在发布，这样我们就可以防止过于不同步。
业务部门需要针对立即需要的一组功能中的特定功能进行非周期发布。

真的很开放。

【讨论】：

如何知道“完成”下的当前卡片是否构成有效发布？它们不可能形成不相关的功能吗？
这在很大程度上取决于 QA 流程。对我们来说，“完成”意味着该功能在 QA 环境中由 QA 测试，并由在模型（生产克隆）环境中请求它的业务用户批准。存在特征对其他特征产生不利影响的风险，因为在模型中对整个系统进行回归测试成本高昂，因此我们必须在工作中努力做到这一点。这些功能可能不相关，但一旦获得批准，它们就会被批准。大型功能可以分解并分块发布，具体情况视具体情况而定。

【解决方案2】：

看板说明了如何管理工作流程和限制进行中的工作，但没有说明发布频率本身。但是，它要求很高，因为它要求始终保留产品的工作集成版本，并在新功能被认为完成后立即添加（完成，板上的最后一列）。

一个经常使用的概念是有一个“节奏”——这个“现成产品”被采用并实际部署到实时系统/交付时的定期间隔。

但是，我认为 Scrum 中非常明确的一个概念在这里也可能有所帮助。在 Scrum 中，明确表示 Scrum 要求在每个 sprint 结束时进行“可交付产品增量”（确认 DONE 的定义）。是否实际发布/部署它超出了开发过程的范围，因为它最终是一个业务决策。我认为同样适用于看板，随时都可以使用现成的集成产品，无论是否将其实际用作超出开发过程及其管理范围的业务决策。

【讨论】：

【解决方案3】：

没有单一的定义。通常在看板中，我们会添加 MMF（Minimal Marketable Features），根据定义，这意味着每个功能都应该为客户增加价值，因此您应该能够独立发布每个功能。

这并不意味着您必须单独发布每个功能，因此您会发现各种方法（David 提到了其中的一些）。我发现看板团队发布的频率高于他们遵循时间盒方法之一的常见情况。

看板中的演示是可选的，但如果客户愿意拥有它们，即使您独立发布每个功能，您也可以在部署时演示功能。从理论上讲，每个功能都应该增加价值，因此这种方法应该可以很好地发挥作用。

【讨论】：

【解决方案4】：

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

【讨论】：

【解决方案5】：

您可以尝试在 DOD 中添加签核步骤，以便安排快速演示。但不同的是，这将是一个一对一的演示，而在 scrum sprint 审查中，该演示面向所有参与者。

关于发布周期，在之前的答案中已经提到过。我想再补充一点，您可能对尚未发布的项目有限制。例如，如果您有 10 个 MMF 在板上准备发布，则可以立即启动发布过程。

此方法可以帮助您以某种方式跟踪吞吐量。

【讨论】：