译者序：Kanban（中文直译为：看板），源于日本丰田的生产模式。Kanban方法是一种非迭代式的敏捷开发方法，它和Scrum是敏捷软件开发中的两股风潮。在软件开发过程中，使用Kanban，还是使用Scrum，在近年来引起很多讨论和关注。如果你关注软件测试领域的敏捷开发方法，或被使用Scrum的问题所困扰，想看看Kanban是如何解决这些问题的，那么Eric Jacobson的What I Love About Kanban As A Tester一文正好回答了这个问题。作者结合在项目实践中的亲身感受，详细介绍了为何从使用Scrum转换为Kanban，以及Kanban的优势。译文如下：

　　上周在我一个项目组里我们庆祝了两件令人兴奋的事。

　　1、完成第一百次迭代（大部分使用了ScrumBut（译注：意为我们根据自己的实际情况，对Scrum框架做了相应的裁剪））。

　　2、开始改用Kanban。

　　我和两位同事就改用Kanban的利弊已经讨论了几个月，在说服自己这个实验是值得的之后，我开始逐渐让组内其他成员接受...我们开始推行了！

　　我们为什么要改变？

　　● 我们产品的优先级每天都在改变，许多时候用户无法等到迭代结束。

　　● Scrum带来的是一大堆对我们从来没有实际帮助的流程。我们不需要每日立会，不喜欢迭代计划，我们花费了很多时间拆分Story，争论如何计算迭代速度。在回顾会中我们想尽问题，在某些情况下（在我看来）只是强迫自己仅仅为了讨论而想出新问题。

　　● 我们厌倦了在迭代的开始和结尾拼命工作。（也就是说，测试在迭代开始时感到无聊，而在迭代结尾狂干，开发在迭代后期无所事事，而在迭代初期拼命）。

　　● 部署满是新功能的完整版本迫使我们进行大量回归测试，而且要在周末的维护窗口里完成（这导致我们周末工作，而我们的用户需要到周末才能看到新功能）

　　● 变化是对思维的刺激。我们的团队已经一起合作6年了，变化会帮助我们再次思考，确保我们为了正确的目的做事。不尝试永远无法知道有更好的方法。

　　写这篇文章时，我可以听到所有的Scrum Master厌恶的哭喊着，“认为Scrum不好用，是因为你没有正确的使用它！”这也许没错。但我认为Scrum的社区，教练，顾问在一定程度上应该受到责备。我觉得他们应当力图向软件开发社区更好的解释Scrum。我经常听到聪明人相互矛盾的建议（比如：“每次迭代的速度应该加快”，“每次迭代的速度应当保持相同”，“每次迭代的速度应当来回波动”）。

　　当我是个孩子的时候，我们家得到了个叫“视频线索”的游戏。我邀请爷爷一起玩，我们一起仔细阅读说明书。在陷入迷惑30多分钟后，爷爷把零件从桌子上扔了下去，说“规则太多的东西，根本用不了”。

　　有其他人在用Kanban吗？

　　身为测试我爱Kanban–之一

　　...集中测试，不再重复！

　　回到Scrum的黑暗时代，我们会在开发环境做大量测试。临近迭代结束时，我们会把所有东西打包成一个版本，部署到QA环境，对一些东西继续测试...需要再做足够充分的测试来确保部署成功，并能与其他关键功能一起正常运行。在QA环境，我们必须把以前执行过的测试找出来，再次恢复它们，并尝试回忆在过去几周内我们从测试中了解到的东西。

　　使用Kanban，我们集中测试。我们仍在开发环境做大量测试。但当我们完成某功能后，会部署（在同一天）到QA环境，立即做额外的测试。这对我们来说就容易多了，因为这些测试在我们脑袋里还记忆鲜活，我们的SQL脚本还打开着，最近使用的其他工具都准备停当并可以随时运行。当完成测试时，我们把它直接部署到生产环境，那些测试在脑子里就可以被放置一边（有时是永远放置一边），给下个新功能腾腾空间了。

　　身为测试我爱Kanban-之二

　　...成就感，直接关系到我的工作热情。

　　回到scrum的黑暗时代，测试成果一个月才会呈现给客户一次。在我停止功能A的测试转而测试功能B的时候，我有时感到尴尬，因为功能A还没测完呢！我经常有一种感觉：如果想到一个功能A的新测试点，我可以把它补进去。这是种非常不负责任的感觉。通常情况下，这其实是：“我可以晚点儿再完成这些测试”。但当迭代版本接近尾声时，就变成了“哇，时间过的真快啊”。