敏捷团队转型的七种武器

产业团队敏捷转型实践。 大家都知道 企业组织中的敏捷变革是个系统性的工程，在这其中需要对企业中的团队、个体、组织几个方面多管齐下，才能保障敏捷变革的全面性。

 

一般来说，我们给企业做敏捷转型都会从团队入手，因为团队是企业中最基本的产出单元， 只有团队转型取得了成效，组织才能更加认可敏捷的价值，组织才能更加支持教练们的敏捷变革行为。 所以今天我给大家的分享就是一个真实的产研团队转型案例。

今天的正题主要是分为两大部分，第一部分会给大家介绍一下这个案例的背景。 第二 部分是总结了七个经验实践，我称之为七种武器。 各位如果有看过古龙武侠小说的，可能会对此有些印象。

 

 

 

案例背景

 

好，我们开始介绍我们的案例背景，首先给大家介绍一下产品团队的一个概括，这个团队它是一个异地团队，绝大部分人在北京，包括产品经理一个人、开发几个人、运营一个人、测试三个人都在外地。他们这个团队所负责的产品是一种ToB类的产品，比较偏技术。在改进前它有哪些概况？

 

• 首先在改进前他们就在进行两周的迭代开发，别的计划完成率比较低下。
• 第二个，因为他们团队的产品已经上线了，所以他们这个团队在平时既要做产品新功能的开发工作，也要做用户反馈的处理工作，这两项工作交织进行，团队经常手忙脚乱。
• 第三个就是大家常见的团队不停的加班，给大家看一些图，大家就能看到他们团队的相对情况。

 

这三个图是他们在改进之前走的两周迭代的燃尽图。大家可以看到这三幅图实际上走的情况都不太好。

我还记得当时我跟他们团队的主管在沟通他们团队的情况时，他们团队的主管评价他们团队的情况，就用了一个字：乱。说这个团队太乱了。

 

 

而当时的敏捷教练也面临很多挑战，当时教练所处的职能部门是PMO， 这个PMO虽然属于集团层级，但是它是一个服务型的组织，它与各事业部的产品线没有隶属关系，这就导致了什么呢？就导致了教练没有权力。这个团队之前做过所谓的敏捷，但是没有什么成效。 总而言之，要求敏捷教练转型需要有成绩单。 所以其实对于教练来说，他面临很多挑战，他没有权力，他还要把团队带好。

那该怎么办呢？需要我后面给大家介绍的7种武器来应对。

 

 

我们回顾一下这个团队的改进历程，这个团队12月份开始敏捷改进启动和规划，在1月份就正式开始实施，到5月份团队能够独立运转。独立运转是指什么意思呢？作为敏捷教练可能已经不在其中，去紧密的辅导他们的日常行为，而是已经脱离出来让他们自己运转，在5月份他们就达到了。7月份团队改进初步产生一些成效，在10月份的时候，他们的团队被评为“敏捷改进的优秀团队”。

 

 

右边这幅海报大家可以看一下，这是他们团队被评为敏捷改进的优秀团队以后，公司给他们做的宣传海报，在海报的右侧大家可以看到有五个度量指标，这五个重要指标就是显示出了他们改进的一些阶段成效。

我们接着看一下到底有哪些 度量指标。

第一个就是版本发版频率，这个在改进之前，他们这个团队大概是平均一个月临时发一次，是一种什么样的场景？就是说可能大家工作一个月了，领导要问你们团队这个月做的怎么样？

 

 

这个团队想一想我们发个版吧，都发哪些内容呢？就把之前做过的屯一块，然后发一个版。所以说它是没有规划的，临时发版。改进以后，他至少一个月要有规划的发两次版，所以说它的版本发版频率相当于提升了一倍。在改进半年后，版本的Bug解决率也达到了100%，在改进之前他就这个产品版本，他都是带着Bug上线的，都没有达到100%。你看他2月份的时候大概89%左右，但是到了7~9月份，基本上都能达到100%。

 

 

大家可能会有疑问说，那你版本Bug解决率是100%，你是不是都遗留了？其实他不是这个样子的。我们接着再看，大家看一下这个图表，它讲的就是这个版本Bug总遗留率的一个变化情况，你看他在17年的改进，一开始3~5月，他还是18% 、19%，但是七八月份到9月10月它已经降到了2%，实际上这是已经比较稳定的一种情况。所以说从这一点来看，它的质量真正的是得到了提升。

