Scrum 看板：是进展，还是矛盾？

尽管看板不是什么新鲜事物，但有越来越多的敏捷软件开发方法的使用者开始关注它。相关讲话、研习班、甚至一整个与之相关的会议都如雨后春笋一般不断涌现，敏捷的培训师们也把看板加入了自己的讲授课程之中。有实用精神的敏捷专家们开始研究这种来自精益的方法能为团队带来哪些好处，引人之处包括：揭示瓶颈、更快取得更多进度、让团队体验更多的“流畅”状态而变得更为快乐。在这个大环境中，Simon Bennett 的一篇《看板思想是Scrum 的氪星石》给希望将看板结合到Scrum 流程的人敲响了一记警钟。看板的提倡者们同意Bennet 的看法，认为看板对于障碍的处理方法不那么积极，这与Scrum 要求立即移除障碍的理念有所冲突。

Bennett 在博客文章中声明，他自己既不是一个反对看板的呛声者，也不是发表类似“要保持 Scrum 纯洁性”长篇大论的人。他指出：

如果你打算试用 Scrum，但是忽略或隐藏障碍（甚至根本不在第一时间说出它们），那你就等于是自找苦吃，而且不会取得工作进展。这就是 Ken Schwaber 和 Martin Fowler 提到过的“松弛的 Scrum”（至少从技术债的角度看是这样）。 Scrum 和看板都奖励透明度，不过是以不同的方式：Scrum 内建了对于行动的直接召唤，必须要应答这种召唤，Scrum 才能成功。

看板允许你和团队只是“接受”障碍，还要衡量它们的影响。

他认为：两者背后的思想是冲突的，“当看板思想迫近时，Scrum 项目就会一直得到削弱”。然而，应用纯粹的思想并不是目标，目标是高质量的软件和频繁的交付。为了达成目标，他鼓励实践者们检查他们从事什么样的项目，使用 Scrum 的成功率如何，他还提供了指南，帮人们选择使用合适的方法论。

Corey Ladas2008 年的文章“ Scrum 看板”讲述了向看板演进的过程，如果走得足够远的话，看板就能替换绝大多数的 Scrum。Ladas 的方法会修改甚至替代许多传统的 Scrum 实践，比如每日立会和燃尽图。有趣的是，在 Agile2007 大会上凭借自己的看板实施经验报告让人们眼前一亮的 Anderson（看来他目前主要的经历放在实施看板上）提到，他最初的意图不是为了“让人们转而离开 Scrum”，而是要帮助实施敏捷有困难的人。Bennett 的博客指出：团队在引入看板之前要想清楚，团队自身从 Scrum 中获得足够价值了么？他补充道：“如果你真的在开发最前沿的技术，那我想你将来还会依赖 Scrum。”

虽然 Bennett 并未被列入 Limited WIP Society （该社区希望成为软件开发社区的看板之家）的思想领导者之列，很多被列席的人都在他的博客留言中表示了支持之意，其中包括 Karl Scotland 和 David J. Anderson。Anderson 表示赞同：

是的，看板是一种进化，而 Scrum 是一种革命。我非常同意这种定位。

当然，任何工具都可能被误用。Chris Sims 的文章《 Are Kanban Workflows Agile? 》提醒读者：如果看板被用来确保每项必要活动都发生了，那就等于是用作强制推行团队对完成的定义，这活有个检查列表就可以了。同时Mitch Lacey 最近总听到这样的话在提醒人们：“说到底，没有什么万能钥匙。说一个什么东西比其他东西更能解决人们的问题，那不过是一厢情愿、痴人说梦而已。”

在InfoQ 上还有更多与看板相关的内容：文章和演讲。

查看英文原文： ScrumBan - Evolution or Oxymoron?