Product Backlog：终极任务清单

健康的Product Backlog就像一个健康的人那样：整洁有序、组织合理、公开透明。
一个按照优先级顺序排好的敏捷Backlog不只可以简化发版和迭代计划，还可以对团队计划去作的全部工做进行细致规划——包括客户根本不会关注的内部工做。尤为是当利益相关者和其余团队对团队提出额外的工做需求时，Backlog可以帮助他们设按期望指标，同时还可以使工程时间具有价值，产出实际可交付的成果。

什么是Product Backlog？

Product Backlog是开发团队根据路线图及需求制定的按优先级排列的列表。其中，最重要的项目显示在Product Backlog的顶部，确保团队知道这就是要先交付的成果。所以，开发团队不是按照Product Owner规定的节奏开展工做，Product Owner也不会是开发团队完成工做的驱动者。相反，开发团队根据Product Backlog中的顺序推动工做，经过看板的持续改善或scrum的迭代来完成这些项目。

专家提示：将全部工做内容存储在同一个任务跟踪器中——不要使用多个系统来管理bug、需求和研发工做项。若是是要求开发团队完成的工做，就请将其保存在单个列表中。

以两个“R”为出发点

团队的路线图和需求为Product Backlog奠基了基础。路线图计划能够拆分为几个史诗（epic），每一个史诗（epic）都包含几个需求和用户故事。 让咱们来看看一个名为Teams in Space的虚构产品的路线图。

 

 

因为Teams in Space网站是路线图中的第一个任务，咱们但愿将这一任务分解为下面三个不一样的开发史诗（epic）（这里以绿色、蓝色和蓝绿色显示）和每一个史诗（epic）中各自不一样的用户故事。

 

 

而后，Product Owner将每一个用户故事的需求，整合到开发团队的单个列表中。Product Owner能够先提供单个完整的史诗（epic）（左图）。或者，若是预订折扣航班的测试对这个系统来讲更为重要时，就须要来自几个史诗的用户故事（右图）。 下面是两个例子：

 

 

哪些因素可能会影响Product Owner的优先级排序？

• 客户优先权
• 紧急反馈
• 相对实施难度
• 工做项之间的关联关系（如：若是先作完A，B会更容易）

虽然肯定Product Backlog的优先级顺序是Product Owner的任务，但绝对不该该在封闭的状况下完成。实际上Product Owner会经过收集来自客户、设计人员和开发团队的意见和反馈，来优化每一个人的工做量和所需交付的产品。

确保 Backlog处于健康状态

Product Backlog一旦建立，很是重要的一点就是要经过按期维护来确保它可以与开发项目的总体节奏保持一致。Product Owner在每次迭代规划会议前，都应该评审backlog，以确保优先级顺序正确无误，且上一次迭代的反馈已经被整合到本次迭代中。敏捷圈一般将Product Backlog的按期审查称为“Backlog修饰”。
若是Product Backlog的规模变大，Product Owner就须要按照短时间和长期项目，将backlog进行分组。贴标签前，短时间项目须要完善细节。这须要与设计和研发一块儿协做制定完整的用户故事、估算开发时间。较长期的项目不须要特别清晰具体，但最好能让开发团队作一个粗略的估计来判断项目的优先级。这里的关键词是“粗略”——也就是说团队彻底理解并开始着手作长期项目后，全部的估算都有可能发生改变。
Backlog做为链接Product Owner和开发团队之间的桥梁。若是是因为客户反馈、精炼估算和新需求出现等缘由，Product Owner能够随时从新变动backlog的优先级。可是，一旦进入开发阶段，尽可能将更改的机率降到最低，由于这样会打乱开发团队的节奏并影响工做的聚焦点、流程和士气。

专家提示：一旦backlog超出了团队的长期能力，能够尝试关闭团队几乎没法达成的任务。在团队的任务跟踪器中，用特别的表述来给这些任务作标记，如“超出范围”等，以便用于稍后研究。

须要注意的很是规现象:

• Product Owner在项目一开始就对backlog进行了优先级排序，而且在开发人员和利益相关者提供反馈意见时也没有对其进行调整。
• 开发团队将backlog中的事项限制为面向客户的项目。
• Backlog存储在本地，不常常共享，致使感兴趣的各方没法获取更新后的内容。

Product Backlog如何让团队保持敏捷？

经验丰富的Product Owner会严格修改其项目的Product Backlog，使其成为可靠且可共享的工做大纲。
Backlog鼓励可以让项目变得更健康的讨论和决策——由于并非每项任务均可以排在第一位。
利益相关者能够质疑既定优先级，这是一个很好的作法。围绕优先事项进行讨论可以确保每一个人的优先事项保持一致。这些讨论能够促进团队优先级一致性的文化，确保项目中的每一个成员都有优先级一致的思惟。
Product Backlog同时也是迭代规划的基础。全部工做项都应包含在backlog中：用户故事、bug、设计变动、技术债、用户提出的需求、回顾中的操做项等。这样作能够确保每一个迭代的每一个人的工做项都包含在整个讨论中。而后，在彻底知晓须要完成的全部事项的状况下，团队成员能够在迭代开始前与Product Owner一块儿权衡这次迭代的工做项。

专家提示：Product Owner决定了backlog中工做项的优先级，而开发团队则经过backlog来决定团队开发速度。而对于但愿将工做“推”给团队的新Product Owner而言，这多是一种难以平衡的关系。

 

文章来源：Worktile敏捷博客

欢迎访问交流更多关于技术及协做的问题。

文章转载请注明出处。