《Scrum精髓：敏捷转型指南》—Scrum活动与工件

Scrum活动与工件

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

图2.3  Scrum框架

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

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

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

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

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

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

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

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

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

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

产品列表

在使用Scrum时，我们总是先做最有价值的工作。产品负责人结合Scrum团队其他成员与利益干系人的意见，最终负责确定和管理工作顺序，并采取产品列表（按优先级排列/排序的列表）的形式传达给别人（参见图2.4）。在开发新产品时，PBI在刚开始时是为满足产品负责人的设想而需要开发的特性。对于正在开发的产品，产品列表也可能包含新特性、对现有特性的变更、需要修复的缺陷以及技术改进点等。

产品负责人与内外部利益干系人合作收集并定义PBI。接下来确保PBI是以正确的顺序（使用类似于价值、成本、知识和风险之类的因子）放置的，使高价值条目出现在产品列表的顶部，低价值条目出现在底部。产品列表是一个不断演进的工件。在业务环境发生变化或Scrum团队（通过每个冲刺获得的对软件的反馈）深入了解产品后，可以添加、删除或修改其中的条目。

图2.4  产品列表

总的来说，建立和优化PBI、估算并确定它们的优先顺序，这样的活动称为“梳理”（参见图2.5）。

图2.5  产品列表的梳理

再简单说点题外话，在2011年还有另外一个争论：哪个术语更适合描述PBI顺序？是“确定优先顺序的”（原来用的术语）还是在《Scrum指南》（Schwaber and Sutherland 2011）中使用的术语“已排序的”？大家争论的焦点是，确定优先顺序只是排序的一种形式（而且，按照某些人的说法，甚至不是最恰当的排序形式）。如何最好地在产品列表中确定条目的优先顺序，这个问题受到很多因素的影响，这个概念的广度和深度不是一个词就能完全表达出来的。虽然关于“已排序的和确定了优先顺序的”的争论在理论上有益，但是大多数人（包括我）在讨论产品列表中的条目时并没有严格区分。

在确定好优先顺序、排好序或者说是安排好产品列表之前，还需要知道产品列表中每个条目的大小（参见图2.6）。

图2.6  PBI的大小

条目大小等同于成本，为了合理确定条目的优先级，产品负责人需要知道条目的成本。Scrum没有规定PBI的大小要用哪种方法来测量。在实践中，很多团队使用相对大小测量，例如故事点（story point）或理想天数。在使用相对大小测量表达项目的整体大小时，不考虑绝对值，而是考虑一个条目与其他条目的相对值。例如，在图2.6中，特性C的大小是2，特性E的大小是8。由此可以得出结论，特性E的大小大约是特性C的4倍。在第7章将进一步讨论这些测量标准。