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

Jan 6, 2020

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



下载APP





关闭

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

渠道合作

推荐作者

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

2020-01-06 宋宁来自北京

《说透敏捷》

课程介绍



讲述：宋宁

时长15:07大小13.85M



你好，我是宋宁。
也许很多订阅咱们这门课的同学已经走在了敏捷实践的路上。然而却有很多人在做的过程中，不小心走入了敏捷的反模式。那么该如何检视你的方法是否正确呢？今天，我想用敏捷的一种反模式“小瀑布”来给你讲一下。
真敏捷，还是“小瀑布”？在我做咨询的过程中，常常会看到一些团队的敏捷实践过程出现下面这些情况：
把一个大项目分成若干个模块，仿照“敏捷”的做法，每四个迭代做一个模块（见下图）：第一个迭代做需求，第二个做设计，第三个做开发，第四个做测试。这样四个迭代交付一个模块的内容，然后开始下一个模块的循环。做着做着，他们发现虽然这种方式比以前的瀑布模式要好一点，但整体的节奏仍然缓慢，“敏捷”好像没那么大的效益。
有的团队觉得上面那种方式还是太慢，于是就加快节奏。每个迭代周期也是 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，很可能就做不好，因为这两个角色要求的技能是完全不同的，技术经理是没有足够的能力和精力来同时担当这些责任的。
但其实陷入了反模式并不可怕，重要的是你一定要保持警惕的心。在发现问题后，需要沉下心来分析原因，只有将具体原因找出了，在正确理解敏捷原则的基础上灵活使用，制定相应的对策，才能真正发挥敏捷的价值，才能继续正确地走下去。
思考题现在，我想请你来思考一下，你在推进敏捷的过程中有没有犯过什么错误呢？我建议你结合今天的内容，先自己想一下怎么解决，再来留言区跟我一起讨论一下吧。
我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

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

生成海报并分享

赞 13

提建议

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

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

 写留言

精选留言(39)

