看板悖论：看板与Scrum相比

一段时间以来，我一直在看到看板的悖论。 具体而言，看板与Scrum相比。

对于刚接触敏捷的团队-尽管有人认为这是异端，但我将看板置于敏捷的保护伞下，是的，我比精益更了解精益，但原因是，无论如何，敏捷本身就是精益方法……

对于希望采用新流程的团队，特别是软件团队，可以选择：

• 看板的入门门槛很低，从一开始看板就说“可视化您的工作并管理结果”。 启动看板就像建立董事会和跟踪工作项目一样简单。 在看板中，可视化应该推动改进。 变化可以是渐进的，也可以是渐进的。 变革植根于学习。
• Scrum的进入门槛更高：本质上，Scrum说：“采用Sprints，指定产品负责人，任命Scrum负责人，并积压工作。” 一旦完成这些更改，您就可以使用Scrum进行操作，然后Scrum Master和回顾会议将启动并推动进一步的改进。

有趣的是，两种方法都没有明确指出“提高质量”。 但是，我始终认为，敏捷方法的许多成功都归功于良好的旧质量改进：编写更少的错误并减少要修复的错误意味着更好的可预测性和更多的时间来交付有价值的软件。 但是我离题了。

从看板开始比较容易，因为它需要较少的前期更改。 但是，这的确意味着改进的速度较慢。

相反，Scrum参与进来，变化很大，大多数团队看到了立即的进步。 Scrum较少依赖于后续更改。

由于看板更多地依赖于正在进行的变更，因此更加困难。 容易陷入“我们建立了看板板，所以我们正在看板的阶段”。 看板中的变更要求人们看到变更的需求，了解解决问题的方法，然后进行变更。 这通常需要经验。 因此，在采用看板的团队中，对教练，顾问和以前做过的人的需求更大。

另一方面，Scrum会预先进行更多的更改，并且改进的方法也更加直接。 当然，还有更多关于Scrum的书籍，关于Scrum的博客，认证的Scrum大师和Scrum经验。 因此，虽然很难开始使用Scrum（因为需要更多更改），但对进一步更改的需求却越来越少，而您进行更改就不需要相同的知识水平。

在查看统计信息时，会特别看到这一点。 观察数字在这两个过程中都应该很重要，但是对于看板而言，这几乎是至关重要的。 任何真正了解看板的人都知道，需要研究排队理论，交货时间，可能是加权的交货时间以及许多其他数字。

另一方面，Scrum的进度比烧毁的图表还远。 是的，使用Scrum进行更多改进也将受益于了解交货时间，对理论进行排队以及其他方面，但是您可以很高兴地使用Scrum，甚至可以在不了解这些思想的情况下改进Scrum。

这就是悖论：

与没有专家知识的Scrum相比，从看板开始更容易，但是与没有专家知识的Scrum相比，改进看板要困难得多。

在许多方面，我更喜欢看板，但我发现这需要专家知识。 我想我不应该，我是一名顾问，我是那个专家，人们雇用我来帮助改善他们的看板流程，从而为我带来更多的工作。

从长远来看，看板方法更可能导致真正的包容性改进文化，并且不太可能陷入次优状态–是的，Scrum可以解决问题，但这是否是最佳解决方案？

看着这样给我的盼盼带来了新的视角。

我希望Xanpan有两点：

• 对实际遵循敏捷过程（特别是看板/ XP混合过程）的一种可理解的描述
• 团队应该如何以及为什么要创建自己的流程的示例。

同样的悖论在这里：Xanpan应该很容易上手，但是可以让您有所改进。 创建自己的流程需要更多的知识，只有真正的经验才能带来。

退一步，再问一个问题： 团队可以应对多少变化？

我发现我主张比以往更多的初始更改。 因为我担心会产生学习依赖，所以我真的希望团队学习改变和改进自己。 但是……一旦一个团队决定做出改变，我想抓住机会并在充满热情的同时进行一系列的改变。

翻译自: https://www.javacodegeeks.com/2017/11/kanban-paradox-kanban-compared-scrum.html