上篇文章大家都学习到了如何描绘产品愿景，其实就是通过粗粒度级别的选择性描述这一简约方式，来激发大家的创造力和执行力。那如何在愿景建立以后确定每次迭代周期里的需求大小、需求的优先级以及验收的标准，这就是 Backlog 发挥出的巨大作用。
Backlog 英文意思为“积压的工作“，Product Backlog 其实就是一个具有优先级的需求列表， 并对每个需求进行了粗略的估算。
首先我们来区别一下传统开发模式 Waterfall PRD 文档和 Scrum 模式下 Backlog 的区别。
Backlog?
Waterfall PRD 文档 VS Scrum Backlog
Waterfall PRD 文档
传统的瀑布工作模式使用详细的需求说明书来表达需求，需求人员负责做需求调研，根据调研情况编制详细的需求说明书，进行需求评审，评审之后签字确认交给研发团队设计开发。在这样的环境下，需求文档是信息传递的主体，也是一份契约。然而这种详细的PRD 文档有以下5大弊端：
1. 单向的信息传递，容易出现理解偏差。
2. 文档很正式，我们会误以为它一定是对的，不去质疑它，让我们停止作出判断。
3. 有了详细的文档，我们不会反复讨论它，相互确认。
4. 书面文档不利于团队共享责任，它扮演了证据的角色。
5. 编制详细的、表达准确需求文档需要花费大量的时间，如果需求变化频繁，维护成本更高。
Scrum Backlog
敏捷使用产品Backlog来管理需求，产品 Backlog 其实就是一个优先级排序的需求清单，优先级的需求在 Backlog 的最上层。产品 Backlog 是一个渐进明细的清单，包括对客户需求或各类技术选项的探索，对功能性和非功能性需求的记述，发布产品的前提条件，还有一些需求涉及环境的建设或者缺陷的修复。
可以看出 Scrum Backlog 较 Waterfall PRD 文档 来看，更强调团队共享责任，团队会分出 10% 的时间来做梳理工作。需求不只是单独的传递。不论是需求人员、开发人员和还是测试员，大家的共同目标是通过讨论、协作，正确理解需求之后把这些需求变成客户真正需要的功能，而不是单向的任务传递。
那接下来，我会从 Backlog 的 DEEP 特征 、梳理的步骤、估算的方法几个方面来详细的介绍 Backlog。
DEEP 特征
1. 详尽适当的
高优先级的比低优先级的技术更详细。优先级越低，细节越少，只要刚能理解 Backlog 即可。因为需求的发掘、分解和细化工作会贯穿整个项目始终。高优先级的 Story 在快速迭代投入市场试错之后，也许会改变低优先级 Story 的内容和顺序。
2. 经过估算的
通常估算以故事点或者理想人天的形式来表达。了解条需求的规模有助于对它们进行优先级排序和制定发布计划（之后会详细介绍用户故事和估点）
3. 涌现的
产品 Backlog 具有一种有机特性，就是它会不断的演化，根据用户的不断反馈，识别出新条目会被加入Backlog里面。
4. 按优先级排序的
产品 Backlog 所有条目都是按照优先级排序的，最重要、优先级最高的条目最先实施，一旦完成，便从 Backlog 移除。这里推荐一个很棒的工具：纸质卡片。方便随时表达涌现的想法和移动
梳理四步法
发掘并记述新条目，根据实际情况改变或者移除已有条目
首先强调，发掘并描述产品 Backlog 是一个持续的过程，它贯穿整个产品始终。
随着产品的深入和反馈，我们对现有的产品会有新的想法涌现，不合适的需求会随时需要更改或者移除。这其实是对传统产品经理来说是个挑战，因为大部分产品经理习惯的做法是一开始就写下所有的产品需求，并且尽享详细的分析描述。
Backlog Working Flow
1. 发掘
发掘的过程首先是储备产品 Backlog，这是团队共同参与的（团队在澄清会上对需求拆解和排列优先级时，或者回顾会上收到客户反馈，这些都是需求涌现的机会）如前所述，这时候的需求不需要面面俱到，事无巨细，只是最基本的需求，力求极简。要抵制诱惑，不要过早过多的增加细节。低优先级的条目数量大，而且是粗粒度的。
这里需要注意，非功能性的需求是个例外，需要尽早对其详细描述，他会影响会影响整个产品的用户体验，甚至是成败。
2. 描述
我推荐用 Story (用户故事，之后我会专门写文章详细讲解用户故事实践）来描述。
这里我简单的说下，用户故事包含一个名称；一句简短的描述；验收标准；保持故事完整性要件。需要具备 INVEST 六个特征，比如，作为研发人员，我需要写一个操作缓存的模块，这就是研发 Initial 的 Backlog 。
Story 可以是粗颗粒度的，称为“史诗故事”，有助于后期的分解移动
User Story
3.Backlog 的层级结构
我推荐将相关 Story 归类于“主题”这样的层级结构，主题是产品功能的占位符，这样有助于优先级的排序和信息的检索。每个主题都有2～5个粗颗粒度的 Story。
比如对于一个手机的主题有邮件、日历、通话、备忘录。那产品 Backlog 示例可以描述为以下：
主题 邮件
颗粒度 Story 创建邮件
详细的 Story 作为一名企业用户 ，
我希望可以填写邮件主题
工作量 1
按优先级对产品 Backlog 排序
团队成员一起对 产品 Backlog 排序有助于引导团队工作，是团队专注。如果 Story 已经比较多了，可以对主题先进行排序。下面就来降下影响排序的几个因素：价值、知识、不确定性和风险、可发布性、依赖性。
1. 价值
简介，产品上市必不可少，那这个需求就是有价值的。PO 要经常问自己“如果没有这个需求，产品是否还能达到预期效果“。如果没有，那就果断剔除此需求。也不要总纠结于新需求，对现有需求的复查可以帮助我们涌现替选更优项。
2. 知识、不确定性和风险
对产品创新来说，风险是基本要素。不确定性越高，风险越高。而引发不确定性的原因是知识的匮乏。三者有密不可分的关系。
因此，具有不确定性和风险的项目享有高优先级。这样做是可以加速引入新的知识，排除不确定性从而降低风险。这也是一种风险驱动方式，可以使失败尽早降临，让团队仍有机会做出选择。
不要将失败看作坏消息，应该庆幸有这样的学习和改进机会，永远记得“风险驱动，尽早失败”！
3. 可发布性
尽早频繁的发布产品增量的能力可以影响产品 Backlog 优先级的排序
4. 依赖性
这也是很多团队常问到我的一个问题，功能性需求不可避免的依赖于其他功能性或者非功能性的需求，这可能涉及到几个团队，势必会影响到优先级的排序，这样的需求必须先实施，最常见的两种解决办法就是将几个独立的需求组合为一个更大的需求或将需求分割成不同的小需求。
为接下来的 Sprint 计划会议准备好高优先级的需求条目，对其分解细化
1.选择一个Sprint 目标
Sprint 目标是对 Sprint 预期成果的概述。每个Sprint 设立一个目标有利于团队成员为一个共同目标而努力，也更容易将工作内容传达给利益相关方。
2.及时准备足够的需求
一旦选定了Sprint 目标，我们就要为下一个Sprint 及时准备足够的需求。而需要准备多少需求，这取决于团队的速率和需求的预期粒度。最好能梳理一些附加需求，以便给团队提供一些灵活性。
3. 分解需求
分解需求就是把它变得原来越小，直到它适合在一个迭代里完成，这个过程叫“渐进式需求分解”，比如，团队最初的史诗故事是“写邮件”，可以分解成颗粒度合适的用户故事，如“指定主题”、“指定收件人”和“设置重要性”。
4. 保持清晰性、可测试性和可实现性
团队成员需求达成一致，说明需求是清晰的。用户故事必须有验收标准，才能保证每个故事是可测试的 。根据谈对完成标准的定义，如果条目可以在一个Sprint 完成，就说明它是可实现的 。
Scrum Product Backlog
团队估算产品Backlog 条目规模
对产品 Backlog 需求的估点是必不可少的环节，之所以必不可少是因为它不仅可以促进优先级的排序，还是我们能追踪并预测项目的进展 。这里有两个估算 ：产品 Backlog 需求粗颗粒度的估算 ；Sprint Backlog 细颗粒度的估算，这强调用小时来表达任务大小。这里我重点说下第一种 。
这里引出一个重要概念”故事点” 。故事点是粗颗粒度的，对原始工作量和规模的相对度量 。他是相对的，具有主观性，常用”1、2、3、5、8、13、20”这样非线性排布，避免了线性排布带来的所谓”正确值”的细节讨论。所以只要团队内达成一致，对一个故事点的标准是什么达成共识即可，并且不与其他团队对比。
这里有个最佳实践”计划扑克”，它能进行有效地基于团队的估算。每个团队成员都要参与，对故事点进行有效估算，达成共识，这里不做过多介绍，之后我会写一篇专门计划扑克实践的文章给大家详细介绍 。
这里要记住三点要素：团队必须大致了解交付一个需求需要哪些具体工作；团队成员必须能判断这个需求与其他需求之间的依赖；必须对完成标准有一个定义 。
这里还要注意一点，只有参与开发的团队成员才能估算产品 Backlog，PO 和SM 不能参与或者干涉。
Priority
产品 Backlog是一个敏捷团队管理开发过程的核心，所有的活动和交付物都围绕产品 Backlog来进行。综上所示，一个完整的 产品 Backlog = 估点的用户故事+ 优先级 + 验收标准。下篇文章我会从详细的讲下如何编写用户故事，它除了更加直观的对其用户需求，也容易让团队成员更好的参与整个需求的产生过程。
网友评论