你好，我是宋宁。
从今天这一节课开始，我要给你讲讲具体怎么来推进敏捷。我会结合案例，用四节课的时间介绍推进敏捷的三大步骤：评估诊断、团队敏捷试点、大规模推广。今天，我们先来学习第一步：评估诊断。
在我做咨询的过程中，一开始经常会碰到下面这些问题：
- 有很多人一头雾水，跑过来问我：“老师，我们现在准备开始做敏捷实践了，可是从哪里做起呢？敏捷那么多方法，我要先用哪个呢？”
- 还有的人说：“敏捷很好，因此我要以它为标准，所有项目都要遵循这个标准。”
- 而有的人在敏捷面前踌躇不前：“敏捷对人的要求很高，我们现在还不具备做敏捷的条件，等条件成熟了再说吧。”
其实，无论是想做敏捷但不知道怎么去选择方法，还是不管三七二十一直接套用成熟的实践经验，抑或以自己不具备条件为借口犹犹豫豫不敢去做，这些问题反映的都是大家没有做前期的评估诊断，因此不了解自己的现状，不清楚自己的痛点，不知道从哪里下手去推进敏捷。
就像医生在看病之前需要患者先做各种相关检查，有了检查结果，医生才好对症下药，敏捷实践亦是如此。在我们决定推进敏捷前，第一步就要评估企业目前的整体情况是什么样的，它在文化、实践、工具等维度上，已经达到了什么程度？它有什么痛点亟待解决？
只有把这个第一步做好，对自身的情况有个清晰的认识，我们才能针对自身的问题找到适合自己的敏捷方法。
那么，如何做敏捷推进前的评估诊断呢？我想分为两部分来谈，首先从理论上说说做评估诊断的方法步骤，然后以一个案例具体说明在实践中到底应该怎么做。
评估诊断的方法步骤
从理论上来说，我们通常采用“四步法”来做评估诊断。
第一步：挑选代表性项目。这一步类似抽样调查中的抽样，在做评估前你需要在企业里选一些具有代表性的项目，可以是业务上有代表性，也可以是研发模式上有代表性。如果企业的项目囊括了大、中、小型项目，那么我建议你从这三类项目中各选一个来进行评估，这样你在深入评估项目时，得到的结果才能更真实地反映企业现状。
第二步：访谈评估。在划定了需要评估的项目范围后，你需要对这些项目中的团队成员进行访谈，从流程、组织、人员技能、度量和技术等维度，对项目进行深度评估。这一步的目的是通过访谈有意识地探查项目的痛点。
第三步：制定转型计划。你需要根据访谈评估中发现的具体问题和痛点，做推进敏捷的计划，以形成后面转型工作的蓝图。痛点不同，计划也不同，一定要有针对性地做计划方案。比如说团队的主要问题是跨部门、跨团队沟通协作不畅，那在计划中就要优先考虑团队组织的问题，必要时再做组织变革；如果团队的问题集中在从开发完成到上线前这一阶段，那么在计划中就要优先考虑建设DevOps流水线。
第四步：沟通。在访谈评估和制定计划后，在正式进行敏捷实践前，你需要与相关人员，比如说团队成员、团队主管，以及推进敏捷的内部负责人等，沟通评估结果和相应计划，以便整个团队达成一致意见。如果不沟通，大家对目前的现状理解不一致，那在互相配合上就会有偏差；更严重的是，如果沟通得不好，大家说不定还会互相拆台，这样再好的计划也是没法真正落地的。
此外，关于由谁来做评估诊断，你也要注意一下。以上四个步骤，如果你请了有经验的咨询师来做，那只需要配合他们选好项目，并安排相关成员参加访谈即可。如果你没有请咨询师，也可以请公司里与研发团队平行的部门如PMO（项目管理中心）等部门，或内部的敏捷教练来负责推进，但这些人员一定要了解敏捷，了解业界的敏捷实践情况，参加过相关培训。否则的话，不仅不能很好地发现问题和痛点，还可能使评估结果不够专业，难以服众。
上面这四点，就是评估诊断在理论上行得通的“四步法”，接下来我就以一个我之前做过的案例，来具体说明下如何做好评估诊断。
评估诊断案例分析
先说一下这个案例的背景：这是一家国有银行，在找我去帮忙评估之前已经做了一些敏捷方面的尝试，而且，内部做尝试的那几个团队自以为做得还不错。现在他们计划向更多团队推广敏捷，在此之前想让我去检查一下他们目前的敏捷成熟度，并让我帮忙做后续的推广计划。
接到这个任务以后，我跟负责接洽的部门简单沟通了下，然后选择了他们敏捷推进情况不一样的两种项目：一种是几个已经做了敏捷尝试的项目，另一种是几个没有做过任何敏捷活动的项目。之所以这样选择，是因为只有把这两种不同的项目都覆盖到，才能更好地看清这个公司的研发现状。
在选定好代表项目后，我便开始访谈评估。我把这些项目中的团队成员分成不同角色，例如开发、测试、运维、需求、项目管理人员等等，依次去和他们访谈，这主要是为了全面了解项目的研发流程，了解每个角色在研发活动中的工作情况，也了解各个角色之间的协作情况。
另外我还去他们做敏捷尝试的团队里做了实地观察，观察他们的站立会议，了解他们的需求管理、开发测试过程、上线过程。最后我有了以下这3个发现。
首先，虽然这些团队进行了敏捷尝试，但成熟度并不高，如果用5分制（1为最低，5为最高）给他们打分，这些团队的实践水平也就是在1和2之间。而且他们的管理实践推进不力，技术实践压根也没有推进。
比如，他们有一个研发团队是由5个不到9人的小Scrum团队组成的，每个Scrum团队理应各自开站立会议，这样每个团队都有一个自己的看板，这样会很方便。但他们却把5个小团队的看板放到了一块板子上，这就使同一块看板上每个团队的区域都很局促，所有的卡片都叠在了一起；这也导致每次开站立会议时，大家不只要排队，每个人还得在一堆卡片里找自己负责的卡片，既浪费时间又不够方便。另外，由于看板上所有的卡片都叠在一起，也不利于大家及时发现问题。
所以，这一系列安排都使他们的站立会议和看板没有起到提高透明度、提高协作水平的作用，这样的会议只是一个形式上的会议。
其次，该企业未推进敏捷的团队现在采用的是瀑布模式，对敏捷了解甚少。这是因为这个企业当初号召大家做敏捷时，遵循的是自愿原则，并未统一做敏捷宣讲和进一步培训，想尝试的团队就自己去学习，没有尝试的团队也就从没有主动去了解敏捷的益处，这样即便团队有了痛点，也意识不到可以用敏捷方法去解决。
所以我在访谈过程中，发现有很多人只是听过“敏捷”这个词，至于它的含义、研发管理用了它后会有什么新变化，以及到底应该怎么去做它，他们是完全没有概念的。
最后，这些团队在跨团队交流方面有很大的障碍，这表现在业务人员与开发测试团队隔离，目标不统一，参与敏捷的投入度明显不够。他们只是在开发测试团队里做了一些敏捷实践，而并没有把业务人员拉进来；团队也没有相应的制度，所以业务人员在这场敏捷活动中是想来就来、想走就走，毫无纪律性可言。另外，业务人员还是像过去一样，认为提完需求，自己的工作就结束了，至于做不做得出来，是开发测试团队的事情。
根据上面的评估结果，我在分析问题后，尝试寻找解决方案。
第一个问题的表象是大家的敏捷推进做得不够好，还有些野路子的样子，但根本原因其实是缺乏专业的指导，并不了解敏捷实践背后的意义。
针对这个问题我给出的方案是：对已经推进敏捷的团队，重新检视他们的实践情况，固化已经做得很好的地方。
第二个问题实质就是未推进敏捷的团队对敏捷没有概念，也不知道怎么去做。
针对这个问题，我给出了两步走的方案。第一步，先解决认知问题，对未推进敏捷的团队进行专业的基础知识培训；第二步，选择试点团队示范怎么做。可以将团队拆分成10人以内的全功能小团队，根据项目的痛点做相应试点计划，推进后定期做总结回顾，并邀请试点团队分享经验。
最后一个问题，其实也可以拆分成两个子问题。一个子问题是团队在跨团队交流方面有很大的障碍，这本质上是个系统性的问题，所以需要建立相应的机制。另一个子问题是团队虽然已经导入了敏捷，但并没有将业务人员纳入到其中，业务人员的工作习惯和工作模式并没有发生很大的改变。针对这个问题，我给出的方案是提出业务与研发团队的组织变革，建立产品负责人制度。
现在，我们把上面每个解决方案加上具体实施时间，就形成了半年的短期计划：
- 1月～4月：选择试点团队示范敏捷实践；
- 5月：推动跨团队交流，建立相应的机制；
- 5～6月：建立产品负责人制度。
看到这里，你也许会问，为什么是短期计划而不是长期计划呢？
这是因为在敏捷中，计划的制定是渐进明细的，这也就是说，近期的计划可以具体到可实施的细节，而远期的计划则是粗略的，所以更长远的计划我们并未在评估和诊断结束之后马上就开始做。此外，因为不清楚敏捷在这个公司里的试验效果如何，所以我们还是要先做个短期试验，由试点团队试点之后，根据实施的情况做回顾和总结，再推导出进一步的长期计划。
前期访谈结束和短期计划制定完成后，我便开始和这些团队沟通。那么问题来了，这个企业的评估结果不是很乐观，我该怎么和团队沟通，才能让他们既理解自己的现状，又不失去信心呢？
经过思考，我决定不拿“满分是5分，而你们只能得1.5分”这样的量化数字给他们看，这样对他们的冲击太大。我在发现（finding）描述里，先列出了一系列的正向发现（positive findings），紧接着在旁边又列了一些负向发现（negative findings），并且告诉他们对于每一则条目来说，好的标准是什么，这样他们就会自己感觉到自己的不足和差距。然后我再讲怎样做才能弥补这些不足，并给出我推荐的时间表，让大家看看是否合理。这样循序渐进，后面我在和团队沟通具体计划时，就顺畅了很多。
另外，前面我们讲的是一个公司做敏捷转型的案例，那如果是一个项目组自己想尝试敏捷，是否需要做前期的评估呢？我是建议谁也做一下，因为项目组的现状和痛点也是需要在评估诊断中来分析的。只不过因为只有一个项目，不存在代表性项目的问题，所以四步法里的第一步是可以省略的，只做其它三步就可以了。
总结
现在我来总结一下今天的课程内容，希望能对你有所帮助。
推进敏捷的第一步是评估诊断，其目的是在转型之前，让企业或者团队了解自己的现状、存在的问题和痛点。采用的方法是四步法：选定代表性项目、访谈评估、制定转型计划和沟通。
你要注意的是，评估诊断的目的是为了解自己的现状是什么，了解自己的痛点在哪里，并针对这些问题和痛点，结合短期要达成的目标，找到解决方案，制定合理的计划。也可以说，我们引进敏捷就是为了解决痛点。
目前有很多公司，他们之所以没有把敏捷做好，很大一部分原因就是他们在推进敏捷前，不对自身情况加以评估，直接套用成熟的实践方法，却不管这些方法适不适合自己，结果就像医生看病不问病因就直接开方抓药一样，药不对症，花了很大力气治病却没有收到好的效果，得不偿失。所以我建议你在决定做敏捷实践之前，一定不要怕麻烦，要先对自己的现状做细致的评估和诊断，之后再针对具体问题使用适合自己的敏捷实践方法，这样你的敏捷推进就迈出了成功的第一步。
思考题
看了今天的文章，你是不是已经跃跃欲试了呢？课程最后，我想请你结合今天的内容和自己的实际情况思考一下，如果让你来牵头推进敏捷，你会怎样迈出第一步呢？
我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。
精选留言
2020-01-10 06:25:25
评估诊断这个还是比较困难的，有点像是老中医的望闻问切。
挑选代表性的项目相对容易一些，内部人士更为熟悉，挑选并不困难。但是可能存在，把最好的项目拿出来“秀”，或者把最差的项目拿出来“示威”的情况。除了按项目大小挑选，也可从人员能力、项目进展等角度来挑选。有一个疑问，就是进展程度不同的项目如何区别对待？
访谈评估我觉的是最难的部分，因为虽然可以从几个维度来考察，但是没有办法量化，只能依赖敏捷顾问的个人经验。并且，在这一部分应该可以了解到团队成员的技术水平和个人特质，也需要在转型的过程中考虑。
制定转型计划这一步和前面的步骤紧密相连，同样依赖敏捷教练的经验，并且在执行的过程中也可能需要手把手的指导。
沟通并达成共识，如果有相关干系人没有办法说服怎么办?整个团队达成一致意见，这个也并不容易。如果是由上层试压，那么在执行中就会走样；如果上层不支持，那么压根没法继续。敏捷教练也不容易。在层级相对严格的单位，可能取得领导的认可，更为重要。前一段时间，好像是华为在做敏捷转型吧，似乎就有大老板喊话来着。
我觉的一般的公司推进敏捷转型，还是需要依靠敏捷教练；即使内部员工参加了敏捷培训，其实也很难迅速扮演教练或者顾问的角色。通过评估诊断，找到痛点，然后依据计划，逐步推进，让相关干系人体验到敏捷带来的好处，这样才有可能顺利的推进。
2020-01-08 08:53:21
2020-01-07 14:57:54
但我们产品经理的疑惑常常是：
1.项目是哪个部门牵头的，牵头业务部门和技术团队是哪个
2.各系统的对接人是谁
3.技术对接方案如何确定
4.项目排期如何确定
5.测试方案和测试分工如何安排
6.上线顺序如何确定
在实施中，还经常遇到信息不回复和回复慢的各种问题。
学习敏捷，针对这些问题，能想到的改善方法
1.确定项目责任人和配合方，由责任人统一协调
2.组织项目组，公布所有项目相关事宜，各系统负责人，分工等
3.确立项目沟通机制，保证沟通效率
2020-03-22 08:28:23
2020-01-06 23:30:39
2020-01-12 22:22:56
2020-01-09 11:24:27
2020-12-08 20:28:25
2020-03-26 20:18:48
2020-01-15 21:28:16
首先，选择具有代表性的项目（我们已经在实践敏捷了，可以跳过这个步骤）
其次，需要找团队人员沟通，关注以下问题
目前团队在组织、文化、工具、技术方面是否适应目前的敏捷方法
团队对敏捷的认知，包括思想、原则和方法
敏捷实践中遇到的问题，或者痛点，可优化的地方
再次，制定敏捷推进计划，注意以下问题
明确
可行性
可度量
分阶段
最后，和团队成员沟通敏捷计划，如果有不一致，可能需要返回3修改机会，最终达成一致
注意方法
引导团队成员认同
2020-01-14 09:26:30
2025-01-09 18:03:12
2023-11-14 10:57:33
1、客户提的要求，我们在做的过程中，有什么原材料进不来的，或者哪里因为当前的技术做不到的，跟客户及时沟通，做出调整
2、产品提的需求，在开发的过程中，发现需求本身无法自解释，或者哪里因为当前的硬件资源或开发人员的技术不够二做不到的，都及时跟产品沟通，做出调整
3、如果在开发实施过程中，遇见任何不能按期交付的情况，及时跟自己的领导沟通，由领导出面或者领导出主意自己出面来沟通
我感觉这几点在日常工作中，应该是天经地义的，在某种程度上，也跟敏捷有点像
2022-11-25 18:32:11
2022-11-25 18:30:20
2022-11-25 18:29:51
2022-11-04 13:21:36
2022-07-30 20:34:52
2021-11-21 10:14:59
2021-08-29 21:23:16