说透敏捷
宋宁
IBM资深敏捷教练
立即订阅
6218 人已学习
课程目录
已完结 12 讲
开篇词 (1讲)
开篇词 | 重识敏捷,让你的研发管理少走一些弯路
免费
原理篇 (2讲)
01 | 灵魂拷问:如何利用敏捷思维更好地解决实际问题?
02 | 老生常谈:你真的知道敏捷到底是什么吗?
实战篇 (4讲)
03 | 评估诊断:成功迈出敏捷推进的第一步
04 | 团队试点(一):让你的敏捷实践“事半功倍”
05 | 团队试点(二):打造一支无往不胜的敏捷团队
06 | 规模化推广:复制粘贴试点的经验就够了吗?
策略篇 (2讲)
07 | 填坑指南:填好这4个坑,快速做对敏捷
08 | 避雷策略:如何防止你的敏捷变为“小瀑布”?
管理篇 (2讲)
09 | 内部教练:守护敏捷实践,求人不如求己
10 | 服务型领导:在敏捷中你该怎样提升自己的领导力?
结束语 (1讲)
结束语 | 用敏捷提升自己,从敏捷走向未来
说透敏捷
登录|注册

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

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

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

在我提供敏捷咨询的过程中,常常会看到一些团队的敏捷实践过程出现下面这些情况:
把一个大项目分成若干个模块,仿照“敏捷”的做法,每四个迭代做一个模块 (见下图):第一个迭代做需求,第二个迭代做设计,第三个迭代做开发,第四个迭代做测试。这样四个迭代交付一个模块的内容,然后开始下一个模块的循环。做着做着,他们发现这种方式比以前的瀑布模式要好一点,但整体的节奏仍然缓慢,“敏捷”好像没那么大的效益。
有的团队觉得上面那种方式还是太慢,于是加快节奏。每个迭代周期也是 2 周,但不同的是,在一个迭代里完成一个大的功能(见下图)。第一周完成需求和设计,第二周完成开发和测试。迭代的次数增加了,但开发和测试却总感觉时间不够,每次迭代都特别赶,体验非常不好。
团队的感觉不好,然而却不知道自己做得到底对不对,就找身为敏捷咨询师的我来诊断。那么上面的做法究竟有没有问题?他们的敏捷活动做得到底对不对呢?
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《说透敏捷》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(19)

  • 李永智
    做个一个项目,将小瀑布方式当做敏捷来看待,造成这个状况原因有二:第一,对敏捷的理解不到位,当时认为需求、设计、开发、测试还是要顺序进行,虽然这些工作是顺序的,但是开展工作时要做到能同步开展工作,这个对团队人员的要求还是蛮高的。 第二,工作能力与工作量不匹配。当时工作量很大,但工期比较短,以当时的人员配比是无法完成的。虽然当时也安排了优先级,不过是按照功能进行拆解的,没有考虑有些业务场景是需要几个功能同时具备才能走通,而实际是各自小组按照自己负责功能模块划分优先级,没有从用户角度考虑某些使用场景需要多个功能关联推进。
    2020-01-13
    6
  • louis_lam
    如何拆分用户故事是敏捷开发一个很关键的部分,而评估是否是一个好的用户故事标准就是能否独立进行上线,如果做不到独立上线,那这个还不叫用户故事,测试也没办法并行进行,也不是真正的敏捷开发。另外敏捷开发跟现在到微服务架构是相辅相成,敏捷开发非常适合微服务这种开发模式,微服务能够提高敏捷开发的效率。总之,敏捷开发的精髓应该是团队至上,小步快跑,快速迭代,拥抱变化。不知道对于敏捷开发这样的理解有没有问题,请老师点评一下。

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

    2020-01-07
    4
  • escray
    说透敏捷
    08 | 避雷策略:如何防止你的敏捷变为“小瀑布”?

    上一篇是避坑指南,这一次是防雷策略,看来推进敏捷还真是不容易。

    其实我们单位现在的一个外包团队就是在采用小瀑布的方式在开发。首先,是因为这个项目本身就是一个比较长期的工程,针对的是在线系统的升级改造。以前采用的是瀑布开发方式,后来因为项目本身的发展,同时也因为瀑布的确出现了很多问题,所以改成了现在的迭代瀑布,其实已经算是一种进步了。

    外包单位本身也是国有研究院所,这种迭代小瀑布的方式在他们那边也不被认可,因为软件系统要有“出所”的测试和评审,所以现在的迭代也只能低调进行。这个可能与合同签订的时候的约束条件有关,也可能与原有的外包团队的制度有关。

    感觉虽然不是地道的敏捷,但是其实也还是有一定的益处,并且并没有过多造成工时的积压和浪费,可能那些需求分析人员以及测试人员都身兼数个项目。缺点当然也很明显,因为身兼多个项目,所以带来了投入时间的不充分。

    之所以现在是小瀑布模式,首先是因为外包团队并没有准备敏捷转型,另外就是需求也没有被分解成可以在很短的迭代周期内完成,最后,我认为比较重要的原因,就是现有系统的架构,并不支持持续集成和连续发布。

    把大需求拆分成能够独立开发测试的小需求,这个是否对于架构有很高的要求?我觉的似乎只有目前流行的“微服务”能够做到,但是微服务那边,本身也是一堆的坑要填。

    文章中提到的那个 N 团队,在开发测试之余,还对产品进行了架构演化,拆分微服务,这个还真是厉害。
    2020-01-15
    2
  • 海棠
    记得第一次真正开展敏捷实践,照搬Scrum全流程,结果被大家强力吐槽😂
    2020-01-14
    1
  • 工画师
    做敏捷最关键的还是搞定高层领导团队,让领导团队理解认识、跟踪推动,这是一切的基础,否则组织和资源会是问题,阻力会非常大。然后就是挑选意愿和整体素质相对较高的团队,我觉得这个也是推行实践相对会顺利的重要因素。
    2020-02-08
  • 旭东
    有MCP的思想在就不会跑太偏,提供最小的最有价值的功能迭代,即使是小瀑布也挺好。瀑布的不一定就不好,只要做到小步快跑,做正确的最有价值的事就好
    2020-02-07
  • Jaising
    N团队是如何拆分需求保证需求开发测试独立性的,宋老师可以展开讲一下嘛
    2020-02-07
  • Hugo
    我在游戏行业,目前实行的就是2周迭代的方式,两周内安排是:
    需求理解->设计->开发->测试->上线
    要点:
    1. 迭代开始时,需求是已经准备好的,准确来说是个需求池,最好能列好优先级
    2.迭代开始时,开发测试从池子里挑选两周迭代能搞定的需求,同时考虑时间和需求优先级
    3.切忌不要犯承若过多的错误
    刚刚试运行时磕磕绊绊,经历多个迭代和回顾会议之后,目前开始正常运转,
    个人觉得互联网行业唯快不破的节奏下很难存在瀑布开发模式,大部分都是各式各样的敏捷模式,
    而敏捷的核心是让业务,开发,测试全链条热火朝天运转起来,如果能做到这个其实架子应该没有问题,
    剩下就是利用回顾会议针对性的解决问题了。
    2020-02-07
  • 张汉桂-东莞
    我还没上过敏捷,不过今天的课有点启发:
    把大需求拆分成独立的小需求,减少模块之间的耦合。
    2020-02-05
  • 老王的老李头
    所以从这个角度来说,小瀑布依旧是瀑布,它并没有改变瀑布模式的宿命,它离真正的敏捷还有相当长的一段距离。
    如何界定小瀑布与敏捷呢?从结果导向上来看,看你的需求拆分粒度,看你的测试人员在开发人员开发时,在干什么。
    2020-01-30
  • Jeff.Smile
    需求的细化和排期不单单是个流程化的东西,还得考虑一些团队情绪,因为即使开发提交测试以后继续下一个小需求开发,这个本身需要有个度,开发不是机械劳动,代码写之前需要充分思考,但在此期间如果总是因为配合测试而打断,也会很心累,所以这中间需要一个缓冲地带,就好比人与人之间的安全距离。可以看出敏捷的迭代频率快,对开发本身技能要求高,所以完全推进的话,对大部分企业还是有不小困难!
    2020-01-28
  • 小老鼠
    1,我已前开发过一个ITLE产品,必须包括五个模块才能叫ITLE产品,由于市场压力老板一定要我们五个月完成,但时间的确不够,若用敏捷,该如何处理。2,DevOps中持续部署流。需求-设计-开发-构建-集成测试-发布-验收测试-部署-预生产环境测试-正式生产,这个是不是也是个小瀑布?

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

    2020-01-18
  • 玉龙
    一个2周的迭代,需求澄清应该在上个迭代,需求 和开发测试异步在上下2个迭代更合适,否则一个迭代内,一周的需求澄清加一周的开发测试都很累,产品质量还不好,特别是测试的时间因为需求和开发被消耗的时间都需要测试消化掉,测试就容易不充分,不充分意味着,上线风险大,只能菩萨保佑了
    2020-01-18
  • 你的美
    敏捷和微服务有点天生就是好兄弟的感觉。说起这个小瀑布,就像那个系统拆分做成了一个一个小单体。
    2020-01-11
  • 无需昵称
    老师好,针对老师的这句话“我们工作的结束点不应该是把之前所有计划的工作做完,而是把客户需要的工作做完。”,在实施固定总价合同的客户项目时,如何比较好的控制项目的范围和成本呢?有时候客户和我们在项目初期都没有办法完全界定清楚,什么是客户需要的工作?

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

    2020-01-11
  • 再不吃胖我们就老了
    很难相信居然还有小瀑布这样的团队,游戏行业策划还能闲着等下一个迭代,早被喷死了。
    2020-01-10
    1
  • Raymond吕
    老师说的大瀑布中小敏捷的累,我们正在踩。
    我们公司内部的工具开发,面向开发做小工具,可能是开发提的需求一般都比较明确,所以效率并没感觉降低。老师说导入敏捷要先找到组织当前的痛点,如果现在并没有觉得“痛”,怎么办呢?

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

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

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

    2020-01-09
  • 吴言乱语
    在实际工作中,因为涉及外部团队的配合,所以需求拆分可以按照内部测试单元和外部测试单元进行分类,从而更好的评估外部依赖性,规避项目风险。
    2020-01-07
收起评论
19
返回
顶部