Ultimate Kanban：Ultimate Software 不使用框架实现规模化敏捷

关键字

• 简单周期时间指标可以促进有价值的讨论和改变
• 团队层面的过程自动化对生产率和可预测性帮助很大
• 规模化敏捷可以在不使用开销较大的预定义框架的情况下实现
• 概率预测可以提供早期预警信号，简化规划
• 使用连续流模型工作有助于轻松地响应变化

介绍

Ultimate Software 是全球领先的人力资源及工资管理软件提供商。它在过去的五年中被评选为“财富全球 25 佳最适宜工作的公司”，并在 2016 年被评选为“最佳技术公司”。Ultimate Software 公司的企业文化是“以人为本”。从 CEO 到团队领导，每一层管理者都鼓励员工能够充满创新性和创造力地完成日常工作。公司非常关心员工，“以人为本”的公司理念不仅仅只针对于其产品的用户，更适用于为每位 Ultimate 的员工所提供的舒适的环境。

Ultimate 的开发组织由来自 25 个团队的 900 名员工组成，所有的团队都遵循敏捷开发原则。敏捷原则非常适用于 Ultimate，主要有以下两个原因：

1. 处于竞争激烈的市场
2. 需要对联邦、州和地方创建的有关工资、税收和人力资源的新法律实时做出回应（比如说平价医疗法）

之前大规模尝试 Scrum 失败之后，Ultimate 最终决定以 Kanban 作为其规模化管理方法。Kanban 提供了与公司自主的文化相结合的框架。团队可以重新定义自己的流程，并根据自身情况施行。这个自主性流程是对 Ultimate Software 文化价值的衍生，表达了其自身的观念。

背景介绍

Ultimate 自 2005 年起就开始尝试使用敏捷原则（即 Scrum）。一开始向 Scrum 的过渡帮助 Ultimate 团队实现了更广泛的业务目标。然而，还有很多 Scrum 不能很好处理的常见问题。比如有一些政策的变化需要团队做出即刻反应，他们需要放弃原来 sprints 中的计划，转而做新的需求。还有理想中小的 Scrum 团队（规模大约在 7 到 9 名成员）跨团队协调成本却非常高。最重要的是，我们尝试 Scrum 方法一段时间后并没有看到生产力的重大突破。

使用了 Scrum 一段时间后，Ultimate 尝试通过 Scrum 原则中对于团队领导的重新训练“再次起步”。然而这次训练是由精益和 XP 的实践实现的。让我们失望的是，这次重新启动仍然没有达成公司正在寻求的超级生产力。

鉴于此，产品开发部门的领导开始尝试 Kanban。作为 Kanban 的第一次试水，我们选择了基础设施团队，因为这个团队问题比较严重。我们并没有非常清晰地直接从 Scrum 方法转换到 Kanban 方法，而是在看板上可视化团队的工作。我们还限制了团队中每个成员正在进行中的工作数。在最终决定放弃 spring 计划和 sprint 回顾之前，团队还是使用了 scrum 的整套规范一段时间。限制 WIP、可视化工作对团队产生了立竿见影的效果。团队可以根据 tickets 进行工作，并保持进展。团队的工作量越来越少，但是成果越来越多，他们已经完全接受了这种方法。基于这个团队的成功，我们在其他核心产品开发团队中都沿用了这种方法。该方法再一次被验证成功。不久后，所有团队都开始使用 Kanban 系统了。

这一改动立竿见影。Kanban 对于团队的规模并没有明确的限制，于是我们可以将业务线交由大型团队完成以降低交易成本。在这些大型团队组建的初始阶段，人们表现地更像是一个团队中还有团队。小型的团队形成了紧密的联系和独特的亚文化，需要一段时间之后才能融入到大团队文化中来。一旦整个团队都开始向一个目标努力，向大型团队的过渡也有了成果。采纳 Kanban 方法也标志着我们第一次达成了敏捷方法带来的超生产力。Kanban 原则和流量指数帮助团队获得自开始实践敏捷方法以来一直想获得的生产力结果。这些结果将详细地在第三部分中进行讨论。

Kanban 的成果

