JIRA 的列表并不是 Scrum 的 Product Backlog

在开始之前需要说明，本文并不是对优秀的 JIRA 工具进行抨击；我提到它只是因为这个工具广泛流行，就像其它类似的工具（Trac，Redmine，VersionOne，Rally，…），这些工具支持他们将想要 _ 记下的内容 _ 创建成 _ 列表 _，对于 Scrum 新人来讲，容易将 _ 待办内容 _ 和真正的 Scrum Product Backlog 混淆。因此，当一个团队开始采用 Scrum 时，我们就会问：“你们有没有 Product Backlog?”所有的答案一定都是“哦，是的，我们有 JIRA/…列表！”

所以，本文讲的是在 Scrum Product Backlog 中应该有什么样的 _ 内容 _，而不是某个特别的工具。

并且作为一个例子，我们分享了一个真实的故事（过渡到大规模 Scrum—LeSS 的一部分）和把原始的 JIRA 列表提炼成 Scrum Product Backlog 的技术，在这个例子中我们将原来 JIRA 的 508 个条目减少到 23 个 Product Backlog Items。这是 20:1 的缩减。如果你们的组织也需要类似的提炼过程，并且你们并没有看到大幅度的削减，那么你们很可能对 Product Backlog 中应该有什么有所误解。

Product Backlog 应该是什么样

一个 Product Backlog 是以客户为中心的，有排序的功能列表。称之为产品待办事项（或者 PBIs）。

和普遍的误解相反，一个 Scrum Product Backlog_ 不 _ 包含‘故事’。在 Scrum 中的一个标志性的思想是它并 _ 不是 _ 关于实践的规定（例如‘故事’）。引用 _Scrum__ 指南 _ [Schwaber & Sutherland, 2013 年 7 月 /Scrum 的定义]：

_Scrum__ 并不是构建产品的一个流程或者一门技术；而是你可以使用各种流程和技术的一个框架。_Scrum__ 使你更清楚地了解产品管理和开发实践的相对有效性，从而可以对其进行改进。

并且在任何情况下，敏捷开发中的故事是通过会话了解需求的一种行为方式（故事 =“卡片，会话和确认”），本身并不是在列表里的一件 _ 事情 _。

因此，在 Scrum 中，对于需求管理以及如何在 PBIs 中表现，只要是对团队有用的，并且可以演化的各种方法都可以采用。不管如何写 PBIs，底线则是需要强调对用户有价值的东西，再一次引用 _Scrum__ 指南：_

Product Backlog__ 列出了所有的特征、功能、需求以及改进等等_…_

一个定义良好的 Product Backlog 是，保持足够的“准备好的”（小的，好理解的…）工作，这些工作是靠近列表顶部（是排序的）的部分，并且至少保持团队一个 Sprint 的工作量。尽管正确地提炼出准备好或可操作的 PBI 的周期相对是比较长的，但你可以把目标放在满足两个 Sprint 的“准备好的”PBIs 上。低优先级的 PBIs 是没有怎么提炼的并且通常都是粗粒度的，从而减少处理中和过度处理的精益浪费。

因此，即使对于大型的产品，一个好的 Product Backlog，大多数的 PBIs（除了靠近顶端的小部分的“准备好的”列表）仍然是比较模糊并且是粗粒度的。甚至对于“大的”Product Backlog 也同样有效，因为这样相对好处理。

从大的‘JIRA’列表开始，Product Backlog 的初步提炼技术。

为了更具体，这里采用了一个真实的例子来讲述将 JIRA 列表提炼成 Scrum Product Backlog。

为了方便地过滤这 508 个 JIRA Issues，我们开始的时候把他们打印出来，一页打印四个，然后把他们切割开来。这样很快地给我们了实实在在的东西，我们可以对其进行分组或者过滤，从而找到我们的 PBIs。

开始的时候，我们是 4 个人一起，只有一个人熟悉产品。为了加速学习，我们让专家指导我们。我们最初尝试从干扰项中对 product backlog 里的条目进行分类。我们采用了新技术从而可以快速地把这些选项剥离开来，由此让我们专注于那些真正的 PBIs。我们用了一个类似于亲和聚类（affinity clustering）的方法按照需要把 JIRA issues 分类到 PBI、缺陷、任务和各种其他所需的类型中。

