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

敏捷开发| 2020-08-13

图0：事实证明，假敏捷都比瀑布优秀

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

01 假敏捷的“猎狗”

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

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

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

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

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

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

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

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

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

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

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

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

图2：事实证明，假敏捷都比瀑布优秀

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

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

02 瀑布的“热带雨林”

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

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

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

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

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

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

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

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

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

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

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

这一测，要命了。

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

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

03 两者对比

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

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

究其原因，有以下几点值得一提：

虽然每个迭代只有输出而不是成果，但这个机制保证了每个迭代进行一次短期计划和复盘，也保证了持续的优先级梳理，虽然开发出来的还是半成品，但总归有实际的进度。
尽管集成测试不能跟随每个迭代进行，但项目组还是想方设法把集成测试提前。虽然没有避免延期，但还是更早地暴露了问题。
项目高层一直跟项目组成员强调遇到任何问题都可以直接越级上报，高层也做到了及时响应，组织会议四处拉人救火。尽管这个过程很频繁，令人怨声载道，但从结果上看，确保了及时灭火。

反观“热带雨林”，它有以下问题：

虽然经常做计划，但这种长期计划需要对项目的细节有完整的理解，太南了；
所有的需求只有到最后联测才有机会验证，太晚了；
项目组高层的风格也不一样，虽然口头上也是说有什么问题都可以越级上报，但如果没有充分准备就上报，会被骂得很惨，所以有些时候，项目组成员多一事不如少一事，问题没有得到及时的曝光和解决，压抑了；
由于缺乏像敏捷这样的定期、频繁的会议机制，缺乏及时的迭代计划、优先级梳理和复盘，对项目的实际进度也很难把握，雾里看花。