博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
软件工程中的瀑布模型和敏捷模型
阅读量:6093 次
发布时间:2019-06-20

本文共 942 字,大约阅读时间需要 3 分钟。

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

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

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

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

 

转载于:https://www.cnblogs.com/DeerTrodis/p/6165960.html

你可能感兴趣的文章
BZOJ 2190[SDOI2008]仪仗队
查看>>
图解SSH原理及两种登录方法
查看>>
[转载] 七龙珠第一部——第058话 魔境圣地
查看>>
【总结整理】JQuery基础学习---样式篇
查看>>
查询个人站点的文章、分类和标签查询
查看>>
基础知识:数字、字符串、列表 的类型及内置方法
查看>>
JSP的隐式对象
查看>>
P127、面试题20:顺时针打印矩阵
查看>>
JS图片跟着鼠标跑效果
查看>>
[SCOI2005][BZOJ 1084]最大子矩阵
查看>>
学习笔记之Data Visualization
查看>>
Leetcode 3. Longest Substring Without Repeating Characters
查看>>
USB2.0学习笔记连载(十八):keil实现寄存器的配置及相关函数讲解(二)
查看>>
SqlServer表名称定义
查看>>
jquery操作select(取值,设置选中)
查看>>
浅谈无线h5开发
查看>>
关于裸婚,没事F5刷豆瓣是不够的!
查看>>
【FJOI2015】金币换位问题
查看>>
HighChar
查看>>
window上安装pymysql
查看>>