瀑布型开发与敏捷开发引起的思考

传统的软件开发模式主要被称为"瀑布法"或者是V model。核心就是自动化生产线的思路。业务用户首先要提出明确、无歧义、有时效性的业务需求，系统分析人员根据业务需求设计系统功能组件和系统整合策略，细化成为软件架构设计、系统整合方案并进行分模块开发。模块开发完毕后从单元测试、集成测试、系统测试直到用户接受度测试一级级往上扩展。

传统的软件系统开发方式路线清晰，管控容易，但最大的前提就是需要业务需求清晰稳定。一旦需求发生变更，尤其是核心需求和关键功能流程的调整，往往会给开发和架构带来灾难性的影响。就好像根据确定车型的生产流水线已经搭建起来了，产品经理说，麻烦把车加长10厘米。生产总监一定会两手一摊说，给我三个月改造生产线吧。一般情况下，程序员对产品经理动了杀心就是在传统软件开发方式+重大需求变更时发生的。

另外，传统的系统开发路线的确清晰，但从设计到开发再到上线往往要经过漫长的等待。最要命的是，在等待期间需求不能随意修改，术语叫做"需求冻结"或者是"需求窗口关闭"（当然需要懂技术的售前进行正确引导客户）。但是在互联网世界里客户的要求是不可能被冻结的，所以传统的软件开发方式玩互联网行不通。

为了在瞬息万变的互联网行业里活命，一些脑子机灵对软件开发熟悉的产品经理捣鼓出了和传统软件开发流程完全不同的开发方式-敏捷开发(Agile Development)。

敏捷开发嘛，顾名思义，最大的特点就是快。那它是怎么实现快速开发的呢？核心思想就是快速迭代，不断优化，永远在改进，永远在发布新版的路上。

从图中我们可以看到，敏捷开发的起点往往是并不非常清晰的业务需求（但框架不是乱变，这跟盲人摸象还是有本质区别的）。但随着开发的进行和原型开发过程中与业务用户的交互，核心的功能点逐渐清晰并形成测试用例。在完成最基本的核心功能后，系统就可以内部上线并供业务人员使用，让业务人员试用"第一批的新鲜产品"。

业务人员在试用后认为基本达到业务目的，就可以小范围开闸交给友好用户使用。如果业务人员认为不够成熟，那就会返工重新修改调整。我们看到的互联网app经常是1-2周就有一个新版本发布，往往就是采用这种"短平快"周期的敏捷开发模式，术语一般称为"持续交付"。

所以有人形象地做了个比喻：从河岸这一侧的A点到河岸那一侧的B点，传统开发就是设计桥梁，建造桥墩，铺设桥板，按部就班；敏捷开发就是先用弓箭射一根线到对岸，然后线带细绳，细绳带粗绳，粗绳带钢缆，逐步把通行能力从蚂蚁、老鼠，猫最后提升到人甚至汽车。

但无论是瀑布型开发还是敏捷开发，变中不变的都是系统可伸缩框架定义+模块化设计，无论对于哪种模式下的快速迭代开发以及测试效率都有不可替代的作用。跳出现有局限的设计模式，用更上层的思路来解决问题，做到脱胎于设计模式又不拘泥于设计模式，也许是软件架构师最好的归宿。