用 Kanban-Ace 框架改进 Scrum

关键点

Scrum 已经几乎成了敏捷的同义词；虽然 Scrum 相当有用，但它仍有弱点和有待改善的空间。Kanban-Ace 框架可以帮助它克服这些弱点。

Kanban-Ace 框架接受 Scrum，并帮助团队提高他们的敏捷水平。这些改进通过以下做法完成：

• Akashi Bridge：这是一种新的工具，它可以在 Kanban-Ace 板的背景下使用每一个 Scrum 事件，包括 Sprint、Sprint 计划、每日站立短会、Sprint 重整和回顾等。
• Kanban-Ace 板：它内置 Akashi Bridge，大大提高了软件开发的各个方面可视化程度，让团队可以识别趋势，提高自身的敏捷度。
• 精益思想：它是 Kanban-Ace 精益 DNA 的一部分。精益思想使团队减少浪费，并优化 Kanban-Ace 事件和过程以满足团队的需要。

Scrum 是一种广泛使用的敏捷框架，它已被证明对许多公司和机构都非常有用。然而，正如 Fred Brooks 的名言所说的那样，在信息技术上没有“银弹”，尽管 Scrum 有其好的部分，但有时我们敏捷专业人员却因为各种原因而不得不与 Scrum 的某些方面进行斗争。在进一步展开本文的陈述之前，我要清楚地说明我喜欢 Scrum。从 2008 年起，我就一直使用它。我甚至拿到了 ScrumMaster 的认证。而且，我发现 Scrum 有两个概念特别有价值：受保护的迭代或 Sprint，也有人正式代表用户，那就是产品经理。

然而，我个人对于敏捷和精益的理解超越了单一的方法或框架，获益于几个灵感来源的智慧结晶，比如：Kanban、极限编程，精益开发，以及一些其它方法中的精华，来以更好的方式来实现敏捷。因此，我开始建立一种方法，它基于精益和敏捷的影响，Kanban 是主要的统一力量，在 2013 年， Kanban-Ace 方法已经在我们的网站上公布。

然而直到现在，还没有一本书整理 Kanban-Ace 方法的价值、原则和技术。原因是，在 Agilelion 公司里，我们专注于通过录制好了的视频进行在线教学，同时也进行现场授课。何其幸运，Kanban-Ace 方法能够被世界各地的人们所使用，在这三年里得到了人们大量的反馈信息，这些反馈近的来自美国和加拿大，远的来自德国、瑞士和澳大利亚。

从我们的学生身上和我的职业咨询实践中，我注意到 Scrum 是无处不在的，它几乎成为敏捷的同义词；虽然 Scrum 是众多敏捷方法之中的一种方法，不可否认的是，它是最广泛使用的一种方法。而且，作为受认证的 ScrumMaster 专家，我在乎 Scrum，并想向来了解 Kanban-Ace 的人展示，他们如何能在保留几个他们喜欢的 Scrum 关键优势的同时，提高他们的敏捷性。

Kanban-Ace 现在是一个框架，而不是一种方法。原因是，框架的建立是为了适应一个特定的域，我们打算把 Kanban-Ace 扩展到以下一些新的领域：对 Scrum 的全面支持、轻量级敏捷提升和产品创新工具。

这篇文章只是对第一个关键领域会发生什么事情的预览：对 Scrum 的全面支持。然而，我们不能在这里停下脚步，我们要改进 Scrum 并使 Kanban-Ace 框架成为你的敏捷工具集的一个有价值的补充，但在我们开始之前，我们需要给你介绍一下 Kanban 的相关背景知识。

Kanban 简史

要了解 Kanban 今天的地位，必须知道它的过去情况。制造 Kanban，有时用小写“kanban”直接指的是丰田公司组织跨工厂和部门工作的制造技术，这种技术和其他几种技术构成了丰田生产系统（ Toyota Production System ，TPS）。TPS 开始于 1945 年。到了 1978 年，大野耐一在日本出版的书是一个重要的里程碑。感谢Norman Bodek 的努力，十年后这本书的英文版出版，使得它可以在西方世界传播。

