使用产品待办事项列表-InfoQ

《Scrum 敏捷产品管理》是一本指导产品负责人通过使用 Scrum 来开发杰出产品的书。该书涵盖了各式各样的敏捷产品管理方面的话题，包括产品构想，构建和精炼产品待办事项列表，计划和追踪项目，如何和团队、用户以及客户一起工作，以及角色转变。
本文节选自该书 (第三章使用产品待办事项列表)，主要介绍了产品待办事项列表及其 DEEP 特征，具体解释了怎样梳理产品待办事项列表，并和大家分享了关于识别、描述产品待办事项列表中的待办项，以及组织产品待办事项列表方面的建议。梳理产品待办事项列表在 Scrum 中需要很好的团队协作，所以通过阅读本文，ScrumMaster、敏捷教练、团队成员都能获益匪浅。

在 Scrum 中很少有像产品待办事项列表那样受欢迎的工件了，这当然是有原因的：产品待办事项列表非常简单明了——它就是一份列表，罗列为了让产品上线需要完成的重要工作，并且按照优先级排序。列表中的待办项可以包括对客户需要的探究、不同的技术方案、功能和非功能性需求的描述、产品上线的必要工作以及其他事项，比如建立环境或者修复缺陷。产品待办事项列表代替了传统的需求文档，比如市场和产品的需求规格说明书。产品负责人来负责管理产品待办事项列表，而 ScrumMaster，项目团队以及利益关系人一起出谋划策，他们会一起讨论产品的功能。
本章将探讨产品待办事项列表以及有效梳理它的相关方法。此外，我们还将讨论了一些更加复杂的产品待办事项列表的应用情况，包括如何处理非功能性需求以及如何在大型项目中使用产品待办事项列表。

产品待办事项列表的 DEEP 特征

产品待办事项列表有四大特征：适当具体化的（detailed appropriately）、估算过的（estimated）、不断演化的（emergent）以及按优先级排序的（prioritized），这就铸就了 DEEP(DEEP 这一缩写应该归功于 Mike Cohn)。让我们来具体谈谈这些特征。

适当具体化的

对产品待办事项列表中的待办项的描述是适当具体化的，如图示 3.1。对待办项的描述，高优先级的要比低优先级的更加具体。Schwaber 和 Beedle（2002, 33）在他们的书中说过：“优先级越低，描述越少，只要你刚刚好能够理解待办事项列表中的待办项就行。”遵循这条金玉良言可以保持待办事项列表的简洁，并且可以确保在接下来一个 Sprint 里很可能会被实现的待办项是可行的。由此带来的结果就是，在整个项目进行的过程中，需求都是被识别好、分解好和精炼好的。

估算过的

产品待办事项列表中的待办项都是被估算过的。这些估算值都是粗粒度的，而且通常是以故事点或者理想日为单位。知道待办项的大小可以帮助我们排列优先级并制定发布计划。（具体的任务级别的估算是在 Sprint 计划会议上才确定的。具体的任务和估算会被记录在 Sprint 待办事项列表里面。）

不断演化的

产品待办事项列表有个有机体般的特征: 它会演化，而且它的内容会经常变化。根据客户和用户的反馈，新的待办项会被识别出来并加入到待办事项列表里面。对于显存的待办项，我们会不断地加以修改、重排优先级、精炼或者移除。

按优先级排序的

产品待办事项列表中的所有待办项都是按优先级排序的。最重要的、优先级最高的待办项会第一个被实现。而且它们总是在产品待办事项列表的最顶部，如图例 3.1 所示。一旦某项完成了，就会从产品待办事项列表中移除它。

梳理产品待办事项列表

就像花园如果很久没人去修整，就会长满野草一样，如果没人关注产品待办事项列表，它也会变得很混乱。待办事项列表是需要定期去关注，仔细地管理或者梳理好的。梳理产品待办事项列表是个持续的过程，主要由以下几个步骤组成。需要注意的是，在执行过程中并不一定需要按照下面所列的次序进行。

