Product Backlog

历史与起源

Product Backlog 的起源可以追溯到对传统项目管理方式的反思和对更灵活、适应变化的需求。在传统的项目管理中，项目计划通常是预先制定的、刚性的，并且难以适应变化。这种刚性的计划方式在快速变化的商业环境中表现出越来越多的不足，因为它往往无法灵活应对新的需求、市场变化或技术挑战。

Jeff Sutherland 和 Ken Schwaber，Scrum 框架的创始人，于 1995 年共同发布了《Scrum Development Process》一文，其中首次引入了 Product Backlog 的概念。他们的目标是提出一种新的项目管理方法，能够更好地适应变化、提高交付价值，并使团队更加灵活和自主。

Product Backlog 的提出是为了解决传统项目管理中的一些痛点，包括：

1. 刚性计划：传统项目管理往往采用预先制定的计划，难以适应项目中的变化。
2. 需求变更困难：在传统方法中，一旦计划制定，更改需求通常是困难和昂贵的。
3. 无法应对不确定性： 传统方法对不确定性的适应能力有限，而现代商业环境充满了变化和不确定性。
4. 缺乏持续交付价值的机制：传统方法可能导致长时间才能交付实际价值，而 Scrum 旨在实现更短周期内的持续交付。

因此，Product Backlog 的引入旨在提供一种更灵活、适应变化、能够持续交付价值的方式，使团队能够更好地满足客户需求并适应不断变化的商业环境。这标志着敏捷开发和 Scrum 框架的崭新时代，为团队提供了更好的工作方式。

定义与概念

Product Backlog 是敏捷开发和 Scrum 框架中的核心概念，为团队提供了灵活性、可适应性和共同的方向。《Scrum Guide》中对于Product Backlog的定义：”Product Backlog是一个有序的、经过优先级排序的需求列表，它对于产品的未来发展方向和对所有的Scrum团队有一个共同的了解。Product Owner负责为Product Backlog的项目确定优先级。Product Backlog是动态的，需要在Scrum团队的反馈和改变中进行调整。” 以下是对Product Backlog 定义的几个关键理解：

1. 有序和经过优先级排序的需求列表： Product Backlog包含对产品的所有需求的列表，并且这些需求是按照优先级进行排序的。这意味着Product Backlog中的项根据其相对的价值和优先级排列，使团队更容易了解哪些项是最重要的。
2. 对产品未来发展方向的了解： Product Backlog不仅仅是当前需求的列表，还提供了对产品未来发展方向的视野。这有助于确保团队在规划和执行时能够考虑到长期目标和愿景。
3. 所有Scrum团队的共同了解： Product Backlog是整个Scrum团队共享的资源，所有团队成员都应该对其内容有共同的了解。这有助于确保整个团队在方向和优先级上保持一致。
4. Product Owner负责确定优先级： Product Owner是负责管理Product Backlog的角色，他们负责为每个项目确定优先级。这确保了整个团队在工作时有一个明确的方向。
5. 动态性和调整： Product Backlog是动态的，可以根据Scrum团队的反馈和改变进行调整。这强调了Scrum团队对变化的敏感性和适应性，以便更好地应对不断变化的需求和市场条件。

重要作用及预期收益

Product Backlog在Scrum框架中有着重要的作用，主要包括：

价值体现： Product Backlog在Scrum框架中的价值彰显在于其作为一个灵活的策划工具，赋予团队能力根据不断变化的需求和优先级进行有序工作。其动态性允许团队根据反馈和新的认识灵活调整，以更好地适应环境的变化。

变革适应性： Product Backlog的特性使团队能够灵活适应新的情况。通过对需求和优先级的调整，团队能够迅速响应市场和客户需求的变化，确保其工作始终与最有价值的需求相一致。

方向明确： Product Backlog不仅包括当前需求，还提供了对产品未来发展方向的明确视角。这有助于确保整个团队在开发过程中都能够保持明确的方向，避免在工作中迷失方向。

