【摘要】 主要分享团队的人和事，以及团队里面在敏捷转型当中最头疼的大象集体沉默现象。

大家好，我是今天的分享者胡俊，大家也可以叫我小玩童。感谢网易杭研管理部以及敏捷家的邀请，感谢Bob和李岩的组织，在这里和大家分享我的敏捷实践经历。这次分享既是对自己敏捷实践的梳理，也希望这些经历对大家有参考作用。分享的内容是我个人目前对敏捷的一些理解，不一定正确，抛砖引玉，也希望后期可以听到更多优秀伙伴的分享。

今天的主题是敏捷与教练相得益彰。这个主题是受一本书的启发，书名叫《看板和 Scrum相得益彰》，它符合敏捷的一些特点，是灵活的，是兼容并包的一种方式。

这张封面上的图是我挑选的，因为这张图在我辅导敏捷团队时出现了2~3次。这是一个创业团队办公室里的神图。我之前看这张图还没有什么感觉，但是当我越来越多的接触到敏捷，接触到更多的团队之后，就发现这张图的背后有一些东西引起了我的共鸣，所以我把这张图放在封面。

首先要介绍我的经历，因为今天分享的内容和我的经历有关。

我目前是一名组织级的敏捷教练，一直在实践中探索敏捷，从支持几个人的小团队到几十人的项目群，目前正在支持几百人的产品研发中心。我本人对IT很感兴趣，从96年开始就使用QBASIC进行开发。06年毕业后加入了世界500强排名第一的跨国公司，在信息部门受训并且从事IT管理的工作，后期做专职的IT咨询持续了10年，主要专注于全面预算和商务智能，平均每年大概2~3个项目的迭代。

我工作的内容主要集中在B端，那段经历让我对B端的软件、产品建立了感觉和认知，后期工作的内容在方案实施的基础上增加了项目管理和团队管理的内容，也取得了一些成绩，例如：实施了全球最大的Oracle预算管理项目，管理13个产品条线的交付条件。

为什么会在敏捷这个领域去着重的研究？因为后期项目管理的工作内容越来越多，感受到了更多交付之外的压力，除了需求分析、项目管理，团队管理这些内容，自己也从执行项目经理到项目经理到项目群经理，压力变得越来越大。

2011年开始了解极限编程、迭代的相关内容，后期真正触动自己，开足马力研究敏捷是因为我的两个项目连续被叫停，第一个项目是一个大的项目群，由于项目管理出现了问题，工期延期一年；另一个项目是需求蔓延，和客户最终达成一致进行止损，整个项目终止。

这两个项目对我的触动非常大，之后我离开了原来的咨询公司，加入了一个独角兽互联网公司，负责B端的财务采购系统建设。在工作过程中全面的梳理和迭代，重构项目管理的知识和内容，逐渐拓宽了视野，之前都是自己埋头研究，现在发现敏捷有很大的圈子，在北京有很多敏捷圈，全国各地也有敏捷社区。今天把我的一些思路，一些经历贡献给大家，希望对大家有所参考。

团队的人和事

为什么会讲到教练这个话题？因为目前我主要辅导团队的敏捷转型，现在也有进行敏捷转型的大项目。当我在辅导敏捷转型时，从方法工具层面越来越困难，单团队还好，到了项目群级别，到了研发中心这么大的体量，我发现团队动能像飞轮一样推起来十分吃力，无法激活团队的动能。所以后期就开始研究敏捷背后的内容，也促成了今天敏捷和教练的话题。

在辅导敏捷团队的过程中，我一直在观察团队，发现团队工作时不仅是工作这样简单，它是有两个维度的：

• 第一个维度是任务运作（事情）的维度。
• 第二个维度是团队里人和人之间的关系维度，也叫社交氛围维度。

任务运作维度：敏捷中会有产品的迭代目标、制定工作计划，计算资源的速度负载，通过每天的站立会议交流信息，通过工作坊去处理专题中的问题，以及敏捷绩效管理，这些都属于任务运作维度（事情的维度）。

另一个维度也是对团队有很大影响的维度，是团队的社交维度（人的维度）。它包含听起来比较虚或者不好着手的一些方式，像沟通、共识、协调，合作、团队学习、凝聚力和满意度。

这两个维度，整合后就是团队钟摆的原理，团队的前进是在人和事之间不断摆动中前进的。所以这个模型也叫团队钟摆模型，是目前可以从人的维度把这些关键词整合起来的模型。