1. 最初的一轮是让专家选一个 issue，大声地念出来，并且把它放到一个分类里边，就这样他边做工作边向我们解释了分类的原因。等我们将一小撮列表考虑好并分类后，我们有了最初的类别和比较模糊的标准，以及产品专家使用的推理过程。
2. 我们设定了 5 分钟的时间限制同时开始工作。开始的时候我们都是小心地把我们的 issues 放到某一类的旁边，而不是放到里面。等时间快到了，我们的产品专家就会审查暂时放到每一个分类边上的这些 issues。正确的分类就正式地放到分类里面，错误的分类就会大声说出来，因此我们可以了解一些在分类时的标准或者误解。
3. 然后继续重复 5 分钟的时间盒，我们会发现每一轮我们的产出会上升并且错误率会下降。最终，在大约 2 个小时之内，我们就对整个的 JIRA 列表进行了分类，保留了 23 个真正的 Product Backlog Items.

清除开发迷雾

随着类别的出现和更多的问题得以分类，我们发现了一些有趣的事情。例如，我们发现团队对一些 JIRA Issues 失去了追踪，这些 Issues 要么应该已经被关掉了，要么就是还没有被人认领。

令我们印象最深的发现是一个被标记为“创建一个 JIRA Issue！”的 JIRA issue

让这些 Issues 来引导你做分类，在我们的实例中有“需求”（真正的 PBIs）、“支持需求”（和需求相关的 Issues，但不是真正的 PBIs）、“任务”、“Fitnesse 任务”、“技术改进”、“需要调研”、“？”（纯粹废话）、还有“缺陷”（Bug）。

对于 Issues 类型的分布，我们发现大部分的 Issues 都是缺陷（Bugs）。独立的任务（可能是分到某个 Sprint 中的任务）是另一个最大的分类——但是 Sprint 的任务并不属于 Product Backlog。而其中一些 Issues 是用于对某些事物进行调研的任务，通常这些事物与一些明显的故障相关。真正的客户需求和技术改进差不多占有同样的数量，而其他的分类则更少了。

试想一下，作为 Product Owner，在找到看起来是客户需求的内容之前，必须费力地看完 50 个缺陷或者 Sprint 的任务，这会是什么感觉？然而，列表中的每个 Issues 都会有各自认为其重要的相关人，所以对于 Product Owner 来说，关注点分离是保持 Product Backlog 易于操作和令人关注的一个宝贵的技巧。

如介绍中提到的，当彻底清除这些迷雾的时候，从最初的 508 个事项就会缩减到 23 个相关的 Product Backlog Items，这些条目是以客户为中心的新的需求。

当开始转到 LeSS 时，我们做过很多这样的列表过滤研讨会，将原始列表缩减到 5% 或 10% 的情况并不少见。这就是说，仍然有很高的标准偏差。我们曾经也遇到过这样的情况，在向 LeSS 过渡的过程中，在 Scrum 之前的原始列表中有 90% 都是真正的高质量需求，因此按照原始的列表没做什么改变就添加到了新的 Product Backlog 中。

作为很大偏差的例子，我们在另一个会议中，列表（名义上的 Product Backlog）是从一个电子表格中得到的，用了这个过滤的技术以后，“正常功能”这个分类的占比相对比较高，占到了 20%，但仍然有很多干扰项。

在 Scrum 中，在哪里记录产品的缺陷？

在 Scrum 中一个常见的问题就是“在哪里记录缺陷？”在一个小规模的 Scrum 团队中，只有很少量的缺陷，把它们保存在 Product Backlog 中是一个简单且明智的解决方案，这也是 Scrum 建议的经典做法。但当我们开始转型到 LeSS 时，对于多个团队一起合作的大型产品，在采用 Scrum 之前，JIRA 列表中就已经创建了数年来遗留下的缺陷，这种情况下，再把他们记录在 Product Backlog 中就站不住脚了，因为他们实在是太多了。

在我们描述的案例研究中，我们发现 508 个 Issue 中超过一半都是缺陷。因此这样的例子是具有普遍意义的，我们可替代的解决方案就是在 JIRA 中保留这些缺陷记录。

在哪里记录技术改进或工程任务？

和缺陷问题一样，另一个在 Scrum 中常见的问题是“在哪里记录技术改进和工程任务？”对于一个开发只有几个改进项的小型产品、并且有着一名经验丰富的 Product Owner 的 Scrum 团队而言，把它们保存在 Product Backlog 中是个合理的选择。