刚才讲了质量，我们再看一下这个团队改进的产能和效率。

 

 

这幅图表是团队改变之前的一个统计数据，在改进之前，他特性故事的交付周期大概是16天左右，速率大概是每天3~4个故事点，这是改变之前。改进之后，我们可以看见绿色的柱状图是它用户的平均前置时间，大家可以看一下，平均基本上都已经到了8天左右。所以说他特性交付周期对于改进前的16天缩减到了8天，而团队交付速率大家可以看一下折线。基本上从6月份开始，已经能够稳定到8点了。所以他的团队交付速率也由原来的4点升到8点，也就是说团队速率也提升了一倍。

整体来看，从数据的角度来讲，它的提升还是挺显著的。

 

 

刚才给大家介绍了这个案例的背景和改变的一个历程，接下来给大家介绍一下总结的七个实践经验。其实我今天用这个案例讲这七个实践经验，不是说这七个实践经验就是从这一个案例中得出来的，实际上是从多个实践案例中总结出来的。这七个实践方法我觉得就是说从形意上可以借用古龙先生的武侠小说其中的武器来隐喻或者延展。

7种武器

 

我们接下来一起看一下有哪些武器。首先我们来看第一个，第一个它是长生剑：不忘初心。

 

 

古龙先生在小说里是怎么说的呢？他说：“所以我说的第一种武器，并不是剑，而是笑，只有笑才能真的征服人心。” 其实在团队敏捷转型的过程中，团队成员是否能够和教练之间建立好这种彼此之间的信任，我认为是至关重要的。所以说在转型过程中，教练首先要做的是和团队成员同心，教练给团队做敏捷转型，做任何变革，实际上都是在解决实际工作中的问题，尤其是我们作为一名企业中的职场人士，我们的一个职业初心就应该是解决问题，产生价值。所以我要讲的第一种武器， 就是不忘初心，问题驱动转型改进，解决问题是第一要务，问题深入解决来驱动进展。

 

 

我们看一下在本案例中是怎么操作的。大家看一下这个片子，这个片子主要列举了十个问题，这十个问题就是这个团队在敏捷改进一开始，团队成员达成共识的十个问题。当然大家都能看到的这十个问题，可能都是表象问题？如什么开发测试需求，很多时候信息同步不及时、任务完成标准不清晰、计划外临时超任务较多、任务固定不准，临时发版太多等等。其实大家可以看到，这些问题是很多产研团队都可能会面临到的问题，但是通过这些问题的提出，才能帮助我们教练来设计敏捷改进的初步解决方案。

大家可以看一下，在这个片子中黑色字是他们的问题，在黑色字的后面的绿色字，就是我们针对他这个问题来设计的应用哪些敏捷实践来应对，这是初步的解决方案。当时我的计划是准备让他们用这种精益Kanban的开发上的方法。

 

 

那问题有了，我们接下来看一下在我们转型过程中是怎么跟踪这些问题的，因为你提出问题你总得跟进解决。这幅表格就是对这些问题跟进解决的一个跟踪表，大家可以看到在上一页我们提出了十个问题，但是在这一页我们只跟踪了八个问题，因为我们当时经过分析发现以后，其中两个问题可能不适合用敏捷的方式来解决，因为毕竟敏捷也不是万能的。所以我们当时是针对这8个问题进行了跟踪。

左边是问题，右边就是跟进的一个评分状态，我们当时是用什么方式呢？就是说在每一个阶段的回顾会上，都会对他的问题进行评分，我们以打分的方式来评估这个问题的解决程度，大家可以看到在这个表格的最右侧，2月24号，其实这是最开始，从右往左是越来越接近现在的时间点。大家可以看到在9月份的时候，实际上团队的一些问题，都已经得到了基本的解决或者缓解。11月份其实它已经比较稳定了，所以说从这里面我们就能够得出来，团队一开始提出来的这些问题，已经基本得到了解决或者缓解。

 

 

这样对于我们教练来讲就是你提的问题，我已经基本上给你解决了。总结一下我们的实践， 这个实践问题去驱动转型改进有三个要素：

 

• 第一就是通过对表象问题的圈定来确定初步的改进范围。
• 第二个是对问题的根因分析来定义初步改进的解决方案。
• 第三个是深入的问题解决，推进转型向更深层次拓展。

 

