阿里敏捷教练是如何帮助团队实施敏捷的——专访阿里敏捷教练张燎原

他是如何看待敏捷、如何帮助团队落地敏捷的，作为研发团队的一员，我们可以从哪些地方着手敏捷，以下是对他的采访。

阿里巴巴敏捷教练张燎原

嘉宾简介：张燎原，阿里巴巴高级技术专家，他是敏捷和精益方法的积极实践者和推动者，具有十多年软件研发一线实践经验，经历过消费电子、通信及互联网多个行业，长期从事研发管理、研发教练及组织转型工作，曾负责Nokia全球大规模敏捷导入实施和转型辅导，成功帮助淘宝、闲鱼、阿里云等事业部引入精益产品交付和创新方法，帮助实现DevOps转型。译有《程序员度量》、《软件驱魔》等。同时，他热衷编写代码和开源，涉及软件设计、测试驱动开发、代码重构、遗留代码的维护和持续集成及交付。工作之余，他还擅长画画和摄影，被同事戏称“最会画画的敏捷教练”。

张燎原：以前，敏捷作为一个很时髦的概念，大家总是反复在提，就像现在的DevOps一样。在我看来，不论是敏捷、精益还是DevOps，能不能解决问题， 这个才是最重要的，一切不以解决实际问题的概念炒作都是耍流氓。去年我和何勉老师（阿里巴巴敏捷教练团队负责人）在一起讨论， 我们是在做敏捷、精益的转型还是其他的什么，后来我们决定提升研发效能。作为一个研发团队，能够持续快速高质量地交付有用的价值，才是我们觉得作为一个研发团队要追求的。

提升研发效能，主要分两点来看，第一个是回答如何持续快速高质量的交付的问题。在交付团队里，大家协作特别好，写的代码要没有太大的问题——高质量，发布特别快。所以，我们知道的比如看板、Scrum是解决我们协作的问题；测试自动化、CI/CD以及DevOps是为了帮助高质量的发布；我们提倡的DDD、Clean Code，是为了让我们的代码能够更健壮、质量更好、更Clean，大家在协作的时候，能够通过代码来交流，这些都是提升交付能力的手段和实践。

另外一点是，就要回答什么是有用的价值这个问题。对很多工程师来说，大家可能更关心代码写的好不好，从产品那拿到的需求，大家基本都认为是对的。很多时候产品提了一个需求，一个工程师可能要做一天甚至是一个礼拜才能完成这个需求。但是，如果这个需求没有价值，那就相当于白干了。所以这个时候，我们要走到源头去看一看，这个需求是否是有用的，对我们的业务有没有帮助，是否值得我们投入。

所以你问我如何看待敏捷，我不会说是要快速响应变化，因为我觉得这样还是有点抽象。回到研发的本质，我们是要持续快速高质量地交付有用价值，从解决阻碍我们达成这一目标的问题出发，选择相应的方法和实践，最终解决掉这些问题，这才是实实在在、对我们有帮助的。

张燎原： 我觉得首先是让大家看得见，对问题形成一致的理解。当我们开始在团队落敏捷时，大家会说我没有问题，所以首先我们要让大家看得见问题，在问题上达成共识。这样，目标才会一致，做事才能齐心。

其次，大家在解决方案上要达成共识。有的时候，针对一个问题，可能有A解法，也可能有B解法，但我们要一起探讨是用A还是用B。例如，B可能见效快，但不持久；A见效慢，但是持久。这个时候，我们得去找一个折中的解决方案。

再次，要有一条明确清晰的改进路径。解决方案要能解决问题，但同时也要给大家改进的信心。每个阶段都能解决一些问题，通过持续地发现和改进问题牵引着大家往前走。这种改进不应该都是烟斗式的，即开始会导致效率先降下来，然后才会慢慢持续往上爬。

最后，有节奏地给出有效反馈。通过在合作过程中，通过数据也好，或者观察到的问题也好，持续地给团队反馈，让大家明白自己是在正确的路上行走的。

这几点对我们来说都是比较大的挑战，但比较好的是，我们现在能驾轻就熟来应对。还有一点，大部分时间，我们是站在全局的视角来看问题，这和具体的职能团队是有差别的，他们更多是站在自己的职能的角度。大家看问题的视角不一样，在沟通的时候，也就需要更有同理心。

张燎原：在实施转型或提效的时候，需要持续地给大家信心。我们不太建议一股脑地给一个完整的解决方案，把之前的全部推翻掉，就按照新的来。因为我们接触的团队，基本上都是工作在现有的业务上的，哪怕是创新型的一些团队，大家之前也一起磨合了很长的时间，大家都有自己熟悉的工作方式和习惯。

我们团队之前有一个案例：《4个迭代，从批量交付到持续交付转型》，就非常典型，每做一个迭代都是让大家看到收益，然后才有信心做第二个迭代。例如，当时的第一个迭代是把所有的职能端到端的拉齐，让大家看到整体。这个时候就减少了各个职能之间的交流误会，整个沟通就顺畅了。然后在整个可视化的协作流程中，大家就会发现：喔，原来需求有这么多反复、原来需求太大了，甚至需求都没搞清楚就开始了。其实很多时候，这些都是大家自己发现的。当解决了协作的问题，大家有了信心，就开始着手解决需求的问题。当需求澄清的问题解决后，又会发现发布速度是不是可以更快一点，原来一个月发一次，现在是不是可以每个礼拜都能发。这样每一个迭代都会有一些点得到了改进，并且也能够持续暴露其他的一些问题，能够让大家朝比较理想的状态前进。

