BT

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

Kanban in Action 新书问答

| 作者 Ben Linders 关注 20 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2014年10月30日. 估计阅读时间: 21 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

Kanban in Action 是Marcus Hammarberg 和 Joakim Sundén的最新著作,介绍了如何用看板结合实际实施管理。其中提到如何使用看板将工作可视化、跟踪进度,限制在制品,以及使用哪些度量指标进行改进。书中同时介绍了一些游戏和练习,可供学习看板原则。

点击这里可以获取本书样章。

Manning出版公司为 InfoQ的读者准备了如下特别优惠:“当你购买 Kanban in Action 一书时,购物车中所有货品都享受40%优惠。下单结算时,只需在优惠码(Promotion Code)文本框中输入 'kanban40infoq' 即可。只在 manning.com 才能享受此优惠。”

InfoQ:为什么要撰写这本书?它与其他看板书籍有何不同?

Marcus:实际上有个很有趣的故事。当时,Manning让我给他们打电话,我那时有印象,他们在写一本看板的书。所以我也很放松,因为也不过就是参加个调查。他们的第一个问题是:“在你看来,看板的书中应该包括什么内容?”我是这么说的:

《看板方法 : 科技企业渐进变革成功之道》这本书已经可以算是看板领域的圣经了。是它的作者 David J Andersson 将看板引入了软件开发的世界。无论什么新书也达不到这个高度,除非采取完全不同的途径。我希望看到的书,最好从实用的、常见的、每天都能碰到的问题开始,而且要把重点放在这些内容上,理论有一些基本的就可以了。如果要说,可以说是“我们的看板”之类的书。

跟 Manning 的人聊了45分钟之后,他们问我:所以,你愿意给我们写这样一本书吗?

我当时目瞪口呆,可能说了“我愿意”,但也拿不准。

(我现在还不知道他们为什么给我打电话。也许是弄错号码了,但我不会说出来的。:) )

接下来,我想,我得跟 Joakim 一起写这本书,因为这些年来我们一直围绕看板展开工作。

Joakim:Marcus 太谦虚了。过去,我们已经完成了一个很深入的看板指南,在多个大会上做过演讲和展示,形式包括短演讲和整整一天的工作坊。我们已经准备了多年的材料,而且在几百个人身上得到验证。在他特别热门的博客上,Marcus也写了很多与看板有关的内容。所以,Manning 找他也不奇怪。既然我们一起制定和交付了那么多内容,Marcus一开始找我加入进来,我觉得也很自然。他这么做我很高兴,这本书能让我们总结过去的经验。我们觉得手上的材料能填充200-250页,结果写了360页……

InfoQ:你们的书一开始,讲述了一个面临困境的团队的故事。为什么要采取这种写法?

Marcus: 我和 Joakim 都是讲故事这种方法的粉丝,我们读过的很多好书也用了这种手法,比如 艾利·高德拉特的《目标》。我们也想尝试那种写法。而且,这种手法也能让我们很好地贯彻我们的理念,保持实用性,只提供“基本”理论。书中一开始的教练课程中,有一个滴答作响的钟,就是这个原因。他们没有时间深入所有细节,但是足够开始动手,知道要解决什么问题。当团队开始解决“尚未意识到的改进机会”(又名:问题),以改进工作流程时,真正的学习也就开始了。

Joakim: 我们写那一章时特别开心,其中到处都是小笑话,某些只有我们两个人懂。我们常常担心,这种方法我们觉得很有趣,但读者不会欣赏我们的幽默和小说技巧。为了收集反馈,我们在多个审读环节加入了一个问题,也让朋友和同事读这本书。有些审读者不太喜欢,但是不少人还是很钟爱这种方法。最后,要保留这种写法也就很快定下来了,不过,我们还是可以保证:你不看这一章,对理解后续章节也没有影响;而且我们还在这一章前面放了免责声明。:)

InfoQ:书中多次提到精益。看板和精益之间是什么关系?

Joakim: 看板在用于精益生产中的日程安排系统。 它是在丰田产生的,目的是为了改善生产,方法是鼓励人们持续改进“准时制(Just-in-Time)” 产品和服务生产流程,同时避免导致系统和工人负担过重。主要通过限制在制品、可视化和管理工作流实现。这与看板在软件开发中的使用很像。就像 Scrum 只是敏捷的一部分一样,看板只是精益的一个部分,但是其中容纳了一些精益最重要的原则。

Marcus: 嗯……我觉得这个问题不好回答。因为二者是并行的。看板是一种工具,很多精益实践者和团队都在使用。精益是一种业务战略,其重点关注流动中的工作,要保证其尽可能平滑和快速。你实施精益可以不用看板,也可以实施看板不用精益……但大部分都不这么做。它们还是并行的。

