Scrum如何拥抱变化
最近和两个朋友一起组织了SEMP沙龙的一次活动，讨论Agile和CMMI一起工作的可能性。在讨论到需求变更管理时，有疑问说，敏捷是宣称拥抱变化的，可是Scrum的实施指导中，又要求在一个Sprint内的需求是不变的，这不是矛盾的吗？在这里，想就这个问题，简单的探讨一下。
其实，我们说拥抱变化，并不等于说毫无章法的变化，如果朝令夕改，也是无法确保项目成功的。在这一点上，无论是采用什么样的方法，都是一样的。
传统的瀑布式，由于其开发方式是序列式的，每一步都是建立在上一步的基础上，因此对上一步的输出，就会要求尽可能准确，完整，而当后期发生任何的变化，无论是需求还是设计，都会对整个项目的风险和成本，造成很大的影响，所以，一般都会设置严格的审批流程，评估风险和成本，以决定是否接受变化，越是后期，对于变化的评估就越是严格，越是不容易接受变化。另外，传统的开发模式，需求大多数是通过详细的需求说明文档来管理的，无论是Use Case，还是遵循IEEE 830的标准，或者ISO标准，都是对需求有非常具体详细的记录，而且很多的需求是从系统运行的角度来描述，很多时候，很难进行优先级的排序。例如：
- 手机应该有一个显示屏幕
- 手机应该有一个输入键盘
- 手机应该有一块电池
- 手机应该有一个通讯模块
这样的需求描述，如果我们让客户来决定那个更重要，应该是不可能完成的，客户会说，“这些对我来说都最重要”
Scrum，作为敏捷的一种实践，其需求管理的方式具备以下的优势。
能够很方便的决定需求优先级
Scrum中，需求是通过用户故事（User Story）和产品清单（Product Backlog）来维护的，是一个从用户角度，希望软件应该具备的功能列表，而且，用户故事的组织是没有层次关系的，因此，用户很容易决定哪一个功能对于他们来说更重要，例如
- 作为手机使用者，我要能够打电话
- 作为手机使用者，我要能够发短信
- 作为手机使用者，我要能够更换电池
- 作为手机使用者，我要能够拍照
- 作为手机使用者，我要能够上网
这样的方式，用户是比较容易决定哪一个功能更加重要，也就可以快速的确定优先级。这样，用户就可以根据现实情况，灵活的调整实现的顺序。因此，当任何需求的变更出现的时候，用户只需要通过设置合适的优先级，就可以将新的变更应用于系统中。
有利于迭代式的开发
Scrum是采用迭代的方式开发，而用户故事和产品清单，和迭代开发是完美的结合。这种需求管理方式，可以帮助团队更加专注于实现最重要的功能，在技术方案上，不必急于完成所有的技术细节的设计，从而帮助他们“延迟决定”，采用演进式的设计，逐步达到最优的技术方案。这种方式，会促使团队根据当前确定的需求，通过持续的重构，获得最好的技术方案，不会因为在信息不完整的情况下，匆匆作出重大的但错误的技术决定，而导致在后期进行大规模重构带来的巨大风险和成本。因此，这样可以从技术实现方面，帮助团队更容易的接受变化。
那么，为什么在一个Sprint内，不希望需求变更呢？这是不是和拥抱变化相矛盾呢？如前所述，拥抱变化并不是允许毫无章法的变化，软件开发是一个类似于马拉松是的长跑，需要整个团队保持一个健康的节奏，这样才能顺利的跑到终点，如果节奏总是被不断的破坏，项目是很难最终成功的。而Sprint就是Scrum的节奏，如果在一个Sprint的过程中，团队不断的被新的要求干扰，就很难培养出对整个团队能力的感觉，也就会对项目的规划和估算带来很大的影响。另外，Sprint的长度往往是2～4周，也就是说，响应用户变化的周期是2～4周，任何新的重要变更，最长就是在2～4周后，就可以被响应和实现，这种频度，对于大多数的项目来说，是可以满足用户的变更要求的。所以在一个Sprint内保持需求的相对稳定是必要的，也是可以接受的，如果用户的需求变更频率更高，可以缩短Sprint的长度，以提高响应速度。
综上所述，任何无序的变化，都是需要通过一定的方式，转化为有序的变化，才能够有利于项目的成功。Scrum中，通过设置合理的需求的优先级，以及合适的Sprint的长度来将需求的变化更加有序，通过迭代的开发和演进式的设计，来帮助团队更加容易的接受和适应变化，因此，相对于传统的瀑布式的开发模式，它更贴近用户，更加灵活，变更的成本和风险更低。