我们在 2014 年底重新开始关注 Kanban。对于组织中团队的每一个人，我们都重新训练 Kanban 原则的重要性和流指数的重要性。每个开发团队都参加了为期两天的课程，课程中安排了流和 Kanban 的相关内容。团队共同构建了过程的映射。我们专注于明确映射、可视化流程、限制 WIP 和流管理带来的优势。团队的每个成员都参与到流程定义、决定 WIP 限制和制定团队应遵守的政策的练习中来。团队开始关注基本流指数：进行中工作（WIP）、周期时间和吞吐量。如果你不熟悉这些概念，我们强烈建议你阅读 Daniel Vacanti 的《可预测的可行敏捷指标》一书。这样产生的结果远比我们的预期要好，我们将在下面的各个团队的案例中详细进行说明。

Aces 团队

• 团队负责 Pay Calculation Engine 的新项目开发
• 周期时间减少了 60%，故事完成度从 35 天完成 85%（使用 Scrum）缩减到 14 天完成 85%（使用 Kanban）
• 由于决定将一些资源重新集中在其他项目上，团队失去了一半成员，但是故障吞吐量却增加了 10%

ACES 团队是在 2013 年成立的 16 人 Scrum 团队，全权负责开发新的 Pay Calculation Engine。在使用 Scrum 方法的早期，因为团队开发的进度一致，大家都认为这个方法很成功。然而，根据流指数检测团队提供的数据，我们发现开发过程的效率非常低下。要补救这一点，团队必须获得更高的效率，从而得到更高的生产率和更大的可预测性。

可以用来展示团队可预测性的最好的图表之一是周期时间散点图。下面的散点图对于使用 Kanban 方法前后的性能进行了对比：

(点击放大图像)

图1：ACES 团队周期时间散点图，左图为使用Kanban 前，右图为使用Kanban 后

图1 的左图显示当团队使用Scrum 实践的时候，85% 的故事需要使用少于等于30 天完成。35 天的循环时间本身并没有什么危害，但如果团队的sprints 周期是14 天左右就会产生问题。此外，在同一时间框架内完成50% 的故事需要使用少于等于15 天。这意味着，就算从sprint 一开始做的故事只有一半的几率能在同一个sprint 中完成。这并不是非常可预测的Scrum 速度指标。

在记录了散点图之后，团队开始深入研究为何故事需要这么长时间才能完成。他们发现大多数需要长时间完成的故事会长时间在“等待QA”栏中。这就是一个很明显的问题，因为“等待QA”栏是一个排队队列，故事只能等待，并没有得到积极处理。这些“等待”项目非常容易实现，所以它们在“等待QA”栏中，团队决定先给这些栏设置WIP 限制为5。团队还优先考虑已经工作了最长时间的工作，以实现完成工作率的一致，而不是让故事工作时间无限延长。这个决定意味着如果有5 个及以上的任务正在等待QA，开发人员就不能引入新的工作。他们将不得不投入对于产品的测试。这已经被团队讨论并接受为确保工作流程的恰当行为。

这些举措产生的结果立竿见影。从这一点开始（参见图2 的右图），团队能够在少于等于14 天内完成85% 的故事。ACES 的吞吐量也从每天1.07 个故事增加到每天1.41 个故事。这是在团队规模缩小到原始规模的一半的同时实现的。这些修改不包括故事大小的变化或加班。团队通过对等待QA 栏降低WIP 限制以及鼓励团队成员跨领域帮助的方式加强流程，以确保看板上没有一项时间超过85%。这也代表着开发人员要完成更多测试，而测试人员需要完成更多开发工作。最终，角色之间的界限变得非常模糊。团队成为了一个良好运作并紧密联系的团体。他们更好地理解不同角色的需求，并共同解决不同问题。

Payroll 团队

• 负责在频繁被紧急客户请求打断的情况下进行核心工资核算
• 故事平均等待时间降低 79%，从 8.84 天缩减到 1.88 天
• 故事周期时间缩短 69%，从 35 天完成 85% 缩短到 11 天完成 85%

Payroll 团队为 Ultimate Software 的旗舰产品 Ultipro 维护和开发核心工资核算功能。这是自 2009 年由三个独立的小型 Scrum 团队组成的 30 人团队。值得注意的是，该团队的计划经常会被紧急客户问题打断（想想如果你的工资不能准确计算或按时派发你一定会感觉很不高兴）。