如果你告诉大家落一个解决方案需要半年的时间说半年之后才能看到结果，你做了一个月没结果，大家能接受，第二个月没结果，大家可以坚持，如果第三个月还是如此，可能就没有然后了......这是我们在制定解决方案的时候需要特别考虑的。

张燎原：从目前在阿里接触的一些团队来说，一个月内，基本上就能够看到一些明显的效果了。当然这跟我们合作的团队也有很大的关系，大家彼此都挺配合的，甚至有的时候他们比我们还专业，他们会说，燎原老师，你看这种方式是不是会更好。然后我发现他给出来的点可能是我都没想到的，所以在这个过程中，我们也是在相互学习。

当然，改进是一个持续的过程，目标越大，要投入的时间可能就会越长。

张燎原：一般情况下，在辅导开始的时候，我们都会有特别明确的目标，我们会清晰地把需要改进的问题定义出来，让大家看得见，找出根因，而不仅仅是现象。随着问题逐渐被解决，后面我们会有意识的慢慢抽身出来，看没有我们的时候，是不是也能够work起来，如果我们发现没有我们也行，这个时间也就到了。

在这个过程中，很重要一点，我们要善于发现和培养有潜力的同学，在被辅导团队留下种子，这些同学会是团队持续改进的生力军。

张燎原：我觉得能做IT的人都是聪明人，如果他没有发现这个问题，更多的是因为他没有这个意识，没有意识到自己要去看有没有问题。所以我们会通过其他的一些渠道，让大家去意识到这件事。老实说，大家不缺方法，缺的是意识，我们希望能够让大家意识到这件事情的重要性，如果我们没有一个很好的研发能力去支撑业务效能的话，我们也很难把业务效能做好。虽然很多时候我们只觉得业务效能很好很重要，我承认确实很重要，但研发效能是基础。如果你有一个很好的点子，但是没有很好的这种研发团队，没有研发方式来支撑。你的点子，也实现不了。

张燎原：确实，让我们去辅导一个团队，肯定没有问题，但是如果让我们同时去辅导很多的团队，精力肯定就忙不过来，一个人一天就24个小时。这个时候我们会有一些策略，例如，就像前面所述，我们会培养业务团队的一些同事，让他们成为这方面的专家，就像一颗种子，他也会发展壮大，然后他自己做的一些事情，对他所在组织都会有很大的帮助，这是一种杠杆撬动的力量。另外，我们还会通过其他的一些手段，例如线上、线下的培训课程、最佳实践文章、案例分享，以及鼓励更多同事把他们一些好的点子share出来。我相信这样一个一个的点，都能够帮助规模化。

还有另外一个很重要一点，我们所在的研发效能团队，通过各个业务部门的实践，对实践方法及不同场景的总结沉淀，会形成一些体系化的东西，然后与工具做更多的结合，让大家通过工具就可以轻松上手，把好的实践最大化。例如，现在Aone的看板，看板上为什么分那些阶段、为什么有那样的一条条泳道、需求是怎样移动的，最早我们是用物理看板，但是现在我们把它都融入到产品里，团队建好自己的项目空间，就自动会有一块项目看板，从而让好的实践在更多的团队得到使用。

我觉得单独从了解方法或知识的角度来说，看完了一本书或者一篇博客，10天半个月可能也就忘了。但是我们可以从自己现实当中的问题出发，比如做为程序员可以去思考，如何能够让代码变更高效地发布。例如你可以搭一个持续集成的流水线，让大家的代码一提交就触发自动化的检查、自动化的测试和部署，把这个做好就是往敏捷，往研发效能的提升上就走了一大步。

对产品经理来说，需求应该如何组织，是否都有对应的目标，任务朝需求对齐，需求朝目标对齐。对于一线管理同学，可以思考整个团队的能力模型，团队的协作当中有哪些问题，比如测试和开发同事、前端和服务端之间的协作有没有更好手段，让大家的协作更高效。这样每个人都站在自己的角度上，改进一点点的话，形成合力。大家再在站在系统的角度，串起来一起看，就会改进很多。

即使是一个刚入职场开发同学，也可以思考代码能不能写的更clean，减少code smell，把这代码写的别人一看就懂，每一段代码都能有很好的单元测试，减少维护成本。这些都是在提升研发效能，在实践敏捷。敏捷不是挂在嘴上，而是落在每天的工作里。

张燎原：很多时候我们做工程师，都是站在自己的位置去看待问题，很少有机会能够站在全局，端到端的角度去看待问题。这次分享我希望能够带着大家一起，从研发的端到端、从需求到交付，去了解我们可以通过哪些手段去提升研发效能，以支持我们提升业务效能。

对于每一个不同的角色，能够富有同理心地去看待软件研发过程中的其他职能的工作，真正做到“眼高手低”：即看到整体，落到实处，整体形成合力，往组织效能最大化的方向去努力。

阿里有一句话叫做：一张图、一场仗，一颗心，首先画好一张整体的图，把团队之间协作的图画好，我们才能得对齐，上下同心，然后把这场仗打好。期待与大家的交流。