华为敏捷转型实践

近年来，互联网大军中掀起一股“敏捷热”，各公司各研发团队纷纷效仿推行敏捷，然而，很多团队都是“形似敏捷而神非敏捷”。那么，

在敏捷推行的过程中有哪些“坑”？

组织级敏捷的困惑有哪些？

团队的敏捷该如何破冰？

个人技能又该如何提升？

从心理学的角度敏捷又有哪些值得思考的问题呢？

一、华为敏捷软件开发解读

2009年起，很多互联网公司都开始实施敏捷，而这些公司大多是先从工程师角度去实践敏捷，然后再慢慢往上说服老板在公司范围内推行，是一种自下而上的敏捷转型模式。华为正好相反，直接从高层发起变革，从上到下地推行敏捷。

这两种模式最大的差别是：

一方面，其他公司的工程师已经用敏捷的方法做出来一些好的效果了，他希望去劝说高层进一步的投入和支持转变；而华为，因为是从高层发起，所以先天条件很好，高层本身就很支持，投入也很充足，资源和人都不缺。

另一方面，大公司的高层和基层之间还有中层干部的阻隔，两者互相有些不信任，再加上不像其他公司的工程师已经知道敏捷能够带来好的效果，华为的基层工程师因为没有充分理解和感受到敏捷的好处，反而会有抵抗和排斥的心理。当然高层也知道这种情绪的存在，相应的会采取一些措施，然而，基层也会有一些相应的对策，所以在公司内部就出现了这样一种博弈的情况。

上图列出了一些组织级敏捷出现的典型困惑。

什么样的团队容易获得敏捷的好处？什么样的团队做敏捷没有效果？

在推行敏捷之前会考虑什么样的团队容易获得敏捷的好处，什么样的团队可能没有明显的效果，我们在现实中也会遇到这样的问题。华为也没有完全齐步走，各个研究所都有相应的自己的一套个性化的定制方案来推行敏捷。

开发测试坐在一起就是完整团队？

完整团队的话看起来不是很难，就是让相关分工的人员——开发测试UI性能设计都坐在一起。但是实际上仅仅是把他们放在一起的话，一般来说不是那么容易或者说不能够自发地产生相互帮助的情况。因为在体量比较大的公司里，这种部门的人员都非常多，部门墙的隔阂很深，想要破冰很难，即使是把开发和测试放在一起，他们一天也可能说不到几句话。

开迭代回顾会就能反思问题不断改进？

其实从管理层来说都是希望开迭代回归会的，这是一个很好的机会带领团队做反思、提出意见并修改。但是实际上大家会发现迭代回顾会很多情况下都是很沉闷的，即使主持会议的scrum master会积极引导大家，但是参与者依旧很沉默很被动，点到谁了开口说几句，能感觉到他并没有从内心里愿意去做这个反思，这是最大的一个问题。

引入高效的版本管理工具，持续集成总是容易的？

提到版本管理和持续集成，以前用的版本管理工具是ClearCase，这种工具比较适合大时间跨度的版本管理，功能强大全面，但是比较笨重。后来为了配合敏捷迭代的速度，版本管理工具换成了svm 、hg、git，这些工具更适合迭代。

如果从纯技术角度来看，这些工具更轻量效果更好，但是实际推行的话，研发人员对工具的变化很敏感，他会消极地抵抗。他表面上不会一开始说这个东西怎么怎么不好，但当他用了一段时间，因为刚开始用不熟悉而导致出现问题，这时他不会说自己不熟悉，而是不停地抱怨这个东西不好用，要换回原来的工具。包括持续集成也是一样的，我们拿到的都是华为自己团队已经做好了并且试点过了保证9成可用的东西，我们只要拿过来改一下就可以用了，很多还可以实现一键集成，但是他们也不太容易接受。

二、迭代中的瀑布，怎么破？

这也是一个真实的案例，大概去年的时候我们新拓展了一项业务，用Android做行业的手机应用，也就是Android软件的开发。这个团队在一年的时间内快速建成并扩充，一共6个小组，每个小组大概6-10人，总共四五十人的样子。因为最开始项目启动的时候就赶第一个版本，所以没有说用什么开发模式，不是瀑布开发也不算敏捷开发，只是先做出来一个东西。做出来第一个版本之后他们决定接下来采用敏捷的方式。

我之前一直都是在成熟的部门做敏捷教练，做了三四年了，现在因为他们突然要做敏捷，我就被调过来辅导这个团队，面对这6个组、人手还比较单薄的情况。

