团队软件研发项目需求变更的管理过程.docVIP

团队软件研发项目需求变更的管理过程　　需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。 　　需求变更的出现主要是因为在项目的需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清晰，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改动他们的工作方式;或要研发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。随着研发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色，或对以前提出的需求进行改动。他们了解得越多，新的需求也就越多，需求变更因此不可避免地一次又一次出现。 　　团队包括一般软体公司状况是： 　　需求：定义模糊，我们一般是以客户为导向，参差不齐的客户，所以，很多团队对需求变化的适应力差。 　　架构：几乎一半的团队没哟架构师。我原来的公司没有。现在的公司有，但是，我还没有感觉到他的价值，感觉更像是需求分析师。 　　测试：这个就不说了。。。 　　评审：不知道大家对这个怎么理解，我觉得应该是很重要的，时发现、纠正问题的一个环节。 　　过程：在CMMI中，虽然只占30%，但是，我觉得很重要，开发文档、注解、单元测试、项目进度跟踪。 　　客户：这一块不熟，因为我一直面对公司内部客户，所以比较好搞定。 　　在三者中， 　　CMMI是标准，他描述，量化了团队的成熟度，和不足的地方，但是没有告诉你怎么改进; 　　SPI是对目标的检测和过程的优化。 　　AP是过程，包括XP，RUP等等。 　　我们来看看Xp,应该是很多程序员喜欢的，但是，有多少团队导入了XP开发。 　　XP：开发周期采用动态迭代式。 　　关键做法有：1.现场客户;2.计划博弈;3.系统隐喻;4.简化设计;5，集体拥有代码;6.结对编程;7.测试驱动;8.小型发布;9.重构;10.持续集成;11.每周40小时工作制;12.代码规范 　　计划博弈: 　　XP要求结合业务和技术情况，快速确定下一次发布的范围。在项目计划的4要素(费用、时间、质量和范围)中，由客户选择3个，而程序员可以选择剩下的1个。 　　通常客户从业务角度确定项目范围、需求优先级和开发进度，开发人员则做出具体的成本和技术估计。 　　XP强调简短和突发性的计划，有时只用几个小时甚至几分钟就能完成，而且可以随时按需进行多次计划。 　　系统隐喻: 　　XP通过一个简单的关于整个系统如何运作的隐喻性描述(story)来指导全部开发。 　　隐喻可以看作是一种高层次的系统构想，通常包含了一些可以参照和比较的类和模式，它还给出了后续开发所使用的命名规则。 　　XP不需要事先进行详细地架构设计。 　　重构：重构是指在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能。 　　测试驱动：先写测试，后编码 　　结对编程： 　　由两名程序员在同一台电脑上结成对子共同编写解决同一问题的代码。 　　通常一个人写代码，另一个人同时负责保证代码的正确性和可读性，比如编写单元测试程序、进行代码走查。 　　PP可以看作是一种非正式的持续进行的同行评审(peer review)。 　　哎呀，看到这些，我就有点感慨了，是不是这些东西太理论化了，和实际情况相差太多了。 　　实际情况，项目来了，马上开需求会，分任务，然后需求评审，然后系统设计，数据建模，系统框架，开发，测试，小版本出来。。。。。一系列。最起码，根本不可能一周40工作小时。 　　实施需求变更管理需要遵循如下原则： 　　1.建立需求基线。需求基线是需求变更的依据。在研发过程中，需求确定并经过评审后(用户参和评审)，能建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。 　　2.制订简单、有效的变更控制流程，并形成文件。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目研发和其他项目都有借鉴作用。 　　3.成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员一起组成，应该包括用户方和研发方的决策人员在内。 　　4.需求变更一定要先申请然后再评估，最后经过和变更大小相当级别的评审确认。 　　5.需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。 　　6.妥善保存变更产生的相关文件。 　　应对之道 　　需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。变更控制流程如