专栏名称: InfoQ

有内容的技术社区媒体。

5个关键点教你如何成功地在亚洲植入敏捷和DevOps

InfoQ · 公众号 · 科技媒体 · 2016-11-09 07:59

正文

“

日本是敏捷宣言创始人之一的Alistair 所说世界上最难实行敏捷式文化的国家，本文作者给出了一个在日本植入敏捷/DevOps的典型过程。考虑到亚洲国家的某些共性，这个过程是可以通用的。

关键要点

首先要植入西方文化的要素。
使用价值流映射有助于打破文化障碍。
让上层管理者参与进来。
黑客节（Hackfest）将有助于减少前置期时间。
理解文化差异的影响。

我读过的一篇文章说Scrum并不适合于亚洲。作者所说的非常正确，但是这并非是不可能的。对于如何成功地在亚洲植入敏捷和DevOps，我愿意在此与大家分享一些我的小建议。

文章链接见：https://enterprisepathtoagility.com/scrum-does-not-work-here-in-asia-72d7bccccb4d#.a4pqddyhl

我是Tsuyoshi Ushio，具有15年的敏捷和DevOps实践者和教练经历。我已帮助很多日本和越南的公司植入敏捷和DevOps，其中有初创企业和成功发展的公司，涉及游戏、SI、服务和企业等领域。我目前工作于Microsoft，职位是DevOps技术布道师（Technical Evangelist）。以我个人的经验看来，在亚洲植入敏捷和DevOps是困难的。下表展示了原因。

图1：敏捷式工作中的国家文化阻力。

该表是由敏捷宣言的创始人之一Alistair Cockburn发布在Twitter上。推文中指出日本是最难以植入敏捷式文化的国家，其敏捷阻力指数异常的高。

但是在你理解了日本的文化底蕴及如何与日本文化共处之后，植入敏捷就不再是难事了。我在这里给出在一个在日本植入敏捷/DevOps的典型过程，该过程就很好地适应了日本的文化。

尽管日本是最难于植入敏捷的国家，但是考虑日本与其它的亚洲国家所具有共性，我认为该方法也会适用于其它的亚洲国家。

我使用了如下五个步骤在日本植入DevOps：

展示和演示；
价值流映射；
植入西方文化，为DevOps做好准备；
DevOps黑客节；
持续改进（日语：kaizen）和持续监管。

下面我将逐一解释这些步骤。

展示和演示

在我看来，西方人擅长于从理论和抽象概念中学习，而日本人常喜欢通过实例学习。这是学习方式的不同。如果你想在日本分享想法，首先你需要聚焦于实例。

因为敏捷和DevOps是具有模糊性的概念，不同的人对它们的内涵有着不同的理解。将对内涵的理解与项目的利益相关者进行分享，这是十分重点的。

这就是为什么我们需要以带有演示的展示为开始。演示很重要，因为它举例说明了真实案例。该方法很适合日本人。

价值流映射

图2：价值流映射

价值流映射是一种精益管理方法，用于做现状分析并设计未来状态，即交付产品或服务所需的一系列事件的状态。价值流映射有助于识别过程中的问题，并降低前置期时间。

它也适用于解决员工的问题。

图2给出了一个价值流的例子。图中展示了所有的过程步骤，从产生一个想法为开始，继而将该想法以各种方式发布到生产环境中。

每个处理步骤都有一个前置期和处理周期。通过对该图的绘制，你可轻易地识别出处理中的损耗所在，并找到用于实现改进和自动化的良机。

通常我的做法是，将所有的利益相关者召集在一起，开一个称为价值流映射的会议，会议应包括开发人员、操作人员、项目经理、以用户为中心的设计（UCD）等。应问及每个具有改变过程权限的人是否可以参会。

日本文化是分等级的，这所导致的不利因素是开发（Dev）和运营（Ops）并没有做过程改变的权力，因而高层管理者也应参与进来。

在管理者不在位的情况下，开发人员和运营人员是不敢去改变过程的，因为他们无权这么做。他们认为，不能自己去改变公司的规则和过程。但是如果有权力的人也加入进来，这项活动就会产生有益的变化。很多高层管理者具有积极改进的工作热情，但是需要将他们置于那些可以发现需要改进之处的位置上。

一旦体验到了这种成功，员工们就会明白改变过程和规则比他们之前的预计要容易。

