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

Jan 6, 2020

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



下载APP





关闭

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

渠道合作

推荐作者

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

2020-01-06 宋宁来自北京

《说透敏捷》

课程介绍



讲述：宋宁

时长18:21大小14.70M



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

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

生成海报并分享

赞 19

提建议

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

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

 写留言

精选留言(63)

escray
2020-01-08
温习了一下敏捷宣言和12条敏捷原则，如果去看英文原版的话，会发现其实宣言只有四条，而作者提到的第五条，其实应该是一个备注。不过，如果按照五条来宣讲的话，可能会更容易被接受。在原则里面，我觉得比较重要的是“被激励起来的个体”，如果没有这个，那么其他的也无从谈起。 “对于 Scrum 适合新软件开发，看板适合维护类软件开发”，这个说法我觉得很有道理。没有经历过 Scrum，似乎这个在国内还是挺热门的，也考虑过去参加 Scrum 的培训，但是总体感觉 Scrum 在敏捷开发里面属于比较“重”的那种，“三三五五”也不容易。通过 Scrum 似乎是降低了对于开发人员自我管理的要求，但是对于 Scrum master 的要求就比较高了。可能也就是因为这一点，所以在国内比较受欢迎？敏捷 = 价值观 + 原则 + 方法这个公式挺清楚的，但是其实困难的部分是在于价值观和原则，如何让团队成员认可敏捷，可能才是敏捷落地的关键。看了一下专栏的目录，似乎并没有，关于采用敏捷开发对于开发人员个人成长有帮助的内容，而是更多的偏向从研发管理或者客户价值的角度，略有遗憾。
展开
共 2 条评论
43
jinny
2020-01-07
敏捷中的‘快’是指应对及时，反馈及时，就像马歇尔说过的那句话：一个及时的中庸决策，比不及时完美决策要好。
作者回复: 👍
共 3 条评论
34
桃子-夏勇杰
2020-01-07
1. 敏捷就像健身，怎么看都对，但是，背后都需要强大的自律。 2. 敏捷就像健身，怎么看都对，但是，背后都需要强烈的改变意愿和一点的自律。 3. 敏捷就像健身，上了点年纪，有了点经历，还不放弃的，才会追求。大家觉得哪句更能激励人尝试敏捷？
共 4 条评论
15
小老鼠
2020-01-12
1，迭代次数增加，回归测试肯定增大，势必会引入自动化测试，但现在好多企业自动化建立不起来，咋办？2，在几次迭代后客户发现他们的需求变多了，这种情况如何处理？
作者回复: 1、自动化建立不起来要寻找原因，最起码要建立自动化回归测试，否则敏捷后的测试量的增加团队是吃不消的； 2、不管需求增加了多少，始终坚持按优先级排序，每次迭代取优先级高的做
10
李小歪
2020-01-20
请问宋老师简单——使未完成的工作最大化的艺术——是根本的？这条原则怎么理解？
作者回复: 抱歉，这句话应该是“以简洁为本，它是极力减少不必要工作量的艺术。”我已经让开发替换了最新的译本。主要讲的是敏捷要讲求简洁，尽量不做额外的没必要的工作。比方说，一些额外的交接类的文档等等。
共 2 条评论
8
Raymond吕
2020-01-09
天下武功唯快不破，敏捷的快我理解是信息流的快，始终保持对当下的目标对齐，贯穿整个开发过程。
8
吃饺子不吐饺子皮
2020-01-06
我是一个项目的团队成员，目前项目中存在大量加班情况，我想讲敏捷思想融入项目开发中，但我不知道这会不会影响其他成员的工作习惯，从而导致计划落空。所以想问下团队成员如何自行实施敏捷开发。
作者回复: 首先恭喜这位朋友，已经有意识想导入敏捷了。关于大量加班的问题，建议分析一下背后的真实原因。比方说到底是什么原因导致的？是需求反复更迭？还是需求范围没界定好，团队承诺过多？还是本身人员效率不高？等等，然后有针对性地采取措施。另外敏捷的导入和真正使用它达到既定效果不是一件简单的事情，因此需要各方面的配合。因此建议先跟团队领导商量，让他们看到敏捷的好处，得到他们的支持。对于团队成员，也需要跟他们树立信心，可以先从简单的实践着手，让大家看到一些益处，然后就自然而然地想跟着做了。我们的整个专栏都有这样的思想，可以看看后面实战篇的方法。
共 6 条评论
8
qi
2020-03-27
老师，如何避免敏捷变相为小瀑布的模式，感觉这是很多团队敏捷转型最容易掉进去的坑
5
reven404
2020-01-28
我认为还有个误区：敏捷是开发团队的事，不属于业务和产品.
共 3 条评论
4
MaO
2020-01-17
里面提到的开发人员遵守纪律，具体是指哪些纪律?
作者回复: 有很多需要自律，比方说最基本的，开发人员开发完代码以后要自测，不能不自测直接就丢给测试人员让他们找bug;还有的团队在做持续集成的实践时，会要求红灯不下班等等
共 3 条评论
4
leslie
2020-02-12
敏捷的本质是如果去追求MVP原则：这个原则不光是基于产品与开发两方面。去年GOPS去参加过，听过不少观点；可能课程对我而言就是一个梳理。建立项目的敏捷其实要有3种视角：产品视角、项目视角、架构视角，在需求、规划、落地的每个阶段做到最小最核心且纪律性才能做到敏捷。极客时间相关的不少课程学过且听过一些用户提及相关问题：架构师说非常清楚结果被销售经营团队说你误解了。。。敏捷教练没做过：大会老师们推荐的书没少看，做为一个老牌DBA灭火的事情干的太多了，视角被逼出来了；不知不觉其实发现这种换位被迫走了一遍，自己的部分流程写过；发现原来就是敏捷。
展开
3
小孩
2020-01-10
老师，有个问题，需求在一个迭代里不加，可是遇到，产品设计不合理的情况，开发过程中发现，导致的不得不改的需求怎么办，自己怎么规避这种问题，希望老师能看到
作者回复: 因为产品设计本身不合理导致的返工问题，需要记录下来，并找相关人员来做改进活动。一开始规避不了，团队需要不断的进行持续改进，提高产品设计的能力
共 3 条评论
3
Twinkle
2020-01-06
怎么去培养团队每个成员的敏捷思维
作者回复: 谢谢，专栏可以给他一些好的观点和思维方式，另外专门的布道也是非常重要的，专栏后面的09里的好的敏捷教练也会负责一直帮助团队理解敏捷背后的原因，帮助他们不断地成长。人其实是非常有意思的，如果他不明白为什么，很难转化成态度和行为的改变
共 2 条评论
3
范
2020-11-23
1.重视沟通：与用户，开发人员的沟通；2.强调自律：对代码负责，对测试负责，对需求负责，对承诺负责 3. 关注量化：进度待办列表，用户演示看板等。敏捷，每个人都需要参与。
2
Geek_kevin
2020-03-22
相比开发人员的敏捷思维，传统企业业务人员普遍没有敏捷思维
2
李永智
2020-01-15
敏捷=价值观+原则+方法，概括得很到位。关键在实际中人们更看看重方法而忘记了价值观和原则，这样一旦方法短期看不到效果，就会全盘否定，其实有了价值观和原则，方法只要长期坚持，不断迭代，不断修正，一定会找到适合自己的团队的工作方法。另外在使用中，大家过于相信敏捷是一个银弹，可以解决任何问题，我理解敏捷更多的是强调价值观和原则，不仅适合团队，也适合个人规划，但是任何理论都有它的局限性，不可能使用一个理论打遍天下任何事。
展开
作者回复: 赞一个
2
吴言乱语
2020-01-07
逐条检视了一下：针对第二条：传统做法是不欢迎在开发后期，甚至是任何阶段，改变需求；但是调整思考方式，敏捷的最终目标是业务目标和业务价值，需求变更若可以为客户带来更好的市场竞争力，欢迎变更。但同时开发团队不过度承诺的原则，要将变更量化，替换原有需求，保证稳定的开发速度。针对第四条：业务人员和开发人员天天在一起工作，是否也可以变更成保持紧密的沟通，比如一周一次的开发成果和进度交流会等，因为在业务高速增长期或者其他一些特殊条件下，并不具备天天在一起的条件。针对第八条：稳定的开发速度，在评估开发周期时，工作时间段量化极为重要，量化单位是天还是小时，天的话是按本团队朝九晚五还是朝九晚六都不一样，这些都非常重要。
展开
2
梁中华
2020-03-29
非常同意敏捷就是注重快速反馈这个总结
1
张汉桂-东莞
2020-02-03
这两条原则很有参考价值，赞👍 他们在迭代开始的时候，不会过度承诺，也就是能完成多少工作，就承诺多少工作。严格遵守纪律。他们在迭代开始之后，原则上不再接受需求的增加，如果一定要往他们的迭代待办事项列表里增加其它需求，就一定要同时从其中拿走等量的需求。
1
Aaron(健廷)
2020-01-06
醍醐灌顶阿，谢谢老师
1