为什么呢？因为你一开始提的问题只是初步的，你可能随着改进的深入，你的问题会越来越多，作为教练你可能要持续的去应对。这个实践的一个关键点，我觉得就是可视化解决表象问题。为什么这么说呢？因为可视化的目的是让信息更加透明，转型过程中信息的开放与合作，既是同步也是建立团队成员和教练彼此信任的一个基础，这是一个关键点。

 

 

第二个实践的武器就是孔雀翎：具备信心。古龙在小说中怎么说呢？他说真正的胜利，并不是你用武器争取的，一定要用你的信心。无论多可怕的武器，也比不上人的信心。我们在一开始定义好了问题，有了解决问题的初心，有了意愿，但同时我们也需要具备信心，也得有解决问题的方法套路和应对策略。所以我要分享的第二件武器叫做 具备信心，系统化思考。 这种方法在这里指的是什么呢？指的是这种全周期覆盖，持续优化价值流和跨越方法论的壁垒。

我们看一下本案例是怎么样来践行的。

 

 

首先我们给大家列举一下，这个团队案例在敏捷转型过程当中，它主要用的一些方法论框架和实践工具。刚才讲过了，这个团队主要用的是精益Kanban，他用的工具是JIRA，这是它的基础。接下来在需求层面他用了User Story和待办列表梳理（Product Backlog Refinement），我们还用了这种基本的PDCA环，还有用到了SAFe中的PI Planning，团队自身也用了Code Review，当然还有他们一些特色的措施，当然这一些工具，实践上它都用到了，但是这些工具实践上不是一开始就说我要给你改进，不是一下子就全导入进去，而是逐渐导入的。

 

 

我们看一下更详细的，这一页是我们在JIRA团队中Kanban的可视化的工作流。这一些是他的工作项，包括他的故事，这故事包括功能故事，非功能故事，有Bug，有它的反馈，有它平常的一些任务、子任务，这是它的工作项。它的服务等级包括紧急类、固定交付日期类、常规类、无形类，包括一些紧急程度高低，还有它Kanban的横向泳道的一个划分定义。

 

 

大家可以看到我们这个里面有产品版本，有紧急通道，有固定日期，还有返回工作，还有普通工作项，还有Bug。我们用不同的通道给它区分开来。这里面就涉及到一个问题;你用JIRA的一块板，怎么样能让这些工作项都跑起来，我们是怎么跑的？大家可以看一下。大家可以看到在左边工作项这块， 它主要有三类，有用户故事，有反馈，有缺陷BUG。

用户故事主要指的是团队的功能故事和非功能故事，或者说它的业务故事和技术故事。在这里，用户故事他会从看板的最左列跑完看板的最右列，这是它整个的一个周期，这是用户故事，反馈就是团队平常要处理的用户反馈。这个反馈，我们让他从左边跑到最右边的验证这一列就跑完了。

 

 

BUG呢？我们让他跑到测试。这样我们就在一个JIRA看板上，让三种工作项类型都能够在这里比较有序的去流动，针对这三种工作项，在不同工作环节，我们定义了Kanban列的准入、准出标准或者说是Dod。大家可以看一下，最上一列是功能故事和非功能的故事，他在每一个列的Dod，还有反馈的缺陷和Bug，这样我们就能够很好的根据工作项类型，把这个团队所有的工作，有序的让他在看板上流动起来。这个是工作流，同时因为是看板开发，所以我们也采用了WIP限制，现在大家可以看一下WIP，大家看上面第一幅图，我们并不是在所有的看板列都设置了WIP，我们只是在优先工作项、开发经营中开发完成、验证上设置了WIP，下面的开发经营，大家可以看一下，我们设置的限额是4，但是它当前是9，所以它就会显示红色提示，表示已经超标了，这就是WIP的限制。

PDCA环主要有两个环：

 

• 第一个就是管理反馈环，这个环指的是对团队日常性管理活动的一个闭环。首先它有发布规划会议，有计划会议，有每日站会，又有总结回顾会议，这四个会议就把团队日常的敏捷管理活动形成了一个闭环。

• 另外一个PDCA环是什么？就是这个改进反馈环。因为大家都知道，你这个团队愿意，想敏捷转型转好，你必须得持续不断的改进，所以我们建立了一个改进反馈环，在这个里面，大家可以看到我们有建立反馈，通过各种渠道来收集反馈信息，通过分析和度量来找到改进的措施，通过让改进行动能够落到实处而产生效果。回过来再持续去发现一些反馈信息，这也形成了一个闭环。这就是我们的PDCA环。

 

