需求冻结问题 - 软件工程/管理 / 开发过程版
本人初学者，最近一直在研究CMMI :(
看到敏捷开发的模式感到非常感兴趣，尤其是“需求变更”的部分
问题在于，在敏捷开发中还有没有“需求冻结”的必要？或者用其他什么形式来代替？
非常期待高手的答复，谢谢~！
[解决办法]
敏捷开发时，并不做“不必要的事情”，不像简单的瀑布开发所说的要把需求全都列出来才开发，相反地，敏捷开发只是“小步快跑”。
一方面，真正的敏捷开发是把需求作为比较细节化的可测试代码，而不是纯粹文字（或者说文档）上的空谈，而是测试代码。如果敏捷开发被看作勤开会、勤作汇报，就成了假的敏捷开发了。所以敏捷开发从XP为其原型，那些没有掌握XP技术的人可以把一些过程模糊化为一些口头理论要求（例如你不懂得全面进行自动化测试的技术那么你可以手工测试、购买一些工具、开发一些工具相结合地来办自动化地测试），但是如果模糊的越多越是口头上的敏捷了。
另一方面，他要求你快跑，如果一个人1天做不完一个小任务，10个人2、3周都不能提交一组很有意义的新增特性，就有问题了。项目开始时只可能有原则性的需求，而不可能有具体的需求设计，否则就不是快跑而是冬眠了（多数人等着少数人做过细的设计，这些设计细节的80%往往在后边的快跑过程中被证明是垃圾）。
[解决办法]
冻结需求，如论CMM还是敏捷都是必要的，关键要衡量冻结的时间点。
一定时期范围内的需求冻结，有助于避免项目组内部开发和测试受到外界过多的干扰。项目经理有责任识别出何时冻结需求，何时解冻。
传统CMM受到诟病最多的就是固定在系统设计或者SRS设计完毕候，基本将大块的需求冻结，用一种较为生硬的方式保证开发可以顺利进行；
敏捷的改进主要在于，没有大块的需求，基本上都有分解为细粒度的story，并且在最长一个月的迭代周期内交付，这就给下次迭代的时候，需求变更留有了机会和余地。否则就像CMM一样，大块大块的需求统一集中设计，当用户想明白自己想要什么的时候，已经来不及变化需求了。
因此，无论是否敏捷，需求冻结都是必要的，但是敏捷有更多的机会在后面的迭代中接纳这部分变化（注意，变化不一定增加工作量）。
[解决办法]
一个project不可能无限期的持续下去，主要范围和目标达到了就该停止接纳新需求。
管理需求最难的不是项目组内部，而来源于项目组外部，每个需求提出者出于个人目的都会夸大本身需求的重要性。
瀑布是一次接纳所有需求（含变更）并试图一次性完美的交付，可能组织上要求需求按优先级排序，但这个排序仅仅是排序，需求要全部实现；
迭代可逐步完善逐步交付，在项目过程中需求管理活动相对来讲更多些，需求优先级是实际生效的，冻结可针对当次迭代或阶段发布版本，整个项目根据情况会适当少实现一些无价值需求。
