瀑布模式
每一步都是建立在上一步的基础：因此对上一步的输出，就会要求尽可能准确，完整，而当后期发生任何的变化，无论是需求还是设计，都会对整个项目的风险和成本，造成很大的影响
设置严格的审批流程，评估风险和成本，以决定是否接受变化：需求大多数是通过详细的需求说明文档来管理的，无论是Use Case，还是遵循IEEE 830的标准，或者ISO标准，都是对需求有非常具体详细的记录，而且很多的需求是从系统运行的角度来描述，很多时候，很难进行优先级的排序
例如：
电视机需要一个显示屏幕
电视机需要AV接口
电视机需要遥控器
电视机需要HDMI接口
电视机需要智能操作系统
然后需求告诉你“这些都很重要！我都要！”
敏捷模式
决定需求优先级：需求是用过story和product backlog进行管理的，是从用户角度切入的对于产品的认知，他们之间相互独立，没有耦合关系，因此比较容易进行排序，我们把刚那个例子改了一下：
作为用户，我希望能看电视频道
作为用户，我希望躺在床上遥控
作为用户，我希望把PS4接入电视玩
作为用户，我希望可以在电视上聊微信
这样的方式，用户是比较容易决定哪一个功能更加重要，也就可以快速的确定优先级。
这样，用户就可以根据现实情况，灵活的调整实现的顺序。因此，当任何需求的变更出现的时候，用户只需要通过设置合适的优先级，就可以将新的变更应用于系统中。
迭代式开发：可以帮助团队更加专注于实现最重要的功能，在技术方案上，不必急于完成所有的技术细节的设计，从而帮助他们“延迟决定”，采用演进式的设计，逐步达到最优的技术方案。这种方式，会促使团队根据当前确定的需求，通过持续的重构，获得最好的技术方案，不会因为在信息不完整的情况下，匆匆作出重大的但错误的技术决定，而导致在后期进行大规模重构带来的巨大风险和成本。因此，这样可以从技术实现方面，帮助团队更容易的接受变化。
变还是不变？
拥抱变化并不是允许毫无章法的变化，软件开发是一个类似于马拉松是的长跑，需要整个团队保持一个健康的节奏，这样才能顺利的跑到终点，如果节奏总是被不断的破坏，项目是很难最终成功的。而Sprint就是Scrum的节奏，如果在一个Sprint的过程中，团队不断的被新的要求干扰，就很难培养出对整个团队能力的感觉，也就会对项目的规划和估算带来很大的影响。另外，Sprint的长度往往是2～4周，也就是说，响应用户变化的周期是2～4周，任何新的重要变更，最长就是在2～4周后，就可以被响应和实现，这种频度，对于大多数的项目来说，是可以满足用户的变更要求的。所以在一个Sprint内保持需求的相对稳定是必要的，也是可以接受的，如果用户的需求变更频率更高，可以缩短Sprint的长度，以提高响应速度。
任何无序的变化，都是需要通过一定的方式，转化为有序的变化，才能够有利于项目的成功。Scrum中，通过设置合理的需求的优先级，以及合适的Sprint的长度来将需求的变化更加有序，通过迭代的开发和演进式的设计，来帮助团队更加容易的接受和适应变化，因此，相对于传统的瀑布式的开发模式，它更贴近用户，更加灵活，变更的成本和风险更低。
其实变与不变没有一定的结论！希望人人都能做好产品经理！
