说透敏捷
宋宁
IBM 资深敏捷教练
29080 人已学习
新⼈⾸单¥29
说透敏捷
15
15
1.0x
00:00/00:00
登录|注册

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

有效的需求拆分方法
小需求的特点
处理大需求的策略
正确的需求拆分方法
选择优先级高的需求
培养基础知识和技能
需求拆分
敏捷活动未达预期效益
浪费时间
保持警惕心态
陷入反模式的原因
N团队的建议
M团队的建议
需求过大
团队对敏捷的误解
真正的敏捷
敏捷实践中的问题
分享讨论
自我反思
总结
避免小瀑布
为什么会出现小瀑布
真敏捷 vs. 小瀑布
思考题
反模式:小瀑布

该思维导图由 AI 生成,仅供参考

你好,我是宋宁。
也许很多订阅咱们这门课的同学已经走在了敏捷实践的路上。然而却有很多人在做的过程中,不小心走入了敏捷的反模式。那么该如何检视你的方法是否正确呢?今天,我想用敏捷的一种反模式“小瀑布”来给你讲一下。

真敏捷,还是“小瀑布”?

在我做咨询的过程中,常常会看到一些团队的敏捷实践过程出现下面这些情况:
把一个大项目分成若干个模块,仿照“敏捷”的做法,每四个迭代做一个模块(见下图):第一个迭代做需求,第二个做设计,第三个做开发,第四个做测试。这样四个迭代交付一个模块的内容,然后开始下一个模块的循环。做着做着,他们发现虽然这种方式比以前的瀑布模式要好一点,但整体的节奏仍然缓慢,“敏捷”好像没那么大的效益。
有的团队觉得上面那种方式还是太慢,于是就加快节奏。每个迭代周期也是 2 周,但不同的是,在一个迭代里完成一个大的功能(见下图)。第一周完成需求和设计,第二周完成开发和测试。迭代的次数增加了,但开发和测试却总感觉时间不够,每次迭代都特别赶,体验非常不好。
在上面这两种情景中,团队的感觉不好,但是却不知道自己做得到底对不对,就找我来诊断。那么,上面的做法究竟有没有问题?他们的敏捷活动做得到底对不对呢?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

敏捷开发在实践中常常出现“小瀑布”反模式,即将大项目分成若干模块,每个模块按照瀑布模式依次进行需求、设计、开发和测试,导致效率低下和时间浪费。真正的敏捷应该是将需求有效拆分,使得每个需求都能在短时间内完成开发和测试,形成良好的循环。团队将敏捷玩成“小瀑布”主要是因为对敏捷理解不深和需求拆分不当。团队应该深入理解敏捷规律,合理拆分需求,避免将敏捷变成“小瀑布”。 在文章中,通过M团队和N团队的案例,详细阐述了如何避免将敏捷开发变成“小瀑布”。对于M团队,建议首先给团队讲解基础知识,培养技能,同时强调需求拆分的重要性,以及将工作重点转向客户最需要的工作。对于N团队,建议讲解需求拆分的方法,保证每个小需求的独立性,并在发现需求拆分后仍然很大的情况下,进行系统架构改造和拆分微服务。 总结指出,敏捷开发容易陷入反模式,需要保持警惕,发现问题后分析原因,正确理解敏捷原则,制定相应对策。最后,提出思考题,鼓励读者结合文章内容思考自己在推进敏捷过程中可能犯过的错误,并提出解决方案。 这篇文章通过具体案例和建议,深入探讨了如何避免将敏捷开发变成“小瀑布”,对于正在推进敏捷开发的读者具有很强的实用性和指导意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《说透敏捷》
新⼈⾸单¥29
立即购买
登录 后留言

