十三、产品Backlog
对需求的概要描述会在项目早期收集，但在那个时候它们只是最粗略的描述，然后在项目进行过程中逐步完善
产品Backlog包括所有待添加功能的列表，它由产品负责人维护，并根据优先级按顺序保存，它具有很高的动态性，其中的事项会被增加或减少，同时在每个Sprint中，这些事项会因为对产品、用户和团队等有更多的了解而重新排列优先级
从文档到讨论的转变
书面文档会让你暂停做出判断
有了书面文档，我们就不能像谈话时那样反复声明要表达的意思
书面文档不利于团队责任制
1、切勿良莠不分
可工作的软件胜过全面的文档
——敏捷宣言
在交付产品时，伴随它的是产出的代码和自动化的测试用例
文档应用于捕捉交谈记录使其不被忘记
2、在产品Backlog中使用用户故事
用户故事通常遵循一个简单的模板：作为一个《用户类型》，我想《某个目标》，以便于《一些原因》
用户故事可作为开发与PO的承诺：开发答应PO在他们开发该用户故事前将与PO讨论，而PO答应团队，当团队准备讨论时它保证将有时间参与
持续地提炼需求
不管我们在项目的开始阶段工作多长时间或多么努力来确认所有需要的功能，我们都不能成功，因为总有一些只有在系统成型后用户或开发人员才会想到的东西
1、涌现的需求
不能提前确认的功能被称作涌现的需求
Scrum团队承认，不管团队成员如何小心谨慎地做计划，需求都会涌现，同时涌现的需求会被看作是计划太早进行或包含太多细节导致的结果，而不会将它们当作计划的某种失败
我们最好根据功能要被实现的时间，采用不同精确程度的方式来规定功能需求，而不是一开始就为了它的完整性而苦苦挣扎
2、产品Backlog冰山
1）梳理产品Backlog
团队需要去梳理或照顾它的产品Backlog，应花每个Sprint的10%精力梳理，以便为下一个Sprint作准备
大功能被分成小的功能，并且细节会在小的功能加入Backlog后添加
如果团队认为比较靠下的事项会对它们上面的事项有影响，那么他们应花精力来理解它
3、为什么要持续地提炼需求？
1）事情会发生变化——优先级与重要程度会反复变化
2）不需要——即将开发的条目要给予足够的可见性，以便让团队看得更远，从而避免大部分问题
3）时间有限——几乎所有的项目都有时间限制，同等对待所有的需求是一种浪费
4、对用户故事的持续提炼
大型用户故事需要可以被拆分成小用户故事，从而确保在每个Sprint中实现
大故事被拆分后，需要立即废弃
一些大需求因为太多，所以它们要被拆分成稍小的大需求
通过加入满意条件来持续提炼可帮助团队，让他们知道PO对该功能的期望
学会在没有详细说明书的情况下开始
在写一份文档前，问问自己是否愿意一直更新该文档
1、通过事例说明
通过讨论和事例的组合来解释这种详细的需求，可以增加产品负责人要求的东西正是开发人员正在创建的系统的可能性
事例最理想的状态是转化为自动化测试
2、跨职能的团队能降低对文档的需求
从某个文档受益的人应该是那个写文档的人，开发编写给测试的说明书，应由测试继续维护更新
创建DEEP的产品Backlog
Backlog的几个关键属性
D详略得当——当前Sprint的用户故事，充分详细；不着急开发的要简略
E做过估算的——靠前的规划精确，靠后的估算大略
E涌现的——随着时间的推移、了解的深入，用户故事会增加、移除与重排
P排列优先级的——价值由高到低，始终根据优先级开发
不要忘记讨论
产品Backlog不在于写，而在于经常讨论
