上一节讲了如何通过提升研发成员的质量意识，提升开发阶段的质量水平，减少返工。其实，这也是最困难的阶段，因为我们要关注成员质量意识和能力两个方面，两手都要抓，非常耗费时间跟精力。

所以，一开始我会自己亲自带着团队做测试、重构级回顾、写自动化测试Demo、定规范和总结最佳实践等。幸好，我们的努力没有白费，产品在投入市场后迅速占领了市场，取得了非常好的市场业绩。同时，团队成员的能力也提升了，对于敏捷思想和价值观认可度也有较大的提高，迭代的整体执行也比较顺畅。但是，又有新的问题出现了。

12.3.1 推动更高级的能力培养

当我开始引入一些高级敏捷实践的指标时，比如测试覆盖率、燃尽图、累积流量图、缺陷循环时间、缺陷益出等，明显感觉到部分成员的抵触心理。有一次，我听见成员在嘀咕：“我们之前一直按传统瀑布式开发来的，也不见有多大的问题，现在这么多指标，我都不会做事了，之前多年的经验也用不上。”还有的人说：“以前我们按确定好的流程做产品多好。现在要做敏捷，无视了以前流程和规定，我不想继续这样改变了。”

我能理解，这也是正常的反应，每个人对敏捷的认知有多有少，有理解当然也会有误解的，况且一般人面对一个新的知识或者一个新的环境时会产生不安全感，又会缩回自己的“舒适圈”，甚至可能恢复最早期的状态。

我发现这种情况的时候，没有生气，也没有气馁。我迅速地把工作的重点放回到了团队内部，继续巩固敏捷的价值观，重申敏捷的四宣言及十二原则，带领大家一起重复学习和体会敏捷的三大支柱：透明、检视和适应，以及“勇气、承诺、尊重、专注、开放”五大价值观。结合我们进行敏捷转型以来的实际情况与转型之前的情况做对比，事实与理论相结合，让大家亲身感受到转型带来的好处。

同时，强调和澄清设立这些敏捷指标，是为了更好地帮助我们进行敏捷实践，更直观地了解我们迭代的工作情况，帮助我们更好地解决所碰到的问题，提高团队绩效，提高我们的生产力和敏捷力。这些指标是针对团队的，而不是说跟踪和面向个人的。

我继续引入一些更加深入的敏捷实践，比如在“团队即我，我即团队”的基础上引入代码共有。代码共有，其实就是“共享与进步”。同样是敏捷思想的体现，它意味着每个人写的代码都是属于团队的，并且每个人都可以修改任何代码。代码共有，可以增强团队对于代码的责任感。

一开始，成员们在代码这方面，常常会遇到修改困难、重构困难、甚至重复代码等情况，成员们也会私下吐槽，“技术债务又增加了，代码量实在太大了，让我编写代码越来越困难，代码质量也被破坏得惨不忍睹”。我鼓励代码共有，在这样的氛围下，团队每个人可以为项目的所有部分贡献新的想法，可以更改任意一行代码去增加新的功能、修复缺陷、改进设计或重构，没有人会成为变化的瓶颈。

在全员成为代码的负责人，代码共有制的环境里，成员互相监督，信息共享，没有上下级，没有权威。这样公平公开的环境，让我们回到最本质的工程师文化，使得团队有了自组织团队的影子。但这还远远不够，我们也是经历了组织干涉、工作散漫的困局，才慢慢建立起真正的自组织团队。

先来说说来自组织的干涉。公司要求产品组每个人每天都要写日报，详细描述当天的工作情况，遇到什么难题，具体是怎么解决的。

有一次，某个高层领导看到某个团队成员在某项具体内容没有按照他的想法进行，他就忍不住直接指挥团队成员该怎么做，直接进行干预。这与敏捷的“最好的架构、需求和设计出自自组织团队”这一原则明显违背，所以我们不能让这种情况出现，要委婉地让高层领导知道，“我们出于什么考虑选择了这样的解决方案，当然，你的方案也很好，但请先让我们试试自己的法子，实在撑不住了，我们一定会向您求教”。