我们来看一下管理流动这一块，我们团队的工作流，它随着改进的进行，它的一些措施也是不断的在进化和演进的。大家可以看一下在这个片子里，最上面这个就是团队一开始的一个工作流、看板等，过段时间，大家可以再看一下，我们演进到什么程度了呢？大家看一下，蓝色的是WIP，我们就把WIP的限额给加上了，我们不是一开始就加了WIP，是经过了一段时间以后才加上WIP，红色大家可以看一下，它是我们增加的新看板列。原有的看板列我们做了一些梳理，这是第二次演进。

第三次演进大家看一下，我们又有变化了，我们把所有的需求都变成了产品Backlog，增加了优先工作项这一列。所以大家可以看到，团队的演进也是持续进行的。

 

 

这一幅图就是团队做的 PI Planning的一个实践，因为这个团队有一些工作，要和别的团队一起协同去完成。在改进之前，这些团队都是独立开发的，所以沟通效果特别差。通过我给他们引用了 SAFe的 PI Planning这个实践，你看这幅图就是他们用PI Planning做的一个简要的Planning，大家可以看到，在这里面的两个团队分出两端，中间是他们公共的依赖，他们在这里面把他的一些版本通过这种planning，版本的deadline就很好地就定义出来了。这样的话它就能实现对齐拉通、高效写作，在这里面我只是展示了一个物理的PI Planing，实际上我们在使用JIRA的时候，是有一个协同的JIRA上看版。这是PI Planning这个事件。

 

 

我们总结一下， 系统化思考实践的几个要素是什么？

 

• 第一个是系统化思考，要实现过程的MVP化覆盖。这句话是什么意思？大家都知道，我们在这个产业过程中有前面的产品需求，有中间的研发测试，还有运维等各个环节，可能开始的时候，所有的环节一起都改，我感觉可能不太容易，以我个人的教练经历，一开始 这个样子可能不太好，大家可能一开始都是从开发测试环节来介入，所以我说什么是过程的MVP化？出来的是什么？就是你可能一开始只是从开发测试环节介入，过了一段时间之后你会发现可能不够好，你再往前延展到需求环节，你觉得还不够好，你再往后延两个月运维环节。

• 但是每一个环节的敏捷措施或者敏捷的实践选取，你都应该看作是一个小小的MVP，就是它应该能够解决应对一些问题，所以我称之为是过程的MVP化覆盖。

• 第二，我们要按需选择实践，大家在做的过程中不要局限于说我用的是Scrum，还是说我用的是看板，那我就只能用这个不能用别的吗？并不是这样子的。我们要按需选择实践。

• 第三个就是渐进式实施，大家不能着急，着急就会坏事，我们需要渐进式的实施。所以这种系统化思考，它的一个关键点是什么？就是要系统化解决根本问题。

 

我们前面讲的实践，是问题去驱动转型改进，你解决这种表象的问题，让团队能够给你建立信任，我知道你对他是有帮助的。当然大家都知道你这个病人有病了，要标本兼治，不能只治标不治本，我们系统化思考，这个实践就是说要治本的，所以我们只有通过标本兼治，才能很好的让团队真正的实现这种改进，变得越来越好。这是我要给大家分享的第二个实践。

 

 

第三件武器就是 霸王枪：勇气尝试。 古龙怎么说的？他说一个人只要有勇气去冒险，天下就绝没有不能解决的事。

在团队转型过程中，我们作为教练光有系统化的方法策略是不够的，我们还得去推进执行，在执行中有很多种情况，作为教练有一点很重要就是什么呢？我们应该能够容许团队试错，这也是我要分享的第三种武器。 你要容许团队试错，允许团队在一定范围内的尝试，而且你要引导式的推进。

 

 

比如这幅这幅图，大家可以看到这是一个哭泣的小孩，你如果是家长看到孩子哭了怎么办？可能大多数会有两种选择，第一种选择，你哭吗？这个我强制我不允许你哭，再哭我就揍你。

第二种，我就哄孩子不要让他哭，很明显我们只能选择第二种来哄的方式。