自 Kanban 2015 年重新培训后，Payroll 团队立即改变了他们的工作方式。他们做出的最大改变就是将看板上 WIP 限制降低到团队总人数之下。这种变化也是为了促进结对并消除知识盲点。实现的系统弹性可以让团队有足够的时间处理紧急客户问题。采用这样严格的 WIP 限制意味着在系统不太熟悉的领域也可以进行更多结对。团队中的一些个体不愿意改变，他们还是坚守自己的方法。但是这也迫使他们采取测试第一，结对并跨领域合作的实践。采取这些政策和做法的结果立刻显现在团队完成故事所需的时间上。随着时间的推移，故事花费在排队状态中的时间急剧减少，因此团队的“周期时间”也急剧减少。下表显示了自 2015 年 3 月底的团队培训以来周期时间的持续缩短。

(点击放大图像)

图 2：Payroll 周期时间 VS 等待时间

从图 2 中我们可以发现团队花在故事上的净时间并没有改变。通过限制 WIP，团队可以避免故事在看板上等待的时间。由于团队可以更加高效地使用 Kanban 系统，并开始协调其流程策略，因此他们能在故事完成时间中获得更多一致性（再一次在 85%，见图 2）。团队通过对过程的控制实现了对 Ultimate Software 自主的文化规范的巩固。不仅仅是 Ultimate Software，几乎所有的开发团队中，经理都退位作为教练，以便团队可以自主调整自己的工作方式。这些团队在大多数情况下没有将这看作是一个额外的负担，他们非常享受这样操作的灵活性。

对周期时间更大的可预测性有两个直接的影响。首先，团队可以更快、更频繁地向客户交付。其次，当紧急问题出现时，团队可以先考虑“可以等到我们手头正在做的项目做完之后再去做吗？”。由于工作项目进展速度变得更快了，有一小部分人可以着手去做下一个项目。由于每天都会有团队成员空出来，团队可以请请求方拖延几个小时或延迟到第二天早上。在非常紧急的情况下，结对的团队成员可以暂时独立出来先处理特殊情况。如果团队平均花费 20 天以上完成工作项目，要尽量避免问相同的问题。

团队的经理是这样谈起他们使用 Kanban 原则的经验的：

“一开始我们觉得限制 WIP 和简化 Kanban 的想法非常可笑。我们非常确定这种方法对我们团队“永远不会有效”。但是在四月进行了 Kanban 培训之后我们的想法彻底发生了改变。我们改变了看板，修改了站会的形式，实施了合理的 WIP 限制并彻底改变了我们的工作方式。

在 Kanban 2.0 之前，如果看板上少于 40 个故事，那一定是非常“宽松的”。但现在，我们看板上的故事很少超过 20。令我们惊讶的是，培训的内容真的有效！我们可以更快地调整工作，并提供更高质量的功能。作为一个经理，我现在可以一目了然地看到团队的所有工作，并在发生事故之前精准定位。最后，拥有稳定的周期时间和吞吐量数据使我们能准确预测未来发布规划和紧急处理生产需求的能力。

想到我们过去的工作方法，不知是哭好还是笑好。”

-Leighton Gill

软件工程经理

组织范围影响

上述改进不仅限于这两个团队。事实上，几乎所有开发组织团队中都有改进。2014 年至 2015 年间完成的故事数量和完成的功能数量显著增加。更短的故事周期时间转换为更快的功能实现。更快地完成功能使得交付给客户的功能总数大大增加：从 2014 年的 176 个增长到 2015 年的 411 个。从月份比较来看，2015 年每个月的生产率都比 2014 年同期要高。

(点击放大图像)

图3：每月功能实现对比

Ultimate Software 公司的企业文化在转型中起到了关键作用。提供给员工自主权，信任员工会为企业做出正确的事情，这都为公司的转型添砖加瓦。团队成员很少表现出“这不是我的工作”的态度，他们会通过努力确保开发出价值流来回应管理层的信任。

这些组织上的改进有助于简化发布规划过程。周期时间变得如此可预测，吞吐量变得如此稳定，我们就可以尝试更复杂的规划技术——其中最重要的是蒙特卡罗模拟。

蒙特卡罗模拟和概率发布计划和追踪

蒙特卡罗模拟（MCS）是一种预测技术，在其过程中过去的数据被用于模拟系统的未来性能。模拟技术对风险级别进行大致评估，企业可以使用该风险级别确定愿意承担多少风险。我们并没有太深入了解 MCS 和它的使用方法，我们邀请你来探究这个方法。

发布计划

