写点什么

刘华:事实证明,假敏捷都比瀑布优秀

用户头像
刘华Kenneth
关注
发布于: 2020 年 08 月 01 日
刘华:事实证明,假敏捷都比瀑布优秀

 两个项目的直接对比,充分说明即使是假敏捷都比瀑布优秀。





01 假敏捷的“猎狗”



“猎狗”项目始于2019年初,当时公司签了一个大客户,并十分激进地计划在2019年10月份上线。据说,公司和客户签的协议还蛮严苛的,延期交付是要被客户被罚款的。



这个项目的复杂度很高,其业务模式和在我们系统上运行的现有业务也不一样。交付风险非常高。



为了尽快启动开发,项目组临时招聘了大量熟悉该业务的业务人员和开发人员,他们对新业务很熟悉,但对我们的系统和内部业务流程则一无所知。



项目组也决定完全采用敏捷开发的方式进行管理。每五个星期为一个迭代。



之所以迭代周期那么长,是因为核心系统是由第三方开发的,又是一个复杂的单体系统,还要顾及现有业务,开发难度大、风险高。原计划每个迭代预留两周做开发,两周做业务验收测试,一周做回归测试。



公司高层对这个项目非常重视,因为这是我们最重要的客户之一。而且,公司一直在推动敏捷转型,也想把这个项目做成敏捷开发的“模范家庭”,证明如此复杂、依赖第三方开发的项目也可以实现敏捷开发,其他更简单的项目就别再唧唧哇哇地找借口不转型了。



初心是好的,但现实很残酷。这个项目很快陷入了泥潭。



前面提到,由于在项目组中,不管是参与的业务人员还是开发人员,都是新聘的,他们对我们的环境完全不熟悉,需求难以落地,缺乏全局视角,很多坑没有预见。此时不得不临时抽调我们团队的“老司机”去救火,但由于大部分人都在忙其他项目,早期能抽调的人手很有限。



由于每个迭代只有两周的开发时间,第三方觉得时间太紧,并以此为由,只开发、不测试,代码交付给我们时其实是“裸奔”的。而且很多时候实际开发时间要三到四周,压缩了迭代内的测试时间。质量问题严重。



由于每个迭代时间都很紧,项目组寄望能通过自动化测试加速测试进程。但是由于第三方开发的系统对我们来说就是个黑盒子,我们没有代码,只能进行通过UI做黑盒测试。自动化测试难度大,一直没有很好的思路,自动化测试框架的开发停滞不前。



这就导致每个迭代开发的东西都没有进行充分的测试。而且由于整个项目涉及到多个系统,各系统的开发进度也很难同步,集成测试无法在迭代中完成,只能在项目后期进行。



所以,这其实是一个假敏捷的过程,每个迭代只是不断输出不能上线的半成品,集成测试集中在后期,也就是把风险累积在上线前。项目也因此不得不延期了几次。







由于大部分的项目组成员不熟悉我们的环境,不断踩坑,经常把问题上报到项目组高层来解决。项目组高层也经常要四处拉人救火。



最后,这个项目磕磕碰碰,延期了两次后,在2020年6月份上线,上线后虽然有一些问题,总体上还算是顺利上线。



02 瀑布的“热带雨林”



“热带雨林”项目启动于2017年。和“猎狗”相似,也是为了一个大型客户,也和客户签署了类似的惩罚协议。



正因为这是一个对客户有承诺的项目,当时项目组高层认为计划与承诺非常重要,所以,项目整体上是采用瀑布形式来管理的。



由于这个原因,做详细的计划和不断地重新做计划贯穿着项目的整个过程。我有一段时间直接参与该项目某个模块的交付,就被这个计划过程整得死去活来。



瀑布计划通常需要根据当时已知的需求和资源做长期的详细计划,更要命的是,我需要对这份计划画押



当时几十页的需求文档还没有消化完,连需求是否完整还不能确定,系统的详细分析也没有做完,有很多的不确定性,要我做一份精准的计划还要画押,臣妾实在做不到。



而且当时和PM的另一个争论是,一方面我们做交付都不够时间和人手,又要花费大量时间和人力来做计划,到底是交付重要还是计划重要。很显然PM也是要向上交差,他当时关心的真的只有计划。



不是说计划不重要,但是长期、全盘的计划只能用来窥探项目全貌,用作确定预算和资源配置,不能当成承诺,也不能作为执行的唯一依据。



幸好我后来离开了这趟浑水,否则我可能真的要约PM去爬六峰山了。后来听继续参与该项目的小伙伴说,做计划这事在项目过程中没完没了,耗费了大量时间和人力。



早期由于有足够预算,项目组当时就圈了一大群人,但由于需求都还没有谈,而且因为是瀑布模式,需求没有全部确定前,后续的工作也开展不了。因此很多人其实是在空耗着,或者实际在做其他项目的事情。



这种要做几年的项目,人也很难有急迫感,难免有“瞎忙”的情况。而且项目延期了几次,造成严重的超支。



