需求变更管理与敏捷开发

转自：http://blog.csdn.net/violet200211/article/details/8612189

需求变更管理

        需求变更是要经过申请、审批、执行、确认等流程。

        为什么要做需求变更的管理？主要原因有两个:

1. 防止范围蔓延引起的进度、成本、质量上，甚至严重时导致项目全面失败的问题；

2. 为以后留下筹码，以后要求追加费用也好，或者让客户看到我们送给他们的人情也好，总之是为了使以后与客户相关的工作更顺畅。除了这两个原因之外，当然还有一些不是特别重要的原因，比如使需求、设计、开发、测试之间对变更的理解等等。

        需求变更管理的流程

1. 就是与客户一起，约定变更管理的流程. 最好在合同中约定，至少也要在启动会上约定

2. 提出变更申请. 而变更申请的提出，也应该按照约定的流程通过由负责人提交给项目经理.

3. 项目经理收到需求变更申请，先了解前因后果和客户的目标，然后优先从系统外解决，如果不行的话再进行变更工作量的评估和影响的分析，进行审批

4. 审评过程中销售人员起到很重要的作用，因为销售要给出变更所需费用的来源，并要给出承诺，否则变更没办法继续。

5. 其他审批人则根据自己的角色和职责进行审批即可。

6. 审批结束，进入执行环节，对绝大多数的变更，都可以不用马上执行变更动作，可以几个变更作为一批一起执行，一方面可以降低频繁变更对项目工作的影响，另一方面对一些客户一时兴起变过来过不久又变回去的变更可以起到拦截作用。

7. 采用敏捷的开发方式进行开发，所以将需求纳入产品Backlog,然后分成Sprint Backlog,最后是Backlog Item。

敏捷可以提供最佳的实践做法,比如测试驱动开发(TDD[编写的case当前不能通过，实现后通过])、特征驱动开发(FDD),结对编程(Paring Coding)或者快速Review 粒子任务等,并且提供给软件开发组织各种敏捷的开发和管理框架,其中应用最为广泛的是SCRUM。敏捷也需要概要设计，要设计出各模块的功能与接口;

有几点是在制定产品Backlog中要明确的:

第一,产品Backlog　SCRUM实施过程允许随着项目进展而进行变更,或者增加,或者修改,或者删减其中的一些特征;

第二,产品Backlog的制定需要客户参与,并且由客户做出选择;

第三,产品Back-log有一个拥有者;

产品Backlog的优先排序原则将取决于特征的价值,也就是说,如果不是现在就实现这个功能,会存在哪些风险,或者要丢失什么样市场机遇,应该根据价值原则做出决定;

需要对产品Backlog的各特征项进行大小和复杂程度进行估计；

8.再之后是确认，需求变更之后的原型，需要在修改完之后就确认，而最终变更结果，则在系统验收时，统一确认。