110-说透敏捷

开篇词 | 重识敏捷，让你的研发管理少走一些弯路

你好，我是宋宁，现在在 IBM 做敏捷教练和咨询顾问。作为一名职场老兵，除了 UI 设计师和运维工程师，我做过软件研发领域内几乎所有的岗位。从一线工程师到管理者，从项目经理、Scrum Master，到现在的敏捷教练、咨询师，我经历过研发管理从无序状态到瀑布模式、敏捷模式，对各个管理模式的优劣深有体会，也从各个角度体验过敏捷。

我一直热衷于探索研发管理的效率、效益和精髓，我本人并不在乎这种研发管理模式叫什么名字，只要它能给研发管理带来益处我就敢大胆的启用，所以敏捷来了以后我也开始了解并使用它，现在我来给你讲讲我从接触到使用敏捷的历程。

时间追溯到 2007 年，当时诺基亚准备在公司内部落地敏捷。作为合作伙伴，我们公司为了更好地和诺基亚协同，并为他们提供服务，所以就派我以排头兵的身份先行了解敏捷。我与当时负责敏捷的外国同事一起研究，并在后面参加了 Scrum 的培训课程，第一次接触到敏捷。

参加完课程后，刚接触敏捷的我认为它的理念非常好，不过还是有些理想化，所以我并没有从内心接纳敏捷。于是在工作中，公司要求用敏捷的项目我就用敏捷，其它的我继续用瀑布。然而做着做着，两相对比，我隐约感觉到一些敏捷带来的好处，这尤其体现在团队管理方面，敏捷为我省去了大量的时间。

对敏捷有了好感后，我开始认真研究并使用敏捷。我熟读了敏捷的价值观和原则，又学习了很多敏捷的方法和实践，从管理实践到后来的技术实践，从单一团队管理到大规模敏捷，都一一涉猎。

因为工作的关系，我在自己深入探究敏捷实践的同时，接触了很多国内的研发团队，这些团队的规模从几十人、上百人甚至到几千人不等。他们的共同特点是很努力，但也存在很多问题，比如：

有的团队是初创团队，没有任何成熟的管理实践，想到哪里做到哪里，研发管理相当混乱；

有的团队已经经历了前期的混乱，想着要正规一些，就倾全公司之力引入 CMMI，导入瀑布流程，导致整个公司流程过重，交付速度受限制，3 个月甚至半年才上一个版本，业务部门相当不满意，项目团队成员也怨声载道；

有的团队听说现在流行的方式是敏捷，于是拿书来看，自己琢磨，炮制了一套敏捷流程，结果也没玩转，正唉声叹气准备请外部咨询师来支援；

有些团队正在拿捏，不知道自己到底该采用哪种研发模式，听说别人在做敏捷，做得还不错，跃跃欲试却不知道该怎么开始。

除了以上这些问题，我在与一些团队成员交流时，发现他们自身也有一些困惑：他们很关心现在的研发管理趋势，听说敏捷不错，也想引进敏捷，但是不晓得公司引入敏捷后，自己的工作跟以前相比有何不同。

有些一线和中层的管理者甚至还有些担忧：之前工业革命的时候，机器在很多岗位上取代了人，那现在敏捷来了，强调团队要自组织，我的岗位会不会也被取代了呢？而且敏捷来了后，

管理方式也会有一些新变化，这些变化是什么呢？到底应该怎么改变自身的管理风格才能更好地适应它？还有一些人，包括想成为 leader 的程序员，相信敏捷作为一种变革，带来挑战的同时也会带来新的机会，但不知道到底该怎么做才能提高自己的职业竞争力，把握住这些机会。

面对这么多的问题，作为敏捷咨询师，我一直想把自己的经验总结出来，就像医生总结临床病例一样，分享给更多需要它的人和团队，以便他们在探索研发管理的路上少走一些弯路。所以当极客时间的编辑跟我探讨写敏捷实践的专栏时，我特别高兴，因为我终于可以把这些年来自己对敏捷的研究，把我在这个领域内积累的经验分享给更多的人了。

我想，现在市面上也有很多关于敏捷的书，会讲到一些基础知识和理论，但是敏捷毕竟有很强的实践性，所以只了解理论是不够的。以我个人的经历来讲，我觉得要想真正理解并接纳敏捷，你需要一些真实的案例来辅助你对它的理解，而要真正自如地运用它，还是需要付出一定的努力的。但无疑，案例会让你学得快一些、深入一些，我想只有通过解读更多的真实案例才能让你更有感触，才能够收获更多。

课程设置

所以在这个专栏里，我想用这样的方式来分享我的故事。

我将从为什么需要做敏捷（why）、什么是敏捷（what）和怎样推进敏捷（how）三个角度来讲述敏捷转型过程中的那些事儿，在 why 和 what 上让你知其然也知其所以然，在 how 上让你更多地知道到底应该从哪里下手，到底该怎么做才好。

Why：在为什么需要做敏捷上，我将用实际案例来阐释做敏捷的价值，以及敏捷带来的好处，看完以后你就明白为什么这些团队不用瀑布模式，并放弃想干啥就干啥的自由散漫管理而采纳敏捷这一研发模式；

What：在总结业界敏捷定义的基础上，结合敏捷实践，从价值观、原则和实践三层讲清敏捷的实质，让你理解敏捷的本质到底是什么，通过深入分析常见的对敏捷的误解，带你正确认识敏捷；

How：结合实际案例，讲解到底怎么来推进敏捷，揭示敏捷推进过程中的常见问题，探讨防范措施，定制专属于你的敏捷实践计划。在本环节我还会带你探讨敏捷推进中需要关注的角色定位问题，不管你是一线或中层管理者，还是志在拓宽职业道路的程序员，我都会帮你解决在敏捷实践中你的职场困惑。

写在最后

虽说这门课程实践性很强，但是我觉得通过经典案例的学习，可以让你短时间内迅速地了解敏捷的实质并学会一些可以上手的方法技巧。

我建议你准备一个自己的小本子，随着课程的学习，总结你的敏捷案例集。本子的每一页分成左右两半，左边写你以前在研发管理方面的做法和困惑，右边写你学习过程中了解到的做法以及你想到的新做法。等学习完成以后，再来回顾一下，并制定一个属于自己的敏捷实施计划，相信在不久的将来，你会很快地上手并体验到敏捷方式给你带来的好处。

未来已来，不管你愿不愿意，敏捷已经成了趋势。所以我想隆重地邀请你，邀请你与我一起学起来、做起来，与我一起在敏捷的大潮中共舞吧！

01 | 灵魂拷问：如何利用敏捷思维更好地解决实际问题？

你好，我是宋宁。

今天是专栏的第一讲，在为你讲解怎么做敏捷之前，我想先用几个案例给你讲讲敏捷的价值。

敏捷在国内推进得如火如荼，我知道很多公司的研发团队都在使用敏捷，并且尝到了其中的甜头。但也有些公司，看别人做得挺好的，就照搬过来，结果却不奏效，因为探索地不是很成功，就觉得敏捷不好用，不适用于他们公司，开始怀疑敏捷的价值。

作为一个过来人，我想谈一下我的看法：我认为敏捷确实是很好的，只是推进它确实不容易。

为什么这么说呢？因为敏捷毕竟是一场变革，它本身涉及很多人的因素，比如人的习惯、团队文化的改变等等，而且它的核心点是持续改进，可以说是一场没有终点的旅行。况且它有一定的章法，但是若想运用好它，你又不能拘泥于它的章法。如果你只是了解敏捷的表面做法，就开始邯郸学步，那注定会失败。

所以，在这里我更想让你了解的是敏捷的思维，多理解一些 why，你自然就能够把敏捷融入到工作中，举一反三。但切记，千万不要为了敏捷而敏捷，所以在这篇文章中我也并不想说服你全盘使用敏捷，如果你觉得敏捷方法多，有些繁杂，不是所有都用得上，那也可以从中借鉴一些去解决你的实际问题。总之，能够更好地解决问题就好。

刚才我说我觉得敏捷很好，这话不具体，接下来我想和你讲一个故事。

记得那是 2007 年~2008 年，我们有一个项目是负责某大型通信公司印度尼西亚工厂的 SAP 实施。在简单了解需求之后，我们制定了项目初步计划，包括预算、人员和进度计划等等；目标是用 10 个月完成项目，包括需求调研、开发、测试、上线以及用户培训。

我们的项目经理很资深，公司也有一套成熟的项目管理模式，于是我们就按照公司规定的项目管理规范来开展工作。

我们花了 1 个月的时间来进行项目的前期筹备，包括组建团队。之后，我们花了 2 个半月的时间做完了需求调研，又花了 3 个月做开发，开发完成后交给测试，测试花了 2 个月完成，然后交付给客户来验收。验收之前，我们仿佛看到了胜利的曙光，就等着庆功宴了。

没想到，噩梦才刚刚开始。当客户看到系统并真正试用时，开始觉得这也不行、那也不可，提了大大小小 50 多条修改意见。记得当时验收会议结束时，客户方相当不满意，就差拍桌子了。

接下来的日子里，我们的工程师开始加班加点地改，项目经理和需求工程师还有技术负责人去跟客户斡旋那些改不掉的需求或问题。等项目真正上线时，工期比预计延期了 50%，预算也超支了不少。所以项目最后虽然上线了，但整个过程客户相当不满意，用客户的话来说：“这是勉强上线……”

好了，到这里，你可以停下来想想，上面的项目到底有什么问题？到底是什么原因导致了这个项目的失败？

这之后我一直在思索，直到我了解了研发模式中瀑布模式和敏捷模式的差别，才真正找到答案。

我上面那个项目所采用的研发模式就是典型的瀑布模式，也就是说，研发的整个工作流程都是按顺序进行的。像上面的项目过程，先做需求调研，再做开发、测试、验收和上线，所有的工作都是串行的，只有达到下一步的准入标准，我们才进行下一步工作。

瀑布模型是 1970 年温斯顿·罗伊斯（Winston Royce）提出的，并且一经提出即被各大公司拿来当做标尺使用，20 世纪 80 年代更是狠狠火了一把。因为它简单粗暴容易推广，在没有其他更好的研发管理理论情况下，使用它无疑比没有管理套路导致的野蛮生长要好得多（如果你想了解更多，可以阅读极客时间出品的软件工程专栏）。

然而，瀑布模型被广泛投入使用之后，真正的一线开发人员却感受到各种束缚，研发效率受到阻碍。就连其提出人温斯顿最后都承认说：“在我的经验里，瀑布模型在大的软件开发中从没真正起到作用”。

在项目实践过程中，瀑布模型经常在以下 3 个方面饱受诟病：

1.研发周期过长，导致研发跟不上业务发展的节奏。在瀑布模型中，所有的工作都是串行的，只有前序环节完成，才能展开后序环节，大量人力与时间成本都在这段时间里被白白消耗，等产品开发出来推向市场，很有可能市场已经没有了，或者业务已经发生了很大变化。

2.研发不能很好地响应需求变化，导致客户满意度低。要知道，我们很难在设计之初就把所有的需求都想清楚，需求又是不断变化的，因此客户在看到真正的产品出来之前，对产品很可能是无感的，正如上面项目中的客户，他们看到并试用了产品后才感觉到这里应该这样，那里应该那样。瀑布模型是在项目最后才一次性地向客户交付产品，当产品被开发出来之后，客户才发现他们需要的不是这个东西，这是非常可怕的事情。

3.不能很好地管控风险。因为是研发最后一次性交付，所以项目中的很多风险在前期很难被完全识别出来，最后发现时再想处理就要付出更大的代价。

那么，为什么“瀑布模型”会存在这些问题呢？

如今我们回过头来看会发现，软件研发和传统的生产管理不同，它的产出物具有强烈的不确定性。而瀑布模型，其流程和步骤都是规定好的，且计划与生产分离，说白了更适合确定性高的工作。那么在这种不确定性很高的研发工作面前，我们以处理确定性高的工作的方式和流程来进行管理，毫无疑问是不奏效的。

因此，自 20 世纪 90 年代起，软件业界陆陆续续有很多大师开始探求新的、轻量级的、适合软件研发的管理方法。2001 年，他们聚集在美国犹他州，将他们共同的方法高度提炼了一下，这就是“敏捷宣言”。

回到我上面的那个项目，如果当时能用敏捷方式来进行研发，或许就不需要延期那么久、预算也不需要超支那么多、客户也不会一直阴沉着脸。再反思一下这个项目，如果让我重新做一次，我至少会选择下面这 4 个点来进行改进：

1. 从大的组织结构来讲，我们的团队应该组成一个个小的特性团队，团队是固定的，成员也基本是固定的，这样项目来的时候我不需要花费那么长的时间去组建团队，磨合团队。

2. 从需求梳理的过程来看，我不会一次花 2 个半月去梳理并在最后才给客户看我们梳理的结果，我会边梳理边跟客户交流。

3. 我会把需求按优先级排序形成需求池，迭代地进行研发。

4. 我会让客户积极地参与我们的研发过程，包括前期的需求调研梳理和后面的开发测试上线，在做的过程中迭代有产出时就让客户来验收，让他们提意见和建议，以便我们在后面的迭代随时调整。

有了上面的经验，在我后面的项目中，我就真正地去尝试敏捷，并切身感受到了敏捷带来的好处。下面我就再你讲一个我亲身经历的、一家初创公司敏捷实践成功的故事。

那是 2012 年，我到一家初创公司去做项目管理。该公司研发中心有七十多人，我一到任，就听到来自业务部门的各种抱怨，我在拜访他们业务部门副总时，他对我说：“宋经理，你们研发部门交付特别慢，我们一个需求要等好几个月才能做好，做好了，我们的推广时机也过了。做得慢不说，做的东西也真是不怎么好，做好了给我们看时，我发现做的根本不是我想要的东西…”他给我讲了一通问题，并殷切希望我的到来能给公司的研发带来新的改变。

我决定在接下来的一周，调研一下，看看怎么应对。看了一圈，我发现该研发中心在刚开始运作时没有任何流程，也没有任何章法，研发过程随意，出了很多生产 Bug。于是在公司总经理的要求下，大家做了一套流程，本想认真执行，结果执行下来效果也不好，不仅交付速度变慢了，做的需求也不符合业务的要求。怎么回事儿呢？原来他们使用的是瀑布模型，有了前面的经验，我说服了公司领导，带着这个研发中心做了敏捷转型。

那么，我是怎么做的呢？我先给研发中心加业务部门的所有人做了培训，又将组织做了变革，将他们分成了一个个特性团队；接下来，我把大需求拆分成小需求，对需求列表进行梳理，排列优先级；最后，我又让业务部门参与进来，迭代地进行研发，每个迭代结束后交给业务人员验收，提反馈。

使用敏捷后的效果还不错，我们的需求流动快了，研发效率提升了，Bug 减少了，业务部门满意了，并博得了公司总经理的赞许。

上面就是我的一些项目经验，相信你已经感受到了做敏捷带来的好处，事实证明也确实如此。我们可以看一下业界的统计数据，根据 VersionOne 的最新统计，97% 的受访者报告他们的组织采纳了敏捷这种开发方式。公司在提升自己的交付能力，提高响应变化的能力，改善协作、减少项目风险等时候，都想到了采纳敏捷，并在这个过程中艰难地探索。

说了这么多，也许你会说，敏捷听起来挺好的，但我还是觉得我们公司用不上。“敏捷到底怎么用”这件事情，我会在后面的文章中为你一一解答。这里我想说的是，其实有很多公司，他们都在有意或无意中使用了敏捷的一些实践。Google 就是个典型的例子，虽然它不对外标榜自己在做敏捷，但其实你可以在他们的文化或项目中随处看到敏捷的影子，比如他们的工程师文化跟敏捷所倡导的以赋能和信任个人为中心的文化就是非常契合的。