其实在这里面有一个对比，就是说我一直觉得咱们的团队其实跟小孩子是很相像的，为什么这么说？因为团队你会发现他有时候他也会有脾气，有自己的想法。虽然你是教练，但是他可能有的时候对你的转型措施会有意见，这也很正常，毕竟我们敏捷教练也不是神，团队当然可以质疑你，在这种情况下作为教练，其实咱们就只能是说循循善诱，你不能强硬指令，因为团队敏捷转型本身的这种不确定性就很高，教练需要获取团队的信任，所以尊重团队是必备的一个根本条件。因此咱们教练要善于运用这种领导力、影响力，而不是纯指令似的控制。

另外团队也只有犯过错才能认识的更深刻。举个例子，我之前带了一个团队，一开始我让他们做故事点的估算，他们都不愿意估，说这太浪费时间了，还是拍脑袋快，我说你们就拍，我就让他们拍，结果他们拍了一两个迭代说拍的确实不太靠谱，结果他们乖乖的跑回来，来做这个故事点数的估算，所以你看有时候你是要容许团队去做一些尝试的。

 

 

我们总结一下这个实践是什么内容？

 

• 首先第一点，我们要尊重团队改进过程中的意见。

• 第二，对于团队提出来的一些尝试在可预见的范畴内是可以实验的。

• 第三个就是我们要及时分析总结实验结果，并且正确引导团队。

 

这个实践的关键点在于什么呢？ 就在于说我们要可控试错，及时修正，这是第三个实践。

 

 

接下来给大家分享的是 碧玉刀：诚实坚持。 古龙是怎么说呢？他说所以他能击败青龙会并不是因为他的碧玉七星刀，而是因为他的诚实。在一个实践的总结，是因为我看过好多自称敏捷还搞得不错的团队，他们自认为自己搞的不错，但实际上他们的一些所谓的敏捷的行为，其实我觉得它是违背了这种敏捷的价值观和经济原则的，也就是传说中的伪敏捷，所以我觉得说有没有把这一点总结出来和大家分享，针对这些伪敏捷我们应该怎么做呢？我觉得重要就是我们要确定策略，坚守原则。

 

 

我们看一下伪敏捷都有哪些常见的问题，比如说用Scrum，它都可能迭代时间盒经常打破，随便的延一天延两天，说产品开发测试对需求的理解都是表面化，好像说是一致的，但其实并不一致。还有就是说团队管理者经常一言堂，像这种迭代内的瀑布式的开发，还有像这种团队成员他只是指令式的执行，就是你让我干啥我就干啥，信息不同步等等。其实是有很多的，比如我还见过一些团队，她们站会就变成这种进度汇报会。我开站会大家说一圈，但是一般人不说话。团队 leader跟产品经理两人变成两人对话了，其他人大眼瞪小眼，就是你问问他说说张三你这个做的怎么样了？张三说我这个正常不正常就是变成这种。比如说像这种用户的使用，五花八门很多，所以我觉得说现在我们要想做好敏捷转型，咱们就要遵从这种敏捷的底线原则和价值观。

 

 

其实这个实践它的要素是什么？

 

• 第一个就是在所有改进过程中，我们实施的措施我们都要评估是否和方法论的原则相抵触。

• 第二个就是我们要切忌随意发挥，你不能随意发挥。

 

为什么这么说？大家这么想，一套行之有效的方法论，它的存在必然是有其价值，它一定是有意义的有价值的，不然它为什么存在？尤其是敏捷，敏捷宣言是2001年诞生，我们就不算说很久之前就有了，从2001年算起到现在也20年了，既然一个理论方法它能够持续走了20年，还在持续不断的演进，它肯定有它的价值在里面。

我们在去实施执行的时候，我们就一定要做到这种形神兼备，不能只走形式，或者说随意解读发挥，是这样的，所以说这个固守方法论的原则，它的一个关键点是什么就是说要支持创新，我们支持创新，但是我们要固守底线，不能随意去发挥，你再随意发挥你可能就不是敏捷了。这是我要跟大家分享的第4个实践。

 

 

第5个武器是什么呢？是这个 多情环：平衡取舍。

下面这句话，这不是古龙说的，是我演绎的。在软件产品研发过程中，其实大家都知道， 度量分析是很重要的，尤其是在敏捷转型过程中，团队的情况更需要尽量的透明，全面的可视化出来。 因为相对主观的这种定性判断，咱们数据度量就能够比较客观真实。同时团队转型的效果使用度量数据也会更直观。所以在团队的敏捷转型过程中，我们需要敏捷度量，为什么呢？因为度量它能够促进我们的敏捷改进。同时它能够比较精准的去定位问题，支撑更精准的分析。还有它能够促进改进措施的一个获取，这个是我局的度量比较有价值的地方所在。

 

 

