你好，我是宋宁。从今天这一讲起，我要给你讲一下具体怎么推进敏捷，并结合案例，通过四讲来介绍推进敏捷所涉及的评估诊断、团队敏捷试点、大规模推广这三大步骤。今天，我们先来看推进敏捷的第一步：评估诊断。

在我做咨询的过程中，一开始经常会碰到以下这些问题：

  1. 有很多人一头雾水，跑过来问我：“老师，我们现在准备开始做敏捷实践了，可是从哪里开始呢？敏捷那么多方法，我要先用哪个呢？”
  2. 还有的人说：“敏捷很好，因此我要制定标准，所有项目都要遵循这个标准。”
  3. 而有的人在敏捷面前踌躇不前：“敏捷对人的要求很高，我们现在不具备条件做敏捷，等条件成熟了再说吧。”

其实，无论是想做敏捷但不知道怎么选择敏捷方法，还是不管三七二十一直接套用成熟的敏捷实践，抑或以自己不具备条件为借口犹犹豫豫不敢做敏捷，这些问题反映的都是他们没有做前期的评估诊断，因此不了解自己的现状，不清楚自己的痛点，不知道从哪里下手去推进敏捷。

就像医生看病之前需要患者做各种相关检查，有了检查结果，医生才好对症下药；敏捷亦是如此。在我们决定推进敏捷前，第一步就要评估企业目前的整体情况是什么样的，它在文化、实践、工具等维度上，已经达到了什么程度？它有什么痛点亟待解决？只有把这个第一步做好，对自身的情况有个清晰的认识，我们才能针对自身的问题找到适合自己的敏捷方法。

那么，如何做敏捷推进前的评估诊断呢？我想分为两部分来谈，首先从理论上说说做评估诊断的方法步骤，然后以一个案例具体说明评估诊断在实践中到底该怎么做。

评估诊断的方法步骤

从理论上来说，评估诊断通常采用“四步法”。

**第一步：挑选代表性项目。**这一步类似抽样调查中的抽样，在做评估前你需要在企业里选一些具有代表性的项目，这些项目可以是业务上有代表性，也可以是研发模式上有代表性。如果企业的项目囊括了大、中、小型项目，那么我建议你把大、中、小型项目各选一个来进行评估，这样我们在深入评估项目时，其结果才能更真实地反映企业现状。

**第二步：访谈评估。**在划定了需要评估的项目范围后，你需要对选定项目中的成员进行访谈，从流程、组织、人员技能、度量和技术等维度，对项目进行深度评估。这一步的目的是通过访谈有意识地询问和探查项目的痛点。

**第三步：制定转型计划。**你需要根据访谈评估中发现的具体问题和痛点，做推进敏捷的计划，以形成后面转型工作的蓝图。由于痛点不同，所以计划也不同，一定要有针对性地做计划方案。比如团队的主要问题表现在跨部门、跨团队沟通协作不畅上，那在敏捷计划中就要优先考虑团队组织的问题，必要时做组织变革；再比如团队的问题集中在从开发完成到上线前这一段，那么在计划中就要优先考虑建设 DevOps 流水线。

**第四步：沟通。**在访谈评估和制定计划后，在正式进行敏捷实践前，你需要与相关干系人，例如团队成员、团队主管，以及推进敏捷的内部负责人等，就评估结果和相应计划进行沟通，以便整个团队达成一致意见。如果不沟通，大家对目前的现状理解不一致，那在互相配合上就会有偏差；更严重的是，如果沟通得不好，大家说不定还会互相拆台，这样再好的计划也是是无法真正落地的。

此外，关于由谁来做评估诊断，你也要注意一下。以上四个步骤，如果你请了有经验的咨询师来做，那只需要配合他们选好项目，并安排相关员工参加访谈即可。如果你没有请咨询师，也可以请公司里与研发团队平行的部门如 PMO（项目管理中心）等部门，或内部的敏捷教练来负责推进，但这些进行评估诊断的人员一定要了解敏捷，了解业界的敏捷实施情况，参加过相关培训。否则，一是不能很好地发现问题和痛点，再就是做出来的评估不专业，不足以服众。

以上，我给你讲了评估诊断在理论上行得通的“推进四步法”，接下来我就以之前我做过的一个案例，来具体说明如何进行评估诊断。

