软件工程中的瀑布模型和敏捷模型
还有两天笔者就要面临一次大型的软件工程项目验收了。这个项目笔者已经管理了两月有余。在管理的过程中,利用课堂中所学习的理论知识和自己实践过程中的摸索,本人逐渐体会到了不同软件管理模型之间的差异,并具备了一定的选择管理方案的能力。
首先,对于绝大多数人来说,刚接手一个新项目的时候都会不自觉的选择“瀑布模型”----我们跟客户交谈后指定需求分析,之后进行简单的设计,之后编写代码,提交,完成。新手会不自觉的选择这种方案,因为它直白,想到哪一步做到哪一步,需要做什么就做什么。但是,这在有些时候是要付出惨重的代价的。比如A拥有一家跑车公司,可以给客户自定义生产跑车。有一天一土豪来到A的公司,跟A商谈了一个跑车项目,他们谈好了车型,材料,马力等等细节。之后,A带着团队做了6个月,做成了这架跑车,交给了土豪。可是土豪开了一天之后回来要求重做,原因是当讨论方案的时候,双方都忘记给跑车安尾灯了!但是给跑车安装尾灯,就要涉及到整个车尾的重新设计,就要把整辆车拆掉再重新组装!
这个模型显然只适合已经成熟了的项目,团队接手项目之后如庖丁解牛般行云流水。当团队接手了创新项目之后,显然已经不再适合用瀑布模型。这时候,就该该使用敏捷模型了。敏捷模型的本质就是优化!第一遍做一个简单版的项目,之后不断迭代优化。就像腾讯的英雄联盟一样,每隔2周就要发布一个新的release,玩家需要安装更新之后才可以继续玩这个游戏。我们就以英雄联盟为例,2016年12月12日版本的英雄联盟是最终版的吗?显然不是。该版本能满足用户全部的需求吗?必然不能。客观的说,这个版本满足了用户当前对于这个游戏的需求。随着时间的推移,用户的需求增多,腾讯就要对英雄联盟进行更新。
敏捷模型的魅力就在于此,每次我们的release只是暂时的满足的用户的需求,让用户的“不满”暂时“平息”。当用户有了新的需求,我们并不需要把项目打倒重来,而是在当前版本增加用户的需求模块。为了完美的做到这一点,我们需要尽可能的在事先建模,把工程模块化,每个模块留有相互交流的接口。当客户对项目有了新的需求,我们就可以在原有的模型上进行优化了。
posted on 2016-12-12 20:57 DeerTrodis 阅读(1934) 评论(1) 编辑 收藏 举报