看板(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 个最佳理由是:
- 对整个价值流建模
- 使工作可视化
- 限制未完成工作
- 建立了一种节奏
- 使持续改进成为可能
因此,正如其他任何一种流程,应用看板也有其原因。一个敏捷团队不应该仅仅因为在他们看来现有流程不合适,就切换到看板。关键在于:团队需要反思在当前流程下他们可以如何改进,而且只有理由充分才能应用看板。
评论