产品待办事项构建画布也常被称为 PBB 画布是一种帮助团队梳理产品待办事项列表、拆解功能并编写用户故事的方法。它特别适用于敏捷团队在产品规划、需求细化和迭代准备过程中系统化地识别用户、功能、PBI 和验收标准。许多软件团队会用产品待办事项列表来描述产品需要实现的功能。这个列表通常由一组用户故事组成。每个用户故事都会说明谁需要这项能力、需要完成什么事以及为什么需要它。很多团队习惯认为产品负责人是产品待办事项列表的唯一来源。但事实上任何人都可以也应该参与编写用户故事。产品待办事项构建画布提供了一套简单的流程帮助团队完成这项工作。它从描述产品用户及其活动开始。用户活动会进一步衍生出功能也就是用户与产品之间的交互。随后功能会被拆解为产品待办事项。最后团队可以结合用户角色和活动背景将这些待办事项转化为用户故事。“用户故事”这一概念最早由 Kent Beck 在极限编程中提出其目的在于推动一种更加敏捷、更加重视对话的需求收集方式。几年后Mike Cohn 出版了《用户故事应用敏捷软件开发》这本书后来成为该领域的重要参考。在敏捷方法的早期团队中的每个人都会编写用户故事用来沟通需要完成的工作。后来随着 Scrum 等方法在更多团队中推广产品负责人逐渐成为编写用户故事并维护产品待办事项列表的主要角色。不过用户故事并不应该只由产品负责人编写。团队中的任何人都可以也应该参与其中。我和 Fábio Aguiar 合著过一本关于产品待办事项构建技巧的书目的正是帮助团队中的每个人都能写出更好的用户故事。什么是好的用户故事在介绍 PBB 画布之前我们有必要先了解什么样的用户故事才算是好的用户故事。下面将介绍几种常用的判断方法和写作原则。用户故事的 3W用户故事是一种简洁描述需求的文本格式。它通常需要回答三个问题也就是 3WWho这个故事是为谁准备的What这个人想完成什么动作或活动Why这个人为什么需要它它带来了什么好处或价值换句话说一个好的用户故事应该说清楚谁要做什么以及为什么要做。INVEST 原则判断用户故事质量的方法William C. Wake 在《极限编程探索》中提出了 INVEST 原则。INVEST 是一个缩写每个字母分别代表用户故事应具备的一项重要特征Independent独立一个用户故事不应强依赖另一个用户故事。Negotiable可协商用户故事描述的是需求的核心而不是一份固定不变的合同。它应该为后续沟通和协商留下空间。Valuable有价值用户故事应清晰体现它为客户或用户带来的价值。Estimable可估算用户故事应包含足够的信息使开发团队能够对其工作量进行估算。Small小而合适用户故事的规模应相对较小能够在较短时间内完成并适合放入一个迭代或冲刺中。Testable可测试用户故事必须足够清晰以便团队能够为它定义测试用例。后来Mike Cohn 将其中的 S 从 Small 调整为 Sized Appropriately也就是“大小合适”。这是因为在不同团队和不同上下文中用户故事的粒度可能并不完全相同。只要它适合团队当前的工作方式和交付节奏就是合适的。3C 模型卡片、对话和确认3C 模型从三个方面描述用户故事卡片、对话和确认。Card卡片用户故事的描述应当足够简洁能够写在一张索引卡片上。卡片上只需要记录足以识别这个用户故事的信息而不需要写下所有细节。最常见的用户故事格式是作为「某个角色 / 用户画像」我想要「完成某个动作 / 活动」以便「获得某种好处 / 达成某个目标」。例如作为一名参与者我想报名参加活动。这个例子虽然简短但已经说明了谁需要它以及这个人想要做什么。Conversation对话用户故事之所以要写得简洁是因为它不应该取代沟通。索引卡片空间有限文字描述必须保持简短因此团队需要通过持续对话来澄清问题、补充细节并明确实现这个故事所需的工作。采用用户故事意味着团队接受这样一种工作方式关于需求和交付的对话会持续发生而不是只在一开始确定需求时才发生。好的文档不是用来替代对话的而是帮助人们记住已经达成的共识和讨论过的内容。Confirmation确认确认是指团队需要判断用户故事的目标是否已经实现。验收标准正是用来完成这件事的。验收标准用于确认用户故事是否被正确实现并且是否成功交付。团队应在开始实现每个用户故事之前先定义清楚验收标准。这样在检查完成情况和验证交付结果时团队就不会产生不必要的分歧。如何使用 PBB 画布编写用户故事如前所述编写用户故事本质上是在回答三个问题谁什么为什么“谁”对应用户角色或用户画像。“什么”对应用户想要完成的动作或活动。“为什么”对应这个动作或活动带来的价值、好处或理由。在《产品待办事项构建》一书中我和 Fábio 介绍了如何借助 PBB 画布识别用户画像、功能和工作项并由此构建出高质量的用户故事。本文将通过一个数字产品示例说明如何填写 PBB 画布并编写用户故事。这个示例产品名为“演讲合集”它由海外某区域敏捷实践者群体创建用于整理演讲内容并组织活动。图 1PBB 画布接下来我们会介绍 PBB 画布中的三个关键模块用户画像、功能和产品待办事项。为了便于说明文中会使用“演讲合集”中的部分用户画像和功能作为示例。第一步描述用户画像用户画像代表产品的真实用户。因此对用户画像的描述不能只停留在“这个人是什么角色”上还需要包含他们的需求、目标和行为特征。这样做可以让用户形象更加具体也能帮助团队从用户视角出发描述产品应该具备哪些功能。图 2角色模块示例在描述主要用户画像时可以思考以下问题这个人的基本画像是什么这个人通常会做什么这个人有什么期待这个人的目标是什么如今很多团队会通过探索性工作坊、启动研讨会或其他协作活动来梳理用户画像。这些活动通常会产出一些相关材料例如同理心地图、用户旅程或访谈记录。如果团队已经有这些材料就可以在 PBB 过程中加以利用。不过需要注意的是在 PBB 阶段重点并不是重新做一遍完整的用户研究而是提炼出用户画像及其关键活动因为这些内容会成为后续识别功能和拆解待办事项的基础。第二步识别产品功能在充分理解用户画像及其活动之后接下来需要分析每个用户画像重新阅读相关描述并找出用户与产品之间的互动或行为。每一次重要互动都可以被表达为一个功能。图 3从用户画像到功能在描述产品功能时可以使用以下问题来引导思考用户想完成某项任务因此产品必须具备相应能力。这个能力是什么这个功能解决了哪些用户问题它能为用户带来什么好处图 4特征块示例团队可以将功能描述写在较大的便签纸上再把这个功能面临的挑战和带来的好处写在较小的便签纸上并贴在功能便签旁边。功能通常比具体开发工作项更高层。也就是说在真正开始开发某个功能之前团队还需要进一步分析这个功能并将它拆解为更具体、可执行、可估算的工作项。在产品待办事项构建画布中团队首先要识别功能、理解功能并确定功能的优先级。之后再将功能进一步拆解为产品待办事项。第三步确定产品待办事项 PBI产品待办事项即 Product Backlog Item简称 PBI是构成产品待办事项列表的基本元素。它们代表为了改进产品、满足客户或利益相关者需求而需要完成的开发工作。在上一步中团队已经描述了产品功能以及该功能面临的挑战和带来的好处。接下来需要把这些功能进一步拆分形成更小、更明确的待办事项。这些待办事项就是 PBI。为了确定某个功能下的 PBI可以让参与者依次回答这个功能的第一个工作项或步骤是什么第二个是什么接下来还需要做什么图 5产品待办事项块示例每个 PBI 都应代表用户在产品中执行的一个动作。例如购买图书。为会议添加演讲者。这些动作需要用清晰的文字描述以提供上下文并让每个待办事项都能够被准确识别。第四步将 PBI 转化为用户故事PBI 是用户故事列表的基础。团队可以结合每个 PBI 所关联的用户画像和功能价值填充典型的用户故事模板。图 6使用 PBB 编写用户故事在用户故事的“作为谁”部分填写用户画像。用户画像信息通常写在便签纸上并贴在 PBB 画布的“用户画像”模块中。例如用户画像可以是“演讲者”。在用户故事的“我想要”部分填写 PBB 画布“产品待办事项”模块中的内容也就是具体动作。它代表实现某个功能所需的一个步骤。例如这个动作可以是“发布演讲”。在用户故事的“以便”部分填写功能旁边便签中记录的某个好处。它代表该功能带来的价值之一例如“让内容可被访问”。因此一个完整的用户故事可以写成作为一名演讲者我想发布演讲以便让内容可被访问。写完用户故事的核心内容后团队还需要补充验收标准、任务、用户界面说明以及赋能项等信息。这些内容可以记录在 PBB 画布的“产品待办事项”区域中也可以记录在团队日常使用的需求或项目管理工具中。例如研发团队可以使用研发工具将目标、客户反馈、需求清理、评审排期、开发、测试、发布和 Wiki 知识沉淀串联起来让产品待办事项从规划到交付的过程更加数据化和可追踪如果团队更偏通用项目协作也可以使用 通用办公软件 管理任务、项目、文档、日历、甘特图、工时和审批等协作事项。PBB 画布中的用户故事示例下面以“演讲合集”这个数字产品为例展示三个功能及其对应的用户画像和用户故事。用户画像演讲者功能 1发布演讲故事 1.1作为一名演讲者我需要访问一个工作空间以便私下管理演讲内容。故事 1.2作为一名演讲者我想发布演讲以便让更多人接触到这些内容。故事 1.3作为一名演讲者我想将外部演示文稿与内部演讲关联起来以便更好地整合演讲内容。用户画像参与者功能 2参与活动故事 2.1作为一名参与者我想查找可参加的活动以便查看活动日程。故事 2.2作为一名参与者我想报名参加活动。故事 2.3作为一名参与者我想在活动现场签到以便确认出席。用户画像组织者功能 3组织活动故事 3.1作为一名组织者我想确定活动日程以便公布议程安排。故事 3.2作为一名组织者我想通过媒体宣传活动以便吸引观众。故事 3.3作为一名组织者我想邀请共同组织者以便共同推进活动筹备工作。用户故事还需要补充哪些细节前面的模板构成了用户故事的核心但一个真正可执行的用户故事通常还需要记录更多信息。虽然 PBB 画布本身并不专门承载所有细节但对这些内容进行说明依然很有价值。团队可以将这些细节补充到画布中的 PBI 上也可以使用其他工具来跟踪和维护用户故事。常见的补充信息包括验收标准实现任务用户界面说明赋能项。验收标准验收标准用于描述如何验证用户故事。它是一份检查清单用来判断用户故事何时算完成以及交付结果是否有效。下面是一个用户故事示例作为一名账户持有人我想在 ATM 机上取款以便不用在银行排队。针对这个故事可以定义如下验收标准当账户余额充足时账户持有人可以从账户中取款。当账户余额不足时账户持有人无法从账户中取款。即使账户余额充足如果 ATM 机现金不足账户持有人也无法取款。这些验收标准可以帮助团队验证故事是否完整、是否有效以及实现结果是否满足预期。将用户故事拆分为任务用户故事通常还会被进一步拆分成更小的任务。任务用于描述为了完成这个用户故事团队需要做哪些具体工作。通过列出实现用户故事所需的任务开发团队可以进一步讨论技术实现细节并明确每项工作的责任和范围。与用户故事不同任务没有固定的文本格式。它们通常更加直接也更偏技术化主要用于开发团队内部沟通。任务代表需要完成的具体工作是实现用户故事不可缺少的一部分。但任务本身不一定完整独立也不一定直接体现业务价值。例如修改输入表单字段创建用户测试账户编写自动化数据生成脚本调整接口参数修改数据库字段。这些都可以是任务。用户界面并不是每个工作项都与界面相关。但如果某个工作项涉及用户界面团队就需要在用户故事的上下文中明确界面要求。界面可以通过多种方式描述例如草图线框图视觉稿可交互原型。具体采用哪种方式取决于团队文化、产品复杂度以及团队愿意在前期投入多少时间。由此会产生一个问题在开始开发用户故事之前界面需要被定义到什么程度答案取决于团队共识。也就是说团队需要共同判断从用户界面的角度来看这个用户故事是否已经准备好进入开发。最重要的是团队要对目标形成一致理解并且对即将开展的工作有足够信心。赋能项有时候一个工作项很难被写成好的用户故事。即使你已经尝试使用 INVEST 和 3W 作为指导仍然可能无法写出令人满意的结果。如果出现这种情况可以判断它是否属于以下两类情况之一这个工作依赖某些前期研究这个工作依赖某些专业技术知识并且需要投入较多精力。如果属于上述情况团队可以把它视为某个更大故事的一部分也可以把它拆分成一个独立条目赋能项。赋能项之所以叫赋能项是因为它通常不遵循用户故事格式。它本身未必直接交付用户价值但它是实现某个用户故事或某组用户故事的必要前提。探索性赋能项例如作为一名开发者我想研究异步消息传递的工作原理以便决定如何实现聊天功能。严格来说这并不是一个真正的用户故事也没有必要把它写成用户故事格式。它更适合作为一个探索性赋能项。它需要在相关用户故事之前完成。例如相关用户故事可能是作为一名参会者我想在活动聊天中发送消息以便与其他参会者互动。这个例子说明在着手实现用户故事之前团队可能需要先完成一个探索性步骤研究异步消息传递的工作原理。探索性赋能项通常包括技术调研背景调查问题澄清方案比较技术选型。它们的作用是为后续高效实现用户故事奠定基础。Spike 是探索性赋能项的常用说法。技术赋能项非功能性需求、重构、流水线改进、测试基础设施改进等工作有时需要投入大量精力不适合直接放入某个用户故事中。在这种情况下团队可以将它们描述为技术赋能项。同时团队也需要说明哪些用户故事依赖这些赋能项。这样可以避免赋能项脱离业务目标变成孤立的技术工作。需要注意的是团队不应过度使用赋能项。否则产品待办事项列表最终可能会变成一组技术任务而不再体现清晰的用户价值。技术赋能项不需要写成用户故事格式。与其写成作为一名开发人员我想迁移自动化测试套件以便提高性能。不如使用更直接的表达执行自动化测试迁移。这样的写法更清楚也更符合技术赋能项的特点。完整用户故事示例发布演讲现在我们来看“演讲合集”中“发布演讲”功能下的一个用户故事示例。这个示例包含完整的用户故事、验收标准、任务、用户界面说明以及赋能项。用户故事 1.1作为一名演讲者我想将外部演示文稿与演讲内容关联起来以便更好地整合演讲资料。验收标准 1场景 1关联演示文稿分享平台上的演示文稿假设海外某演示文稿分享平台上存在一个有效链接当我关联外部演示文稿链接时那么屏幕上会显示该演示文稿的预览。验收标准 2场景 2发布演讲时关联演示文稿假设演示文稿链接有效当我发布演讲时那么已发布的演讲详情中会显示相关演示文稿。任务使用演示文稿端点。创建用于显示演示文稿 PDF 文件的用户界面。在后端创建逻辑将演示文稿与已发布的演讲关联起来。将参数调整为公共链接或私有链接。创建测试数据以验证链接是否有效。修改数据库使其能够存储演示文稿链接。界面草图探索性赋能项研究端点 API 与海外某些在线演示文稿分享平台的集成方式。技术赋能项使用 oEmbed 端点作为响应头中的链接标签以便在嵌入演示文稿时能够被自动检测。DoR 与 DoD定义“准备就绪”和“完成”在管理产品待办事项时团队通常还需要明确两个重要概念准备就绪的定义和完成的定义。它们可以帮助团队判断一个 PBI 是否已经可以进入开发以及一个 PBI 是否真正完成。准备就绪的定义 DoR准备就绪的定义即 Definition of Ready简称 DoR是团队达成的一项共识用来说明一个产品待办事项何时可以进入迭代周期。换句话说DoR 用于判断某个 PBI 是否已经具备足够信息可以进入计划、执行和交付阶段。当人们说“这个事项可以开始做了”时通常意味着团队已经确认团队具备处理该事项所需的信息团队理解该事项的目标和用途团队知道如何证明该事项已经完成团队清楚该事项如何构成某个功能或与某个功能相关团队认为该事项适合在一个冲刺或指定时间范围内完成。针对下一个迭代或工作周期中的每个候选 PBI团队都可以使用类似下面的检查清单进行确认。PBI 准备就绪检查清单PBI 已以用户故事的形式呈现。PBI 已具备验收标准。已识别需要改进或创建的 PBI 验收测试。PBI 已具备必要的用户体验要素。已识别 PBI 的依赖项如有。这是一份 DoR 检查清单示例。不同团队通常会制定并维护自己的检查清单以体现他们对准备工作的标准和偏好。产品待办事项列表的细化应当持续进行。团队需要不断推进下一批候选条目的准备工作为下一个迭代或工作周期做好准备。准备就绪的定义和完成的定义并非 Scrum 独有。在看板以及其他敏捷方法中它们同样非常有用。完成的定义 DoD完成的定义即 Definition of Done简称 DoD是团队用来确认 PBI 质量的一项约定。这里的“完成”并不只是指代码写完了而是指团队已经认可该项工作的交付质量和完成状态。DoD 明确了产品增量中“已完成工作”的标准。一旦某个 PBI 符合完成的定义就意味着该产品增量已经准备好发布到产品中。如果某个 PBI 不符合 DoD就不应该发布也不应该在迭代评审中作为已完成内容进行展示。它应继续作为团队的在制品也就是 WIP继续处理。对于每个被认为已经完成的 PBI团队需要证明它满足以下条件已交付产品增量已符合既定验收标准已编写必要的使用说明已符合编码标准已维护产品性能指标。PBI 完成检查清单已交付产品增量。已满足验收标准。已完成必要的使用说明。已符合编码标准。已维护产品性能指标。这是一份 DoD 检查清单示例。不同团队通常会制定并维护自己的清单以体现他们对工作验证和质量标准的偏好。总结用 PBB 画布提升用户故事质量产品待办事项构建画布能够帮助团队从用户画像出发识别产品功能拆解产品待办事项并最终形成清晰、可讨论、可验证的用户故事。对于希望提升产品待办事项列表质量的敏捷团队来说PBB 画布不仅是一种需求梳理工具也是一种促进团队协作和共识形成的方法。通过结合用户故事、PBI、验收标准、DoR 和 DoD团队可以让产品规划和迭代交付更加清晰、高效。
产品待办事项构建（PBB）画布：如何编写高质量用户故事
产品待办事项构建画布也常被称为 PBB 画布是一种帮助团队梳理产品待办事项列表、拆解功能并编写用户故事的方法。它特别适用于敏捷团队在产品规划、需求细化和迭代准备过程中系统化地识别用户、功能、PBI 和验收标准。许多软件团队会用产品待办事项列表来描述产品需要实现的功能。这个列表通常由一组用户故事组成。每个用户故事都会说明谁需要这项能力、需要完成什么事以及为什么需要它。很多团队习惯认为产品负责人是产品待办事项列表的唯一来源。但事实上任何人都可以也应该参与编写用户故事。产品待办事项构建画布提供了一套简单的流程帮助团队完成这项工作。它从描述产品用户及其活动开始。用户活动会进一步衍生出功能也就是用户与产品之间的交互。随后功能会被拆解为产品待办事项。最后团队可以结合用户角色和活动背景将这些待办事项转化为用户故事。“用户故事”这一概念最早由 Kent Beck 在极限编程中提出其目的在于推动一种更加敏捷、更加重视对话的需求收集方式。几年后Mike Cohn 出版了《用户故事应用敏捷软件开发》这本书后来成为该领域的重要参考。在敏捷方法的早期团队中的每个人都会编写用户故事用来沟通需要完成的工作。后来随着 Scrum 等方法在更多团队中推广产品负责人逐渐成为编写用户故事并维护产品待办事项列表的主要角色。不过用户故事并不应该只由产品负责人编写。团队中的任何人都可以也应该参与其中。我和 Fábio Aguiar 合著过一本关于产品待办事项构建技巧的书目的正是帮助团队中的每个人都能写出更好的用户故事。什么是好的用户故事在介绍 PBB 画布之前我们有必要先了解什么样的用户故事才算是好的用户故事。下面将介绍几种常用的判断方法和写作原则。用户故事的 3W用户故事是一种简洁描述需求的文本格式。它通常需要回答三个问题也就是 3WWho这个故事是为谁准备的What这个人想完成什么动作或活动Why这个人为什么需要它它带来了什么好处或价值换句话说一个好的用户故事应该说清楚谁要做什么以及为什么要做。INVEST 原则判断用户故事质量的方法William C. Wake 在《极限编程探索》中提出了 INVEST 原则。INVEST 是一个缩写每个字母分别代表用户故事应具备的一项重要特征Independent独立一个用户故事不应强依赖另一个用户故事。Negotiable可协商用户故事描述的是需求的核心而不是一份固定不变的合同。它应该为后续沟通和协商留下空间。Valuable有价值用户故事应清晰体现它为客户或用户带来的价值。Estimable可估算用户故事应包含足够的信息使开发团队能够对其工作量进行估算。Small小而合适用户故事的规模应相对较小能够在较短时间内完成并适合放入一个迭代或冲刺中。Testable可测试用户故事必须足够清晰以便团队能够为它定义测试用例。后来Mike Cohn 将其中的 S 从 Small 调整为 Sized Appropriately也就是“大小合适”。这是因为在不同团队和不同上下文中用户故事的粒度可能并不完全相同。只要它适合团队当前的工作方式和交付节奏就是合适的。3C 模型卡片、对话和确认3C 模型从三个方面描述用户故事卡片、对话和确认。Card卡片用户故事的描述应当足够简洁能够写在一张索引卡片上。卡片上只需要记录足以识别这个用户故事的信息而不需要写下所有细节。最常见的用户故事格式是作为「某个角色 / 用户画像」我想要「完成某个动作 / 活动」以便「获得某种好处 / 达成某个目标」。例如作为一名参与者我想报名参加活动。这个例子虽然简短但已经说明了谁需要它以及这个人想要做什么。Conversation对话用户故事之所以要写得简洁是因为它不应该取代沟通。索引卡片空间有限文字描述必须保持简短因此团队需要通过持续对话来澄清问题、补充细节并明确实现这个故事所需的工作。采用用户故事意味着团队接受这样一种工作方式关于需求和交付的对话会持续发生而不是只在一开始确定需求时才发生。好的文档不是用来替代对话的而是帮助人们记住已经达成的共识和讨论过的内容。Confirmation确认确认是指团队需要判断用户故事的目标是否已经实现。验收标准正是用来完成这件事的。验收标准用于确认用户故事是否被正确实现并且是否成功交付。团队应在开始实现每个用户故事之前先定义清楚验收标准。这样在检查完成情况和验证交付结果时团队就不会产生不必要的分歧。如何使用 PBB 画布编写用户故事如前所述编写用户故事本质上是在回答三个问题谁什么为什么“谁”对应用户角色或用户画像。“什么”对应用户想要完成的动作或活动。“为什么”对应这个动作或活动带来的价值、好处或理由。在《产品待办事项构建》一书中我和 Fábio 介绍了如何借助 PBB 画布识别用户画像、功能和工作项并由此构建出高质量的用户故事。本文将通过一个数字产品示例说明如何填写 PBB 画布并编写用户故事。这个示例产品名为“演讲合集”它由海外某区域敏捷实践者群体创建用于整理演讲内容并组织活动。图 1PBB 画布接下来我们会介绍 PBB 画布中的三个关键模块用户画像、功能和产品待办事项。为了便于说明文中会使用“演讲合集”中的部分用户画像和功能作为示例。第一步描述用户画像用户画像代表产品的真实用户。因此对用户画像的描述不能只停留在“这个人是什么角色”上还需要包含他们的需求、目标和行为特征。这样做可以让用户形象更加具体也能帮助团队从用户视角出发描述产品应该具备哪些功能。图 2角色模块示例在描述主要用户画像时可以思考以下问题这个人的基本画像是什么这个人通常会做什么这个人有什么期待这个人的目标是什么如今很多团队会通过探索性工作坊、启动研讨会或其他协作活动来梳理用户画像。这些活动通常会产出一些相关材料例如同理心地图、用户旅程或访谈记录。如果团队已经有这些材料就可以在 PBB 过程中加以利用。不过需要注意的是在 PBB 阶段重点并不是重新做一遍完整的用户研究而是提炼出用户画像及其关键活动因为这些内容会成为后续识别功能和拆解待办事项的基础。第二步识别产品功能在充分理解用户画像及其活动之后接下来需要分析每个用户画像重新阅读相关描述并找出用户与产品之间的互动或行为。每一次重要互动都可以被表达为一个功能。图 3从用户画像到功能在描述产品功能时可以使用以下问题来引导思考用户想完成某项任务因此产品必须具备相应能力。这个能力是什么这个功能解决了哪些用户问题它能为用户带来什么好处图 4特征块示例团队可以将功能描述写在较大的便签纸上再把这个功能面临的挑战和带来的好处写在较小的便签纸上并贴在功能便签旁边。功能通常比具体开发工作项更高层。也就是说在真正开始开发某个功能之前团队还需要进一步分析这个功能并将它拆解为更具体、可执行、可估算的工作项。在产品待办事项构建画布中团队首先要识别功能、理解功能并确定功能的优先级。之后再将功能进一步拆解为产品待办事项。第三步确定产品待办事项 PBI产品待办事项即 Product Backlog Item简称 PBI是构成产品待办事项列表的基本元素。它们代表为了改进产品、满足客户或利益相关者需求而需要完成的开发工作。在上一步中团队已经描述了产品功能以及该功能面临的挑战和带来的好处。接下来需要把这些功能进一步拆分形成更小、更明确的待办事项。这些待办事项就是 PBI。为了确定某个功能下的 PBI可以让参与者依次回答这个功能的第一个工作项或步骤是什么第二个是什么接下来还需要做什么图 5产品待办事项块示例每个 PBI 都应代表用户在产品中执行的一个动作。例如购买图书。为会议添加演讲者。这些动作需要用清晰的文字描述以提供上下文并让每个待办事项都能够被准确识别。第四步将 PBI 转化为用户故事PBI 是用户故事列表的基础。团队可以结合每个 PBI 所关联的用户画像和功能价值填充典型的用户故事模板。图 6使用 PBB 编写用户故事在用户故事的“作为谁”部分填写用户画像。用户画像信息通常写在便签纸上并贴在 PBB 画布的“用户画像”模块中。例如用户画像可以是“演讲者”。在用户故事的“我想要”部分填写 PBB 画布“产品待办事项”模块中的内容也就是具体动作。它代表实现某个功能所需的一个步骤。例如这个动作可以是“发布演讲”。在用户故事的“以便”部分填写功能旁边便签中记录的某个好处。它代表该功能带来的价值之一例如“让内容可被访问”。因此一个完整的用户故事可以写成作为一名演讲者我想发布演讲以便让内容可被访问。写完用户故事的核心内容后团队还需要补充验收标准、任务、用户界面说明以及赋能项等信息。这些内容可以记录在 PBB 画布的“产品待办事项”区域中也可以记录在团队日常使用的需求或项目管理工具中。例如研发团队可以使用研发工具将目标、客户反馈、需求清理、评审排期、开发、测试、发布和 Wiki 知识沉淀串联起来让产品待办事项从规划到交付的过程更加数据化和可追踪如果团队更偏通用项目协作也可以使用 通用办公软件 管理任务、项目、文档、日历、甘特图、工时和审批等协作事项。PBB 画布中的用户故事示例下面以“演讲合集”这个数字产品为例展示三个功能及其对应的用户画像和用户故事。用户画像演讲者功能 1发布演讲故事 1.1作为一名演讲者我需要访问一个工作空间以便私下管理演讲内容。故事 1.2作为一名演讲者我想发布演讲以便让更多人接触到这些内容。故事 1.3作为一名演讲者我想将外部演示文稿与内部演讲关联起来以便更好地整合演讲内容。用户画像参与者功能 2参与活动故事 2.1作为一名参与者我想查找可参加的活动以便查看活动日程。故事 2.2作为一名参与者我想报名参加活动。故事 2.3作为一名参与者我想在活动现场签到以便确认出席。用户画像组织者功能 3组织活动故事 3.1作为一名组织者我想确定活动日程以便公布议程安排。故事 3.2作为一名组织者我想通过媒体宣传活动以便吸引观众。故事 3.3作为一名组织者我想邀请共同组织者以便共同推进活动筹备工作。用户故事还需要补充哪些细节前面的模板构成了用户故事的核心但一个真正可执行的用户故事通常还需要记录更多信息。虽然 PBB 画布本身并不专门承载所有细节但对这些内容进行说明依然很有价值。团队可以将这些细节补充到画布中的 PBI 上也可以使用其他工具来跟踪和维护用户故事。常见的补充信息包括验收标准实现任务用户界面说明赋能项。验收标准验收标准用于描述如何验证用户故事。它是一份检查清单用来判断用户故事何时算完成以及交付结果是否有效。下面是一个用户故事示例作为一名账户持有人我想在 ATM 机上取款以便不用在银行排队。针对这个故事可以定义如下验收标准当账户余额充足时账户持有人可以从账户中取款。当账户余额不足时账户持有人无法从账户中取款。即使账户余额充足如果 ATM 机现金不足账户持有人也无法取款。这些验收标准可以帮助团队验证故事是否完整、是否有效以及实现结果是否满足预期。将用户故事拆分为任务用户故事通常还会被进一步拆分成更小的任务。任务用于描述为了完成这个用户故事团队需要做哪些具体工作。通过列出实现用户故事所需的任务开发团队可以进一步讨论技术实现细节并明确每项工作的责任和范围。与用户故事不同任务没有固定的文本格式。它们通常更加直接也更偏技术化主要用于开发团队内部沟通。任务代表需要完成的具体工作是实现用户故事不可缺少的一部分。但任务本身不一定完整独立也不一定直接体现业务价值。例如修改输入表单字段创建用户测试账户编写自动化数据生成脚本调整接口参数修改数据库字段。这些都可以是任务。用户界面并不是每个工作项都与界面相关。但如果某个工作项涉及用户界面团队就需要在用户故事的上下文中明确界面要求。界面可以通过多种方式描述例如草图线框图视觉稿可交互原型。具体采用哪种方式取决于团队文化、产品复杂度以及团队愿意在前期投入多少时间。由此会产生一个问题在开始开发用户故事之前界面需要被定义到什么程度答案取决于团队共识。也就是说团队需要共同判断从用户界面的角度来看这个用户故事是否已经准备好进入开发。最重要的是团队要对目标形成一致理解并且对即将开展的工作有足够信心。赋能项有时候一个工作项很难被写成好的用户故事。即使你已经尝试使用 INVEST 和 3W 作为指导仍然可能无法写出令人满意的结果。如果出现这种情况可以判断它是否属于以下两类情况之一这个工作依赖某些前期研究这个工作依赖某些专业技术知识并且需要投入较多精力。如果属于上述情况团队可以把它视为某个更大故事的一部分也可以把它拆分成一个独立条目赋能项。赋能项之所以叫赋能项是因为它通常不遵循用户故事格式。它本身未必直接交付用户价值但它是实现某个用户故事或某组用户故事的必要前提。探索性赋能项例如作为一名开发者我想研究异步消息传递的工作原理以便决定如何实现聊天功能。严格来说这并不是一个真正的用户故事也没有必要把它写成用户故事格式。它更适合作为一个探索性赋能项。它需要在相关用户故事之前完成。例如相关用户故事可能是作为一名参会者我想在活动聊天中发送消息以便与其他参会者互动。这个例子说明在着手实现用户故事之前团队可能需要先完成一个探索性步骤研究异步消息传递的工作原理。探索性赋能项通常包括技术调研背景调查问题澄清方案比较技术选型。它们的作用是为后续高效实现用户故事奠定基础。Spike 是探索性赋能项的常用说法。技术赋能项非功能性需求、重构、流水线改进、测试基础设施改进等工作有时需要投入大量精力不适合直接放入某个用户故事中。在这种情况下团队可以将它们描述为技术赋能项。同时团队也需要说明哪些用户故事依赖这些赋能项。这样可以避免赋能项脱离业务目标变成孤立的技术工作。需要注意的是团队不应过度使用赋能项。否则产品待办事项列表最终可能会变成一组技术任务而不再体现清晰的用户价值。技术赋能项不需要写成用户故事格式。与其写成作为一名开发人员我想迁移自动化测试套件以便提高性能。不如使用更直接的表达执行自动化测试迁移。这样的写法更清楚也更符合技术赋能项的特点。完整用户故事示例发布演讲现在我们来看“演讲合集”中“发布演讲”功能下的一个用户故事示例。这个示例包含完整的用户故事、验收标准、任务、用户界面说明以及赋能项。用户故事 1.1作为一名演讲者我想将外部演示文稿与演讲内容关联起来以便更好地整合演讲资料。验收标准 1场景 1关联演示文稿分享平台上的演示文稿假设海外某演示文稿分享平台上存在一个有效链接当我关联外部演示文稿链接时那么屏幕上会显示该演示文稿的预览。验收标准 2场景 2发布演讲时关联演示文稿假设演示文稿链接有效当我发布演讲时那么已发布的演讲详情中会显示相关演示文稿。任务使用演示文稿端点。创建用于显示演示文稿 PDF 文件的用户界面。在后端创建逻辑将演示文稿与已发布的演讲关联起来。将参数调整为公共链接或私有链接。创建测试数据以验证链接是否有效。修改数据库使其能够存储演示文稿链接。界面草图探索性赋能项研究端点 API 与海外某些在线演示文稿分享平台的集成方式。技术赋能项使用 oEmbed 端点作为响应头中的链接标签以便在嵌入演示文稿时能够被自动检测。DoR 与 DoD定义“准备就绪”和“完成”在管理产品待办事项时团队通常还需要明确两个重要概念准备就绪的定义和完成的定义。它们可以帮助团队判断一个 PBI 是否已经可以进入开发以及一个 PBI 是否真正完成。准备就绪的定义 DoR准备就绪的定义即 Definition of Ready简称 DoR是团队达成的一项共识用来说明一个产品待办事项何时可以进入迭代周期。换句话说DoR 用于判断某个 PBI 是否已经具备足够信息可以进入计划、执行和交付阶段。当人们说“这个事项可以开始做了”时通常意味着团队已经确认团队具备处理该事项所需的信息团队理解该事项的目标和用途团队知道如何证明该事项已经完成团队清楚该事项如何构成某个功能或与某个功能相关团队认为该事项适合在一个冲刺或指定时间范围内完成。针对下一个迭代或工作周期中的每个候选 PBI团队都可以使用类似下面的检查清单进行确认。PBI 准备就绪检查清单PBI 已以用户故事的形式呈现。PBI 已具备验收标准。已识别需要改进或创建的 PBI 验收测试。PBI 已具备必要的用户体验要素。已识别 PBI 的依赖项如有。这是一份 DoR 检查清单示例。不同团队通常会制定并维护自己的检查清单以体现他们对准备工作的标准和偏好。产品待办事项列表的细化应当持续进行。团队需要不断推进下一批候选条目的准备工作为下一个迭代或工作周期做好准备。准备就绪的定义和完成的定义并非 Scrum 独有。在看板以及其他敏捷方法中它们同样非常有用。完成的定义 DoD完成的定义即 Definition of Done简称 DoD是团队用来确认 PBI 质量的一项约定。这里的“完成”并不只是指代码写完了而是指团队已经认可该项工作的交付质量和完成状态。DoD 明确了产品增量中“已完成工作”的标准。一旦某个 PBI 符合完成的定义就意味着该产品增量已经准备好发布到产品中。如果某个 PBI 不符合 DoD就不应该发布也不应该在迭代评审中作为已完成内容进行展示。它应继续作为团队的在制品也就是 WIP继续处理。对于每个被认为已经完成的 PBI团队需要证明它满足以下条件已交付产品增量已符合既定验收标准已编写必要的使用说明已符合编码标准已维护产品性能指标。PBI 完成检查清单已交付产品增量。已满足验收标准。已完成必要的使用说明。已符合编码标准。已维护产品性能指标。这是一份 DoD 检查清单示例。不同团队通常会制定并维护自己的清单以体现他们对工作验证和质量标准的偏好。总结用 PBB 画布提升用户故事质量产品待办事项构建画布能够帮助团队从用户画像出发识别产品功能拆解产品待办事项并最终形成清晰、可讨论、可验证的用户故事。对于希望提升产品待办事项列表质量的敏捷团队来说PBB 画布不仅是一种需求梳理工具也是一种促进团队协作和共识形成的方法。通过结合用户故事、PBI、验收标准、DoR 和 DoD团队可以让产品规划和迭代交付更加清晰、高效。