评估诊断案例分析

先说一下这个案例的背景：这是一家国有银行，在找我去帮忙评估之前已经做了一些敏捷方面的尝试，而且，内部做敏捷尝试的那几个团队自以为做得还不错。现在他们计划向更多团队推广敏捷，在此之前想让我去检查一下他们目前的敏捷成熟度，并帮忙做后续的推广计划。

接到这个任务以后，我跟负责接洽的部门进行了简单沟通，然后选择了敏捷推进情况不一样的两种项目：一种是几个已经做了敏捷尝试的项目，另一种是几个没有做过任何敏捷活动的项目。之所以这样选择，是因为只有把这两种不同的项目都覆盖到，才能更好地看清公司的研发现状。

在选定好代表项目后，我便开始进行访谈评估。我把这些项目中的团队成员分成不同角色，例如开发、测试、运维、需求、项目管理人员等等，依次进行访谈，这主要是为了全面了解项目的研发流程，了解每个角色在研发活动中的工作情况，也了解各个角色之间的协作情况。

另外我还去他们做敏捷尝试的团队里做了实地观察，观察他们的站立会议，了解他们的需求管理、开发测试过程、上线过程等。最后我有了以下这 3 个发现。

**首先，虽然有些团队进行了敏捷尝试，但成熟度并不高，如果用 5 分制（1 为最低，5 为最高）给他们打分，这些团队的实践水平均介于 1 和 2 之间。**而且他们的管理实践推进不力，技术实践压根也没有推进。

比如，他们有一个研发团队是由 5 个不到 9 人的小 Scrum 团队组成，每个小 Scrum 团队理应各自开站立会议，这样每个团队有一个自己的看板会比较方便。但他们却把 5 个 Scrum 团队的看板放到了一块板子上，这就使得一块看板上每个团队的区域都很局促，所有的卡片都叠在了一起，这就导致开站立会议时，每个人都得在一堆卡片里找自己负责的卡片，既浪费时间又不够方便，也导致大家开站会时需要排队来开，时间上更加紧张。另外由于看板上所有的卡片都叠在一起，也不利于及时发现问题。

所以，这一系列安排都使他们的站立会议和看板没有发挥提高透明度、提高协作水平的作用，这样的会议只是一个形式上的会议。

其次，该企业未推进敏捷的团队现在采用的是瀑布模式，对敏捷了解甚少。这是因为企业当初号召做敏捷时遵循的是自愿原则，并未统一做敏捷宣讲和进一步培训，想尝试敏捷的团队就自己去学习尝试，没有尝试敏捷的团队也就从没有主动去了解敏捷的益处，这样即便团队有了痛点，也意识不到可以用敏捷方法来解决。

所以当我在访谈过程中，发现有很多人只是听过“敏捷”这个词，至于敏捷的含义、研发管理采纳敏捷后会有什么新变化，以及到底应该怎么做敏捷，他们是完全没有概念的。

**最后，团队在跨团队交流方面有很大的障碍，这表现在业务人员与开发测试团队隔离，目标不统一，且参与敏捷的投入度不够。**对于已经采纳敏捷的团队而言，他们只是在开发测试团队上做了一些敏捷实践，而并未将业务人员拉进来；团队也没有相应的制度，所以业务人员在敏捷活动中想来就来、想走就走，毫无纪律性可言。另外，业务人员还是像过去一样，认为提完需求，自己的工作就结束了，至于做不做得出来，是开发测试团队的事情，而不是想着大家一起把产品做出来，一起去为它的最终上线及推广效果负责。

根据上面的评估结果，我先对问题进行了分析和诊断，并尝试寻找解决方案。

第一个问题的表象是大家的敏捷推进做得不够好，还有些野路子的样子，但根本原因其实是缺乏专业的敏捷指导，只照猫画虎地做了敏捷实践却并不了解敏捷实践背后的意义，有一些问题明明可以靠技术实践解决，然而他们却并不了解怎么去推进。

针对这个问题我给出的方案是：对已经推进敏捷的团队，重新检视他们的敏捷实践，固化已经做得很好的地方，视情况推进技术实践。

第二个问题实质就是未推进敏捷的团队对敏捷没有认知，也不知道怎么去做。