知识工作Kanban 或首字母大写的Kanban 指的是围绕应用TPS 理念、约束理论、精益开发和其他相关资源的改变和创新，以便重点管理和改善人类创造力相关的领域，特别强调以软件开发、信息工程、营销和管理为重点。知识工作Kanban 是最早的敏捷和精益的方法，是我们各种Kanban 类型的创立者。从现在开始，我们所有提到的Kanban 都是指这种特殊类型的Kanban。

Kanban 的起源

2009 年，Corey Ladas 在他的关于 Kanban 的书《Scrumban：论Kanban 系统的精益软件开发》（Scrumban - Essays on Kanban Systems for Lean Software Development）中首次介绍了Kanban。随后，在2010 年，David Anderson 的书《Kanban：为了你的科技企业的成功演进》（Kanban: Successful Evolutionary Change for Your Technology Business）也是这一方法的一个关键推动力。在这本书里，David Anderson 提出了他最初的将Kanban 作为精益敏捷方法的想法。

Kanban 早期的历史与敏捷运动的发展密切相关，Corey 和 David 都有很强的软件开发和信息技术背景。在早期，Kanban 依然是一种敏捷和精益方法，它出自于 Donald Reinertsen , Mary 和 Tom Poppendieck 的早期精益相关著作。

Kanban 方法

大约在 2013 年，David Anderson 决定生成一个自己版本的 Kanban，他称之为不同方向的 Kanban 方法（The Kanban Method），与所有其他的敏捷方法都不同，把重点放在“进化改进”和改善管理方式上。在向着这个方向努力的过程中他多次声明，Kanban 方法不是敏捷，尽管它可能实现敏捷。这个时候，许多早期的 Kanban 成员都开始决定走一条不同的路径，就是保持敏捷，并且保持和信息技术及软件开发的紧密联系：经典 Kanban。

经典 Kanban

经典 Kanban 代表 Kanban 的最初精益和敏捷方法。经典 Kanban 充分地体现了敏捷宣言，并维护着与软件开发、信息技术、DevOps 和产品开发的紧密关系。

现在，经典 Kanban 非常活跃，蓬勃成长。它的主要代表人物有 Corey Ladas、Al Shalloway、Henrik Kniberg 和我自己。Corey 通过 Scrumban 和精益 Kanban 代表经典 Kanban。Al Shalloway 通过关注团队的精益Kanban，最近是Leanban 来代表经典 Kanban 。Henrik Kniberg 通过他的书尤其是《精益开发实战》（ Lean from the Trenches ）代表经典 Kanban，他的作品来源于他在 Spotify 和乐高的实践。在这个声誉卓著的名单里，我很不好意思地想加入我们的 Kanban-Ace 方法和这篇文章探讨的 Kanban-Ace 框架。值得一提的是两个简约版的 Kanban 方法：第一个是 Jim Benson 和 Tonianne DeMaria 的个人 Kanban ；另一个是我们自己的开放 Kanban ，它是 Kanban-Ace 的核心。

谈及经典 Kanban，我想澄清一个观点。Scrumban 不是 Kanban 和 Scrum 的混合产物，而是一种源于 Scrum 的、包含 Kanban 的方法，以下是 Corey 对这一点的解释：

对于一个有经验的敏捷团队来说，Scrum 在作为一个起点，并让团队不断进化变得更精益这方面非常有用。我一直认为，我是为这样的受众写作的，这种进化是一种“Scrumban”过程，并且我以此命名此书：《Corey Ladas，Scrumban：关于精益软件开发的 Kanban 系统的一些看法》。

Scrum 的优缺点

毫无疑问，丰富的书籍、ScrumMaster、培训和成功的故事是 Scrum 的最大优势。该框架已成为敏捷的基础，在信息技术、软件开发、市场营销和产品开发领域，许多人对它甚是熟悉。

在我看来，除了成功和认可，另外这两个关键的优势是：

