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