我在和团队的PO或者SM交流时，大家提到比较多的是团队的满意度，工作是否开心，凝聚力等等，这些都属于人的维度，说明大家对这方面都是很关注的。目前敏捷更多关注方法层面，关注任务运作，对于人的层面关注较少，我们可以通过其他领域关注，后面会给大家介绍。

在辅导团队的过程中，我们把团队的冲突通过钟摆模型进行区分后，可以分为两类：

• 一类冲突叫任务的冲突，包括：制定的目标，团队成员说目标不合理；制定的计划，团队成员说计划不合理；确定的负载，团队成员说实际负载很高。这些都属于任务的冲突，这类冲突对团队是有益的。
• 另一类冲突是社交氛围的冲突叫人际冲突，这类冲突对团队是有损伤的，所以我们实施敏捷时，和团队一起工作，需要把人际冲突还原成任务冲突。因为任务冲突如果不去排解，会逐渐上升为人的冲突。

也就是我们在敏捷转型过程中出现的三级抗拒：

• 一级抗拒是：我不理解它。为什么要做敏捷？敏捷是什么？可能开始时连敏捷是什么都不清楚，如果直接导入敏捷，直接进行敏捷仪式，会产生团队的一级抗拒：我不理解他，所以在执行时也无法严格执行。
• 一级抗拒的问题如果没有解决好，就会上升为抗拒的第二级：我不喜欢它。我不喜欢敏捷，即使我已经了解了敏捷，从心里也会有抗拒。如果这一层依然没有处理好，会进入第三层，解决第三层的问题会更困难，敏捷转型的风险会非常大。
• 第三级抗拒是：我不喜欢你（敏捷教练），包括一些敏捷的外部咨询力量，或者是推动敏捷实施的部门里的人，他会认为我不喜欢你们这群人，上升到人的高度，就会更麻烦。所以把视角从团队的事情再增加一个维度：人的视角，然后将这种冲突还原成对团队有益的任务冲突，将敏捷转型的抗拒，还原成本来应该去做的信息同步，例如在事情层面可以解决好，就还原成事情，这也是团队钟摆目前面临的现状，也是这个模型给我们带来的启示。

有一本书叫《房间里的大象》，它来自于英国的谚语，是指：大家都知道的，但是都不说的，不敢说，不愿意去说的事情，叫做大象。和皇帝的新衣一样非常明显，这种现象称为团队中的集体沉默现象。在一个团队中，大象的出现会有很多种情况。进入团队后，第一感觉就会发现团队的氛围可能出现了问题。例如：有的团队人员变动很频繁，就会出现团队信任的问题；有的团队角色，在任务发生变化，目标进行调整之后，角色自己还不清楚，工作时总感觉有力使不出，这就是角色不清。

之前讲到的冲突也会存在，原因有很多种，例如我们的一些文化习惯，导致有些问题不会当面说出来，这些沉默有善意的，也有中立的，当然也会有恶意的。产生的原因就是文化的冲突，亚洲的文化导致我们不愿意当面说有伤面子的事情。

我们在团队里调研时，有些团队成员说自己的职位比较低，只是普通的团队成员，那些权力的问题，是Leader的事情，不愿意和我们说；还有人际关系之间的互动，一些文化习惯等，都有可能产生房间大象的情况。

以上是目前在辅导中面临的一些问题。

敏捷的形与神

• 第一部分是敏捷团队中的人和事；
• 第二部分是敏捷的形与神。

当我关注到敏捷，精益和敏捷方法时，就感觉它对我的吸引力非常大，因为我发现敏捷和其他的方法不一样，在精益或者敏捷里，提到了很多的人和团队，包括精益的一些原则和敏捷宣言里都会提到，所以我认为这是一种形神兼备的做事方法，很全面，之前提到的团队中的人和事，这两种方法都兼顾了，所以产生的效果非常明显。

第一种是管理实践。我接触到敏捷是从管理实践开始的，看板、Scrum、极限编程、DSDM以及其他的敏捷方法，当我学完一个敏捷方法之后，发现还有很多相关联的敏捷方法，上面的这张图，它的原文是“你相信吗？敏捷有40多种方法”，所以敏捷的管理实践是非常多的，每一种都可以组合起来应用，也可以单独去应用某一部分。如果你可以抓到敏捷背后的神，那么真的很有用。