• 受保护的迭代或 Sprint 的概念。
• 指导产品研发的两个关键角色的创立：产品经理和 ScrumMaster。

然而，Scrum 并非没有缺点，也不是没有可提高的空间。最近通过 Agilelion 研究所，我们用调查的形式收集了一些关于这个话题的反馈意见。原创文章中有我们研究结果的详细报告，但我还是想用下面的图表总结我们的研究结果：

如图所示，用户看到 Scrum 有四个弱点：

1. 规划与估计 40%
2. 扩展困难和死板的角色 28%
3. 大量的会议 13%
4. 缺乏技术实践 11%

要把上述列表的每一项问题都解决，需要写几本书才能完成。所以，我选择讲述 Kanban-Ace 框架会如何改善上述领域中出现的问题，好让 ScrumMasters、产品经理、研发人员和管理者轻松一些。

Kanban-Ace 框架：为 Scrum 实践者所写的简介

我不打算对 Kanban-Ace 框架的每一个值、实践和技术一一做解释，我想要给你们简单讲讲我们能给 Scrum 带来的主要好处。

如果你对 Kanban-Ace 框架的全面探讨感兴趣，包括理论、价值、原则和技术，我强烈推荐你去 Agilelion 学院。在那里，我们为你提供在线和现场培训和认证。

Kanban-Ace 框架提供了一系列的工具和技术来解决 Scrum 在 Kanban 领域的薄弱环节，但仍保持着每天你习惯使用的 Scrum 的关键要素。我们提供的这个系列的工具和技术叫做 Akashi。在我们详细探讨这一能使我们把 Scrum 的精华和 Kanban-Ace 相结合的技术之前，我们必须了解 Kanban-Ace 是如何通过它的主要优势来运作的——将工作可视化。

理解 Kanban-Ace 对于 Scrum 的主要优势：可视化的整体和局部

Scrum 使用任务板去展示在特定的迭代或Sprint 期间内的进展。Sprint 可能长达一到四个星期，每个任务板通常有3 列：将要做的事情、正在做的事情、已经完成的事情。为了让大家可以看到它们看上去是什么样子的，我推荐大家看看敏捷教练 John Yorke 的这篇好文章。

与 Scrum 不同，Kanban-Ace 不是可视化一个 Sprint，而是可视化从构思到赚钱的产生产品的全部努力。这个工作量很大，它意味着 Kanban-Ace 板可以看到软件开发生命周期的整个森林、产品开发的全生命周期、或者说任何业务系统，经过不同的阶段来实现价值，如雇佣人员、实现销售和设计新产品。然而，在这篇文章中，我们将集中在软件方面。本质上，我的解释意味着 Kanban-Ace 可以清楚地看到整体（森林），并且可以在任何时间了解我们的软件团队发生的事情。

而这并没有结束，除了你付出的努力的全景图，你还可以得到局部细节（树）的缩放图。Kanban-Ace 板有一系列的列，以表示你软件开发过程中关键步骤的阶段，它能够清晰的显示瓶颈，并显示在任何时间你团队里的每一个人的位置。为了更好地理解这个关键的优势：看树的细节，我想先解释 Kanban-Ace 板如何运作，因此，请让我们一起看看图 1 所示的板。

图形 Kanban-Ace 板从左到右流动。这是一种持续流，即接近实时，所以你可以看到你的团队在任何时刻的位置。

在这个小 Kanban-Ace 板上你可以看到，在最左边的栏中，一系列不同工作量的工作项在待定列里，被称之为未处理的事情。在它旁边，你可以看到准备队列栏，这意味着故事、历史故事、特征、最小可行的发布，最小可行产品（MVP）或准备好可以开始做的任务。下一列是主要工作进行的地方。在这里，我把它称之为工作之河。这一次，它只是一个宽列，但在实践中，它通常被分为你想跟踪的工作阶段，并使之可见。最后，我们有 TV 栏，这可不是指平时看电视的栏目！它实际上代表 Trust（信任）或 Verify（验证）的英文单词首字母，因为在向世界发布之前，通常需要做这两件事情。当然，一旦我们做完了全部事情，我们有真正的完成事项栏；许多朋友亲昵的称其为 DONE DONE 列；-）

