需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。
需求变更的出现主要是因为在项目的需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清晰，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改动他们的工作方式;或要研发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。随着研发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色，或对以前提出的需求进行改动。他们了解得越多，新的需求也就越多，需求变更因此不可避免地一次又一次出现。
团队包括一般软体公司状况是：
需求：定义模糊，我们一般是以客户为导向，参差不齐的客户，所以，很多团队对需求变化的适应力差。
架构：几乎一半的团队没哟架构师。我原来的公司没有。现在的公司有，但是，我还没有感觉到他的价值，感觉更像是需求分析师。
测试：这个就不说了。。。
评审：不知道大家对这个怎么理解，我觉得应该是很重要的，时发现、纠正问题的一个环节。
过程：在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)。
哎呀，看到这些，我就有点感慨了，是不是这些东西太理论化了，和实际情况相差太多了。
实际情况，项目来了，马上开需求会，分任务，然后需求评审，然后系统设计，数据建模，系统框架，