需求变更的代价.doc
需求变更的代价 让我们先来看一个需求变更的典型案例: Steven 刚出任项目经理,并承接了一个中型软件项目。公司再三叮咛他一定要尊重客户,充分满足客户需求。项目开始比较顺利,但进入到后期,客户频繁的需求变更带来很多额外工作。Steven 动员大家加班,保持了项目的正常进度,客户相当满意。 但需求变更却越来越多。为了节省时间,客户的业务人员不再向 Steven 申请变更,而是直接找程序员商量。程序员疲于应付,往往直接改程序而不做任何记录,很多相关文档也忘记修改。很快 Steven 就发现:需求、设计和代码无法保持一致,甚至 没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱,很多人违反配置管理规定,直接在测试环境中修改和编译程序。但在进度压力下,他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题,客户已经明确表示“失去了耐心”。 而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块,造成系统运行异常缓慢,大量应用程序超时退出。虽然最终花费了整整 3 天的时间解决了这个问题,但客户却投诉了,表示“无法容忍这种低下的项目管理水平”。更糟糕的是,因为担心系统中还隐含着其他类似的错误,客户高层对项目的质 量也疑虑重重。 随后发生的事情让 Steven 更加为难:客户的两个负责人对界面风格的看法不一致,并为此发生了激烈争执。Steven 知道如果发表意见可能会得罪其中一方,于是保持了沉默。最终客户决定调整所有界面, Steven 只好立刻动员大家抓紧时间修改。可后来当听说因修改界面而造成了项目一周的延误后,客户方原来发生争执的两人这次却非常一致,同时气愤地质问 Steven:“为什么你不早点告诉我们要延期!早知这样才不会让你改呢!” Steven 很无耐,疑惑自己到底错在哪里了。 对软件需求和需求变更的理解 软件需 求是整个软件项目的最关键的一个输入,和传统的生产企业相比较,软件的需求具有模糊性、不确定性、变化性和主观性的特点,它不像生产汽车、电脑等硬件的需求,是有形的、客观的、可描述的、可检测的。软件需求是软件项目最难把握的问题,同时又是关系项目成败的关键因素,因此对于需求分析和需求变更的处理十分重要。 需求变更会给项目带来巨大的风险 ,会导致项目的成本费用增加、开发周期延长、产品质量下降及团队工作效率下降等不良后果,因而软件开发项目中应该