看板神话

Alan Shalloway 最近列举了他所谓的关于看板的“一般神话”。 他的列表中包括以下内容：

• 精益开发是一种能够在社会化系统中起作用的规范方法。
• 看板要求线性地工作，并且需要太多的传递。
• 显式的规则是静态的，难于改变，并且不具有灵活性。
• 看板已经获得了成功，因为它是由早期的采用者完成的。
• 开始时使用 Scrum，然后再从看板开始，这样做会好一些
• 看板不像其它敏捷方法那样注重人的作用。
• 看板没有对人做足够的处理
• 想要获得强大的改变，你需要进行革命性的改变，而看板则是渐进发展的。

[...]

• 看板是没有迭代的 Scrum。
• 看板大多是用来作为支持的。
• 看板会导致团队固定不变。
• 看板无法生效，因为显式的规则在敏捷世界中是不合理的。

Shalloway 尽其所能在《看板神话》这篇文章中消除其中的一些神话。

Alan Dayley 引用了关于响应的神话：

我遇到最多的神话是关于 WIP 限制的。

“如果我们已经达到了极限，那么看板会降低我们对客户做出快速响应的能力。”

Adam Sroka 向列表中添加了关于时间箱（timeboxing）的神话：

一直以来我所认为的是看板 == 没有时间箱。

有些人认为它是必要的（通常是因为他们认为两周的时间太短了）。 其他人则认为这意味着他们会破坏规定。

这两种想法都是错误的。 我们的节奏不一定必须是两周，但是我们需要有节奏并且知道它是多少。 我们不会刻意地使用时间箱，但是我们会衡量每件事情会花费多少时间，并试着按照平均的时间让它最小化。

Matthias Bohlen 认为 Ken Schwaber 引用的内容也是一种看板神话： “上帝保佑， 人们试图找到各种方式，可以在瀑布模式中放松一下，从而获得休息，并变得更有创意。 有了精益和看板，其中隐藏的部分已经被移除了。 因此现在我们要持续向死亡行军而没有停顿。” Bohlen回应说：

没有什么“持续向死亡行军而没有停顿”。 人们可以在任何需要的时候停下来喝杯咖啡。 可以决定在什么时候休息。 看板不会比其它方法更严重地压榨人们，因为看板并非是一种方法——人们是使用团队现有的方法完成的工作。 看板让工作变得更加透明，但是本身并不是一种方法。 如果你愿意，可以认为它是“非方法”（至少我是那么认为的）。

看板与“持续向死亡行军而没有停顿”恰恰相反。 考虑一下验收测试团队，它的职责是帮助产品所有者发现是否已经正确实现了 backlog 项目。 如果整个团队都感冒了会怎么样呢？ 开发团队就会遇到 WIP 限制，因为测试人员都病了，无法把已经开发完成的内容从开发状态转换为验收测试状态。 因此，这些内容会保持在开发状态。

然后会怎么样呢？ 开发者会由于自己的 WIP 限制而停止开发——他们会休息。 他们会读书、参加培训、重构他们的软件、学习一直想要学习的新知识等等。 当测试人员的感冒好了，并继续工作的时候，他们会发现在这段时间中开发人员并没有创建大堆的工作等着他们。 没有任何“死亡行军”——他们只是继续工作，并把项目从开发者那里拉过来。 然后，开发者也开始继续工作，工作流程又开始流转了。

看板的这些“神话”真的是神话吗？ 你听说过哪种看板神话呢？