价值流映射也激发了员工们做出改变的能力。一开始他们可能会具有由恐惧所引发的抵制情绪，但是在价值流映射会议后，员工们明白他们具有减少前置期时间的能力，并认识到自己可以做到。这是一个重要的认知。

可通过价值流映射估计前置期的时间，这有助于获取高层管理者的许可。如果你宣称“嗨，如果植入DevOps可以将前置期从八个月缩短为一个星期，那么我们可以去植入它吗？”，管理层怎么会反对呢？

植入西方文化，做好DevOps的准备

很多人可能已经发现Scrum和DevOps是源自于日本的，它们的最早来源是Toyota和Nonaka的一篇论文。

是的，这绝对正确。但是，是具有西方文化背景的人拿走了原始的材料，并发明了敏捷和DevOps。

图3 敏捷和DevOps是基于西方文化的

直接在日本文化中植入敏捷和DevOps会导致冲突，导致的原因包括：日本人所强调的按等级做事与自组织团队的理念相冲突；日本使用的评价系统未必适合于敏捷；存在学习方式上的差异，等等。

那么你应该怎么做呢？你可以在植入工作实践之前就植入西方文化。当然，你不必去改变整个文化，仅是改变那些将会带来改进和生产力提高的部分。

很多人认为自己的文化是不可改变的。我也曾这样认为，由此我尽量在日本文化和习俗中采用敏捷。但是这样的话我需要做很多的妥协，导致尽管我已经尽力，敏捷的作用依然有限。采用了如此改进的敏捷的团队并能不达到美国团队那样的生产力。

此前我只在日本企业工作过，直至我加入Microsoft的国际团队。我开始认识到西方人和日本人之间的差异，包括学习方式、心态、价值观等。我开始明白敏捷和DevOps是基于西方文化的。一旦我与团队成员探讨文化差异，他们就认识到了其中的差异并开始从中学习。这样与以前相比，敏捷和DevOps的植入会更加平缓，我们也可更加深入地应用敏捷。

现在我经常使用这个策略，它是非常有效的。但是在加入Microsoft之前，我从未注意到这些差异。

例如，日本人更愿意看重的是投入而非产出，因此对长时间工作的人评价很高。

这样，在短期内能产生出价值的人并不受欢迎。这也是为什么日本工人生产率低，为什么他们的工作时间是如此之长。对于下午五点完成工作并离开回家的员工，会被认为是懒惰的，甚至有时会被直接告知。

图4 日本的低生产率

此外，日本人想要将所有的事情做完美。这导致做事中缺失优先级（还有缺失确定优先级的能力）。我们想将所有的事情都做得出彩。

Led Zeppelin说过：“有时一个词会有两个方面的意思。”他是对的。

如果我看到一个朋友承压过大，我可能会说：“嗨，你需要确定积压的工作优先级，仅侧重于其中重要的事情。”

我的美国朋友将会找出最重要的事情，专注于其中，暂时忽视掉哪些不那么重要的事情。

而我的日本朋友将会从中找出最不重要的事情，虽将其标为超出范围的事情，但是仍然试图去解决它。如果他们能解决该问题，他们就会去做它。对于易做的小问题，他们就会立刻去做。我的日本朋友看重不休息地完成剩余的问题。他们没有优先级的概念，团队长时间地工作为的是努力去完成所有的事情。

图5 对比日本和美国所采用的方法

日本人的心态远非敏捷/精益思想。西方人注重如何用最少工作解决问题，这是两者文化的基本差异之一。由于此原因，完成相同的工作，在日本可能需要花费西方国家十倍的时间。统计显示日本工人的生产率仅是美国水平的62%。

如果让西方人去解释一个重要的概念，具有西方文化背景的人通常可轻易地理解，但是日本人即使理解了单词的意思，可能还是会误解该概念。两种文化中的人看待同一事务的方式常常不同。

一旦我们理解了两种文化中的实践差异并与相互分享，就可相互领会大家所要表达的实际意思。

但是日本人并没有认识到这种差异。在我向他们解释这个差异所在并给出能使他们更具有生产力的方法后，他们就会高兴地照葫芦画瓢去做。我称这种心态为“Be Lazy”，换句话说，就是试图用最小的努力做出最大的产出。我发现一旦日本人尝试了这种做事方法后，他们就会喜欢这个理念。我也解释了两种文化中其它的一些差异所在。