因为自组织团队需要考虑团队的多样性、持久性和平衡性，不仅仅是针对成员的性格方面，还需要考虑他的专业和领域知识的深浅和掌握的多少。一开始，我就走了误区，认为自组织是成员随意组合就行，然后也放手让他们去干，结果整个团队都变得特别散漫。有的成员说：“这部分工作我做得很吃力，给某人做吧。”也有人觉得：“老大不会检查我的代码质量，随便弄弄就交差，应付得过去就行了。”这样下去肯定是不行的，我及时出手了，把个别不适合自组织的成员果断换掉，保证每个人都是专业、可靠的，愿意为同一个交付目标努力。

12.3.2 以教练指导为主

随着工作的开展，我又在自组织团队的基础上引入全团队一专多能。比如开发人员前后端都可以编码，这样解决了前端等后端、后端等前端的尴尬局面。鼓励团队里面的每一位成员在他擅长的领域不断提升精进，成为一名专家，同时在其他方面也能为团队提供支持的T形人才。在这个阶段，我也改变了对团队的指导风格，以指导为主，而不过多干涉团队成员。我对于团队的直接控制逐渐减少，更多是利用软技能去激发和鼓励团队成员自学。

这时候，可能成员们一开始不习惯，会问：“你怎么什么都不管了？这样放手，我们都不知道怎么做，我们很怕出错。”我们不能因为成员一时的迷茫就心软，什么都一手包办，要用言行让他们明白，因为大家都成长了，有足够的实力独当一面，大家一定要有自信，放心大胆地做。在必要时刻，我们可以拿出之前的数据佐证，“看看，我们现在产品的BUG是不是少很多？不需要经常返工了，这些都是大家的功劳，大家要相信自己的能力。当然，我们还要不断学习进步，有些问题今天解决不了，通过学习，明天就能解决”。同时，我也没有停止对敏捷和scrum的思想和价值观的输出，让成员持续学习。

其实，团队在这个时候已经变成一个较为成熟的自组织团队，已经有自我提升的意识，并且团队也逐渐建立起了自我改进的习惯。那么，为了进一步提升团队敏捷力，同样遵循“客户合作高于合同谈判” “业务人员和开发人员必须相互合作，项目中的每一天都不例外”等原则，我们团队还必须贴近业务。

12.3.3 贴近业务

什么是贴近业务？当然不是无条件服从业务部门，不然我们的辛苦就白费了。

而是从团队可以更好理解业务，同时给业务提供更有价值的建议的目的出发，可以尝试让相关业务在决策早期，就会引入研发团队的成员，让研发成员主动参与，讨论与技术相关的内容。在开发过程中，尽早邀请业务人员一起工作。一开始在实际接触中，开发人员看不惯业务人员的随意和感性，业务人员看不惯开发人员逻辑思维太严谨，不肯将就，爆发了几次冲突，使得两个部门的紧张关系又加剧了。这一度让我头痛，不知道怎么办。后面发现，其实就是双方的出发点不一致。开发人员从自己的工作量出发，业务人员从自己的提成角度出发，肯定会爆发不可调和的矛盾。

我们作为整个敏捷转型团队的领导者，既不能偏袒开发，也不能迎合业务。既然双方角度不一致，就调整一致。如果调整成从为客户创造价值的角度出发，从精益开发避免浪费的角度出发，就可以很好地解决这个问题。这样，研发团队也能少走弯路，做出客户想要的产品。随着工作的进行，迭代的继续，研发团队肉眼可见的能力变强了，研发部门也与业务部门建立起了信任与默契，为公司产出更好的产品，业绩也有了明显的提升。这个阶段的主要目标就是培养成员的自我提升意识，提升团队的自我改善能力，并帮助团队建立自我改进的习惯，形成自组织团队。

那么，如何达到目标，让缺乏安全感的团队成员放下传统开发模式，走出舒适圈，自我提升呢？主要有以下三方面。

（1）推动更高级的能力培养。团队进入这一阶段，说明已经具备了支撑快速变化业务的基本能力，可以推动更高级的能力建设，比如引入微服务、代码共享、全团队一专多能等。

（2）领导以教练指导为主。在这个阶段，我作为领导者，坚决贯彻“少微观管理，多宏观管理”的管理理念，学会放手，通过软技能来指导的内容会变多，让团队组织更多的分享，鼓励团队成员自学，并建立学习型文化。