这个团队大部分的员工是一年之内新招进来的，他们基本上对公司过去的开发模式和文化不是太了解，而骨干大多是从原来成熟的部门转过来的，一般还是倾向于传统的一代一代的瀑布开发的思路。所以这个团队最大的问题是：内在的思路是瀑布的，但是他外在要去套迭代的形式。这个情况就比较严峻，他其实两头都不靠，这样的话不仅无法获得敏捷的好处，反而有些地方会变得低效。

原来传统部门做敏捷的时候会有配套的敏捷行动，比如宣传，或者开设全体的敏捷培训班，每一期培训班学员会有三天的比较充分的敏捷相关培训。而这个部门直接开始做项目了，没有时间做这些事情，因此团队人员缺乏对敏捷的了解，也没有实行敏捷的基本准备，他们还是抱着自己固有的思维习惯。

这6个团队在敏捷过程中遇到的问题我都列了出来，当然这些问题不是所有团队都有，大家可以对照自己的团队看有没有碰到过类似的问题。

我觉得有两个原因导致这样的结果。

缺乏敏捷经验的scrum master通常寄希望于理想化的计划和管理模式。我们一般是以4个星期也就是1个月为一个迭代周期，他会自己把这个迭代周期划分为多少天设计、多少天编码、多少天测试等，这是很理想化的计划，也很像一个小瀑布，只是把时间缩短到一个月，这实际上和敏捷的心法是相矛盾的。

过去我们大概6-9个月才发布一个对外的版本，而现在每个月就要发一个版本，这不仅仅是把原来的计划压缩到一个月就工作量少一点，因为一旦进入这种高速迭代的模式之后，很多状况会频发。并不像想象的那样仅仅是把它切割成一个小段儿这么简单的一个改变，实际上当开始高速开发和迭代之后就会出现一些原来低速开发的情况下根本不会出现的问题。他们的内心或管理经验上都没有准备，他根本就没有想到有这些问题。这是第一个原因。

另外一个原因是体量大的公司为了便于管理和降低管理成本，倾向于把研发人员、测试人员看做孤立的人力资源，就是他认为每个开发人员、测试人员都是可以换的。所以在管理的时候倾向于把人都看成可以通用的资源去管理，每个人都是孤立的被安排任务，缺乏一些群策群力的机制，这样会放任技术壁垒的加深，每个人对自己所做的模块越来越熟悉，而对别人所做的模块越来越陌生。但其实这样的情况在敏捷的迭代方式下不太好。

因为迭代的速度很快，所以一旦出现困难，就需要把能调动的人员都集合起来互相帮助才能度过难关。过去9个月才出一个版本，有足够的时间可以去向外界求助，现在没有时间去找外援，很多scrum master就没有想到有这么大的一个变化。

我要面对的是6个团队、四五十个人，这些人对于敏捷的理解都不是很深入，所以我不能铺太大的摊子，我采取的办法是直接抓团队的leader，着重去纠正他们，并着力于能够影响到整个团队的管理措施及实务，比如需求澄清、任务划分、任务的清单完成标准、优先级的定义、任务调整等，我是想通过杠杆作用，就是通过组长来撬动整个大的团队。

敏捷能够实现快速开发和交付，但这并不是简单地遵循一下敏捷的外在形式就能够实现的。在相比之前快得多的开发节奏下，需要管理能力、特别是基层管理能力的支撑。这是敏捷能够取得收益的必要代价。

在快速扩张的团队中，基层管理者基本来自于原先的技术骨干，从技术思维方式向管理思维方式的转变，跨度很大，简单的培训并不能产生转变思维方式的效果，往往需要手把手的辅导，以养成新的思维习惯。

为什么讲到心理学上去呢？我原来也是搞技术的，编程编了好长时间，自己是程序员的时候不觉得，但是做管理特别是当上敏捷教练之后，发现程序员有一些自己的思维习惯，而这些习惯跟普通人有所区别。

另外一点就是敏捷的个人性的实践，比如测试驱动开发、结对编程，涉及到的不仅仅是技术的东西，还跟思维有很大关系，包括如何去思考、如何去写代码。所以我看了很多这些这方面的书，并在敏捷过程中去实践获得这些心得。

我们常规的推广敏捷的做法有几种：培训讲解敏捷的基本知识和原理、参考业界或公司内部的优秀实践优秀案例、制定指导书及流程要求等，这些能框住大的东西，但是培训只能告诉你知识原理，涉及到个人或具体到编程的技术实践是技能的问题，技能是没办法通过培训来传达的。

