Backlog 饱受质疑已经很长一段时间了。 Mary Poppendieck 认为:如果产品 backlog 不能满足预先的需要,人们就应该抛弃它。 Jeff Patton 提出了类似的观点,认为扁平的 backlog 不能完整传递系统的整体印象。他建议转而使用故事地图。为了让backlog 更有意义,Serge Beaumont 进一步提出了一种有趣的方式来切分backlog ,将其映射到一个流之中,让backlog 的存在变得更有价值。
Serge 认为:由产品负责人从“新建”状态的故事中选出一些,并将它们置于“准备完成”状态,这些工作就构成了 完成准备的“流” ,这样团队就能针对这些故事开展工作,让它们向“完成”状态过渡。
Serge 还提到可以把 backlog 切分为如下 4 个区域,以保证其一致性。
- 目前处于 Sprint 中的条目
- 处于“准备完成”状态的条目
- “准备中”,包括打算使其进入“准备完成”状态的条目
- 剩余处于“新建”状态的工作
“新建”和“准备完成”状态的条目都是排列过优先级的,而“准备中”和“处于 Spring 中”的条目都是在制品。
- 优先级排列完成的缓冲区:新建——产品负责人还没有开始考虑这些条目。这里非常适合对待完成工作条目进行分类,同时去除那些几乎没有任何附加价值的条目。该列表的排序需要基于业务经验、利益评估、业务紧急程度等因素。
- 在制品:准备中——这是核心列表,产品负责人会花费很多时间来让一个工作条目进入“准备完成”状态。 Serge 认为:在这个阶段,产品负责人可能需要根据自身的具体情况加入其它人员来辅助工作。该部分会反映产品负责人处理工作的速度。产品负责人要每个 backlog 条目提出问题,并征求答案,以求进一步精化 backlog 条目,从而使其进入“准备完成”状态。
- 优先级排列完成的缓冲区:准备完成——“准备完成”缓冲区需要有一个排列好优先级的列表,其中包括大概 1.5 到 2 个迭代的工作。如果团队在一个迭代中提前完成任务,就可以从该列表中选取更多工作条目。Serge 提到:如果其中包含多于 2 个迭代的工作条目,这就会造成浪费。
- 在制品:处于 Sprint 中——这些 backlog 条目就是正在当前 sprint 中实现的条目。
像上面那样,将 backlog 切分为 4 个区域,就能很好地使其对应上从“新建”到“准备完成”、再到“完成”状态这样的工作流程。 这也有助于降低在任何一个区域内的库存数量,基于团队和产品负责人的工作能力,每个区域都可以“拉入”新的工作条目。
评论