第二种是工程实践。敏捷追求高效率，持续发布，持续交付，所以会有越来越多的工程实践概念出现，例如DevOps，以及银行可能比较关注的DevSecOps开发安全运维，还有测试运维等。这些工程实践也代表了敏捷的外在。我当时研究到DevOps之后，就没有继续深入研究了，在我的印象笔记里还收藏了DevSecOps的分享，是渣打银行的伙伴的分享实践，当时我只是保存，还没有去看，因为后来发现自己并不是专门的开发者，所以对于工程实践的部分，暂时只处于了解阶段，没有更深入的探讨学习。

我会把我基于自己的兴趣以及个人的经历或者是能力部分转到另外的视角，后面会介绍另外的视角是什么。

这个是我参加Bob 老师的CSM课程时认为很好的一个图，Bob 老师用一把大伞把敏捷的概念讲得很清楚，敏捷的背后有很多的工具、方法、框架等等，敏捷是非常兼容并包的，所以它的形的部分仍然不断在发展，可能没有固定的框架。所以有点像大象无形，它的形已经太大了，以至于你看不到它。这是从形的层面来看敏捷。

这是我理解的敏捷背后的神的部分，以及如何去抓住敏捷中人的部分的探索，我在研究敏捷时也经历了一些历程，开始是几个人的小团队，单团队的敏捷；然后是一个现场交付项目，七八个产品组成项目群；然后到公司级的产品研发中心，会有更多的项目群组合在一起。接下来我会逐一介绍在每个规模层级上的敏捷，它背后的神是有一些差异的。

首先是单团队实施敏捷，我们用一个项目去做敏捷试点时，更多的是先从了解敏捷的思想开始，进行故事地图、影响地图，用户故事的一些需求管理，使用看板来引入这些实践，因为我当时在北京的引导技术大会上接触到了教练，所以这里写了敏捷迭代和个人教练。在单团队的管理中我会用到一些教练的方式，教练目前是从IT的角度学习人，和hr或者销售不同，他们有不同的视角，从IT的视角，我发现教练技术的领域切入人是非常快的，下面是我在单团队辅导时，用到教练技术的例子。

有一个小伙伴提问：我们在看板墙上贴的这种小纸条任务卡片一般是什么内容？

我在回复“你现在写的是什么？”这句话之前，我是回复了敏捷里标准的5点，例如：要在卡片上写编号、名称，标题、预计完成日期、负责人。因为我回复后想用教练的方式来引导，所以就把我写的答案删掉了。重新回复了教练经常会用的，从现状开始。

先了解你现在写的是什么？先建立连接，结果对方发来9点，比我发给他的多，我没有用顾问或者咨询给建议的方式，而是使用启发式的方式。下面用到的是教练的一个工具，叫度量尺，把一些非常抽象的状态，通过度量的方式，感觉的方式去展示它。有点像医生问你疼不疼，你说疼。

医生问：“假设你的疼是10级，你现在是几级疼？”你说：“我现在是6级疼”，医生给你用完药以后，问你现在几级疼，你说我4级疼，说明医生给你使用的药有效。通过这种方式去诊断，去帮助团队，去启发团队思考，所以我当时也做了医生一样的诊断，我说：“这个任务卡片，满分10分的话你大概几分”，他说大概6分，接下来我没有继续问，本来应该会问：“你6分做到的是哪些？为什么可以达到6分？”，他自己直接说出了6~10分之间的差距，说：“456可能不太好，就是UI开发测试这部分有一些问题”。所以我问的都是开放式的问题，不会说yes或no，或者直接给建议。我会问，如果这两个问题可以解决，能够达到10分的目标吗？然后会问我们需要去怎么做，等等这种问题。

最后他说找到办法了，他自己去改进。所以这是教练的工作方式，教练会相信客户面对问题时，都是有积极的动机的，他给我发看板上的任务卡片时，一定是做过尝试或者思考的，他有意愿去解决这个问题。

第二个是教练有一个假设：客户相信客户是解决自己问题的专家，所以我们需要做的就是帮助他看到问题，让团队有办法去解决，所以这是我用到的一些团队方法，最后我还是会提供给他一些教科书式的，关于看板任务卡片的方法，仅供作为参考，每个团队的情况不太一样，所以敏捷是一种经验主义，我们就得去测试，去迭代。这是我们在单团队的一种教练的工作方式。