图6：“Be Lazy”心态

我的团队很高兴看到有这样的结果。一个例子是在数月的时间内，有的团队就成功地实现将交付周期从13天缩短到2天。

另一个值得注意的重要领域是为敏捷/DevOps做好准备。日本人非常善于“通过实例学习”，并且在尚未完全领会事情前就着手做事了。这与美国人完全不同，美国人喜欢先去理解所有的事情。

在没有看到任何实例前，日本人在理解概念上存在着困难。其中很多的人曲解了敏捷/DevOps的理念。产生曲解的人群比率严重超过了我在美国所见的。鉴于此，我建议对他们的敏捷工作进行观察并检查，为的是发现他们是否少做了什么事情。

对于日本人，重要的是应在他们继续做事前就确认DevOps、敏捷过程、心态、TDD/BDD、OOP等理念已经得到采用。如果未得到正确地认识其中的任何一件事情，就需要先去填补上这个空白。这个方法非常有效。记住，如果能给出一些实例，他们学得就会格外地快。

另一件应记住的事情是很多的日本软件公司使用了瀑布式工作流。如果想在企业中植入敏捷/DevOps，你需要找到那些已经具有敏捷开发经验的人。软件公司中的销售人员可能会说他们可以做到敏捷，但是不要根据表象去判断这些话语。你应该小心对待这些话，去发现他们是否真正地理解了敏捷心态和文化。

DevOps黑客节

黑客节是另外一个有效的DevOps技术。如果你经历了价值流映射，你很可能已经发现了很多的损耗和改进空间，已经知道了哪些过程需要做自动化。

图7：黑客节

如果你做到了这些，就可以继续去实现过程，并与专业人士一起将过程自动化。我会帮助客户实现DevOps，自动化客户构建和发布流水线，我同他们一起举行黑客马拉松（hackathon）。这不仅加速了过程自动化并缩短了前置期，而且也是一个好的技能转化方法。

持续改进（kaizen）和持续监管

改进是一种一次性的活动。一次黑客节并不能使所有的事情得到迅速的改变。还需要让人们持续追踪自己的输出。

不要去催促他们。重要的是具有可持续的开发节奏。让人们持续改进自身的节奏，让他们自己去思考。

这么说听上去很奇怪，这是因为日本有着遵行长者命令的习俗，一些日本人在一开始并不善于做自我思考。但是如果坚持授权他们并鼓励他们，他们就会开始思考和创新。

结论

这个过程可能看上去过于简化了，但是确实对我产生了好的结果。我相信如果遵循以上的方法，你就能在日本植入敏捷/DevOps，并实现如同在西方国家一样的工作。

亚洲人可能在一开始会具有不同的文化和心态，这将阻碍采用适合的敏捷/DevOps。一旦他们理解了西方人的心态，这种差异就变成了优点。例如，一旦日本人具有更高的生产力，他们就能变得更加具有创新性。在团队中，不同的思考问题方式引发了不同的观点。然而，除非你能通过生产力的提升更具竞争力，否则仍然不会成功。

此刻，我正致力于“文化植入”方法的进一步开发和优化，并与从事文化转变的专业人士Rochelle Kopp女士协作。

Kopp女士对日本文化和硅谷文化都非常地了解（她也是多本书的作者，其中包括了《The Rice-Paper Ceiling: Breaking Through Japanese Corporate Culture》、《* Valley Speak: Deciphering the Jargon of Silicon Valley*》，以及即将出版的《Creating Engaged Employees in Japan》一书）。我计划与Kopp女士及我的客户的共同继续改进本文中所阐述的方法。

我的一位美国朋友曾告诉我，日本人对敏捷/DevOps的采用落后美国八年。我有一个梦想，就是在开发软件和植入新理念上，有一天日本的人民将会具有与美国一样的速度。

关于作者

Tsuyoshi Ushio在Microsoft从事DevOps技术布道师工作。他是一位使用敏捷和DevOps的理念和技术做企业变革的专业人士。十多年来他一直致力于帮助各种规模的企业采用敏捷原则，其中具有从初创企业到大型企业。

目前他的工作兴趣在于能改变软件开发世界的DevOps。他是Agile 2011和Agile Roots 2014大会的演讲者，一名日本畅销书的作者。