针对这个问题，我给出了两步走的方案。第一步，先解决认知问题，对未推进敏捷的团队进行敏捷基础知识专业培训；第二步，选择试点团队示范怎么做。我建议，可以将团队分拆成 10 人以内的小团队，并建立全功能团队，根据项目的痛点做相应试点计划并推进试点，定期做总结回顾，并邀请试点团队分享经验。

最后一个问题，其实也可以拆分成两个子问题。一个子问题是团队在跨团队交流方面有很大的障碍，这本质上是个系统性的问题，所以需要建立相应的机制。另一个子问题是团队虽然已经导入了敏捷，但并没有将业务人员纳入到敏捷实践中，业务人员的工作习惯和工作模式并没有发生很大的改变。针对这个问题，我给出的方案是提请业务与研发团队的组织变革，建立产品负责人制度。

现在，我们把上面每个解决方案加上具体实施时间，就形成了半年的短期计划如下：

  1. 1 月～4 月：选择试点团队示范敏捷实践；
  2. 5 月：推动跨团队交流，建立跨团队交流机制；
  3. 5～6 月：建立产品负责人制度。

看到这里，你也许会问，为什么是短期计划而不是长期计划呢？

这是因为在敏捷中，计划的制定是渐进明细的，即近期的计划可以具体到可实施的细节，而远期的计划则是粗略的，所以更长远的计划我们并未在评估和诊断结束之后立即着手做。此外，因为不清楚敏捷在这个公司里的试验效果如何，所以我们决定先做个短期实验，由试点团队试点之后，根据实施的情况做回顾和总结，再推导出进一步推进敏捷的展望和长期计划。

前期访谈结束和短期计划完成以后，我便开始和这些团队沟通。那么问题来了，因为前面我们说过对于该企业而言，已经进行敏捷试水的团队自以为他们的敏捷做得已经很好，而经过我的评估诊断，他们离“很好”还有很大的差距，也就是说评估结果是不乐观的。那么我怎么和团队沟通，才能让他们既理解自己的现状，又不失去信心呢？

经过思考，我决定不拿“满分是 5 分，而你们只能得 1.5 分”这样的量化数字给他们看，这样对他们的冲击太大。我在发现（finding）描述里，先列出了一系列的正向发现（positive findings），紧接着在旁边又列了一些负向发现（negative findings），并且告诉他们对于每一则条目来说，好的标准是什么，这样他们就会感觉到自己的不足和差距。然后我再讲怎样做才能弥补这些不足，并给出我推荐的时间表，让大家看看是否合理。这样循序渐进，后面我再和团队沟通具体计划时，就顺畅了很多。

另外，前面我们讲的是一个公司做敏捷转型的案例，那如果是一个项目组自己想尝试敏捷，是否需要做前期的评估呢？我建议也做一下，因为项目组的现状和痛点也是需要在评估诊断中来分析的。只不过因为只有一个项目，不存在代表性项目的问题，所以四步法里的第一步可以省略，只做其它三步就可以了。

总结

结合上面的讲述，我想来总结一下，希望能对你有所帮助。

推进敏捷的第一步是评估诊断，其目的是在转型之前，让企业或者团队了解自己的现状、存在的问题和痛点。采用的方法是四步法：选定代表性项目、访谈评估、制定转型计划和沟通。

你要注意的是，我们评估诊断的目的是为了解自己的现状是什么，了解自己的痛点在哪里，并针对这些问题和痛点，结合短期要达成的目标，来找到解决方案，制定合理的计划。也可以说，我们引进敏捷就是为了解决痛点。

目前有很多公司，之所以没有把敏捷做好，很大一部分原因就是他们在推进敏捷前，不对自身情况加以评估，直接套用成熟的敏捷实践方法，却不管这些方法适不适合自己，结果就像医生看病不问病因就直接开方抓药一样，药不对症，花了很大力气治病却没有收到好的效果，得不偿失。所以我建议你在决定做敏捷实践之前，一定不要怕麻烦，要先对自己的现状做细致的评估和诊断，之后再针对具体问题使用适合自己的敏捷实践方法，这样你的敏捷推进就迈出了成功的第一步。

思考题

看了今天的文章，你是不是已经跃跃欲试了呢？我想请你结合今天的内容和自己的实际情况思考一下，如果让你来牵头推进敏捷，你会怎样迈出第一步呢？