软件工程中的瀑布模型和敏捷模型

Posted 2020-08-23

 还有两天笔者就要面临一次大型的软件工程项目验收了。这个项目笔者已经管理了两月有余。在管理的过程中，利用课堂中所学习的理论知识和自己实践过程中的摸索，本人逐渐体会到了不同软件管理模型之间的差异，并具备了一定的选择管理方案的能力。

首先，对于绝大多数人来说，刚接手一个新项目的时候都会不自觉的选择“瀑布模型”----我们跟客户交谈后指定需求分析，之后进行简单的设计，之后编写代码，提交，完成。新手会不自觉的选择这种方案，因为它直白，想到哪一步做到哪一步，需要做什么就做什么。但是，这在有些时候是要付出惨重的代价的。比如A拥有一家跑车公司，可以给客户自定义生产跑车。有一天一土豪来到A的公司，跟A商谈了一个跑车项目，他们谈好了车型，材料，马力等等细节。之后，A带着团队做了6个月，做成了这架跑车，交给了土豪。可是土豪开了一天之后回来要求重做，原因是当讨论方案的时候，双方都忘记给跑车安尾灯了！但是给跑车安装尾灯，就要涉及到整个车尾的重新设计，就要把整辆车拆掉再重新组装！

这个模型显然只适合已经成熟了的项目，团队接手项目之后如庖丁解牛般行云流水。当团队接手了创新项目之后，显然已经不再适合用瀑布模型。这时候，就该该使用敏捷模型了。敏捷模型的本质就是优化！第一遍做一个简单版的项目，之后不断迭代优化。就像腾讯的英雄联盟一样，每隔2周就要发布一个新的release，玩家需要安装更新之后才可以继续玩这个游戏。我们就以英雄联盟为例，2016年12月12日版本的英雄联盟是最终版的吗?显然不是。该版本能满足用户全部的需求吗？必然不能。客观的说，这个版本满足了用户当前对于这个游戏的需求。随着时间的推移，用户的需求增多，腾讯就要对英雄联盟进行更新。

敏捷模型的魅力就在于此，每次我们的release只是暂时的满足的用户的需求，让用户的“不满”暂时“平息”。当用户有了新的需求，我们并不需要把项目打倒重来，而是在当前版本增加用户的需求模块。为了完美的做到这一点，我们需要尽可能的在事先建模，把工程模块化，每个模块留有相互交流的接口。当客户对项目有了新的需求，我们就可以在原有的模型上进行优化了。