在我个人来说,看板让我开始阅读和学习精益。

InfoQ:你们能不能给 InfoQ 的读者说说,看板中的“板”长什么样子?

Marcus:这主要根据每个人的具体情况而定。这个板还是为了让你当前的、实际的工作流程一目了然。一般来说,它是一系列竖栏,表明当一项工作从左向右流动时,价值在哪些地方加入。假如说工作是从上流动到下,那就类似“泳道”。还有螺旋板,不同板之间有开关,可以切换到不同的泳道甚至是不同的板,等等等等。大多数还是使用竖栏方式。

你需要展示真实的工作流程,而不是梦中看到的,或是要写在正式文档中的。要保证尽可能接近真实情况。

一般来说,尽可能把整个流程放到上面去,这样总没错。就算有些步骤是第三方团队或利益相关者完成,也没关系。在我们的故事中,Kanbaneros 团队与部署代码的团队不在一起。但Kanbaneros 团队还是决定将其作为一栏展示在他们的板子上,展示出他们在等待的工作。也许这能引发一些讨论,看看是否有助于改进整体流程。

哦对了,最后还要提醒,要用马克笔在白板上画,这样很容易调整。而且要经常调整。因为这个板子也只是“目前的最佳状况”。我们的目标是要改进流程,并将其用可视化方式展示。

InfoQ:看板和 Scrum 中的板子有何区别?为什么存在这些区别?

Marcus:最主要的区别在于:Scrum 中的板子在每个 sprint 之前都会重置。在 sprint 开始,你会把所有打算在 sprint 中完成的工作放上去,放在第一栏(待办、Todo)中。在 sprint 之中,工作会在板子上流动,并在最终栏(Done、Completed、完成,或其他什么名字)中终结。然后,板子就会用于下个 sprint。

看板不会主导 sprint,所以常见情况是,它更像是持续的工作流程,只要板子上还有地方,而且没有超过在制品 WIP 的限制,我们就会向第一栏中加入新工作。

还有一个可能存在的区别:

看板有可能存在更多竖栏,流程细化程度更高。很多 Scrum 团队使用 Todo、Doing、Done 三栏,详细的拆分放在将每个工作项拆分为具体任务上。

看板一般都有某种在制品 WIP 限制,用来限制某个竖栏或者整个板子中的工作数目。这在 Scrum 团队中也有,可能团队只会为下个 sprint 拉动合适数目的工作,如果他们觉得合适,而且没有其他情况的条件下。

我的经验中,看板变化更频繁,而 Scrum 板子则不是。这只是我的经验,当时不是说 Scrum 团队就不能这么做。我们曾经这么传授 Scrum。我有这么一些客户,他们在参加过 Scrum master 的课程之后,就会说:“Scrum不适合我们。我们不能用 Todo、Doing 和 Done。我的老师说那是 Scrum 中板子的样子。”不!你要自己决定它长什么样子。

Joakim: 我想强调的是,这些区别是我们在所谓“我们实施 Scrum”和所谓“我们实施看板”两种团队之间发现的常见区别。我们将看板视为某种“元过程(meta-process)”,你可以将其应用到任何事情中,所以“正确的”描述方式可能是:“我们用看板实施 Scrum”,或者“我们从实施 Scrum 开始,同时是用看板,现在,我们已经转而使用持续的‘准时’规划来完成 Sprint 规划,所以我估计我们也不能说是在实施 Scrum 了”。把二者结合起来没有问题,不过我的经验是不太可能出现这样的情况:Scrum 团队已经拥抱了看板,但还是死抱着 Scrum 教条不放。看板内在的持续改进和实用主义,会引导他们定制自己的流程。

InfoQ:真实看板和数字化看板之间的主要区别是什么?是否有方式可以结合?

Marcus: 这个问题有点儿难啊。。。一个是真实的,另一个。。。

实际上,说到看板,这是我们被人问得最多的问题。我觉得有两个重要差异:

真正的看板,你可以摸到它,比起浏览器里面的一个标签页,更有存在感。即便我们已经解决了大屏幕投影的问题,我还是对真实的、一整面墙的板子更“有感觉”。

