【问题标题】:Kanban Board Flow and Columns' Relationships [closed]看板流程和列的关系[关闭]
【发布时间】:2010-07-06 12:11:33
【问题描述】:

鉴于看板上的基本流程:

| Backlog | Dev | QA | Deploy |

在阅读书籍/文章/演示文稿后,它大致变成了

Business  -> | Backlog | Input |     Development    |         QA         | Deployment | Closed |
Marketing -> |         | Queue |--------------------|--------------------|    Queue   |        |
Other   ->   |         |       | Queue | WIP | Done | Queue | WIP | Done |            |        |

所以我想不通的问题:

  1. 积压与输入队列与开发队列关系。 PM 优先考虑该版本的待办事项中的 MMF 并将它们移动到输入队列中,dev(基于 WIP 限制)取一个并开始处理它(WIP 列)。开发队列是做什么用的?应该是 PM 将内容从 Backlog 移动到 Dev Queue,然后 dev 将它们移动到 Dev WIP,还是应该 PM 将内容从 Backlog 移动到 Input Queue,然后 dev 取一个并将其移动到 Dev WIP?我不明白为什么看板的例子会说有 Backlog、Input Queue 和 Dev sub-Queue,每个都有自己的用途吗?

  2. dev 将已完成/已解决的工作项移动到哪里,Done 和 next Queue 列之间的关系是什么?如果不需要质量检查怎么办?例如,当 Dev WIP 完成时,您可以将其移至 Dev Done,QA 会将其从那里拉入 QA WIP。或者从 Dev WIP 到 QA 队列或部署队列(当不需要 QA 时)。在第一种情况下,即使描述过于技术性或过于模糊,QAer 也需要了解并检查 Dev Done 列中的每一张票。在第二个 Dev Done 被绕过,QA 失去了对部署内容的控制/监督。此外,是否应该有部署队列或已关闭?多亏了 CI,部署是一键式的,但是在将其移动到 Closed 之前,遍历每个开发任务并将修订号与刚刚部署的版本相匹配听起来像是一种负担……

有什么想法吗?或者,也许您知道真实世界的看板及其流程设置的详细示例?我知道我应该绘制出真实的现有流程并随着时间的推移发展/改进它(Kaizen 作为对出现的瓶颈/问题的反应),但如果是一个新团队/项目,那么完美的流程是什么?

【问题讨论】:

  • 不存在一般完美的流程。一个例子:QA 很可能包含在 DoD 中。

标签: agile kanban


【解决方案1】:

保持简单。恕我直言,您的实施太复杂了。我读了你的帖子三遍,仍然没有理解所有内容;)检查以下网页。

http://www.limitedwipsociety.org/2009/11/16/kanban-example/

http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html

【讨论】:

    【解决方案2】:

    理想的董事会取决于项目/团队,因此没有单一的答案,即使对于新项目也是如此。与您的团队讨论流程,从简单开始,定期回顾。但我在我的帖子Kanban in a nutshell 中有描述。

    除非您的流程要求进行某种移交,否则您不需要同时使用“完成”和“队列”列。至于谁在列之间移动项目,目标是“拉”而不是“推”。

    【讨论】:

    • 感谢您对“完成”、“队列”和移交的澄清。但是,虽然我理解这个想法,但它对我来说仍然是违反直觉的。即使你有交接,为什么不把事情从完成拉到进行中呢?我觉得这些队列列有利于创建工作队列(因此​​,大批量)。没有直接的暗示,但这是我的感觉。我错过了什么?
    • 在后面的列中进行活动的个人或团队可能已经被占用(可能已达到极限)。在两个阶段之间有一个缓冲区反映了当前没有处理工作项的现实。一个很好的例子(在大卫安德森的书中很好地描述了)是优先队列。如果优先级论坛只是定期举行会议,那么拥有足够大的缓冲区实际上是一件好事,这样下游活动就不会被饿死。此外,花在排队上的时间是一件非常好的事情。它可以告诉你很多关于下游瓶颈的信息。
    • 非常感谢您的解释和书籍建议。顺便说一下 +1。
    【解决方案3】:

    没有完美的流程...如果您有现有的团队,请从当前流程开始。保持简单,务实,无论是现有团队还是新团队。

    我们在几个地方使用“done”子列,对 working 和 done 子列有共同的 WIP 限制。这样,我们既启用了拉取行为,又限制了整个步骤的 WIP。

    队列的典型用途是在瓶颈之前优化流程。非瓶颈应该使用 slack 来学习和改进,但瓶颈(如果你能识别它)会限制整个团队的表现。

    关于最后的“完成”栏,我会在门票方面务实。但是,我会在董事会上更具体地讨论列名。 “关闭”是指在生产中还是在您的测试服务器上?只需将其放在列名中即可。

    【讨论】:

      【解决方案4】:

      您的两个问题实际上是相同的。简短的回答是开发队列和输入队列应该是同一个东西,即你需要一个或另一个,但不是两者都需要。 dev done 和 qa queue 也是一样的,它们是一样的。队列或上游完成列的点是向下游阶段指示有工作等待完成。这些列还用于强制执行 wip 限制。

      我的建议是,即使是在一个新项目上,也要按照团队当前的工作方式进行映射,然后从那里使用 Kaizen。看板(和 Scrum)的全部意义不是告诉你如何工作,而是让事情变得可见和明确,这样你自己就可以发现问题并改变你的系统或流程。它适用于经验数据,这意味着您不一定事先知道应该采取的方向。看板作为一种工具/技术存在,通过反复试验为您指明方向,并使事物可见。

      【讨论】:

        【解决方案5】:

        Backlog & Input Queue & Dev Queue 关系。 PM 优先考虑该版本的待办事项中的 MMF 并将它们移动到输入队列中,dev(基于 WIP 限制)取一个并开始处理它(WIP 列)。开发队列是做什么用的?

        我不知道,把最初的基本流程变成了复杂的东西:) 也许你应该发布你使用的参考资料。但在我看来,它们似乎是多余的(也许它们不在另一个上下文中,但我觉得不需要它们)。

        dev 将已完成/已解决的工作项移动到哪里以及 Done 和 next Queue 列之间的关系是什么?

        如果 WIP 项目是 Dev-Done,我认为 QA 应该将其拉到 QA-WIP。我不明白所有这些队列。所以与上面的答案相同,它们对我来说似乎是多余的。

        有什么想法吗?

        不是真的,但我会简化一些事情(实际上,几乎会退回到您的基本流程),我不认为让它们比我在this previous answer 中描述的更复杂。好的,这个答案是关于 Scrum 板而不是纯粹的看板,但如果你删除迭代它也可以工作。

        或者,也许您知道看板的详细示例及其来自现实世界的流程设置?

        看看 Henrik Kniberg 的 Kanban vs ScrumOne day in Kanban LandKanban and Scrum - a practical guide。好东西。

        (...) 但是在一个新的团队/项目停止时,完美的流程是什么?

        没有完美的流程,我们团队的完美流程不是你的。但是以上所有链接都会给您一些想法。但要保持简单,不必过于复杂。

        【讨论】:

          【解决方案6】:

          “就绪”队列(您称之为“输入队列”)用于推送流。 “完成”队列(输出)用于拉流。

          大多数系统都有推和拉。推送将发生在工作步骤之间存在不同组织语义的地方。例如,工作项在产品积压和团队输入队列之间的移动通常是推送移动。然后可以从输入队列中拉出工作。

          很少有一个工作步骤同时具有输入和输出队列。

          【讨论】: