BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Steve Reid 关注 0 他的粉丝 , Prateek Singh 关注 0 他的粉丝 , Daniel S. Vacanti 关注 0 他的粉丝 ,译者 刘嘉洋 关注 0 他的粉丝 发布于 2016年12月13日. 估计阅读时间: 25 分钟 | QCon北京2018全面起航:开启与Netflix、微软、ThoughtWorks等公司的技术创新之路!

亲爱的读者:我们最近添加了一些个人消息定制功能,您只需选择感兴趣的技术主题,即可获取重要资讯的邮件和网页通知

关键字

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

介绍

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT