看板先驱:David J. Anderson采访实录

David J. Anderson是将看板应用于软件开发的先驱,他最近来到了巴西。InfoQ巴西对David进行了一次关于“精益、敏捷与看板”的采访,下面是采访中的精彩对话。

InfoQ 巴西站(以下简称infoQ):您是怎样将“精益”与“敏捷”这两种思想联系起来的?

David: 显然,这两种思想有很多相似之处。而区别在于,“精益”这种思想实际上体现了一种追求完美的理念,而“敏捷”则意味着在信息不完善的情况下取得进展,并且 在获知更多事实后对原有的问题进行修正。许多持有“精益”观念的人会执着于完美,纠结于是否应该在信息不完全的情况下向前推进。在他们的观念里,返工即浪 费。而“敏捷”则并不追求完美,这是“精益”与“敏捷”间的一个关键区别。

我认为还有另一个区别,就是在这两种思想中,对“人”的定位不同。“精益”是从体系的角度来看的,其认为,人所在的体系会在很大程度上影响一个人的 表现;所以如果要体现对人的尊重,就要设计一个合理的体系,使得人能够高效地工作。而“敏捷”则更加以人为本,尊重“人”作为一个个体存在。“敏捷”具有 无政府主义(自由意志)论者的观点,其相信人可以通过自我管理做正确的事情。所以对于“人”,“精益”和“敏捷”这两种思想的看法区别很大。

政治因素对于“敏捷”社区——尤其是美国的“敏捷”社区——是有一些影响的,其中有些人非常地以人为本,是自由意志论者和无政府主义者。有种观念在 “敏捷”社区中很流行,他们认为既然人性本善,那么就应当允许人们做自己想做的事情,而且我们应当相信他们。就个人而言,我认为这个想法实在有些一厢情 愿。

从历史上看,纯粹的共产主义对“敏捷”社区有一定的影响。他们会认为,所有的管理者都是恶的,所有控制他人的企图都是恶的,所有对他人进行决断的企 图都是恶的。我并不认为这种看法是正确的,而且我觉得持有“精益”观点的人也不这么看。“精益”认为应当对体系进行建设,其中一些人负责构建体系,另一些 人负责管理体系,“改善文化(Kaizen Culture)”并不具备自我管理性。所以“敏捷”和“精益”对于个人和组织的看法存在很大不同。

如果有人想的是按部就班地工作,领取薪水,然后回家干自己的事情,为家庭操心,这对我来说完全没问题——一个人的热情不在工作上并不是什么要紧的事 情。我相信很多持有“敏捷”观点的人认为,团队中的每一个人都应当对其职业抱有极大的热情。我觉得在比较大的一些公司里这种想法很不现实,而且也没法大规 模地在实践中进行操作。在仅有6个人的创业公司里,依靠个人对事业的深厚感情是可能的,但对一个300人的大公司则很不现实。

InfoQ:那对团队进行授权呢,是否和您刚才说的相违背?

David: 授权并不是让人为所欲为,也不是假定人就是能够通过自我管理把事情做对。授权是划定事情的边界,就像我们教育小孩时给 他们做规矩。我们会告诉小孩子一些规定,比如他们应该在几点上床睡觉,他们可以在哪里玩,他们是否可以跑出院子,他们只能在游泳池的浅水区游泳,他们不能 使用跳水板……等等,诸如此类。所以授权是清晰地告诉人们事情的边界在哪里,然后让他们在边界内发挥主观能动性。

InfoQ:您最近又给看板添加了一项核心实践,即“实施有组织的反馈”,您为什么觉得要增加这一项呢?

David: 其实这一项并不是我加的,我只是使它更突出了。在我的《看板:技术企业的成功变革》这 本书中,有一整章是关于这个话题的,我只是没有把它列为一项核心实践而已。但我意识到这是一个错误,因为我们发现组织层面的反馈通路在实践中并没有充分应 用。有时候,如果一项实践没有得到贯彻,那就需要把它变得更显眼,而把它加入到核心实践列表中就是这个目的。所以这并不是什么新东西,我只是加以强调而 已。

InfoQ:您说看板是根据生产能力来调整需求的一种形式。您能跟我们谈谈这样做的好处吗?我们应当如何让业务人员相信其重要性呢?

David: 我们要同时针对生产能力和我们的能力来调整需求。而且很显然,我们应当避免使自己负担过重。如果我们的负担过重,那么 我们的生产力会下降,产品的品质会降低,而且通常花的时间也会更多。而通过建立平衡,我们可以提升生产能力,加快速度。我们可以做更多的事情,而且质量也 会变得更好。

对于业务人员来说,他们必须明白什么叫根据能力来控制需求。也就是说,我们必须根据产能来配给需求,因为总会有超出我们能力的需求存在。人类的创造力是无限的。人们会想出各种各样的新软件,最重要的是要正确评估其中的风险、回报和收益。

所以帮助企业对其想法进行分析,并帮其厘清其中的风险和收益是很有价值的。而且要根据我们的实际能力,帮助他们选择出能达到供需平衡的最佳方案。 我们会努力提高产能,但同时他们也要学会怎样从很多想法中选择出最棒的那一个。

如果我们可以同时做到这两件事:一是提升我们的能力,二是对需求进行控制/改善需求中的风险管理,那么一切就会更为和谐。我们之所以会发现需求越来 越多,原因之一是因为未来具有不确定性,而业务人员为了规避这种不确定性,会说“干脆把什么都做了吧”。显然这并不实际,所以我们需要帮助他们更好地评估 风险,帮助他们理解所面对的不确定性。这样他们就能够对自己做出的选择更有信心。

InfoQ:现在有对看板的误会和误解吗?如果有的话,哪种误会或者误解是最常见的,或者是最严重的呢?

David:Alan Shallaway就“关于看板的误解”这一问题发表了一篇文章,这是一个很好的参考。我认为现实中 误解很多,其中一个是关于“板(board)”的。其实 Agile Alliance中 已经有了一个页面,讨论的就是在看板中使用板作为敏捷实践。看板方法并不是因为有块板而得名,它叫看板是因为它采用了一种虚拟的看板系统。这种拉动式的系 统(pull system)在过程中对工作量进行限制,然后把工作提交推迟到精益开发人员所说的“最后责任时刻(Last Responsible Moment)”,板只是将这个过程可视化的一个工具。

看板系统是最先出现的,“板”是随后加入的。“板”起先叫做“卡片墙(card walls)”,在敏捷社区中十分普遍。“板”并不是什么新的东西,也没有什么创新,使用虚拟的看板系统才是具有创新性的。

还有其他很多不断重复的误解,其中一个就是看板只能用于运维和IT运营(IT operations),不能在大项目中使用,这显然是错误的。在2007年,我们做了一个1100万美金的项目,团队有50多个成员,这个项目就使用了看板。

所以很久以前,我们就开始在大项目中使用看板了。你也可以使用看板来帮助你提高预见能力,提升项目中的风险管理。预见性和风险管理在项目管理与治理中显然十分重要,能让你确保项目交付的时间。

遗憾的是,认为看板只能用于运维或者IT运营,而不能用在大项目的管理中,这种误解十分普遍而且经常出现。即使在敏捷社区中,这种误解也时常发生。

InfoQ:看板会把我们带回到瀑布式开发,这种误解是怎么回事呢?现在还有这种误解吗?

David:这种误解在2007年到2009年间曾十分常见,但是现在不太能听到了。这主要是因为早期看板的例子都是一些使用传统的 软件开发生命周期方法,或者是其他非敏捷方法(例如“个体软件过程(Personal Software Process)”或者“团队软件过程(Team Software Process)”)的团队做的。所以看板早期的例子都不是敏捷的。

我引入看板就是为了对那些拒绝敏捷的团队进行改进,所以早期的看板都应用在非敏捷的项目里,这也是很自然的。 但是,现在使用看板已经非常普遍了,大约在超过50%的项目中大家会把看板加到Scrum之上,所以我认为这种误解现在很大程度上不存在了。

InfoQ:您最近提出要考虑增加一项实践“允许有想法并鼓励创新”,为什么您过去没有这样的想法呢?您是否看到了增加一个“看板负责人(Kanban Master)”的必要性?

David: 实际上,我加入这个实践的初衷是因为要鼓励领导力,然后让人们知道在看板的原则中领导力和管理是不同的。管理者对系统 的设计负责,还对所有的策略以及改变或者是重新制定策略的决定负责,这没什么问题。但是我们想让参与工作的每个人——不管是独立工作者,还是管理者——都 作出具有领导力的行动。

具有领导力的行为是指,既然并非所有的事情都很完美,所以可以对其提出改进意见,或者让大家看到其实我们可以做的更好。如果你不具备领导能力,那么 你就没有持续进步的动力。大家都可以耸耸肩说:“哦,反正就是这样了,回去干活吧!”这样永远都不会有进步,所以领导力是一种很神奇的东西,它是一种催化 剂。

最近有个类似的例子,Håkan Forss是来自瑞典的看板顾问,他最近读了 Mike Rother的一本书 《丰田套路(Toyota Kata)》。这本书促使他提出了看板的三个关键性做法,即“看板的三个套路”。

一是每日立会,促进对项目进行改善。二是对业务操作回顾,促进对内部工作流程和看板系统的改进。三是上下级关系,即更高级别的管理者对其下级管理者 进行指导:“我们的系统运行的怎么样?”,“我们的策略正确吗?”,“我们收集的指标正确吗?”,“我们可视化的东西正确吗?”。这样我们就能理解我们周 遭的环境,并对其作出改善。

InfoQ:社区现在是不是已经习惯了“看板负责人”?

David: 不是这个意思,我们不鼓励“看板负责人”(直接对等于Scrum负责人)这个想法。但我觉得找一个看板教练是有价值的。看板教练通常不同于敏捷教练。敏捷教练往往是团队的一员,每天与团队在一起工作。

而看板教练往往一个月只过来两到三天,与大家讨论策略、可视化和指标,帮助大家理解他们现有的产能并考虑如何进行提高。所以看板教练并不需要每天都在团队里。

InfoQInfoQ最近发表了一篇题为“看板,敏捷的下一步”的文章,你觉得这篇文章怎么样?

David: 如果他们是在讨论看板的的市场前景的话,我觉得看板确实正在成为软件过程市场中的下一个明星。有很多证据表明,我们确 实需要看板方面的培训、辅导、咨询,以及看板软件、模拟和游戏——各种诸如此类的东西。所以我觉得从市场角度看的话,看板正在发展成为下一个热点。如果从 历史角度来看,从CMMI,然后到RUP,到XP,再到Scrum,那么看板就是下一个。

但如果他们指的是必须先进行Scrum,然后再使用看板,那么这就完全错了。对于很多组织来说,Scrum并不容易应用,它与许多公司的文化都有所冲突,导致人们对其十分抵触。

而另一方面,看板是为易于使用设计的。它以你正在做的东西为出发点,它是Scrum之外的一个选择。如果我们等着人们克服对Scrum的抵触心理, 那么他们就会丧失一个重要的机会,即如果他们早点使用看板,那改进就会快得多。如果已经在使用Scrum,但是觉得有必要作出进一步改善,那么在后期加入 看板也是个好主意。如果尚未使用Scrum,那么就应当考虑使用看板,随时都可以。

InfoQ:在Jurgen Appelo的书《管理3.0》中,他提到了“文化基因(memeplex)”。他认为Scrum之所以如此成功,得到如此广泛的接受,一个原因是现在Scrum已经完全改变了“文化基因”,您怎么看这件事?

David: 我不想就这一点进行争论,但我觉得真正挑战在于是否真的能够将原有的“文化基因”完全抹去,然后用全新的一套去替代? 尽管Scrum已经非常成功了,但现在对它还是有很多的抵触。在采用Scrum时有许多备受质疑甚至失败的例子。最近一个比较可靠的市场调查显 示,Scrum的市场占有率大约在15%,这比RUP的市场占有率要高,RUP获得过的最高市场占有率是11%。所以15%已经很不错了,因而你应当问的 是,在15%之中有多少Scrum的实现是有问题的?

但是先让我们大胆地假设,这15%之内的所有Scrum都很成功,那么仍然有85%的市场呢。这正是我想要解决的问题。怎么才能做的更好,怎么才能 帮助这些已经在使用敏捷的人把Scrum做得更好,并且尝试开拓和帮助剩下的85%的人?我觉得Jurgen说的大部分关于Scrum的事情都很对,也很 准确。但是,在世界上还有很多更为有趣的问题亟待解决,在管理学和软件过程领域也是如此,而我更感兴趣的是剩下的空间。我相信在Scrum社区中有很多人 都有兴趣改进Scrum。

关于受访人:

David J. Anderson在高科技行业拥有30年经验,并曾在诸如Sprint、Motorola和Microsoft这样的大公司使用创新的敏捷方法带领软件开发团队,使得团队拥有卓越的生产力和产品质量。David是三本书的作者,包括《软件工程的敏捷管理》,《看板——技术企业的成功变革》以及《敏捷管理课程:通往“看板”之路》。

译者注:memeplex: 即“模因复合体”,也有直接音译作“谜迷复合体”,本文中意译为“文化基因”。memeplex是基于达尔文进化论观点解释文化进化规律的一种新理论。它 认为,在文化领域内存在着一种类似DNA的文化复制因子——模因(meme),模因通过人与人之间的相互模仿得以复制和传递,从而推动着人类文化的进化。

查看英文原文:Kanban Pioneer: Interview with David J. Anderson


感谢臧秀涛对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

This entry was posted in Agile, Best Practices. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s