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

图0:事实证明,假敏捷都比瀑布优秀

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

01 假敏捷的“猎狗”

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

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

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

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

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

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

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

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

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

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

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

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

图2:事实证明,假敏捷都比瀑布优秀

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

最后,这个项目磕磕碰碰,延期了两次后,在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等论坛发表主题演讲
  • 著有《猎豹行动:硝烟中的敏捷转型之旅》一书
余下全文(1/3)
分享这篇文章:

请关注我们:

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注