我发现在辅导团队的时候，基本上敏捷的一些方法用的会越来越少，可能百分之八十都在用教练的方式去支持团队，其他就是去激发团队，去找到答案。

所以我会在迭代的过程中用到一些个人教练的方式，包括去聆听，听到他问题背后的问题，然后去发问，去直接沟通给他反馈。帮助他看到一些问题，比如矛盾点，用一些教练工具做支撑，这就是我在单团队敏捷的时候会用到的一些方式。

到了项目群级别就会不一样了。我们如果去辅导一个项目群，大家用到的就是像一些safe、Less这样，或者是Scrum@Scale这些方式，都会有一些项目群前面的仪式，像计划同步评审回顾，让项目群能够对其目标识别依赖，让项目群去计算项目群的负载，识别项目群风险。

在项目层面，我也同样会像团队钟摆一样去看项目群背后人的方面如何去做，当然项目群层面我开始研究DevOps，因为我发现项目越大，如果工程实践做不好，包括代码做不好，确实敏捷的威力发挥不出来，所以DevOps是我在项目群研究中行的一个部分。

对于神的部分我有两个觉得很好用的方法：

第一个就是引导技术，特别是当我开项目群大会，例如引导计划会的时候，需要用到一些引导技术去设计工作坊，在面对项目和团队在一起遇到团队冲突的时候，如何保持引导者的状态，去将冲突变为团队学习的机会。当然也有一些比较重要的引导工具，例如世界咖啡、开放空间、焦点讨论，甚至会用到一些沙盘、隐喻的方式，用这些工具和方法去支持团队更好的开展项目群的敏捷实践活动。

在引导技术之后，我发现引导背后更多还是关注于目标，因为这个流程是我设计的，目标是我们跟团队一起确定的，我们还是关注于团队的事情方面。对于人的方面，我一直找不到很好的抓手去做人方面的事情。

有一次非常凑巧，我当时知道有团队教练这个说法，好像听到过。有一次我在机场遇到了徐东伟老师，我的ACP老师，当时我们在登机口聊了一个小时，他告诉我他正在学习团队教练，说这个领域的方法是辅导团队时非常有利的方法，所以当时我就开始留意了。后来在北京ICF（国际教练联盟）的国际教练周里，我看到曌乾组织教练，在做分享。经过各方比较，我就去学习了关于团队教练的部分，后来发现团队教练对于项目群的辅导确实给我产生的可以叫震撼，或者叫惊讶，或者叫惊喜，我发现了团队背后的某一些动能的东西，后面会有案例给大家介绍。因为在团队教练里，团队钟摆模型就是团队教练里面的一个工具，它会从研究“什么是一个团队”开始，然后去看团队的绩效模型以及团队教练的原则是什么，他和引导很像，甚至一度我都分不清引导和团队教练的区别是什么。

后来我发现其实也不用区别，他们之间和而不同，我只要达到目标就好。通过了解团队教练的一些原则，运用一些团队教练的工具，图片左边我列举了一些团队教练常见的工具，其实对于一个团队来说，信任是第一位的，所以团队教练开始之前先不做事情，他们先让团队打开，有一些像热椅子、空椅子这种方式去让团队看到自己的模式，这点非常有冲击力。不仅是教练提出来，团队成员也会说对方的模式是什么，建立团队信任，一旦有了信任之后，后面的事情好处理了。

例如创建愿景，我们的团队目标，团队要去哪里？团队的使命是什么？未来2~3年的目标定出战略焦点，团队在一起合作的规则是什么样的，如何开会？如何迭代？还有团队的章程，我之前学PMP的时候知道有项目章程，我现在才知道还有团队章程，团队章程会对以上使命、愿景、价值观、规则都做很详细的约定，以及团队的评估，还有团队的角色谈判、共识。有时候你会发现，我认为我在团队里担任的是这个角色，但是其他人不一定这么认为，这就是大象，所以通过团队教练的方式，让大家看到这些差异，并且达成一致，最后做出行动计划，因为团队教练不仅仅是让大家看到，不仅让大家知道，还要让大家做到，所以每次团队教练都会形成一项改进行动计划。

这个计划我们会让他们做为一项团队的内部用户故事，指定好负责人，设定好验收标准，预计完成日期。放到团队里，需要占团队的迭代产能。在我们下一次的团队教练时再一起去回顾学习，这些都是在团队教练里，在辅导项目群的时候，现在给我的一些支持，让我在项目群中能够看到团队的动力，它的动力来源和期待是什么？这是关于项目群背后的神。