现在，请注意下面图 2，你会看到一个真实的软件开发 Kanban-Ace 板，我们一起来仔细研究它。首先，你将注意到，团队已经将他们的软件开发生命周期详细规划为从左到右的八列：积压、优先积压、正在进行的开发、已完成的开发、进行中的质量保证、已完成的质量保证、部署和已完成。

现在让我们看看到底在 Kanban-Ace 板发生了什么。这一次，让我们从右读到左，因为交付的价值总是在板的右端。首先，我们可以看到，团队已经把故事 A 交付到生产了；故事 W 刚刚完成，现在它准备由一个系统管理员进行部署。在团队的测试部分有两个故事，一个刚刚经过质量保证 QA（故事 B）和另一个正在占用在两位质量保证分析师时间（T1 和 T2），这是故事 E，我们可以有把握地推断，这是一个更复杂的故事。现在在开发方面，我们可以看到，团队现在正在为四个故事忙得团团转。一个是刚刚交付给已完成开发列（故事 Y），所以当质量保证团队有能力时，他们将把故事 Y 安排为下一项的工作。在此期间，开发团队已经有停滞不前的问题出现了，故事 C 已经停止推进。这时，需要 ScrumMaster，Kanban-Ace 教练或敏捷项目经理干预，采取相应的措施来消除停滞，尽可能地推动团队前进，进一步完成研发。到目前，并没有浪费时间，两位研发人员都在忙着故事 D，用户体验设计师忙着为故事 H 设计界面。在团队的优先积压方面，产品经理、产品负责人正在和一位关键的研发人员一起努力将所需要的细节加入故事 G，以便做好下一步开发的准备。我们也在故事 G 进行相似的工作。在故事 G 中，我们注意到开发人员三在开发团队把故事 G 纳入他们的研发列之前，为它增加了一些细节。最后，积压列显示了六个故事在等待，一旦他们完成了整个过程，所有的努力都不会被白费，产品将完全实现和公之于众。

现在，你能明白我之前说到 Kanban-Ace 版能让你看到你的软件开发生命周期森林和树的意思了。只需几分钟或几秒钟，你可以从字面上看到整个产品怎么样，或在指定的一天里产品处于什么阶段。

此外，要记住，那些列并不是雕刻在石头上一成不变的东西。团队可以一起决定如何将变化引入板，以改善过程，或改善以它所代表的系统的可见性。例如，他们可能为代码审查、代码合并、UAT、用户演示等等引入额外的列。

现在还有一点需要大家注意，就是 Kanban-Ace 板也有在制品限制，表现为 WIP。它们在上述的板上是以你所看见的一些列的顶端的数字表示。WIP 限制使团队着重于一个可行的系列故事，让他们在同一时间做许多的事情的努力不会白费。在队列后面的坚实理论说明，甚至心理学也表明，专注于更少的事情，实际上可以让你和你的团队在更少的时间内提交更多的事情。少便是多！然而，Kanban-Ace 框架认为 WIP 限制是可选项，但强烈推荐使用它。我们首先强调减少基础的原则，这意味着减少你努力。对于开发团队把 WIP 限制成 1 是无用的，如果这个 1 是一个巨型的功能，减少基础原则基本说明了这一点：让你的努力成为颗粒状，并尽可能的小，而一旦你使之变小，尽可能一次做尽可能少的工作，你就能集中精力努力。一旦体积变小了，限制在制品是容易的！

为 Scrum 引入 Kanban-Ace Akashi Bridge

Akashi 里面的想法从一开始就是 Kanban-Ace 的一部分。但现在 Kanban-Ace 框架增加了与 Scrum 一起工作的系统方法，以便让它们互相磨合，并作为一个统一的整体。