我们看一下本案例中它用到的一些度量，大家看一下这个是累积流量图，大家都知道看板开发，在看板开发方法里面会有累计流量图这个图表，这个是我在JIRA上截取的，它是从2~10月份是在第二年改进的一个累积流量图，大家可以看一下，左边这些图标都是它看板上的看板粒，右边是它这个图，它就流量图。

 

 

除了这个我们还有WIP趋势图，大家也可以看一下，在左上角是我们设置了WIP的工作列，大家可以看一下，这也是从2月份到10月份，大家可以看一下它的峰值，你看峰值实际上都是在变小，这说明什么？这说明团队他们WIP都有渐渐变小趋势，流动趋势，所以说他更往单件流的趋势的发展。这也能客观的能看到说团队的看板使用是在变好，这是WIP的一个趋势图。

 

 

接下来大家看一下这个是用户故事的平均前置时间，大家可以看一下，之前我给大家讲过，这个团队它的用户故事，就是说特性需求的开发周期也是用户的平均前置时间，从原来的16天变成了8天，数据哪里来的？就是这里面来的，大家看一下左上角，平均一周一日就是8天。

你看图也能看出来，在图上看得从17年的3月份看中间的蓝色的粗线，它是在红实线之上，还是比较高的。到了7月份的时候，你看它那就明显的在往下走了，中间可能有一些反复，但是整体来说它的平均周期是变低了。所以你通过这些数据，你就能发现团队一些变化的趋势。

我们总结一下度量实践，首先第一点，我们要选取适合于团队的度量指标，比如你要用Scrum，你可能就要选一些别的速率，你要用看板，你可能要选择这种前置时间提升效率等等，这是合适的。第二你根据团队的发展，度量指标也要不断的演进，比如像这个团队那一开始，可能我们的前置时间，它可能就不是这种全周期的度量，可能我只度量开发中，测试中。

接着我再把前面的需求和后面的方法等待这些在逐步的把这个度量周期来拓展。因为你不同的阶段，你可能要进行持续的去演进拓展，这样才能更好地去了解他们的情况。在前期的时候，你上来就度量一个整个周期，可能每个环节都有问题，你可能度量一整个的周期你也不太好分析，所以我说你这个指标你要根据团队的发展，度量指标要有一个不断的演进。

这里面它的一个关键点是什么？就是 度量只是工具而不是目的。

我在这么多年的工作经验中就发现了，其实咱们很多团队当然不只是敏捷团队，只要在产研工作中就会有很多组织部门去做这种度量，把好多度量都做得特别细特别多。有的团队他可能就是说光度量这个事，有时候也需要一个专人要花很长时间，可能每周都要出什么周报月报都要出很多。有的时候其实没必要有很多重要指标可能都不是特别有意义或者是有价值。所以我在这里要强调就是说度量这个东西它只是工具。

比如我们通过度量，我们能够更精准的去定位问题，更好的去能够获取到改进的措施，我觉得它就比较有价值了。如果说你光是说拿度量的一个数，来说明你这个团队好或者不好，我觉得这就会比较片面。你根本就说有的时候你很多你度量数据本身，你还不准确。所以我说度量只是工具并不是目的，这个是实践的一个关键点。

 

 

接下来给大家介绍，另外下一个实践是什么？叫做 离别钩：戒骄融合。 古龙在书中怎么说呢？他说你用离别钩，只不过是为了要相聚。在这里面，我们取相聚的谐意就是融合，大家都知道团队的敏捷转型变革，是比较复杂的一件事。

其中涉及到的角色岗位是非常多的。作为敏捷转型的推动者，比如咱们可能很多人都是教练去推动，或者有一些可能根本就不是教练，是项目经理或者等等。但是不管怎么说，只要你做了团队的敏捷转型的推动者，在某种意义上实际上你也就类似于一种敏捷转型项目的项目经理了。假设说你把转型这个事情成为这个项目组。

我们这个时间就给大家介绍的武器叫做什么？叫做 协同项目相关方 ，就是你首先把你的敏捷转型看成是一个项目，你做项目管理，你就要协同项目相关方怎么做呢？你就要做好利益的协同，共同推进进展。

