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. 有没有相应的使用规则？
+
+此外，你还可以看看别人是怎么用这些方法的，看他们在使用过程中有没有遇到什么坑，如果有又是怎么避免的。我希望通过这样的自我提问和借鉴，你在日后能正确使用敏捷的方法。
+
+## 总结
+
+说到现在，你是不是已经明白了到底什么是敏捷呢？我希望你在学完今天的课程后，能深入理解什么是真正的敏捷，并能分辨出对敏捷的误解。综合上面内容，我来总结一下，希望能给你带来帮助。
+
+一句话，**敏捷=价值观+原则+一系列符合价值观和原则的方法。单纯说敏捷是一种方法，肯定是片面的；但只强调它的价值观和原则，而不重视方法也是不对的，因为那样敏捷就飘在空中，不能落地了**。
+
+因此对于敏捷，你需要从敏捷的价值观、原则和具体方法上对它有全方位的认识，更重要的是，你也不能只关注具体的方法，还要时时刻刻记住做敏捷的初心，不能偏离了它的价值观和原则。
+
+## 思考题
+
+结合上面的内容，我想请你来思考一下，你还知道有哪些对敏捷的误解吗？你可以对照着它的价值观和原则检视一下，在留言区写出来。
+
+我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。