瀑布模型是项目管理中最基本的模型,基本软件工程的同学和软件开发的同学都学过,把软件开发的过程划分为需求分析、设计、开发、测试、部署、运维等几个阶段,是目前在实际工作中使用最广泛的项目管理模型。缺点教科书上写的也很清楚,船大难掉头,执行到后面想要修改前面的部分就很难,或者说成本就很高。

但为什么瀑布模型目前还是用的最广泛呢?因为在实际环境中,大部分的企业或者组织,采用的都是外包形式的软件开发方法,而外包就需要签合同。而瀑布模型从本质上来说,关心的是两个点:明确的目标,可划分职责和边界的过程。这两个点恰恰是组成合同的核心要素。明确开发商需要干什么,在什么时间内完成,彼此的职责边界在哪里。

但是软件开发,即使是再小的项目,在项目开始时就非常的明确。按照瀑布模型,经常是项目做了三分之二,差不多可以试运行了,然后用户一试,这个地方需要改一下,那个地方需要改一下,开发一看就头大,可能数据库要重新设计,可能业务流程要重新改,属性的定义也要改,而用户往往一句话,就改这么一小点,没多少工作量吧。只有按照用户需求改,改完了,用户还觉得和自己想要的不是同样的东西。而且,还存在用户本身也错了的情况,用户设想的是A,结果跑下来市场需求是B,那么最后只有开发去改系统。改来改去,最后系统架构可能就一团乱麻了。

需求是随着项目的推进而渐进明晰的,这是软件开发项目的特点,过去我们考虑的是要么在项目开始时做大量的可研、市场调查等等一大堆工作,尽量在项目开始前就把需求定义的非常清楚。可惜,市场是在不断变化的,人的想法也可能睡个觉醒来就变了,这种方法无异于刻舟求剑,用这种方法做出来的系统,可能从上线开始就在规划第二期,也就是把过程中需要修改的部分,拿出来重新做一遍。

苦逼的乙方,则考虑的更多是怎么快速灵活的响应甲方的需求。为此过去我们IT人做了很多的努力,包括微服务、中台、接口技术等等,把架构变的更灵活,能在用户改需求的时候,快速响应用户的变化,降低修改的成本。但再小的变更也有工作量,而且往往工作量投入了,项目延期了,用户还是不满意。再者,由于为了响应变化,架构的复杂度越来越高,导致开发和维护的工作量就越来越大,可能一个小项目,最后做出一个复杂的架构出来,用专业术语来说,就是过度设计。

为了解决这个问题,我们需要从本质上改变软件开发项目的管理方法,这就是敏捷方法。具体的敏捷方法和实践在这里都不细说,网上已经有很多资料可以学习了,在这里只想探讨一下,敏捷方法和瀑布模型的本质区别在哪儿。

刚才我们提到过,瀑布模型的特点是明确的目标,明确的过程,如果顺利走下去,就是明确的结果。其实是传统的工业流水线的思维模型,每个环节大家各自负责做什么,如果出了问题,可以明确定位到责任人,做出来的产品一定是和预计分毫无差的,至于这个产品是不是市场需要的?这是项目立项前就应该想好的,和项目过程管理关系不大。

而敏捷方法,则是以产品为核心,既然大家一开始都只有个模糊的方向,那就先做个原型出来试试水,实际跑一下,看看哪里还需要完善,哪里需要修改,流程怎么设置,甚至可以看看市场的反馈,有可能第一版的原型很多理解是有偏差的,那需要根据市场反馈进行调整。因此敏捷方法,核心强调的就是快速的多次迭代,在一个一个的版本迭代中,不断对系统进行完善,从心理学的方面来说,由于用户不断的看到新的功能上线,也会不断提高用户对系统的满意度,甚至能够激发用户的畅想,提出比最初设计更好的功能需求,整个开发团队和用户团队就能真正形成一个整体,以产品为核心推动产品不断优化。

但是在传统的企业里面,绕不开的合同、没有自研团队、合作方选定需要招投标等等的问题怎么解决呢?每个企业有自己的特点,这个方法不好一概而论,但可以有很多变通的方法能够解决,在此就不做过多描述了,如果有此方面困惑的同学,可以私下交流。