谈软件开发项目管理之需求变更(转)

标签: 软件开发 项目管理 需求 | 发表时间:2013-08-25 14:15 | 作者:suixufeng
出处:http://blog.csdn.net

在软件开发过程中需求的变更会给开发带来不确定性,但只要把需求变更作为重点、难点小心加以控制,软件开发的进度、成本和质量也就有了"安全"的基础。变化并不是人们最害怕的,最怕的是跟不上变化的步伐。

1、需求变更管理的需求

需求变更是因为需求发生变化。根据软件工程思想,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减,均属于需求变更。需求变更的出现主要是因为在项目的需求确定阶段,用户往往不能确切地定义自己需要什么。用户常常以为自己清楚,但实际上他们提出的需求只是依据当前的工作所需,而采用的新设备、新技术通常会改变他们的工作方式;或者要开发的系统对用户来说也是个未知数,他们以前没有过相关的使用经验。

随着开发工作的不断进展,系统开始展现功能的雏形,用户对系统的了解也逐步深入。于是,他们可能会想到各种新的功能和特色,或对以前提出的要求进行改动。他们了解得越多,新的要求也就越多,需求变更因此不可避免地一次又一次出现。这时,如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效,抑或不按变更控制流程来管理需求变更,那么很可能造成项目进度拖延、成本不足、人力紧缺,甚至导致整个项目失败。当然,即使按照需求变更控制流程进行管理,由于受进度、成本等因素的制约,软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响,这也正是我们进行需求变更管理的目的所在。

2、六大原则

实施需求变更管理需要遵循如下原则:

1)建立需求基线。需求基线是需求变更的依据。在开发过程中,需求确定并经过评审后(用户参与评审),可以建立第一个需求基线。此后每次变更并经过评审后,都要重新确定新的需求基线。

2)制订简单、有效的变更控制流程,并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时,这个流程具有一定的普遍性,对以后的项目开发和其他项目都有借鉴作用。

3)成立项目变更控制委员会(CCB)或相关职能的类似组织,负责裁定接受哪些变更。CCB 由项目所涉及的多方人员共同组成,应该包括用户方和开发方的决策人员在内。

4)需求变更一定要先申请然后再评估,最后经过与变更大小相当级别的评审确认。

5)需求变更后,受影响的软件计划、产品、活动都要进行相应的变更,以保持和更新的需求一致。

6)妥善保存变更产生的相关文档。

3、应对之道

需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受,还要增加实施变更和验证两个步骤,有时还会有取消变更的步骤。

变更控制流程如图所示。针对变更控制流程,笔者在实际工作中总结出了软件开发人员在需求变更管理实践中的几点对策:

1)相互协作

很难想像遭到用户抵制的项目能够成功。在讨论需求时,开发人员与用户应该尽量采取相互理解、相互协作的态度,对能解决的问题尽量解决。即使用户提出了在开发人员看来"过分"的要求,也应该仔细分析原因,积极提出可行的替代方案。

2)充分交流

需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想,并加以分析和整理。同时,软件开发人员应该向用户说明,进入设计阶段以后,再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。

3)安排专职人员负责需求变更管理

有时开发任务较重,开发人员容易陷入开发工作中而忽略了与用户的随时沟通,因此需要一名专职的需求变更管理人员负责与用户及时交流。

4)合同约束

需求变更给软件开发带来的影响有目共睹,所以在与用户签订合同时,可以增加一些相关条款,如限定用户提出需求变更的时间,规定何种情况的变更可以接受、拒绝接受或部分接受,还可以规定发生需求变更时必须执行变更控制流程。

5)区别对待

随着开发进展,有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。遇到这种情况,开发人员可以向用户说明,项目的启动是以最初的基本需求作为开发前提的,如果大量增加新的需求(虽然用户认为是细化需求,但实际上是增加了工作量的新需求),会使项目不能按时完成。如果用户坚持实施新需求,可以建议用户将新需求按重要和紧迫程度划分档次,作为需求变更评估的一项依据。同时,还要注意控制新需求提出的频率。

6)适当的开发模型

采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型,再与用户沟通。一般用户看到一些实际的东西后,对需求会有更为详细的解释,开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后,系统原型逐渐向最终的用户需求靠拢,从根本上减少需求变更的出现。

目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。

7)参与需求评审

作为需求的提出者,用户理所当然是最具权威的发言人之一。实际上,在需求评审过程中,用户往往能提出许多有价值的意见。同时,这也是由用户对需求进行最后确认的机会,可以有效减少需求变更的发生。

 

补充:多次迭代验收。一方面可以控制风险,另一方面保证需求变更在一个可控范围内。。

作者:suixufeng 发表于2013-8-25 14:15:57 原文链接
阅读:98 评论:0 查看评论

相关 [软件开发 项目管理 需求] 推荐:

谈软件开发项目管理之需求变更(转)