识别并且描述新的待办项，根据情况更新或者移除已有项。
对产品待办事项列表进行优先级排序。最重要的待办项放在最顶部。
分解并优化高优先级的待办项，为在接下来的 Spring 计划会议上讨论它们做好准备。
团队估计产品待办事项列表中每一项的大小。在待办事项列表中添加新的待办项，或者更新已有项并修正必要的估算。

虽然产品负责人负责确保产品待办事项列表的有效性，但梳理工作是一个团队协作的过程。整个 Scrum 团队一起参与待办项的识别、描述、优先级排列、分解以及精炼——Scrum 中，往往会安排最多 10% 的团队时间来做梳理工作 (Schwaber 2007)，有时候，根据需要，利益关系人也会参与其中。需求不再是“被”交接给团队，相反，团队成员是需求的共同作者。产品负责人、 ScrumMaster 以及团队成员一起参与到面对面的交流之中，而不再是通过文档来交流了。

大家一起协作来梳理产品待办事项列表是很有意思和有效的。这会促进 Scrum 团队内部以及团队和利益关系人之间的交流；移除“业务部门”和“技术部门”之间的三八线；消除不必要的交接工作；提高需求的透明度；充分利用 Scrum 团队的集体智慧和创造力；同时营造认同感和共同所有权。

有些团队喜欢在他们的每日例会之后简短地梳理一下待办事项列表。另外一些更喜欢每周有个梳理会议或者在 Sprint 快结束时举行一个时间更长的梳理研讨会。当 Scrum 团队和利益关系人在 Sprint 评审会议上讨论下一步工作的时候，也可以进行梳理：识别出新的，移除不再需要的。确保你建立起一套梳理过程，比如可以从每周梳理研讨会着手，这样可以使梳理更有保障。梳理好的待办事项列表是成功 spring 计划会议的必要条件。

纸质卡片是帮助梳理产品待办事项列表的一个很好的工具，便宜且易用。它们能很好地促进大家的协作。每个人都可以拿一张卡片，写下自己的观点。同时可以把卡片归集到桌上或者都贴在墙上，以便来检查它们的一致性和完整性。

纸质卡片或者一些电子化的产品待办事项列表工具，比如电子表格，能很好地相互补充：在研讨会之前，把已有的需求打印到卡片上，讨论完之后，把卡片上的信息更新回电子表单中。现在，让我们来进一步探讨一下梳理过程四部曲，先从识别、描述待办项开始。

识别、描述待办项

识别和描述产品待办事项列表中的待办项是一个持续的过程。如果你习惯于预先编写全面深入的需求规格说明书的话，你就会发现 Scrum 其实是一种本质上完全不一样的方法。需求不再需要一开始就定义清楚，相反，需求的识别和具体描述贯穿于整个项目周期。当我们对客户需要以及怎么最好地去实现这些需求越来越理解，现有的需求很可能会改变或者变得多余了，而新的需求也将出现。因此，在 Scrum 中，产品识别不能仅仅限于开发的早期阶段，而是要贯穿于整个项目开发周期中。

很多正在过渡到产品负责人的产品经理发现，不写下所有的需求，不去定义细节是很有挑战性的——即使他们本可以这么做。

识别待办项

识别产品待办事项列表中的待办项的第一步是构建产品待办事项列表。这个过程最好由 Scrum 团队，需要的话，加上利益关系人一起协作，以产品理念，产品愿景或者产品发展蓝图作为出发点，进行头脑风暴，想想为了让产品走向市场，有哪些项是需要的。构建产品待办事项列表的时候，要避免犯一种错误，那就是试图找出所有可能的待办项。就像第二章所描述的，那些必需的功能应该尽可能得最少，力求保持简单。随着项目进展，会有更多的想法涌现，根据客户和用户的反馈，待办事项列表也将变大。一开始就有一个非常长而且复杂的产品待办事项列表会让大家很难关注重点，也很难做好优先级排序。这个时候，就需要利用产品理念、产品愿景来指导工作。

眼前，仅仅关注最关键的部分，不用太过担心其他的。需要抵御住快速地增加很多细节这种诱惑。对于细节地描述是根据优先级渐进式的。低优先级待办项的数目会很巨大，而且是粗粒度的。在优先级改变之前（抑或因为它们被重新分配了优先级，抑或因为本来高优先级的待办项已经完成了），它们就这样在待办项列表里保持不变。那些代表产品整体特性的非功能性需求是个例外。这些非功能性的需求应该在早期就被具体地定义下来，我会在后面具体解释。