我们看一下对于组织级，这个部分我目前还在整理，所以会介绍的简要一些。因为我目前也在做几个组织级的敏捷咨询项目，所以在这方面我还在整理研究还在重构，有一些我自己感觉还不太完善，所以这边把目前整理出来的，感觉还可以1.0版本贡献给大家。其他的内容在第2.0版本会拿出来分享。对于组织级敏捷这部分，目前safe在单团队和项目群里可操作性多一点，但是我发现SAFe在第三层（解决方案层以及组织级），点到为止，介绍的不是非常详细，可能也是我没有研究到，没有抓到要点，不如项目群这边感受这么深。

目前也在研究less和Scrum@Scale，最近也报了一个Scrum@Scale的课程，因为是 Scrum的创始人提出来的，我想了解一下他背后的依据，所以自己这边没有很好的方法，目前来说还处于探索阶段，我们现在跟客户在一起探索，包括我现在也在看一些cmmi的内容，因为我发现cmmi也是好东西，因为它确实提供了很多参考框架，我可以在上面去跟团队一起找到一个同样的对话的一个术语。

在组织级敏捷这边要考虑的事情好像已经不是方法层面了，可能考虑的是一些规范制度的内容。比如说我们到了客户那边，客户会让我们建立敏捷研发体系，会要求我们去约定敏捷的过程。敏捷研发体系的过程，比如说从需求到开发到测试到运维，以及会让我们去约定敏捷的角色分工，因为对于金融机构，目前做金融比较多，它会涉及到很多处室，例如需求管理部、pmo、开发、测试、安全、质量，特别是质量，这些部门它应该如何在敏捷研发体系下去工作，甚至有的处室会担心我上了敏捷之后，处室的工作会不会被替代了，他们会有生存危机，后来发现其实他们会更有价值的事情去做。

比如说需求管理的部门，他们可以去做业务po教练，因为他们对需求了解的太清楚了。比如说质量，我们可能让他去设计一些DevOps里面的质量门禁等等，所以这些我们都会去考虑。我们也在做一些敏捷度量，设计指标。质量对于敏捷度量这方面太专业了，各种指标的体系，数据源，计算公式，所以我们在组织级里考虑的更多的是敏捷研发体系、过程、角色以及一些实践。

同时还有一点很关键就是敏捷文化，敏捷文化很虚，落地下来几件可操作的事情就是，如何建立赋能中心去培训项目组，如何去开展内部的敏捷交流活动，如何做一些敏捷企业的宣传，例如做一些海报，做写一些推文，建立跨职能的社区，这都是敏捷文化要做的一些事情。还有建知识库，另外在组织级里还要去建立敏捷平台，这个平台不仅仅是持续交付的流水线，还要和整个研发管理系统结合在一起，所以要打通端到端的，从需求到后面的整个的部分，所以流水线会集成很多系统，还要考虑外部接口，这些都是组织级敏捷，从事情层面要做的一些“形”。具体大家可以去研究关于组织级敏捷相关的一些方法实践。

我们来说一下组织级敏捷背后的神，我们在谈组织级敏捷的时候，发现其实组织级敏捷背后有两个神，一个是我们组织级敏捷项目的心，通常组织级敏捷项目是由高管发起的，要么可能是IT部的老大或者是一些项目管理部的老大，我们习惯上去就直接谈一些敏捷的过程体系、实践、文化、平台、度量、敏捷转型计划。后来发现其实高管他们自己有内部深层次的需求，在这个过程中用到的一个方式就是高管教练，我们会用高管教练的方式去和他聊。

包括目前的高管，现在的发起人，他现在的心智模式，他的关注点在哪里，他的思考模式是什么样的，会关注到这一层面。然后我们跟他调频之后再沟通，你会发现他会觉得你懂他，所以接下来他会把他很多深层次的需求，跟你说出来，然后我们再去设计，组织级敏捷就会方向更明确，我们会定期向高管问一个问题，我们现在的组织级敏捷项目是否还在正确的方向上？我们目前可能会有哪些阻碍？等等会和他去聊这些事情。