而上下文是关键 ：一样地，和处理缺陷情况类似，当（1）你在大规模化 Scrum 团队中，原来的‘JIRA’列表中有“成百的”各式各样的改进内容，从而淹没了小部分的客户需求。并且（2）当一个来自业务端的新 Product Owner 加入进来时，他对“技术的问题”细节不感兴趣，只是勉强地担任着这个角色，并且害怕承担传统的 IT 项目经理所期望的那样去解决问题的责任，那么对于这个情况你必须要敏感，需要制定一个有吸引力的 Product Backlog，包含了业务端新 Product Owner 所关心的内容，并且注意在过渡的过程中不要把这些内容“扔掉”。

所以，我们的结论就是在 JIRA 中保留那个超大的技术改进和工程任务列表。

更幸福的业务端 Product Owner

要知道，转变到 Scrum，其中一个主要的变化就是让 _ 业务端 _ 的 Product Owner 参与进来。你可能不知道的是，当把 Scrum 引入到业务社区或者产品管理（Product Owner 一般都是从这里转过来的）中时，那个社区的人们经常私下里（如果不公开）吐露出他们所担心的事情：

为什么我们必须要参与到所有凌乱的技术问题中？我对项目管理中的缺陷、工程任务或其他的不感兴趣。我只想专注于我们需要的业务功能 。

这种担心在过渡到大规模化敏捷 LeSS 中变得尤为严重，因为这不仅仅只是管理 4 个现存的缺陷和工程任务，而是 304 个！把这些所有的“干扰”暴露给潜在的 Product Owner，对很多 Product Owner 来说都是非常懊恼的。

所以我们想把这些干扰信号分开，介绍给他们有吸引力的、干净的 Product Backlog，这包括他们真正关心的（新功能），而没有任何需要让他们考虑的、就像传统的项目经理那样不得不管理的、他们不感兴趣的大量的技术问题。

试想一下，如果新的业务端的 Product Owner 发现，不是让他管理 508 个问题列表，而是关注 23 个 _ 与他们相关 _ 的小型条目时，那会是多么高兴。

管理成百上千的悬而未决的遗留缺陷或者工程的任务，对刚刚采取大规模敏捷方法（LeSS），并且是新的业务端的 Product Owner 来说是一个很严重的问题，但这个超过了这篇文章的范畴。请关注即将发表的文章“在大规模敏捷（LeSS）中处理缺陷和技术改进”。

简单的工具

继续谈论这个话题，这是一个对新上任的，工作紧张的业务端 Product Owner 有吸引力的话题……

他们已经知道并熟悉使用什么样的工具？也许不是 JIRA/Trac/…但很可能是一个电子表格（最近，也可能是一个 Google Doc 的表格）。它是作为 Scrum Product Backlog 所推荐的经典工具。因此可以考虑使用电子表格，它让你在实现中继续保持简单，并且让新的产品负责人只做简单的改变。我们所看到 LeSS 的实施者中，包括数以百计的人和多个网站都采用了一个简单的电子表格来作为他们的新的 Product Backlog，并且卓有成效。我们对那些宣称需要比电子表格和 Wiki 更复杂的工具的这一说法则抱有怀疑态度，即使是在大规模的例子中。

甚至可以更加简单！……有的 Product Owner 甚至把每一个 PBI 作为一张卡片粘在墙上，并且用那样的方式进行管理。

这样做是为了让 Product Backlog 保持干净——尤其是对于那些搭配了新的业务端 Product Owner 的大规模敏捷转型的案例。请务必在 Product Backlog 中保持条目的 _ 客户价值 _ 和 _ 可理解性 _。

关于作者

Craig Larman 是 _Large-Scale Scrum (LeSS)_ 的共同创始人 (与 Bas Vodde 一起)，同时也是一位关注企业实施和用 LeSS 进行超大型产品开发的组织设计顾问，除了成为早期的 Certified Scrum Trainer 之一，从 2004 年开始，他还帮助许多集团进行 LeSS 实施，例如 J.P 摩根、爱立信、UBS、施乐、bwin.party、BML、ION Trading、Valtech India 等。他是即将出版的新书《Large-Scale Scrum: More with LeSS》、以及另外两本已出版的 LeSS 书籍《精益和敏捷开发大型应用实战》和《精益和敏捷开发大型应用指南》的联合作者（都是与 Bas Vodde 一起）

Tim Born是 JPMorgan 的一名敏捷教练，帮助在大规模环境下实施敏捷。他之前在 Bell 实验室，为阿尔卡特朗讯电子产品部门实施大规模敏捷。在转成为敏捷教练之前，作为早期的 Scrum 经验，他曾是多个研发团队的一员、Scrum Master 和（伪）Product Owner。

查看英文原文： http://www.infoq.com/articles/jira-list-not-backlog

感谢赵震一对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。