08 | 避雷策略：如何防止你的敏捷变为“小瀑布”？
该思维导图由 AI 生成，仅供参考
真敏捷，还是“小瀑布”？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
敏捷开发在实践中常常出现“小瀑布”反模式，即将大项目分成若干模块，每个模块按照瀑布模式依次进行需求、设计、开发和测试，导致效率低下和时间浪费。真正的敏捷应该是将需求有效拆分，使得每个需求都能在短时间内完成开发和测试，形成良好的循环。团队将敏捷玩成“小瀑布”主要是因为对敏捷理解不深和需求拆分不当。团队应该深入理解敏捷规律，合理拆分需求，避免将敏捷变成“小瀑布”。 在文章中，通过M团队和N团队的案例，详细阐述了如何避免将敏捷开发变成“小瀑布”。对于M团队，建议首先给团队讲解基础知识，培养技能，同时强调需求拆分的重要性，以及将工作重点转向客户最需要的工作。对于N团队，建议讲解需求拆分的方法，保证每个小需求的独立性，并在发现需求拆分后仍然很大的情况下，进行系统架构改造和拆分微服务。 总结指出，敏捷开发容易陷入反模式，需要保持警惕，发现问题后分析原因，正确理解敏捷原则，制定相应对策。最后，提出思考题，鼓励读者结合文章内容思考自己在推进敏捷过程中可能犯过的错误，并提出解决方案。 这篇文章通过具体案例和建议，深入探讨了如何避免将敏捷开发变成“小瀑布”，对于正在推进敏捷开发的读者具有很强的实用性和指导意义。
《说透敏捷》，新⼈⾸单¥29
全部留言(39)
- 最新
- 精选
云梦泽如何拆分用户故事是敏捷开发一个很关键的部分，而评估是否是一个好的用户故事标准就是能否独立进行上线，如果做不到独立上线，那这个还不叫用户故事，测试也没办法并行进行，也不是真正的敏捷开发。另外敏捷开发跟现在到微服务架构是相辅相成，敏捷开发非常适合微服务这种开发模式，微服务能够提高敏捷开发的效率。总之，敏捷开发的精髓应该是团队至上，小步快跑，快速迭代，拥抱变化。不知道对于敏捷开发这样的理解有没有问题，请老师点评一下。作者回复: 赞一个！优秀用户故事的标准业界有通用的认识，公认的是符合INVEST原则。在《用户故事与敏捷方法》一书中有介绍，可以去看一下。
2020-01-07226- 无需昵称老师好，针对老师的这句话“我们工作的结束点不应该是把之前所有计划的工作做完，而是把客户需要的工作做完。”，在实施固定总价合同的客户项目时，如何比较好的控制项目的范围和成本呢？有时候客户和我们在项目初期都没有办法完全界定清楚，什么是客户需要的工作？
作者回复: 这里要管理好客户期望。始终要对客户灌输价值理念，让他自己挑选价值最大的需求，以及向其可视化你们的工作，让他理解到在有限的时间内，有限的资源不能完成所有的事情，但我们能保证的是在给定的资源和时间内给他最好的。 另外就是要让客户真正理解敏捷的概念，否则就变成对团队的压榨了。客户首先要能区分清楚他们的需求中哪些是价值大的要优先做的，其次是在每个迭代中要给开发团队反馈，让团队知道哪些已经做的可以了，哪些产品还需要优化。 再者一定要管理好需求列表。
2020-01-1136 
小老鼠1，我已前开发过一个ITLE产品，必须包括五个模块才能叫ITLE产品，由于市场压力老板一定要我们五个月完成，但时间的确不够，若用敏捷，该如何处理。2，DevOps中持续部署流。需求-设计-开发-构建－集成测试-发布-验收测试-部署-预生产环境测试-正式生产，这个是不是也是个小瀑布？作者回复: 1、挑能够完成的最小可行性产品MVP进行开发 2、这个不是小瀑布
2020-01-182
Raymond吕老师说的大瀑布中小敏捷的累，我们正在踩。 我们公司内部的工具开发，面向开发做小工具，可能是开发提的需求一般都比较明确，所以效率并没感觉降低。老师说导入敏捷要先找到组织当前的痛点，如果现在并没有觉得“痛”，怎么办呢？作者回复: 一般都是有痛点的，很多时候是大家已经习以为常了，都感觉不到“痛”了。所以这里有两个问题，一个是确实目前研发管理方式不错，感觉各个方面没有任何痛点，这样保持现有方式即可；还有一个是有痛却没感到痛，这个是比较麻烦的，需要让团队感知到，一个是通过提问的技巧引发思考，还有一些就是请外部的“咨询师”来说出来。
2020-01-0922- 落地得分我们是创业公司，主要工作就是主业务的日常迭代，都不是很大的需求。正常开发也是一周左右可以上线。任务故事根本无需拆分，这样怎么去实施敏捷呢？
作者回复: 主要看你们目前的研发工作组织方式有无痛点。如果一切运行OK，那么不需要做什么改变，如果现在感觉管理上有些混乱，那么可以找找原因，然后来具体应对。如果要选择实施敏捷，可以从一些小点开始，例如先把所有的工作用看板管理起来，开个站会，定期进行回顾来改进工作等等
2020-01-092 
李永智做个一个项目，将小瀑布方式当做敏捷来看待，造成这个状况原因有二：第一，对敏捷的理解不到位，当时认为需求、设计、开发、测试还是要顺序进行，虽然这些工作是顺序的，但是开展工作时要做到能同步开展工作，这个对团队人员的要求还是蛮高的。 第二，工作能力与工作量不匹配。当时工作量很大，但工期比较短，以当时的人员配比是无法完成的。虽然当时也安排了优先级，不过是按照功能进行拆解的，没有考虑有些业务场景是需要几个功能同时具备才能走通，而实际是各自小组按照自己负责功能模块划分优先级，没有从用户角度考虑某些使用场景需要多个功能关联推进。2020-01-1310
Joey请教老师，我们是金融行业的开发部门，约1000人，组织架构并非是小功能性团队，即需求、开发、测试都是独立的团队；此外，我们部门只负责开发，交付版本，公司还有专门的运维部门承担运维角色，负责版本上线，生产监控等职责。 请问这种情况下，是否适合退敏捷研发流程？（组织架构变动的可能性基本为零），如果不行，可以借鉴敏捷思想的哪些实践，来提升部门的整体研发效能，谢谢老师解答。2020-05-1929
J.Smile需求的细化和排期不单单是个流程化的东西，还得考虑一些团队情绪，因为即使开发提交测试以后继续下一个小需求开发，这个本身需要有个度，开发不是机械劳动，代码写之前需要充分思考，但在此期间如果总是因为配合测试而打断，也会很心累，所以这中间需要一个缓冲地带，就好比人与人之间的安全距离。可以看出敏捷的迭代频率快，对开发本身技能要求高，所以完全推进的话，对大部分企业还是有不小困难！2020-01-287
escray
说透敏捷 08 | 避雷策略：如何防止你的敏捷变为“小瀑布”？ 上一篇是避坑指南，这一次是防雷策略，看来推进敏捷还真是不容易。 其实我们单位现在的一个外包团队就是在采用小瀑布的方式在开发。首先，是因为这个项目本身就是一个比较长期的工程，针对的是在线系统的升级改造。以前采用的是瀑布开发方式，后来因为项目本身的发展，同时也因为瀑布的确出现了很多问题，所以改成了现在的迭代瀑布，其实已经算是一种进步了。 外包单位本身也是国有研究院所，这种迭代小瀑布的方式在他们那边也不被认可，因为软件系统要有“出所”的测试和评审，所以现在的迭代也只能低调进行。这个可能与合同签订的时候的约束条件有关，也可能与原有的外包团队的制度有关。 感觉虽然不是地道的敏捷，但是其实也还是有一定的益处，并且并没有过多造成工时的积压和浪费，可能那些需求分析人员以及测试人员都身兼数个项目。缺点当然也很明显，因为身兼多个项目，所以带来了投入时间的不充分。 之所以现在是小瀑布模式，首先是因为外包团队并没有准备敏捷转型，另外就是需求也没有被分解成可以在很短的迭代周期内完成，最后，我认为比较重要的原因，就是现有系统的架构，并不支持持续集成和连续发布。 把大需求拆分成能够独立开发测试的小需求，这个是否对于架构有很高的要求？我觉的似乎只有目前流行的“微服务”能够做到，但是微服务那边，本身也是一堆的坑要填。 文章中提到的那个 N 团队，在开发测试之余，还对产品进行了架构演化，拆分微服务，这个还真是厉害。2020-01-155
玉龙一个2周的迭代，需求澄清应该在上个迭代，需求 和开发测试异步在上下2个迭代更合适，否则一个迭代内，一周的需求澄清加一周的开发测试都很累，产品质量还不好，特别是测试的时间因为需求和开发被消耗的时间都需要测试消化掉，测试就容易不充分，不充分意味着，上线风险大，只能菩萨保佑了2020-01-184