共同理解和对齐： Product Backlog作为一个共享资源，促使团队形成对产品方向和优先级的共同理解。这有助于保持团队的一致性和高效协作，确保所有成员都在同一页面上。

Product Backlog的层级及定义

在Scrum框架中，Product Backlog通常包含多个层级，具体的层级和定义可以在《Scrum Guide》中找到。以下是Product Backlog的常见层级及其定义：

1. 战略层（Strategic Themes）： 这一层级包括对整个产品或项目的高层战略目标和方向的描述。战略层帮助团队和利益相关者理解产品的长期愿景，以及为什么执行特定的产品代办项（PBI）是有意义的。
2. 愿景层（Vision Items）： 愿景层包含对产品愿景和期望结果的高级描述。这可能包括对新功能、市场需求或用户体验的宏观阐述。
3. 特性层（Features）： 特性层定义了在愿景层基础上更具体的功能，通常以用户故事或功能项的形式呈现。这一层级帮助团队理解要开发的核心功能。
4. 用户故事层（User Stories）： 用户故事层包含用户对系统的期望以及他们的需求。用户故事通常简明地描述了一个特定功能或需求，并以用户的角度进行表达。
5. 任务层（Tasks）： 在Product Backlog的较低层次，可能包含具体的任务，这些任务是为了实现用户故事或特性而必须完成的工作。任务通常更具体，包括设计、编码、测试等方面的活动。

这些层级构成了Product Backlog的多个层次，每个层级都有其独特的作用，帮助团队和利益相关者在不同的抽象级别上理解产品的需求和方向。这个层次结构有助于更好地组织和管理Product Backlog，确保团队专注于实现最大价值的功能。

Product Backlog 在大规模敏捷框架中的层级及定义

在大规模敏捷框架中，如SAFe（Scaled Agile Framework）和LeSS（Large Scale Scrum），Product Backlog被分为不同的层级，以便更好地管理复杂性和规模。以下是这些层级的一般描述：

SAFe（Scaled Agile Framework）中的层级：

1. Portfolio Backlog（投资组合待办事项）：

• 包含组织正在考虑的不同史诗（epics）。
• 主要由投资组合负责人（Portfolio Owner）管理。

2. Solution Train Backlog（解决方案待办事项）：

• 包含高层次的待办事项（capabilities和enablers），代表解决方案的各个方面。
• 由解决方案管理者（Solution Manager）进行管理。

3. ART Backlog（敏捷火车待办事项）：

• 包含代表解决方案各个方面的待办事项（features）。
• 由产品负责人（Product Owner）和敏捷教练（Scrum Master）进行管理。

4. Team Backlog（团队待办事项）：

• 包含敏捷团队正在处理的待办事项（用户故事等）。
• 由敏捷团队的产品负责人（Product Owner）进行管理。

LeSS（Large Scale Scrum）中的层级：

1. Product Backlog（产品待办事项）：

• 与基本Scrum相同，包含所有待办事项，但通常更大规模。
• 由产品负责人进行管理。

2. Requirement Area Backlog（需求区域待办事项）：

• 在大规模环境中，产品待办事项可能被组织成不同的需求区域。
• 由大型Scrum团队的产品负责人进行管理。

无论在哪种大规模敏捷框架中，这些层级的设立有助于在复杂的组织结构中更好地管理和协调不同层级的工作。

创建和维护Product Backlog

创建和维护Product Backlog是Scrum中的重要活动，涉及多个步骤和相关角色。以下是详细的流程、角色和职责：

创建Product Backlog的流程：

需求搜集：

角色： 产品负责人（Product Owner）、开发团队、利益相关者。

职责： 产品负责人负责领导需求搜集，可以通过与利益相关者交流、团队讨论、市场调研等方式收集需求。

需求整理：

角色： 产品负责人、开发团队。

