如何处理软件项目中发生的需求变化

中国人跟老外的思路是不同的，完全照搬国外的方法，体系困难重重。正如楼上所说，东西咱都知道，但是具体的问题却无法克服。国外的软件理论与管理方法，是多年演变出来的，长时间内形成了很多解决具体问题的方法跟经验，但所有这些经验都是与当时的实际状况相关的。而管理理论一般只是抽象，综合后的结果：告诉你要做什么东西，但无法告诉你怎么做到这些。

所以想仅仅靠规定，架构等方法解决所有问题，是远远不够的。要使用国外的方法，观念上就得跟老外一致。

中国的软件行业总体来说还是很浮躁的。没办法，大趋势如此。毕竟很多公司还在生死线上挣扎。试问在这种情况下，又有多少人会去做项目各项参数的积累与分析呢？

因此，在这种状态下，需求的变化是无法避免的，因为在项目前期无法对项目的任何状况做出正确的判断--包括客户的“无知”，这本身就应该在风险计划中。

这点我不赞同，老外的管理是非常细化、科学的，是告诉你做什么，怎么做。就像CMMI，外资企业和国内企业，完全是两回事。外资企业里怎么去做需求、设计、编码、估算、测试，一套一套的方案、部门、职能全部齐全，而国内只知道“出个文档”，并且，还只有程序员这个角色。

在做项目计划的时候，应该明确项目范围，确定边界，范围内的事要做也必须做，范围外的事坚决不做。这是原则。
如何确定范围需要方法和技巧，对项目背景理解，产品了解，用户需求分析...这些是技能和方法。
当用户提出这样或者那样需求的时候，要根据确定的范围进行管理和控制，这是执行力。

原则+方法+执行力=需求管理

原则和方法可以通过学习和实践获得，而执行力更多依赖于管理者的个性、能力，包括职权。

在需求管理上面，实战经验没有多大意义，在他那边行得通在你这边却行不通，就是因为项目环境和人之间的差异。因此只有一些原则方法来作为指导，具体管理仍要看管理者自己。

由于软件的“软”特质， 用户对需求的认识是逐步明朗化，因此应对需求变化需要软件系统具备一定的弹性和适应性，这一方面来源于软件的架构和设计，一方面取决于开发方法的采纳，比如用敏捷方法开发软件在应对变化上必然强于过程开发。

我觉得应该是设计时的可扩展性，不知道可否理解为敏捷式开发.

你说的很不错，我再补充一点，其实敏捷管理只是方法论，它就是告诉你怎么做到这些。要做什么东西是CMMI的事情。还有像RUP，PMP，6西格玛什么的都是和敏捷一样是告诉PM怎么做到CMMI中定义的那些标准。

敏捷是方法论？明显你还不懂敏捷。
做什么是CMMI的事？观点尤其很搞笑。
最后CMMI对RUP,PMP,6C都包圆了？ 糊涂阿糊涂，淅沥糊涂

我不是很有时间和你说这件事情。我也不知道你的观点从何而来。
请你多阅读几本07-09年出版的敏捷管理书籍再来和我说这件事情。当然目前这些书籍都没有简体中文版。你的消息闭塞我是可以理解的。

你原来还挂着片树叶的，但这么一说就把这片可怜的黄叶也被风吹走了
管理学被你用中英文衡量简直是在亵渎管理二字