其实组织级敏捷现在慢慢的用组织教练的方式去设计了，包括去做调研设计，去做一些团队组织教练的工作法，组织教练会用到一些刚才讲到的单团队教练，用到个人教练、也会用到团队教练。在这个过程中我们会去探索团队和组织的意向是什么。我们当时在一个银行曾经组织过将近10个处室一起来去做这种研发流程的梳理。当时也提前梳理了大家对于目前研发流程的一些看法，用到了一些组织教练的方式。

我们再去做设计，现在还会考虑更深层次的一些内容，比如说做二次启动，一般项目开了启动会之后，团队一定会走到U底，我发现组织级敏捷项目最后会走一个u型，他会走到U底的时可能会遇到一些障碍，有的障碍是事情方面的障碍，有的是人方面的障碍，对于人方面的障碍，还需要做一个二次启动，我们会再做一次启动，跟大家去看我们的方向，跟团队一起去聊。所以这个地方组织级教练这边还是有很多的方式可以支持到组织级敏捷。

这方面我们结合起来之后会发现比较稳妥，现在仍然在尝试。所以这里就不多说了，因为更多内容还在总结。这是关于组织级敏捷下面的形和神。

敏捷转型中的团队教练

我们接下来看刚才讲的这些内容，我画了一个敏捷的全景图，这是我目前所关注和涉及到的领域。从单团队、项目群和组织级背后的形与神的部分，我就介绍到这里，接下来介绍案例，刚才讲的可能会比较虚一点，如果没有接受过一些教练的培训的话，或者是这种训练，那么可能理解起来会有些困难。

我自己接触教练，是自己亲身体验过一次。当时在工作坊有一个教练让我们每人准备一个你觉得最有难度，最有挑战，价值最大的话题。接下来他通过一种形式让我们工作坊参与者之间相互支持，这个话题竟然被梳理出来了，当时我很震惊。然后我就开始去研究，我之前在杭州的敏捷社区曾做过一次焦点解决教练的分享，也是用这种方式让大家去梳理，大家觉得很有价值的话题让大家去支持，并且在这个过程中体验教练的工作方式。所以后面有机会可以组织一次这样的分享，刚才Bob也谈到说，我们后期还会做一些类似于线下互动的分享，我没有尝试过在线如何去做教练工作坊，有机会可以尝试。

有机会我们教练这边再去做一些体验，今天可能只是让大家见到知道，因为每次培训都有一些目标的，从知道到理解到应用到最后创新，我们这次的分享只能到知道，相当于埋一个种子，希望大家未来看到教练能够去尝试一下，因为目前确实教练市场鱼龙混杂，还有身心灵，我也去参加过，所以对教练有误解也是正常的，其实教练是一个还蛮成熟的领域，当然也需要去甄别。

敏捷团队教练案例

我们来介绍案例，案例的内容可能是各位敏捷伙伴感受最深刻的。

案例我会介绍目前正在辅导的一个公司的产品研发中心的规模化敏捷项目，研发中心有4个项目群，每个项目群都是一个产品条线。这也是ToB端的，有4个产品方向，然后有14个产品，团队成员大概在200~300，这个是我们第一次PI计划会的场景。我们整个项目目前是想经过6个PI来完成。采用的是守破离的方式。

这6个PI的安排跟大家分享一下，第一个PI主要是体验为主，当时是在12月份启动，12月1号到31号，主要做的事情是导入敏捷事件，建立敏捷场域，建立敏捷规范。我们当时想预留2~3个PI来去固化，还是守，先让大家去固化，先固化再优化，所以先固化。后期由于疫情，中间这一两个月我们就只能焦急的等待，因为没法大家集中在一起，疫情对于PI计划会是一个巨大的打击，因为PI计划会是大房间，要求全员的核心人员参加，各团队参加，和国家因为疫情提出的少聚会少出门有很大的冲突，所以我们推迟了。

当时我们开始第二个PI主要做第二个阶段：固化阶段，一般做两个PI主要做的是形成团队规则，因为之前导入的时间都是标准范式，团队需要在做的过程中不断的去理出DoD、DoR，还有一些敏捷的规范、团队规则。同时我们开始准备收集一些团队的数据，像团队的速度、产能、负载这些内容，同时开展团队学习，这是第2、第3个迭代要做的。