职责： 产品负责人对收集到的需求进行整理和分类，确保它们清晰、具体，并能够为团队理解和实现。

优先级排序：

角色： 产品负责人。

职责： 产品负责人根据价值、风险、战略目标等标准为每个需求设置优先级。这确保了团队首先处理最有价值的工作。

估算：

角色： 开发团队。

职责： 开发团队对每个需求进行估算，以确定完成所需的时间和资源。这有助于更好地计划Sprint。

维护Product Backlog的流程：

持续搜集和更新：

角色： 产品负责人、开发团队、利益相关者。

职责： 持续搜集新的需求，并对现有需求进行更新。反馈来自团队和利益相关者。

优先级调整：

角色： 产品负责人。

职责： 根据新的信息、市场变化或团队反馈，产品负责人可能需要调整需求的优先级。

删除过时需求：

角色： 产品负责人。

职责： 定期检查Product Backlog，删除过时或不再相关的需求，保持清晰度。

反馈与透明度：

角色： 所有团队成员。

职责： 团队成员提供对需求的反馈，确保透明度。团队应该了解Product Backlog的状态和变化。

相关角色的职责：

1. 产品负责人（Product Owner）：

• 领导需求搜集和整理过程。
• 设置和调整需求的优先级。
• 确保Product Backlog与战略目标一致。

2. 开发团队：

• 参与需求的估算过程。
• 提供对需求的反馈，包括可能的实施挑战和建议。

3. Scrum Master：

• 协助团队解决在创建和维护Product Backlog过程中出现的障碍。
• 促进透明度和信息流动。

以上流程和职责的执行需要团队内外的紧密协作，确保Product Backlog能够反映团队的目标和利益相关者的需求。

管理Product Backlog常见的错误模式

管理Product Backlog时常见的错误模式有很多，以下是一些常见的例子：

1. 缺乏优先级： 如果Product Backlog没有明确的优先级，团队可能会难以确定下一步要处理的工作。缺乏明确的优先级可能导致团队在不重要的任务上花费过多时间。
2. 过度细化： 在Product Backlog中过度细化任务，将任务划分得过于具体，可能导致过度耗费时间和精力在微观层面，而忽略了整体目标。
3. 静态不变： 有些团队忽视了Product Backlog的动态性质，不进行及时的调整和更新。随着需求和项目的变化，Product Backlog也应该是动态调整的。
4. 产品负责人独断： 如果产品负责人（Product Owner）独自决定Product Backlog的内容和优先级，而没有充分征求团队的意见，可能导致团队对目标的理解不足，影响整体协作。
5. 忽视反馈： 团队应该及时收集用户和利益相关者的反馈，以调整Product Backlog。忽视这些反馈可能导致团队朝着错误的方向前进。
6. 不考虑价值： 一些团队可能只关注任务的完成，而不考虑任务的实际价值。这可能导致在重要的事项上花费过少的时间。
7. 缺乏清晰的定义： 如果Product Backlog中的任务没有清晰的定义和描述，团队可能会对任务的预期产出和目标存在误解。
8. 过度复杂化： 将Product Backlog中的任务和需求过度复杂化可能导致团队难以理解和处理。任务应该以简洁、清晰的方式表达。
9. 忽视技术债务： 不考虑和管理技术债务可能导致系统的质量下降，影响未来的开发工作。
10. 过于短期思考： 只关注短期目标，而忽略了长期战略，可能导致团队在长远视角上失衡。

团队在管理Product Backlog时需要不断优化和改进，避免上述错误，确保团队朝着正确的方向前进。

引用及参考文献：

• Sutherland, J., & Schwaber, K. (1995).  “Scrum Development Process.” OOPSLA’95 Business Object Design and Implementation Workshop.
• 《Scrum Guide》
• https://scaledagileframework.com/#
• https://less.works/less/framework?preferred_lang=zh-CN