类似 Google 这样的公司其实不在少数，虽然它们并没有全盘采纳敏捷的所有方法，但是在其做事方式上体现了敏捷的思想，他们在用敏捷的思想来改变自己的一些行为，来达成公司的目标。

比方说，有的公司会考虑加快反馈循环来提升流转效率；有的公司会把自己所有事情按照价值和优先级来排序，定期整理自己的工作列表，就像管理产品待办事项列表一样来管理工作，让员工把精力放在更有价值的工作上；还有的公司引进了很多在线协作管理工具来加强协作等等。

所以，是否打着敏捷的名头，是否冠以敏捷，这本身是无所谓的，只要我们能够用到敏捷的一些方法来帮助到自己的公司或项目就好。

总结

凡事都有两面，敏捷也不例外。前面我花了很大的篇幅带你了解了很多敏捷的益处，但敏捷也不是万能的，不是所有的问题都能用敏捷来解决。比方说产品本身的容错率就很低，不允许试错，用敏捷的话与投入产出不成正比，这就不必非要用敏捷方式来做；或者说公司需要深远地考虑战略问题，那么不去考虑布局，妄想着通过导入敏捷把战略思考省略掉，这也是不现实的。

另外，说到敏捷不利的地方，我觉得主要问题应该是“听起来简单，但实施起来并不容易”，敏捷实施起来具有一定的复杂性，这也是为什么敏捷虽然被提出来接近 20 年，在落地的过程中，直到现在，还是有很多的争吵和讨论，也还是有很多人在不断地摸索。

但不管怎么说，我觉得积极吸纳敏捷带来的好处都远超你的想象。毕竟我们现今的世界，已进入 VUCA 时代，我们正面对着一个易变（volatility）、不确定（uncertainty）、复杂（complexity）和模糊（ambiguity）的世界，而敏捷快速响应变化、允许试错、小步快跑的特点无疑是符合时代潮流的。

从我的角度来说，我希望通过这个专栏，帮你澄清一些对敏捷的误解，让你可以深度了解敏捷背后的意义和原理，了解它的一些做法，并能够让你结合你自身的公司或项目特点，结合你的痛点，借鉴到它的一个或者多个方式，来帮助到你的公司或项目完成预期目标，那么我们专栏的目的就达到了。

思考题

结合我们今天讲的内容，我想请你来思考一下，你在研发过程中碰到过哪些难解决的问题呢？你有过利用敏捷思维或敏捷方法解决实际问题的经历吗？欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

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

你好，我是宋宁。今天这节课我要给你讲一下到底什么是敏捷。

当谈到敏捷时，大家往往是仁者见仁，智者见智，有各种不同的理解。然而这里面，有不少是对敏捷的误解，比如在我平时的咨询过程中，会听到一些团队成员这样说敏捷：

敏捷来了，太好了，我们只负责开发软件就够了，再也不用做文档，也不用做设计了；

敏捷就是快，原来要 6 个月才能完成的项目，用了敏捷后，周期就可以缩短到 3 个月了；

敏捷就是加班，用了敏捷后，由于在迭代开始时许诺要做的事到迭代结束时一定要完成，所以我们比原来加班更严重了；

Scrum 就是敏捷，敏捷就是 Scrum，这俩是同义词；

敏捷是自由的、无约束的，不需要那么多条条框框，跟随自己的心来做就好了。

如果你带着这些对敏捷的误解去做敏捷，很可能会做得一塌糊涂。作为过来人，我想我应该在给你讲怎么做敏捷之前，先给你捋一捋到底什么是真正的敏捷，以便你能正确地理解敏捷。

在我看来，大家之所以对敏捷有那么多的误解，归根结底，是忘记了做敏捷的初心，忘记了敏捷的价值观和它的基本原则，只把注意力集中在怎么做上。

所以要想真正了解敏捷，需要从敏捷的价值观、原则以及具体的方法和实践上对它有全方位地认识，只从任何单一的方面去谈敏捷，都像盲人摸象，是片面的。

敏捷的价值观：正确理解敏捷的初心

我们先来看一下敏捷的价值观。2001 年，17 个轻量级方法论者在美国的犹他州，发布了敏捷宣言，在里面阐明了敏捷的 5 条价值观，我在下面也给你列出了这 5 条价值观：

个体和交互胜过过程和工具

可以工作的软件胜过面面俱到的文档

客户合作胜过合同谈判

响应变化胜过遵循计划

虽然右项有价值，但我们更重视左项

请注意这 5 条价值观中的最后一条：“虽然右项有价值，但我们更重视左项。”这一条其实是对前 4 条价值观的解释说明，很多人在传递敏捷价值观时其实只讲了前面 4 句，而忽略了最后这一句，很大程度上，这导致了大家对敏捷的误解。

结合这一条，前 4 条价值观中“胜过”一词的意思是：与每一条中右面的内容相比，左面的内容是敏捷更加重视的，但要注意，这并不表示让你停止做右面的内容。

以开篇的中一个误解“敏捷来了，我们只负责开发软件就够了，再也不用做文档，也不用做设计了”为例，我们来看看对它的误解在哪里。

在敏捷价值观的第 2 点里，敏捷认为“可以工作的软件比面面俱到的文档更加重要”，然而这并不是说我们就完全不要文档了。对这句话的正确理解应该是：敏捷重视可工作的、有价值的软件，减少一切不必要的文档。注意，是不必要的文档，而不是所有文档。

那么对于一个项目来说，什么样的文档是没有必要的文档呢？比如说一些交接类的文档，开发人员开发完毕要提交给测试部门测试，还要写一个提测单，再一级一级批复，我认为这样的文档就是可以省略的。因为在敏捷里，开发人员和测试人员是在一起工作的，所以提测的工作不需要走如此麻烦的申请与审批，开发人员做好了需要提测时，直接在软件上点击一下“提交”，并告知测试人员就足够了。

什么又是有必要的文档呢？比如那些写着重要设计方案的文件，如果在后期遇到问题，其他同事就要回头查看文件，找出问题所在；或者是系统后期开发完成、需要转交给其他人维护时，若想知道这个系统当初是怎么做的，也需要去查看当时的系统设计文档，所以这类设计方案是需要保留下来的。我想你可以根据自己的项目情况，考虑哪些是重要的文档，哪些是不重要的。

所以说，敏捷的价值观并未否定或贬损“右项” 的价值，“流程和工具”、“ 详尽的文档”、“ 合同谈判” 以及“ 遵循计划” 这些右面的内容也很重要，在敏捷里并不是完全不做。比如在敏捷中也是有计划的，只不过计划的方式与传统瀑布模式的计划方式不一样罢了。

敏捷的价值观体现了敏捷的初心，只有正确理解它，你才能更深层次地理解敏捷。敏捷的初心是通过一系列方法来让我们的研发工作更加灵活、有序和高效，所以敏捷的价值观重视人的能动性，强调人与人之间的协作，也更重视对变化的应对，这些都是为了能够更好、更灵活地组织和管理研发工作，但如果“流程和工具”、“ 详尽的文档”、“ 合同谈判” 以及“ 遵循计划” 同样能让研发工作更有序和更高效，那敏捷是不反对的，也不会放弃不做，这才是敏捷的真谛。

敏捷的原则：正确理解敏捷的基石

上面我带你重新理解了敏捷的价值观，但对于敏捷来说，只有价值观还不够具体，为了能更具体地指导工作，由敏捷的价值观又引出了 12 条敏捷原则，在下面我也给你列出了这 12 条原则，方便的话，你可以打开 App 看一下：

我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

工作的软件是首要的进度度量标准。

敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

不断地关注优秀的技能和好的设计会增强敏捷能力。

简单——使未完成的工作最大化的艺术——是根本的。

最好的构架、需求和设计出自于自组织的团队。

每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

这 12 条原则是正确理解敏捷的基石，所以在这里，我想结合开篇那几条对敏捷的误解来为你解读敏捷的原则。

针对“敏捷就是快”这个误解，你要注意的是，在敏捷的原则里，可从来没有说过“敏捷就是快”这句话。所以你需要正确理解“快”这个词。

如果你将“快”理解为采纳了敏捷以后，你的代码编写速度就立马加快了，那是非常不现实的。虽然在敏捷中我们也会使用一些方法来训练整个团队的代码编写能力，但是这并不意味着用了敏捷后，程序员敲代码的速度就得到了显著提升。况且即使敲代码的速度加快了，项目整体上线的速度就也一定能快吗？

那么敏捷在交付上会带来什么变化呢？你可以先看一下敏捷原则里的第 1 条和第 3 条，总体的意思是：针对交付，敏捷希望能够尽早交付可工作的软件给客户，而不是最后一次性交给客户，并希望交付的间隔时间越短越好。所以说，敏捷中的“快”其实指的是反馈更快，反馈更及时。

这样，我们就能更快、更准地得到用户的真实反馈，尽早修正，为用户创造有价值的产品和竞争优势。在这一过程中，客户也可能更早一点想清楚想要什么样的产品，你也能比预想时间更早达成客户的目标。这里你也要注意，是有“可能”，而不是“一定”。甚至，由于客户能够早些看到产品，通过修正，也许在某一个时间节点上，客户觉得目的达成了，项目可以结束了，这或许比客户预想的上线时间还要早。

但这绝不是通过快速写代码来完成的，而是通过不断检视客户的需求，总是优先做最有价值的事，减少浪费来达到的。在瀑布模式的项目管理过程中，我们把原计划的事情全部做完，项目即宣告结束；而在敏捷的原则下，客户的目标达到才意味着项目可以结束，这是因为敏捷是以业务价值和业务目标为导向的，根据业务价值和业务目标，短迭代使客户对自己的需求更清楚了，有可能做的事情更少了，所以时间才减少了，交付也更快了。

同样，“敏捷就是加班”这个理解当然也是有失偏颇的。你可以回到敏捷原则里，重新看看第 8 条：“敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。”

你可以清晰地看到，敏捷强调“可持续的开发速度”，这指的是团队能一直以稳定的开发速度持续下去，而不是为了加速开发，本次或几次迭代一通加班，透支团队成员的健康，后面又由于员工身体不支等原因导致接下来的迭代开发产能下降。试想如果天天加班，员工能否能一直保持高昂的斗志和较高的工作效率？能否保证一直以这样的开发速度开发下去？我想这是不行的。

那怎么才能做到保持“可持续的开发速度”呢？在咨询过程中，我看到能做到这一点的开发团队，通常都是这样做的：

他们在迭代开始的时候，不会过度承诺，也就是能完成多少工作，就承诺多少工作。

严格遵守纪律。他们在迭代开始之后，原则上不再接受需求的增加，如果一定要往他们的迭代待办事项列表里增加其它需求，就一定要同时从其中拿走等量的需求。

这么做有什么好处？我认为这样做，可以使开发团队聚焦在自己的事情上，不受干扰，效率更高，从而形成稳定的开发节奏；而稳定的开发节奏可以加强我们的预见性，这样我们预计的上线时间才可能是精准的。

所以，如果你的团队采纳了敏捷后加班更严重了，那么我建议你参照上面的做法来自我检视一下，看看你的团队是否在一个迭代中承诺的事情太多了，也就是工作范围是否太大了，如果是的话，那你可以结合团队的实际产能，根据需求条目的优先级来进行调整；此外，你的团队是否遵守了纪律，如果不遵守纪律，那额外的加班肯定不可避免。

现在，我们回过头再来看看敏捷原则里的内容，会发现它和敏捷宣言一样，重视研发各方的协作，并强调了持续改进、响应变化。只不过在这 12 条原则里，对敏捷重视的价值做了更细致的阐述，涵盖了软件项目管理的所有基本流程，而且这些流程很具体，让大家有了更可参考的标准，将敏捷的价值观落实到具体的、可操作的原则之上。

因此正确理解敏捷的原则，并以此为基准去行事，才能在后面具体的敏捷实践中不偏离，最终取得敏捷项目的成功。

敏捷的方法与实践：正确落地敏捷的基础

但很显然，只有价值观和原则，敏捷是不能落地的，你还需要一系列的敏捷方法和具体实践。

在提出敏捷时，建立敏捷联盟的 17 位大师所创立的敏捷方法包括：极限编程、Scrum、特征驱动开发、动态系统开发方法、自适应软件开发、水晶方法等等，这些方法被统称为敏捷方法。到现在还有很多关于规模化敏捷的方法，比如说 SaFe 和 Less；也有更多技术实践，比如说测试驱动开发。可以这么说，凡是符合敏捷价值观和原则的方法论，都可以归到敏捷的大伞下。

怎么样，敏捷是不是包罗万象？但敏捷的方法和实践虽然很多，你一定要结合自己的需求来选择。所以在这里我想和你强调的是，这些方法从共性上来说都遵守了敏捷的价值观和原则，不同的是它们针对了不同的应用场景，比如说 Scrum 在新软件开发中更好用，而看板在维护类的软件开发中更胜一筹。

所以开篇我们提到的 “Scrum 就是敏捷，敏捷就是 Scrum”这一说法，也是相当片面的，是对敏捷的误解。敏捷还有很多如上面讲到的方法，如果只认识这俩，那你在采纳敏捷时，无疑就受到了限制。

说到敏捷落地的方法，我们可以回头看看开篇的那个误解“敏捷是自由的，无约束的”，我想以敏捷的方法 Scrum 为例，来谈一下为什么这个说法是不对的。