到了第4个PI，通常到了破的阶段，这个阶段我们目前正在做，用到的就是团队教练，我们目前破的阶段是五一这段时间，之后我们开始去迭代敏捷实践，这些破不是我们告诉团队应该怎么破，而是团队自己去通过数据，通过回顾学习来定出破局点，从哪个地方去改善，并且我们在执行过程中整理完善了敏捷的规范。计划在下个月做进化阶段，这个时候会开敏捷的专题工作坊，去专题改进，并且会建立一些敏捷度量。

5月份我们定了很多专题，6月份我们会逐一专题突破。这个项目大概在7月份我们就准备结束，这个时候教练会做离场准备？因为那个时候我们会建立起团队自我学习的机制，在这个当中团队动能很重要，大家敢不敢说，愿不愿意说，这些都是需要考虑的内容。这个是项目的一个背景。

接下来我们来看一下目前我们是如何破的，如何让敏捷和教练相得益彰？如何破，我们做的是深入团队开展团队教练，当时我们做了5场的团队教练，第一场特别有挑战，因为第一场团队全在西安，所以当时我们只能做纯远程的，当时架了两个机位，架两个手机让大家去做。然后我们在远程能看到大家，听到大家，这样去远程引导，我们被投在电脑上，现场发出引导指令，然后让他们做一些开放讨论，一对一讨论，小组讨论等等。

后面剩下的几场刚好他们几个核心产品骨干全在研发中心，我们就可以现场去引导。所以我们就开始去做团队教练，团队教练怎么做呢？大家可以看到团队钟摆，我们在团队钟摆的基础上做一些调研问卷，从事情层面和人的层面，让团队先自评，然后我们根据团队教练里面的一些工具（比如说团队有效性测评工具）去看他们的区间在哪里。

我们开始跟大家介绍，我们前期1~2个迭代，更多关注在任务运作层面，社交氛围层面，我们会从破的阶段开始引入教练部分，教练更多关注于人。敏捷也关注人，但是事情稍稍多一些。所以我们来判断团队现在在哪个钟摆区，然后去识别。这个是我当时发的问卷，当时做了一些征集，有的团队填的人比较多有的比较少，当时收集的98份，这个是没关系的，仅供我们参考。

所以当时我标出来，每个团队在团队教练之前会把这些写在纸上，比如说我对某个团队说，我们目前收到了你们15个人的反馈问卷，其中这15个人对于我们目前的任务运作评分在45分，根据我们的经验值，根据一些调查和测评，45分以上在绿色区域目前还是ok的。其中大家觉得满意度和凝聚力都比较高，达到了49分。接下来就是团队教练，去和大家一起探索我们和56分之间的差距在哪里。

接下去开始我们的团队教练对话，去找到这些破的点。这是团队教练的一些工具，比如开鸡尾酒会，让大家介绍自己在这个团队里面我是谁以及我的动力来源、我的期待，团队教练和大家在沟通中，是非常走心的一个环节，能看到大家对于技术的热爱，对于产品的热爱。当然有的人动力非常实际，除了情怀产品之外，还有一些钱这类，大家都会提出来。

刚才讲到团队大象这个隐喻，我们就和大家一起做关于团队大象的工作坊，大家可以看到这是我们当时的内容。

大象方面，我们第一行贴的都是大象，第二行我们用一种团队教练的方式让大家能够说出来，匿名，然后畅所欲言。另外除了说出我们团队有哪些大象，还要说出具体的场景是什么？因为有的大象非常粗，比如角色分工不清楚，有个技术leader他没有执行好技术leader应该做的事情，他扑在一线在coding，在修bug，他没有制定一些技术规范等等。这些我们都会还原成具体的场景，以及他的建议是什么，比如有人说建议这种bug团队自己去消化掉，这样leader能够腾出精力来为团队定出一些开发规范，技术规范等等这些内容。所以不仅要说大象，还要说建议是什么？

最后大家挑一个大象，大家可以看到我们上面投票了，画“正”字，所有参加团队教练的成员去找出我们的第一个行动点，在两周或者是2~4周，我们再做一次回顾，这是当时的样子。

团队教练很看重人，大家可以看到这张照片，右上角这个是当时有一个团队成员被孤立了，我们当时要求一对一，所有人相互介绍你的来源，你的动力是什么，你的期待是什么。有一个人落单了，当时现场就让大家停，团队教练有一个常规动作就是“停”，“看”我们接下来可以怎么选择，上面这张图片，其实大家选过了，我们当时让大家再开展一次，这个团队成员就会被照顾到了，所以让团队也做了一次学习，让大家知道：一对一他们是单数，所以有人落单，这个人如何处理，他们可以三个人分享。通过这个来让大家去创造学习。