起了个大早,赶了个晚集。“热带雨林”起步比“猎狗”要早得多,现在“猎狗”已经在2020年6月上线了。而“热带雨林”折腾了几年,目前最新的计划是在2021年1月份上线,现在正在跟客户进行联测。



这一测,要命了。



客户在这个时候提出了很多新需求。而现在离计划上线的日子已经不多了。其实我们都知道,这哪是什么新需求,只能说明原来写的很多需求都不成立。由于项目是以瀑布形式来管理的,现在才有机会让客户验证那些需求,丑媳妇见公婆的时间太晚了而已。反馈太慢、太晚恰恰就是瀑布的最大硬伤



虽然“热带雨林”的剧情还在发展中,它能否在2021年1月份顺利上线还是未知数,现在判断它的结局为时尚早,我有被打脸的可能。但目前联测的情况是真不乐观,我当然也不介意被打脸,希望它能顺顺利利。



03 两者对比



从复杂度、性质来说,“猎狗”和“热带雨林”是差不多的,虽然“猎狗”也有超支、延期的情况,但总算在一年半时间内顺利上了线。“热带雨林”在2017年就启动了,现在是否能按最新计划顺利上线还很悬,孰优孰劣,一目了然。



那么对比“猎狗”和“热带雨林”,“猎狗”“优秀”在哪里呢?



究其原因,有以下几点值得一提:



  1. 虽然每个迭代只有输出而不是成果,但这个机制保证了每个迭代进行一次短期计划和复盘,也保证了持续的优先级梳理,虽然开发出来的还是半成品,但总归有实际的进度。

  2. 尽管集成测试不能跟随每个迭代进行,但项目组还是想方设法把集成测试提前。虽然没有避免延期,但还是更早地暴露了问题。

  3. 项目高层一直跟项目组成员强调遇到任何问题都可以直接越级上报,高层也做到了及时响应,组织会议四处拉人救火。尽管这个过程很频繁,令人怨声载道,但从结果上看,确保了及时灭火。



反观“热带雨林”,它有以下问题:



  1. 虽然经常做计划,但这种长期计划需要对项目的细节有完整的理解,太南了;

  2. 所有的需求只有到最后联测才有机会验证,太晚了;

  3. 项目组高层的风格也不一样,虽然口头上也是说有什么问题都可以越级上报,但如果没有充分准备就上报,会被骂得很惨,所以有些时候,项目组成员多一事不如少一事,问题没有得到及时的曝光和解决,压抑了;

  4. 由于缺乏像敏捷这样的定期、频繁的会议机制,缺乏及时的迭代计划、优先级梳理和复盘,对项目的实际进度也很难把握,雾里看花。



04 总结



抛开敏捷、瀑布这些学说,想要项目成功,以下几个因素很重要:



  1. 短周期迭代、频繁的定期仪式确保了持续、及时的计划、进度跟踪和复盘,也能营造紧迫感,避免人浮于事;

  2. 想方设法缩短反馈周期和提早反馈;

  3. 营造宽松、透明的环境,让项目组成员遇到阻碍和问题时,乐于及时沟通与上报。



觉得文章不错,顺手转发给朋友们吧。



分割线 卡通



为什么软件交付要快?因为要有赢的感觉!



刘华:上云还是不上云,这是一个问题



关于作者


刘华(Kenneth)



  • 敏捷、精益、DevOps专家

  • 公众号“敏于思 捷于行”博主

  • 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈

  • 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit等论坛发表主题演讲

  • 著有《猎豹行动:硝烟中的敏捷转型之旅》一书



小说体敏捷/DevOps转型教科书和实战经验分享



购书指南



纸质书、电子书在京东当当亚马逊、微信读书等渠道已全面上架,搜索关键字“猎豹 敏捷”即可找到。点击阅读原文可直接购书。有声书已登录喜马拉雅、微信读书,适合路上听书的你。



发布于: 2020 年 08 月 01 日阅读数: 1584
用户头像

刘华Kenneth

关注

敏捷、精益、DevOps专家 2017.10.19 加入

著有《猎豹行动:硝烟中的敏捷转型之旅》一书及专栏《软件交付那些事儿》;敏捷、精益、DevOps专家;公众号“敏于思 捷于行”博主;曾在国内多个大型论坛发表过主题演讲;就职于世界500强银行。

评论 (3 条评论)

发布
用户头像
假敏捷 VS 假瀑布     你想得出什么结论都是可以的!
2020 年 08 月 04 日 15:40
回复
用户头像
我发现,凡是做得烂的项目,无论如何组织它都会被称作瀑布;凡是做的好的或者差强人意的项目,无论组织得多瀑布,它都会被称作敏捷~
2020 年 08 月 03 日 09:54
回复
严重同意
2020 年 08 月 03 日 11:34
回复
没有更多了
刘华:事实证明,假敏捷都比瀑布优秀