Scrum 框架看起来很简单，很多人以为它不过就是“三三五五”：3 个角色（产品负责人、团队、ScrumMaster)，3 个工件 (产品待办事项列表、迭代待办事项列表、燃尽图），5 个会议（迭代计划会议、每日站会、迭代回顾会议、迭代评审会议、产品 Backlog 梳理会议），5 个价值（承诺 、专注、开放、尊重、勇气），以为只要把上面这些事情都照搬过来做完就万事大吉，就能用好 Scrum 这一方法了。但其实 Scrum 也是有约束条件的，如果不按照这些约束条件来使用它，是用不好这个方法的。

关于 Scrum 的约束条件，这里我举最重要的两条来说明：

迭代计划会议开始前，产品负责人需要准备好需求条目，使需求达到准入标准；

Scrum 讲究时间盒，包括迭代的周期、各个会议，这些都要遵守时间盒的约定。

如果不遵守第 1 条约定，你会发现你的团队即使用了 Scrum，仍避免不了研发节奏被打乱的命运；如果不遵守第 2 条约定，你会发现你的团队被耗在各个会议上，会议效率又很低，团队成员很快就会感到厌烦。所以说，Scrum 是有纪律的，如果不遵守纪律，自由自在无约束，那么使用它注定是痛苦的，也达不成既有目的。

从上面 Scrum 的例子我们可以看出，了解敏捷的方法和实践，不能只了解它的表面，更要深度了解它背后的规则和深意，只有这样才能正确地应用它，并让它为我们的研发管理服务。

针对敏捷的每一种方法我建议你在使用前问自己 3 个问题，从下面几个方面去深入了解它：

这个方法能解决什么样的问题？

有没有使用前提？

有没有相应的使用规则？

此外你还可以借鉴别人是怎么用这些方法的，看他们在使用过程中有没有遇到什么坑，如果有又是怎么避免的。我希望通过这样的自我提问，能让你深度了解敏捷，并在日后能正确地使用敏捷的方法。

总结

说到现在，你是不是已经明白到底什么是敏捷呢？我希望通过这篇文章，你能够了解什么是真正的敏捷，并能够从人们对敏捷的看法中分辨出哪些是对敏捷正确的理解，哪些是误解。综合上面内容，我来总结一下，希望能给你带来帮助。

一句话，敏捷 = 价值观 + 原则 + 一系列符合价值观和原则的方法。单纯说敏捷是一种方法，肯定是片面的；只强调敏捷的价值观和原则而不重视方法也是不对的，因为那样敏捷就飘在空中，不能落地了。

因此对于敏捷，需要从敏捷的价值观、原则、具体方法和实践上对它有全方位的认识，只从任何单一的方面去谈敏捷，都是片面的。更重要的是，做敏捷不能只关注具体的实践和方法，还要时时刻刻记住做敏捷的初心，不能偏离了它的价值观和原则。

思考题

结合上面的内容，我想请你来思考一下，你还知道有哪些对敏捷的误解么？请对照着前面提到的敏捷的价值观和原则来检视一下吧。

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

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

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

有很多人一头雾水，跑过来问我：“老师，我们现在准备开始做敏捷实践了，可是从哪里开始呢？敏捷那么多方法，我要先用哪个呢？”

还有的人说：“敏捷很好，因此我要制定标准，所有项目都要遵循这个标准。”

而有的人在敏捷面前踌躇不前：“敏捷对人的要求很高，我们现在不具备条件做敏捷，等条件成熟了再说吧。”

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

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

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

评估诊断的方法步骤

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

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

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

第三步：制定转型计划。你需要根据访谈评估中发现的具体问题和痛点，做推进敏捷的计划，以形成后面转型工作的蓝图。由于痛点不同，所以计划也不同，一定要有针对性地做计划方案。比如团队的主要问题表现在跨部门、跨团队沟通协作不畅上，那在敏捷计划中就要优先考虑团队组织的问题，必要时做组织变革；再比如团队的问题集中在从开发完成到上线前这一段，那么在计划中就要优先考虑建设 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），并且告诉他们对于每一则条目来说，好的标准是什么，这样他们就会感觉到自己的不足和差距。然后我再讲怎样做才能弥补这些不足，并给出我推荐的时间表，让大家看看是否合理。这样循序渐进，后面我再和团队沟通具体计划时，就顺畅了很多。

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

总结

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

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

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

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

思考题

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

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

你好，我是宋宁。

上节课我给你讲了怎么做敏捷推进前的评估诊断，也帮你做了推进敏捷的短期计划。接下来我要用两节课时间给你讲讲推进敏捷实践的第二个步骤，也就是团队敏捷试点。

试点工作的展开可以分为试点前准备和试点推进过程两步。今天我先来讲在做团队敏捷试点前，你需要做哪些准备，试点推进过程我在下一节课会再做详细讲解。

说到这里你可能要问了：直接给公司所有团队都直接导入敏捷不就得了，为什么还要费精力先搞个敏捷试点？

这是因为，敏捷实践毕竟属于一场变革，与其他所有变革一样，都需要先从局部试点试水，只有在试点中积累了切实的经验教训，确定了可行性后，才能去大规模推广。如果不先在试点试水，就贸然在全局上推广，一旦在推进过程中遇到水土不服等问题，不只阶段性的成果会前功尽弃，想倒回去做新的改变也更不容易，最终整个变革大概率会走向失败。

为什么要做试点前的准备？

现在你知道了为什么要做敏捷试点，那是不是在毫无准备的情况下，立马就着手做呢？

我先来带你看一家创业公司推进敏捷的故事。因为是创业公司，工作节奏本来就非常快，老板希望他们推进敏捷时也能够“短、平、快”：快速行动、快速见成果。于是，推进敏捷的负责人只对团队成员进行了简单的两小时培训，直接就要求所有团队上 Scrum。

但效果极其不好，问题更是显而易见。因为此时，大家连 Scrum Master 是谁都不知道，况且没有任何前期铺垫，直接就要求团队改变熟悉的工作模式，团队既不理解为什么要改变，也不知道这种新模式到底该怎么做。大家很快就接受不了这种工作方式，做得一塌糊涂，连个形式上的敏捷都没做到，更别提见收效了。此时，推进敏捷的负责人到处救场，劳累不说，团队也不满意，老板更不满意，最后整个敏捷实践就这么灰头土脸地草草收场了。

这家创业公司的敏捷为什么会失败？原因就是他们在推进敏捷试点之前，没有做好试点前的准备工作。俗话说“凡事预则立，不预则废”，敏捷也是如此，只有做好详细、充足的准备，我们才能在推进敏捷试点时真正做到有备无患。有人还给敏捷试点前的准备工作起了个名字，叫迭代 0（Iteration 0），更足以见得这些准备工作的重要性。

如何做好敏捷试点前的准备？

现在你知道了为什么要做敏捷试点前的准备，那么你到底该如何做，才能为你的试点打开一个好局面呢？下面我将结合一个我接触过的实际案例，为你讲解做好试点前准备工作的基本要点。另外，简单介绍一下这个案例的主角，它是一家拥有一千多名研发人员的银行，我们姑且叫它 B 公司。

1. 选择试点团队

首先，你需要挑选试点团队，让他们充当推进敏捷的排头兵，快速打赢敏捷变革的第一仗。一般来说，有以下这些特征的团队会成为我们的首选：

采纳敏捷的意愿相对强烈

业务价值高或采纳敏捷会在短期内给团队带来很大收益

为什么要选择这样的团队？

这是因为，相对强烈的敏捷意愿，是团队落地敏捷的优渥土壤。如果团队愿意接纳敏捷，那么在推进过程中，团队成员会很容易发挥他们的主观能动性，成员之间的配合度也会相对较高，更易于产生良好的化学反应，也更有利于克服推进过程中遇到的困难与不适，使敏捷顺利推进并获得成效。

另外如果团队做的产品业务价值高，或者敏捷能在短期内给他们带来很大的益处，那么团队排头兵的示范效应就会比较好。一般而言，这样的项目比较重要，公司会高度关注，团队做起来也会更认真，也就更重视自己的敏捷实践活动是否能能取得成果。况且如果敏捷能在这些团队里率先取得胜利，那么敏捷在公司里的影响力就会更大，也会让其他团队更加信服，为进一步推进敏捷打下良好基础。

此外，我建议你选两个或两个以上团队来进行试点。如果只选一个团队，孤品风险太大，也没有竞争效果；而两个或两个以上团队容易产生竞争性，对比效果明显，大家都会争着把事情做到最好。当然，这也要看敏捷教练的数量，一般一个教练一次只能带 2～3 个团队，否则一个教练的精力是没有办法照顾到每个团队的。

例如 B 公司，他们希望通过导入敏捷提高研发效能。在试点时，我们选择了两个试点团队，手机银行产品团队和直销银行产品团队。对于 B 公司这样的银行来说，这两个产品都是公司的核心产品，在互联网的冲击下，业务压力很大，所以他们要求研发团队能够快速响应，因此团队有相对强烈的敏捷实践意愿。

2. 前期准备工作细则

选好了团队，就要配合团队做一些前期准备工作，你需要从这几个方面去准备：

组织和人员

管控治理规则

需求范围

架构

敏捷方法和工具

办公环境设施

下面我就结合 B 公司这个案例，逐一把这些准备工作详细讲解给你。

首先，是组织和人员的准备。说到底敏捷实践要靠人来执行和推动的，因此，我认为在所有准备工作中，这一条是最重要，也是最需要花费心力来做好的，它直接关乎了敏捷试点乃至整个敏捷推进工作能否成功。从组织层面来说，你要查看当前的项目组织结构是否适合做敏捷，如果不适合，就要重新组织。从人员层面来说，你需要对参与试点的人员进行相关培训。

那具有什么特点的组织结构更适合做敏捷呢？简而言之，就是“高内聚，低耦合”。这本是软件开发中用来衡量软件设计好坏的词，一般而言，模块内部高度聚集和关联，而模块之间关联程度低，这样的软件才是好软件。

引申用在组织结构中，高内聚指的是日常工作中，全功能小团队内、小团队内部成员之间的沟通合作更紧密；低耦合则指的是，团队之间的沟通协作要远比团队内部的少。这样的组织结构才更适合推进敏捷。

那要怎样来划分组织结构呢？其实，业界如今已经有很多这样的组织结构框架，但在这里我想提醒你的是，框架虽然多，但本质都是一样的，都是为了让小团队内的沟通合作频度更多、更加顺畅，而团队之间的沟通协作尽量少一些。

这里我用 Spotify 框架来说一下，它是目前“高内聚，低耦合”组织结构的一个通用典范。

它分两层，下面一层是 Squad，指的是一个一个全功能小团队，每个小团队中都有自己的业务分析师、开发人员、测试人员和迭代经理（Iteration Manager），能够端到端负责一个需求或者产品。一般来说，团队中的人数被限制在 5～9 人，当团队人数超过 9 人时，就会被分拆成不同的 Squad。而当 Squad 超过 5 个，一般就要考虑将这些 Squad 划分到不同的 Tribe（部落）中去，这是组织结构的第二层。在敏捷中，我们就是按照从 Tribe 到 Squad 这样的线条去管理团队的。

参考这一组织结构框架，我们将 B 公司的研发团队进行了重新组织。以 B 公司的手机银行项目组为例，他们的项目团队有将近 30 人，且开发团队和测试团队分属不同的领导，也在不同的办公区办公。我们将其团队分成了 4 个小分队，每个小分队都是有开发、测试、业务分析人员和迭代经理的独立的功能团队。我们还在这四个团队之外设立了产品负责人的角色，用来把握整个产品。为了沟通方便，我们设法将小分队里的人都安排到了一起来办公。在组织重组完成以后，我们又定义了各个角色的描述和职责，并进行了宣讲，在团队内达成一致。

在完成团队组织结构的重组以后，接下来还需要给团队成员进行敏捷培训。在上面 B 公司重组好的团队中，我们是这样做的：

进行敏捷思想基础和敏捷实践基础两门基础课程培训；

组织拆书会，选择一些敏捷基础的书籍，每个人都来读一节，一起来分享，这样团队成员很快就有了一定的敏捷知识储备。

此外，除了对要参加敏捷试点的团队进行培训以外，我们还对相关项目的干系人也做了一些宣讲，例如兄弟公司是怎么做敏捷的，取得了什么成效等等。

以上这些都是试点启动前的培训，在试点运行过程中，我们也会根据团队实践情况，针对大家对敏捷认知模糊的部分，随时做出讲解。比如随着团队工作的推进，我们会深入讲需求条目化、怎么做用户故事以及怎么做拆分等等。

其次，是管理治理规则准备。相信你还记得，在前面的课程中我给你讲过，敏捷是有规则的，不是随意的、自由奔放的，不能想咋做就咋做。所以，在做好组织结构和人员的准备后，为了大家能更好地协同、配合，省掉管理和交流中不必要的争执，你也要做一些管理治理规则的准备，并在敏捷试点之前就跟大家明晰，保证整个试点工作有序运行。因此，在 B 公司，我们做了架构和设计的治理规则，质量管理策略规则等等。

再次，是需求范围的前期准备。要想顺利开展后续的迭代，前期需求的准备是必不可少的。但因为在敏捷中，需求是逐渐涌现出来的，所以在后面的每个迭代中，我们都会对下一迭代要做的需求进行新的梳理。

在前期我们做好这些准备就可以：

项目的高阶需求范围、高阶发布计划；

高阶的史诗级故事；

近期 2 个迭代要开发的用户故事，要有优先级排序

如何准备好这些用户故事呢？通常我们会开几个工作坊，一起来头脑风暴一下。例如在 B 公司，我们就做了几个工作坊，写好了几十个用户故事，并将其按照优先级排序。这里请你注意，用户故事不仅要准备好相应的故事描述，还要有验收标准。

接着，是架构上的准备。做好需求，就要开始架构。关于敏捷里的架构，之前业界也有很多相关讨论。但总体来说，我们希望抛弃原有的瀑布模式，由于在敏捷中需求是分步提出来的，也是不断演进变化的，因此相应地，我们要求采用演进式架构，而不是做成一锤子买卖。正因为这样，在迭代 0 的时候，我们基于当时的信息做好足够的架构就好，后面会随着项目的深入及时来调整。

这时候我们做架构的方式，是在完成初始需求分析之后，根据初始需求来做架构建模。在项目早期，进行一些高层次的架构建模，会有助于团队与关键利益相关人商讨系统采取的技术策略，这样做的关键目标是快速识别出架构策略，快速完成架构建模。

在 B 公司，我们通过召开建模的头脑风暴会议，讨论了系统的功能特征，并思考了实现这些特征的高层设计策略，从技术图表、用户交互流程图、领域图和变更流程图四个方面做了建模。

再来看敏捷方法和工具的准备。做完上面的准备后，你还要根据我们在第一步评估诊断时的访谈结果，根据痛点选择合适自己团队的敏捷方法，当然方法的使用是灵活的，也许一开始选择的方法随着敏捷的推进不再适用，那你就要做出相应的调整或改变。

在 B 公司，起初我们在管理实践上选择了 Scrum 方法，在技术实践上则选择了单元测试、自动化回归测试，还有搭建 DevOps 流水线。然而在实际推进敏捷试点的过程中，我们发现在当时的情况下，由于团队的老旧代码过多，做单元测试的收益不大，所以我们及时调整，优先推进了自动化接口测试、自动化回归测试和搭建 DevOps 流水线，而选择在试点后再尝试单元测试。

“工欲善其事，必先利其器”，要把试点工作做好，工具方面也不能马虎。你需要在试点前选择、构建、测试、部署工作过程管理工具，并在测试后安装好；与此同时，也要选好自动化测试用的工具，如果自动化工具不到位，所有工作都靠手工处理，效率就会过于低下。

工作过程管理工具，主要指研发作业流程管理工具，比如 Jira 和 Trello 等，国内也有人用禅道。你可以根据实际情况，通过这样的原则来选择工具：

如果试点团队已经有自己的工具，那可以先自行试用、评估一下这种工具在敏捷中好不好用，也就是说，看看敏捷的过程在工具中是不是可视化的。比如说有的工具只有需求管理的作用，没法将后面的开发、测试过程囊括在内，这时你就要考虑是要将两种不同功能的工具合起来使用，还是重新选用新的工具；

如果试点团队没有自己的工具，那么无论是工作过程管理工具还是自动化测试等工具，都可以根据预算以及公司要求的安全性级别选择引进新的工具。一般来说，这些工具又可分为付费工具和开源工具，如 Jira、Confluence 等 Atlanssian 的付费工具，后续的服务要好一些；而免费的开源工具如 Jenkins，则能节省资金，这还是要结合自身情况来进行选择。

在 B 公司，由于他们的团队规模较大，考虑到后续可能需要 Atlanssian 的一部分插件来做管理工作，我们选择了 Jira 做工作过程管理工具。另外，考虑到目前 Jenkins 做持续集成的案例比较多，为了日后方便，我们又选择了 Jenkins 来做持续集成，并用 SonaQube 来做代码扫描。

要将敏捷做好，除了上面的“软”件，也离不开硬件的支持，所以办公环境设施的准备也很重要。如果项目中有人员是远程的，则需要准备必要的音视频设备，远程会议工具；如果项目都在一个区域，就还要有适用于敏捷开发的办公环境，如物理看板和开放式的工位等等。

在 B 公司，由于他们所有团队的员工都在一个区域办公，我们就在办公区域张贴了一些敏捷的宣传画报，也安放了物理看板，这可以方便团队学习和交流，提高工作效率。

总结

OK，说到这里，我们的试点准备工作就大功告成了，现在我来总结一下，以利于你更好的理解。

所谓“凡事预则立，不预则废”，在推进团队敏捷试点之前，你要挑选好试点团队，并做好试点工作前的充分准备。如何做好准备工作呢？一句话：调整好结构、组织好人员、划定好需求、搭建好架构、选择好方法和工具、布置好办公环境。你要注意，这些准备工作是相辅相成的，每一步都马虎不得。

俗话说“心急吃不了热豆腐”，在推进敏捷时，不能盲目地求快，不能省略掉该走的步骤。如果在做团队敏捷试点时，不做试点前的准备工作，就直接开展活动，那么团队成员既没有心理上的准备，也没有知识和技能上的储备，整个试点工作也会如同一团乱麻，达不到预期效果。做好了各项准备，未雨绸缪，才能让我们的团队敏捷试点工作“事半功倍”。

思考题

现在，我想请你来思考一下，在团队试点前的准备工作中，关于组织和人员的准备，你会怎么做呢？你有没有更好的方法呢？

05 | 团队试点（二）：打造一支无往不胜的敏捷团队

你好，我是宋宁。

上节课我讲了怎么做团队敏捷试点前的准备工作，这节课我们一起来看看具体怎么推进敏捷试点。

你可能要问了，既然准备工作已经做好，万事俱备，还等什么，直接推进试点不就可以了吗？

其实没那么简单，因为一切准备工作还得靠团队来执行和交付。如果说试点准备工作中最重要的是组织和人员的准备，那么在推进试点过程中，最重要的也可以说是核心关键点，就是打造一支活力与战斗力并存的敏捷团队。

团队是整个敏捷实践活动的根基，只有团队能有条不紊又高效率的执行敏捷实践中的每一项工作，敏捷才能发挥出它最大的效用。如果团队氛围不好、执行力不高，那即便导入了敏捷实践活动，团队也很有可能做不好。

在做试点准备工作时，我们已根据最适合团队交流协作的方式，对团队的组织结构进行了重组，那么重组后的团队就可以成为一支无往不胜的团队了吗？当然不是，你还需要想办法来唤醒、激发团队，让整个团队更有活力和战斗力。

因此在今天的课程里，我想教给你的是如何完成敏捷试点中最重要的一步：打造一支活力与战斗力并存、无往不胜的团队。学好了这关键一步，不管你和你的团队采纳的是哪种敏捷实践，你都能在推进时得心应手、运筹帷幄，你的团队管理能力也会因此更上一层楼。

一起制订社会契约

我先来讲一个做法，叫做“社会契约”（Social Contract）。

什么是社会契约？它本指一个社会里的全体成员，为了更好地生活，定义了一些基本准则，大家一起来遵守。用在团队中，指的就是团队里的行为公约，也就是为了让团队中每个成员都能加强协作、发挥价值，一起来约定的一些基本准则。在工作中，如果有任何成员的行为影响了团队协作，其他成员都可以拿出这个契约来约束他，这样就可以“对事儿不对人”，在处理不良行为的时候更有说服力。

落地社会契约的过程，其实就是团队内部相互认可、磨合和协作的过程。那具体怎么来做呢？我认为可以将团队所有成员都聚到一起，大家一起来制定，只有这样，才能够充分征求每一个人的意见，让大家一致认可，并有充分理由一起执行。

首先，给大家分发一些贴纸，并给所有人 5 分钟的静默时间，让每一位团队成员思考这一个问题：你认为加强协作、达成团队目标，需要哪些行为准则？每一个人都要把自己认为重要的准则写在贴纸上，且一张贴纸只写一条准则。

写完之后，每个人把自己手中写好准则的贴纸贴到白板上，然后将白板划分为不同区域，把内容相似的贴纸归在同一个区域。

接着，会议的组织者逐条给大家读贴纸上每个人写的准则，询问大家是否同意，如果有人不同意，就停下来就此讨论一番，如果讨论的结果还是有人不同意，就放弃它；如果大家都同意，就将该准则保留下来。

这样进行一遍，把大家都同意的行为准则留下来，就形成了团队的“社会契约”。

你要注意的是，“社会契约”做完以后要张贴到所有团队成员都可以看到的地方，以便整个团队时时可以看到它，感受它带来的激励和约束。如果把它束之高阁，那就失去了它应有的效用，你的团队的协作也可能因此出现问题，进而导致敏捷推进的失败。

回顾会议，引导团队的自主性

在试点推进前制定“社会契约”，可以让你的团队形成一个约束和激励机制；那么在试点推进过程中，通过开展回顾会议，你的团队会形成一个引导机制，来引导团队的自主性。

在评估诊断阶段的调研访谈中，你已大体了解到团队的痛点，也根据痛点选择了相应的敏捷方法。那问题来了，敏捷方法里既有管理实践又有技术实践，推进顺序是怎样的呢？

一般而言，作为敏捷教练，我们自己会有一个自认为“正确”的推进顺序。但敏捷实践方法是团队来用的，行为和习惯转变也是团队要做的，而且我们也要打造自组织团队，所以相比你自己单纯地做口头宣讲，按自己的想法推进敏捷，引导团队自行选择和决定推进顺序会比较好，这更容易让团队认可和接受。所以重要的不是“你想”而是“团队想”，回顾会议正好可以完美地做到这一点。

怎么开展回顾会议？其实也很简单。

首先，要选一个大家都方便的时间，把会议时间固定下来。前几次的回顾会议可以由敏捷教练来引导，等大家对会议流程都熟悉了，就可以由团队的组长来组织。

会议开始后，先说明会议目的，接着让大家讨论三个条目：

团队工作中做得好的地方是什么？

做得不好的地方又是什么？

除此之外，有没有什么其它疑问？

和制定契约的会议一样，先用五分钟时间让大家静默思考，然后把每一个点子都只写在一张贴纸上。将白板划分不同的区域，把相似内容的贴纸分区域贴到白板上。

接着一一讨论这些问题。做得好的地方我们在接下来的迭代中就可以保持下去，做得不好的地方大家可以一起头脑风暴到底怎么去改善，并做一些行动计划。对于有疑问的地方大家也可以互相提问，有些是敏捷教练需要阐释的，有些则是团队成员需要解释的。

这里你要注意，回顾会议是有时间盒的，一般不会超过 1 个半小时。在前几次回顾会议中，团队会提很多关于敏捷实践的问题，但我们的时间有限，所以如果问题几句话就能解释明白，通常我会当场解释清楚，否则我会安排专门的时间来和团队解释他们的疑惑，而不会把会议拖得过长，占用过多时间。

你可以看到，这个会议其实也有查漏补缺的功能，可以让你察觉团队成员在哪些方面有疑惑，或者哪些敏捷知识储备不足，后面你可以安排其它时间来帮助团队专门补齐。

以我带过的一个手机银行团队为例。在第一次回顾会议时，团队针对做得不好的地方提出“项目透明度差，只了解自己的工作而不了解其他团队成员的工作”，我就这个问题引导团队思考其背后的原因，之后团队一致认为主要原因是“没有地方和机会了解别人的工作”。我就势引导团队说：“大家觉得可以做些什么事情来改善这个问题呢？”最后大家讨论认为，不如约一个时间，每天定时定点地开个短会来共享一下彼此的工作内容和状态，这不就是“站立会议”吗？我们又一起给这件事情定了一个时间段：下个迭代。我领取了这个改进任务，在下一个迭代中为团队导入“站立会议”。

说到这你发现了没有，通过回顾会议来引导团队思考，所有的敏捷改进就不是我作为“敏捷教练”安排给团队来改进的，而是团队自己思考出来的行动。身为敏捷教练，我只需要将专业的敏捷知识和做法示范给团队即可，团队会更愿意践行自己主动思考出来的行动，这样，整个团队的行为和习惯就会转变得非常顺畅。

所以说，只要掌握了正确的方法，敏捷的推进并没有想象中的那么难。每个团队其实都有向好转变的原动力，我们只需要将它激发出来，并且告诉他们正确的行为规范，加以引导就好了。

成绩墙与错题集，记录团队敏捷的成长

有了契约的约束和回顾会议的引导，是不是就意味着在试点过程中，会一直一帆风顺呢？不会，你一定还会遇到些小波澜。因为团队也不会一直都正确地思考，也有犯错的时候，比如：

团队为了赶进度，省略了部分测试，匆忙上线；

迭代中间有业务人员向某个团队成员提出了新的需求，要求加到迭代中，团队成员不顾自己的研发产能，擅自将该需求加到了迭代中，最后却搞不定等等。

遇到类似这些情况，该怎么办呢？这里我不想教你具体的解决方案，而是想教你如何引导团队解决问题的思维。

如果这个所谓的错误并不会带来毁灭性的灾难，比如导致用户大规模投诉，或给公司带来巨大的经济损失，那么我会选择放手让团队去按自己的想法先做一做，即使碰个壁也未尝不可。事后我们再坐下来认真分析到底怎么做才是对的，引导团队想出新的解决方案。有了这样一个试错的过程，团队通常会将经验教训记得很清楚。

另外，配合着团队敏捷试点，我会让团队通过“成绩墙”和“错题集”在敏捷推进过程中记录自己的心情曲线，记录自己的喜怒哀乐，记录取得的成绩和错误，所以这其实也记录着团队的成长。

团队有任何大大小小的进步和成绩，我都会让团队顺手记录下来，贴在一面小小的“成绩墙”上。同样，我们也将自己遇到的问题和坎坷，以及解决方案也顺手记录下来，贴在另一面小小的墙上，构成一个“错题集”。这样团队成员时不时经过它，都会很生动地想起在我们敏捷实践的过程中都发生过什么。在敏捷试点结束的时候，我们也会把试点总结里成功的经验和失败的教训写到这里。

这样做有很多好处，首先团队会一直感觉到敏捷氛围的存在，有精气神儿；其次，以后有团队请我们去宣讲时，我们很快就能找到素材，也能绘声绘色地传达给大家；再次，团队记录的心情曲线、“成绩墙”和“错题集”，这些都是试点结束后在做总结时，记录团队敏捷成长历程的鲜活的素材，是团队敏捷实践的轨迹。

总结

最后，我来总结一下今天的内容，以利于你更好的理解。

在做团队敏捷试点时，团队的执行力、战斗力是关键，可以通过三种方法唤醒团队的活力：

推进试点前，制定“社会契约”，保证团队敏捷工作的有序和高效；

推进试点过程中，开展定期的“回顾会议”，引导团队自发思考，激发团队的自主性，使敏捷工作更加顺畅；

在试点过程中和结束后，通过“成绩墙”和“错题集”记录团队敏捷的成长，总结经验。

我想让你知道，其实打造一支无往不胜的团队并不难，只要你善于利用上面我给出的几种方法，善于用同理心理解团队，那么你离敏捷实践的成功就不远了。而你也要注意的是，做团队敏捷试点不是目的，我们的目的其实是通过试点总结敏捷实践的经验和教训，以便我们给其他团队导入敏捷时有所参考。

思考题

现在，我想请你结合今天的内容来思考一下，如果由你来负责推进团队敏捷试点，你会怎么做呢？如果你是试点团队成员之一，正在做敏捷改进，你喜欢用什么样的方式来做呢？

06 | 规模化推广：复制粘贴试点的经验就够了吗？

你好，我是宋宁。

在前两节课中我讲到了如何做团队敏捷试点，这节课我就给你说说如何把敏捷试点成功的经验做规模化推广。

团队敏捷试点不是目的，做试点是为了在我们的环境中探索敏捷实践的可行性，积累经验，若是确认敏捷在我们的环境中是好用的，我们就要根据试点结果，把试点过程中积累的成功方法推广到更多团队中。

规模化推广≠直接复制试点经验

那么其他的团队该怎么使用试点团队的成功经验呢？是不是把它们直接复制过来就大功告成了呢？

在做敏捷咨询的经历中，我发现很多人都认为“规模化推广敏捷就是复制试点成功经验”，但其实这个说法只对了一半。

没错，我们是做了试点，试点中的经验教训也是可以拿来给后面推广做参考的，但如果直接复制未免有点简单粗暴。

举个例子。某个试点团队成功使用了 Scrum，于是领导一拍脑袋，也不管其他团队能不能吃得消，直接让所有团队一股脑儿在一个月内全部上马 Scrum。结果，有的团队导入 Scrum 比较顺利，而有的团队却遇到了很多困难。其中，一个团队做的是运维类的项目，由于运维类项目开发的内容通常来自客户的建议或生产上的 Bug，比较零散，没有一定的规划性，所以对于他们来说使用 Scrum 并不合适，他们其实更适合使用看板；还有一个近百人的团队，产品本身比较大，团队拆分后有十几个小团队，只使用 Scrum 却没有解决好团队间的协同，效果同样不佳。

从这个例子你可以看出，上面这位领导除了拍脑袋和一刀切做决策，在推广敏捷时也只是机械地简单复制试点成功经验，这非但没有给其他团队带来好处，对于他们来说反而成了一种桎梏。

此外，试点涉及的主要是团队内部的敏捷，而规模化推广还要涉及团队间的敏捷。

在做团队敏捷试点时，我们更多解决的是小团队内部的敏捷怎么用，所以对于单一小团队来说，借鉴试点中的经验更为便利有效。

而当你想规模化推广敏捷时，一旦小团队的数量多于两个，就会牵涉到团队与团队之间的协同问题。当然，在多个团队一起开发同一个产品的情况下，敏捷试点可能就是在多个团队中同时进行的，那么团队间的管理你也多少会有一些涉及。

当小团队数量多于 5 个时，如果你用的是 Spotify 这个组织模式，那小团队的管理就上升到部落（Tribe）级别，这时就要考虑部落内的管理了；而如果你的团队数量超过一个部落的范畴，你还需要考虑部落与部落间的管理。所以说当团队足够大时，它在管理上也就更复杂，使用基于小团队的管理方法就不够用了。

所以，从试点到规模化推广，是要从团队内敏捷扩充到团队间敏捷的过程。由于牵涉到团队间的协同管理，团队间的敏捷较之团队内的敏捷更为复杂，因为你要开始考虑让各个团队方向一致而不是互相羁绊，还要考虑跨多个迭代、多个团队、多个产品的情况下进行计划和安排优先级，更要考虑团队间的依赖、更大规模地沟通协调、多团队版本控制等一系列的问题，所以要想做好规模化推广，直接复制团队内敏捷的成功经验远远不够。

规模化推广的正确方法

关于怎么做敏捷的规模化推广，当前有两个主流的框架，SaFe（Scaled Agile Framework）和LeSS（Large Scale Scrum），这里我不想用大量的笔墨给你介绍它们，如果你对它们的具体内容感兴趣，可以去它们各自的官网进行了解。

而之所以提到这两个框架，是因为它们是如今做规模化推广比较成熟的范式，它们的方法可以为我们提供参考，有很多团队甚至直接套用这两个框架，但我并不建议你这么做，因为它们都有各自的长处和短板，如果你使用不当，反而会陷入敏捷实践的歧途。

其实不只这两个框架，每个框架都有各自的优劣之处，所以我想和你强调的是，要想做好敏捷的规模化推广，不要套用框架，也不要被框架限制，只要它们的可取之处能帮到我们，我们就可以有选择地拿来使用。就像我在一开始讲敏捷的价值时提到的，是不是冠以敏捷的名称不重要，只要它能帮助我们解决问题就好。

那规模化推广到底该怎么做呢？我认为，在规模化推广敏捷前，还是要从企业或团队的痛点切入，看他们究竟需要解决什么问题。分析具体问题后，你可以从下面这些方面考虑怎么去规模化推广敏捷，并形成自己的规模化推广方案：

选择合适的规模化推广策略。推广时该选择激进式变革还是渐进式改革？其实这两种策略没有优劣之分，你需要结合企业变革的急迫程度、领导支持敏捷推广的力度以及团队能接受的方式来进行选择。

做好敏捷文化铺垫，培养好敏捷的中坚力量。敏捷文化和敏捷人员始终都是整个敏捷推进过程的坚实基础，在规模化推广过程中也是如此，所以你也要做好必要的全员敏捷基础培训和核心敏捷人员的能力培养，以便支持更多团队开展敏捷。

搭建适合敏捷的工作环境，做好必要的工具和自动化准备。适合敏捷的工位布置，必要的物理白板和各种协同管理工具等，这些无论在敏捷试点还是规模化推广敏捷中都是必要的硬件设施，配合着规模化推广敏捷也要有相应的硬件准备。

组织级别的敏捷度量以及持续改进。你要做好组织级别的敏捷度量，从效率、质量、成本等方面收集敏捷相关的数据，并借由这些数据辅助企业做持续改进。

重视大型团队的敏捷导入与推广。这一点是规模化敏捷的核心，因为有的产品需要多个团队共同交付一个产品，这就涉及到复杂的团队间的敏捷，因此很多企业在做规模化敏捷时都会遇到这个问题，这也是我想重点为你讲解的部分。

接下来我会结合一个案例来给你讲具体怎么做大型团队的敏捷导入与推广，做好了这点，我相信你的规模化敏捷之路会更加平稳顺畅。

规模化推广实例分析

这个案例来自一家银行，我们姑且叫它 D 公司，D 公司的研发团队有接近 2000 人，在比较顺利地做了团队敏捷试点后，希望做规模化推广，让敏捷为整个公司的研发赋能。

我先分析了 D 公司的痛点，总结来说是研发效率比较低，无法满足业务发展的要求。他们的问题也很突出，主要有 3 点：

研发中各个环节的效率有待提升，各个角色的等待时间过长；

敏捷走到业务那里就卡壳，业务人员参与度低；

跨团队沟通不畅，协作效率低。

针对问题 1，我们在规模化敏捷前的团队敏捷试点中，改变了研发模式，让小团队使用了 Scrum，很有效地解决了这个问题。

而问题 2 和问题 3 涉及的就是大型团队敏捷导入与推广最需要解决的两个问题。该团队要想做好规模化敏捷，主要就是要突破这两个问题。

那该如何解决这两个问题呢？

针对问题 2 业务人员参与度低这个问题，其实就是 D 公司在敏捷推广时忽视业务这一环。

你要注意，只做到开发、测试团队的敏捷，只算是敏捷的一小胜利，最重要的是要走向业务敏捷。只有业务敏捷了，我们才能和 IT 团队一起真正打通研发整个过程的敏捷，才能在短时间内快速交付业务价值。

因此，大型团队敏捷的导入和推广，首先要打造端到端的、从需求到开发到测试到运维到运营的敏捷全生命周期，向业务敏捷靠拢。

所以针对问题 2，我们主要通过两个方法来解决。

第一是定制度。确立产品负责人制度，将过去以“项目”为中心的管理改为以“产品”为中心的管理。只有这样才能让业务战略与产品战略合二为一，让整个团队目标一致，“劲儿往一处使”，从而方便团队做好研发全链条的敏捷。

第二定反馈机制。在整个产品研发流程中进行数据收集和处理，做到从业务创意和机会捕捉到需求识别，到开发上线，再到业务运营的整体大反馈闭环。这样的好处是为端到端的研发过程提供了数据支持，以便在后续工作中识别整个研发过程的瓶颈，为持续改进做支持。

针对问题 3 跨团队沟通不畅这一问题，涉及的就是团队间的敏捷实践。

我们很多团队在需要兄弟团队协助开发时，总是希望对方在我们需要时能够随叫随到，但每个团队都有自己的优先级工作，哪里有时间随时“听喝”呢？

因此，要建立各团队间的敏捷实践，就需要提前安排支持工作。这样，你们团队需要协助的工作就会被排入对方的工作列表，就更加易于团队间依赖关系的管理，省去了很多无效的沟通和无谓的等待。

由于管理实践是后面一切具体技术实践的基础，因此在这里我只想教你如何在管理实践上探索团队间的敏捷，带你做好这关键的第一步。

所以针对问题 3，我们主要是建立沟通机制，对齐团队目标，把“做什么”和“怎么做”这两个方面的目标对齐以后，团队间的沟通就更加有序和有高效了。

具体的措施是定义了一系列关于产品团队内及与 Scrum 团队间的沟通策略和沟通机制、定期的产品集体计划会议以及将团队间的依赖放到看板上，通过 Scrum of Scrum 等来定期沟通进展。其他还包括一些具体的技术实践，例如怎么进行团队间版本控制，团队间的架构解耦等。

把这两个问题解决好以后，D 公司根据自己的情况优先选择了做管理实践的规模推广，又在工具和自动化方面做了更多的工作。考虑到要做敏捷的长期实践规划，我们又通过培养核心敏捷人员，也即内部敏捷教练来延续企业的敏捷文化，具体的举措，你可以参考后续 09 的文章来看。这样他们的规模化敏捷工作就开始平稳地推进下去。

最近我又对 D 公司进行了电话回访，发现几年以后的今天他们内部已经完成规模化敏捷 1.0，目前正在循序渐进地推进规模化敏捷 2.0，2.0 的重点在 DevOps 方面的建设。据其核心负责人反馈，他们一直在做持续改进，我为他们的持续性探索而开心，因为这也是敏捷的本质所在。

总结

好了，现在我想总结一下今天这节课，以利于你更好的理解。

敏捷的规模化推广不是对试点经验的简单拷贝，也不是找来几个规模化框架往企业身上套，而是需要根据企业的研发管理痛点和需要解决的问题，根据实际情况寻找解决方案。当然在这个过程中，成熟的规模化框架可以给予我们参考。

规模化推广敏捷的核心是大型团队的敏捷导入与推广，主要集中在业务敏捷和团队间敏捷两点上。你可以通过定制度、定反馈机制推进业务敏捷，可以通过在管理实践上建立沟通机制，对齐团队目标来保证团队间敏捷的高效和有序。当然除了这一点，你也需要统筹全局，从推广策略、文化、环境等方面完成整个敏捷规模化推广的持续改进。

敏捷的推进不是一帆风顺，但是走到了规模化推广这一步，我想由衷地恭喜你，因为这意味着你的敏捷实践已经克服了很多困难并取得了一定成果，我相信只要你以更加坚韧的心态和努力的态度去不断检视、改善自己，坚持下去，你的敏捷实践一定会取得更大的成功。

思考题

现在，我想请你来思考一下，假设你在一个大型的研发组织里，你会怎么做敏捷规模化推广呢？你有成功或失败的经历吗？

07 | 填坑指南：填好这4个坑，快速做对敏捷

你好，我是宋宁。

今天这节课我来给你讲讲敏捷实践中你会遇到的一些问题以及解决方案。

理想很丰满，现实很骨感。敏捷听起来那么美好，它的推进策略和推进路线貌似也有迹可循，但现实却往往事与愿违。在敏捷实践过程中，我经常听到有这样一些问题：

团队刚开始做敏捷时就遇到了很强的阻碍，因此不热衷于敏捷；

敏捷做着做着就流于形式，大家慢慢地就偃旗息鼓了；

开发测试人员干得很苦，然而只是他们自己在忙活，他们的上游产品却游离在外不给力。

如果你也遇到过这些问题，并且不知道该怎么办，那么今天我就带你来看看 A 公司的敏捷实践历程，结合他们在推进敏捷时遇到的一些坑，给你讲讲相应的填坑策略吧。

我先来简单介绍一下 A 公司的情况。A 公司是一家国有企业，是业界排名前几的保险公司，研发团队有一千多人，前些年因为受到互联网冲击，业绩压力比较大，加之他们在研发效率提升、研发透明度方面有诉求，因此就准备通过推进敏捷改良现状。

前期他们没有自己的敏捷教练，也没有向外聘请敏捷教练，自己分步推进，磕磕碰碰地实践了接近两年，结果遇到了很多问题和困难。无奈之下，他们只好找专家组来帮忙。

专家组来到现场后，慢慢地梳理了他们的问题，并给出了解决方案，亲自示范；在专家组驻场一段时间以后，团队最终把敏捷推进成功。作为专家组中的首席敏捷教练，我经历了这个过程，现在就来分享给你。

坑一：团队说他们不想做敏捷

当我进入该公司做咨询时，他们请我帮忙诊断一个团队，据说是个难啃的骨头，因为这个团队不想做敏捷。他们的领导希望能够引进敏捷做一些改进，然而团队对此并不感冒，在推进敏捷这个问题上阳奉阴违。

在进入这个团队之前，我先跟这个团队的同事做了一次约谈，在这期间团队的 leader 对我说：“我们已经很忙了，没有时间做敏捷。”看来马上就要吃闭门羹，这时我该怎么办呢？

以我的经验来分析，团队不想做敏捷的原因有很多方面，不能只看表面，必须深层次挖掘，比如：

团队没有真正理解到底什么是敏捷、敏捷能给他们带来什么切实有效的帮助；

团队真的很忙（当然“忙”要分情况应对，是否是有效的忙碌也是一个值得探讨和挖掘的方面）；

团队中有人一言堂，这个人的意见不改变，其他人不敢动。

如上例，我在进行了调研之后发现，这个团队之所以很忙，其实是因为资深老员工不够信任新员工，凡事都要亲力亲为。那么我是怎么发现这一原因的呢？

在并不太被接受的情况下，我跟这个团队的 leader 说，我不影响你们工作，只坐在你们旁边可以吗？他表示赞同。

就这样我坐在他们团队旁边，观察他们的一举一动，没几天我就发现了这个团队的小情况。该团队有 2 名资深员工，其他 5 位都是新人。其中一位资深员工经常在团队工作中一言堂，与此同时，他不信任新员工，对新员工做的很多工作都不放心，于是基本上所有核心一点的工作都是这两位老员工在做，其他同事最多打打杂，这样他们不忙才怪呢。结果就是，两位老员工忙的脚打后脑勺，新员工却没什么大事儿可做，每天也不开心，总觉得自己被边缘化。

在分析了团队不想做敏捷的根本原因后，我制定了以下对策。

我决定从这位资深老员工下手，慢慢地解决问题。首先，我先找他分享了我的观察，谈了一些基本管理技巧；其次，我鼓励他试着慢慢放手，让其他团队成员参与进来，并定期做代码 Review。这样几轮迭代以后，他们的工作变得均衡了，老员工不那么累，新人也成长起来了，团队整体的满意度也提升了。在此基础上我们再引进敏捷的新思想和实践，也就无人反对了。

总而言之一句话，不了解和分析现状就直接推进敏捷是非常不靠谱的，必须看清现实，摸清项目的痛点，在解决痛点的基础上导入并推进敏捷才是可行的。

坑二：不理解敏捷实践背后的意义，把敏捷当作一种新的流程，而忘记敏捷的核心是持续改进

上面我们解决了团队不想做敏捷的情况，在实际工作中还有一种情况是：即使公司已在推进敏捷，但对于很多并不深刻理解敏捷的员工来说，他会说敏捷不就是一套新的流程或一种新的工具么？

我在调研 A 公司的员工时，发现大概有一半以上的员工认为“敏捷就是一种替代瀑布的新流程”，他们一直在开 Scrum 中的五个会议，已经开得烦闷而枯燥，也没看到更多显而易见的好处，但迫于高层的压力，不敢停下来。

于是整个团队每天都在机械地重复着，回顾会议里回顾的问题也就是反反复复的那几条，而这些问题基本上又是自己内部不能解决、需要别的团队协同或者高级管理层来协助解决的，但没有人去推动，问题就日复一日的挂在那里。团队里渐渐怨声载道，觉得敏捷只是凭空增加了很多会议，并没有带来什么新的好处。

面对这种情况，我认为他们犯了两个错误：

公司敏捷实践的基础导入工作没有做好，连敏捷究竟是什么，以及为什么要做敏捷都没给团队讲清楚；

缺乏一名强有力的敏捷教练做引导，在持续改进方面欠缺较大。

那么，如何能让整个团队更清晰地理解、接受敏捷实践呢？我认为可以通过两种方法来解决：

基础培训、基础培训、基础培训，重要的事情说三遍。有很多公司舍不得投入前期的基础教学时间，大家对敏捷的理解一知半解时，就开始让大家照猫画虎、迅速铺开实践，这就造成大家在做各种实践之前根本不知道这样做的背后有什么意义，从而导致整个程序的僵化。通常来说，敏捷推进会经历三个阶段：做敏捷（doing agile）、思考敏捷（thinking agile）和思想敏捷（being agile），但如果只停留在“做敏捷”的阶段，就会出现这样的问题。

找一个靠谱的敏捷教练陪伴。敏捷本身是一种变革，是从指挥和控制到协作的、以团队为中心的结构性转变，它也涉及到人的头脑和习惯上的改变，归根结底不是那么容易的。因此这种转变需要一个有丰富敏捷经验和有影响力的人来持续引导敏捷实践，敏捷教练就是这样的角色。敏捷教练不仅负责组织一个敏捷团队，还通过敏捷帮助公司进行企业文化层面上的转变。因此在推进敏捷过程中，你需要一位甚至几位敏捷教练的陪伴。

坑三：Scrum 过程被严重缩减，只剩下每日站会

在团队认识到敏捷会带来好处并开始推进敏捷后，是不是就可以顺利推进了呢？其实不然，在推进过程中你仍然会遇见各种各样的问题。

有一天，一个负责理赔服务研发的团队 leader 找到我，对我说：“宋宁老师，你快过来看看我们团队吧，我们的敏捷现在很尴尬，只剩下站会了……”我很诧异，因为这个团队之前做得还是很不错的，怎么就变成这个样子了呢？带着种种疑惑，我到团队进行了调研和观察，我发现该团队采纳的敏捷方法是 Scrum，但团队很默契地剪掉了里面几乎所有的会议，只留下了站会。

但是，先不着急下结论、给建议，在了解了该团队的敏捷实践经历后，我发现该团队在 A 公司整体的转型中导入敏捷较晚，刚开始大家还很有激情，每个 Scrum 的实践都做到了，将敏捷做得有声有色。但等他们的导入者走后，会议渐渐没人张罗，会议过程也无人关心、无人引导，慢慢地大家就开始觉得这些事情没有做下去的必要了。

再到后来，大家觉得聚到一起开会无话可谈、倍显尴尬，就自然省掉了这些流程，还美其名曰为了提高效率。半年以后，当他们发觉自己的敏捷有问题再请我去看时，整个敏捷实践已然是病态的了，前期的实践成果基本前功尽弃，我需要再花多出一倍的时间帮大家重新建立信心，重新燃起敏捷的火种。

那么这个团队的问题在哪呢？在我看来，最重要的问题是他们没有培养出属于自己的合格的 Scrum Master，这导致敏捷教练或咨询师撤场以后，敏捷的火种无人守候，敏捷的纪律无人看管。敏捷的效果在短期内并不容易显现，因此在团队的敏捷习惯刚刚养成还没有固化时，一旦敏捷教练或 Scrum Master 不在场，大家很容易迅速回到引入敏捷前的状态，使敏捷的成果付之一炬。

那么我们该如何解决这一问题呢？

首先，你一定要认识到 Scrum Master 在敏捷实践中的重要性。在团队还不成熟的时候，他负责宣讲敏捷的价值观、理念，也负责具体实践的导入和守护。一个好的 Scrum Master 在引导（facilitation）、教育（teaching）、辅导（mentoring）、教练（coaching）这四个方面都有很强的能力，并能根据具体的情景选择使用哪种能力来帮助团队体验敏捷带来的益处，坚定维持团队新养成的敏捷习惯。在领导力方面，他具有服务型领导的理念，是团队的主心骨，在构建敏捷文化等方面对推进敏捷具有很大的意义。

其次，要想将敏捷推进到底，必须在基层留有敏捷的火种。因而在推进敏捷实践之初，团队就应该计划一系列 Scrum Master 的培养活动，识别出优秀的 Scrum Master，然后相互配合着推进敏捷；每周举办 Scrum Master 工作研讨会，让 Scrum Master 学习和实践上文讲的 4 种能力。在敏捷实践后期，由 Scrum Master 来负责进行团队引导等工作，并听取敏捷教练的反馈意见，这样在敏捷教练离开之后，培养好的 Scrum Master 就会接过敏捷的大旗，专心引导和辅导团队，在团队遇到困难时及时帮助解决。与此同时，跟随着团队推进敏捷的步伐，引入新的合适的实践。

坑四：筒仓中的敏捷

所谓筒仓，原指贮存散装物料的仓库，用在研发领域，指的是部门各自为政，不好协同。A 公司的敏捷实践进行了一段时间后，这样的问题也出现了。

在 A 公司，开发测试部门的副总最先意识到敏捷的价值，他带着一腔热情，撸胳膊挽袖子，将开发测试部门敏捷了，然而敏捷的火种却并没有传播到其他支持协同部门，除了开发和测试部门以外，其他各部门之间还是各自为战，形成严重的筒仓。比如：

产品业务部门没有协同，因此对需求的分析理解还是极其缓慢，每次到迭代开始时，需求都准备不好，打乱开发的节奏；

上线运维部门也与开发测试部门割裂，导致虽然开发测试做得很快，然而到了上线那一步又变慢了，最终拖慢了整个进程。

因为研发管理的全链条没有打通，开发测试部门也不能真正感受到敏捷带来的好处，最后推动无力，大家越来越没有信心，敏捷遂在大家的愤懑中偃旗息鼓，人人不愿再提“敏捷”二字。

针对上面的状况，我们如何来解决呢？

仅就这个问题本身来讲，我认为前期应该多宣讲敏捷的本质和好处，尤其应该推动对高管层面的宣讲，并成立更高级别的敏捷实践督导团队。当高管层面理解到敏捷的好处和他们应该做的事情之后，就不会成为推进敏捷的桎梏，而能及时为敏捷提供必要的帮助，这尤其适用在一些大型的控制型传统企业中。

以 A 公司为例，现阶段要想实现“需求 - 开发 - 测试 - 运维”的全链条协同，必须推动组织变革。但该公司是一家大型国有企业，从某种意义上说，推动组织变革尤其是大部门的组织、合并、重组并不容易，必须由高层领导认可并推动才能完成。在经过谨慎的思考后，我鼓起勇气将这个问题提到了他们总经理办公会上，并跟总经理约到半个小时的访谈时间，借由这个机会向他宣导敏捷。最终的结果很让人满意，他们的高管高度重视这件事且推动了事情的进展。在咨询结束后大概几个月，当我做回访时，惊讶地听到他们已经做完了组织重组，并按照之前我们的规划进行了研发全链条的协同，不仅提升了研发效率也提升了研发的整体满意度。

就这个问题再深层次地挖掘一下，我认为：

第一，推进敏捷时要通盘考虑整个链条应该怎么推进。组织全功能团队，除了一个一个的研发敏捷小团队以外，还要考虑需求管理怎么推进，并想好推进策略。

第二，敏捷可以分步推进，但是推进过程中一旦识别出新的阻碍，应及时去除。像在本案例中，我相信当产品团队没有跟随一起推进敏捷实践时，整个敏捷流程很快就会有新的问题浮现出来，例如每个迭代前，需求条目都准备不好，在这种情况下，这个障碍就应该及时去除。

总结

好啦，我们今天的课到这里就要结束了，结合我给出的敏捷实践中的填坑策略，现在我来总结一下。

敏捷是个整体工程，需要从全局上来考虑怎样去推进。在前期，要做好诊断和规划，在解决痛点的基础上导入适合自己的敏捷方法；推进过程可以分步进行，要及时排查每一步中出现的新的阻碍；要加强协作，打通研发管理的全链条，必要时要成立高层参与的敏捷督导团队，请高层领导帮忙推动；在整个敏捷实践过程中都需要有能力的敏捷教练陪伴，并在推进过程中培养出适合自己团队的 Scrum Master。

从今天的文章你可以看出，推进敏捷确实不是一件容易的事儿，在推进过程中你会踩到很多坑，而在填坑时既要有方法的甄选，又离不开人力的支持，很多公司和团队之所以会遇到各式各样的问题，也是由于他们或是浅尝辄止，或是急于求成，没有把敏捷实践真正落实好。所以我相信，只要你稳扎稳打，踏实、耐心、正确地完成敏捷推进中的每一步，夯实基础、持续改进，再多的问题都会迎刃而解；你更会举一反三，成为一个真正的“填坑专家”。

思考题

我想请你思考下在推进敏捷过程中你踩到过哪些坑呢？除了文章中提到的方法，你还有更好的填坑方法吗？

08 | 避雷策略：如何防止你的敏捷变为“小瀑布”？

你好，我是宋宁。

也许在一起订阅我们这门课程的人中，很多已经走在敏捷实践的路上。然而却有很多人在做的过程中，不小心走入了敏捷的反模式。那么该如何检视你的敏捷方法是否正确呢？今天，我想以其中的一种反模式“小瀑布”来与你深入探讨一下。

真敏捷，还是“小瀑布”？

在我提供敏捷咨询的过程中，常常会看到一些团队的敏捷实践过程出现下面这些情况：

把一个大项目分成若干个模块，仿照“敏捷”的做法，每四个迭代做一个模块 (见下图）：第一个迭代做需求，第二个迭代做设计，第三个迭代做开发，第四个迭代做测试。这样四个迭代交付一个模块的内容，然后开始下一个模块的循环。做着做着，他们发现这种方式比以前的瀑布模式要好一点，但整体的节奏仍然缓慢，“敏捷”好像没那么大的效益。

有的团队觉得上面那种方式还是太慢，于是加快节奏。每个迭代周期也是 2 周，但不同的是，在一个迭代里完成一个大的功能（见下图）。第一周完成需求和设计，第二周完成开发和测试。迭代的次数增加了，但开发和测试却总感觉时间不够，每次迭代都特别赶，体验非常不好。

团队的感觉不好，然而却不知道自己做得到底对不对，就找身为敏捷咨询师的我来诊断。那么上面的做法究竟有没有问题？他们的敏捷活动做得到底对不对呢？

先来看一下他们目前的研发过程，整体来看，他们是按照“需求 - 设计 - 开发 - 测试”这个流程来做的。你是不是觉得似曾相识？没错，这其实就是瀑布模式。

但是他们做了一些改造，也就是引入了“迭代”这个概念。先把大项目或需求做一个模块拆分，然后一个一个模块做下去，和瀑布模式相比，这种方式有了一点进步。然而，究其本质，仍然还是瀑布，我们一般称它为“小瀑布”。

“小瀑布”同样具有瀑布模式的一些缺陷。比如说，很要命的一个问题就是浪费。我们看一下上面那两种做法就会发现，他们在研发中的所有步骤都是顺序进行的，这就意味着做第一步时，后面的步骤都处于等待状态。这样，BA（需求分析师）做需求的时候，开发测试人员在等待；开发人员写代码的时候，测试人员也在等待。这就造成了时间上的浪费。

所以从这个角度来说，小瀑布依旧是瀑布，它并没有改变瀑布模式的宿命，它离真正的敏捷还有相当长的一段距离。

那么真正的敏捷是什么样子呢？

以需求为例，团队会尽可能有效拆分需求，这样进入到迭代内的需求就可以是多个独立的小需求。小到什么程度呢？小到每个需求都可以在很短的时间内，比如 2～3 天内完成开发和测试，最长也不要超过一个迭代周期。

这样在开发人员写代码的时候，测试人员在写测试案例，或者在考虑使用自动化测试方案。由于需求拆分得足够小，所以很可能第一个小需求在迭代后的第二天就可以交付测试了，在测试人员测试这个需求的同时，开发人员继续开发下一个小需求，由此形成一个良好的循环。在这种情况下，大家都在热火朝天地工作，节省了很多等待的时间。

为什么你把敏捷玩成了“小瀑布”？

那为什么有的团队会把敏捷玩成“小瀑布”呢？我在接触了使用“小瀑布”的团队之后，才慢慢明白这背后的原因。

第一个原因是有些团队其实并没有真正地了解敏捷，团队遇到痛点，他们只了解了敏捷的皮毛，就拍脑袋炮制了一个所谓的“敏捷”流程。

比如说有一个 M 团队，他们团队的工作量很大，以前用瀑布太慢，完不成工作任务。他们领导说：“你们怎么做我不管，这个产品必须在 3 个月之内交付！”然而这些需求却远远超出团队的交付能力，所以当团队听到这个消息时一脸懵圈。团队中有一个机灵鬼说：“我听说现在别人用了敏捷后，交付得很不错，要不咱们也来试试？”此话一出，M 团队像是抓住了一根救命稻草，他们在很短时间内快速地上网查看别人怎么做敏捷，再按照自己的理解，把团队负责的产品按功能大卸八块，又给每个功能都定了小时间点，每个功能用一个小瀑布这么做下去。

他们在这里犯了什么错呢？他们误以为敏捷就是简单地换一个工作流程，只要套用一个不知所谓的敏捷流程就能成功交付工作，而完全忽视了敏捷自身的规律。

第二个原因是需求太大。团队知道使用敏捷后，需求要做拆分，也把需求做了拆分，然而由于拆分方法不当等原因，拆完后的需求还是很大，一个 2 周的迭代根本就做不完，或者只能灰头土脸地勉强做完。

比如有个 N 团队，他们每次拆分完需求后，需求的大小都要 2 周的迭代才能做完。这样他们每个迭代最多做一个需求，在研发过程中，也是按照做完需求分析再做设计、开发和测试这样一条线下来，所以虽说迭代频繁了，每一步也还是需要等待时间。

这里最大的问题，你看出是什么了吗？没错，就是需求太大，这导致团队在做敏捷时不能发挥敏捷的优势，将敏捷实践做成了不折不扣的“小瀑布”。

如何避免把你的敏捷做成“小瀑布”？

既然我们分析了问题和原因，那到底怎么做才能避免把敏捷做成“小瀑布”呢？我想针对上面 M 团队和 N 团队的情况，再给你一些建议。

先来看 M 团队，针对他们不了解敏捷就开始着急模仿敏捷流程的做法，首先我们可以给予他们知识上的宣贯，在使他们充分了解敏捷的基础上，对他们进行技能上的培养。

除此以外，不知道你有没有注意到一个细节，那就是他们预计的工作量要远高于他们的产能，这其实也是一个很严重的问题。其实如果工作范围没有发生变化，即便是用了敏捷的方法，或许也很难做到在 3 个月之内做完整个项目。

这是不是意味着这个问题就无解了呢？其实不是。

你应该还记得在敏捷的原则里，有一条是“我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意”，也就是说我们要先做有价值的东西。所以反应到这个项目中，我们其实可以先把客户的需求拿来看一下，挑选好并先从有价值的、优先级最高的需求开始做。

如果一定要卡 3 个月这个时间点进行交付，那么就按照 3 个月之内我们能做多少，来选定价值最高的需求优先做，因为在整个过程中我们是不断的把产品交付给客户的，所以我们有很大可能在 3 个月内交付给客户一个令他们满意的产品。

你有没有看到，在这里我其实是把“3 个月做完项目”这个课题转换成“3 个月做一个让客户满意的产品”，而其实后面的那个课题才是客户最需要的。

所以在敏捷实践中，我们工作的结束点不应该是把之前所有计划的工作做完，而是把客户需要的工作做完。这些工作不一定是之前就被纳入计划的，但却一定要是客户最需要的。明白了这一点，敏捷才能被活学活用，而不是被误用成小瀑布。M 团队日后的工作就是按照这个原则来做的，他们的研发工作由此慢慢走上了正轨。

接着再来看看 N 团队，他们的问题是需求太大。这里涉及两个层面，第一个层面是拆分方法不当，导致大需求并没有被正确拆分成小需求；第二个层面是即使拆分方法得当，拆分后的需求仍然很大。

所以作为敏捷咨询师，第一步我先给他们讲解了需求拆分的方法。需求拆分的方法有很多，例如按照业务流程、按照业务规则的变化或按照数据的处理方式进行拆分等等。

你要注意，不管是使用哪种拆分方法，做需求拆分的目的，都是把大需求拆成一个个能够独立开发测试的小需求。只有这样，我们才能在迭代中同时做几个小需求，而不需要等待，并且在测试完成后，这些小需求也能独立上线。

N 团队之前是按照架构的层次来进行需求的拆分，例如把一个大需求拆成了 UI 层的用户故事、逻辑层的用户故事、数据访问层的故事。然而由于这个端到端的大需求一个迭代做不完，所以他们放到了几个迭代中。但是他们发现，每一个故事做完都不能单独测试，只能等着这一连串的故事全部做完以后才能一起测试。另外每一个故事没有独立的价值，也不能独立上线，这样就需要大量额外的等待时间。

在认识到这个问题之后，N 团队重新对他们现有的需求进行了拆分，保证了每个小需求的独立性，之后在两个周的迭代内他们能做好几个小需求。

但是 N 团队发现有的需求经过拆分后还是很大，无法在 2 周内做完，这种情况怎么办呢？这时就需要深度的挖掘一下背后的原因，采用相应的应对策略，

经过细致分析，大家了解到，他们的系统架构比较老旧，代码的耦合度较高，依赖性大，要完成一个需求甚至要改很多个系统，这对于产品交付来说明显是一个很大的障碍。

于是团队计划在现有的开发测试工作之余，对该产品进行架构演化，拆分微服务。为了能顺利开展这些工作，团队用 70% 的时间进行新需求的开发，用 30% 的时间进行架构演进。经过大概半年的时间，N 团队完成了既有架构的改造，拆分了微服务，现在他们的敏捷已经运转得越来越好。

总结

好，现在我来总结一下我们今天的课程内容。

在推进敏捷的过程中，有时候一不小心就会走入敏捷的反模式。综合上面 M 团队和 N 团队的情况，我们可以看到，如果团队只是套用敏捷流程，或没有做好需求拆分，敏捷很容易变成“小瀑布”。

此外，还有一些其他情况也可能让你步入敏捷的反模式，比如虽然导入了敏捷模式，却没有按照敏捷模式要求的角色职责进行人员匹配。举例来说，如果直接让一个技术经理同时扮演产品负责人和 Scrum Master，很可能就做不好敏捷，因为这两个角色要求的技能是完全不同的，技术经理是没有足够的能力和精力来同时担当这些责任的。

但其实走入了反模式并不可怕，重要的是我们一定要保持警惕的心。团队在发现问题后，需要沉下心来分析原因，只有将具体原因找出了，在正确理解敏捷原则的基础上灵活使用敏捷，并制定相应的对策，才能真正发挥敏捷的价值，敏捷才能继续正确地走下去。

思考题

现在，我想请你来思考一下，你在推进敏捷的过程中有没有犯过什么错误呢？我建议你思考一下，并结合今天的内容先自己想一下怎么解决，再来留言区跟我一起讨论一下吧。

09 | 内部教练：守护敏捷实践，求人不如求己

你好，我是宋宁。

这节课我想来给你讲讲怎么培养自己的内部敏捷教练。

在推进敏捷时，如果团队没有合格的内部敏捷教练，可以说是非常痛苦的，为什么这么说呢？你可以看看下面这些场景：

团队敏捷实践初期，外部敏捷教练在场，他带着大家了解敏捷，并给大家做示范，团队有问题及时协助解决，在他的带领下，团队把敏捷玩得很 high。然而，外部敏捷教练撤场后，团队渐渐无所适从，气氛低沉，该开的会议也不开，失去了对敏捷的热情，工作模式慢慢又退回到了瀑布。

团队刚开始引进敏捷时，有敏捷咨询师帮忙做了相关的敏捷培训，培训后团队成员都掌握了做敏捷的方法。后来有团队成员转队或者离职，团队招募了一批新的成员，新成员到岗后，团队中的老成员对他说：“你就看着，我们怎么做你就怎么做就行了。”于是新成员跟在大家后面，亦步亦趋，却并不知道为什么要这么做，工作干得很别扭。

团队在引入敏捷之后，取得了很好的进步，大家一直都很开心。突然有一天，团队遇到了一个比较大的困难，然而团队的 Scrum Master 是位兼职的同事，有自己本职的测试工作，他对 Scrum Master 的认识就是每天带着大家开开会，其他时间都在做他自己的工作。团队还没到足够成熟的地步，因为不知道要怎么解决这个困难，加之无人牵头，大家很快就泄气了。

你可以看到，在上面这些场景中，敏捷之所以会失败，究其根本原因，是企业或团队在敏捷推进过程中，过于依赖外部敏捷教练，而忽视培养自己的内部敏捷教练。

内部敏捷教练为什么重要？

在讲怎么培养自己内部敏捷教练之前，我想先带你了解一下敏捷教练这个职位在敏捷推进过程中到底充当什么角色，以及内部敏捷教练为什么重要。

顾名思义，敏捷教练是帮助组织或团队推进敏捷实践的人。这个职位需要具备的能力，用行业内的话来说，有 4 项，分别为：

教授（Teaching）

引导（Facilitation）

辅导（Mentoring）

教练（Coaching）

但其实，我们可以把这些能力简要归结成两点：懂敏捷、能“教练”。

懂敏捷指的是一名合格的敏捷教练，首先要有扎实、完备的敏捷知识，要有推进敏捷实践的经验和技术，这是能“教练”的基础。

能“教练”指的是敏捷教练既要能教授团队什么是敏捷，给团队讲授基础的敏捷知识和敏捷背后的意义；又要能给团队示范和辅导具体的敏捷实践怎么做，通过引导团队会议等引导团队的敏捷推进；同时，他还能用一定的技巧来引导和启发团队主动思考，主动改良自己的行动。

所以说，敏捷教练对于企业或团队推进敏捷实践至关重要，由于敏捷是一场变革，在推进过程中难免会磕磕绊绊，不尽人意，这时就需要敏捷教练的引导和辅助。

那么为什么说内部敏捷教练更重要呢？

这是因为很多企业或团队在引进和推进敏捷时，由于企业或团队内部很少有真正懂敏捷的人，就少不了向外寻求外部敏捷教练的帮助。然而在这个过程中，他们没有培养出属于自己的内部敏捷教练，那么一旦向外请的敏捷教练退场，再遇到问题，他们往往就失去了领头羊，导致在推进敏捷时缺少必要的引导和辅助，最终走向失败。

所以，在第一个场景中，外部敏捷教练一离开，团队在推进敏捷时马上就失去了主心骨；而在第二个和第三个场景中，由于没有内部敏捷教练，团队失去了专业的引导者，导致敏捷推进无以为继。

如何培养内部敏捷教练？

好了，既然内部敏捷教练这么重要，那么对于企业来讲，如何来培养自己的内部敏捷教练呢？下面我就以某大型跨国公司 F 公司中一个团队为例，来给你讲解一下。这个团队是 F 公司数字科技部门，有接近 3000 人，用敏捷的方式进行工作。

这里你要注意下，在这样一个庞大的组织中，敏捷教练也按技能和分工的不同分为高级敏捷教练、中级敏捷教练和初级敏捷教练。初级敏捷教练在公司内部有其独特的角色名称，但为了便于理解，我们就称呼其为初级敏捷教练。

从分工上来看，高级敏捷教练负责组织级别的敏捷事宜，包括培养初级、中级敏捷教练，新团队的敏捷导入，以及咨询和处理疑难敏捷问题等。中级敏捷教练通常负责几个小团队组成的一个部落的敏捷事宜，负责部落内各小团队的组间协同等等。而初级敏捷教练则主要负责一个一个小团队的敏捷事宜。

由于初级敏捷教练是直接带领每一个敏捷团队的，且数量庞大，所以我们培养内部敏捷教练的主要精力也放在培养初级敏捷教练身上，而中高级敏捷教练也是在初级敏捷教练基础上逐渐成长起来的。

基础培训

首先是基础培训，它的目的是通过一系列培训课程使大家能了解足够多的敏捷知识。

初级敏捷教练需要先参加敏捷基础培训、设计思维培训和产品负责人培训。在这些培训里，他们会建立起敏捷的基本概念，了解敏捷基础实践是什么以及怎么做，设计思维是什么以及怎么做；也会学习关于产品管理的一系列基础知识，以便更好地与产品负责人沟通，帮助他们理解敏捷并指导他们做敏捷实践。在培训之后，初级教练会自行进行实践，有问题可以请教同行或者高级敏捷教练。

安排实战工作坊

紧接着会安排实战工作坊，因为在敏捷实践过程中，有些问题只靠掌握基础知识是不能解决的，还需要将这些知识转化成实战技能，这就需要练习和实践。

比如在 F 公司，有一次我们就安排了一个为期两天的实战工作坊。

在第一天，敏捷培训师带大家回顾了敏捷的基础内容，并让大家把自己在实践中遇到的问题写出来，一起讨论解决方案。他还带大家讨论了初级敏捷教练的定位，让大家明白原来我们不只是引导会议的人，还有很多别的职责，比如说保护团队，带领团队从“泥潭中”爬出来。

第二天，培训师带大家体会演练了领导力、引导的技巧、团队的对话、强有力的问题等。这些环节是这样设计的：

领导力环节。带大家讨论不同的领导风格，并让大家就不同的情境，练习不同领导风格的选择和使用；

引导技巧和团队对话环节。大家一起探讨如何应对团队对话中的沉默状态等问题；

强有力的问题环节。这部分关注的是教练技巧，这一环节会设计很多场景，大家在各个场景中练习怎么使用强有力的问题解决团队成员的各种困惑，并互相引发对方的思考。

通常来说，在来实战工作坊前，初级敏捷教练会带来了一堆问题，通过工作坊的帮助以及在这个过程中自己的思考，他们最终带回相应的解决方案和技巧。同时，经过在工作坊中的实践，他们也会有新的计划、新的想尝试或改变的事情。

但你要注意，实战工作坊只是个开始和模拟演练，初级敏捷教练会在后面的工作中，开展具体的实践，进一步掌握敏捷教练所需的各种技能。

线上活动加力

除了以上两个常规的活动以外，我们还有一系列在线培养初级敏捷教练的活动，这对于没有时间参加几整天实战工作坊的初级教练来讲，是一个非常不错的补充。

我们一般会把整个线上活动划分为 10 个星期，每个星期 1 个小时，让有需要的初级教练来参加，讨论一些基本问题，并在这个过程中加以引导，让他们主动发掘自己需要改进和提高的地方。和工作坊类似，在整个过程中，我们会让这些初级教练定制并实施自己的改进计划，在活动后分享大家的经验。

一对一的教练服务

除了基础培训和安排实战工作坊，高级教练还会为初级教练提供一对一的教练服务。

我们先请部门负责人对需要辅导的教练进行优先级排序。并规定：一位高级教练一次可以辅导两位初级教练，辅导完这两位初级教练后，再从待辅导教练池中“领”两位初级教练继续辅导。

辅导过程可以设计成以下 4 步：

签署教练协议。高级教练与初级教练会签一个教练协议，承认两人之间的教练关系，明确各自的职责与义务，比如说高级教练负责在这一段时间内辅导初级教练，而初级教练要承诺这一段时间能够参加教练活动等。

进行评估。高级教练会对初级教练进行一个简单的评估，包括 360 度的评估和一对一的访谈，借此了解该初级教练目前的水平，以便后面两人商讨教练计划。接着，高级教练要与初级教练商讨访谈的评估结果，以及他认为的初级教练所处的分级，据此与初级教练探讨教练计划，准备一个周期内（通常我们会把一个周期设定成 2 个月）要进行的改进，预设改进之后初级教练能够到达的层级。

一对一的教练服务。等两人达成一致后，就开始进行一对一教练服务。在这个过程中，高级教练或用 GROW 模型（G 为 goal 目标，R 为 Reality 现实，O 为 Option 方案、W 为 Will 意愿) 来引导教练对话，帮助初级教练发现自己的目标和可做的事情，引导他作改进；要么针对一些具体的技能，如观察初级教练组织的活动等，提供一些反馈，帮助初级教练进行改进。

成果展示。每个参加教练活动的初级教练，都要定期向大家展示自己新获得的技能或是给项目带来的改变等等。

一对一的专属教练服务会让初级敏捷教练更快地成长，也是他们成长为中高级教练更为专业的进阶方式。

以上我们讲的都是内部初级敏捷教练的培训方法，这其实是培养中高级敏捷教练的基础，我们当然也希望在初级教练中能逐渐产生一些中高级教练，这些教练不仅能看护好自己既有的小团队，也会为其它一些不好带的团队或者新团队提供帮助。

这里我再简单说说如何培养中高级教练。以我个人的经验而言，最好的办法其实是做咨询，多接触其它敏捷团队。

但我们是内部教练，没有太多机会做外部咨询，该怎么办呢？我想了一个办法，就是定期带一批教练来给一些团队的疑难杂症做诊断，出主意。比如说有其它团队来向我们内部的高级教练求助，高级教练在去支援时可以带几个初级教练一起去，大家一起考察和分析问题，这样，我们的初级教练就进一步接受了历练。这样在不断接触问题、解决问题，积累实践经验的过程中，初级教练就很可能会晋级为中级教练。

而从中级教练到高级教练，我们也提供了一定的培养路径。比如在整个 F 公司，我们还有自己的“核心教练培养”项目，每个月一次，可以跟着专业教练一起练习教练技巧。另外，对于高级教练，也会让他们组成一个高级教练组，每周开展相应的例会，分享大家的经验以及各自的工作进展。

总结

好了，今天的内容就讲到这里，现在我来梳理总结一下。

敏捷教练在整个敏捷推进过程中的作用不可小视，尤其是企业或团队自己的内部敏捷教练更为重要，他们可以在推进敏捷过程中为你的敏捷实践保驾护航，引导你的敏捷实践能顺利、正确地向前推进。

关于怎么培养内部敏捷教练，我建议你要重点关注初级敏捷教练的培养，这其实也就是通过基础培训培养他们“懂敏捷”的能力，通过实战工作坊、一对一教练服务等培养他们“能教练”的能力。在实践和交流中，在不断地提出和解决问题过程中，将初级教练培养成敏捷推进的中坚力量，甚至将他们进阶培养成中、高级敏捷教练，以便使我们的敏捷火炬在企业或团队内部不断被传承，不至于熄灭，甚至越燃越旺。

思考题

现在，结合今天这节课的内容，我想请你来思考一下，你有想过怎么培养自己组织内的敏捷教练吗？有自己独特又好用的方法吗？欢迎你来留言区与我一起讨论。

10 | 服务型领导：在敏捷中你该怎样提升自己的领导力？

你好，我是宋宁。

这节课我想来给你讲讲服务型领导。

之所以要讲这个话题，是因为在我做敏捷咨询的过程中，有团队领导曾经跟我表露过对“敏捷”的担忧，他想的是从前工业革命时，机器在一些岗位上取代了人，造成了一部分人的失业。那在敏捷这场新的变革中，强调团队的自我管理，身为团队的管理者和领导者会不会因此而失业呢？

这个团队领导的担忧有一定代表性，现在有很多人尤其是一线管理者都存在这样的职业困惑：在敏捷中，作为领导者和管理者，我该如何定位自己呢？

但其实你可以换个方式来看这个问题，工业革命时，确实存在本来属于人的岗位被机器取代这种情况，然而，机器在取代这些岗位的同时，也创造了更多其它岗位。

比如在第一次工业革命期间，蒸汽机带来的产业升级使原来传统的农业和家庭手工业崩溃，导致了一定程度上的失业危机；然而它带来的诸如铁路、造船和电力等重工业的兴起，又创造了一系列新的产业和工作岗位，极大缓解了失业危机。

所以，作为新时期的一场变革，敏捷固然会带来组织方式和文化理念上的各种改变，但与此同时，它也对原来的领导方式和领导力了新的要求，激励领导者革新管理方式，在敏捷这一新形势下持续提升自己的管理能力。

为什么你要成为服务型领导？

那在目前这样一个持续变革的社会中，或者说在敏捷实践中，我们更需要什么类型的管理者，更需要具备什么能力的领导呢？

你会发现，从工作形态上来说，我们现在要处理的工作变得更加复杂，因此如果使用传统的管理方式，那其中诸如僵化的管理方针、等级思维、冗长的决策方式等这些弊端就会被进一步放大，这在当下的工作环境中更加行不通。

所以如今，我们需要的管理方式和领导方式是，管理者和团队一起，在短时间内对新的市场要求做出快速反应。请注意“和团队一起”这几个字，这意味着现在只靠领导者一个人的“英雄主义”是远远不够的，领导者要有出色的协调能力，能聚人气，带领大家一起出谋划策，搞定复杂的工作。

而符合这种条件的新型领导者，我们称他为“服务型领导者”。

简单来说，这指的是领导者首先要是一个服务者，要为整个团队服务，拉近他与员工的心理距离，这样才会取得团队的信任。从管理目标上来说，他的目标是和团队成员共同成长，所以做任何事的首要动机都是为团队中大多数人谋取利益，由此团队成员才会更愿意跟随他，努力工作并取得整个工作的胜利。

说到这就不得不提 Herman Miller,Inc 的首席执行官 Max De Pree，在他的领导之下，这家办公家具制造厂销售额翻了将近三倍。谈到自己的领导方式，他曾简明又形象地说到：“领导的第一要任是要精确判断现实。最后是要说谢谢你。”表面上看，他拉下领导者的身段，由衷地感激员工的付出；而在这背后，实质就体现了服务型领导的管理理念：理解员工并为员工服务，与员工精诚合作。

怎样成为服务型的领导？

说完服务型领导者在如今工作环境中的必要性，接下来我来给你详细解读怎样成为这样的领导，怎样利用这样的管理理念达成工作目标。

给员工建立心理安全机制

首先，作为一个服务型领导者，给员工建立心理安全机制是必不可少的，只有这样，才能真正拉近与员工的心理距离，更好地达成团队目标。

那怎么建立心理安全机制呢？你可以从这 3 点来着手：

信任是必不可少的。要支持员工和他们的决定，在工作和工作之外都照顾好团队成员；

培养健康的分歧环境。允许分歧存在，在有分歧时虚心听取不同的意见；

建立正确的失败文化。失败是可以接受的，只要从失败中吸取教训，能够改进就好。

但只给员工建立起心理安全机制显然是不够的，要想为团队成员服务，更重要的是，你还必须掌握一套服务的章法，这就是情境领导能力，接下来我会结合一个具体的例子，为你详细解读这一点。

掌握情境领导能力

那什么是情境领导能力呢？简言之，就是领导者能在不同的情境下运用不同的领导力来指导和支持团队成员完成目标或任务。

情境领导力强调的是引导、激发团队一起做事儿。要想激发团队成员的能力、动机和信心，就要了解员工在特定目标和任务下所处的状态。

在实际工作中，领导者通常会面对 4 种不同的情境，或者说面对特定的目标和任务，团队成员会有下面 4 种状态。

情境 1：热情的初学者

情境 2：幻灭的学习者

情境 3：有能力但谨慎的贡献者

情境 4：自力更生的成功者

对应到每种情境中，它们也有各自不同的特点：

能力低、承诺高。这指的是情境 1 这类团队成员，对自己的目标或任务很陌生，缺乏经验，甚至不了解自己的知识和工作盲区。但他们有很高的学习意愿，有好奇心并且愿意接受指导，也很自信自己能够学会怎么做。

能力不是很高，承诺很低。这指的是情境 2 这类团队成员有一定的知识和技能，但还有所欠缺。然而，他的学习意愿很差，随时都有气馁和沮丧的情绪，随时可能准备放弃。

能力处于中上等、承诺很低。这指的是情境 3 这类团队成员，对于这个特定的目标或任务是有能力并且有经验的。但是他不是很自信，偶尔会犹豫不定，觉得自己的任务很无聊，甚至对目标漠不关心。

能力高、承诺高。这指的是情境 4 这类团队成员，有足够的能力，能够胜任交给他的工作任务。他非常自信，也能鼓舞别人。

作为管理者，首先你要能识别出这不同的 4 种情境，识别出来之后，再匹配不同的领导风格。领导风格在工作中是用领导行为来体现的。

一般来说，有两种基本的领导行为：

指导性行为：告诉他人应该做什么，何时做，如何做，并经常提供结果反馈；

支持性行为：鼓励、表扬他人自力更生解决问题，倾听意见，并让他人参与决策。

针对上面 4 种不同的情境，两种基本领导行为在经过权重高低的分配和组合后，也就形成了 4 种不同的领导风格，下面我们来看针对每一种情境下的团队成员，应该使用什么样的领导风格。

风格 1：指导。高指导行为和低支持行为。领导者通过讲述和展示，具体指导员工如何达成目标，并密切跟踪员工的表现，频繁地进行反馈和指导，让员工能够顺利地完成目标。它的的目的是帮助情境 1 的员工建立起必备的工作技能。

风格 2：教练。高指导行为和高支持行为。领导者对员工解释目标或任务，征求员工的意见，鼓励、引导并持续指导员工完成目标；随时让员工积极参与到问题中来，协助他一起解决问题。对员工不会做的部分，领导者会亲自示范；在员工做的过程中，领导也会在员工需要的时候随时提供指导。它的目的是重新激发情境 2 的员工的工作热情，提高他们的工作能力。

风格 3：支持。低指导行为和高支持行为。针对情境 3 的员工，领导者通过提出开放式问题来促进问题的解决，通常只是询问他的做法，不多加干涉，倾听和鼓励他的工作，引导他一起参与做决定。它的目的是激发情境 3 员工的信心。

风格 4：授权。低指导行为和低支持行为。对于情境 4 的员工，领导者认可他的专业知识，鼓励他的自主性，并邀请他持续学习和不断创新。它的目的是珍视员工的贡献，最大限度地发挥员工的潜能。

上面我从理论上给你讲了 4 种情境中的员工，以及具有针对性的 4 种领导风格，只讲理论估计你听起来会比较迷糊，接下来我用一个领导让员工小李泡茶的例子，形象地给你讲解一下这些内容。

这个例子的场景是这样的，L 公司的办公室来了位非常重要的客人“孙总”，他对 L 公司非常重要，决定着该公司下一次融资能否顺利进行。他喜欢喝西湖龙井，公司的领导“兰总”想让员工小李为孙总倒一杯热茶，兰总该怎么做才能让小李招待好孙总呢？

先来看情境 1 与风格 1。

假设小李是位年轻的二十多岁的毕业生，刚刚来到公司，对茶一无所知，之前也从没见过孙

总，但他热情肯干，那兰总遇到的就是情境 1 的员工，即“热情的初学者”。

要想指导好他，兰总就会用第 1 种指导型的领导风格，这样和小李说：“小李啊，孙总是咱们的重要客户，他喜欢喝龙井茶，你来帮他泡杯茶吧。”说完要做的事儿，然后具体指导他：“龙井茶在左边的柜子里，先用桌子上那个蓝色的茶壶泡。水烧开后晾一会儿，85-95 度的水温最合适。泡完了叫我过去看一下。”

小李听把茶泡好后告诉兰总，兰总点点头：“不错不错，干得很好。”然后指导小李另换了一个漂亮的茶杯，并在茶盘上放了餐巾纸，送给孙总。

接着来看情境 2 与风格 2。

假设小李已经在公司呆了一段时间，以前也给别的领导泡过茶，但没泡过龙井茶，也不喜欢给领导泡茶，那么他此时就是情境 2 的员工，即“幻灭的学习者”。

此时兰总就要用第 2 种教练型领导风格，这样和小李说：“小李啊，孙总是咱们的重要客户。他喜欢喝龙井茶，你来帮他泡杯茶吧。帮他泡茶容易跟他拉近关系，对未来你跟他的接触也有好处，未来你们还要一起工作。”先说要做的事儿，但不仅说事儿，还把做这事儿的意义说清楚。

然后鼓励他：“你以前泡过茶，泡起来没问题的。”接着提问题引导他：“龙井茶用多少度的水温来着？”如果小李说不知道，那就接着引导他去做：“你上网查查呗。”然后继续询问：“你准备用哪个茶壶和茶杯啊？”小李说：“蓝色的茶壶和旁边那套白色骨瓷杯子。”兰总表示认可，并在小李泡完茶之后过去看一下，对他的工作表示肯定。

再来看情境 3 与风格 3。

假设小李会泡龙井茶，但是很害怕见领导，没有自信，那小李的状态就属于情境 3，即“有能力但谨慎的贡献者”。

此时兰总就要用第 3 种支持型的领导风格：“小李啊，孙总是咱们的重要客户。他喜欢喝龙井，你来帮他泡杯茶吧。孙总这个人啊，人特别好，平易近人，对人很客气的。”这里，兰总不仅讲了要做的任务，还给小李打消了思想上的包袱。

兰总看小李神情缓和下来，接着继续鼓励他：“小李啊，我知道在咱们公司龙井茶你泡得最好，赶紧去吧，泡完了端给孙总，有什么问题，随时来找我。”

最后来看情境 4 与风格 4。

假设小李既会泡龙井茶，又很自信，热情能干，他就属于情境 4“自力更生的成功者”。

那兰总就会用第 4 种授权型的领导风格，这样和小李说：“小李啊，孙总是咱们的重要客户。他喜欢喝龙井茶，你来帮他泡杯茶吧。我相信你能做得很好，去吧。”说完任务后，直接让小李自己去干，全程不用关注。

等小李泡完茶回来，兰总又说：“小李啊，你这个泡茶的技术很好，等回头给行政部的那几个小伙子都培训一下哈。”这样既认可小李的成绩，又给他创造机会，将自己的本领分享给别人。

我相信通过兰总让小李泡茶的例子，你会具体又形象地了解，针对不同的情境，怎么使用不同的领导风格，和员工进行不同的对话。

这里我还想再强调一下，你可以通过下面这 3 点用好情境领导力：

设定目标。要运用好目标管理，设立正确的目标，目标的设定要与需要做的事情保持一致；

协同诊断。要会评估员工在特定目标或任务上的能力和承诺，判断员工在这个目标或任务上属于哪一种情境；

学会匹配。根据员工所处的情境，匹配自己所需要运用的领导风格，帮助他们实现工作目标或完成工作任务，也为他们个人提供需要的帮助。

总结

好了，讲到这里我们这节课又结束了，现在我来总结一下今天的主要内容。

在如今变化快速的环境尤其是敏捷的环境中，要想做好一个管理者和领导者，一定要具备“服务型领导”的能力。服务型领导的核心是团结员工，形成凝聚力更强的团队。

作为一个服务型领导者，首先要从内心里有服务意识，要给员工营造安全的心理环境，拉近与员工的心理距离。还要有足够的能力来从语言和行动上让员工感受到他们是被关怀的，这就需要掌握情境领导力，针对不同的情境，使用不同的领导风格。

正如恋人间的恋爱一样，不能“爱在心头口难开”，要大胆的将内心的爱表达出来，让对方感知到。在服务型领导这一管理方式下，领导者与员工之间的关系也是如此，领导者对员工的关心也需要用对话和行动表达出来，唯有这样，员工才能够感受到你对他的支持与帮助，才能够更好地与你协同合作，共同达成组织的目标，同时也更能获得个人的成长。

其实，虽然我们这节课讲的是敏捷中的一种领导方式，但它其实更是一种沟通方式、合作方式，关注人、强调合作本就是敏捷与生俱来的内容，也是做好敏捷的关键。所以不论你是想用或正在使用敏捷的领导者，还是想成为领导者的程序员，抑或是普通的团队成员，如果你想尝试一下领导者的角色，或者转换一下自己的工作方式，那么我都鼓励你学好服务型领导这一新型的领导方式，我相信它一定会给你带来工作和思维上的帮助。

思考题

现在，结合今天的内容我想请你来思考一下，你在实际工作中会怎么运用情境领导力呢？你认为还有其它更有效的管理方法吗？欢迎你来留言区跟我一起讨论吧。

结束语 | 用敏捷提升自己，从敏捷走向未来

时间过得真快，不知不觉中，你已经学完了整个课程。敏捷的内容有很多，在写之前我就一直在想，如何在这短短的只有十篇的小专栏里，把我对敏捷的思考呈现给你。

最后，我按照“为什么 - 是什么 - 怎么做”这样的方式组织了一下，并结合了大量的案例，将这么多年来我对敏捷的独特看法讲给了你。我相信通过我们专栏的学习，你一定会有所收获，但我觉得，今天课程的结束不是终点，而是你学习路上的新起点。

前几天我在上教育心理学课时，老师让我们大家思考这样一个问题：在未来的智能化社会，我们需要培养什么样的人才？这些人才需要什么样的能力？

讨论到最后，大家一致认为，未来的人才一定要具备这 6 大能力：健康力、交往力、学习力、专注力、批判力和创造力。

健康力让人的自然生命更长，交往力让人的社会生命更宽，学习力让人的学习生命更高，专注力让人的事业生命更深，批判力让人的思维生命更广，而创造力让人的精神生命更精彩。

毫无疑问，我们已经进入了人类第四次工业革命，这次工业革命中涌现了很多新科技（如 AI 等），而且发展迅猛。在这样的世界里，唯一不变的东西应该就是“变”。面对这样变化飞快的世界，我们该怎么来应对呢？

敏捷其实为我们提供了一种很好的应对方式，通过敏捷，我们可以很好地提升自己的能力。

在敏捷的价值观和原则中你可以看到，敏捷强调人与人之间的合作，设计合作型的组织，做合作型的实践，甚至到了领导力这一层面，也强调了领导与员工的合作，通过合作不正是可以提升我们的交往力吗？

敏捷也强调终身学习，不断改进，这恰好可以对应到学习力上；敏捷还强调契而不舍，这也就是专注力；此外，敏捷也非常重视创造力，敏捷环境的营造本身就适合培养创造力。

敏捷也强调思辨，强调接纳不同的意见，如果你还记得我对服务型领导者的讲解，也就一定会记得服务型领导会给大家营造允许分歧的环境，还有什么比这更适合培养批判力点呢？

通过上面的分析你能看到，通过实践敏捷，可以培养出 6 大能力中大绝大部分能力。这是不是也意味着，在未来，敏捷本身就变成了一项人才需要具备的基本能力？所以了解和学习敏捷，也许是我们未来工作的一个基础内容。

在我们这个专栏中，使用的案例基本都源自软件研发领域，然而敏捷虽从软件研发中来，却并不止于此，对敏捷的使用已经远远超出了这一行业，因为敏捷的很多思想，都可以在很多领域和工作中发挥价值。

所以，我并不是想让你全盘接受敏捷，也不是让你在一切工作中非用敏捷不可，相较于具体的敏捷方法，我始终在强调敏捷思维。我越深入学习敏捷，我越明白，敏捷学习的高阶程度不是你学会了几种实践方法，而是你真正掌握了这背后的敏捷思维，并且能用这些思维来助益你的工作和生活。

再举一个简单的例子，在敏捷中，有一个思想是“做得多不等于价值大”，那我是怎么理解这个思想并把它用到我的工作中呢？

以前我的工作习惯是，不管能不能做完，一股脑去做所有的事情，结果发现工作应接不暇，自己每天都很忙，身心俱疲，压力也很大。

在敏捷这个思想引导下，我开始思考：“我做的事情价值大吗？”接着我把自己所有的工作都记下来，放到 Jira 上，形成一个“工作池”，然后按照价值大小对这些工作按优先级排序。

这样我每天来到公司，就不是像过去那样立马开始着手做工作，而是先统计下今天都有什么事情要做？这些事情哪些价值较大，哪些价值较小？排完优先级后，先做完价值较大的事情。每天下班时再总结一下，看看今天有什么收获，有什么值得注意的地方，把它们记在自己的工作笔记里。

这样每天坚持下来，虽然我的工作时间没有延长，但由于我优先做价值大的工作，一方面增强了自己的成就感，另一方面也确实提升了自己的绩效，我处理工作也就更加游刃有余了。后来在我做敏捷咨询的过程中，我一个人能抵 1.5 到 2 个敏捷咨询师，我惊讶于自己的变化。

敏捷同样给我的生活带来了一些变化，它像是一扇门，借由它，我能使自己一直保持对世界的好奇心，我的思想也更开放，并对生活始终怀抱着积极的心态。

比如我现在依然愿意尝试学习新事物，作为一个职场妈妈，我学习钢琴、绘画、法语、滑冰等一切我感兴趣的事情，并乐在其中。这是敏捷带给我的精神财富，它拓宽了我的精神生命。

其实这样的例子还有很多，我希望你在学习这个专栏后，除了掌握敏捷实践的方法，也能自觉利用敏捷思维来帮助自己的工作和生活，你一定会切实感受到它的好处。

我相信，如果你能用好敏捷，并将敏捷内化为你自己的思维方式，那么对于未来，你将会有很强的适应能力和应变能力，你也一定能激发内心的能量，不会畏惧未来世界的变化，创造出属于自己的未来！

最后，我为你准备了一份结课问卷，题目不多，2～3 分钟即可完成。希望你能畅所欲言，把自己真实的学习感受和对我们课程的意见表达出来，我一定会认真看。

成功提交问卷的同学，将有机会得到由极客时间商城独家销售的“数据结构与算法知识地图”或者价值“99 元的专栏兑换阅码”，算法地图共有 3 个名额，阅码共有 2 个名额，期待你的反馈。

当然，如果你对专栏内容还有什么问题，也欢迎你在留言区继续提问，我会持续回复你的留言，感谢你的关注与学习。