高效制定并使用Scrum开发的产品Backlog

摘要：Scrum开发过程框架中，产品Backlog是产品所要具备的所有功能的总纲，是Scrum过程的核心。产品Backlog就类似于传统顺序开发模型中的需求分析，但它不需要完全的确定和细化产品的需求，也不用形成完整使用说明，它用的是另一种恰到好处的方式。本文从三个方面讨论如何高效制定并使用产品Backlog，并举一个考务系统的Scrum开发实例进行深入说明，希望可以为刚转型Scrum的传统开发团队提供参考。

关键词：Scrum 产品Backlog 用户故事

中图分类号：TP311.1 文献标识码：A 文章编号：1007-9416（2015）09-0000-00

1 敏捷开发现状

敏捷开发是一种具有快速响应需求变化能力的软件开发管理方法。2014年VersionOne对敏捷现状的调查数据显示，72%的组织已经实施敏捷超过两年，52%的调查对象正在使用敏捷管理大部分的项目，可见敏捷开发已经成为了软件开发的普遍技术。从敏捷团队采用的敏捷技术来看，Scrum（52%）、Scrum/XP混合（14%）、自由组合（9%）名列前三，成为了技术的主流。之所以是这样的结果，是Scrum的优势决定的。Scrum给出了一个完整的产品开发活动框架，同时给出了具体的产品需求管理、迭代开发任务分解以及开发、闭环等偏管理的敏捷实践活动。因此，Scrum成为了传统开发团队实践敏捷开发的第一选择，但真正尝试了才知道遇到的难题并不少。例如团队各角色的职责定位，产品Backlog的制定，系统架构的动态制定，快速响应变化的Sprint计划等。下面就高效制定并使用产品Backlog进行深入探讨。

2 高效制定并使用产品Backlog

Scrum项目中，产品Backlog就类似于传统顺序开发模式中的需求分析，只不过它用的是另一种恰到好处的方式。它记录的是项目早期收集的需求概要，只是最粗略的描述，在之后项目进行过程中将会逐步完善。产品Backlog包括所有待添加功能的列表，由产品负责人维护，并根据优先级排序。所以，产品Backlog具有很高的动态性，其中的事项会被增加或减少，而且在每个Sprint中，这些事项会因为对产品、用户等有更多了解而重新排列优先级。下面将从三个方面来讨论如何高效的制定并使用产品Backlog。

2.1 从文档到讨论

很多时候书面文档容易让人误解，且并不那么准确。例如书面文档容易让人暂停做出判断，让人不能像谈话时反复声明要表达的意思，还有不利于团队责任制。产品Backlog中，就可以采用更合理的文档来描述待办事项，例如在产品Backlog中使用用户故事。用户故事是从用户的角度对新功能的短小简单的描述，可以写在卡片或便签上，贴在墙上或摆在桌子上，来推动计划和讨论。这样就能极大的将焦点从编写需求转变到讨论它们。

2.2 不断提炼需求

传统开发模式中，不管在项目开始阶段努力工作多长时间来确认所有需要的功能，总有一些只有在系统成型后用户或开发人员才会想到的东西。这种不能提前确认的功能被称作涌现的需求。所以在Scrum的产品Backlog中，我们要接受这么一个观点，“我们不需要也不可能提前拥有一份已整理好的项目的所有细节的完美文档”。最好的方法是，根据功能要被实现的时间，采用不同精度程度的方式来规定功能需求，也就是用不断提炼需求来保持产品Backlog的动态性。提炼需求可以由以下两个个方面来完成：大型用户故事拆分为更小的需求；加入满意条件（满意条件就是简单的概要验收测试）。

2.3 改变详细说明书的书写方式

因为Scrum项目把需求收集从文档撰写转变到讨论它们，然后在项目过程中持续的提炼。所以在项目开始时，团队就面临着没有传统详细说明书的情况，导致很多刚转型Scrum团队在启动项目时有些困难。

实例：这是一个医学类高职院校定制的考务管理系统，简约需求如下：（1）为了方便广大考生报名考试，该考务管理系统能够实现网上报名。（2）该系统可以对报名信息进行网上资格审查，并能及时信息。（3）该系统能够实现自动排考。（4）考务系统能自动完成加权平均分计算、成绩投档、平行志愿录取等工作。

在第一版的产品Backlog中没有详细的列出所有任务和需求，而选择先写下它该具备的显著特性和功能，只要保证第一个Sprint可以顺利开始。然后随着Sprint周期的进行，呈现出可的产品增量，客户对该系统的直观认识随之加深，再去更改或者添加产品Backlog的任务。第一版产品Backlog（部分）如下表1所示。

表1 考务管理系统

此产品Backlog中包括这样一些字段：重要性：（Importance）：产品负责人评出一个数值，指示这个故事有多重要。分数越高越重要。初始估算（Estimate）：团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点（story point），一般大致相当于一个“理想的人天（man-day）”。如何做演示（How to demo）：它大略描述了这个故事应该如何在sprint 演示上进行规范，本质就是一个简单的测试规范。用户故事（UserStory）：几乎所有的敏捷人士都会选择用户故事来作为需求收集的技巧，它的优势在于，一般需求条目描述总是专注于功能上，而用户故事的使用使得团队更容易从整体来讨论需求。我们采用了一般的语法“作为一个……，可以……，以（以便）……”这样可以这个故事的角色、功能、价值都写出来。产品Backlog表还可以包含很多字段，比如“故事类型”、“状态”等等，但是经过实践，该表的7个字段是一种最简化，也最有效可以一直使用的字段。在产品Backlog中使用用户故事的优势十分明显，但是在实践过程中，也遇到了一些问题。例如，用户故事和Backlog上的项目不能内容前文后理，以及在这一刻的高层目标，而且无法测算功能的规模，还有不能提供一个合适的机制来考虑到未来工作的困难程度。而用例方法结合UML 用例图、活动图、序列图、状态图等生动模型来描述复杂的系统需求，在需求技术手段比用户故事要更加丰富和完善。所以在本项目中，采用一些用例方法来对产品Backlog做一些补充。

3 结语

笔者认为这些制定并使用产品Backlog的方法并不是规定死的条条框框，好的Scrum团队总是在框架内改进适合自己的方法。所以本文主要是给转型Scrum的传统开发团队提供参考。

参考文献

[1] 廖靖斌，吕梁岳，等，译.Mike Cohn. Succeeding With Agile：Software Development Using Scrum[M].北京：清华大学出版社，2010.

[2] 王敏.基于Scrum敏捷开发的软件过程管理研究[D].昆明：昆明理工大学，2010.

[3] 曾嵘.Scrum敏捷方法实践及优势分析[D].北京：北京邮电大学经济管理学院，2009.

[4] 舆涓，译.Alistair Cockburn. Agile Software Devolopment[M].北京：人民邮电出版社，2003.

收稿日期：2015-08-19

作者简介：庄旭晖（1984―），男，福建泉州人，本科，工程硕士，助教，研究方向：软件工程，网络工程；陈昱宇（1985―），男，福建泉州人，本科，软件工程在职研究生，软件设计师（中级），研究方向：软件工程，网络工程。