我们看一下案例中是怎样操作的。既然是项目，你可能就要定义对项目相关方应对的一些策略。比如像这个团队，它 涉及到的相关方岗位角色有哪些？主要有这五种？有哪五种呢？

第一个是团队的部门经理，我跟他去调研，说这个团队很乱的那个领导，他的希望是什么呢？他肯定希望团队改进成功，团队越来越好。对于他来说，可能我作为敏捷教练，我可能就是可能要阶段性的和他沟通，以及一些重大的角色发生了一些讨论，像这种人投入的精力可能不会特别多。

第二种他的角色是什么呢？团队的研发主管就是一线Leader，也是我们团队的 Master的这个角色。

他的期望是什么？他作为研发主管，他经历过之前团队比较乱的情况，他也很苦恼，他肯定希望说什么？团队工作更顺畅，就是说你改进成不成功，他可能第一要求想要述说我工作顺不顺畅，他是一个关键人员，是敏捷种子，所以你作为教练你肯定要给它细心教练，在他身上投入的精力最多。在团队中还有一些产品经理、测试主管，这些人可能跟研发的Master，他的期望是类似的，但是对于他们来说，可能作为教练投入他们身上的精力，你就不需要像 Master这么多。

另外比较多的人员是什么呢？就是普通团队成员，其实你说团队成员会看团队敏捷转型这个事情我觉得不会的。他可能更多的关心是什么？就是这么说你这个团队你做不做敏捷，我都要干活？我干一天活赚一天钱？或者说可能有那些比较积极的开放的，他也希望说学到更多东西，但是我觉得大多数团队成员，他对我们敏捷改变期望是什么，就是说你做什么都好，但是你不要影响我的工作。不要给我增加一些累赘。

对于这种普通成员，可能我们就是一个比较普及型的指导，他们对敏捷有疑问了，你可能就要有问必答。当然在他身上投入的精力，你可能也不会像Leader层级这么多。

 

 

另外一个就是说敏捷教练的领导，PMO的经理，他可能跟团队的主管的情况是一样的，因为你看他派人去做改进这个事情，他肯定希望改进成功。教练对于他可能你就要工作上做汇报，有些资源需要他去协调的，所以你看从这个表格我们就可以看出来，教练在项目中对相关的人，其实他是有不同的应对策略和投入精力是不同的，不能千篇一律，怎么能做好这些呢？你就要做好这种沟通和信息同步。

可以做哪些呢？比如我们可以阶段性的发一些简报，你看这个是他们每一个阶段是这样的，虽然这个团队他不走Scrum那种两端的迭代，但是我也会阶段性的让他们开这种回顾会，这样就是说它才能有节奏感。他每次开完会以后，我都会把团队的改进的简报会抄送给相关的人员，告诉大家这个团队现在是个什么样子，同时你肯定要及时及时去发布。

 

 

总结这个其实行政项目相关方这个实践，它的几个要素什么呢？

 

• 第一个就是我们要分析不同相关方的项目期望，采取针对性的措施，因为不同的人他对敏捷改进这个事，他的看法肯定不一样。

• 第二就是说在项目中你要最大化的协同共同利益，就是说虽然说每个人的期望不一样，但是可能我们找到一些敏捷改进，让可他们的期望能够匹配、更加一致，这样我们大家才能有共同的利益。

• 第三个就是什么呢？改变过程透明化，一定要尽量透明起来，你是用这种看板也好，是用这种电子看板也好，物理看板也好，还是说邮件什么的，就是你要过的过程一定要透明，你不能说你做了什么事情什么人都不知道，你这样是很危险的，你想比如说作为团队的一个主管，人家把图片交给你了，让你做改进，结果你什么都不会告诉人家，或者总是不及时沟通。人家可能会担心吗？所以我们要改进过程透明化，沟通及时化。

 

在这个里面关键点是什么？只有小演员没有小角色，团结一切可以团结的力量。团队中大家可能觉得说新来的这个人也没什么经验，大家不要这样想，每一个人他都会有自己的想法，他都可能对于敏捷改进起到很重要的一个影响。所以我们认为说啥呢，只有小演员没有小角色，这个是实践。

 

 

