大兴安岭网站建设,seo工具优化软件,福田住房和建设局官网,外贸网站推广计划为了让大家对敏捷有更多的了解#xff0c;小编特意采访了阿里巴巴高级技术专家、敏捷教练张燎原。他是如何看待敏捷、如何帮助团队落地敏捷的#xff0c;作为研发团队的一员#xff0c;我们可以从哪些地方着手敏捷#xff0c;以下是对他的采访。 嘉宾简介#xff1a;张燎原…为了让大家对敏捷有更多的了解小编特意采访了阿里巴巴高级技术专家、敏捷教练张燎原。他是如何看待敏捷、如何帮助团队落地敏捷的作为研发团队的一员我们可以从哪些地方着手敏捷以下是对他的采访。 嘉宾简介张燎原阿里巴巴高级技术专家他是敏捷和精益方法的积极实践者和推动者具有十多年软件研发一线实践经验经历过消费电子、通信及互联网多个行业长期从事研发管理、研发教练及组织转型工作曾负责Nokia全球大规模敏捷导入实施和转型辅导成功帮助淘宝、闲鱼、阿里云等事业部引入精益产品交付和创新方法帮助实现DevOps转型。译有《程序员度量》、《软件驱魔》等。同时他热衷编写代码和开源涉及软件设计、测试驱动开发、代码重构、遗留代码的维护和持续集成及交付。工作之余他还擅长画画和摄影被同事戏称“最会画画的敏捷教练”。
1、燎原你好我知道你是敏捷和精益方法的积极推动者在阿里也辅导过淘宝、闲鱼等多个团队。从事敏捷这么多年特别好奇你是如何看待敏捷和精益的呢
张燎原以前敏捷作为一个很时髦的概念大家总是反复在提就像现在的DevOps一样。在我看来不论是敏捷、精益还是DevOps能不能解决问题 这个才是最重要的一切不以解决实际问题的概念炒作都是耍流氓。去年我和何勉老师阿里巴巴敏捷教练团队负责人在一起讨论 我们是在做敏捷、精益的转型还是其他的什么后来我们决定提升研发效能。作为一个研发团队能够持续快速高质量地交付有用的价值才是我们觉得作为一个研发团队要追求的。
提升研发效能主要分两点来看第一个是回答如何持续快速高质量的交付的问题。在交付团队里大家协作特别好写的代码要没有太大的问题——高质量发布特别快。所以我们知道的比如看板、Scrum是解决我们协作的问题测试自动化、CI/CD以及DevOps是为了帮助高质量的发布我们提倡的DDD、Clean Code是为了让我们的代码能够更健壮、质量更好、更Clean大家在协作的时候能够通过代码来交流这些都是提升交付能力的手段和实践。
另外一点是就要回答什么是有用的价值这个问题。对很多工程师来说大家可能更关心代码写的好不好从产品那拿到的需求大家基本都认为是对的。很多时候产品提了一个需求一个工程师可能要做一天甚至是一个礼拜才能完成这个需求。但是如果这个需求没有价值那就相当于白干了。所以这个时候我们要走到源头去看一看这个需求是否是有用的对我们的业务有没有帮助是否值得我们投入。
所以你问我如何看待敏捷我不会说是要快速响应变化因为我觉得这样还是有点抽象。回到研发的本质我们是要持续快速高质量地交付有用价值从解决阻碍我们达成这一目标的问题出发选择相应的方法和实践最终解决掉这些问题这才是实实在在、对我们有帮助的。
2、你是如何帮助团队落地敏捷的这中间有没有遇到一些困难
张燎原 我觉得首先是让大家看得见对问题形成一致的理解。当我们开始在团队落敏捷时大家会说我没有问题所以首先我们要让大家看得见问题在问题上达成共识。这样目标才会一致做事才能齐心。
其次大家在解决方案上要达成共识。有的时候针对一个问题可能有A解法也可能有B解法但我们要一起探讨是用A还是用B。例如B可能见效快但不持久A见效慢但是持久。这个时候我们得去找一个折中的解决方案。
再次要有一条明确清晰的改进路径。解决方案要能解决问题但同时也要给大家改进的信心。每个阶段都能解决一些问题通过持续地发现和改进问题牵引着大家往前走。这种改进不应该都是烟斗式的即开始会导致效率先降下来然后才会慢慢持续往上爬。
最后有节奏地给出有效反馈。通过在合作过程中通过数据也好或者观察到的问题也好持续地给团队反馈让大家明白自己是在正确的路上行走的。
这几点对我们来说都是比较大的挑战但比较好的是我们现在能驾轻就熟来应对。还有一点大部分时间我们是站在全局的视角来看问题这和具体的职能团队是有差别的他们更多是站在自己的职能的角度。大家看问题的视角不一样在沟通的时候也就需要更有同理心。
3、在敏捷实施过程中给团队建立信心真的很重要能具体说说你是如何在短时间内给团队建立信心的吗
张燎原在实施转型或提效的时候需要持续地给大家信心。我们不太建议一股脑地给一个完整的解决方案把之前的全部推翻掉就按照新的来。因为我们接触的团队基本上都是工作在现有的业务上的哪怕是创新型的一些团队大家之前也一起磨合了很长的时间大家都有自己熟悉的工作方式和习惯。
我们团队之前有一个案例《4个迭代从批量交付到持续交付转型》就非常典型每做一个迭代都是让大家看到收益然后才有信心做第二个迭代。例如当时的第一个迭代是把所有的职能端到端的拉齐让大家看到整体。这个时候就减少了各个职能之间的交流误会整个沟通就顺畅了。然后在整个可视化的协作流程中大家就会发现喔原来需求有这么多反复、原来需求太大了甚至需求都没搞清楚就开始了。其实很多时候这些都是大家自己发现的。当解决了协作的问题大家有了信心就开始着手解决需求的问题。当需求澄清的问题解决后又会发现发布速度是不是可以更快一点原来一个月发一次现在是不是可以每个礼拜都能发。这样每一个迭代都会有一些点得到了改进并且也能够持续暴露其他的一些问题能够让大家朝比较理想的状态前进。
如果你告诉大家落一个解决方案需要半年的时间说半年之后才能看到结果你做了一个月没结果大家能接受第二个月没结果大家可以坚持如果第三个月还是如此可能就没有然后了......这是我们在制定解决方案的时候需要特别考虑的。
4、你们的敏捷实施或提效一般多久能见到效果
张燎原从目前在阿里接触的一些团队来说一个月内基本上就能够看到一些明显的效果了。当然这跟我们合作的团队也有很大的关系大家彼此都挺配合的甚至有的时候他们比我们还专业他们会说燎原老师你看这种方式是不是会更好。然后我发现他给出来的点可能是我都没想到的所以在这个过程中我们也是在相互学习。
当然改进是一个持续的过程目标越大要投入的时间可能就会越长。
5、一般什么时候可以判断说这个团队辅导OK了
张燎原一般情况下在辅导开始的时候我们都会有特别明确的目标我们会清晰地把需要改进的问题定义出来让大家看得见找出根因而不仅仅是现象。随着问题逐渐被解决后面我们会有意识的慢慢抽身出来看没有我们的时候是不是也能够work起来如果我们发现没有我们也行这个时间也就到了。
在这个过程中很重要一点我们要善于发现和培养有潜力的同学在被辅导团队留下种子这些同学会是团队持续改进的生力军。
6、有什么方法可以帮助一些团队发现自己的问题
张燎原我觉得能做IT的人都是聪明人如果他没有发现这个问题更多的是因为他没有这个意识没有意识到自己要去看有没有问题。所以我们会通过其他的一些渠道让大家去意识到这件事。老实说大家不缺方法缺的是意识我们希望能够让大家意识到这件事情的重要性如果我们没有一个很好的研发能力去支撑业务效能的话我们也很难把业务效能做好。虽然很多时候我们只觉得业务效能很好很重要我承认确实很重要但研发效能是基础。如果你有一个很好的点子但是没有很好的这种研发团队没有研发方式来支撑。你的点子也实现不了。
7、如何让更多的有需求的团队也能得到你们的支持
燎原确实让我们去辅导一个团队肯定没有问题但是如果让我们同时去辅导很多的团队精力肯定就忙不过来一个人一天就24个小时。这个时候我们会有一些策略例如就像前面所述我们会培养业务团队的一些同事让他们成为这方面的专家就像一颗种子他也会发展壮大然后他自己做的一些事情对他所在组织都会有很大的帮助这是一种杠杆撬动的力量。另外我们还会通过其他的一些手段例如线上、线下的培训课程、最佳实践文章、案例分享以及鼓励更多同事把他们一些好的点子share出来。我相信这样一个一个的点都能够帮助规模化。
还有另外一个很重要一点我们所在的研发效能团队通过各个业务部门的实践对实践方法及不同场景的总结沉淀会形成一些体系化的东西然后与工具做更多的结合让大家通过工具就可以轻松上手把好的实践最大化。例如现在Aone的看板看板上为什么分那些阶段、为什么有那样的一条条泳道、需求是怎样移动的最早我们是用物理看板但是现在我们把它都融入到产品里团队建好自己的项目空间就自动会有一块项目看板从而让好的实践在更多的团队得到使用。
8、作为研发团队的一员我们每个人可以如何着手去实施敏捷
我觉得单独从了解方法或知识的角度来说看完了一本书或者一篇博客10天半个月可能也就忘了。但是我们可以从自己现实当中的问题出发比如做为程序员可以去思考如何能够让代码变更高效地发布。例如你可以搭一个持续集成的流水线让大家的代码一提交就触发自动化的检查、自动化的测试和部署把这个做好就是往敏捷往研发效能的提升上就走了一大步。
对产品经理来说需求应该如何组织是否都有对应的目标任务朝需求对齐需求朝目标对齐。对于一线管理同学可以思考整个团队的能力模型团队的协作当中有哪些问题比如测试和开发同事、前端和服务端之间的协作有没有更好手段让大家的协作更高效。这样每个人都站在自己的角度上改进一点点的话形成合力。大家再在站在系统的角度串起来一起看就会改进很多。
即使是一个刚入职场开发同学也可以思考代码能不能写的更clean减少code smell把这代码写的别人一看就懂每一段代码都能有很好的单元测试减少维护成本。这些都是在提升研发效能在实践敏捷。敏捷不是挂在嘴上而是落在每天的工作里。
9、最后本周六你的分享《从持续交付到业务创新》希望能给大家带来哪些收获
张燎原很多时候我们做工程师都是站在自己的位置去看待问题很少有机会能够站在全局端到端的角度去看待问题。这次分享我希望能够带着大家一起从研发的端到端、从需求到交付去了解我们可以通过哪些手段去提升研发效能以支持我们提升业务效能。
对于每一个不同的角色能够富有同理心地去看待软件研发过程中的其他职能的工作真正做到“眼高手低”即看到整体落到实处整体形成合力往组织效能最大化的方向去努力。
阿里有一句话叫做一张图、一场仗一颗心首先画好一张整体的图把团队之间协作的图画好我们才能得对齐上下同心然后把这场仗打好。期待与大家的交流。
原文链接 本文为云栖社区原创内容未经允许不得转载。