MCS 特别适用于了解在确定了某日需要完成的故事数量的情况下，该日可以交付的概率。在发布的不同时间点运行的模拟可以告诉我们，团队的工作是否落后于所承诺的时间，是否达到了规划日期或是否可以在这次发布中完成更多任务。与使用平均值获得的单一结果相反，蒙特卡罗根据可信度的不同提供了更广范围的可能结果。这使得团队能够以团队和产品经理同意的任何信任级别进行提交。由于该方法使用团队过去的数据，所以团队完全可以影响预测，并确定他们做出承诺的可信度。

在 Ultimate，每个团队的发布都是独立的，每个团队都有自己的发布日期。使用第 3 部分中提到的故事数据，并将这些数据提供给 MCS，我们得到了一个发布仪表板来跟踪每个团队对应其目标日期的进度。下图是蒙特卡罗追踪仪表板的截图，每天每小时更新一次，反映正在进行中的每个发布的完成可能性。这里的信息还包括发布的代码冻结日期，尚待关闭的故事以及团队完成发布故事 85% 的日期。

通常团队做出承诺时的信心比较高。这代表着他们一般会承诺完成较少的故事。一旦初期承诺达成，蒙特卡罗模拟会告诉团队他们可以开始做新的工作。如果团队有这个能力，他们就会承诺完成新的工作。随着发布日期越来越接近，需要延迟发布的可能性逐渐增加（比如说团队可能因为任何原因减慢速度）。在红色区域的点受到团队的关注，他们会做出这些点的风险缓解。

(点击放大图像)

图 4：蒙特卡罗仪表板

这个仪表板使团队可以一目了然看到任何妨碍发布按时完成的风险。仪表板对于我们规模化敏捷实践非常重要，我们称其为每日产品评估，在每日的会议上我们都会非常关注它。

每日产品评估

每日产品评估（DRP）是 Ultimate Software 的 Scrum of Scrums 的后继者。DRP 是每日 15 分钟的会议，通过评估周期时间和发布完成可能性给开发组织提供参考。它强调了我们每天必须关注的指标和实践。Ultimate 有一个大型的开发组织，团队自主、（大部分时间）独立运行。DRP 帮助团队的领导者重申我们都是整体的一部分的概念。下面是一些 DRP 板块可以帮助我们加强和规模化这些实践。

图 4 所示的蒙特卡罗仪表板的修改版本与 DRP 板不同。该仪表板仅仅在每天的上午更新，剩余故事和完成可能性列包含了前一天同样时间做出的更改。当团队的发布开始变红或进一步进入红色的时候，他们会回应以以下任何策略：

• 减少发布的规模。
• 修改发布的时间。
• 进行额外的工作来完成剩下的故事。
• 可能会执行以上策略的任意组合或是执行所有的策略。

DRP 板的另一部分是单独的团队更新贴。这些更新贴的颜色分别为绿色、黄色或红色，颜色的改变是基于团队达到 95% 周期时间故事的数目而改变。团队可以往贴上添加注释，解释用较长时间完成故事的原因以及他们处理超长时间故事所采取的行动。这里的假设是，超过 95% 的故事不再受团队控制。下图显示了 Payroll 团队的更新贴，第一个故事由于外部依赖性受到了阻塞，第二个故事则由于缺乏正确的搭建被阻塞。当遇到阻塞问题时，开发团队的经理通常会尝试解决问题。如果团队成员都能了解这些阻塞的解决对进展的预测有多重要，他们将会尽可能快地解决问题。

(点击放大图像)

图5：DRP 板中团队更新贴

超越开发

采用敏捷技术有助于提高生产率和可预测性。从总体来说，Ultimate Software 采用瀑布模型和三明治方法。敏捷开发组织处于传统的销售和支持组织和传统的部署和激活组织之间。为了Ultimate Software 敏捷和基于流的下一步演变，我们也在努力扩展我们的组织。Ultimate 的文化鼓励经理和员工自主创新，做出对公司有利的决定，极大地促进在核心发展之外原则的传播。Ultimate Software 已经开始将敏捷教练服务推广到各个部门之中，帮助他们遵照相同的原则进行开发。

我们与产品战略部门的密切合作以及可预测性能力的提升，大大提高了开发过程中，在不中断工作的同时，也能协助解决问题的能力。Tier 3 支持还采用了Kanban 实践，以提升支持客户的能力。产品策略部门可以利用开发环节可预测性和生产力的提高，对即将推出的产品和功能的销售提供更好的指导。随着我们不断改进销售环节的可预测性，我们可以与销售部门一起创建功能请求和优先级。之后就可以通过价值流、追踪周期时间和吞吐量决定功能，从而使我们对客户做出更准确的承诺。