每种工具都存在局限。说到看到什么,以及如何可视化,真实的看板局限更少。虽然现在有些比较新的看板工具还不错,可以做很多自定义(比如 LeanKit 的看板,网址 http://leankit.com/,良心推荐),但总是有限制。

话虽如此,数字化看板可以很快创建很多数据和统计,又不费力,还能保证大家遵守你提出的原则和方针(比如,如果违反了某项原则,就无法把一个卡片插入到某列中)。

我们经常这样建议:不妨先从真实看板开始,等适应差不多了,再切换到数字化看板。使用工具,而不是让工具使用你。

Joakim: 我都喜欢用。喜欢真实的,因为它们更容易持续改进,它们的信息更易于获取,而且鼓励协作;喜欢数字的,因为分布式团队和项目干系人可以参与进来,同时更容易产生度量数据。有人认为:同时维护真实看板和数字看板太麻烦了。我想这是因为开发人员太过坚持 DRY 原则(Don't Repeat Yourself),而且过于执着于只能有一个数据来源。(也许,只是也许,因为他们面对“事务性”工作总是要羞羞地跑开……)但如果认真考虑各自的本质,以及你想要解决的问题,你大概会意识到:两者的目的不同。我觉得:真实看板可以用来促进协作,鼓励面对面沟通,在团队中培养责任感。每天花几分钟复制一些句子,这占用不了多少成本。而且也完全没必要一字一句地复制,只需要有用的信息,支持不同工具各自的目的即可。也许你只需要在一种工具上维护概要工作项信息,另一种工具才维护详细工作项信息?

InfoQ:对于限制在制品、增加产出,你们能列出一些做法吗?如何使用在制品支持这样的目标?

Marcus:这是一个常见问题,因此,我们用了整整一章——第六章——讨论它。我觉得,最重要的是:在制品限制没有永远正确的数字。在制品限制只是一种工具,你能用它来改进工作流。在制品限制越低,工作流动越快,因此,限制数字越小越好。但是,这个数字越小,你的流程中问题浮现得就越快。这就是某种希望的信息:你会遇到困难!或者我们称为“尚未意识到的改进机会”。之所以这么说,是因为如果你解决它们,你的流程就会更快、更流畅。

接下来的问题就是,那你该做什么?

有些团队为整个看板设置了在制品限制,但是卡片可以位于板子上的任何位置。在制品限制越低,需要的协作就越多。5人团队的在制品限制可以设置为4,否则就会有人空闲。(当然不是说空闲就不好,有时候需要一些放松时间,这样才能有改进的余地。)

更常见的做法,是我们在流程中为一栏(或步骤)或多栏(步骤)设定在制品限制,这样就能保证不会导致某个步骤负担过重。也许是因为我们只有一个测试。为了确保工作流能稳定进入他的环节,我们为他设定了一个合适的在制品限制:3,也可能是2。当他所在那一栏工作量饱满之后,工作就会堆积,其他人就能得到明确信号:出现瓶颈情况。他们就会过来帮助他,而不是继续往可怜的测试人员身上堆积过多工作。

另一个常见做法,是限制一个人的头像只能出现在特定数目的卡片上,而且不能存在没有头像的卡片。这可以保证没人选取了太多工作。 Joakim: 总而言之,你必须学着停止开始太多任务,开始完成更多任务。这很简单,但也很复杂,因为这就意味着你必须要说不,不仅对其他人,也是对自己。当人遇到障碍或者必须等待其他人时,有新任务跳出来就马上选走,这种事情很容易发生。不如多花时间想想如何避免未来被阻碍,甚至现在就试着搬走自己的障碍。

InfoQ: “蜂巢方法(swarming)”可以用来移除障碍。能详细介绍下吗?

Marcus: “蜂巢方法(swarming)”源于(非)著名的“安灯拉绳(Andon cord)”装置,世界上很多精益工厂中都有。基本上,就是说如果你遇到阻碍进度的问题,你拉下灯绳,人们就会过来帮你清除障碍。

在绝大多数(其实就是所有的)软件开发团队中,我都没见过灯绳,而是遇到问题时,就找人来帮忙。没有灯绳,但是背后的理念是一样的。

本质上,我们十分重视阻碍我们流程的问题,我们会放下手中其他的一切,前来协助。这是很好的建议,因为受到阻碍的不仅是某个工作项,而是会造成一个瓶颈,导致流程中的工作堆积、停滞。要是仅仅傻傻地等,那就会创建更多在制品。

最后,如果你真心想要改进,所有这些阻碍事件都应该认真分析,事后还要反思,这样才能从中学习。为什么会发生这样的事情?我们如何防止再次发生?类似反思中,“五个为什么”是很好的工具。

InfoQ:你们的书中讲到看板中用到的多种估算技巧,能举几个吗?

Marcus: 我们在第九章中列出的技巧,都与相对估算相关。你可以将一个工作项需要的工作量与其他已完成的工作项比较。需要的工作量会给个名字或是数字,比如:S、M、L 或者1、2、3、5、8、13。

规划扑克最常见。这是一种依靠大众智慧的技术,你可以讨论某个工作项,然后每个人在心里估算,数到3,大家把自己的估算亮出来。如果我们意见一致,就可以进入下一个工作项。如果有差别,我们就会再深入讨论,直到全部达成一致。

我们用过的最快的估算技术,称为“一行卡片”。你把要估算的一个工作项放在桌子上,然后拿出另一个,问团队:“这个更大,还是更小?”如果更大,就把它放在上面,更小,就放在桌子上那张下面。你会继续估算这些工作项,每个都问同样的问题。过一会儿,就能得到一行按照估算大小排序的卡片。现在就可以为不同组的卡片分配大熊啊,对于整体上需要多少工作量,也就知道差不多了。

“中庸法(Goldilocks)” 很有趣,因为它跟估算反着来。我们会将工作划分成我们希望的大小。具体做法是:创立三堆——“太大”、“正好”、“太小”。然后团队为所有工作项投票,决定它们属于哪一堆。所有进入“太大”的,最后会切分成“正好”。所有进入“太小”的 ,最后会合并到“正好”中。

InfoQ:你们曾经说过:“使用看板后,过上一段时间就不需要规划了”。能够说明原因?

Marcus:我们很骄傲,因为这是第一本写到“不需要估算”的书。在估算那个章节中,这也没啥奇怪的。不需要估算,背后的理念是试图找到某种软件开发方法,其中不需要估算。举个例子,如果你的交付周期很短(我指导过的某些团队,最多只需要几天),业务人员就会认为没必要估算了。只要说“大概就是我们上周完成的报表功能那么多”,也就够了。

如果认真想想,会有哪个终端客户(不是业务需求人员或是项目经理,而是真正的终端客户)会打电话给公司,然后感谢你们的估算很准确吗?或者需求文档写得很棒?或者感谢你们所有的会议?

所有这些只是我们现在的工作流程。从客户角度来看,这些都是浪费(另外,如果它们不是浪费,那就有价值,要真这么想那就多做这些活动吧!),我们应该尽量扩大产出。也许可以少花些时间做估算?不妨试试看效果如何?

Joakim: 看板会驱动团队将工作项变小,而且大小趋于一致,这样它们才能在工作流中顺畅流动。看板社区中,大家都喜欢跟踪工作项交付周期,有些工具内置预测和模拟支撑,所以基于历史数据更容易得到出色的预测。

大型规划会议中,工作项会批量讨论,用持续的“准时制”讨论单个工作项取而代之,可以缩短规划时间。这种做法也使得计划的定制更容易,从而满足不同上下文和不同团队,规划活动也就没那么有破坏性了。

InfoQ:每种方法都有自己的问题或缺陷。那么看板呢?你们如何应对这些问题。

Marcus: 看板天衣无缝,完美无瑕!:)

真的,我们在一开始说了:看板是业务流程改进工具。其中只是一些很简单的原则。“缺陷”是:面对阻碍你改进的问题,你必须采取行动。下定决心改变当前的情形,很难,而且需要勇气和毅力。不是所有组织都愿意这么做。特别是当看板开始质疑最顽固的想法,或者是质疑“我们一直以来的工作方式”的时候。

无数次,我指导或是身处的团队开始停止反思,停止遵循在制品限制,甚至停止使用我们创建的可视化工具。这是因为一直处于改进状态需要努力工作。人们都需要足够好的理由才能这么做。 Joakim: 是的,有时候,看板似乎是团队的一条出路,因为他们不愿意花时间和经历去适应 Scrum 或是 XP 之类的方法。“咱们还是让即时贴都待在墙上,并称之为看板,然后就这样吧。”不结合其他优秀实践,看板会让你对于改进什么不知所措。所以,一定不要停止可视化,要确保执行在制品限制,也要了解其他方法和实践。这就是我们要在书中加入“看板进阶”部分的原因。

关于书籍作者

Marcus Hammarberg:让敏捷在实践中发挥作用,这是他的座右铭。一直以来,他也因此对下列东西感兴趣:精益、TDD、看板、实例化需求、Node、持续交付、NancyFx 和 Koa。现在,他已经离开软件开发领域一段时间,转而为印度尼西亚的慈善机构救世军工作,试图帮助他们的医院变得更加有效。

Joakim Sundén是 Spotify 的敏捷教练,这家公司致力于将音乐传播到全世界。他帮助人们改善工作,在个人、团队和组织层面进行指导和教练,常常使用敏捷和精益的思维和方法,包括看板、Scrum 和 XP。他组织并积极参与各种敏捷和精益的大会、社区和用户组。

查看英文原文:Q&A on Kanban in Action

评价本文

专业度
风格

您好,朋友!

您需要 注册一个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