Scrum如何拥抱变化

最近和两个朋友一起组织了SEMP沙龙的一次活动,讨论Agile和CMMI一起工作的可能性。在讨论到需求变更管理时,有疑问说,敏捷是宣称拥抱变化的,可是Scrum的实施指导中,又要求在一个Sprint内的需求是不变的,这不是矛盾的吗?在这里,想就这个问题,简单的探讨一下。

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

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

  1. 手机应该有一个显示屏幕
  2. 手机应该有一个输入键盘
  3. 手机应该有一块电池
  4. 手机应该有一个通讯模块

这样的需求描述,如果我们让客户来决定那个更重要,应该是不可能完成的,客户会说,“这些对我来说都最重要”

 

Scrum,作为敏捷的一种实践,其需求管理的方式具备以下的优势。

能够很方便的决定需求优先级

Scrum中,需求是通过用户故事(User Story)和产品清单(Product Backlog)来维护的,是一个从用户角度,希望软件应该具备的功能列表,而且,用户故事的组织是没有层次关系的,因此,用户很容易决定哪一个功能对于他们来说更重要,例如

  1. 作为手机使用者,我要能够打电话
  2. 作为手机使用者,我要能够发短信
  3. 作为手机使用者,我要能够更换电池
  4. 作为手机使用者,我要能够拍照
  5. 作为手机使用者,我要能够上网

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

有利于迭代式的开发

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

 

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

 

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

posted @ 2010-08-29 14:54  Li Dingshan  阅读(...)  评论(...编辑  收藏