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

Jan 6, 2020

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



下载APP





关闭

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

渠道合作

推荐作者

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

2020-01-06 宋宁来自北京

《说透敏捷》

课程介绍



讲述：宋宁

时长17:05大小13.69M



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

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

生成海报并分享

赞 22

提建议

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

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

 写留言

精选留言(87)

丁丁历险记
置顶
2020-01-07
一定要早点把客户拉下水。让客户早点确认各种细节。这样就不会后期唧唧歪歪了。
作者回复: 赞一个
共 11 条评论
64
李永智
2020-01-07
敏捷方法使用过，虽然效率有提升，开发理解需求有极大改善，但也做了测试驱动，尽管代价不小，发现有些产品交付质量差，经分析，主要是人员水平造成的，应该是敏捷相比瀑布开发对人员的要求多和高，但现实人员更换受限的情况下，如何提升?或者是我上述的归因有偏差，那问题可能出在哪里，针对这些，有啥应对原则?
作者回复: 这是个好问题，关于人员培养的问题是个永恒的话题。这里面涉及2个方面，一个是态度转变，一个是能力提升。态度转变的话我们其实有很多方法可以让员工有参与感，参与到转型过程中，如后面05会有一些方法，让员工进到我们的转型过程，有参与感，同时也要意识到自己的能力需要提升，这样很多员工都有提升的动力；第二个问题，能力提升的问题方法也非常多，可以组织拆书会等等快速地了解一个领域的知识，也可以互相之间分享，老带新，反讲，建立辅导机制，能力高的辅导能力低的等等，非常多的方法，只要人发动起来，方法总能找得到。最后记住一点是，人毕生都是在发展的，减少对人的刻板印象，鼓励发动他动起来学起来跟上来，这个很重要。
共 10 条评论
37
qinhua-冰糖橙自产自...
2020-01-07
特点：快速响应变化，允许试错，小步快跑。做法:固定小团队，优先级的需求池，客户参入，实时验收。
20
escray
2020-01-07
我对于，“敏捷确实好，但是推进不容易”这个说法深表认同。如果真的落实敏捷，对于研发人员的要求还是比较高的，对于每个开发的工作会有定性和定量的尺度，上班摸鱼就没那么方便了；对于组织架构来说，可能也需要进行一定的调整，比如作者说的划分小团队，但是更主要的可能还是思想上的变革。其实如果能够照着一成不变的需求文档或者详细设计来写代码，对于开发人员来说是相对简单的，但是往往做出来的东西，并不是用户真正想要的。不过从另一方面，如果是类似于火箭发射或者是精密仪器之类的软硬件研发，还是瀑布模式更合适，主要是因为这一类项目的需求规格相对比较稳定。还有一点，个人感觉其实小团队更容易实行敏捷，主要是比较容易形成共识。但是现在似乎把敏捷的范围扩展了，只要采用了一部分敏捷的方法，就可以定义为敏捷。在体制内单位，其中也有项目的外包方采用了迭代开发、滚动上线的方式，也可以说“敏捷”起来了。但是，没有单元测试、配置管理、持续继承、版本控制……这样也可以算是敏捷么？
展开
作者回复: 现实中没有完美的敏捷模式，虽然这是我们一直追求的目标，但大家都走在路上，推进敏捷的方式有激进式的“貌似一步到位”，但其实后面也有很多工作，另一种渐进式的则是解决一个旧问题出现一个新问题，其实一直在做持续改进，有的企业先做了“形式”上的敏捷，后面发现痛点之后继续改进一步一步地推进了更多的技术实践来助力研发
共 5 条评论
11
而立斋
2020-01-30
我这问题是边看边整理的，有一些疑问看到后面就看到答案，记录一下自己的疑问总能加深一下印象：1、在您第一个例子（印尼SAP)中，我觉得这跟使用瀑布流程并没有什么关系。只是在各里程碑节点之后需要有用户的签字确认。为什么在需求分析完就开始开发了呢？难道不应该有一些需求设计评审的操作吗？这不是一种常识性的操作吗？自己闷头整理的需求调研，还不跟客户反复沟通，然后去就是冒然推进开发，这种情况不多见吧，这得啥样的项目经理会这么做呀，再说客户应该也不会允许的吧。 2、我们自己公司也是，有时候像是瀑布模型，有时候像敏捷模型，有时候还像原型模式，这些都有什么真正意义上的区别呢，书上网上一找一大堆，看的时候懂了，哦，原来是这样。实施的时候，就扯淡了，管它什么归类呢？适用，客户认可就行了。这种状态也持续了一段时间，还会遇到一些其它看似无解的问题，但从来没有想过会是研发模型的问题
展开
9
吴言乱语
2020-01-07
利用敏捷的方法缩短项目开发时间是我们一直努力的方向，公司在高速成长，产品迭代必须紧跟业务发展，常常遇到的情况是业务部门临时的排版需求上线时间。在实现过程中，产品经理会在同业务确定需求完成后的第一时间组织立项会议，UI，开发，测试共同参与，进行需求宣导。接下来，产品团队的方案设计，UI团队的界面交互设计，开发团队的技术实现拆分，测试团队的测试用例会同步并行开展。如果遇到需要外部协作，也是先沟通确定合作方案，然后各自开发最终联调，将等待时间不断的压缩，缩短项目开发周期
展开
共 3 条评论
9
想想
2020-01-12
您好，我遇到的问题是： 1.我们采用原型跟用户迭代确认，也形成需求确认书签字确认。但是在具体测试过程中，用户实际使用后，又有新的想法或者原先就考虑完整的，这时也只能继续进行迭代修改。 2.如果存在多个模块处于第1个问题时，因为交付模块一直迭代调整中，导致其他任务无法继续执行。由于成员有限，一个人负责多个模块，就会导致项目工期延期。所以在后面的项目中为了避免出行这种问题，我们只能回到“原型+瀑布”模式，等到开发结束，再集中精力修改，但是这种模式存在的问题也显而易见。一直没有好的解决方案。如果迭代一直停留在几个模块，导致其他模块无法执行时，有什么好的解决方案吗？
展开
作者回复: 第一个迭代结束，客户有反馈是可以的也是正常的，关键在于我们接受了反馈后的处理方式。一般我们是把新的反馈加到我们的需求列表中，并按优先级进行排列，下一个迭代继续从需求列表中选取优先级高的继续开发。这样不是所有的反馈都在下一个迭代中满足，就可以防止您的开发一直停留在几个需求上。要管理好需求列表
共 2 条评论
7
阡陌
2020-01-07
一直想尝试，但是总是事与愿违。说到底还是需要公司高层的支持和底层人员的不断尝试才行。
7
王刚
2020-01-07
老师，请教几个问题： 1.团队拆分为特性小组的标准是什么？多少人为一组为最佳呢？ 2.使用敏捷模式，开发前期的接口文档要不要省略呢？ 3.业务参与需求分析，是不是就是确定原型图的过程？
作者回复: 第一个问题，我们在04里有一些关于组织的说明，特性团队拆分在敏捷里如上面朋友所说，确实没有固定的死的标准，但有些原则可供你参考。一个是团队大小，是5-9个人，大了要进行拆分；第二个是全功能团队。第二个问题，文档的留与否，需要根据实际情况来做剪裁，在剪裁前，评估文档为产品开发带来的价值大小和实际工作量，一般而言不建议省略接口文档，接口文档是开发中的重要文档，但如果团队找到了更好的工作方法替代这个文档除外。
共 5 条评论
4
Geek_bd800b
2021-02-18
我司也采用敏捷开发，目前的状况是: 1.公司领导规定每个迭代两周必须上线； 2.开发人员在做当前迭代的时候，产品必须已经在开始做下下个迭代的需求设计了； 3.假设开发这周完成这个迭代的任务，那么下周开始，测试就开始测试这个迭代的功能，并且开发马上进入下个迭代的开发，测试测完这个迭代的功能后马上上线这个迭代的功能。。如此循环往复，以实现产品在不停的写需求，开发在不停的写代码，测试在不停的测试功能，每周都有功能要上线； 4.以上导致功能实现仓促，代码质量低下，部分人员不满这种节奏，公司离职率很高，后面来的新员工接手旧代码不停吐槽。。公司高管从BAT出来的，说是BAT就是这么干的，不知道这是不是真正意义上的敏捷
展开
共 1 条评论
2
小小光芒
2020-02-04
瀑布开发干的是一锤子买卖。敏捷开发中的小步快跑，持续迭代，也反映了通过主动降低信息获取门槛，让项目内的信息公开透明。包括项目组内部产品/开发/测试人员，也包括外部的客户，都能时时获取到项目的最新状态，产生被尊重的感觉，参与的感觉，产生同理心，进一步可以不断给出反馈，形成良性循环
2
吃饭饭
2020-01-15
怎么跟精益创业提到的：开发-测量-认知循环这么相似
共 1 条评论
2
J
2020-01-13
作为研发人员，宋老师列举的案例是真的感同身受。当时团队没有任何规范的研发流程，并且没有测试。按照瀑布模式，做出来的东西很自然遭到客户投诉。后面复盘以及处理各个环节如需求挖掘，沟通力度，用人方向等所暴露问题。而为了整顿就引入了敏捷开发的概念，各个环节的问题都没有妥善解决，最后整个系统虽然还是上线了，但时不时会就遭到客户不同岗位角色对于某一功能缺陷提了好几个月都没解决好的投诉。
展开
2
桃子-夏勇杰
2020-01-07
第一步组建特性团队就是一个难题，这是一个思维方式的转变，改变了开发团队原有的开发习惯和思维惯性。宋老师是如何说服团队做这样的转变的呢？
作者回复: 思维方式转变确实是比较难的，仅靠口头说服是远远不够的，所以除了宣讲以外，我采取的方式有很多：带他们参观已经转型的团队，有一些感性认识；必要的时候带他们打个胜仗，团队在不同阶段需要的辅助也是不同的，还有我们在05团队试点里的一些方法等等重要的是要让他们觉得是他们需要改变而不是“我”作为咨询师或者敏捷推动者让他们改变。
共 2 条评论
2
桃子-夏勇杰
2020-01-07
什么是敏捷思维？要解决什么问题？首先要回答好这个问题，否则，不存在所谓的灵魂拷问。
2
再不吃胖我们就老了
2020-01-07
不管是瀑布还是敏捷，对于人员的要求都是有的，只不过敏捷因为是快速迭代的，要求会更高。N年前接触敏捷，今天看完这篇发现现在的项目已经是敏捷式的开发了。现在大家都对MVP、迭代这些习以为常了。
2
王刚
2020-01-07
老师，请教几个问题 1.团队拆分成特性的小组，这个是按照什么标准拆分呢？几个人好呢？ 2.使用敏捷方式，那开发前期的接口文档之类的要不要省略呢？ 3.让业务参与需求分析的过程，是不是就是确定原型的过程？
作者回复: 第三个问题，确切地说，在敏捷当中，业务不仅仅需要确认原型图。我们希望业务能够更多地参与研发过程，具体来讲，在前期需求创意的时候，我们希望能够跟业务在一起梳理，可以是用设计思维的方式，也需要明确业务价值；在迭代准备中，梳理优先级、确认需求等等；在迭代中，有可以确认的东西，如有能演示的版本等都可以找业务来看看，征求他的意见。说到底，业务与开发测试团队之间目标要绑定到一起，要有及时的反馈，这样敏捷开发的效益最大
2
船长
2022-10-01 来自河南
其实无论是瀑布还是敏捷，我觉得重点还是一定是把关键的人员拉进到项目中，让他们参与到设计与确认中来。
1
Gechmind
2020-09-03
我觉得前面的例子讲的不是很好，需求不清晰/功能不满足客户要求真的是瀑布模式的锅么？瀑布模式也是有用户适用何验收环节呀，只不过是比较滞后而已。即使是敏捷模式，允许试错，也只是加快了反馈，快速修改问题。其实也是会有功能不满足客户需求的情况呀。
1
杨承伟
2020-03-28
对于一个产品或者项目来说，如果是在中后期(初版已经完成了，但是要对这个初版进行改造)如何把敏捷开发落实到这个产品或者项目当中呢？
1

