SCRUM中如何处理sprint期间的需求变更和一些不确定性的任务

SCRUM是一种敏捷开发模式，源于橄榄球术语，有一些思想方法来自于这项运动，来回奔跑传球，最终达到团队目标。

SCRUM模式有4个会议：Sprint计划会议、每日站立会议（一般15分钟）、评审会议、回顾会议。

Sprint计划会议确定本次冲刺任务列表（Sprintbacklog），原则上一次冲刺内，拒绝需求变动，scrum master有责任保护team不受需求变更的影响。

关于Sprint执行期间（mid-sprint）的需求变更

一般而言，对一个成熟的scrum团队，通过挑选合适的用户故事列表，能够有效均衡团队工作量在各成员之间的分布，通过合适的接口设计，解除任务间的高度耦合，

这样可以使得每个成员都能高效投入，各司其职，紧密配合协作，最终完成整个团队的目标。

但让我们现实些，实际上由于各种各样的原因（开发模式成熟度、管理层压力、team前期选择的随意性、任务本身的不确定性、技术架构不清晰等），

容忍Sprint期间的任务变更在某些情况下是合理的。在实在需要变动时，可以通过异常终止一个sprint/开启一个新的sprint的方式来处理。但这种方法个人看来过于拘泥，可选的解决方法是Justintimesprintplanning来处理变更要求。但原则上team要对这个变更认可，觉得合适，不影响原先的承诺，productowner才可以加入变更；或者这个任务变更是team自主的一致意见，为了解决某个显见的问题。除此之外，mid-sprint需求变更应该被拒绝。

关于Sprint中不确定性任务的处理

用户需求中的一些不确定性的任务通常源于故事较大，涉及到不熟悉的技术方案，比如需要在一个手机应用中实现实时聊天，而团队并无这方面的经验，较难给出合适的估计，

那么在这个sprint中就需要安排进去技术调研的任务，这个任务的输出并非可以演示，而是可行或不可行。

类似这样的情况在SCRUM中有3个术语Spike/Research/Tracer Bullet：

• Spike – 一种快速而简陋的实现，是作为将被丢弃的试验品而设计的，主要是为了获取背景知识以知道某需求在技术上可行还是不可行，通常在不能有效估计用户故事时采用该方法
• Research – 宽泛基础的知识获取以决定哪些可以作为spike或者给到评估能力，通常在不知道该采用何种技术解决方案时采用
  
• Tracer Bullet – 对于一个宏大的用户故事的简略实现，通常在用户故事过大而难以评估时采用

Spike和Tracer Bullet的区别在于Tracer Bullet的实现一般不会被丢弃，且不一定要有具体的时间限制（is not necessarily time-boxed）。

参考链接：

http://thescrumbucket.tumblr.com/post/7680619154/on-changing-requirements-mid-sprint

http://www.gettingagile.com/2007/10/22/research-spikes-tracer-bullets-oh-my/

by iefreer