云梦泽
2020-01-07
如何拆分用户故事是敏捷开发一个很关键的部分，而评估是否是一个好的用户故事标准就是能否独立进行上线，如果做不到独立上线，那这个还不叫用户故事，测试也没办法并行进行，也不是真正的敏捷开发。另外敏捷开发跟现在到微服务架构是相辅相成，敏捷开发非常适合微服务这种开发模式，微服务能够提高敏捷开发的效率。总之，敏捷开发的精髓应该是团队至上，小步快跑，快速迭代，拥抱变化。不知道对于敏捷开发这样的理解有没有问题，请老师点评一下。
展开
作者回复: 赞一个！优秀用户故事的标准业界有通用的认识，公认的是符合INVEST原则。在《用户故事与敏捷方法》一书中有介绍，可以去看一下。
共 2 条评论
24
李永智
2020-01-13
做个一个项目，将小瀑布方式当做敏捷来看待，造成这个状况原因有二：第一，对敏捷的理解不到位，当时认为需求、设计、开发、测试还是要顺序进行，虽然这些工作是顺序的，但是开展工作时要做到能同步开展工作，这个对团队人员的要求还是蛮高的。第二，工作能力与工作量不匹配。当时工作量很大，但工期比较短，以当时的人员配比是无法完成的。虽然当时也安排了优先级，不过是按照功能进行拆解的，没有考虑有些业务场景是需要几个功能同时具备才能走通，而实际是各自小组按照自己负责功能模块划分优先级，没有从用户角度考虑某些使用场景需要多个功能关联推进。
展开
10
Joey
2020-05-19
请教老师，我们是金融行业的开发部门，约1000人，组织架构并非是小功能性团队，即需求、开发、测试都是独立的团队；此外，我们部门只负责开发，交付版本，公司还有专门的运维部门承担运维角色，负责版本上线，生产监控等职责。请问这种情况下，是否适合退敏捷研发流程？（组织架构变动的可能性基本为零），如果不行，可以借鉴敏捷思想的哪些实践，来提升部门的整体研发效能，谢谢老师解答。
展开
共 2 条评论
8
J.Smile
2020-01-28
需求的细化和排期不单单是个流程化的东西，还得考虑一些团队情绪，因为即使开发提交测试以后继续下一个小需求开发，这个本身需要有个度，开发不是机械劳动，代码写之前需要充分思考，但在此期间如果总是因为配合测试而打断，也会很心累，所以这中间需要一个缓冲地带，就好比人与人之间的安全距离。可以看出敏捷的迭代频率快，对开发本身技能要求高，所以完全推进的话，对大部分企业还是有不小困难！
7
escray
2020-01-15
说透敏捷 08 | 避雷策略：如何防止你的敏捷变为“小瀑布”？上一篇是避坑指南，这一次是防雷策略，看来推进敏捷还真是不容易。其实我们单位现在的一个外包团队就是在采用小瀑布的方式在开发。首先，是因为这个项目本身就是一个比较长期的工程，针对的是在线系统的升级改造。以前采用的是瀑布开发方式，后来因为项目本身的发展，同时也因为瀑布的确出现了很多问题，所以改成了现在的迭代瀑布，其实已经算是一种进步了。外包单位本身也是国有研究院所，这种迭代小瀑布的方式在他们那边也不被认可，因为软件系统要有“出所”的测试和评审，所以现在的迭代也只能低调进行。这个可能与合同签订的时候的约束条件有关，也可能与原有的外包团队的制度有关。感觉虽然不是地道的敏捷，但是其实也还是有一定的益处，并且并没有过多造成工时的积压和浪费，可能那些需求分析人员以及测试人员都身兼数个项目。缺点当然也很明显，因为身兼多个项目，所以带来了投入时间的不充分。之所以现在是小瀑布模式，首先是因为外包团队并没有准备敏捷转型，另外就是需求也没有被分解成可以在很短的迭代周期内完成，最后，我认为比较重要的原因，就是现有系统的架构，并不支持持续集成和连续发布。把大需求拆分成能够独立开发测试的小需求，这个是否对于架构有很高的要求？我觉的似乎只有目前流行的“微服务”能够做到，但是微服务那边，本身也是一堆的坑要填。文章中提到的那个 N 团队，在开发测试之余，还对产品进行了架构演化，拆分微服务，这个还真是厉害。
展开
5
无需昵称
2020-01-11
老师好，针对老师的这句话“我们工作的结束点不应该是把之前所有计划的工作做完，而是把客户需要的工作做完。”，在实施固定总价合同的客户项目时，如何比较好的控制项目的范围和成本呢？有时候客户和我们在项目初期都没有办法完全界定清楚，什么是客户需要的工作？
作者回复: 这里要管理好客户期望。始终要对客户灌输价值理念，让他自己挑选价值最大的需求，以及向其可视化你们的工作，让他理解到在有限的时间内，有限的资源不能完成所有的事情，但我们能保证的是在给定的资源和时间内给他最好的。另外就是要让客户真正理解敏捷的概念，否则就变成对团队的压榨了。客户首先要能区分清楚他们的需求中哪些是价值大的要优先做的，其次是在每个迭代中要给开发团队反馈，让团队知道哪些已经做的可以了，哪些产品还需要优化。再者一定要管理好需求列表。
共 2 条评论
5
Geek_bd800b
2021-02-19
需求不停的这需求，开发不停的开发，测试不停的测试，循环往复，谁都停不下来，结果就是代码能用就行，匆忙上线，代码质量堪忧，开发人员受不了，离职率高，后面接手的人吐槽不断。
3
Hugo
2020-02-07
我在游戏行业，目前实行的就是2周迭代的方式，两周内安排是：需求理解->设计->开发->测试->上线要点： 1. 迭代开始时，需求是已经准备好的，准确来说是个需求池，最好能列好优先级 2.迭代开始时，开发测试从池子里挑选两周迭代能搞定的需求，同时考虑时间和需求优先级 3.切忌不要犯承若过多的错误刚刚试运行时磕磕绊绊，经历多个迭代和回顾会议之后，目前开始正常运转，个人觉得互联网行业唯快不破的节奏下很难存在瀑布开发模式，大部分都是各式各样的敏捷模式，而敏捷的核心是让业务，开发，测试全链条热火朝天运转起来，如果能做到这个其实架子应该没有问题，剩下就是利用回顾会议针对性的解决问题了。
展开
共 2 条评论
3
玉龙
2020-01-18
一个2周的迭代，需求澄清应该在上个迭代，需求和开发测试异步在上下2个迭代更合适，否则一个迭代内，一周的需求澄清加一周的开发测试都很累，产品质量还不好，特别是测试的时间因为需求和开发被消耗的时间都需要测试消化掉，测试就容易不充分，不充分意味着，上线风险大，只能菩萨保佑了
4
海棠
2020-01-14
记得第一次真正开展敏捷实践，照搬Scrum全流程，结果被大家强力吐槽😂
共 1 条评论
3
Bradly
2022-02-01
刚做项目经理不久，在拆分需求这块是弱点，在开发过程中经常发现漏了需求或需求分析的不对，关于拆分需求，老师有没有什么方法和建议？
共 1 条评论
2
而立斋
2020-01-30
所以从这个角度来说，小瀑布依旧是瀑布，它并没有改变瀑布模式的宿命，它离真正的敏捷还有相当长的一段距离。如何界定小瀑布与敏捷呢？从结果导向上来看，看你的需求拆分粒度，看你的测试人员在开发人员开发时，在干什么。
2
小老鼠
2020-01-18
1，我已前开发过一个ITLE产品，必须包括五个模块才能叫ITLE产品，由于市场压力老板一定要我们五个月完成，但时间的确不够，若用敏捷，该如何处理。2，DevOps中持续部署流。需求-设计-开发-构建－集成测试-发布-验收测试-部署-预生产环境测试-正式生产，这个是不是也是个小瀑布？
作者回复: 1、挑能够完成的最小可行性产品MVP进行开发 2、这个不是小瀑布
2
Raymond吕
2020-01-09
老师说的大瀑布中小敏捷的累，我们正在踩。我们公司内部的工具开发，面向开发做小工具，可能是开发提的需求一般都比较明确，所以效率并没感觉降低。老师说导入敏捷要先找到组织当前的痛点，如果现在并没有觉得“痛”，怎么办呢？
作者回复: 一般都是有痛点的，很多时候是大家已经习以为常了，都感觉不到“痛”了。所以这里有两个问题，一个是确实目前研发管理方式不错，感觉各个方面没有任何痛点，这样保持现有方式即可；还有一个是有痛却没感到痛，这个是比较麻烦的，需要让团队感知到，一个是通过提问的技巧引发思考，还有一些就是请外部的“咨询师”来说出来。
共 2 条评论
2
落地得分
2020-01-09
我们是创业公司，主要工作就是主业务的日常迭代，都不是很大的需求。正常开发也是一周左右可以上线。任务故事根本无需拆分，这样怎么去实施敏捷呢？
作者回复: 主要看你们目前的研发工作组织方式有无痛点。如果一切运行OK，那么不需要做什么改变，如果现在感觉管理上有些混乱，那么可以找找原因，然后来具体应对。如果要选择实施敏捷，可以从一些小点开始，例如先把所有的工作用看板管理起来，开个站会，定期进行回顾来改进工作等等
2
郭占冰
2022-01-07
即使需求拆分的足够小，实现起来还是“小瀑布”啊，我理解的文章的意思是：要能同时、交叉存在多个“小瀑布”，需求、开发、测试在同一时间都有事情做，不存在“谁在等谁”的情况，这样整体看来就不是“串行”，而是“并行”的了，和cpu的工作原理一样，cpu再nb，号称多核可以同时处理很多任务，内部也是每个任务“串行”执行的，只不过是每个任务足够小，执行时间足够快，这样在一个维度上看，就是“并行”的了，也就是“敏捷”的了
共 1 条评论
1
吴帆
2021-10-12
设计这个活动能并行么？或者说设计是要交给每个故事的开发人员来做么？
1
行骏
2021-09-01
再谈一个现实的问题：确实是每个迭代都是一个独立的小需求了，但也演变了全部都是小需求了，看不到大需求是什么，每个迭代做不完的小需求。
共 1 条评论
1
刘隐林
2021-05-28
合理,高效的拆分用户故事是关键,如果故事拆的不好,直接导致故事测试,提交的质量问题,如果拆的太慢,也会导致团队在讨论过程中消耗大量时间. 同时,尤其在前期不成熟的时候,Scrum Master和PO最好要有人全职做,要充分认识到这两个岗位的重要性和复杂性,只有当Scrum Master已经很熟悉,有了一定的经验后,可以考虑兼职做
1
秦悦
2021-01-23
全课程的坑都踩过
1

