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