一旦产品待办事项列表有了雏形，就会有很多识别新待办项的机会。比如在梳理研讨会上，当 Scrum 团队进行优先级排序以及分解产品待办事项列表项的时候，比如在 Sprint 评审会议中当利益关系人提出反馈的时候，或者当收到客户和用户关于已发布产品的评价的时候。

只要向待办事项列表中添加了新的需求，我们就需要确保正确地理解了相关的客户需求。思考自问一下为什么这个需求是必要的，它能给客户带来什么价值呢？不要犯这种错误，盲目地将客户需求复制粘帖到产品待办事项列表中，因为这只会给你带来一份不一致而且很难管理的愿望清单。要对已有的需求抱着怀疑的态度，把它们当做一种负债来看待，而不是你的资产。有的时候，对于那些大家认为是产品必须的功能，只需要简单地描述一下就够了。随着市场和技术的变化，随着 Scrum 团队更加深入地了解了客户的需求以及如何最好地去实现它们，需求也是会改变或者废弃的。

描述待办项

Scrum 不强制规定应该怎么样去描述产品待办事项列表，但我更喜欢使用用户故事来描述 (Cohn 2004)。就像它的名字那样，用户故事讲述客户或者用户使用产品的情况。它包含名字，故事概要，验收条件以及完成故事的必要条件。

用户故事可以是粗粒度的，也可以具体化的。粗粒度的故事被称之为史诗故事 (epics)。编写、分解以及精炼这种用户故事是相当容易的。当然，你也可以使用别的技术来描述你的需求。如果你在使用用户故事，你不应该觉得自己必须要把每个产品待办事项列表中的待办项都描述成用户故事。比如，对于可用性方面的需求，最好以原型或者草图的方式来捕获。

使用产品待办事项列表并不意味着 Scrum 团队就不能使用其他有帮助的工件，包括不同用户角色的概述文档、用户故事的工作流模型、描述业务规则的图、描述复杂计算的电子表格、用户界面草图、故事板、用户界面导航图以及用户界面原型。这些工件不能取代产品待办事项列表，但它们能详细描述和解释待办事项列表中的内容，它们也能让事情保持简单。虽然工件种类繁多，但我们只使用有助于帮助 Scrum 团队早日发布产品的工件。

组织待办事项列表

把相关的待办项归类成不同的主题能给产品待办事项列表带来不少益处。主题是产品功能的占位符，它们能组织好待办事项列表，帮助优先级排序，也使得信息检索变得更加方便。比方说，对于手机而言，可能的主题包括：邮件、日历、语音通讯以及记事簿。一般来说，每个主题都应该包括二到五个粗粒度的需求。这有助于在没有过于具体化待办事项列表内容的情况下，也能提供一定的信息，让大家明白为了让产品上线需要做点什么。

主题可以创建产品待办事项列表的层次结构，除了单个零散的待办项，还有成组的待办项。此外，它也有助于进一步区分粗粒度的需求，比如史诗故事，以及已经具体化了的待办项，比如故事，如下表 3.1 所示，描述了部分产品待办事项：

表 3.1 产品待办事项列表举例

主题

粗粒度的待办项

具体化的待办项

工时

邮件

发邮件

作为一名企业用户，我想能够填写邮件主题

表 3.1 中的主题包含了粗粒度的待办项。随着时间的推移，它们会被分解成更加具体的待办项。当团队做估算的时候，会记录下它们的大小。在使用你的产品待办事项列表工具的时候，你也可以单独使用表 3.1 的结构，比如在一块插针板、白板或者公司的墙上适当地排列纸质卡片。

本文是 Roman Pichler 的《Scrum 敏捷产品管理：构建客户喜爱的产品》一书的书摘。该书由Pearson/Addison-Wesley Professional 于2010 年3 月出版，ISBN 0321605780，版权 2010 Roman Pichler。可以访问出版商的网站获取详细的目录。

查看英文原文： Working with the Product Backlog

感谢石永超对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。