产品列表

在使用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章将进一步讨论这些测量标准。