对话阿里敏捷教练 | 成功辅导过淘宝、闲鱼，他都是如何帮助团队

为了让你们对敏捷有更多的了解，小编特地采访了阿里巴巴高级技术专家、敏捷教练张燎原。他是如何看待敏捷、如何帮助团队落地敏捷的，做为研发团队的一员，咱们能够从哪些地方着手敏捷，如下是对他的采访。

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

一、燎原你好，我知道你是敏捷和精益方法的积极推进者，在阿里也辅导过淘宝、闲鱼等多个团队。从事敏捷这么多年，特别好奇，你是如何看待敏捷和精益的呢？

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

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

另一点是，就要回答什么是有用的价值这个问题。对不少工程师来讲，你们可能更关心代码写的好很差，从产品那拿到的需求，你们基本都认为是对的。不少时候产品提了一个需求，一个工程师可能要作一天甚至是一个礼拜才能完成这个需求。可是，若是这个需求没有价值，那就至关于白干了。因此这个时候，咱们要走到源头去看一看，这个需求是不是有用的，对咱们的业务有没有帮助，是否值得咱们投入。

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

二、你是如何帮助团队落地敏捷的，这中间有没有遇到一些困难？

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

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

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

最后，有节奏地给出有效反馈。经过在合做过程当中，经过数据也好，或者观察到的问题也好，持续地给团队反馈，让你们明白本身是在正确的路上行走的。

这几点对咱们来讲都是比较大的挑战，但比较好的是，咱们如今能得心应手来应对。还有一点，大部分时间，咱们是站在全局的视角来看问题，这和具体的职能团队是有差异的，他们更可能是站在本身的职能的角度。你们看问题的视角不同，在沟通的时候，也就须要更有同理心。

三、在敏捷实施过程当中，给团队创建信心真的很重要，能具体说说你是如何在短期内给团队创建信心的吗？

张燎原：在实施转型或提效的时候，须要持续地给你们信心。咱们不太建议一股脑地给一个完整的解决方案，把以前的所有推翻掉，就按照新的来。由于咱们接触的团队，基本上都是工做在现有的业务上的，哪怕是创新型的一些团队，你们以前也一块儿磨合了很长的时间，你们都有本身熟悉的工做方式和习惯。

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

若是你告诉你们落一个解决方案须要半年的时间说半年以后才能看到结果，你作了一个月没结果，你们能接受，第二个月没结果，你们能够坚持，若是第三个月仍是如此，可能就没有而后了......这是咱们在制定解决方案的时候须要特别考虑的。

四、大家的敏捷实施或提效通常多久能见到效果？

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

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

五、通常何时能够判断说这个团队辅导OK了？

张燎原：通常状况下，在辅导开始的时候，咱们都会有特别明确的目标，咱们会清晰地把须要改进的问题定义出来，让你们看得见，找出根因，而不只仅是现象。随着问题逐渐被解决，后面咱们会有意识的慢慢抽身出来，看没有咱们的时候，是否是也可以work起来，若是咱们发现没有咱们也行，这个时间也就到了。

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

六、有什么方法能够帮助一些团队发现本身的问题？

张燎原：我以为能作IT的人都是聪明人，若是他没有发现这个问题，更多的是由于他没有这个意识，没有意识到本身要去看有没有问题。因此咱们会经过其余的一些渠道，让你们去意识到这件事。老实说，你们不缺方法，缺的是意识，咱们但愿可以让你们意识到这件事情的重要性，若是咱们没有一个很好的研发能力去支撑业务效能的话，咱们也很难把业务效能作好。虽然不少时候咱们只以为业务效能很好很重要，我认可确实很重要，但研发效能是基础。若是你有一个很好的点子，可是没有很好的这种研发团队，没有研发方式来支撑。你的点子，也实现不了。

七、如何让更多的有需求的团队也能获得大家的支持？

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

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

八、做为研发团队的一员，咱们每一个人能够如何着手去实施敏捷？

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

对产品经理来讲，需求应该如何组织，是否都有对应的目标，任务朝需求对齐，需求朝目标对齐。对于一线管理同窗，能够思考整个团队的能力模型，团队的协做当中有哪些问题，好比测试和开发同事、前端和服务端之间的协做有没有更好手段，让你们的协做更高效。这样每一个人都站在本身的角度上，改进一点点的话，造成协力。你们再在站在系统的角度，串起来一块儿看，就会改进不少。

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

九、最后，本周六你的分享《从持续交付到业务创新》，但愿能给你们带来哪些收获？

张燎原：不少时候咱们作工程师，都是站在本身的位置去看待问题，不多有机会可以站在全局，端到端的角度去看待问题。此次分享我但愿可以带着你们一块儿，从研发的端到端、从需求到交付，去了解咱们能够经过哪些手段去提高研发效能，以支持咱们提高业务效能。

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

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

原文连接 本文为云栖社区原创内容，未经容许不得转载。