尽管上游扩展可以帮助我们更好地创造价值，扩展部署和激活也能帮助我们改善对客户的交付价值。由于Ultimate Software 已经开始开发新的产品，我们也将部署活动引入到各团队。对于我们的旧产品，我们总是会交给Sass 部署团队。通过将部署工程师引入到新产品开发团队，指导他们如何维护自己的部署管道的方式缓解了“越墙式”心理。团队最初担心会不会承担额外的责任，后来团队意识到他们可以为组织的其他成员提供支持的时候，这种担心就逐渐减少了。这种做法还大大减少了生产环境意外的发生。由于团队帮助搭建他们部署代码的环境，在生产环节代码也不会发生意外。这些团队由产品工程部门外的三个小组提供支持。负责正在开发产品的构建和部署基础设施的团队也采用了Kanban 原则，并开始测算周期时间，以便为团队提供基础设施。他们已经为不同类型的请求建立了SLAs，这些度量也变得可预测。

我们现在可以看到一个功能的全过程，从销售到产品策略，到开发，最后到生产。一旦能够以这种方式追踪功能的进度，我们就可以确定从开始到交付环节可以做出什么改进。作为一个整体，组织可以确定哪个功能陷入了困境，并应用我们对流的理解缩短功能等候所产生的时间。

在开发和部署后的另外一个方面是激活。激活部门是能帮助新客户使用Ultimate Software 产品的团队。激活过程可能需要长达一年时间，并可能涉及到多个团队。当客户处于激活阶段，Ultimate Software 投入的时间并没有得到完全的回报。这是一个可以利用开发组织从流和敏捷实践中所收获的经验的领域。开发与激活部门相互合作，共享原则和时间，为可交付结果的可预测性和完成速度带来了积极的影响。

Ultimate Software 下一步目标就是逐渐停止使用 Kanban。通过与支持和部署团队的合作，我们已经开始朝着这个方向迈进。Ultimate 将继续规模化敏捷方法，而不使用任何已经创建的框架。建立正确的沟通渠道，以一种容易被大家理解的方式可视化我们的工作，这是 Ultimate 成功地大规模采纳和发展敏捷方法的关键。

总结

通过创新使用流实践和原则，Ultimate 从精益敏捷中受益匪浅，公司也不再使用重量级框架：

• 提高生产力：更快地向客户发布更多功能，客户整体满意度也相应提升
• 简化规划：使用蒙特卡罗模拟等技术，计划发布的时间从几天缩短到几分钟
• 早期警告信号：在开发过程的早期观察到一个给定的故事或发布偏离规划，我们可以提早做出反应进行调整
• 轻松地做出改变：如果我们没有详细了解我们的真实能力，我们就不能及时转去处理新的客户需求或是政府法规

我们已经充分了解到这些好处，并以传统的规模化敏捷实施成本的一小部分实现。这里概述的实践是无论大小的任何组织都可以轻松实践，并立即收获成功的方法。

参考书目

Daniel Vacanti，《可预测的可行敏捷指标》，ActionableAgile Press 2015

致谢

我们要感谢Rafael Santos 和Fernando Trigoso，他们为Ultimate Software 早期取得敏捷和Kanban 的成功起到了至关重要的作用。

关于作者

Steve Reid已经在 Ultimate Software 工作了超过 16 年，他开发了大规模的人力资本管理系统。他目前的工作是负责研究精益敏捷思维。在此之前，他曾担任多个管理职位，包括软件工程副总裁和软件工程总监。

Daniel Vacanti服务于软件行业超过 20 年。2006 年，他帮助开发了 Kanban 方法，并一直帮助世界各地的团队实施流原则。他的书《可预测的可行敏捷指标》于 2015 年出版，是敏捷环境中使用流指标的终极指南。

Prateek Singh在过去的 10 年中一直领导并致力于敏捷团队。从 XP，到 Scrum，再到现在的 Kanban 系统，Prateek 目前负责对 Ultimate Software 中使用 Kanban 和精益原则的团队进行指导和培训。

查看英文原文： Ultimate Kanban: Scaling Agile without Frameworks at Ultimate Software