看板（Kanban），逐字来看就是：“看（Kan）”意味着可视化，“板（ban）”意味着卡或者板。看板试图通过确保上游阶段只生产下游阶段所需的零件，以达到在不同阶段之间最小化 WIP（未完成任务），或者存货清单的目的。越来越多的公司开始创建看板、限制 WIP 和终止浪费（Muda）。Michael Dubakov撰文探讨了应用看板的是是非非。
Michael 提出了以下五条应用看板的错误理由，并给出了他为什么觉得这些理由错误的意见。
- 故事大小分布从 1 个点到到 40 个点，大小不一。大的故事甚至不能在一个迭代里面完成—— 团队需要理解如何把故事分解成更小的粒度。根据排队理论（Queueing Theory），最好保持使用小故事，而且故事的大小不能相差太多。
- 在一个迭代里面，不能完成大多数故事—— 太短的迭代周期可能引发交易成本。
- 回顾会议就是浪费时间，并不能帮助改善流程，我们想取消这些会议—— 团队需要分析回顾会议失败的原因。一个最常见的原因就是“会议之后没有行动事项”。
- 我们的开发人员有限，他们得在几个项目之间周旋。我们无法组建稳定的项目团队—— 如果采取多个项目共用开发人员的方式让团队开计划 sprint 会议的时候觉得困难，试试首先解决根本性问题——组建跨功能团队，根除分派多任务。
- 看板太简单了！没有计划、没有估算、没有迭代、没有管理开销—— 从来不存在银弹，而且除了努力工作、纪律、追求完美和持续改进之外，别无他法。实施任何一种敏捷方法，都需要所有这些必要条件。
Michael 也给出了应用看板的 5 个正确理由，在他看来：
- 随时发布的灵活性 —— Scrum 和 XP，通常不在 sprint 中期进行发布。有了看板，这不再是问题。
- 随心所欲调整优先级的灵活性 —— Scrum 很不推荐在 sprint 中期调整优先级。有了看板，如果来了一个紧急的请求需要实现，或者一个非常重要的用户故事，团队只需把它放在队列的顶端即可。
- 不再需要迭代 —— 迭代对于进入节奏非常有帮助。但是，在此之后，一旦团队能够进入高效的“流”工作状态，迭代反而可能变成浪费。
- 不再需要估算 —— 正如迭代一样，估算也可能变成一种浪费。Michael 提到：在他们的实际项目中，他们有一个排定优先级的 backlog，他们只需要从中取出最重要的用户故事，然后实现即可。
- 完美的流可视化 —— 看板给当前未完成的工作提供了一个非常清晰的视图。它把流可视化了，使快速计划和跟踪成为可能。
Tobias Mayer 提到其他应用看板的好理由，Karl Scotland在给出回复时提到：
在我的脑海中，使用看板方式的 5 个最佳理由是：
- 对整个价值流建模
- 使工作可视化
- 限制未完成工作
- 建立了一种节奏
- 使持续改进成为可能
因此，正如其他任何一种流程，应用看板也有其原因。一个敏捷团队不应该仅仅因为在他们看来现有流程不合适，就切换到看板。关键在于：团队需要反思在当前流程下他们可以如何改进，而且只有理由充分才能应用看板。
注册/登录 InfoQ 发表评论