我这里还是要强调一下：技能是没办法通过培训来传达的。比如游泳，你再怎么跟他讲知识原理或者给他书看都是没有用的，必须有一个会游泳的人带着他下水，先讲讲要求，做做示范，然后直接在游的过程中去纠正动作，这样才能真正教会游泳。

敏捷的编程或测试驱动开发也是这样的，光靠讲课没用，我也试过很多次，一个课你讲的很好，学员表示都听懂了，你让他写他还是不会，还是觉得跟原来一模一样，他感受不到区别。后来干脆我作为教练直接带他们去练习，这样的效果就很好，至少能触动他，让他感受到有一种新的方式去写代码。

敏捷还有一个比较重要的实践，重构。不要认为重构就是直接让程序员重新写一遍代码，也不要认为重新写一遍代码他就一定能写好。他重新写一遍也许会比第一遍要好，但是他也不一定能有突破或者说大的改观，这也涉及到他的思维模式。

最初第一遍他写得匆忙一点，有的地方不太规范，重构的时候写第二遍，也只能在细节方面更规范一些。而如果没有跳出之前的思维盲区，那么第二遍的重构，整体的设计依然不会有大的改观，最终也还是不能真正解决系统的架构问题。

关于代码重构三个常见的问题。

代码功能都是正确的，结构却复杂混乱

第一个问题很常见，我们公司的代码从交付之后的表现来看质量是过关的，因为我们测试的环节很多，测试人员也很多，所以功能对了即使写的有问题最终改也能改对了。其实我刚开始没有看过别人写的代码的时候，就很难想象这个问题。我写代码的时候要是写乱了就很难保证它正确，相反只要结构写清楚了功能就自然很正确，很少有bug。所以我看到别人的代码的时候就很惊讶，他的功能都是对的，但是结构很乱，我都不知道他是怎么做到的。

后来我去看了一下心理学的书籍之后恍然大悟，原来是这个原因。建议大家可以看看《认知心理学》这本书，书中提到每个人都有自己的大脑思维模式，程序员也会“偏科”，他们比较惯常使用而且比较强的是逻辑推理能力，逻辑推理能力能够保证功能正确，而代码结构的整齐需要的是抽象和规划能力。这个问题的解决办法是引导其他思维模式的扩展，我会鼓励我团队的程序员多看不同的书籍，开发大脑思维模式，并跳出原来的固有模式。

为什么设计的复杂度，往往超过脑力掌控的范围？

在重构中还有个问题就是设计，因为现在流行的是简单设计，我们也希望能够简单设计，但是在实际做设计的时候会发现很难，不是说你想简单它就能简单的。很多时候会发现这个设计的复杂度远远超过我们能控制的范围，这个时候系统就可能会出问题，架构也可能会出问题。

为什么好的设计，很难向他人表述？

还有一点就是你作为架构师做出来一个好的设计，但是你怎么能够把这个好的设计传递到整个团队去。很多情况下架构师做好了之后其他人过来一改又改乱了，开始你跟他讲的时候他好像听懂了，但是实际上他做的时候又跟你想的不一样。这也是一个问题。

刚才的三个问题都是跟重构和设计有关的，这张图列出了结对编程时的一些常见现象，一些不太好的低效的现象。

一个人编码，一个人沉默观看

两个人的思维节拍不同步，甚至互相打断

两人的方案经常产生分歧

一些高水平的程序员不愿结对

对开发者要求太高

我不知道你们有没有遇到过这样的情况：做结对编程，最开始我们这边经理层都是比较开放的，至少他们愿意推动他们的团员去做尝试，但是尝试之后整体的效果不是太好。我在公司大概跟四五十个人结过对，作为教练一对一地跟他们结对编程，使用的代码有c++ 、java等，他们的感悟都很好，也会把个人心得发表到内部刊物上，作为案例。编程是一种技能，很难通过讲解来讲明白，让他们自发地两个人去实验的效果也不好，这些东西就需要手把手去带。

敏捷是看起来容易，做起来并不容易的实践。它并不仅仅是表面大家能看到的那些形式，在这些形式下，有很多心理学的原理。它的一些实践看起来不是那么严谨，但这反而是它针对人的思维特点所作出的调整。推广敏捷的过程中，需要更多地去了解人，了解人的思维模式。

这是第三个案例的总结。

本文来自微信公众号“壹佰案例 ”（ID：Top100Case），作者 程鹏：十二年开发领域经验，五年架构设计经验，2009年起，做为公司敏捷推行组核心成员推行敏捷。公司内部敏捷培训主讲师，多个版本的敏捷教练，参与多次架构级重构，指导大量模块级重构项目。

管理圈经授权转载，如需转载请联系原作者。