敏捷Scrum如何响应变化

Posted 2021-04-25 中国光大银行科技创新实验室

敏捷专家在介绍敏捷开发的好处时，都会强调拥抱变化，敏捷宣言中，也有提到“响应变化高于遵循计划”。所以，在讨论到需求变更管理时，就有疑问说，敏捷是宣称拥抱变化的，可是在Scrum的实践中，又要求在一个Sprint内的需求是不变的，这不是矛盾吗？今天的敏捷课堂，就探讨一下“变化”这个问题。

其实，我们说拥抱变化，并不等于说毫无章法的变化，如果朝令夕改，是无法确保项目成功的，在这一点上，无论是采用什么样的方法，都是一样的。

传统的瀑布式，由于其开发方式是序列式的，每一步都是建立在上一步的基础上，因此对上一步的输出，就会要求尽可能准确、完整，而当后期发生任何的变化，无论是需求还是设计，都会对整个项目的风险和成本造成很大的影响。所以，一般都会设置严格的审批流程，评估风险和成本，以决定是否接受变化，越是后期，对于变化的评估就越是严格，越是不容易接受变化。另外，传统的开发模式，需求大多数是通过详细的需求说明文档来管理的，而且很多的需求是从系统运行的角度来描述，很多时候，很难进行优先级的排序。例如：

手机应该有一个显示屏幕；

手机应该有一个输入键盘；

手机应该有一块电池；

手机应该有一个通讯模块；

这样的需求描述，如果我们让客户来决定哪个更重要，应该是不可能给出结果的，客户会说，“这些对我来说都最重要”。

而Scrum，作为敏捷的一种实践，其需求管理的方式能够很方便的决定需求优先级。Scrum中，需求是通过用户故事（User Story）和产品待办列表（Product Backlog）来维护的，是一个从用户角度，希望软件应该具备的功能列表，而且，用户故事的组织是没有层次关系的，因此，用户很容易决定哪一个功能对于他们来说更重要，例如：

作为手机使用者，我要能够发短信；

作为手机使用者，我要能够拍照；

作为手机使用者，我要能够上网；

这样的方式，用户是比较容易决定哪一个功能更加重要，也就可以快速的确定优先级。这样，用户就可以根据现实情况，灵活的调整实现的顺序。因此，当任何需求的变更出现的时候，用户只需要通过设置合适的优先级，就可以将新的变更应用于系统中，这样就更好的适应了变化。

Scrum是采用迭代的方式开发，而用户故事和产品待办列表，和迭代开发是完美的结合。这种需求管理方式，可以帮助团队更加专注于实现最重要的功能，在技术方案上，不必急于完成所有的技术细节的设计，从而帮助他们“延迟决定”，采用演进式的设计，逐步达到最优的技术方案。这种方式，会促使团队根据当前确定的需求，通过持续的重构，获得最好的技术方案，不会因为在信息不完整的情况下，匆匆作出重大的但错误的技术决定，而导致在后期进行大规模重构带来的巨大风险和成本。因此，这样可以从技术实现方面，帮助团队更容易的接受变化。

那么，为什么在一个Sprint内，不希望需求变更呢？这是不是和拥抱变化相矛盾呢？拥抱变化并不是允许毫无章法的变化，软件开发需要整个团队保持一个健康的节奏，这样才能顺利的跑到终点，如果节奏总是被不断的破坏，项目是很难最终成功的。而Sprint就是Scrum的节奏，如果在一个Sprint的过程中，团队不断的被新的要求干扰，会影响团队的效率，也就会对项目的规划和估算带来很大的影响。另外，Sprint的长度往往是2～4周，也就是说，响应用户变化的周期是2～4周，任何新的重要变更，最长就是在2～4周后，就可以被响应和实现，这种频度，对于大多数的项目来说，是可以满足用户的变更要求的。所以在一个Sprint内保持需求的相对稳定是必要的，也是可以接受的，如果用户的需求变更频率更高，可以缩短Sprint的长度，以提高响应速度。

综上所述，任何无序的变化，都是需要通过一定的方式，转化为有序的变化，才能够有利于项目的成功。Scrum中，通过设置合理的需求的优先级，以及合适的Sprint的长度来将需求的变化更加有序，通过迭代的开发和演进式的设计，来帮助团队更加容易的接受和适应变化，因此，相对于传统的瀑布式的开发模式，它更贴近用户，更加灵活，变更的成本和风险更低。

END

图文：项目管理处

你“ 在看 ”我吗