- - CSDN博客研发管理推荐文章
在软件开发过程中需求的变更会给开发带来不确定性,但只要把需求变更作为重点、难点小心加以控制,软件开发的进度、成本和质量也就有了"安全"的基础. 变化并不是人们最害怕的,最怕的是跟不上变化的步伐. 需求变更是因为需求发生变化. 根据软件工程思想,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减,均属于需求变更.

项目管理入门PPT

- - 堇| 网络 产品 读书 睡觉
无意看到一个项目管理的PPT,虽然标题是《轻松项目管理之电信项目管理实务》,所写内容在互联网行业也颇为适用. 地址: http://doc.mbalib.com/view/05ee6199c3b3885c59e878a5cbd8cd53.html.

项目管理ppt下载

- - 人月神话的BLOG
项目管理培训的ppt前年做了部分,一直没有做完,今年准备花些时间全部做完,并全部共享出来. 最近做完的主要是项目成本管理和项目质量管理. 成本管理: http://vdisk.weibo.com/s/dyHc0/1348535220. 成本管理涉及到比较多的财务的内容,包括财务上的预算管理,成本核算,概预核决,资金管理.

Excel项目管理工具

- - CSDN博客研发管理推荐文章
版权所有,转载请注明出处: http://guangboo.org/2013/10/27/excel-project-management. Excel强大的表格功能在项目管理中同样具有大用处,作者通过在实践中实际运用Excel进行项目管理的经验,简单介绍Excel在项目管理中的应用. 本文主要介绍Excel如何做项目计划和项目进度跟踪,项目计划和项目跟踪是项目周期中最重要的环节,无论是几个月的小项目,还是几年的大项目,计划和进度始终是保证项目正常推进、按时交付的重要手段.

项目管理总结

- - 研发管理 - ITeye博客
【一】开发环境和测试环境部署和配置:具体包括JDK、TOMCAT、Eclipse、SVN、ANT   、Maven,以及缺陷库环境的搭建,以及用户权限的分配. 【三】数据库服务器环境的部署、搭建、并根据项目需求情况,建立相应的表空间、用户对象、并制定数据库备份计划. 【四】 SVN环境的部署及配置,并建立版本库和对应的项目目录结构、常用知识库目录结构等.

未来项目管理发展趋势

- tiod - cnBeta.COM
根据ESI国际项目管理培训公司的分析,项目管理作为一门学科越来越被接受. 公司项目管理将起到关键作用,无论是开发新的产品和服务,或确保日常的日常工 作顺利进行. 项目经理可以组织本地或远程团队,在许多情况下还是虚拟团队,不同的群体的人为一个项目一起工作. 对于组织,人才和项目经理是一个有效的竞争 优势,根据ESI执行副总裁J LeRoy的 分析,这种情形在2011年仍将继续.

IT项目管理工具总结

- 腾 - 博客园-首页原创精华区
阅读: 3434 评论: 16 作者: Lynn. 发表于 2010-06-02 10:27 原文链接.          俗话说"工欲善其事必先利其器",在一个项目开发流程中,如果搭配一个比较完善的项目管理工具,必将取得事半功倍的效果. 本文搜集了目前项目管理界比较有规模的管理工具,给予了简单介绍,同时为了发扬免费开源的精神,重点总结了免费开源工具Dotproject 和Redmine.

一份项目管理提纲

- 黎明 - 最新文章 - UCD大社区
这是一份工作笔记,我的做项目管理的方法,相信大多数有经验的项目/产品经理对此必定了如指掌,或者有更优秀的经验. 提案过程是公司内部的一次自我营销,方案好坏、沟通高低决定公司对项目能投入多少资源. 提出解决方案——PPT提纲.ppt. 撰写产品需求文档PRD.doc、制作页面原型.rp. 以PPT提纲和页面原型进行共享、论证、评估.

互联网项目管理要点

- - 月光博客
  互联网项目,会定一个计划发布日期,然而这个项目有个隐藏的实际合理发布日期. 因为软件开发并不是一个直接添加资源就可以加快速度的过程,所以这个实际合理发布日期是在现实资源合理利用前提下一个客观存在的最可能早的完成时间. 项目进展的过程,其实也是发现这个隐藏的合理发布日期的过程.   从管理的角度来讲,当然是尽可能的赶上计划的发布时间,或者尽可能快的完成项目.

再谈敏捷项目管理

- - 人月神话的BLOG
前面谈敏捷开发和敏捷项目管理的文章已经很多了,由于最近在整理敏捷项目管理的培训材料,在整理材料的过程中又思考了一些离散点,特做记录. 在敏捷里面我们一直在强调团队的动态自适应和调整能力,要知道一个高成熟度的敏捷团队一定是一个能够高度高效率的进行自适应,自学习和自我调节的团队. 那么传统的层级结构一定是不适合的,包括原来传统的按阶段划分的流水线式生命周期结构,取而代之的是多个小团队之间的网状结构,在这种结构下能够通过高效的消息传递快速的发送消息,接受反馈,并进行自我调整维持在一个动态平衡的状态.