第六章 产品代办事项列表PBI

我是伊昂杨啊，我把自己的Scrum学习之路搬来了咱们煎饼果子铺????。

每天积累一点小知识，每天在这里一点碎碎念，顺便和你交个朋友，一起学习，一起考证，一起进步????。

1、产品代办事项列表定义：

产品代办事项列表是一个按优先顺序排列的、预期产品功能列表。产品代办事项列表是 Scrum 框架的核心工件。

1、PBI定义：

产品代办事项列表由各个待办事项组成称为PBI或简称条目。

图片来自网络（侵删）

1、详略得当(Detailed appropriately)：

马上要做的 PBI 应当放在列表顶部，工作量小，内容非常详细，可以在最近一个冲刺中实现。短时间内还不打算做的 PBI 应当在产品代办事项列表底部，工作量大，内容粗略。

图片来自网络（侵删）

2、涌现的 (Emergent)：

只要有正在开发或维护的产品，产品代办事项列表就永远不会完成或冻结。它会根据不断涌入的、具有经济价值的信息持续更新。随着时间的推移，产品代办事项列表渐渐变得有条理。在增加新条目或细化现有条目时，产品负责人必须考虑新涌现的信息，让产品代办事项列表重新保持平衡并重新排序。

3、做过估算的 （Estimated）：

每个 PBI 都有大小估算，相当于开发这个条目需要完成多少工作。估算要靠谱，但也不必过于精确。

图片来自网络（侵删）

4、排列好先顺序的( Prioritized）：

虽然产品代办事项列表是一个排列好优先顺序的 PBI列表，但不可能其中所有 PBI 都已经排好优先顺序。对接下来几个冲刺中确定要做的近期条目，排好优先顺序很有用。

图片来自网络（侵删）

1、梳理指三大重要的活动：

确立并细化 PBI（增加 PBI的细节）；对PBI 进行估算；为 PBI 排列优先顺序。

图片来自网络（侵删）

2、由谁来梳理？

梳理产品代办事项列表是一个持续不断、合作完成的活动，由产品负责人牵头，包括内外部利益干系人中的主要参与者，还包括 SerumMaster和开发团队。

图片来自网络（侵删）

梳理活动有一个最终决策者：产品负责人。

3、何时梳理？

（1）第一个时间点：最开始的梳理活动是纳入版本规划活动进行的。在产品开发过程中，产品负责人和利益干系人会面并不断执行梳理活动，频率不限，只要合理就行。

（2）第二个时间点：在与开发团队一起工作时，产品负责人在执行冲刺的过程中可能安排每周一次或每个冲刺一次的梳理活动研讨会。这样做是为了确保梳理活动能够定期执行并让团队在制定沖刺计划时能够考虑到这部分时间。同时还可以减少临时安排会议所带来的浪费

图片来自网络（侵删）

（3）第三个时间点：梳理活动也可以分摊到冲刺中。他们在每日例会后拿出一点时间来做增量的梳理活动。

（4）第四个时间点：在冲刺评审时也需要做一些梳理工作。随着每个参与者都逐步理解产品目前的状况及今后的方向，常常需要建立新的PBI、重新排列现有 PBI 的优先顺序或删除不再需要的 PBI。

简单理解就是准备好了。????

图片来自网络（侵删）

1、版本的工作流管理：

产品代办事项列表的梳理活动必须支持持续版本规划活动。

图片来自网络（侵删）

2、冲刺的工作流管理

图片来自网络（侵删）

⚠️原则：一个产品，一个产品代办事项列表，即每个产品都应当有自己单独的一个产品代办事项列表，提供对整个产品的描述并对需要完成的工作排列优先顺序。

1、大型产品，层级化列表

大多数组织在处理大型产品时，采取的方式都是建立层级式的列表。

图片来自网络（侵删）

2、多个团队，一个产品列表

设计“一个产品，一个产品代办事项列表”规则，目的是允许所有开发产品的团队都能使用同一个产品代办事项列表。让所有团队都使用同一个列表，可以让我们在整个产品的层面上充分整合和优化经济因素。

图片来自网络（侵删）

3、一个团队，多个产品

如果一个组织有多个产品，就会有多个产品代办事项列表。处理多个产品代办事项列表的最佳方式是每个产品都由一个或多个团队专职开发。

图片来自网络（侵删）