Alan Shalloway最近列举了他所谓的关于看板的“一般神话”。 他的列表中包括以下内容：
[...]
- 精益开发是一种能够在社会化系统中起作用的规范方法。
- 看板要求线性地工作，并且需要太多的传递。
- 显式的规则是静态的，难于改变，并且不具有灵活性。
- 看板已经获得了成功，因为它是由早期的采用者完成的。
- 开始时使用Scrum，然后再从看板开始，这样做会好一些
- 看板不像其它敏捷方法那样注重人的作用。
- 看板没有对人做足够的处理
- 想要获得强大的改变，你需要进行革命性的改变，而看板则是渐进发展的。
- 看板是没有迭代的Scrum。
- 看板大多是用来作为支持的。
- 看板会导致团队固定不变。
- 看板无法生效，因为显式的规则在敏捷世界中是不合理的。
Shalloway尽其所能在《看板神话》这篇文章中消除其中的一些神话。
Alan Dayley引用了关于响应的神话：
我遇到最多的神话是关于WIP限制的。“如果我们已经达到了极限，那么看板会降低我们对客户做出快速响应的能力。”
Adam Sroka向列表中添加了关于时间箱（timeboxing）的神话：
一直以来我所认为的是看板 == 没有时间箱。有些人认为它是必要的（通常是因为他们认为两周的时间太短了）。 其他人则认为这意味着他们会破坏规定。
这两种想法都是错误的。 我们的节奏不一定必须是两周，但是我们需要有节奏并且知道它是多少。 我们不会刻意地使用时间箱，但是我们会衡量每件事情会花费多少时间，并试着按照平均的时间让它最小化。
Matthias Bohlen认为Ken Schwaber引用的内容也是一种看板神话： “上帝保佑， 人们试图找到各种方式，可以在瀑布模式中放松一下，从而获得休息，并变得更有创意。 有了精益和看板，其中隐藏的部分已经被移除了。 因此现在我们要持续向死亡行军而没有停顿。” Bohlen回应说：
没有什么“持续向死亡行军而没有停顿”。 人们可以在任何需要的时候停下来喝杯咖啡。 可以决定在什么时候休息。 看板不会比其它方法更严重地压榨人们，因为看板并非是一种方法——人们是使用团队现有的方法完成的工作。 看板让工作变得更加透明，但是本身并不是一种方法。 如果你愿意，可以认为它是“非方法”（至少我是那么认为的）。看板与“持续向死亡行军而没有停顿”恰恰相反。 考虑一下验收测试团队，它的职责是帮助产品所有者发现是否已经正确实现了backlog项目。 如果整个团队都感冒了会怎么样呢？ 开发团队就会遇到WIP限制，因为测试人员都病了，无法把已经开发完成的内容从开发状态转换为验收测试状态。 因此，这些内容会保持在开发状态。
然后会怎么样呢？ 开发者会由于自己的WIP限制而停止开发——他们会休息。 他们会读书、参加培训、重构他们的软件、学习一直想要学习的新知识等等。 当测试人员的感冒好了，并继续工作的时候，他们会发现在这段时间中开发人员并没有创建大堆的工作等着他们。 没有任何“死亡行军”——他们只是继续工作，并把项目从开发者那里拉过来。 然后，开发者也开始继续工作，工作流程又开始流转了。
看板的这些“神话”真的是神话吗？ 你听说过哪种看板神话呢？
查看英文原文：Myths of Kanban
0 0 标签： 敏捷