Akashi 是以日本的明石大桥（Akashi bridge）命名的。这是世界上最长的悬索桥，连接神户市和淡路市。我取这个名字是因为 Kanban-Ace 和 Scrum 都有来自日本的共同的精益传承。注意，这座桥有两座主桥墩来统一整体结构，Kanban-Ace 明石大桥也是一样。 在 Kanban-Ace Akashi Bridge 里，这两个主桥墩就是 Scrum 和 Kanban-Ace！

在以下图 4 中，你可以看到完整的 Kanban-Ace Akashi Bridge。让我一步步地解释它是如何工作的。让我们从顶部开始，那里有 4 个主要支柱或列，将桥梁分为各个部分。首先，在桥的最左边部分，你可以看到待定支柱，它包含有产品积压部分。其次是 Scrum 桥墩。第三是 Kanban-Ace 桥墩，最后是真正完成。

Akashi Bridge 两个主桥墩使 Scrum 从业人员可以借助 Kanban-Ace，去看一眼整体和局部（森林和树）的工作，并能轻易地在处理持续流和 Kanban-Ace 的每一事件的同时，保留 Scrum 对他们有价值的关键事件。

Scrum 桥墩是一个小型 Kanban-Ace 板，它显示与 Scrum 事件相关的所有活动。在 Scrum 桥墩的最左边的部分，你可以看到事件的积压，包括团队认为需要提供完整版本的 Scrum 仪式或产品的预计。当仪式开始时，题为“活动日”的下一节将被使用。例如，在板的下面，你可以看到第二次 Sprint 计划（2PL）事件是定于今天进行的，就像每日站立短会（ST.）一样。Scrum 桥墩还向我们展示，因为使用了 Akashi Bridge，第一次 Sprint 充分完成，Sprint 计划、审查和回顾已经在过去完成了（分别在 1PL、1RV 和 1RT）。

在同一时间，我们非常便利地、能够几乎实时地查看整个团队为 Kanban-Ace 桥墩所做的努力，因此你可以看到森林和树木。Kanban-Ace 桥墩本身就是一个完整的 Kanban-Ace 板！让我们研究一下团队在 Akashi Bridge 的位置。让我们从最右边的列开始，看看目前为止团队已经完成了什么任务：故事 1 到 4 已经完全完成，故事 5 刚刚通过了质量保证，故事 9 和 8 现在在质量保证过程中。故事 10，11 和 6 是最近由开发团队实施，他们现在正在研究开发的故事 7、12 和 13，最后，一旦开发团队完成目前的工作，他们将准备从积压的故事 14 和 15 开始，推进开发。

但等等，这不是全部！因为我们有 Scrum 桥墩，我们也知道，Sprint1 交付四个故事，Sprint2 有完成整块板的挑战；而且可能没办法实现这些事情，因为它们只能发生在他们设法完全完成故事 4 之前。对 ScrumMaster、产品经理、Kanban-Ace 教练和团队检查和适应为 Sprint2 即将举行的 Sprint 规划会议来说，这是非常有价值的信息。

本文的下一个话题我们将不再讨论 Akashi Bridge，我们将探讨 Kanban-Ace 给所有敏捷实践者带来的好处。

Kanban-Ace 为 Scrum 团队带来的额外好处

我在这篇文章中已经解释过，决定采用 Kanban-Ace 框架的 Scrum 团队能够保持其关键作用和事件，同时获得 Kanban-Ace 的全部各种工具，比如：能查看整体，又能放大查看他们工作细节的能力；在一个持续流领域计划和执行的能力；他们习惯使用的关键 Scrum 事件；以及更多早已成为我们 Kanban-Ace 课堂构成部分的好处。我想提醒你注意我们之前介绍过的明石大桥的额外优势中的两点：

A. Kanban Ace 的优势：精益思维

