Scrum活动与工件

图2.3描述Scrum的大部分活动和工件并说明了它们是如何配合的。

我们来概述一下图中的内容，从图的左边开始，沿着最大的环形箭头（一个冲刺）顺时针介绍。

产品负责人建立产品愿景（图中的大立方体）。因为这个立方体可能很大，所以要通过梳理（也称“修整”）活动分解为一组特性并收集到列表按优先级排序的列表中。

冲刺开始时首先是冲刺计划，在冲刺过程（称为冲刺执行）中包含开发工作，最后是评审和回顾。冲刺由图中央最大的那个环形箭头表示。产品列表中的条目开发团队可能无法在一个短冲刺中开发完。因此，在每个冲刺开始的时候，开发团队必须把自己认为能够完成的PBI的子集确定下来——这个活动称为“冲刺规划会”，即图中用来表示产品列表的大立方体右边的那部分。

简单说点题外话，在2011年，《Scrum指南》（Schwaber and Sutherland 2011）中的一处修改引发了一场争论：预测和承诺这两个术语，哪一个更适合描述冲刺计划呢？主张使用预测的人之所以喜欢这个词，是因为他们觉得开发团队虽然做出了当时能做的最佳估算，但随着冲刺过程中了解的信息越多，估算可能会发生变化。还有些人认为让团队做出承诺会导致团队为实现承诺而牺牲质量或者为确保兑现承诺而“少承诺一些”。

所有开发团队都应当预估自己在每个冲刺能够交付的产品，我认同这个观点。但是，如果能够从预测中得到承诺，对很多开发团队都是有益的。承诺有助于增进产品负责人和开发团队之间的互信，也有助于增进开发团队内部的互信。另外，承诺也有助于在组织内制定合理的短期计划并有助于决策。并且，在多个团队开发产品时，承诺有助于同步计划——一个团队可以根据另外一个团队做出的承诺进行决策。本书中，我比较喜欢使用术语“承诺”，不过，如果上下文合适，偶尔也会使用“预测”。

为了有信心确保开发团队的承诺是合理、恰当的，团队成员在冲刺规划期间会建立第二个列表，称为冲刺列表。冲刺列表通过一组详细任务，描述团队在这个特定的冲刺中计划如何设计、构建、集成并测试从产品列表中挑选出来的特性子集。

接下来是冲刺执行，开发团队执行一些必要的任务，以便实现选定的特性。在冲刺过程中的每一天，团队成员都要进行同步、检查与调整计划，通过每日例会这种活动来帮助管理工作流。在冲刺执行结束时，团队产出一个潜在可发布产品增量，体现产品负责人所构想的部分产品，但不是全部产品。

Scrum团队在冲刺结束时要执行两个“检视与调整”活动。第一个活动称为“冲刺评审”，利益干系人和Scrum团队检视正在构建的产品。第二个活动称为“冲刺回顾”，Scrum团队在这个活动中检视构建产品时所用的Scrum过程。这些活动带来的结果可能是对产品列表或团队开发部分过程进行适应性调整。

此时再次重复进行Scrum冲刺的循环过程，在重新开始时开发团队要确定能够完成的下一批最重要的PBI（产品列表条目）。在完成适当数量的冲刺之后，就可以实现产品负责人的构想并发布解决方案了。

本章接下来将进一步详细讨论这些活动和工件。