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”直接指的是丰田公司组织跨工厂和部门工作的制造技术,这种技术和其他几种技术构成了丰田生产系统( Toyota Production System ,TPS)。TPS开始于1945年。到了1978年, 大野耐一 在日本出版的书是一个重要的里程碑。感谢Norman Bodek的努力,十年后这本书的英文版出版,使得它可以在西方世界传播。
知识工作Kanban或首字母大写的Kanban指的是围绕应用TPS理念、约束理论、精益开发和其他相关资源的改变和创新,以便重点管理和改善人类创造力相关的领域,特别强调以软件开发、信息工程、营销和管理为重点。知识工作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 的早期精益相关著作。
大约在2013年,David Anderson决定生成一个自己版本的Kanban,他称之为不同方向的Kanban方法(The Kanban Method),与所有其他的敏捷方法都不同,把重点放在“进化改进”和改善管理方式上。在向着这个方向努力的过程中他多次声明,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系统的一些看法》。
毫无疑问,丰富的书籍、ScrumMaster、培训和成功的故事是Scrum的最大优势。该框架已成为敏捷的基础,在信息技术、软件开发、市场营销和产品开发领域,许多人对它甚是熟悉。
在我看来,除了成功和认可,另外这两个关键的优势是:
然而,Scrum并非没有缺点,也不是没有可提高的空间。最近通过Agilelion研究所,我们用调查的形式收集了一些关于这个话题的反馈意见。原创文章中有我们研究结果的详细报告,但我还是想用下面的图表总结我们的研究结果:
如图所示,用户看到Scrum有四个弱点:
要把上述列表的每一项问题都解决,需要写几本书才能完成。所以,我选择讲述Kanban-Ace框架会如何改善上述领域中出现的问题,好让ScrumMasters、产品经理、研发人员和管理者轻松一些。
我不打算对Kanban-Ace框架的每一个值、实践和技术一一做解释,我想要给你们简单讲讲我们能给Scrum带来的主要好处。
如果你对Kanban-Ace框架的全面探讨感兴趣,包括理论、价值、原则和技术,我强烈推荐你去 Agilelion学院 。在那里,我们为你提供在线和现场 培训 和认证。
Kanban-Ace框架提供了一系列的工具和技术来解决Scrum在Kanban领域的薄弱环节,但仍保持着每天你习惯使用的Scrum的关键要素。我们提供的这个系列的工具和技术叫做Akashi。在我们详细探讨这一能使我们把Scrum的精华和Kanban-Ace相结合的技术之前,我们必须了解Kanban-Ace是如何通过它的主要优势来运作的——将工作可视化。
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是一个巨型的功能,减少基础原则基本说明了这一点:让你的努力成为颗粒状,并尽可能的小,而一旦你使之变小,尽可能一次做尽可能少的工作,你就能集中精力努力。一旦体积变小了,限制在制品是容易的!
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课堂 构成部分的好处。我想提醒你注意我们之前介绍过的明石大桥的额外优势中的两点:
作为精益-敏捷方法,Kanban-Ace充分包含了精益思想和它的一个核心原则:减少浪费。这一原则对Kanban-Ace Scrum团队的影响是什么?主要影响是质疑事件或仪式的价值,曾经事件和仪式被团队认为是浪费。让我用一个例子来进行解释:一个开发一个苹果手机应用程序的团队,需要几天的时间对他们的应用程序做重大的改变,因此他们认为每天开一次每日站立短会是一种浪费,因而他们选择每周开两次站立短会,而不是五次。这不仅会给他们赢得更多额外的时间,但它也将提高团队的士气,因为没有人特别喜欢在会议上浪费时间,人们将只参加一个真正有用的会议,比如发布之后的回顾会议。因此Kanban-Ace敦促你减少浪费,减少会议时间,相应应对团队沟通和节约的需求。我仍要提醒你,减少浪费是一个重要原则,但不要迷恋它。不同于机器,人需要放松和休息来发挥他们的最佳才干。
精益思想也引导你去思考整个系统以及你在整个系统中的位置如何影响整个价值流的价值创造。其中一个结果是当有一个Sprint(意思是受保护的迭代)对整体业务或部门是有意义时,做出选择。通常当处理产品开发Sprint时非常有意义,但你做运维的时候,信息技术的基础设施或任何其他技术领域需要一天几次发布,这时去除Sprint和选择标准的包含持续发布的Kanban-Ace板会更好!因此,检查和适应,如果它符合你的需求,使用较少Sprint的持续流!
Kanban-Ace为Scrum实践者提供了许多重要的原则、价值观和技术,他们现在都是包含在我们的知识库中的。我想强调其中的几个:
最后,我想提一下,我正忙着写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