我们再给大家介绍最后一个实践，这是 一口箱子：永不放弃。 古龙是怎么说的呢？他说歌女的歌，舞者的舞，剑客的剑，文人的笔，英雄的斗志都是这样子的，只要是不死，就不能放弃。其实大家都知道就是咱们其实敏捷变革的成功率其实不是很高，那是因为就是在敏捷转型的过程中，作为教练你确实会遇到很多困难，会遇到很多看得见和看不见的大坑，怎么样才能做到不轻易放弃，而力争转型成功。

我最后给大家分享的一个实践是什么？就是转型过程要项目式的管理，要把转型过程那样放进来进行项目式的管理，我们看一下案例是怎么做的。一开始的时候，我们不是说团队提出了十个问题，最后我们筛选出八个来做吗？那时候其实我们定义了一个初步的项目的改进范围和目标，有哪些目标？

 

• 第一个是在阶段时间内，基本解决或者大幅缓解团队提出的表象问题，当然我在这里跟大家说是表象问题，但那时候跟团队不能说表象问题。

• 第二个是要让团队建立一种系统化的看法开发规则，是基于JIRA支持的，开发过程要基本成熟。

• 第三个是完成团队由迭代开发向看板开发的一个基本转型。因为它们之前有迭代了。

• 第四个我们要用这种数据度量指标来度量团队的情况，来更好的支撑团队的持续改进。

 

这四个目标其实如果借用敏捷的术语来说，它实际上还是一个守的阶段的一个目标。那么什么是守呢？这里面就涉及到一个敏捷改进的一般规律，是什么？守破离，守就是说你要遵守规则，规则拿过来你先到了用，破就是说你开始有自己的特色规则，离就是说你是根据自己需要，你完全能够灵活的应用这些规则。

为什么这样呢？因为团队的敏捷转型，好比是一个长期的系统化工程，它的复杂度很高，我们为什么说团队要“持续”改进？因为它需要很长期，但是你也不能说我这领导问你说你这团队多长时间能改好，你说他就是一个永远的长期的过程，那也不靠谱。所以我们要运用这种守破离的方式，有什么好处？

 

 

第一个能降低复杂度，因为从整个周期来看，敏捷团队转型很复杂，但是你给它分成阶段，它就相当于会简单一些。 每个阶段你都去针对性的应对，可以针对性的措施，就像我之前给大家讲的，我们渐进式的去加一些实践进去，对团队一点一点用药，你不能一下子下猛药，你一下猛药可能病人就过去了，只有这样才便于管理操作。

 

 

我们总结一下这个实践是什么呢？大家可以看一下，先看下右边这个高山图，你看这个高山根据它的海拔不一样，在每一个海拔高度上它都有不同的植被，你看有常绿阔叶林，有针叶林等等，其实这些就跟团队一样，团队在不同的阶段，它的问题或者说它的情况也有不同的特点。所以作为教练，我们要分析团队，改进各个阶段不同的特点，根据不同的阶段去定义我们不同的定义多个这种改进的小项目。

我们转型改进，在迭代的进行，比如你首个阶段你能改的不错，有一个阶段的成效，领导就会认为你还不错，他会更加支持你，你才能更深入的进行下一阶段，这你让领导总等着，那你肯定是有问题的，所以说这个实践上关键点是什么呢？说明我们要阶段化、项目式。

讲到这里，我们七个实践就给大家讲的差不多了，最后带大家整体回顾一下，整体回顾一下几种武器，就是首先咱们给团队做敏捷转型改进的，你要以问题为驱动，你要抓住问题，你在关键的问题上还要系统化的去思考，系统化的去应对解决。

在这个过程中，你要容许团队试错。但是在这个过程中，你也不能让大家随意发挥，你要固守敏捷的原则和价值观，同时你可以用度量的方法促进改变。

当然人的关系很重要，所以我们要协同相关方，让大家利益协同，最后你要用这种项目式的管理，把敏捷转型改进的事情复杂程度给它降低。

当然这七种武器是对咱们敏捷改进的一个实践经验的总结，实际上这些一个由于敏捷改进之外的一些工作过程，或者说工作场景。哪些呢？就是这个样子，比如说不忘初心、具备信心、勇气尝试、诚实坚持、平衡取舍、戒骄融合、永不放弃。其实大家做这样的事情可能你都可以考虑到或者说应用这些信条或者实现方法。

 

内容来源：敏捷+社区线上直播013期，《敏捷团队转型的七种武器》分享实录

分享者：王凌宇