冲刺

什么是冲刺目标？

冲刺目标描述当前冲刺的商业目的和价值。比如

支持报告生成

加载地图数据

收集硬件信息

 

共同承诺

冲刺目标是团队和产品负责人作出共同承诺的基础。团队承诺在当前冲刺结束之前完成目标，产品负责人承诺在冲刺执行过程中不变更目标 。

 

是变更，还是澄清？

什么情况算变更？变更是工作或资源的变动，在经济上会造成潜在的严重浪费，中断工作流或在一个冲刺内大量增加工作范围。比如：产品负责人：“哦，我所说的是要能够在警察数据库中搜索少年犯，并不只是按姓名搜索，还有能够按照嫌犯的汶上照片来搜索数据库！”（增加图片搜索可能意味着开发量大增，属变更）

 

什么情况是澄清呢？

澄清是在冲刺执行期间提供更多的细节来帮助团队实现冲刺目标。比如：

开发团队：“你说搜索出来的少年犯应该显示在列表中，你对列表排序方式有什么偏好吗？”

产品负责人：“有，按照姓的字的字幕顺序排序”

开发团队：“没问题，可以这样做”

 

变更引起的后果

锁定目标后若在冲刺中进行变更，除了浪费这样的直接经济后果，还可能损害团队的士气和信任关系。

 

注重实效

理想很丰满，现实很骨感。在某些特殊情况下，Scrum团队除了锁定目标，还需要注重实效。比如

假设竞争对手在我们执行冲刺的过程中推出了一个新产品。在考察这个新产品后，我们得出结论，考虑到竞争对手所完成的产品，我们现在做的事情没有什么价值，需要改变当前冲刺设定的目标。这种情况下，我们应该盲目的遵循“锁定目标”这个规则吗？也许不必盲从。

假如一个重要的生产系统发生故障，而且只有我们团队里部分或所有人才能修复这个故障，此时应该怎么办？我们能跟业务部门说，我们将在下一个冲刺中优先考虑修复故障吗？也许不能。

归根结底，我们必须用经济合理的方式采取行动。Scrum团队的每个人都会理解。如果我们改变当前冲刺，就会出现前面谈到的负面经济后果。但是，如果变更造成的经济后果远远小于推迟变更所造成的经济后果，那么适时变更就是一个明智的决策。如果产品负责人与团队能够针对变更的必要性进行一次坦诚的、关注经济效果的讨论，大多数团队都应该能理解并领会这种必要性，这样一来，就能保全士气和信任。

 

异常中止

假如冲刺的目标变得完全无效，Scrum团队可能会认为继续当前的冲刺没有任何意义并建议产品负责人异常中止当前冲刺。一个冲刺异常终止时，Scrum团队需要聚在一起执行一次冲刺回顾。然后，团队和产品负责人在一起计划下一个冲刺，设置不同的目标并开发一组不同的PBI（Production Backlog Item）

虽然产品负责人有权取消任意一个冲刺，但从过往经验上看，产品负责人很少动用这个权权力。Scrum团队常常可以采取一些更温和的手段来处理目前的形式，因为冲刺很短，且突发状况多发生在冲刺中途，所以终止冲刺所产生的经济后果可能还不如走下去更有利。要有这样的意识，中止冲刺应该是不得已而为之的最后手段。

 

完成的定义

从概念上说，完成的定义是，在宣布工作潜在可发布之前，要求团队成功完成的各项工作检查。（如下表）

设计评审完成

代码完成

  代码重构完成

  代码是标准格式

  代码已加注释 

  代码已提交

  代码已检查

最终用户文档已更新

完成测试

  完成单元测试

  完成集成测试

  完成回归测试

  完成平台测试

  完成语言测试

零已知缺陷

完成接收测试

已在生产服务器上线 

显然，检查列表上的具体项目依赖很多变量。

  正在构建的产品的性质

  构建所采用的技术

  构建产品的组织

  当前阻碍可能完成的事情的因素

在多数情况下，完成的定义至少要产生一个产品功能的完整切片，即经过设计、构建、集成、测试并编写了文档，能够交付已验证的客户价值。

 

完成的定义可以随时间演变

可以将完成的定义看作是对冲刺结束时工作状态的定义。对于很多高效率团队来说，工作的目标结束状态是产品潜在可发布-并且这种结束状态在整个开发周期中保持相对恒定。有些情况下，团队知道他们的障碍无法立即移除。因此知道在产品开发的过程中完成的定义必须演变。一个常见的例子是一个产品同时包含硬件和软件，有时硬件要滞后很久才能提供，所以只能先在仿真机上做测试，后期，有了实际的硬件之后，完成的定义就会演变成潜在可发布或者至少接近于这个标准。

 

结语

本文强调了Scrum框架中冲刺的重要作用。冲刺提供基本的Scrum股价，大多数其他的活动和工件都以它为基础。下一集，我们关注冲刺的输入：用户故事。