作为精益 - 敏捷方法，Kanban-Ace 充分包含了精益思想和它的一个核心原则：减少浪费。这一原则对 Kanban-Ace Scrum 团队的影响是什么？主要影响是质疑事件或仪式的价值，曾经事件和仪式被团队认为是浪费。让我用一个例子来进行解释：一个开发一个苹果手机应用程序的团队，需要几天的时间对他们的应用程序做重大的改变，因此他们认为每天开一次每日站立短会是一种浪费，因而他们选择每周开两次站立短会，而不是五次。这不仅会给他们赢得更多额外的时间，但它也将提高团队的士气，因为没有人特别喜欢在会议上浪费时间，人们将只参加一个真正有用的会议，比如发布之后的回顾会议。因此 Kanban-Ace 敦促你减少浪费，减少会议时间，相应应对团队沟通和节约的需求。我仍要提醒你，减少浪费是一个重要原则，但不要迷恋它。不同于机器，人需要放松和休息来发挥他们的最佳才干。

精益思想也引导你去思考整个系统以及你在整个系统中的位置如何影响整个价值流的价值创造。其中一个结果是当有一个 Sprint（意思是受保护的迭代）对整体业务或部门是有意义时，做出选择。通常当处理产品开发 Sprint 时非常有意义，但你做运维的时候，信息技术的基础设施或任何其他技术领域需要一天几次发布，这时去除 Sprint 和选择标准的包含持续发布的 Kanban-Ace 板会更好！因此，检查和适应，如果它符合你的需求，使用较少 Sprint 的持续流！

B.Kanban-Ace 的优势：我们的知识库

Kanban-Ace 为 Scrum 实践者提供了许多重要的原则、价值观和技术，他们现在都是包含在我们的知识库中的。我想强调其中的几个：

• 最小的可操作的规划。它创造出有用的敏捷计划，可以指导版本的交付，或最小可行产品（MVPs）的创作。
• 按需发布。Kanban-Ace 板包括按需发布，只要你准备好了就可以部署它们；无论是一周几次，或者一天许多次。Sprint 是可选的，可以只在需要时使用。Kanban-Ace 欢迎持续集成，持续发布并与信息工程基础设施、运营和 DevOps 一起运作。
• Kanban-Ace 齿轮。这是一种工具，教我们如何检查整个价值链和工作流，以带来彻底的改善，使过程、工具和团队可以达到新的性能水平。这不是每天进步一点点的改善（Kaizen），或小的持续改进，而是突破性的改善（Kaikaku）或革命性的变化。
• 角色的实用主义。今天 Kanban-Ace 承认如果一个组织选择了一个角色，组织就肯定需要它。我们不反对这些角色，或要求公司严格地采用新的角色，我们要从现在拥有的角色开始，从中改善。Akashi Bridge 就已经采用了同一种理念，以此迎合 Scrum 角色。
• 价值观。Scrum 花了十多年时间，最终明确地接受了价值观作为框架的一部分的，但这仍然是好消息。然而，我们很高兴地说，其实从第一天起，Kanban-Ace 已经接受了保护团队和交付软件的价值观！这些价值观有：勇气、专注、合作和尊重人。

最后，我想提一下，我正忙着写 Kanban-Ace 框架的书，这本书将在 2017 年出版发行。在这本书里，我打算介绍很多有用的创新，比如 ACE 故事点、轻量级扩展和 SAFe 支持。如果你想与我保持联系，并在第一时间知道这本书什么时候出版，请与我联系。

最后，我想引用我非常钦佩的人的一句话做总结。艾萨克•牛顿爵士说：“我们建造了太多的墙，却没有足够的桥梁。”

Joseph Hurtado是 Kanban-Ace 框架和开放 Kanban 的作者，他也是 Agilelion 学院创始人。专业上，他被认证为 SAFe SPC 4（敏捷教练）、Kanban-Ace 教练和 Scrum CSM。他热衷于软件和产品开发的人性和技术方面，他领导的团队在各种行业提供技术解决方案。他的敏捷方法使工作愉快，提供出色的软件，同时保持团队士气高涨和身体健康。在技术之外，他的兴趣是摄影，艺术和哲学。你可以在 LinkedIn 、 Twitter 和网站上找到他。

阅读英文原文： Improving Scrum with the Kanban-Ace Framework