（3）贴近业务。产品不能脱离业务，所以研发部门需要跟业务部门建立起密切联系、相互信任的关系，在业务决策早期就可以引入研发团队的成员，在开发的过程中，也应该尽早邀请业务人员一起工作。

不知道你有没有注意到，在整个团队敏捷转型道路上，我扮演的是一个仆人式领导的角色。一开始，成员身处恶劣工作环境中，我带着同理心鼓励、支持他们，也主动帮助他们解决难题，这让我们双方都建立了深厚的信任感，成员们也很服气我做的所有决定。

这里要提醒，如果你充当敏捷教练这种角色时，记住你一定是一名仆人式领导，这样才有利于团队转型，让团队变得高效。当我们团队走到这一步时，研发团队已经是一个成熟的自组织团队，有自我提升的意识，并且团队成员也愿意走出舒适圈，逐渐建立起自我改进的习惯，主动学习新技术、新知识。

你会看到，成员不会像以前一样从心里抵触敏捷、只愿待在舒适圈，而是遵循敏捷实践来做工作，实现全团队一专多能。另外，研发团队从要么无条件服从业务部门，要么敌视业务部门的态度转变过来，学会如何有分寸地贴近业务，能从研发角度出发更好理解业务，还能给业务提供更有价值的建议，两个部门建立起了信任与默契，为公司产出更好的产品，也更好地提升了业绩，也为客户创造出了更大的价值。

如果你读完前面三节，相信你也能感觉出来，团队的持续改进之路其实就是团队的敏捷转型之路。我讲的整个团队转型的过程，其实就是作为一名新领导空降到一个传统研发团队里，通过发挥自己的敏捷领导力，在不偏袒开发也没有迎合业务的基础上，不但给开发人员营造安全的工作环境，培养他们的敏捷价值观，而且在质量提升方面我也发挥了作用，减少迭代返工。

引导和教练团队中的人员自身综合能力逐步提升，思想随之改变。慢慢演变成团队所有人都能对什么是正确的事，如何正确地做事，做出更好的判断，继而走向持续改进的道路，建立起能自己做持续改进的自组织团队。

这就圆满落幕了吗？当然不是，没有人能告诉我们敏捷的终点在哪里。敏捷联盟及scrum联盟创始人之一迈克·科恩（Mike Cohn）曾经说过：“你不是变敏捷了，而是变得更敏捷了。”敏捷或Scrum没有任何终极状态，变得更精通Scrum或更敏捷是一个持续的、永无止境的过程，追求的是日益精进。“我们终于实现了敏捷” 这样的说法没有任何意义，所以我们团队的敏捷还是需要继续坚持。

虽然我讲述的案例中用的是敏捷的方法，而且也获得了很好的成效，但这并不代表我的敏捷实践是唯一的解决途径，或者说你的团队的敏捷转型就一定要照搬我的方式来。每一个组织所处的环境不同，开发的产品也千差万别。

变革之路注定充满荆棘。不要指望Scrum过程不会出现问题。我敢肯定地说，到某个时候肯定会出现阻碍敏捷顺利实施执行的障碍。面对内部障碍，我们要依靠我们的自组织团队，充分地信任他们能够自己解决问题。对于大多数组织而言，维持现状是一股强大的力量，为了抵制这种倾向，要坚定、耐心，在组织变革中充中坚力量。

要明白这种抵触很正常。给他们讲讲敏捷的价值观、基本原则和我们的想法，和他们共同工作，帮助他们走出困境。不要与他们对立，而是和他们一起扫除障碍，让团队、开发工作和组织从敏捷的实施中获取最大收益。

说了这么多，总结起来，其实我想表达的是：敏捷本身就是由价值观、思维方式和最佳实践组成的，但是这些本身并不能解决遇到的问题，解决问题的核心还是人，是一个贯彻敏捷价值观、用敏捷思想进行思考、充分贯彻敏捷最佳实践的自组织团队。

当我们使用敏捷时，不要担心事先是否能做到一次性到位。没有人做得到！绝大多数团队在前几个迭代都不会做得很好。这没有关系，我们只需要持续优化改进，建立起强有力的自组织团队，让Scrum团队在下一个冲刺都能比前一个冲刺做得好就行了。