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

高效制定并使用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）：产品负责人评出一个数值