mod

极客时间专栏/说透敏捷/原理篇/01 | 灵魂拷问：如何利用敏捷思维更好地解决实际问题？.md

@@ -0,0 +1,92 @@
+<audio id="audio" title="01 | 灵魂拷问：如何利用敏捷思维更好地解决实际问题？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/10/ed/106fd63fe4d3f3c4b190d0c43d3ec8ed.mp3"></audio>
+
+你好，我是宋宁。
+
+今天是我们的第一节课，在给你讲怎么做敏捷之前，我想先用几个案例给你讲讲它的价值。
+
+最近几年，敏捷在国内推进得如火如荼，很多公司的研发团队都在使用它，并且尝到了这里面的甜头。但也有些公司，看别人做得挺好，就照搬过来，结果却并不奏效；由于探索得不是很成功，他们就觉得敏捷不好用，不适用于自己的公司，也开始怀疑它的价值。
+
+作为一个过来人，我想谈一下我的看法：我认为敏捷确实是很好的，只是推进它也确实不容易。
+
+为什么这么说呢？这是因为，敏捷毕竟是一场变革，它本身涉及了很多有关人的因素，比如说人的习惯、团队文化的改变等等；而且它的核心点是持续改进，可以说是一场没有终点的旅行。况且它有一定的章法，但是你若想运用好它，又不能拘泥于它的章法；如果你只是了解它的表面做法，就开始邯郸学步，那你注定会失败。
+
+因此在这节课里，我更想让你了解的是敏捷的思维，理解透了这一点，你自然就能够把它融会到工作中，举一反三。但是切记，千万不要为了敏捷而敏捷，所以我也并不是想说服你必须全盘使用敏捷，如果你觉得敏捷方法很多、有些繁杂，不是所有都能用得上，那你完全可以从中借鉴一些好用的去解决你的实际问题。总之，不管用什么方法，只要能更好地解决问题就可以了。
+
+接下来我想和你讲一个故事，来具体说明下为什么我觉得敏捷很好。
+
+记得那是2007年~2008年，我们有一个项目是负责某大型通信公司印度尼西亚工厂的SAP实施。在简单了解需求之后，我们制定了项目初步计划，包括预算、人员安排和进度计划等等；目标是用10个月完成项目，这又包括了需求调研、开发、测试、上线以及用户培训。
+
+我们的项目经理很资深，公司也有一套成熟的项目管理模式，于是我们就按照公司规定的项目管理规范来开展工作。
+
+我们花了1个月的时间进行项目的前期筹备，包括组建团队。之后，我们花了2个半月的时间做完了需求调研，又花了3个月做开发，开发完成后交给测试，测试花了2个月完成，然后交付给客户来验收。验收之前，我们仿佛看到了胜利的曙光，就等着办庆功宴了。
+
+没想到，噩梦才刚刚开始。当客户看到系统并真正试用时，才开始觉得这也不行、那也不可，提了大大小小50多条修改意见。记得当时验收会议结束时，客户相当不满意，就差拍桌子了。
+
+在接下来的日子里，我们的工程师开始加班加点地改，项目经理和需求工程师还有技术负责人去跟客户斡旋那些改不掉的需求或问题。等项目真正上线时，工期比预计延期了50%，预算也超支了不少。所以项目最后虽然上线了，但整个过程客户相当不满意，用他们的话来说，这是勉强上线。
+
+好了，说到这里，你可以停下来想想，上面我说的那个项目到底有什么问题呢？到底是什么原因导致了它的失败呢？
+
+之后我也一直在思考这个问题，但直到我明白了研发模式中瀑布模式和敏捷模式的差别，才真正找到了答案。
+
+上面那个项目它采用的研发模式就是典型的瀑布模式，也就是说，研发的整个工作流程都是按顺序进行的。整个项目过程，要先做需求调研，然后再做开发和测试，最后才能验收和上线，在这个过程中，所有的工作都是串行的，只有达到下一步的准入标准，我们才进行下一步工作。
+
+瀑布模型是在1970年由温斯顿·罗伊斯（Winston Royce）提出来的，并且一经提出即被各大公司拿来当作标尺使用，在20世纪80年代，它更是狠狠火了一把。原因就在于它简单粗暴容易推广，在没有其它更好的研发管理理论情况下，使用它无疑比没有管理套路，让研发项目野蛮生长要好得多（如果你想了解更多，可以阅读极客时间的[软件工程专栏](https://time.geekbang.org/column/article/83598)）。
+
+然而，瀑布模型被广泛投入使用之后，真正的一线开发人员却备受束缚，研发效率反而受到阻碍。后来，就连提出它的温斯顿都承认说：“在我的经验里，瀑布模型在大的软件开发中从没真正起到作用”。
+
+在项目实践过程中，瀑布模型经常在以下3个方面饱受诟病：
+
+1. **研发周期过长，导致研发跟不上业务发展的节奏。**在瀑布模型中，所有的工作都是串行的，只有前序环节完成后，才能展开后序环节，大量的人力与时间成本就在这段时间里被白白消耗掉了，等产品开发出来再推向市场，很有可能市场已经没有了，或者业务已经发生了很大变化。
+1. **研发不能很好地响应需求变化，导致客户满意度低。**要知道，我们很难在设计之初就把所有的需求都想清楚，而需求又是不断变化的，因此客户在看到真正的产品出来之前，对产品很可能是无感的，正如上面项目中的客户，他们在看到并试用了产品后才觉得这里应该这样，那里应该那样。瀑布模型是直到项目最后，才一次性地向客户交付产品，当产品被开发出来之后，客户才发现他们需要的不是这个东西，这是非常可怕的事情。
+1. **不能很好地管控风险。**这是因为研发到最后才一次性交付产品，所以项目中很多风险在前期很难被完全识别出来，那等到最后发现时再想处理，就要付出更大的代价了。
+
+那么，为什么“瀑布模型”会存在这些问题呢？
+
+如今我们回过头来看会发现，软件研发和传统的生产管理不同，它的产出物具有强烈的不确定性。而瀑布模型，其流程和步骤都是规定好的，而且计划与生产分离，说白了更适合确定性高的工作。那么在不确定性很高的研发工作面前，我们以处理确定性高的工作的方式和流程来管理它，毫无疑问是不奏效的。
+
+因此，自20世纪90年代起，软件业界就陆陆续续有很多大师开始探索新的、轻量级的、适合软件研发的管理方法。2001年，他们聚集在美国犹他州，将他们共同的方法高度提炼了一下，这就是“敏捷宣言”。
+
+那么回到上面那个项目，如果我当时能用敏捷的方式来进行研发，或许就不需要延期那么久，预算也不需要超那么多，客户也就不会一直阴沉着脸了。再反思一下这个项目，如果现在让我重新做一次，我至少会选择下面这4个点来进行改进：
+
+1. 从大的组织结构来讲，我们的团队应该组成一个个小的特性团队，团队是固定的，团队成员也要基本是固定的，这样项目来的时候我就不需要再花费那么长的时间去组建团队、磨合团队了。
+1. 从需求梳理的过程来看，我不会一次花2个半月去梳理需求，并且在最后才给客户看我们梳理的结果，我会边梳理边跟客户交流。
+1. 我会把需求按优先级排序，形成需求池，迭代地进行研发。
+1. 我会让客户积极地参与我们的研发过程，包括前期的需求调研梳理和后面的开发测试上线，在迭代有产出时就让客户来验收，让他们提意见和建议，以便我们在后面的迭代中随时调整。
+
+有了上面的经验，在我后面的项目中，我就真正地去尝试使用敏捷，并且我也切身感受到了它带来的好处。现在我就再和你讲一个我亲身经历的、一家初创公司敏捷实践成功的故事。
+
+那是在2012年，我到一家初创公司去做项目管理。这家公司的研发中心有七十多人，我一到任，就听到来自业务部门的各种抱怨。在和他们业务部门副总交流时，他对我说：“宋经理，你们研发部门交付特别慢，一个需求我们要等好几个月，等做好了，我们的推广时机也过了。做得慢不说，做的东西也真是不怎么好，做好了给我们看时，我发现做的根本不是我想要的东西……”他给我讲了一通问题，并殷切希望我的到来能给公司的研发带来新的改变。
+
+我决定在接下来的一周，调研一下，看看怎么应对。看了一圈，我发现这个研发中心在刚开始运作时没有任何流程，也没有任何章法，研发过程很随意，出了很多生产Bug。于是在公司总经理的要求下，大家做了一套流程，本想认真执行，结果执行下来效果也不好，不仅交付速度变慢了，做的需求也不符合业务的要求。
+
+怎么回事儿呢？原来他们用的是瀑布模型，有了前面的经验，我说服了公司领导，带着这个研发中心做了敏捷转型。
+
+那么，我是怎么做的呢？我先给研发中心和业务部门的所有人都做了培训，又将组织做了变革，将他们分成了一个个特性团队；接下来，我把大需求拆分成小需求，对需求列表进行梳理，排列优先级；最后，我又让业务部门参与进来，迭代地进行研发，每个迭代结束后交给业务人员验收和提反馈。
+
+使用敏捷后的效果还不错，我们的需求流动快了，研发效率提升了，Bug减少了，业务部门满意了，还博得了公司总经理的赞许。
+
+上面就是我的一些项目经验，相信你已经感受到了做敏捷带来的好处，事实证明也确实如此。我们可以看一下业界的统计数据，根据VersionOne的最新统计，97%的受访者都报告他们的组织采取了敏捷这种开发方式。公司在提升自己的交付能力，提高响应变化的能力，改善协作、减少项目风险等时候，都想到了采纳敏捷，并在这个过程中艰难地探索着。
+
+说了这么多，也许你会说，敏捷听起来是挺好的，但我还是觉得我们公司用不上。关于“敏捷到底怎么用”这件事，我会在后面的课程里为你一一解答。这里我想说的是，**其实有很多公司，他们都在有意或无意中使用了敏捷的一些实践。**Google就是一个典型的例子，虽然它不对外标榜自己在做敏捷，但其实，你可以在他们的文化或项目中随处看到敏捷的影子，比如说他们的工程师文化，跟敏捷倡导的以赋能和信任个人为中心的文化，就是非常契合的。
+
+**类似Google这样的公司其实不在少数，虽然它们并没有全盘采纳敏捷的所有方法，但是在其做事的方式上，却多少都体现了敏捷的思想，他们在用敏捷的思想来改变自己的一些行为，来达成公司的目标。**
+
+比方说，有的公司会考虑加快反馈循环来提升流转效率；有的公司会把自己所有事情按照价值和优先级来排序，定期整理自己的工作列表，就像管理产品待办事项列表一样来管理工作，让员工把精力放在更有价值的工作上；还有的公司引进了很多在线协作管理工具来加强协作。
+
+**所以，是否打着敏捷的名头，是否冠以敏捷，这本身是无所谓的，只要我们能够用到敏捷的一些方法来帮助到自己的公司或项目就好。**
+
+## 总结
+
+凡事都有两面，敏捷也不例外。前面我花了很大的篇幅带你了解了很多敏捷的益处，但它也不是万能的，不是所有的问题都能用它来解决。比方说产品本身的容错率就很低，不允许试错，用敏捷的话就会使投入和产出不成正比，这就不必非用敏捷来做了；或者说公司需要深远地考虑战略问题，那么如果想通过导入敏捷把战略思考省略掉，而不去考虑布局，这也是不现实的。
+
+另外，说到敏捷不利的地方，我觉得主要的问题就是它“听起来简单，但实施起来并不容易”，它还是具有一定的复杂性，这也是为什么它虽然被提出来将近20年，但直到现在，在落地的过程中，还是有很多的争吵和讨论，也还是有很多人在不断地摸索。
+
+但不管怎么说，我还是觉得积极吸纳敏捷带来的好处都远超你的想象。毕竟我们现在已经进入了VUCA时代，我们正面对着一个易变（Volatility）、不确定（Uncertainty）、复杂（Complexity）和模糊（Ambiguity）的世界，而敏捷快速响应变化、允许试错、小步快跑的特点无疑是很能应对时代变化的。
+
+从我的角度来说，我希望通过这个专栏课程，帮你澄清一些对敏捷的误解，让你可以深度了解敏捷背后的意义和原理，了解它的一些做法，并能让你结合你自身，或者公司和项目的特点，结合你的痛点，借鉴到它的一个或者多个方式，来帮你完成预期目标，那么我的目的就达到了。
+
+## 思考题
+
+结合我们今天讲的内容，我想请你来思考一下，你在研发过程中碰到过哪些难以解决的问题呢？你有过利用敏捷思维或敏捷方法解决实际问题的经历吗？
+
+我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

极客时间专栏/说透敏捷/原理篇/02 | 老生常谈：你真的知道敏捷到底是什么吗？.md

@@ -0,0 +1,140 @@
+<audio id="audio" title="02 | 老生常谈：你真的知道敏捷到底是什么吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d5/23/d56c9ecbd7ef118f2c33cb4ab6b86d23.mp3"></audio>
+
+你好，我是宋宁。今天这节课，我要给你讲一讲到底什么是敏捷。
+
+当我们谈到敏捷时，大家往往是仁者见仁，智者见智，有各种不同的理解。然而这里面，有不少是对它的误解，在我平时做咨询的过程中，经常会听到一些团队成员这样说它：
+
+- 敏捷来了，太好了，我们只要负责开发软件就够了，再也不用做文档，也不用做设计了；
+- 敏捷就是快，原来要6个月才能完成的项目，用了敏捷后，周期就可以缩短到3个月了；
+- 敏捷就是加班，用了敏捷后，由于在迭代结束时一定要完成当初的目标，所以我们加班比原来更严重了；
+- Scrum就是敏捷，敏捷就是Scrum，这俩是同义词；
+- 敏捷是自由的、无约束的，不需要那么多条条框框，随自己的心情来做就好了。
+
+上面这些说法，我相信你多少也都听说过一些，但它们其实都是对敏捷的误解。如果你带着这些误解去做敏捷，那很可能会做得一塌糊涂。所以作为一个过来人，我想我在给你讲怎么做敏捷之前，有必要先给你捋一捋到底什么是真正的敏捷，以便你能正确地理解它。
+
+在我看来，**大家之所以对敏捷有那么多的误解，归根结底，是忘记了做敏捷的初心，忘记了它的价值观和基本原则，而只是把注意力集中在怎么做上。**
+
+所以你要想真正理解敏捷，就要从它的价值观、原则以及具体的方法和实践上，对它有一个全方位的认识，只从任何单一的方面去了解它，都像是盲人摸象，是片面的。
+
+## 敏捷的价值观：正确理解敏捷的初心
+
+我们先来看一下敏捷的价值观。2001年，17个轻量级方法论的大师在美国的犹他州，发布了敏捷宣言，阐释了它的5条价值观：
+
+1. 个体和交互**胜过**过程和工具。
+1. 可以工作的软件**胜过**面面俱到的文档。
+1. 客户合作**胜过**合同谈判。
+1. 响应变化**胜过**遵循计划。
+1. 虽然右项有价值，但我们更重视左项。
+
+请注意这5条价值观中的最后一条：“**虽然右项有价值，但我们更重视左项。**”这一条其实是对前4条的解释说明，然而很多人在传递这些价值观时，其实只讲了前面4句，而忽略了最后这一句，很大程度上，这导致了大家对敏捷的误解。
+
+那么结合这一条来看，前4条中“胜过”这两个字就可以解释为，**与每一条中右面的内容相比，左面的内容是敏捷更加重视的，但要注意，这并不是说让你停止做右面的内容。**
+
+以“敏捷来了，我们再也不用做文档了”这个误解为例，结合敏捷的价值观，我们来看看对它的误解到底体现在哪里。
+
+价值观的第2点是这么说的：“可以工作的软件比面面俱到的文档更加重要”，但这并不是说我们就完全不要文档了。对这句话的正确理解应该是：**敏捷重视可工作的、有价值的软件，减少一切不必要的文档。注意，是不必要的文档，而不是所有文档。**
+
+那么对于一个项目来说，什么样的文档是没有必要的文档呢？
+
+比如说一些交接类的文档。开发人员在开发完成后要提交给测试部门测试，需要写一个提测单，再一级一级批复，我认为这样的文档就是可以省略的。因为在敏捷里，开发人员和测试人员是在一起工作的，所以提测的工作不需要走如此麻烦的申请和审批；开发人员需要提测时，直接在软件上点击一下“提交”，再告诉测试人员一下就足够了。
+
+那么，什么又是有必要的文档呢？
+
+比如说一些写着重要设计方案的文件。如果系统在后期遇到了问题，你就要回头查看这类文件，找出问题所在；或者是系统后期开发完成后，需要转交给其他同事维护时，他们若想知道这个系统当初是怎么做的，也需要去查看当时的系统设计文档，所以这类设计方案是需要保留下来的。你可以根据自己的项目情况，考虑哪些是重要的文档，哪些是不重要的。
+
+所以说，**敏捷的价值观并未否定或贬损“右项”的价值**，“流程和工具”“ 详尽的文档”“ 合同谈判”以及“遵循计划”这些右面的内容也很重要，在敏捷里并不是完全不做。比如在敏捷实践中也是有计划的，只不过它计划的方式与传统瀑布模式的计划方式不一样罢了。
+
+敏捷的价值观体现了敏捷的初心，只有正确理解它，你才能更深层次地理解敏捷。它的初心是通过一系列方法来让我们的研发工作更加灵活、有序和高效，所以它的价值观重视人的能动性，强调人与人之间的协作，也更重视对变化的应对，这些都是为了能够更好、更灵活地组织和管理研发工作。
+
+但如果“流程和工具”“详尽的文档”“合同谈判”以及“遵循计划”，同样能让研发工作更有序和更高效，那敏捷是不反对的，也不会放弃不做，这才是敏捷的真谛。
+
+## 敏捷的原则：正确理解敏捷的基石
+
+上面我带你重新理解了敏捷的价值观，但对于它来说，只有价值观还不够具体，为了能更具体地指导工作，由它的价值观又引出了12条原则：
+
+1. 我们最优先要做的是，通过尽早地、持续地交付有价值的软件使客户满意。
+1. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
+1. 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
+1. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
+1. 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
+1. 在团队内部，最具有效果并且富有效率地传递信息方法，就是面对面地交谈。
+1. 工作的软件是首要的进度度量标准。
+1. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
+1. 不断地关注优秀的技能和好的设计会增强敏捷能力。
+1. 简单——使未完成的工作最大化的艺术——是根本的。
+1. 最好的构架、需求和设计出自于自组织的团队。
+1. 每隔一定时间，团队会针对如何才能更有效地工作进行反省，然后相应地对自己的行为进行调整。
+
+这12条原则是正确理解敏捷的基石，所以在这里，我会结合开篇那几条对敏捷的误解，对这其中的几条原则做个详细的解读。
+
+有一个误解是“敏捷就是快”，你要注意，在敏捷的原则里，可从来没有说过这句话。所以你需要正确理解“快”这个词。
+
+如果你将“快”理解为用了敏捷以后，你的代码编写速度就立马加快了，那是非常不现实的。虽然在敏捷中，我们也会用到一些方法来训练整个团队的代码编写能力，但这并不意味着，程序员敲代码的速度就得到了显著提升。况且，即使敲代码的速度加快了，项目整体上线的速度就也一定能加快吗？
+
+那么敏捷在交付上会带来什么变化呢？你可以先看一下原则中的第1条和第3条，总体的意思是：敏捷希望能尽快把可用的软件持续性地交付给客户，交付的时间越短越好，而不是最后才一次性地交给客户。
+
+所以说，**敏捷中的“快”其实指的是反馈更快，反馈更及时。**这样，我们就能更快、更准地得到客户的真实反馈，也能尽早修正。在这个过程中，客户也可能会更早一点想清楚自己要什么样的产品，你也可能更早达成客户的目标（这里你也要注意，是有“可能”，而不是“一定”）。甚至，由于客户比预计的时间早些看到了产品，他觉得很满意，结果可能比大家预想的上线时间都要早。
+
+但这绝不是通过快速写代码来完成的，而是通过不断检视客户的需求，总是优先做最有价值的事和减少浪费来完成的。在瀑布模式下的项目管理过程中，我们把原计划的事情全都做完后，项目也就结束了；而在敏捷的原则下，只有完成客户的目标，项目才可以结束。这是因为，敏捷是以业务价值和业务目标为导向的，在这个导向下，短迭代使客户更清楚自己的需求了，不必要做的事情减少了，所以时间才减少了，交付也就更快了。
+
+我们再来看看“**敏捷就是加班**”这个误解。你可以回到前面的原则里，重新看第8条，你可以清晰地看到，**敏捷强调“可持续的开发速度”**。
+
+这指的是团队要能一直以稳定的开发速度持续下去，而不是为了加速开发，本次或几次迭代一直加班，透支团队成员的健康，这么做反而会因为员工身体不支，导致接下来的迭代开发产能下降。你要想一想，如果天天加班，员工能否能一直保持高昂的斗志和较高的工作效率？你能保证一直可以用这样的开发速度开发下去？我想这是不行的。
+
+那怎么才能保持“可持续的开发速度”呢？我看到能做到这一点的开发团队，通常都是这样做的：
+
+1. 他们在迭代开始的时候，不会过度承诺，也就是能完成多少工作，就承诺多少工作。
+1. 严格遵守纪律。他们在迭代开始以后，原则上不会再增加需求，如果一定要往他们的迭代待办事项列表里增加其它需求，就要同时从中拿走等量的需求。
+
+这么做有什么好处呢？我认为这可以使开发团队聚焦在自己的事情上，不受干扰，效率更高，这样就能形成稳定的开发节奏；而稳定的开发节奏可以加强我们的预见性，这样我们预计的上线时间才可能是精准的。
+
+所以，如果你的团队用了敏捷以后加班更严重了，那么我建议你参照上面的做法来自我检视一下，看看你的团队是否在一个迭代中承诺了太多事情，也就是工作范围是否太大了，如果是的话，那你可以结合团队的实际产能，根据需求条目的优先级来进行调整；此外，还要看你的团队是否遵守了纪律，如果不遵守纪律，那额外的加班肯定是不可避免的。
+
+现在，我们再回过头看看敏捷原则里的内容，你会发现它和敏捷宣言一样，重视研发各方的协作，并强调了持续改进、响应变化。只不过在这12条原则里，对敏捷重视的价值做了更细致的阐述，也涵盖了软件项目管理的所有基本流程，而且这些流程又很具体，让大家有了更可以参考的标准，将价值观落实到具体的、可操作的原则之上。
+
+因此正确理解这些原则，并以此为基准去做事，才能在后面具体的敏捷实践中不偏离，最终取得项目的成功。
+
+## 敏捷的方法：正确落地敏捷的基础
+
+但很显然，只有价值观和原则，敏捷是不能落地的，你还需要一系列的方法来推进它。
+
+在当初提出敏捷这个概念的时候，建立敏捷联盟的17位大师就创立了一些敏捷方法，这包括极限编程、Scrum、特征驱动开发、动态系统开发方法、自适应软件开发，以及水晶方法等等，这些方法被统称为敏捷方法。到现在也出现了很多关于规模化敏捷的方法，比如说SaFe和Less；也有很多技术实践，比如说测试驱动开发等等。**可以这么说，凡是符合敏捷价值观和原则的方法论，都可以归到敏捷的大伞下。**
+
+怎么样，这么一看，敏捷是不是包罗万象？但方法虽然很多，你一定要结合自己的需求来选择。所以在这里我想和你强调的是，**这些方法从共性上来说都遵循了敏捷的价值观和原则，不同的是它们针对了不同的应用场景**，比如说Scrum在新软件开发中更好用，而看板在维护类的软件开发中更胜一筹。
+
+所以 “Scrum就是敏捷，敏捷就是Scrum”这个说法，是相当片面的，是对敏捷的误解。敏捷还有很多我刚刚提到的方法，如果只认识这俩，那你在做敏捷时，无疑就受到了限制。
+
+说到落地敏捷的方法，我们还可以看看“敏捷是自由的，无约束的”这个误解，我想以Scrum为例，来谈一下为什么这个说法是不对的。
+
+Scrum框架看起来很简单，很多人以为它不过就是“三三五五”：3个角色（产品负责人、团队、Scrum Master），3个工件（产品待办事项列表、迭代待办事项列表、产品增量），5个会议（迭代计划会议、每日站会、迭代回顾会议、迭代评审会议、产品Backlog梳理会议），5个价值（承诺 、专注、开放、尊重、勇气），以为只要把上面这些事都照搬过来做完，就万事大吉了。但其实Scrum也是有约束条件的，如果你不按照这些约束条件去使用它，是用不好这个方法的。
+
+关于Scrum的约束条件，这里我举最重要的两条来说明：
+
+1. 在迭代计划会议开始前，产品负责人需要准备好需求条目，使需求达到准入标准；
+1. Scrum讲究时间盒，包括迭代的周期、各个会议，这些都要遵守时间盒的约定。
+
+如果不遵守第1条约定，你会发现你的团队即使用了Scrum，研发节奏仍然会被打乱；如果不遵守第2条约定，你会发现你的团队会被耗在各个会议上，会议效率又很低，团队成员很快就会感到厌烦。所以说，Scrum是有纪律的，如果不遵守它的纪律，自由自在无约束，那么使用它注定是痛苦的，也达不成既有目的。
+
+从上面Scrum的例子我们可以看出，了解敏捷的方法，不能只了解它的表面，要深度理解它背后的规则和深意，只有这样才能正确地应用它，让它为我们的研发管理服务。
+
+针对敏捷的每一种方法，我建议你在使用前，都要问自己3个问题：
+
+1. 这个方法能解决什么样的问题？
+1. 有没有使用前提？
+1. 有没有相应的使用规则？
+
+此外，你还可以看看别人是怎么用这些方法的，看他们在使用过程中有没有遇到什么坑，如果有又是怎么避免的。我希望通过这样的自我提问和借鉴，你在日后能正确使用敏捷的方法。
+
+## 总结
+
+说到现在，你是不是已经明白了到底什么是敏捷呢？我希望你在学完今天的课程后，能深入理解什么是真正的敏捷，并能分辨出对敏捷的误解。综合上面内容，我来总结一下，希望能给你带来帮助。
+
+一句话，**敏捷=价值观+原则+一系列符合价值观和原则的方法。单纯说敏捷是一种方法，肯定是片面的；但只强调它的价值观和原则，而不重视方法也是不对的，因为那样敏捷就飘在空中，不能落地了**。
+
+因此对于敏捷，你需要从敏捷的价值观、原则和具体方法上对它有全方位的认识，更重要的是，你也不能只关注具体的方法，还要时时刻刻记住做敏捷的初心，不能偏离了它的价值观和原则。
+
+## 思考题
+
+结合上面的内容，我想请你来思考一下，你还知道有哪些对敏捷的误解吗？你可以对照着它的价值观和原则检视一下，在留言区写出来。
+
+我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

极客时间专栏/说透敏捷/实战篇/03 | 评估诊断：成功迈出敏捷推进的第一步.md

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

极客时间专栏/说透敏捷/实战篇/04 | 团队试点（一）：让你的敏捷实践“事半功倍”.md

@@ -0,0 +1,129 @@
+<audio id="audio" title="04 | 团队试点（一）：让你的敏捷实践“事半功倍”" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4d/f4/4dfb3cc5e4593a6cef3248beb87d8af4.mp3"></audio>
+
+你好，我是宋宁。
+
+上节课我给你讲了怎么做敏捷推进前的评估诊断，也帮你做了短期的推进计划。接下来我要用两节课时间，给你讲讲推进敏捷的第二个步骤：团队敏捷试点。
+
+试点工作的展开可以分为**试点前准备**和**试点推进过程**两步。今天我先来讲在做团队敏捷试点前，你需要做哪些准备，试点推进过程我在下一节课会再做详细讲解。
+
+说到这里你可能要问了：直接给公司所有团队都直接导入敏捷不就得了，为什么还要费精力先搞个敏捷试点？
+
+这是因为，敏捷实践毕竟属于一场变革，与其它所有变革一样，都需要先从局部试点试水，只有在试点中积累了切实的经验教训，确定了可行性后，才能去大规模推广。如果不先在试点试水，就贸然在全局上推广，一旦在推进过程中遇到水土不服等问题，不只阶段性的成果会前功尽弃，再想倒回去做新的改变也更不容易，最终整个变革大概率会走向失败。
+
+## 为什么要做试点前的准备？
+
+现在你知道了为什么要做试点，那是不是在毫无准备的情况下，立马就着手做呢？
+
+我先来带你看一家创业公司推进敏捷的故事。因为是创业公司，工作节奏本来就非常快，老板希望他们做敏捷时也能够“短、平、快”：快速行动、快速见成果。于是，相关的负责人只对团队成员进行了两个小时的简单培训，直接就要求所有团队上Scrum。
+
+但效果极其不好，问题更是显而易见。因为此时，大家连Scrum Master是谁都不知道，况且没有任何前期铺垫，直接就要求团队改变熟悉的工作模式，团队成员既不理解为什么要改变，也不知道这种新模式到底该怎么做。大家很快就接受不了这种工作方式，做得一塌糊涂，连个形式上的敏捷都没做到，更别提见收效了。此时，负责人到处救场，劳累不说，团队也不满意，老板更不满意，最后整个敏捷实践就这么灰头土脸地草草收场了。
+
+这家创业公司的敏捷实践为什么会失败？原因就是他们在推进试点前，没有做好试点前的准备工作。俗话说“凡事预则立，不预则废”，敏捷也是如此，只有做好详细、充足的准备，我们才能在推进试点时真正做到有备无患。有人还给敏捷试点前的准备工作起了个名字，叫迭代0（Iteration 0），这更足以见得这些准备工作的重要性。
+
+## 如何做好敏捷试点前的准备？
+
+现在你知道了为什么要做试点前的准备，那么到底该如何做，才能为你的试点打开一个好局面呢？下面我就结合一个我接触过的实际案例，给你讲讲做好试点前准备工作的基本要点。另外，简单介绍一下这个案例的主角，它是一家拥有一千多名研发人员的银行，我们姑且叫它B公司。
+
+### 1. 选择试点团队
+
+首先，你需要挑选试点团队，让他们充当推进敏捷的排头兵，快速打赢变革的第一仗。一般来说，有以下这些特征的团队会成为我们的首选：
+
+- 采纳敏捷的意愿相对强烈；
+- 业务价值高或采纳敏捷会在短期内给团队带来很大收益。
+
+为什么要选择这样的团队？
+
+这是因为，相对强烈的实践意愿，是团队落地敏捷的优渥土壤。如果团队愿意接纳敏捷，那么在推进过程中，团队成员会很容易发挥他们的主观能动性，成员之间的配合度也会相对较高，更易于产生良好的化学反应，也更有利于克服推进过程中遇到的困难与不适，使敏捷顺利推进并取得成效。
+
+另外如果团队做的产品业务价值高，或者敏捷能在短期内给他们带来很大的益处，那么团队排头兵的示范效应就会比较好。一般而言，这样的项目比较重要，公司也会高度关注，团队做起来也会更认真，也就更重视自己的敏捷实践活动是否能取得成果。而且如果敏捷能在这些团队里率先取得胜利，那么它在公司里的影响力就会更大，也会让其它团队更加信服，为进一步推进它打下良好基础。
+
+此外，我建议你选两个或两个以上团队来进行试点。因为只选一个团队，孤品风险太大，也没有竞争效果；而两个或两个以上团队容易产生竞争性，对比效果明显，大家都会争着把事情做到最好。当然，这也要看敏捷教练的数量，一般来说，一个教练一次只能带2～3个团队，否则一个教练的精力是没办法照顾到每个团队的。
+
+比如说B公司，他们希望通过导入敏捷提高研发效能。在试点时，我们选择了两个团队：手机银行产品团队和直销银行产品团队。对于B公司这样的银行来说，这两个产品都是他们的核心产品，在互联网的冲击下，业务压力很大，所以他们要求研发团队能够快速响应，因此团队有相对强烈的敏捷实践意愿。
+
+### 2. 前期准备工作细则
+
+选好了团队，就要配合团队做一些前期准备工作，你需要从6个方面去准备：
+
+- 组织和人员
+- 管控治理规则
+- 需求范围
+- 架构
+- 方法和工具
+- 办公环境设施
+
+下面我就结合B公司这个案例，逐一把这些准备工作详细讲给你。
+
+**首先，是组织和人员的准备。说到底敏捷是要靠人来执行和推动的，因此，我认为在所有准备工作中，这一条是最重要，也是最需要你花费心力来做好的，它直接关乎了敏捷试点乃至整个敏捷推进工作能否成功。**从组织层面来说，你要查看当前的项目组织结构是否适合做敏捷，如果不适合，就要重新组织。从人员层面来说，你需要对参与试点的人员进行相关培训。
+
+那具有什么特点的组织结构更适合做敏捷呢？**简而言之，就是“高内聚，低耦合”。**这本来是软件开发中用来衡量软件设计好坏的词，一般而言，模块内部高度聚集和关联，而模块之间关联程度低，这样的软件才是好软件。
+
+**引申用在组织结构中，高内聚指的是日常工作中，全功能小团队内部成员之间的沟通合作更紧密；低耦合则指的是，团队之间的沟通协作要远比团队内部的少。这样的组织结构才更适合推进敏捷。**
+
+那要怎样来划分组织结构呢？其实，业界如今已经有很多这样的组织结构框架，但在这里我想提醒你的是，**框架虽然多，但本质都是一样的，都是为了让小团队内的沟通合作频度更多，也更加顺畅，而团队之间的沟通协作尽量少一些。**
+
+这里我用Spotify框架来说一下，它目前是“高内聚，低耦合”组织结构的一个通用典范。
+
+它分两层，下面一层是Squad，指的是一个个全功能小团队，每个小团队中都有自己的业务分析师、开发人员、测试人员和迭代经理（Iteration Manager），能端到端负责一个需求或者产品。一般来说，团队中的人数要限制在5～9人，当团队人数超过9人时，也要分拆成不同的Squad。而当Squad超过5个时，就要考虑把它们划分到不同的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做持续集成的案例比较多，为了日后方便，我们又选择了它来做持续集成，并用SonaQube来做代码扫描。
+
+要将敏捷做好，除了上面的“软”件，也离不开硬件的支持，所以**办公环境设施的准备也很重要。**如果项目中有成员是远程办公的，就需要准备必要的音视频设备，远程会议工具；如果项目都在一个区域，就还要有适用于敏捷开发的办公环境，如物理看板和开放式的工位等等。
+
+在B公司，由于他们所有团队的员工都在一个区域办公，我们就在办公区张贴了一些关于敏捷的宣传画报，也安放了物理看板，这可以方便团队学习和交流，提高工作效率。
+
+## 总结
+
+OK，说到这里，我们的试点准备工作就大功告成了，现在我来总结一下，以便于你更好地理解。
+
+所谓“凡事预则立，不预则废”，在推进团队敏捷试点之前，你要挑选好试点团队，并做好试点工作前的充分准备。如何做好准备工作呢？一句话：**调整好结构、组织好人员、划定好需求、搭建好架构、选择好方法和工具、布置好办公环境。**你要注意，这些准备工作是相辅相成的，每一步都马虎不得。
+
+俗话说“心急吃不了热豆腐”，在推进敏捷时，不能盲目地求快，不能省略掉该走的步骤。如果不做试点前的准备工作，就直接开展敏捷活动，那么团队成员既没有心理上的准备，也没有知识和技能上的储备，整个试点工作也会如同一团乱麻，达不到预期效果。做好了各项准备，未雨绸缪，才能让我们的试点工作“事半功倍”。
+
+## 思考题
+
+现在，我想请你来思考一下，在团队试点前的准备工作中，关于组织和人员的准备，你会怎么做呢？你有没有更好的方法呢？
+
+我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

极客时间专栏/说透敏捷/实战篇/05 | 团队试点（二）：打造一支无往不胜的敏捷团队.md

@@ -0,0 +1,100 @@
+<audio id="audio" title="05 | 团队试点（二）：打造一支无往不胜的敏捷团队" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d9/4c/d9eab7cc79da8bdfdc73a4c646b75a4c.mp3"></audio>
+
+你好，我是宋宁。
+
+上节课我讲了怎么做团队试点前的准备工作，这节课我们一起来看看具体怎么推进敏捷试点。
+
+你可能要问了，既然准备工作已经做好，万事俱备，还等什么，直接推进试点不就可以了吗？其实没那么简单，因为一切准备工作还得靠团队来执行和交付。如果说试点准备工作中最重要的是组织和人员的准备，那么在推进试点过程中，最重要的也可以说是核心的关键点，**就是打造一支活力与战斗力并存的敏捷团队。**
+
+团队是整个敏捷实践活动的根基，只有团队能有条不紊又高效率地执行实践中的每一项工作，敏捷才能发挥出它最大的效用。如果团队氛围不好、执行力不高，那即便导入了敏捷，团队也很有可能做不好。
+
+在做试点准备工作时，我们已根据最适合团队交流协作的方式，对它的组织结构进行了重组，那么重组后的团队就可以成为一支无往不胜的团队了吗？当然不是，你还需要想办法来唤醒、激发团队，让它更有活力和战斗力。
+
+因此在今天的课程里，我想教给你的是如何完成敏捷试点中最重要的一步：打造一支活力与战斗力并存、无往不胜的团队。学好了这关键一步，不管你和你的团队采取的是哪种敏捷方法，你都能在推进时得心应手、运筹帷幄，你的团队管理能力也会因此更上一层楼。
+
+## 一起制订社会契约
+
+我先来讲一个做法，叫做“社会契约”（Social Contract）。
+
+什么是社会契约？它本指一个社会里的全体成员，为了更好地生活，制定了一些基本准则，大家一起来遵守。用在团队中，指的就是团队里的行为公约，也就是为了让团队中每个成员都能加强协作、发挥价值，一起来约定的一些基本准则。在工作中，如果有任何成员的行为影响了团队协作，其他成员都可以拿这个契约来约束他，这样就可以“对事儿不对人”，在处理不良行为的时候更有说服力。
+
+落地社会契约的过程，其实就是团队内部相互认可、磨合和协作的过程。那具体怎么来做呢？我认为可以将团队所有成员都聚到一起，大家一起来制定，只有这样，才能充分征求每一个人的意见，让大家一致认可，这样就有充分理由让大家一起来执行了。
+
+首先，给大家分发一些贴纸，并给所有人5分钟的静默时间，让每个人都思考一个问题：你认为加强协作、达成团队目标，需要哪些行为准则？每个人都要把自己认为重要的准则写在贴纸上，且一张贴纸只写一条准则。
+
+写完之后，每个人把自己手中写好准则的贴纸贴到白板上，然后把白板划分为不同区域，把内容相似的贴纸归在同一个区域里。
+
+接着，会议的组织者要给大家宣读每一条准则，并询问大家是否同意，如果有人不同意，就停下来就此讨论一番，如果讨论的结果还是有人不同意，就放弃它；如果大家都同意，就将该准则保留下来。
+
+这样进行一遍，把大家都同意的行为准则留下来，就形成了团队的“社会契约”。
+
+你要注意的是，“社会契约”做完以后要张贴到所有团队成员都可以看到的地方，以便整个团队时时可以看到它，感受它带来的激励和约束。如果把它束之高阁，那就失去了它应有的效用，团队的协作也可能因此出现问题，进而导致敏捷推进的失败。
+
+## 回顾会议，引导团队的自主性
+
+在试点推进前制定“社会契约”，可以让你的团队形成一个约束和激励机制；那么在试点推进过程中，通过开展回顾会议，你的团队会形成一个引导机制，它能引导团队的自主性。
+
+在评估诊断阶段的调研访谈中，你已大体了解到团队的痛点，也根据痛点选择了相应的敏捷方法。那问题来了，这些方法里既有管理实践又有技术实践，它们的推进顺序是怎样的呢？
+
+一般而言，作为敏捷教练，我们自己会有一个自认为“正确”的推进顺序。但是实践方法是团队来用的，行为和习惯的转变也是团队要做的，而且我们也要打造自组织团队，所以相比你自己单纯地做口头宣讲，按自己的想法推进敏捷，引导团队自行选择和决定推进顺序会比较好，这更容易获得团队的认可和接受。所以重要的不是“你想”，而是“团队想”，回顾会议正好可以完美地做到这一点。
+
+怎么开展回顾会议呢？其实也很简单。
+
+首先，要选一个大家都方便的时间，把会议时间固定下来。前几次的会议可以由敏捷教练来引导，等大家对会议流程都熟悉了，就可以由团队的组长来组织了。
+
+会议开始后，要先说明会议目的，接着让大家讨论三个条目：
+
+- 团队工作中做得好的地方是什么？
+- 做得不好的地方又是什么？
+- 除此之外，有没有什么其它疑问？
+
+和制定契约的会议一样，先用五分钟时间让大家自己思考，然后把每一个点子都只写在一张贴纸上。将白板划分成不同的区域，把相似内容的贴纸分区域贴到白板上。
+
+接着和大家一一讨论这些问题。做得好的地方在接下来的迭代中可以保持下去，做得不好的地方大家可以一起头脑风暴看看到底怎么去改善，并做一些行动计划。对于有疑问的地方大家也可以互相提问，有些是敏捷教练需要阐释的，有些则是团队成员需要解释的。
+
+这里你要注意，回顾会议是有时间盒的，一般不会超过1个半小时。在前几次会议中，团队成员会提很多问题，但我们的时间有限，所以如果问题几句话就能解释明白，通常我会当场解释清楚，否则我会安排专门的时间答疑解惑，而不会把会议拖得太长，占用过多时间。
+
+你可以看到，这个会议其实也有查漏补缺的功能，可以让你发现团队成员在哪些方面有困惑，或者哪些敏捷知识储备不足，后面你可以安排其它时间来帮助他们专门补齐。
+
+以我带过的一个手机银行团队为例。在第一次回顾会议时，团队提出了一个问题：“项目透明度差，大家只了解自己的工作而不了解其他人的工作”。就这个问题，我引导团队成员思考它背后的原因，之后大家一致认为主要原因是“没有地方和机会了解别人的工作”。
+
+我就势说：“大家觉得可以做些什么事情来改善呢？”最后大家讨论认为，不如约一个时间，每天定时定点地开个短会来共享一下彼此的工作内容和状态，这不就是“站立会议”吗？我们又一起给它定了一个时间段：下个迭代。我领取了这个改进任务，在下一个迭代中为团队导入“站立会议”。
+
+说到这你发现没有，通过回顾会议来引导团队思考，所有的改进就不是我作为“敏捷教练”安排给团队来改进的，而是团队自己思考出来的行动。身为敏捷教练，我只需要将专业的知识和做法示范给团队即可，团队会更愿意践行自己主动思考出来的行动，这样，整个团队的行为和习惯就会转变得非常顺畅。
+
+所以说，只要掌握了正确的方法，敏捷的推进并没有想象中的那么难。每个团队其实都有向好转变的原动力，我们只需要将它激发出来，并且告诉他们正确的行为规范，加以引导就好了。
+
+## 成绩墙与错题集，记录团队敏捷的成长
+
+有了契约的约束和回顾会议的引导，是不是就意味着在试点过程中，会始终一帆风顺呢？不会，你一定还会遇到些小波澜。因为团队也不会一直都正确地思考，也有犯错的时候，比如：
+
+- 团队为了赶进度，省略了部分测试，匆忙上线；
+- 迭代中间，有业务人员向某个团队成员提出了新的需求，要求把它加到迭代中，团队成员不顾自己的研发产能，擅自将该需求加到了迭代中，最后却搞不定。
+
+遇到类似这些情况，该怎么办呢？这里我不想教你具体的解决方案，而是想教你引导团队解决问题的思维。
+
+如果这个所谓的错误并不会带来毁灭性的灾难，比如导致用户大规模投诉，或给公司带来巨大的经济损失，那么我会选择放手让他们按自己的想法先做一做，即使碰个壁也未尝不可。事后我们再坐下来认真分析到底怎么做才是对的，引导大家想出新的解决方案。有了这样一个试错的过程，大家通常会把经验教训记得很清楚。
+
+另外，配合着试点，我会让团队通过“成绩墙”和“错题集”在推进敏捷的过程中记录自己的心情曲线，以及取得的成绩和犯下的错误，所以这其实也记录着团队的成长。
+
+团队有任何大大小小的进步和成绩，我都会让他们顺手记录下来，贴在一面小小的“成绩墙”上。同样，我们也将自己遇到的问题和坎坷，以及解决方案也顺手记录下来，贴在另一面小小的墙上，构成一个“错题集”。这样大家经过它时，都会很容易想起在我们敏捷实践的过程中都发生过什么。在试点结束的时候，我们也会把总结中关于成功的经验和失败的教训写到这里。
+
+这样做有很多好处，首先团队会一直感觉到敏捷氛围的存在，有精气神儿；其次，以后有团队请我们去做宣讲时，我们很快就能找到素材，也能绘声绘色地讲给大家；还有，团队记录的心情曲线、“成绩墙”和“错题集”，这些都是试点结束后在做总结时，记录团队敏捷历程的鲜活素材，是团队敏捷实践的轨迹记录。
+
+## 总结
+
+现在，我来总结一下今天的内容，以利于你更好地理解。
+
+在做团队敏捷试点时，团队的执行力、战斗力是关键，你可以通过三个方法唤醒团队的活力：
+
+1. 推进试点前，制定“社会契约”，保证团队工作的有序和高效；
+1. 推进试点过程中，开展定期的“回顾会议”，引导团队成员自发思考，激发大家的自主性，使工作变得更顺畅；
+1. 在试点过程中和结束后，通过“成绩墙”和“错题集”记录团队的成长，总结敏捷实践中的经验。
+
+我想让你知道，其实打造一支无往不胜的团队并不难，只要你善于利用我给出的这三种方法，善于用同理心理解团队，那么你离敏捷实践的成功就不远了。但你也要注意的是，做试点不是目的，我们的真正目的是通过试点总结经验和教训，以便我们在给其它团队导入敏捷时能有所参考。
+
+## 思考题
+
+现在，我想请你结合今天的内容来思考一下，如果由你来负责推进团队敏捷试点，你会怎么做呢？如果你是试点但团队成员之一，正在做敏捷改进，你喜欢用什么样的方式来做呢？
+
+我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

极客时间专栏/说透敏捷/实战篇/06 | 规模化推广：复制粘贴试点的经验就够了吗？.md

@@ -0,0 +1,109 @@
+<audio id="audio" title="06 | 规模化推广：复制粘贴试点的经验就够了吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/bb/fb/bb3a145dfb5dd69099e8e44a573125fb.mp3"></audio>
+
+你好，我是宋宁。
+
+在前两节课中，我讲了如何做团队敏捷试点，这节课我就给你说说怎么把试点成功的经验做规模化推广。
+
+试点不是目的，做试点是为了在我们的环境中探索敏捷实践的可行性，积累经验，若是确认敏捷在我们的环境中是好用的，我们就要根据试点结果，把这个过程中积累的成功方法推广到更多团队中。
+
+## 规模化推广≠直接复制试点经验
+
+那么其他的团队该怎么使用试点团队的成功经验呢？是不是把它们直接复制过来就大功告成了呢？
+
+在我做咨询的经历中，我发现很多人都认为“规模化推广敏捷就是复制试点成功经验”，但其实这个说法只对了一半。
+
+**没错，我们是做了试点，试点中的经验教训也是可以拿来给后面的推广做参考，但如果直接复制未免有点简单粗暴。**
+
+举个例子。某个试点团队成功使用了Scrum，于是领导一拍脑袋，也不管其他团队能不能吃得消，直接让所有团队一股脑儿在一个月内全部上马Scrum。结果，有的团队导入Scrum比较顺利，而有的团队却遇到了很多困难。
+
+其中，一个团队做的是运维类的项目，由于运维类项目开发的内容通常来自客户的建议或生产上的Bug，比较零散，没有一定的规划性，所以对于他们来说使用Scrum并不合适，他们其实更适合使用看板；还有一个近百人的团队，产品本身比较大，团队拆分后有十几个小团队，只使用Scrum却没有解决好团队间的协同问题，效果同样不佳。
+
+从这个例子你可以看出，上面这位领导除了拍脑袋和一刀切做决策，在推广敏捷时也只是机械地简单复制试点的成功经验，这非但没有给其他团队带来好处，对于他们来说反而成了一种桎梏。
+
+**此外，试点涉及的主要是团队内部的敏捷，而规模化推广还要涉及团队间的敏捷。**
+
+在做试点时，我们更多解决的是小团队内部的敏捷怎么用，所以对于单一小团队来说，借鉴试点中的经验更为便利有效。
+
+而当你想规模化推广敏捷时，一旦小团队的数量多于两个，就会牵涉到团队与团队之间的协同问题。当然，在多个团队一起开发同一个产品的情况下，试点可能就是在多个团队中同时进行的，那么团队间的管理你也多少会涉及到。
+
+当小团队数量多于5个时，如果你用的是Spotify这个组织模式，那小团队的管理就上升到部落（Tribe）级别，这时就要考虑部落内的管理了；而如果你的团队数量超过一个部落的范畴，你还需要考虑部落与部落间的管理。所以说当团队足够大时，它在管理上也就更复杂，使用管理小团队的方法就不够用了。
+
+所以，从试点到规模化推广，是要从团队内敏捷扩充到团队间敏捷的过程。由于牵涉到团队间的协同管理，团队间的敏捷较之团队内的敏捷更为复杂，因为你要开始考虑让各个团队方向一致而不是互相羁绊，还要考虑跨多个迭代、多个团队、多个产品的情况下推进计划和安排优先级，更要考虑团队间的依赖、更大规模地沟通协调、多团队版本控制等一系列的问题，所以要想做好规模化推广，直接复制团队内敏捷的成功经验远远不够。
+
+## 规模化推广的正确方法
+
+关于怎么做敏捷的规模化推广，当前有两个主流的框架，[SaFe](https://www.scaledagileframework.com)（Scaled Agile Framework）和[LeSS](https://less.works/zh-CN)（Large Scale Scrum），这里我不想用大量的笔墨给你介绍它们，如果你对它们的具体内容感兴趣，可以去它们各自的官网了解一下。
+
+而之所以提到这两个框架，是因为它们是如今做规模化推广比较成熟的范式，它们的方法可以为我们提供参考，有很多团队甚至直接套用这两个框架，但我并不建议你这么做，因为它们都有各自的长处和短板，如果你使用不当，反而会陷入敏捷实践的歧途。
+
+其实不只这两个框架，每个框架都有各自的优劣之处，**所以我想和你强调的是，要想做好敏捷的规模化推广，不要套用框架，也不要被框架限制，只要它们的可取之处能帮到我们，你就可以有选择地拿来使用。就像我在一开始讲敏捷的价值时提到的，是不是冠以敏捷的名称不重要，只要它能帮助我们解决问题就好。**
+
+那规模化推广到底该怎么做呢？我认为，在做之前，还是要从企业或团队的痛点切入，看他们究竟需要解决什么问题。分析具体问题后，你可以从下面这些方面考虑怎么去推广，并形成自己的方案：
+
+- **选择合适的规模化推广策略。**推广时该选择激进式变革还是渐进式改革？其实这两种策略没有优劣之分，你需要结合企业变革的急迫程度、领导支持敏捷推广的力度以及团队能接受的方式来进行选择。
+- **做好敏捷文化铺垫，培养好敏捷的中坚力量。**文化和人员始终都是整个敏捷推进过程的坚实基础，在规模化推广过程中也是如此，所以你也要做好必要的全员敏捷基础培训和核心敏捷人员的能力培养，以便支持更多团队开展敏捷。
+- **搭建适合敏捷的工作环境，做好必要的工具和自动化准备。**适合敏捷的工位布置，必要的物理白板和各种协同管理工具等，这些无论在试点还是规模化推广中都是必要的硬件设施，配合着规模化推广也要有相应的硬件准备。
+- **组织级别的敏捷度量以及持续改进。**你要做好组织级别的敏捷度量，从效率、质量、成本等方面收集敏捷相关的数据，并借由这些数据辅助企业做持续改进。
+- **重视大型团队的敏捷导入与推广。**这一点是规模化敏捷的核心，因为有的产品需要多个团队共同交付，这就涉及到复杂的团队间的敏捷，因此很多企业在做规模化推广时都会遇到这个问题，这也是我想重点给你讲的部分。
+
+接下来我会结合一个案例，来给你讲具体怎么做大型团队的敏捷导入与推广，做好了这点，我相信你的规模化敏捷之路会更加平稳顺畅。
+
+## 规模化推广实例分析
+
+这个案例来自一家银行，我们姑且叫它D公司，他们的研发团队有接近2000人，在比较顺利地做了试点后，希望做规模化推广，让敏捷为整个公司的研发赋能。
+
+我先分析了他们的痛点，总地来说就是研发效率比较低，无法满足业务发展的要求。他们的问题也很突出，主要有3点：
+
+1. 研发中各个环节的效率有待提升，各个角色的等待时间过长；
+1. 敏捷走到业务那里就卡壳，业务人员参与度低；
+1. 跨团队沟通不畅，协作效率低。
+
+针对问题1，我们在规模化前的试点中，改变了研发模式，让小团队使用了Scrum，很有效地解决了这个问题。
+
+而问题2和问题3涉及的就是大型团队导入与推广敏捷最需要解决的两个问题。要想做好规模化敏捷，主要就是要突破这两个问题。
+
+那么该如何解决这两个问题呢？
+
+针对问题2业务人员参与度低这个问题，其实就是D公司在推广时忽视了业务这一环。
+
+你要注意，只做到开发、测试团队的敏捷，只算是敏捷的一个小胜利，最重要的是要走向业务敏捷。只有业务敏捷了，我们才能和IT团队一起真正打通研发整个过程的敏捷，才能在短时间内快速交付业务价值。
+
+**因此，大型团队敏捷的导入和推广，首先要打造端到端的、从需求到开发到测试到运维到运营的敏捷全生命周期，向业务敏捷靠拢。**
+
+所以针对问题2，我们主要通过两个方法来解决。
+
+第一是**定制度。**确立产品负责人制度，将过去以“项目”为中心的管理改为以“产品”为中心的管理。只有这样，才能让业务战略与产品战略合二为一，让整个团队目标一致，“劲儿往一处使”，从而方便团队做好研发全链条的敏捷。
+
+第二是**定反馈机制。**在整个产品研发流程中进行数据收集和处理，做到从业务创意和机会捕捉到需求识别，到开发上线，再到业务运营的整体大反馈闭环。这样做的好处是为端到端的研发过程提供了数据支持，以便在后续工作中识别整个研发过程的瓶颈，为持续改进做支持。
+
+针对问题3跨团队沟通不畅这一问题，涉及的就是团队间的敏捷实践。
+
+我们很多团队在需要兄弟团队协助开发时，总是希望对方在我们需要时能够随叫随到，但每个团队都有自己的优先级工作，哪里有时间随时“听喝”呢？
+
+**因此，要建立各团队间的敏捷实践，就需要提前安排支持工作。**这样，你们团队需要协助的工作就会被排入对方的工作列表，就更加易于团队间依赖关系的管理，省去了很多无效的沟通和无谓的等待。
+
+由于管理实践是后面一切具体技术实践的基础，因此在这里我只想教你如何在管理实践上探索团队间的敏捷，带你做好这关键的第一步。
+
+所以针对问题3，我们主要是**建立沟通机制，对齐团队目标**，把“做什么”和“怎么做”这两个方面的目标对齐以后，团队间的沟通就更加有序和高效了。
+
+具体的措施是定义了一系列关于产品团队内以及与Scrum团队间的沟通策略和沟通机制，定期的产品集体计划会议，并将团队间的依赖放到看板上，通过Scrum of Scrum来定期沟通进展。其它还包括一些具体的技术实践，例如怎么进行团队间版本控制，团队间的架构解耦等等。
+
+把这两个问题解决好以后，D公司根据自己的情况优先选择了做管理实践的规模推广，又在工具和自动化方面做了更多工作。考虑到要做敏捷的长期实践规划，我们又通过培养核心人员，也即内部敏捷教练来延续企业的敏捷文化，具体的举措，你可以参考后续[09](https://time.geekbang.org/column/article/185502)的文章来看。这样他们的规模化敏捷工作就开始平稳地推进下去。
+
+最近我又对他们进行了电话回访，发现几年以后的今天，他们内部已经完成了规模化敏捷1.0，目前正在循序渐进地推进规模化敏捷2.0，重点放在DevOps方面的建设。据其核心负责人反馈，他们一直在做持续改进，我为他们的持续性探索而开心，因为这也是敏捷的本质所在。
+
+## 总结
+
+好了，现在我想总结一下今天这节课的内容，以利于你更好的理解。
+
+敏捷的规模化推广不是去简单拷贝试点经验，也不是找来几个规模化框架往企业身上套，而是需要根据企业的研发管理痛点和需要解决的问题，根据实际情况寻找解决方案。当然在这个过程中，成熟的规模化框架可以给予我们参考。
+
+规模化推广敏捷的核心是大型团队的敏捷导入与推广，主要集中在业务敏捷和团队间敏捷这两点上。你可以通过定制度、定反馈机制推进业务敏捷，可以通过在管理实践上建立沟通机制，对齐团队目标来保证团队间敏捷的高效和有序。当然除了这一点，你也需要统筹全局，从推广策略、文化、环境等方面完成整个规模化推广的持续改进。
+
+敏捷的推进不是一帆风顺，但是走到了规模化推广这一步，我想由衷地恭喜你，因为这意味着你的敏捷实践已经克服了很多困难并取得了一定成果，我相信只要你以更加坚韧的心态和努力的态度去不断检视、改善自己，坚持下去，你的敏捷实践一定会取得更大的成功。
+
+## 思考题
+
+现在，我想请你来思考一下，假设你在一个大型的研发组织里，你会怎么做敏捷规模化推广呢？你有成功或失败的经历吗？
+
+我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

极客时间专栏/说透敏捷/开篇词/开篇词 | 重识敏捷，让你的研发管理少走一些弯路.md

@@ -0,0 +1,48 @@
+<audio id="audio" title="开篇词 | 重识敏捷，让你的研发管理少走一些弯路" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/05/bb/053be4f8e9ec1ad0c3c19f19f8ca63bb.mp3"></audio>
+
+你好，我是宋宁，现在在IBM做敏捷教练和咨询顾问。作为一名职场老兵，除了UI设计师和运维工程师，我做过软件研发领域内几乎所有的岗位。从一线工程师到管理者，从项目经理、Scrum Master，到现在的敏捷教练、咨询师，我经历过研发管理从无序状态到瀑布模式、敏捷模式，对各个管理模式的优劣深有体会，也从各个角度体验过敏捷。
+
+我一直热衷于探索研发管理的效率、效益和精髓，我本人并不在乎这种研发管理模式叫什么名字，只要它能给研发管理带来益处我就敢大胆的启用，所以敏捷来了以后我也开始了解并使用它，现在我来给你讲讲我从接触到使用敏捷的历程。
+
+时间追溯到2007年，当时诺基亚准备在公司内部落地敏捷。作为合作伙伴，我们公司为了更好地和诺基亚协同，并为他们提供服务，所以就派我以排头兵的身份先行了解敏捷。我与当时负责敏捷的外国同事一起研究，并在后面参加了Scrum的培训课程，第一次接触到敏捷。
+
+参加完课程后，刚接触敏捷的我认为它的理念非常好，不过还是有些理想化，所以我并没有从内心接纳敏捷。于是在工作中，公司要求用敏捷的项目我就用敏捷，其它的我继续用瀑布。然而做着做着，两相对比，我隐约感觉到一些敏捷带来的好处，这尤其体现在团队管理方面，敏捷为我省去了大量的时间。
+
+对敏捷有了好感后，我开始认真研究并使用敏捷。我熟读了敏捷的价值观和原则，又学习了很多敏捷的方法和实践，从管理实践到后来的技术实践，从单一团队管理到大规模敏捷，都一一涉猎。
+
+因为工作的关系，我在自己深入探究敏捷实践的同时，接触了很多国内的研发团队，这些团队的规模从几十人、上百人甚至到几千人不等。他们的共同特点是很努力，但也存在很多问题，比如：
+
+1. 有的团队是初创团队，没有任何成熟的管理实践，想到哪里做到哪里，研发管理相当混乱；
+1. 有的团队已经经历了前期的混乱，想着要正规一些，就倾全公司之力引入CMMI，导入瀑布流程，导致整个公司流程过重，交付速度受限制，3个月甚至半年才上一个版本，业务部门相当不满意，项目团队成员也怨声载道；
+1. 有的团队听说现在流行的方式是敏捷，于是拿书来看，自己琢磨，炮制了一套敏捷流程，结果也没玩转，正唉声叹气准备请外部咨询师来支援；
+1. 有些团队正在拿捏，不知道自己到底该采用哪种研发模式，听说别人在做敏捷，做得还不错，跃跃欲试却不知道该怎么开始。
+
+除了以上这些问题，我在与一些团队成员交流时，发现他们自身也有一些困惑：他们很关心现在的研发管理趋势，听说敏捷不错，也想引进敏捷，但是不晓得公司引入敏捷后，自己的工作跟以前相比有何不同。
+
+有些一线和中层的管理者甚至还有些担忧：之前工业革命的时候，机器在很多岗位上取代了人，那现在敏捷来了，强调团队要自组织，我的岗位会不会也被取代了呢？
+
+而且敏捷来了后，管理方式也会有一些新变化，这些变化是什么呢？到底应该怎么改变自身的管理风格才能更好地适应它？还有一些人，包括想成为leader的程序员，相信敏捷作为一种变革，带来挑战的同时也会带来新的机会，但不知道到底该怎么做才能提高自己的职业竞争力，把握住这些机会。
+
+面对这么多的问题，作为敏捷咨询师，我一直想把自己的经验总结出来，就像医生总结临床病例一样，分享给更多需要它的人和团队，以便他们在探索研发管理的路上少走一些弯路。所以当极客时间的编辑跟我探讨写敏捷实践的专栏时，我特别高兴，因为我终于可以把这些年来自己对敏捷的研究，把我在这个领域内积累的经验分享给更多的人了。
+
+我想，现在市面上也有很多关于敏捷的书，会讲到一些基础知识和理论，但是敏捷毕竟有很强的实践性，所以只了解理论是不够的。以我个人的经历来讲，我觉得要想真正理解并接纳敏捷，你需要一些真实的案例来辅助你对它的理解，而要真正自如地运用它，还是需要付出一定的努力的。但无疑，案例会让你学得快一些、深入一些，我想只有通过解读更多的真实案例才能让你更有感触，才能够收获更多。
+
+## 课程设置
+
+所以在这个专栏里，我想用这样的方式来分享我的故事。
+
+我将从为什么需要做敏捷（why）、什么是敏捷（what）和怎样推进敏捷（how）三个角度来讲述敏捷转型过程中的那些事儿，在why和what上让你知其然也知其所以然，在how上让你更多地知道到底应该从哪里下手，到底该怎么做才好。
+
+**Why**：在为什么需要做敏捷上，我将用实际案例来阐释做敏捷的价值，以及敏捷带来的好处，看完以后你就明白为什么这些团队不用瀑布模式，并放弃想干啥就干啥的自由散漫管理而采纳敏捷这一研发模式；
+
+**What**：在总结业界敏捷定义的基础上，结合敏捷实践，从价值观、原则和实践三层讲清敏捷的实质，让你理解敏捷的本质到底是什么，通过深入分析常见的对敏捷的误解，带你正确认识敏捷；
+
+**How**：结合实际案例，讲解到底怎么来推进敏捷，揭示敏捷推进过程中的常见问题，探讨防范措施，定制专属于你的敏捷实践计划。在本环节我还会带你探讨敏捷推进中需要关注的角色定位问题，不管你是一线或中层管理者，还是志在拓宽职业道路的程序员，我都会帮你解决在敏捷实践中你的职场困惑。
+
+## 写在最后
+
+虽说这门课程实践性很强，但是我觉得通过经典案例的学习，可以让你短时间内迅速地了解敏捷的实质并学会一些可以上手的方法技巧。
+
+我建议你准备一个自己的小本子，随着课程的学习，总结你的敏捷案例集。本子的每一页分成左右两半，左边写你以前在研发管理方面的做法和困惑，右边写你学习过程中了解到的做法以及你想到的新做法。等学习完成以后，再来回顾一下，并制定一个属于自己的敏捷实施计划，相信在不久的将来，你会很快地上手并体验到敏捷方式给你带来的好处。
+
+未来已来，不管你愿不愿意，敏捷已经成了趋势。所以我想隆重地邀请你，邀请你与我一起学起来、做起来，与我一起在敏捷的大潮中共舞吧！

极客时间专栏/说透敏捷/策略篇/07 | 填坑指南：填好这4个坑，快速做对敏捷.md

@@ -0,0 +1,118 @@
+<audio id="audio" title="07 | 填坑指南：填好这4个坑，快速做对敏捷" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4d/c5/4df9f0be3ce3e7feea1f533097628cc5.mp3"></audio>
+
+你好，我是宋宁。
+
+今天这节课我来给你讲讲敏捷实践中，你会遇到的一些问题以及解决方案。
+
+理想很丰满，现实很骨感。敏捷听起来那么美好，它的推进策略和推进路线貌似也有迹可循，但现实却往往事与愿违。在实践过程中，我经常听到有这样一些问题：
+
+- 团队刚开始做敏捷时就遇到了很强的阻碍，因此不喜欢做；
+- 敏捷做着做着就流于形式，大家慢慢地就偃旗息鼓了；
+- 开发测试人员干得很苦，然而只是他们自己在忙活，他们的上游产品却游离在外，很不给力。
+
+如果你也遇到过这些问题，并且不知道该怎么办，那么今天，我就带你来看看A公司的敏捷实践历程，结合他们在推进敏捷时遇到的一些坑，给你讲讲相应的填坑策略吧。
+
+我先来简单介绍一下A公司的情况。这是一家国有企业，是业界排名前几的保险公司，研发团队有一千多人，前些年因为受到互联网冲击，业绩压力比较大，加之他们有提升研发效率和透明度的诉求，因此就准备通过推进敏捷改良现状。
+
+前期他们没有自己的敏捷教练，也没有向外聘请敏捷教练，自己分步推进，磕磕碰碰地实践了接近两年，结果遇到了很多问题和困难。无奈之下，他们只好找专家组来帮忙。
+
+专家组来到现场后，慢慢梳理了他们的问题，给出了解决方案，也亲自做了示范，一段时间后，团队最终把敏捷推进成功。作为专家组中的首席敏捷教练，我经历了这个过程，现在就来分享给你。
+
+## 坑一：团队说他们不想做敏捷
+
+我刚进这个公司做咨询时，他们就请我帮忙诊断一个团队，据说是个难啃的骨头，因为这个团队不想做敏捷。他们的领导希望能够引进敏捷做一些改进，然而团队对此并不感冒，在推进敏捷上阳奉阴违。
+
+我先跟这个团队的Leader做了一次约谈，他对我说：“我们已经很忙了，没有时间做敏捷。”看来我马上就要吃闭门羹了，这时该怎么办呢？
+
+以我的经验来分析，团队不想做的原因有很多方面，不能只看表面，必须深层次挖掘，比如：
+
+- 团队没有真正理解到底什么是敏捷，能给他们带来什么切实有效的帮助；
+- 团队真的很忙（当然“忙”要分情况应对，是否是有效的忙碌也是一个值得探讨和挖掘的方面）；
+- 团队中有人一言堂，这个人的意见不改变，其他人不敢动。
+
+我在调研后发现，这个团队之所以很忙，其实是因为资深老员工不够信任新员工，凡事都要亲力亲为。那么我是怎么发现这个原因的呢？
+
+在并不太被接受的情况下，我跟这个团队的Leader说：“我不影响你们工作，只坐在你们旁边可以吗？”他表示赞同。
+
+就这样，我坐在他们团队旁边，观察他们的一举一动，没几天我就发现了这个团队的小情况。他们有两位资深员工，另外5个人都是新人。其中一位资深员工经常在团队工作中一言堂，与此同时，他不信任新员工，对新员工做的很多工作都不放心，于是基本上所有核心一点的工作都是这两位老员工在做，其他同事最多打打杂，这样他们不忙才怪呢。结果就是，两位老员工忙得脚打后脑勺，新员工却没什么大事儿可做，每天也不开心，总觉得自己被边缘化。
+
+在分析了这个根本原因后，我制定了以下对策。
+
+我决定从这位资深老员工下手，慢慢地解决问题。首先，我先找他分享了我的观察，交流了一些基本管理技巧；其次，我鼓励他试着慢慢放手，让其他团队成员参与进来，并定期做代码Review。这样几轮迭代以后，他们的工作变得均衡了，老员工不那么累，新人也成长起来了，团队整体的满意度也提升了。在此基础上再引进敏捷的新思想和实践，也就没人反对了。
+
+总而言之一句话，**不了解和分析现状就直接推进敏捷是非常不靠谱的，必须要看清现实，摸清痛点，在这基础上导入并推进敏捷才是可行的。**
+
+## 坑二：不理解敏捷背后的意义，把它当作一种新的流程，而忘记它的核心是持续改进
+
+上面我们解决了团队不想做敏捷的情况，在实际工作中还有一种情况是：即使公司已经在推进敏捷，但对于很多并不深刻理解敏捷的员工来说，他会说敏捷不就是一套新的流程、一种新的工具吗？
+
+我在调研A公司的员工时发现，大概有一半以上的人认为“敏捷就是一种替代瀑布的新流程”，他们一直在开Scrum中的五个会议，已经开得烦闷又枯燥，也没看到显而易见的好处，但迫于高层的压力，不敢停下来。
+
+于是整个团队每天都在机械地重复着，回顾会议里的问题也就是反反复复的那几条，而这些问题基本上又是自己内部不能解决，需要别的团队协同或者高级管理层来协助才能解决的，但没有人去推动，问题就日复一日地挂在那里。团队里渐渐怨声载道，觉得敏捷只是凭空增加了很多会议，并没有带来什么新的好处。
+
+面对这种情况，我认为他们犯了两个错误：
+
+1. 公司敏捷实践的基础导入工作没有做好，连敏捷究竟是什么，以及为什么要做敏捷都没给团队讲清楚；
+1. 缺乏一名强有力的敏捷教练做引导，在持续改进方面欠缺较大。
+
+那么，如何能让整个团队更清晰地理解和接受敏捷呢？我认为可以通过两种方法来实现：
+
+- **基础培训、基础培训、基础培训，重要的事情说三遍。**有很多公司舍不得投入前期的基础教学时间，大家对敏捷的理解一知半解时，就开始让大家照猫画虎、迅速展开实践，这就造成了大家在做各种实践之前根本不知道这样做的背后有什么意义，从而导致了整个程序的僵化。通常来说，敏捷推进会经历三个阶段：做敏捷（doing agile）、思考敏捷（thinking agile）和思想敏捷（being agile），但如果只停留在“做敏捷”的阶段，就会出现这样的问题。
+- **找一个靠谱的敏捷教练陪伴。**敏捷本身是一种变革，是从指挥和控制到协作的、以团队为中心的结构性转变，它也涉及到人的思维和习惯上的改变，归根结底不是那么容易的。因此这种转变需要一个有丰富经验和影响力的人来持续引导，敏捷教练就是这样的角色。他不仅负责组织一个敏捷团队，还通过敏捷帮助公司进行文化层面上的转变。因此在推进敏捷过程中，你需要一位甚至几位敏捷教练来陪伴。
+
+## 坑三：Scrum过程被严重缩减，只剩下每日站会
+
+在团队认识到敏捷会带来好处并开始推进它后，是不是就可以顺利推进了呢？其实不然，在推进过程中你仍然会遇见各种各样的问题。
+
+有一天，一个负责理赔服务研发的团队leader找到我，对我说：“宋宁老师，你快过来看看我们团队吧，我们的敏捷现在很尴尬，只剩下站会了……”我很诧异，因为这个团队之前做得还是很不错的，怎么就变成这个样子了呢？带着种种疑惑，我到团队里进行了调研和观察，我发现他们用的是Scrum，但很默契地剪掉了里面几乎所有的会议，只留下了站会。
+
+但是，我没有急着下结论、给建议，我了解了他们的实践经历后，我发现他们在公司整体的转型中，导入敏捷比较晚，刚开始大家还很有激情，每个Scrum的实践都做到了，将敏捷做得有声有色。但等他们的导入者走后，会议就渐渐地没人张罗了，会议过程也没人关心、没人引导了，慢慢地大家就开始觉得没有做下去的必要了。
+
+再到后来，大家觉得聚到一起开会无话可谈、倍显尴尬，就自然省掉了这些流程，还美其名曰为了提高效率。半年以后，当他们发觉自己的敏捷有问题再请我去看时，整个实践已然是病态的了，前期的成果基本前功尽弃，我需要再多花一倍的时间帮他们重新建立信心，重新燃起敏捷的火种。
+
+那么这个团队的问题在哪呢？在我看来，最重要的问题是他们没有培养出属于自己的合格的Scrum Master，这导致敏捷教练或咨询师撤场以后，敏捷的火种无人守候，纪律也没人看管。敏捷的效果在短期内并不容易显现，因此在团队的习惯刚刚养成还没有固化时，一旦敏捷教练或Scrum Master不在场，大家很容易迅速回到引入敏捷前的状态，使敏捷的成果付之一炬。
+
+那么该如何解决这个问题呢？
+
+**首先，你一定要认识到Scrum Master在敏捷实践中的重要性。**在团队还不成熟的时候，他负责宣讲敏捷的价值观和理念，也负责具体实践的导入和守护。一个好的Scrum Master在引导（facilitation）、教育（teaching）、辅导（mentoring）、教练（coaching）这四个方面都有很强的能力，并能根据具体的情景选择专项的能力，帮助团队体验敏捷，坚定维持团队新养成的敏捷习惯。在领导力方面，他具有服务型领导的理念，是团队的主心骨，能帮助团队打造敏捷文化。
+
+**其次，要想将敏捷推进到底，必须在基层留有敏捷的火种。**因此，在推进敏捷之初，团队就应该计划一系列Scrum Master的培养活动，识别出优秀的Scrum Master，然后相互配合着推进敏捷；每周也要举办工作研讨会，学习和实践我刚刚讲的那4种能力。在敏捷实践后期，由Scrum Master来负责引导团队，并听取敏捷教练的反馈意见，这样在教练离开之后，培养好的他就会接过敏捷的大旗，专心引导和辅导团队，在团队遇到困难时及时帮助解决。与此同时，跟随着团队推进敏捷的步伐，引入新的合适的实践。
+
+## 坑四：筒仓中的敏捷
+
+所谓筒仓，原指贮存散装物料的仓库，用在研发领域，指的是公司部门各自为政，不好协同。A公司的敏捷实践进行了一段时间后，这样的问题也出现了。
+
+公司开发测试部门的副总最先意识到敏捷的价值，他带着一腔热情，撸胳膊挽袖子，将开发测试部门敏捷了，然而火种却并没有传播到其它支持协同部门，除了开发和测试部门以外，其它各部门之间还是各自为战，形成了严重的筒仓。比如：
+
+- 产品业务部门没有协同，因此对需求的分析理解还是极其缓慢，每次到迭代开始时，需求都准备不好，打乱了开发的节奏；
+- 上线运维部门也与开发测试部门割裂，导致虽然开发测试做得很快，然而到了上线那一步又变慢了，最终拖慢了整个进程。
+
+因为研发管理的全链条没有打通，开发测试部门也不能真正感受到敏捷带来的好处，最后推动无力，大家越来越没有信心，敏捷遂在大家的愤懑中偃旗息鼓，人人不愿再提“敏捷”二字。
+
+针对上面的状况，如何来解决呢？
+
+仅就这个问题本身来讲，我认为前期应该多宣讲敏捷的本质和好处，尤其应该**推动对高管层面的宣讲，成立更高级别的敏捷实践督导团队。**当高管层面理解到敏捷的好处和他们应该做的事情之后，就不会阻碍整个推进过程了，还能及时为敏捷提供必要的帮助，这尤其适用在一些大型的控制型传统企业中。
+
+以A公司为例，他们现阶段要想实现“需求-开发-测试-运维”的全链条协同，必须推动组织变革。但这是一家大型国有企业，从某种意义上说，推动组织变革尤其是大部门的组织、合并、重组并不容易，必须由高层领导认可才能推进下去。
+
+在经过谨慎的思考后，我鼓起勇气将这个问题提到了他们总经理的办公会上，并跟总经理约到半个小时的访谈时间，借由这个机会向他宣导敏捷。最终的结果很让人满意，他们的高管高度重视和推进了这件事。在几个月后，我做回访时，发现他们已经做完了组织重组，并按照之前我们的规划进行了研发全链条的协同，不仅提升了研发效率，也提升了研发的整体满意度。
+
+就这个问题再深层次地挖掘一下，我认为：
+
+**第一，推进敏捷时要通盘考虑整个链条应该怎么推进。**组织全功能团队，除了一个一个的敏捷小团队以外，还要考虑需求管理怎么推进，并想好推进策略。
+
+**第二，敏捷可以分步推进，但是推进过程中一旦识别出新的阻碍，要及时去除。**像在A公司这个案例中，我相信当产品团队没有跟着一起推进敏捷时，整个流程很快就会有新的问题浮现出来，例如每个迭代前，需求条目都准备不好，在这种情况下，这个障碍就应该及时去除。
+
+## 总结
+
+好啦，我们今天的课到这里就要结束了，结合我给出的填坑策略，现在我来总结一下。
+
+敏捷是个整体工程，需要从全局上考虑怎么去推进。在前期，要做好诊断和规划，在解决痛点的基础上导入适合自己的敏捷方法；推进过程可以分步进行，但要及时排查每一步中可能出现的新的障碍；要加强协作，打通研发管理的全链条，必要时要成立高层参与的督导团队，请高层领导帮忙推动；在整个实践过程中，都需要有能力的敏捷教练陪伴，并培养出适合自己团队的Scrum Master。
+
+从今天的课程你可以看出，推进敏捷确实不是一件容易的事，在这个过程中你会踩到很多坑，而在填坑时既要有方法的甄选，又离不开人力的支持，很多公司和团队之所以会遇到各式各样的问题，也是由于他们或是浅尝辄止，或是急于求成，没有把敏捷实践真正落实好。所以我相信，只要你稳扎稳打，踏实、耐心、正确地完成每一步，夯实基础、持续改进，再多的问题都会迎刃而解；你更会举一反三，成为一名真正的“填坑专家”。
+
+## 思考题
+
+最后，我想请你思考下，在推进敏捷的过程中，你踩到过哪些坑呢？除了文章中提到的方法，你还有更好的填坑方法吗？
+
+我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

极客时间专栏/说透敏捷/策略篇/08 | 避雷策略：如何防止你的敏捷变为“小瀑布”？.md

@@ -0,0 +1,97 @@
+<audio id="audio" title="08 | 避雷策略：如何防止你的敏捷变为“小瀑布”？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f8/fa/f8d94f42bdbb1ffc716d8a781450ecfa.mp3"></audio>
+
+你好，我是宋宁。
+
+也许很多订阅咱们这门课的同学已经走在了敏捷实践的路上。然而却有很多人在做的过程中，不小心走入了敏捷的反模式。那么该如何检视你的方法是否正确呢？今天，我想用敏捷的一种反模式“小瀑布”来给你讲一下。
+
+## 真敏捷，还是“小瀑布”？
+
+在我做咨询的过程中，常常会看到一些团队的敏捷实践过程出现下面这些情况：
+
+- 把一个大项目分成若干个模块，仿照“敏捷”的做法，每四个迭代做一个模块（见下图）：第一个迭代做需求，第二个做设计，第三个做开发，第四个做测试。这样四个迭代交付一个模块的内容，然后开始下一个模块的循环。做着做着，他们发现虽然这种方式比以前的瀑布模式要好一点，但整体的节奏仍然缓慢，“敏捷”好像没那么大的效益。
+
+<img src="https://static001.geekbang.org/resource/image/4f/1a/4f127bb86ab2179e91efb4343405171a.jpg" alt="">
+
+- 有的团队觉得上面那种方式还是太慢，于是就加快节奏。每个迭代周期也是2周，但不同的是，在一个迭代里完成一个大的功能（见下图）。第一周完成需求和设计，第二周完成开发和测试。迭代的次数增加了，但开发和测试却总感觉时间不够，每次迭代都特别赶，体验非常不好。
+
+<img src="https://static001.geekbang.org/resource/image/cd/25/cd35c7cdc35b059488b7a7a16c398a25.jpg" alt="">
+
+在上面这两种情景中，团队的感觉不好，但是却不知道自己做得到底对不对，就找我来诊断。那么，上面的做法究竟有没有问题？他们的敏捷活动做得到底对不对呢？
+
+先来看一下他们目前的研发过程，整体来看，他们是按照“需求-设计-开发-测试”这个流程来做的。你是不是觉得似曾相识？没错，这其实就是瀑布模式。
+
+但是他们做了一些改造，也就是引入了“迭代”这个概念。先把大项目或需求做一个模块拆分，然后再一个一个模块做下去，和瀑布模式相比，这种方式有了一点进步。然而，究其本质，它仍然还是瀑布，我们一般称它为“小瀑布”。
+
+“小瀑布”同样具有瀑布模式的一些缺陷。比如说，很要命的一个问题就是浪费。我们看一下上面那两种做法就会发现，他们在研发中的所有步骤都是顺序进行的，这就意味着做第一步时，后面所有的步骤都处于等待状态。这样，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 | 内部教练：守护敏捷实践，求人不如求己.md

@@ -0,0 +1,115 @@
+<audio id="audio" title="09 | 内部教练：守护敏捷实践，求人不如求己" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/bb/cb/bbf65818c7c004e30b1496e11d3565cb.mp3"></audio>
+
+你好，我是宋宁。
+
+这节课我想来给你讲讲怎么培养自己的内部敏捷教练。
+
+在推进敏捷时，如果团队里没有合格的内部敏捷教练，可以说是非常痛苦的，为什么这么说呢？你可以看看下面这些场景：
+
+- 团队在敏捷实践初期，外部教练在场，他带着大家了解敏捷，并给大家做示范，团队有问题就及时协助解决，在他的带领下，团队玩得很high。然而，在他撤场后，团队渐渐无所适从，气氛低沉，该开的会议也不开，失去了对敏捷的热情，工作模式慢慢又退回到了瀑布模式。
+- 团队刚开始引进敏捷时，有咨询师帮忙做了相关的培训，团队成员基本都掌握了做敏捷的方法。后来有团队成员转队或者离职，团队重新招募，新成员到岗后，团队中的老成员对他说：“你就看着，我们怎么做你就怎么做就行了。”于是新成员跟在大家后面，亦步亦趋，并不知道为什么要这么做，工作干得很别扭。
+- 团队在引入敏捷后，取得了很大的进步，大家一直都很开心。突然有一天，团队遇到了一个比较大的困难，然而团队的Scrum Master是位兼职的同事，他有自己本职的测试工作，对Scrum Master的认识就是每天带着大家开开会，其它时间他都在做自己的工作。团队其实还没到足够成熟的地步，由于不知道要怎么解决这个困难，再加上没人牵头，大家很快就泄气了。
+
+**你可以看到，在上面这些场景中，敏捷之所以会失败，究其根本原因，是企业或团队在推进过程中，过于依赖外部教练，而忽视培养自己的内部敏捷教练。**
+
+## 内部敏捷教练为什么重要？
+
+在讲怎么培养自己的内部教练之前，我想先带你了解一下敏捷教练这个职位在敏捷推进过程中到底充当什么角色，以及内部教练为什么重要。
+
+顾名思义，敏捷教练是帮助组织或团队推进敏捷实践的人。这个职位需要具备的能力，用行业内的话来说，有4项，分别为：
+
+- 教授（Teaching）
+- 引导（Facilitation）
+- 辅导（Mentoring）
+- 教练（Coaching）
+
+但其实，我们可以把这些能力简要归结成两点：**懂敏捷、能“教练”**。
+
+懂敏捷指的是一名合格的敏捷教练，首先要有扎实、完备的敏捷知识，要有推进敏捷实践的经验和技术，这是能“教练”的基础。
+
+能“教练”指的是敏捷教练既要能**教授**团队什么是敏捷，给团队讲授基础的敏捷知识和这背后的意义；又要能给团队**示范**和**辅导**具体的实践怎么做，通过**引导**团队会议来引导团队推进敏捷；同时，他还能用一定的技巧来引导和启发团队去主动思考，主动改良自己的工作。
+
+所以说，敏捷教练对于企业或团队推进敏捷至关重要，由于敏捷是一场变革，在推进过程中难免会磕磕绊绊，不尽人意，这时就需要敏捷教练来引导和辅助。
+
+那么为什么说内部敏捷教练更重要呢？
+
+这是因为很多企业或团队在引进和推进敏捷时，由于内部很少有真正懂的人，就少不了向外寻求外部教练的帮助。然而在这个过程中，他们没有培养出属于自己的内部教练，那么一旦外部教练退场，再遇到问题，他们往往就失去了领头羊，导致在推进过程中缺少必要的持续性引导和辅助，最终只能走向失败。
+
+所以，在第一个场景中，外部教练一离开，团队在马上就失去了主心骨；而在第二个和第三个场景中，由于没有内部敏捷教练，团队失去了专业的引导者，敏捷推进就无以为继了。
+
+## 如何培养内部敏捷教练？
+
+好了，既然内部教练这么重要，那么对于一家企业来讲，如何来培养自己的内部教练呢？下面我就以某大型跨国公司F公司中一个团队为例，来给你讲解一下。这个团队是F公司数字科技部门，有接近3000人，用敏捷的方式开展工作。
+
+这里你要注意下，在这样一个庞大的组织中，敏捷教练也按技能和分工的不同分为高级敏捷教练、中级敏捷教练和初级敏捷教练。初级教练在公司内部有他独特的角色名称，但为了便于理解，我们就称呼他为初级敏捷教练。
+
+从分工上来看，高级敏捷教练负责组织级别的敏捷事务，包括培养初级和中级教练，为新团队引入敏捷，以及咨询和处理复杂的敏捷问题等等。中级教练通常负责几个小团队组成的一个部落的敏捷事务，负责部落内各个小团队的组间协同等等。而初级教练则主要负责一个一个小团队的敏捷事务。
+
+由于初级教练是直接带领每一个敏捷团队的，这些团队的数量也很多，所以我们培养内部教练的主要精力也就放在了培养初级教练身上，而中高级教练也就是在初级教练的基础上逐渐成长起来的。
+
+### 基础培训
+
+首先是基础培训，它的目的是通过一系列培训课程让大家了解足够多的敏捷知识。
+
+初级教练需要先参加敏捷基础培训、设计思维培训和产品负责人培训。在这些培训里，他们会建立起敏捷的基本概念，了解敏捷和设计思维是什么以及应该怎么做；也会学习关于产品管理的一系列基础知识，以便能更好地与产品负责人沟通，帮助他们一起做敏捷。在培训之后，初级教练会自己去实践，有问题可以向同行或者高级教练请教。
+
+### 安排实战工作坊
+
+紧接着会安排实战工作坊，因为在敏捷实践过程中，有些问题只靠掌握基础知识是不能解决的，还需要将它转化成实战技能，这就需要练习和实践。
+
+比如在F公司，有一次我们就安排了一个为期两天的实战工作坊。
+
+在第一天，培训师带大家回顾了敏捷的基础内容，并让大家把自己在实践中遇到的问题写出来，一起讨论解决方案。他还带大家讨论了初级敏捷教练的定位，让大家明白原来我们不只是引导会议的人，还有很多别的职责，比如说保护团队，带领团队从“泥潭中”爬出来。
+
+第二天，培训师带大家演练了领导力、引导的技巧、团队的对话以及强有力的问题等等。这些环节是这样设计的：
+
+- 领导力环节。大家讨论不同的领导风格，并让大家就不同的情境，练习不同的领导风格；
+- 引导技巧和团队对话环节。大家一起探讨如何打破团队对话中的沉默状态等问题；
+- 强有力的问题环节。这部分主要关注的是教练技巧，这一环节会设计很多场景，大家在各个场景中练习怎么解决团队成员的各种困惑。
+
+通常来说，在来这里之前，初级教练会带来一堆问题，但通过工作坊的帮助以及在这个过程中他们自己的思考，他们最后都会找到相应的解决方案和技巧。同时，经过在这里的实践，他们也可能会有新的计划和新的尝试。
+
+但你要注意，实战工作坊只是个开始和模拟演练，初级教练会在后面的工作中，开展具体的实践，进一步掌握敏捷教练所需要的各种技能。
+
+### 线上活动加力
+
+除了以上两个常规的活动以外，我们还有一系列在线培养初级敏捷教练的活动，这对于没有时间参加几整天实战工作坊的初级教练来说，是一个非常不错的补充。
+
+我们一般会把整个线上活动划分为10个星期，每个星期1个小时，让有需要的教练参与进来，讨论一些基本问题，并在这个过程中加以引导，让他们主动发掘自己需要改进和提高的地方。和工作坊类似，在整个过程中，我们会让这些初级教练定制并实施自己的改进计划，组织大家在活动后分享各自的经验。
+
+### 一对一的教练服务**
+
+除了基础培训和安排实战工作坊，高级教练还会为初级教练提供一对一的教练服务。
+
+我们先请部门负责人对需要辅导的教练进行优先级排序。并规定：一位高级教练一次可以辅导两位初级教练，辅导完成后，再从待辅导教练池中“领”两位继续辅导。
+
+辅导过程可以设计成以下4步：
+
+1. **签署教练协议**。高级教练与初级教练会签一个教练协议，承认两人之间的教练关系，明确各自的职责与义务，比如说高级教练负责在这一段时间内辅导初级教练，而初级教练要承诺这一段时间能够准时参加教练活动。
+1. **进行评估**。高级教练会对初级教练进行一个简单的评估，包括360度的评估和一对一的访谈，借此了解他目前的水平，以便后面两人商讨教练计划。接着，两人一起商讨访谈的评估结果，以及高级教练认为的初级教练所处的分级，据此探讨教练计划，准备一个周期内（通常我们会把一个周期设定成2个月）要进行的改进，预设改进之后初级教练能够到达的层级。
+1. **一对一的教练服务。**等两人达成一致后，就开始进行一对一教练服务。在这个过程中，高级教练或用GROW模型（G为goal目标，R为Reality现实，O  为Option方案、W为Will意愿）来引导教练对话，帮助初级教练发现自己的目标和可做的事情，引导他自己做改进；要么针对一些具体的技能，如观察初级教练组织的活动等，提供一些反馈，帮助他改进。
+1. **成果展示。**每个参加教练活动的初级教练，都要定期向大家展示自己新获得的技能，或者是自己给项目带来的改变。
+
+一对一的专属教练服务会让初级教练更快地成长，也是他们成长为中高级教练更为专业的进阶方式。
+
+以上我讲的都是内部初级教练的培训方法，这其实也是培养中高级教练的基础，我们当然也希望在初级教练中能逐渐产生一些中高级教练，他们不仅能看护好自己既有的小团队，还会为其他一些不好带的团队或者新团队提供帮助。
+
+这里我再简单说说如何培养中高级教练。以我个人的经验而言，最好的办法其实是去外面做咨询，多接触其他敏捷团队。
+
+但我们是内部教练，没有太多机会做外部咨询，该怎么办呢？我想了一个办法，就是定期带一批教练来给一些团队的疑难杂症做诊断，出主意。比如说有其它团队来向我们内部的高级教练求助，高级教练在去支援时就可以带几个初级教练一起去，大家一起考察和分析问题。这样，我们的初级教练就进一步接受了历练。这样在不断接触问题、解决问题，以及积累实践经验的过程中，初级教练就很可能会晋级为中级教练。
+
+而从中级教练到高级教练，我们也提供了一定的培养路径。比如在整个F公司，我们还有自己的“核心教练培养”项目，每个月一次，可以跟着专业教练一起练习教练技巧。另外，对于高级教练，我们也会让他们组成一个高级教练组，每周开展相应的例会，分享大家的经验以及各自的工作进展。
+
+## 总结
+
+好了，今天的内容就讲到这里，现在我来梳理总结一下。
+
+敏捷教练在整个敏捷推进过程中的作用不可小视，尤其是企业或团队自己的内部教练更为重要，他们可以在推进过程中为你的敏捷实践保驾护航，引导你的实践能顺利、正确地向前推进。
+
+关于怎么培养内部教练，我建议你要重点关注初级教练的培养，这其实也就是通过基础培训培养他们“懂敏捷”的能力，通过实战工作坊、一对一教练服务培养他们“能教练”的能力。在实践和交流中，在不断地提出和解决问题过程中，将初级教练培养成敏捷的中坚力量，甚至将他们进阶培养成中、高级教练，以便使我们的敏捷火炬在企业或团队内部不断被传承，不至于熄灭，甚至越燃越旺。
+
+## 思考题
+
+现在，结合今天这节课的内容，我想请你来思考一下，你有想过怎么培养自己组织内的敏捷教练吗？你有自己独特又好用的方法吗？
+
+我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

极客时间专栏/说透敏捷/管理篇/10 | 服务型领导：在敏捷中你该怎样提升自己的领导力？.md

@@ -0,0 +1,146 @@
+<audio id="audio" title="10 | 服务型领导：在敏捷中你该怎样提升自己的领导力？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/65/23/65bbce4e74af9dad818aa9208f2c1523.mp3"></audio>
+
+你好，我是宋宁。
+
+这节课我想来给你讲讲服务型领导。
+
+之所以要讲这个话题，是因为在我做咨询的过程中，有团队领导曾经跟我表露过对“敏捷”的担忧，他想的是从前工业革命时，机器在一些岗位上取代了人，造成了一部分人的失业。那在敏捷这场新的变革中，它强调团队的自我管理，身为团队的管理者和领导者会不会因此而失业呢？
+
+这个领导的担忧有一定代表性，现在有很多人尤其是一线管理者都存在这样的职业困惑：**在敏捷中，作为领导者和管理者，我该如何定位自己呢？**
+
+但其实你可以换个方式来看这个问题，工业革命时，确实存在本来属于人的岗位被机器取代这种情况，然而，机器在取代这些岗位的同时，也创造了更多其他岗位。
+
+比如在第一次工业革命期间，蒸汽机带来的产业升级使原来传统的农业和家庭手工业崩溃，导致了一定程度上的失业危机；然而它带来的诸如铁路、造船和电力等重工业的兴起，又创造了一系列新的产业和工作岗位，极大缓解了失业危机。
+
+**所以，作为新时期的一场变革，敏捷固然会带来组织方式和文化理念上的各种改变，但与此同时，它也对原来的领导方式和领导力提出了新的要求，它激励领导者革新管理方式，在新形势下持续提升自己的管理能力。**
+
+## 为什么你要成为服务型领导？
+
+那在目前这样一个持续变革的社会中，或者说在敏捷实践中，我们更需要什么类型的管理者，更需要具备什么能力的领导呢？
+
+你会发现，从工作形态上来看，我们现在要处理的工作变得更加复杂，因此如果使用传统的管理方式，那其中诸如僵化的管理方针、等级思维、冗长的决策方式这些弊端就会被进一步放大，这在当下的工作环境中更加行不通。
+
+所以如今，我们需要的管理方式和领导方式是，管理者和团队一起，在短时间内对新的市场要求做出快速反应。请注意**“和团队一起”**这几个字，这意味着现在**只靠领导者一个人的“英雄主义”是远远不够的**，**领导者要有出色的协调能力，能聚人气，带领大家一起出谋划策，搞定复杂的工作。**
+
+而符合这种条件的新型领导者，我们称他为“服务型领导者”。
+
+简单来说，这指的是领导者首先要是一个服务者，要为整个团队服务，拉近自己与员工的心理距离，这样才会取得团队的信任。从管理目标上来说，他的目标是和团队成员共同成长，所以他做任何事的首要动机都是为团队中大多数人谋取利益，因此团队成员才更愿意跟随他，努力工作并更好地完成工作。
+
+说到这就不得不提Herman Miller,Inc的首席执行官Max De Pree，在他的领导下，这家办公家具制造厂的销售额翻了将近三倍。谈到自己的领导方式，他曾简明又形象地说到：“领导的第一要务是要精确判断现实。最后是要说谢谢你。”表面上看，他拉下领导者的身段，由衷地感激员工的付出；而在这背后，实质就体现了服务型领导的管理理念：理解员工并为员工服务，与员工精诚合作。
+
+## 怎样成为服务型的领导？
+
+说完服务型领导在如今工作环境中的必要性，接下来我就给你详细讲讲怎样成为这样的领导，怎样利用这样的管理理念达成工作目标。
+
+### 给员工建立心理安全机制
+
+首先，给员工建立心理安全机制是必不可少的，只有这样，才能真正拉近与员工的心理距离。
+
+那怎么建立心理安全机制呢？你可以从这3点来着手：
+
+1. 信任是必不可少的。要支持员工和他们的决定，在工作和工作之外都照顾好团队成员；
+1. 培养健康的分歧环境。允许分歧存在，在有分歧时虚心听取不同的意见；
+1. 建立正确的失败文化。失败是可以接受的，只要从失败中吸取教训，能够改进就好。
+
+但只给员工建立起心理安全机制显然是不够的，要想为团队成员服务，更重要的是，你还必须掌握一套服务的章法，这就是情境领导能力，接下来我会结合一个具体的例子，为你详细解读这一点。
+
+### 掌握情境领导能力
+
+那什么是情境领导能力呢？简言之，就是**领导者能在不同的情境下运用不同的领导力来指导和支持团队成员完成目标或任务。**
+
+它强调的是引导、激发团队一起做事儿。要想激发团队成员的能力、动机和信心，就要了解他们在特定任务下所处于的状态。
+
+在实际工作中，领导者通常会面对4种不同的情境，或者说面对特定的任务，团队成员会有下面4种状态。
+
+- 情境1：热情的初学者
+- 情境2：幻灭的学习者
+- 情境3：有能力但谨慎的贡献者
+- 情境4：自力更生的成功者
+
+对应到每种情境中，团队成员也有各自不同的特点：
+
+1. **能力低、承诺高。**这指的是情境1这类团队成员，他们对自己的任务很陌生，缺乏经验，甚至不了解自己的知识和工作盲区。但他们有很强的学习意愿，有好奇心并且愿意接受指导，也很自信自己能够学会怎么做。
+1. **能力不是很高，承诺很低。**这指的是情境2这类团队成员，他们有一定的知识和技能，但还有所欠缺。而且，他们的学习意愿很差，随时都有气馁和沮丧的情绪，随时可能准备放弃。
+1. **能力处于中上等、承诺很低。**这指的是情境3这类团队成员，对于某个特定的任务来说是有能力也有经验的。但是他不是很自信，偶尔会犹豫不定，觉得自己的任务很无聊，甚至对能否完成任务漠不关心。
+1. **能力高、承诺高。**这指的是情境4这类团队成员，他们有足够的能力，能够胜任交给他的工作任务。他们也非常自信，能鼓舞别人。
+
+作为管理者，首先你要能识别出这4种不同的情境，识别出来之后，再匹配不同的领导风格。领导风格在工作中是用领导行为来体现的。
+
+一般来说，有两种基本的领导行为：
+
+- 指导性行为：告诉其他人应该做什么，何时做，如何做，并经常提供结果反馈；
+- 支持性行为：鼓励、表扬他人自力更生解决问题，倾听意见，并让他人参与决策。
+
+针对上面4种不同的情境，两种领导行为在经过权重高低的分配和组合后，也就形成了4种不同的领导风格，下面我们来看针对每一种情境下的团队成员，应该使用什么样的领导风格。
+
+**风格1：指导。高指导行为和低支持行为。**领导者通过讲述和展示，具体指导员工如何达成目标，并密切跟踪员工的表现，频繁地进行反馈和指导，让员工能够顺利地完成目标。它的目的是帮助情境1的员工建立起必备的工作技能。
+
+**风格2：教练。高指导行为和高支持行为。**领导者给员工解释工作任务，征求他们的意见，鼓励、引导并持续指导他们完成目标；领导者会随时让员工积极参与到问题中来，协助他一起解决问题。对员工不会做的部分，领导者会亲自示范；在员工做的过程中，领导也会在他们需要的时候随时提供指导。它的目的是重新激发情境2的员工的工作热情，提高他们的工作能力。
+
+**风格3：支持。低指导行为和高支持行为。**针对情境3的员工，领导者通过提出开放式问题来促进问题的解决，通常只是询问他们的做法，不多加干涉，倾听和鼓励他们的工作，引导他们一起参与做决定。它的目的是激发情境3员工的信心。
+
+**风格4：授权。低指导行为和低支持行为。**对于情境4的员工，领导者认可他们的专业知识，鼓励他们的自主性，并邀请他们持续学习和不断创新。它的目的是珍视员工的贡献，最大限度地发挥员工的潜能。
+
+上面我从理论上给你讲了4种情境中的员工，以及针对性的4种领导风格，只讲理论估计你听起来会比较迷糊，接下来我用一个领导让员工小李泡茶的例子，形象地给你讲解一下这些内容。
+
+这个例子的场景是这样的，L公司的办公室来了位非常重要的客人“孙总”，他对公司非常重要，决定着该公司下一次融资能否顺利进行。他喜欢喝西湖龙井，公司的领导“兰总”想让员工小李为孙总倒一杯热茶，兰总该怎么做才能让小李招待好孙总呢？
+
+先来看情境1与风格1。
+
+假设小李是位年轻的二十多岁的毕业生，刚刚来到公司，对茶一无所知，之前也从没见过孙
+
+总，但他热情肯干，那兰总遇到的就是情境1的员工，即“热情的初学者”。
+
+要想指导好他，兰总就会用第1种指导型的领导风格，这样和小李说：“小李啊，孙总是咱们的重要客户，他喜欢喝龙井茶，你来帮他泡杯茶吧。”**说完要做的事儿，然后具体指导他**：“龙井茶在左边的柜子里，先用桌子上那个蓝色的茶壶泡。水烧开后晾一会儿，85-95度的水温最合适。泡完了叫我过去看一下。”
+
+小李把茶泡好后告诉兰总，兰总点点头：“不错不错，干得很好。”然后指导小李另换了一个漂亮的茶杯，并在茶盘上放了餐巾纸，让他送给孙总。
+
+接着是情境2与风格2。
+
+假设小李已经在公司呆了一段时间，以前也给别的领导泡过茶，但没泡过龙井，也不喜欢给领导泡茶，那么他此时就是情境2的员工，即“幻灭的学习者”。
+
+此时兰总就要用第2种教练型领导风格，这样和小李说：“小李啊，孙总是咱们的重要客户。他喜欢喝龙井茶，你来帮他泡杯茶吧。帮他泡茶容易跟他拉近关系，对未来你跟他的接触也有好处，未来你们还要一起工作。”**先说要做的事儿，但不仅说事儿，还把做这事儿的意义说清楚。**
+
+然后鼓励他：“你以前泡过茶，泡起来没问题的。”接着提问题引导他：“龙井茶要用多少度的水温来着？”如果小李说不知道，那就接着引导他去做：“你上网查查呗。”然后继续询问：“你准备用哪个茶壶和茶杯啊？”小李说：“蓝色的茶壶和旁边那套白色骨瓷杯子。”兰总表示认可，并在小李泡完茶之后过去看一下，对他的工作表示肯定。
+
+再来看情境3与风格3。
+
+假设小李会泡龙井茶，但是很害怕见领导，没有自信，那小李的状态就属于情境3，即“有能力但谨慎的贡献者”。
+
+此时兰总就要用第3种支持型的领导风格：“小李啊，孙总是咱们的重要客户。他喜欢喝龙井，你来帮他泡杯茶吧。孙总这个人啊，人特别好，平易近人，对人很客气的。”这里，兰总**不仅讲了要做的任务，还给小李打消了思想上的包袱。**
+
+兰总看小李神情缓和下来，接着继续鼓励他：“小李啊，我知道在咱们公司龙井茶你泡得最好，赶紧去吧，泡完了端给孙总，有什么问题，随时来找我。”
+
+最后来看情境4与风格4。
+
+假设小李既会泡龙井茶，又很自信，热情能干，他就属于情境4“自力更生的成功者”。
+
+那兰总就会用第4种授权型的领导风格，这样和小李说：“小李啊，孙总是咱们的重要客户。他喜欢喝龙井茶，你来帮他泡杯茶吧。我相信你能做得很好，去吧。”**说完任务后，直接让小李自己去干，全程不用关注。**
+
+等小李泡完茶回来，兰总又说：“小李啊，你这个泡茶的技术很好，等回头给行政部的那几个小伙子都培训一下哈。”**这样既认可小李的成绩，又给他创造机会，将自己的本领分享给别人。**
+
+我相信通过兰总让小李泡茶的例子，你会具体又形象地了解，针对不同的情境，怎么使用不同的领导风格，和员工进行不同的对话。
+
+这里我还想再强调一下，你可以通过下面这3点用好情境领导力：
+
+1. **设定目标。**要运用好目标管理，设立正确的目标，目标的设定要与需要做的事情保持一致；
+1. **协同诊断。**要会评估员工在特定任务上的能力和承诺，判断他们在这个任务上属于哪一种情境；
+1. **学会匹配。**根据员工所处的情境，匹配自己所需要运用的领导风格，帮助他们完成工作任务，也为他们个人提供需要的帮助。
+
+## 总结
+
+好了，讲到这里我们这节课又结束了，现在我来总结一下今天的主要内容。
+
+在如今变化快速的环境尤其是敏捷的环境中，要想做好一个管理者和领导者，一定要具备“服务型领导”的能力。它的核心是团结员工，形成凝聚力更强的团队。
+
+作为一个服务型领导者，首先要从内心里有服务意识，要给员工营造安全的心理环境，拉近与员工的心理距离。还要有足够的能力来从语言和行动上让员工感受到他们是被关怀的，这就需要掌握情境领导力，针对不同的情境，使用不同的领导风格。
+
+就像谈恋爱一样，不能“爱在心口难开”，你要大胆地将内心的爱表达出来，让对方感知到。在服务型领导这种管理方式下，领导者与员工之间的关系也是如此，领导者对员工的关心也需要用对话和行动表达出来，唯有这样，员工才能够感受到你对他的支持与帮助，才能够更好地与你协同合作，共同达成组织的目标，同时也更能获得他们个人的成长。
+
+其实，虽然我们这节课讲的是敏捷中的一种领导方式，但它其实更是一种沟通方式、合作方式，关注人、强调合作本就是敏捷与生俱来的内容，也是做好敏捷的关键。所以不论你是想用或正在使用敏捷的领导者，还是想成为领导者的程序员，抑或是普通的团队成员，如果你想尝试一下领导者的角色，或者转换一下自己的工作方式，那么我都鼓励你学好服务型领导这个新型的领导方式，我相信它一定会给你带来工作和思维上的帮助。
+
+## 思考题
+
+最后，结合今天的内容，我想请你来思考一下，你在实际工作中会怎么运用情境领导力呢？你认为还有其它更有效的管理方法吗？
+
+我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

极客时间专栏/说透敏捷/结束语/结束语 | 用敏捷提升自己，从敏捷走向未来.md

@@ -0,0 +1,49 @@
+<audio id="audio" title="结束语 | 用敏捷提升自己，从敏捷走向未来" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1d/fb/1dd123bda99abb0a535717babf6349fb.mp3"></audio>
+
+时间过得真快，不知不觉中，我们已经一起学完了整个课程。有关敏捷的内容其实有很多，我在写这个专栏前就一直在想，如何在这短短的十节课里，把我对敏捷的思考呈现给你。
+
+最后，我按照“为什么-是什么-怎么做”这样的逻辑组织了一下，并结合了大量的案例，将这么多年来我对敏捷的独特体会讲给了你。我相信学习完这门课后，你一定会有所收获，但我觉得，**今天课程的结束不是终点，而是你学习路上的新起点。**
+
+前几天我在上一门教育心理学的课时，老师让我们大家思考这样一个问题：在未来的智能化社会里，我们需要培养什么样的人才？这些人才又需要什么样的能力？
+
+讨论到最后，大家一致认为，**未来的人才一定要具备6个能力：健康力、交往力、学习力、专注力、批判力和创造力。**
+
+这是因为，健康力让人的自然生命更长，交往力让人的社会生命更宽，学习力让人的学习生命更高，专注力让人的事业生命更深，批判力让人的思维生命更广，而创造力让人的精神生命更精彩。
+
+毫无疑问，我们已经进入了人类第四次工业革命，在这次工业革命中涌现了很多新科技（如AI等），而且发展很迅猛。在这样的世界里，唯一不变的东西应该就是“变”。那么，面对这样变化飞快的世界，我们该怎么应对呢？
+
+**敏捷其实就为我们提供了一种很好的应对方式，通过它我们可以很好地提升自己的能力。**
+
+在敏捷的价值观和原则中你可以看到，它强调人与人之间的合作，强调设计合作型的组织，做合作型的实践，甚至到了领导力这一层面，也强调了领导与员工的合作，那么通过合作，不正是可以提升我们的交往力吗？
+
+它也强调终身学习，不断改进自己，这恰好可以对应到学习力上；它还强调契而不舍，这其实也就是聚焦在专注力上；此外，它也非常重视创造力，它自身营造的环境氛围本来就很适合培养创造力。
+
+它也强调思辨，强调接纳不同的意见，如果你还记得我对“服务型领导”的讲解，也就一定会记得“服务型领导”会给大家营造允许分歧存在的环境，还有什么比这更适合培养批判力的呢？
+
+通过上面的分析你可以看到，实践敏捷，是可以培养出6大能力中绝大部分能力的。这是不是也意味着，在未来，敏捷本身就变成了一项人才需要具备的基本能力了呢？所以了解和学习它，也许是我们未来工作的一个基础内容。
+
+在我们这个课程中，我使用的案例基本都源自软件研发领域，然而**敏捷虽从软件研发中来，却并不止于此，对它的使用已经远远超出了这一行业，因为它的很多思想，都可以在很多领域和工作中发挥价值。**
+
+所以在这里，我并不是想让你全盘接受敏捷，也不是让你在一切工作中非用它不可，相较于具体的敏捷方法，我始终在强调敏捷思维。我越深入学习它，我越明白，**学习它达到的高阶段位并不是学会了几种实践方法，而是要真正掌握它背后的思维方式，并且能用这些思维来助益你的工作和生活。**
+
+再举一个简单的例子，在敏捷中，有一个思想是“做得多不等于价值大”，那我是怎么理解它并把它用到我的工作中呢？
+
+以前我的工作习惯是，不管工作能不能做完，一股脑去做所有的事，结果我发现工作应接不暇，自己每天都忙得身心俱疲，压力也很大。
+
+在敏捷这个思想的引导下，我开始思考：“我做的事情价值大吗？”接着我把自己所有的工作都记下来，放到Jira上，形成了一个“工作池”，然后根据价值大小把这些工作按照优先级排序。
+
+现在我每天来到公司，就不是像过去那样立马开始着手做工作了，而是先统计下今天都有什么事情要做，这些事情哪些价值比较大，哪些价值又比较小。排完优先级后，先做完价值比较大的事情，每天下班时再总结一下，看看今天有什么收获，有什么值得注意的地方，再把它们都记在自己的工作笔记里。
+
+这样每天坚持下来，虽然我的工作时间没有延长，但由于我优先做价值大的工作，一方面增强了自己的成就感，另一方面也确实提升了自己的绩效，我处理起来工作也就更加游刃有余了。后来我在给别人做敏捷咨询时，我一个人能顶1.5到2个敏捷咨询师，我惊讶于自己的变化。
+
+敏捷同样给我的生活带来了一些变化，它像是一扇门，借由它，我能使自己一直保持对这个世界的好奇心，我的思想也更开放，并始终用积极的心态去面对生活。
+
+比如我现在依然愿意尝试学习新事物，作为一个职场妈妈，我学习钢琴、绘画、法语、滑冰等一切我感兴趣的事情，我也乐在其中。这是敏捷带给我的精神财富，它拓宽了我的精神生命。
+
+其实这样的例子还有很多，我希望你在学习我们这门课后，除了掌握敏捷实践的方法，还能自觉利用敏捷思维来帮助自己的工作和生活，你一定会切实感受到它的好处。
+
+我相信，如果你能用好敏捷，并将敏捷作为你自己的思维方式，那么对于未来，你将会有很强的适应能力和应变能力，你也一定能激发自己内心的能量，不会畏惧未来世界的变化，创造出属于自己的未来！
+
+如果你对敏捷还有心得或者问题，那么你要记得，我会一直在留言区等你，这里还有很多和我们一起学习和分享的人，你可以随时回来，和他们分享你的问题和困惑，当然也包括你的成功。
+
+如果这个专栏曾经帮到了你，或正在帮助着你，也欢迎你把它分享给你的朋友和同事，我们一起沟通和探讨。我是宋宁，在前行的路上，记住，你永远也不孤单。

极客时间专栏/说透敏捷/结课测试/结课测试 | 敏捷的这些知识，你掌握到什么程度了呢？.md

@@ -0,0 +1,14 @@
+
+你好，我是宋宁。
+
+不知道你学完这些敏捷知识以后，掌握得怎么样呢？
+
+为了帮助你检测自己的学习成果，我特别准备了一套结课测试题。这套测试题共有20道单选题，满分100分。
+
+题目中涉及到的知识点，我在这个系列课程中都讲过。
+
+希望你能认真完成这次测试，如果你发现有些知识还没有掌握，可以回顾相应的内容，再去加深一下理解。也欢迎你在留言区与我互动交流。
+
+好，点击下面的图片，开始测试吧！
+
+[<img src="https://static001.geekbang.org/resource/image/28/a4/28d1be62669b4f3cc01c36466bf811a4.png" alt="">](http://time.geekbang.org/quiz/intro?act_id=160&amp;exam_id=357)