全部留言(39)

  • 最新
  • 精选
  • 云梦泽
    如何拆分用户故事是敏捷开发一个很关键的部分,而评估是否是一个好的用户故事标准就是能否独立进行上线,如果做不到独立上线,那这个还不叫用户故事,测试也没办法并行进行,也不是真正的敏捷开发。另外敏捷开发跟现在到微服务架构是相辅相成,敏捷开发非常适合微服务这种开发模式,微服务能够提高敏捷开发的效率。总之,敏捷开发的精髓应该是团队至上,小步快跑,快速迭代,拥抱变化。不知道对于敏捷开发这样的理解有没有问题,请老师点评一下。

    作者回复: 赞一个!优秀用户故事的标准业界有通用的认识,公认的是符合INVEST原则。在《用户故事与敏捷方法》一书中有介绍,可以去看一下。

    2020-01-07
    2
    26
  • 无需昵称
    老师好,针对老师的这句话“我们工作的结束点不应该是把之前所有计划的工作做完,而是把客户需要的工作做完。”,在实施固定总价合同的客户项目时,如何比较好的控制项目的范围和成本呢?有时候客户和我们在项目初期都没有办法完全界定清楚,什么是客户需要的工作?

    作者回复: 这里要管理好客户期望。始终要对客户灌输价值理念,让他自己挑选价值最大的需求,以及向其可视化你们的工作,让他理解到在有限的时间内,有限的资源不能完成所有的事情,但我们能保证的是在给定的资源和时间内给他最好的。 另外就是要让客户真正理解敏捷的概念,否则就变成对团队的压榨了。客户首先要能区分清楚他们的需求中哪些是价值大的要优先做的,其次是在每个迭代中要给开发团队反馈,让团队知道哪些已经做的可以了,哪些产品还需要优化。 再者一定要管理好需求列表。

    2020-01-11
    3
    6
  • 小老鼠
    1,我已前开发过一个ITLE产品,必须包括五个模块才能叫ITLE产品,由于市场压力老板一定要我们五个月完成,但时间的确不够,若用敏捷,该如何处理。2,DevOps中持续部署流。需求-设计-开发-构建-集成测试-发布-验收测试-部署-预生产环境测试-正式生产,这个是不是也是个小瀑布?

    作者回复: 1、挑能够完成的最小可行性产品MVP进行开发 2、这个不是小瀑布

    2020-01-18
    2
  • Raymond吕
    老师说的大瀑布中小敏捷的累,我们正在踩。 我们公司内部的工具开发,面向开发做小工具,可能是开发提的需求一般都比较明确,所以效率并没感觉降低。老师说导入敏捷要先找到组织当前的痛点,如果现在并没有觉得“痛”,怎么办呢?

    作者回复: 一般都是有痛点的,很多时候是大家已经习以为常了,都感觉不到“痛”了。所以这里有两个问题,一个是确实目前研发管理方式不错,感觉各个方面没有任何痛点,这样保持现有方式即可;还有一个是有痛却没感到痛,这个是比较麻烦的,需要让团队感知到,一个是通过提问的技巧引发思考,还有一些就是请外部的“咨询师”来说出来。

    2020-01-09
    2
    2
  • 落地得分
    我们是创业公司,主要工作就是主业务的日常迭代,都不是很大的需求。正常开发也是一周左右可以上线。任务故事根本无需拆分,这样怎么去实施敏捷呢?

    作者回复: 主要看你们目前的研发工作组织方式有无痛点。如果一切运行OK,那么不需要做什么改变,如果现在感觉管理上有些混乱,那么可以找找原因,然后来具体应对。如果要选择实施敏捷,可以从一些小点开始,例如先把所有的工作用看板管理起来,开个站会,定期进行回顾来改进工作等等

    2020-01-09
    2
  • 李永智
    做个一个项目,将小瀑布方式当做敏捷来看待,造成这个状况原因有二:第一,对敏捷的理解不到位,当时认为需求、设计、开发、测试还是要顺序进行,虽然这些工作是顺序的,但是开展工作时要做到能同步开展工作,这个对团队人员的要求还是蛮高的。 第二,工作能力与工作量不匹配。当时工作量很大,但工期比较短,以当时的人员配比是无法完成的。虽然当时也安排了优先级,不过是按照功能进行拆解的,没有考虑有些业务场景是需要几个功能同时具备才能走通,而实际是各自小组按照自己负责功能模块划分优先级,没有从用户角度考虑某些使用场景需要多个功能关联推进。
    2020-01-13
    10
  • Joey
    请教老师,我们是金融行业的开发部门,约1000人,组织架构并非是小功能性团队,即需求、开发、测试都是独立的团队;此外,我们部门只负责开发,交付版本,公司还有专门的运维部门承担运维角色,负责版本上线,生产监控等职责。 请问这种情况下,是否适合退敏捷研发流程?(组织架构变动的可能性基本为零),如果不行,可以借鉴敏捷思想的哪些实践,来提升部门的整体研发效能,谢谢老师解答。
    2020-05-19
    2
    9
  • J.Smile
    需求的细化和排期不单单是个流程化的东西,还得考虑一些团队情绪,因为即使开发提交测试以后继续下一个小需求开发,这个本身需要有个度,开发不是机械劳动,代码写之前需要充分思考,但在此期间如果总是因为配合测试而打断,也会很心累,所以这中间需要一个缓冲地带,就好比人与人之间的安全距离。可以看出敏捷的迭代频率快,对开发本身技能要求高,所以完全推进的话,对大部分企业还是有不小困难!
    2020-01-28
    7
  • escray
    说透敏捷 08 | 避雷策略:如何防止你的敏捷变为“小瀑布”? 上一篇是避坑指南,这一次是防雷策略,看来推进敏捷还真是不容易。 其实我们单位现在的一个外包团队就是在采用小瀑布的方式在开发。首先,是因为这个项目本身就是一个比较长期的工程,针对的是在线系统的升级改造。以前采用的是瀑布开发方式,后来因为项目本身的发展,同时也因为瀑布的确出现了很多问题,所以改成了现在的迭代瀑布,其实已经算是一种进步了。 外包单位本身也是国有研究院所,这种迭代小瀑布的方式在他们那边也不被认可,因为软件系统要有“出所”的测试和评审,所以现在的迭代也只能低调进行。这个可能与合同签订的时候的约束条件有关,也可能与原有的外包团队的制度有关。 感觉虽然不是地道的敏捷,但是其实也还是有一定的益处,并且并没有过多造成工时的积压和浪费,可能那些需求分析人员以及测试人员都身兼数个项目。缺点当然也很明显,因为身兼多个项目,所以带来了投入时间的不充分。 之所以现在是小瀑布模式,首先是因为外包团队并没有准备敏捷转型,另外就是需求也没有被分解成可以在很短的迭代周期内完成,最后,我认为比较重要的原因,就是现有系统的架构,并不支持持续集成和连续发布。 把大需求拆分成能够独立开发测试的小需求,这个是否对于架构有很高的要求?我觉的似乎只有目前流行的“微服务”能够做到,但是微服务那边,本身也是一堆的坑要填。 文章中提到的那个 N 团队,在开发测试之余,还对产品进行了架构演化,拆分微服务,这个还真是厉害。
    2020-01-15
    5
  • 玉龙
    一个2周的迭代,需求澄清应该在上个迭代,需求 和开发测试异步在上下2个迭代更合适,否则一个迭代内,一周的需求澄清加一周的开发测试都很累,产品质量还不好,特别是测试的时间因为需求和开发被消耗的时间都需要测试消化掉,测试就容易不充分,不充分意味着,上线风险大,只能菩萨保佑了
    2020-01-18
    4
收起评论
显示
设置
留言
39
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部