03 | 评估诊断：成功迈出敏捷推进的第一步

Jan 6, 2020

03 | 评估诊断：成功迈出敏捷推进的第一步-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

03 | 评估诊断：成功迈出敏捷推进的第一步

2020-01-06 宋宁来自北京

《说透敏捷》

课程介绍



讲述：宋宁

时长17:19大小13.87M



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

分享给需要的人，Ta购买本课程，你将得9元

生成海报并分享

赞 14

提建议

02 | 老生常谈：你真的知道敏捷到底是什么吗？

04 | 团队试点（一）：让你的敏捷实践“事半功倍”

 写留言

精选留言(35)

escray
2020-01-10
开玩笑的讲，如果让我来牵头推进敏捷，那么首先就请专栏作者来做一次宣讲，然后再请专业的敏捷顾问来帮助实施。一方面，外来的和尚好念经，敏捷转型最好又体系之外的人来牵头，可以避免不必要的内部矛盾；另一方面，专业的敏捷教练显然更有转型经验，也更具说服力，内部也可以借此更快的培养出内部敏捷教练。评估诊断这个还是比较困难的，有点像是老中医的望闻问切。挑选代表性的项目相对容易一些，内部人士更为熟悉，挑选并不困难。但是可能存在，把最好的项目拿出来“秀”，或者把最差的项目拿出来“示威”的情况。除了按项目大小挑选，也可从人员能力、项目进展等角度来挑选。有一个疑问，就是进展程度不同的项目如何区别对待？访谈评估我觉的是最难的部分，因为虽然可以从几个维度来考察，但是没有办法量化，只能依赖敏捷顾问的个人经验。并且，在这一部分应该可以了解到团队成员的技术水平和个人特质，也需要在转型的过程中考虑。制定转型计划这一步和前面的步骤紧密相连，同样依赖敏捷教练的经验，并且在执行的过程中也可能需要手把手的指导。沟通并达成共识，如果有相关干系人没有办法说服怎么办?整个团队达成一致意见，这个也并不容易。如果是由上层试压，那么在执行中就会走样；如果上层不支持，那么压根没法继续。敏捷教练也不容易。在层级相对严格的单位，可能取得领导的认可，更为重要。前一段时间，好像是华为在做敏捷转型吧，似乎就有大老板喊话来着。我觉的一般的公司推进敏捷转型，还是需要依靠敏捷教练；即使内部员工参加了敏捷培训，其实也很难迅速扮演教练或者顾问的角色。通过评估诊断，找到痛点，然后依据计划，逐步推进，让相关干系人体验到敏捷带来的好处，这样才有可能顺利的推进。
展开
共 1 条评论
45
李永智
2020-01-08
业务人员配合敏捷项目不积极，或者由于客观原因，他们还有自己的事情，咱们有什么办法说服领导做这个?如何让业务人员感受到好处？
作者回复: 这是个好问题，是业务敏捷的初步问题，在实操中很多公司都有这个问题。有两种解决方式，一种是激进式的，把业务人员和开发测试划归到了一个部门管理，成立了事业部，甚至是成立了公司，目标绑定，从上至下推进，业内有公司做过；还有一种是渐进式的，也是大部分公司采纳的，比较温和的改变，很多公司先把自己的研发的痛点解决了，有一些亮点，给业务看。把业务的领导前期请到参与到这里面来，给业务领导做宣讲，跟他们一起做业务规划，或者请业务领导来给研发讲解业务目标，说研发兄弟配合他们的工作，让业务领导派驻业务代表到研发团队，研发进度透明化，让他们定期可以看到产出，对研发有一些理解，可以积极的收集他们的反馈，需求前期业务与开发一起共创，产生创意等等。在现实中，业务的工作不仅是支持研发，它非常重要的工作是要完成业务目标，所以要争取把这件事情排到他们的工作列表中。这里面有很多内容，涉及的部门多，领域也比较广，也有跨部门合作的很高的艺术，业务敏捷是后面敏捷的重要趋势之一。
共 2 条评论
10
吴言乱语
2020-01-07
谈一个具体点的例子吧，因为公司的业务交付流程比较长，所以很多的业务需求是需要跨技术团队协作的，现象是我们这个团队的产品经理经常就被莫名其妙的拉进一个需求讨论群，负责跟我们对接的业务负责人会告知我们需要配合做什么样的功能。但我们产品经理的疑惑常常是： 1.项目是哪个部门牵头的，牵头业务部门和技术团队是哪个 2.各系统的对接人是谁 3.技术对接方案如何确定 4.项目排期如何确定 5.测试方案和测试分工如何安排 6.上线顺序如何确定在实施中，还经常遇到信息不回复和回复慢的各种问题。学习敏捷，针对这些问题，能想到的改善方法 1.确定项目责任人和配合方，由责任人统一协调 2.组织项目组，公布所有项目相关事宜，各系统负责人，分工等 3.确立项目沟通机制，保证沟通效率
展开
7
Geek_peak
2020-03-22
敏捷需要负责需求的人员不断的参与其中，但是外包公司的需求都是由客户来决定的，客户并不会随时配合我们的工作，那么该如何实施敏捷项目呢？
作者回复: 外包公司这块我记得回答过几个相关问题。原则上来说，如果作为需求的提出方客户不关心敏捷的话，那么这个敏捷实施会非常困难。比较建议在采纳敏捷方法之前，跟客户做好相关沟通，包括基本的敏捷理念传达，敏捷基础培训、在敏捷过程中双方的角色职责、客户的具体参与时点等都做好约定，否则后面很难实施。另外就是如果是乙方引导敏捷的话，也要时不时的让客户感受到一点成就感，才能持续下去。
6
Aaron(健廷)
2020-01-06
启动敏捷前的诊断过程，就是ㄧ连串大量的个体交互过程，充分呼应了敏捷的第一条宣言
5
小老鼠
2020-01-12
1，让业务人员进入team，他们除了对需求负责，还要作什么工作吗？2，敏捷团队成员应该是通才还是专才？现在都在说全栈工程师，是不是对team member要求太高，若用专才，是不是会存在等待显象，比如测试人员等开发人员开完代码再进行测试。
作者回复: 1、还要给团队反馈产品做的怎么样，提产品建议等等 2、希望是T字形人才，团队的能力是慢慢的ramp up起来的，没有可以有办法慢慢培养。一般当我们需求足够小的时候，开发与测试之间的等待较少，因为开始的时候，开发写代码的同时，测试人员可以写案例，开发写完代码，测试人员就可以做测试，然后开发人员开发新的需求，没有等待
共 4 条评论
3
Raymond吕
2020-01-09
敏捷前诊断由公司内部的人来做的话，如果没有高层直接授权，靠个人能力推动转变太难了，请问老师如何能让大家自发的认识到问题，对敏捷带来的转变不那么抵触？
作者回复: 在教练技巧里有提问的技巧，可以提一些强有力的问题，这个需要有专门的训练，通过提问引发思考，意识到问题并让他们想到解决方法，在团队工作中我经常会用到。
3
小小
2020-12-08
宋老师，UI设计也跟着迭代走吗？我们是维护类的项目，遇到的问题是：1.如果UI纳入当次迭代，那么前端同学会有等待的情况；如果提前一个或两个迭代，需求条目又提前不了那么久或者有变更。
共 1 条评论
1
bin的技术小屋
2020-03-26
老师的声音真好听，哈哈
1
solaris
2020-01-15
思考题：如果让你来牵头敏捷，你会怎样迈出第一步呢？首先，选择具有代表性的项目（我们已经在实践敏捷了，可以跳过这个步骤）其次，需要找团队人员沟通，关注以下问题目前团队在组织、文化、工具、技术方面是否适应目前的敏捷方法团队对敏捷的认知，包括思想、原则和方法敏捷实践中遇到的问题，或者痛点，可优化的地方再次，制定敏捷推进计划，注意以下问题明确可行性可度量分阶段最后，和团队成员沟通敏捷计划，如果有不一致，可能需要返回3修改机会，最终达成一致注意方法引导团队成员认同
展开
1
规划架构
2020-01-14
老师能否在此课提供个成熟度评估参考模型吗？会对敏捷落地有很大推动作用
作者回复: 非常抱歉，因为咨询公司的成熟度评估模型是其咨询方法，一般公司不外传，我司也不例外。但是可以去咱们的大参考书SaFe的官网上去找找
1
ifelse
2022-11-25 来自浙江
实行敏捷前先诊断评估
ifelse
2022-11-25 来自浙江
在决定做敏捷实践之前，一定不要怕麻烦，要先对自己的现状做细致的评估和诊断，之后再针对具体问题使用适合自己的敏捷实践方法，这样你的敏捷推进就迈出了成功的第一步。--记下来
ifelse
2022-11-25 来自浙江
学习打卡
Geek_73b3b1
2022-11-04 来自北京
敏捷和系统规划及前期的架构搭建有冲突吗？例如刚立项需要选择系统架构、根据业务设计数据库结构，如果只是按照一个一个的业务需求来做，如何保证系统整体是可拓展的
甘亚鹏
2022-07-30 来自陕西
团队成员能力参差不齐，敏捷推进难度大
Geek_bc98a3
2021-11-21
项目人员比较多，一般都有15人左右，如果按5-9人团队拆分的话，就需要拆成2-3个团队，但对于项目经理或者公司内部敏捷教练来说，缺少规模化敏捷的经验，像这种情况如果进行敏捷转型？
行骏
2021-08-29
评估诊断是迭代的，小步快跑的，长期的，就如敏捷本身一样。不同的业务阶段会不一样，不同的专业程度也会不一样
刘隐林
2021-05-27
业务人员不了解敏捷,不配合敏捷,这需要对业务人员也做相应的培训.
半橙汁
2020-10-24
最麻烦的还是客户勾通无果，他们只关心结果，还限定工期，很难解~🤣🤣🤣