团队教练像镜子一样，在团队里面就像镜子，随时让大家“停”、“看”。这个是投完票之后，我们把改进事项，一起录成一个issue，然后在里面定出我们的行动项，我们的目标是什么，我们的验收标准是什么？

如果去做这项改进，可能会有哪些障碍和应对，这都是团队教练的标准问句，只是把它变成了这种格式的模板来填。这是我们5月20号做的，我们2~4周之后会再去团队里面看一看，大家是否落实了，如果没有做到发生了什么？我们团队会有哪些还没有被识别到的内容，我们再去学习。

这个就是关于PI目标的这一改进，这是我们团队的一些做法。这个是我们做完之后，我们当时做的底，这是我们的第一轮团队教练的反馈，当时收集了团队里面的问题，这是大家的反馈，我红框框出来，是觉得特别有感触的。

有人说日常问题都存在，只是没有提出来，这就是团队里的大象了。第二个最大的感受，就是每个人都提出了自己的想法，团队教练是让每个人都发出声音，让大家都听到，如果没有人发声，团队教练会去关注。我们观察到你在这个团队里面刚才发言比较少，你可以分享一下你的想法吗，团队说我最开始不知道内容，也没啥预期，但是收获颇丰，连团队教练也不知道接下来会发生什么，因为团队教练没有预设，他只是带着中立的态度，像镜子一样让团队照到自己团队里面可以改进的点。还有团队成员说留意工作中发生的事情，有这种会议的时候可以很好的去开展一些内容，他们产生留意，这就是我们这次团队教练也是希望达到的留意，就是觉察的开始，团队接下来就会更多的去留意，他们的觉察度会越来越高。

有的团队，我们问他们的收获或者期待，他们说听到一些特别的声音，比如说加班，有团队会提出：晚8点，有个大象是团队成员好像都等到8点下班，就算自己没有事情也等到8点，怎么办？大家都提出来，比如说到了5:30做一次check，如果大家没有事情就按时下班，其他人如果有事情就去做，需要支持的就留下来做，所以这些大象大家都看到了，由于某种原因集体沉默，团队教练就把这些事情让大家看到，所以这又是一个大象。还有借助这样的场合，大家似乎距离拉近了。

我们第二天去看团队的站会的时候，有的敏捷教练反馈第二天站会，发现大家站得更近了，效率很高，我们这次团队教练大概两个小时，有的大象比较多，可能到三个小时，希望他们觉得效率很高，并且短期内成效显著，其实我们两个小时的产出足以让团队去消化两周，我们两周之后再去看，应该大家还会有新的发现。这就是团队教练之后团队成员的反馈。

总结

本次分享关于敏捷和教练相得益彰就到这里。总结一下：今天主要是分享团队的人和事，以及团队里面在敏捷转型当中最头疼的大象集体沉默现象。

然后我们分享了从单团队多团队，项目群以及组织级项目管理或者敏捷部分，它的形与神，以及在每一层级我们用到的教练方法，然后以及给大家介绍的一些我们在一个产品中心，一个组织级的中心去做的这种团队教练的实践，希望给大家一些参考，我们还在摸索，因为发现还有一些地方可以提高，而且这些提高点都来自于团队，是我们教练团队和我们的项目团队大家一起去完成的。在团队教练里面意愿度是第一位的，如果团队没有意愿度，团队教练是没法开展的。所以我们会去关注这部分内容。

今天的分享就到这里，希望后面有机会再跟大家一起分享。这是我的个人的微信和公众号，也希望更多小伙伴可以交流。公众号里面刚才讲到的敏捷全景图放在里面，如果大家想要原图的话，也可以在里面去下载。

另外，也想听听大家的反馈，因为今天整理比较仓促，把之前敏捷实践过程中的一些要点杂糅在一起，希望听到你的反馈，你觉得喜欢的或者不喜欢希望改进的，可以以匿名或者实名的形式反馈给我，以便我们持续迭代。好的，今天的分享就到这里了。谢谢大家。

内容来源：敏捷+社区线上直播011期，《敏捷与教练相得益彰》分享实录

分享者：胡俊（小顽童）

点击下方，第一时间了解华为云新鲜技术~

华为云博客_大数据博客_AI博客_云计算博客_开发者中心-华为云