|
|
# 03 | 评估诊断：成功迈出敏捷推进的第一步
|
|
|
|
|
|
你好，我是宋宁。
|
|
|
|
|
|
从今天这一节课开始，我要给你讲讲具体怎么来推进敏捷。我会结合案例，用四节课的时间介绍推进敏捷的三大步骤：评估诊断、团队敏捷试点、大规模推广。今天，我们先来学习第一步：评估诊断。
|
|
|
|
|
|
在我做咨询的过程中，一开始经常会碰到下面这些问题：
|
|
|
|
|
|
* 有很多人一头雾水，跑过来问我：“老师，我们现在准备开始做敏捷实践了，可是从哪里做起呢？敏捷那么多方法，我要先用哪个呢？”
|
|
|
* 还有的人说：“敏捷很好，因此我要以它为标准，所有项目都要遵循这个标准。”
|
|
|
* 而有的人在敏捷面前踌躇不前：“敏捷对人的要求很高，我们现在还不具备做敏捷的条件，等条件成熟了再说吧。”
|
|
|
|
|
|
其实，无论是想做敏捷但不知道怎么去选择方法，还是不管三七二十一直接套用成熟的实践经验，抑或以自己不具备条件为借口犹犹豫豫不敢去做，这些问题反映的都是大家没有做前期的评估诊断，因此不了解自己的现状，不清楚自己的痛点，不知道从哪里下手去推进敏捷。
|
|
|
|
|
|
就像医生在看病之前需要患者先做各种相关检查，有了检查结果，医生才好对症下药，敏捷实践亦是如此。在我们决定推进敏捷前，第一步就要评估企业目前的整体情况是什么样的，它在文化、实践、工具等维度上，已经达到了什么程度？它有什么痛点亟待解决？
|
|
|
|
|
|
**只有把这个第一步做好，对自身的情况有个清晰的认识，我们才能针对自身的问题找到适合自己的敏捷方法。**
|
|
|
|
|
|
那么，如何做敏捷推进前的评估诊断呢？我想分为两部分来谈，首先从理论上说说做评估诊断的方法步骤，然后以一个案例具体说明在实践中到底应该怎么做。
|
|
|
|
|
|
## 评估诊断的方法步骤
|
|
|
|
|
|
从理论上来说，我们通常采用“四步法”来做评估诊断。
|
|
|
|
|
|
**第一步：挑选代表性项目。**这一步类似抽样调查中的抽样，在做评估前你需要在企业里选一些具有代表性的项目，可以是业务上有代表性，也可以是研发模式上有代表性。如果企业的项目囊括了大、中、小型项目，那么我建议你从这三类项目中各选一个来进行评估，这样你在深入评估项目时，得到的结果才能更真实地反映企业现状。
|
|
|
|
|
|
**第二步：访谈评估。**在划定了需要评估的项目范围后，你需要对这些项目中的团队成员进行访谈，从流程、组织、人员技能、度量和技术等维度，对项目进行深度评估。这一步的目的是通过访谈有意识地探查项目的痛点。
|
|
|
|
|
|
**第三步：制定转型计划。**你需要根据访谈评估中发现的具体问题和痛点，做推进敏捷的计划，以形成后面转型工作的蓝图。痛点不同，计划也不同，一定要有针对性地做计划方案。比如说团队的主要问题是跨部门、跨团队沟通协作不畅，那在计划中就要优先考虑团队组织的问题，必要时再做组织变革；如果团队的问题集中在从开发完成到上线前这一阶段，那么在计划中就要优先考虑建设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），并且告诉他们对于每一则条目来说，好的标准是什么，这样他们就会自己感觉到自己的不足和差距。然后我再讲怎样做才能弥补这些不足，并给出我推荐的时间表，让大家看看是否合理。这样循序渐进，后面我在和团队沟通具体计划时，就顺畅了很多。
|
|
|
|
|
|
另外，前面我们讲的是一个公司做敏捷转型的案例，那如果是一个项目组自己想尝试敏捷，是否需要做前期的评估呢？我是建议谁也做一下，因为项目组的现状和痛点也是需要在评估诊断中来分析的。只不过因为只有一个项目，不存在代表性项目的问题，所以四步法里的第一步是可以省略的，只做其它三步就可以了。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
现在我来总结一下今天的课程内容，希望能对你有所帮助。
|
|
|
|
|
|
推进敏捷的第一步是评估诊断，其目的是在转型之前，让企业或者团队了解自己的现状、存在的问题和痛点。采用的方法是四步法：选定代表性项目、访谈评估、制定转型计划和沟通。
|
|
|
|
|
|
你要注意的是，评估诊断的目的是为了解自己的现状是什么，了解自己的痛点在哪里，并针对这些问题和痛点，结合短期要达成的目标，找到解决方案，制定合理的计划。也可以说，我们引进敏捷就是为了解决痛点。
|
|
|
|
|
|
目前有很多公司，他们之所以没有把敏捷做好，很大一部分原因就是他们在推进敏捷前，不对自身情况加以评估，直接套用成熟的实践方法，却不管这些方法适不适合自己，结果就像医生看病不问病因就直接开方抓药一样，药不对症，花了很大力气治病却没有收到好的效果，得不偿失。所以我建议你在决定做敏捷实践之前，一定不要怕麻烦，要先对自己的现状做细致的评估和诊断，之后再针对具体问题使用适合自己的敏捷实践方法，这样你的敏捷推进就迈出了成功的第一步。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
看了今天的文章，你是不是已经跃跃欲试了呢？课程最后，我想请你结合今天的内容和自己的实际情况思考一下，如果让你来牵头推进敏捷，你会怎样迈出第一步呢？
|
|
|
|
|
|
我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。
|
|
|
|