kanban板的迭代过程建模

Question

看板确实假定了一个或多或少的线性流.在大多数情况下，这个软件开发模型很安静:我们将一个用户故事打包，编写代码，测试它，然后部署它。然而，有些内部阶段在性质上是迭代的，因此不太明显。以这个(简单化)板为例：

||   Planning   ||  Development ||     Test     ||     Deploy   || Done ||
|| doing | done || doing | done || doing | done || doing | done ||      ||
||       |      ||       |      ||       |      ||       |      ||      ||

让我们关注规划专栏。如果这是开发用户故事的地方，那么显然需要某种迭代:编写故事、细化/对话、改进故事、客户反馈等等。这些阶段根本不是以董事会为蓝本。

让我们关注一下Test列。一旦一个故事(或任务/诸如此类)被测试:一些测试将通过，一些将失败。因此，这个故事需要更多的研究。它是否应该返回到“发展”栏？保持在一个特殊的测试/开发？应该有测试/失败和测试/通过列吗？过于复杂的董事会不是一个最佳解决方案。

您应该使用看板来建模迭代过程吗？

如果是这样的话，是怎么做的？若否，原因为何？

Answer 1

我认为看板的目的是非常迅速地展示目前的一切，以及一个简单的方式把东西从一个区域转移到另一个地方。

有一些细节，特别是关于历史或特定的故事所走的道路。你可能需要一个独立的功能，你的董事会，更多的是一个日志，一个故事。

这里有两个故事，假设它们同时开始了第二步(第一阶段开发)。例子:故事"A“

1. 规划
2. 开发
3. 测试
4. 开发
5. 测试
6. 开发

示例:故事"B"

1. 规划
2. 开发

两个故事"A“和"B”都在发展中，但这两个故事显然都有不同的地方。故事A是被送去测试的速度太快了，还是更复杂？当另一个人参与到这些延迟的故事中时，kanban板只会提供足够的信息来表明它们还在开发中，而没有显示测试和开发之间迭代的细节。

如果这是一个问题，您可能需要其他类型的报告。不幸的是，在纸质系统中，您需要跟踪故事从一个地方转移到另一个地方的日期/时间。问那些参与的人，“进展如何？”也许更实用些。

Answer 2

从你在这两种情况下说的话来看，工作项目仍将在“做”一栏中，似乎有不同的“做”阶段。

也许，如果你想要追踪到这个精细的细节水平，你可以为每个阶段的董事会。因此，规划委员会看起来可能如下：

|| Write Story  ||     Refine   || Customer Feedback ||
|| Doing | Done || Doing | Done || Doing | Done      ||

然后在这些板中来回移动您的工作项目，同时将高级别的工作项目保留在in列中，直到下板完成为止？

Answer 3

您应该使用看板来建模迭代过程吗？如果是这样的话，是怎么做的？若否，原因为何？

你从建模/跟踪中得到了什么？除非开发开始的故事还没有准备好(客户从来没有看到过，模棱两可等等)，否则你就会解决一个你没有的问题。

实际上:您不需要跟踪编码的每一个阶段(编写测试、编写API、编写代码、编写更多的测试、本地验证、推送、CI正在进行、CI结果验证)，因为您希望负责故事的人能够妥善地处理这些问题。为什么不对PO抱有同样的期望呢？