应用看板的是是非非_研发效能_Vikas Hazrati



 写点什么

看板（Kanban），逐字来看就是：“看（Kan）”意味着可视化，“板（ban）”意味着卡或者板。看板试图通过确保上游阶段只生产下游阶段所需的零件，以达到在不同阶段之间最小化WIP（未完成任务），或者存货清单的目的。越来越多的公司开始创建看板、限制WIP 和终止浪费（Muda）。 Michael Dubakov 撰文探讨了应用看板的是是非非。

Michael 提出了以下五条应用看板的错误理由，并给出了他为什么觉得这些理由错误的意见。

故事大小分布从 1 个点到到 40 个点，大小不一。大的故事甚至不能在一个迭代里面完成—— 团队需要理解如何把故事分解成更小的粒度。根据排队理论（Queueing Theory），最好保持使用小故事，而且故事的大小不能相差太多。
在一个迭代里面，不能完成大多数故事—— 太短的迭代周期可能引发交易成本。
回顾会议就是浪费时间，并不能帮助改善流程，我们想取消这些会议—— 团队需要分析回顾会议失败的原因。一个最常见的原因就是“会议之后没有行动事项”。
我们的开发人员有限，他们得在几个项目之间周旋。我们无法组建稳定的项目团队—— 如果采取多个项目共用开发人员的方式让团队开计划 sprint 会议的时候觉得困难，试试首先解决根本性问题——组建跨功能团队，根除分派多任务。
看板太简单了！没有计划、没有估算、没有迭代、没有管理开销—— 从来不存在银弹，而且除了努力工作、纪律、追求完美和持续改进之外，别无他法。实施任何一种敏捷方法，都需要所有这些必要条件。

Michael 也给出了应用看板的 5 个正确理由，在他看来：

随时发布的灵活性 —— Scrum 和 XP，通常不在 sprint 中期进行发布。有了看板，这不再是问题。
随心所欲调整优先级的灵活性 —— Scrum 很不推荐在 sprint 中期调整优先级。有了看板，如果来了一个紧急的请求需要实现，或者一个非常重要的用户故事，团队只需把它放在队列的顶端即可。
不再需要迭代 —— 迭代对于进入节奏非常有帮助。但是，在此之后，一旦团队能够进入高效的“流”工作状态，迭代反而可能变成浪费。
不再需要估算 —— 正如迭代一样，估算也可能变成一种浪费。Michael 提到：在他们的实际项目中，他们有一个排定优先级的 backlog，他们只需要从中取出最重要的用户故事，然后实现即可。
完美的流可视化 —— 看板给当前未完成的工作提供了一个非常清晰的视图。它把流可视化了，使快速计划和跟踪成为可能。