君，已阅读到文档的结尾了呢~~
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
高效制定并使用Scrum开发的产品Backlog
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer--144.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口5886人阅读
敏捷开发管理（14）
&&&&&&& 敏捷方法指导团队将产品需求置于Product Backlog中管理，并按照优先级对每个产品需求进行必要的排列。在计划会(Planning Meeting)之前，由Product Owner从Product
Backlog中挑选迭代周期准备开发的意向表（Willing List）进行总体介绍，然后分配到Sprint研发过程中。以Scrum为代表的纯敏捷方法，认为首先不需要对需求做分析，因为需求一直在变。所以提出了Story的概念，认为需求就该是对需求的一种类似讲故事的方式来表达的，这样便于让原始客户比较清晰的对需求进行表达，同样开发和测试也会逐渐以客户的需求思维来思考自己的工作。使得大家都能在需求的层面上，进行大脑思维。
但是敏捷方法的普遍使用中，又发现了纯敏捷方法的局限性
无法支持需求驱动下完整的可追溯性。整个团队完全致力于项目的开发是基本前提。一旦开发团队的方向出现变化，会导致项目的崩溃；因为需求总在变化。
&&&&&& 实践调查发现更多大型项目的成功，依赖于通过需求工作流、需求分析、和需求可追溯性的管理，在需求层面上进行整体的项目规划和控制。敏捷过程中，仅用Product Backlog，不足以满足需求的管理。通常，一个项目的研发过程，通过3个空间来进行表达：需求空间、研发空间和QA测试空间。3个空间相互间应当是完全整合的，使得整个团队的不同职能工作能够相互协作。今天我们首先探讨需求空间！
需求空间用来做什么？
&&&&&& SpecDD模型中，用户需求，在需求空间中被录入登记。敏捷提倡客户价值导向，应当从客户价值角度描述，就是描述客户如何使用，而不是描述技术层面如何实现。我们喜欢Story的用户需求表达方式，但这不代表用户需求的管理就是杂乱、随意和无序的。产品负责人需要借助需求工作流、需求分析、和需求可追溯性的管理，进行产品需求的提炼、条目化、优先级排序等。通过需求空间，对用户需求形成细化和量化的SPEC。
&&&&&& 需求和SPEC之间常常存在多对多的关系，即一个需求可能拆分出多个SPEC，一个SPEC可能来源于多个原始的用户需求。而实际的开发任务和测试任务，又常常需要基于具体的SPEC来分解和分配。这样的话，借助于需求空间的系统化管理，项目负责人能更好的对需求相关联的产品功能、用户需求、开发任务、测试用例、产品缺陷等进行全程跟踪，实现需求可追溯性管理。
有了需求空间后，Product Backlog 是否被取代？在实践中应当如何使用？
&&&&&&&可以明确的回答，有了需求空间后，我们仍然需要Product Backlog，并且Product Backlog仍将继续扮演重要的角色。首先我们明确Product
Backlog 存放的是给开发团队用的需求，更多服务于开发团队。如何来理解这点？你可能会说，这不是废话么，给开发团队的需求当然应该放在Product Backlog里了。但实际项目进展中，常常会遇到以下2个实际问题。
问题一：“需求还在设计中；或整理完毕，但还未决定让开发团队去实现；这些需求是否需要存放在Product Backlog来管理”？
回答：可以啊，就放Product Backlog来管理，通过特定字段或者标题标识加以区分就好。
评论：这样的处理办法，您依然可以使用Excel来管理产品Backlog。但随着用户需求的增加，或者当项目很庞大的时候，您势必会需要一台47寸显示器和一双鹰般锐利的眼睛来管理Product Backlog 列表:-)
&&&&&& SpecDD认为，只有当需求决定要开发的时候，才需要有分配；有了分配后，才需要放到Backlog中。否则当一个需求还在设计阶段，或者还没有决定是否需要开始实施的时候，甚至都可以对开发部门和测试部门进行隐藏。有了这样的改进，能更好的控制、管理Product Backlog列表。需求一旦分配到开发团队后，也就从Backlog中移除了。新的，设计完毕的，可供分派到开发团队的待处理需求，又从需求空间进入到 Product Backlog中。这样的改进，更能让Product Backlog实现了Scrum最早的思想；帮助项目经理从茫茫海洋中快速定位急待开发的任务。
问题二：一个需求包含的开发工作较大，Sprint 1 开始的时候，需求从Product Backlog分配出去。但是在Sprint 2中，同一个需求需要继续迭代开发，但该需求已经不存在于Product Backlog中了，该怎么办？
产品负责人：从Sprint 1将之前的需求move到Sprint 2中？
项目经理：那Sprint 1的历史工作记录不就失真和破坏了么？
产品负责人：或者在ProductBacklog建立一个相同的需求，再分配到Sprint 2中？
项目经理：那不就出现了重复的需求条目了么？
&&&&&&&显然这2种想法都不是好办法。针对这个问题，SpecDD做了现实解答。SpecDD认为，Product backlog和需求空间是相互整合的。只不过需求（Epic/Spec）并不直接从需求空间被分配到 Product Backlog或Sprint中。当产品负责人决定要实现的时候，需求以Story的形式分配到Product Backlog中。Story是需求的一次实现分配。
&&&&&& SpecDD模型认为Product Backlog中不要直接存放用户需求，否则会使得Backlog中的任务队列越来越多，反倒影响了对于任务优先级的排列。 Backlog中的内容应该尽可能的少，因此避免直接把需求放到Backlog中。而是采用把Story和Task放到Backlog中更好。Story一旦被分配，也就从Product Backlog中移除了。一个需求，如果工作量较大，需要通过多次迭代开发，或多个团队共同协作来完成的话，那么就可以根据开发情况，生成多个Story来进行分配。您也可以把Story理解为一个指向需求的指针；通过Story，开发团队能直接查看到具体Epic/SPEC的描述信息，获得上下游需求。分配到开发团队的Story，可包含一组已分类的开发任务。所有这些关联派生的Story以及拆分的任务，在需求空间上，又全都能够在Epic/SPEC条目上进行全程跟踪和追溯管理；从而让项目负责人和管理组从需求层面上，牢牢掌控、规划项目的进度和质量。
&&&&&& 通过上面一系列的讨论，我们就会发现单纯的Product Backlog 不足以实现需求管理。通过引入需求空间，重新定位Product Backlog的作用，以及Story概念的定义等系统化地需求管理，将有助于团队决定产品功能取舍的“智慧”有效地发挥作用，且能直接从软件产品结果中进行追踪，也提高了可执行产品的交付正确性。高效、灵活地保证了可执行产品的交付，也就能让用户更早提出修改意见，从而使得项目整体保持良好的进展健康度。管理层也无需担忧由于团队人员变动和流失，而让企业找不回当初创造产品功能时所经历过的团队讨论与决定过程。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：26373次
排名：千里之外
(1)(3)(3)(1)(1)(1)(1)(1)(4)(1)(1)Product Backlog_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
Product Backlog
阅读已结束，如果下载本文需要使用5下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩6页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢Scrum常用术语介绍-Product Backlog - Stay Foolish - ITeye博客
博客分类：
Product Backlog由所有的功能特性，包括业务功能，非业务功能（技术、架构和工程实践相关），提升点以及缺陷的修复等组成。这些内容也是将来产品版本发布的主要内容。 一个完整的Backlog是一个蓝图，可以根据它来把产品改造成为我们期望的样子。 但是在Scrum中，Backlog是根据产品和产品使用环境的演化而不断演化的。所以Backlog是动态的，我们会持续的改变它去确保我们的产品是最合理的，最有竞争力的，最有价值的。 当我们去看产品的Backlog的时候，优先级是一个重要的视角，优先级越高的Backlog需要越清晰，越详细。对于优先级低的Backlog，详细程度会越低，直到几乎我们不能认为它是一个Backlog项（非常低的优先级，只相当于一个占位符，来用做提醒）。 评算(Esitimate) 对每个backlog项做估算（包括成本，复杂度，风险，功能点）。优先级越高的Backlog估算要越精确，在估算的过程中可能会导致backlog的优先顺序有可能随之发生变化（对于那些很重要，并且可以快速解决的问题可以先做）。 我们要经常做估算。 创建者(Creater) Backlog内容的来源是多样化的. 产品营销部门会分析产生产品的特性和功能点，销售也会有很多反馈可以使产品更具有竞争力或者取悦某些特殊的客户。产品的架构师或者设计人员也会提出一些技术架构方面或者工程实践方面的需求使得产品更加灵活，更具扩展性，可复用性，开发更高效等等。产品实施或者技术支持部门也会有许多产品缺陷的反馈被放入Backlog。 重要程度(Importance) 每个Backlog项都有优先级，这些backlog项按照优先次序排行队列放在Backlog列表中。在评估的过程中 我需要在“什么样的产品特性，技术架构，缺陷的修复才会给产品公司和它的客户带来带来最大的收益？ " 和"什么样的技术架构，工程方法使我们可以更快，更高质量的交付版本"之间做出抉择。不论是对内部技术环境或者外部市场，我们都需要不断筛选和评估什么是最重要的。 版本发布(Release) 规划接下来的几个版本，包括版本的目标，及可能包含的内容。（我们可能需要在发布内容，开发成本及发布周期之间做出抉择）。 产品Backlog要按照Release分组，要让开发团队的所有成员都全部的了解总体开发目标，并且确保所有的技术问题都做了充分的考虑并且放入了产品Backlog. 负责人(Product Owner) 我们需要指定一个负责人来管理Backlog。这个人的职责是管理和控制Backlog列表，对于商业产品的开发， Backlog的负责人也许会是产品经理，对于内部项目的开发Backlog的负责人有可能是项目经理或者它指派的人。这个负责人的职责是调整产品Backlog的优先级和工作量估算，同时决定哪些内容包括在Sprint中。这是一个各个相关的组织协作的过程。 优先级(Priority) 只有一个人来进行排序的工作，这个人的职责是确保达成产品的愿景，提高产品投资回报率。这个人的职位一般是产品经理或者产品营销经理。如果任何人需要改变优先级，他们必须说服这个负责人去改变。 可视化(Visualization) 产品的Backlog需要能够让开发团队，利益相关者等相关的人能够很容易的看到它的内容，状态，进展等等。 以下是引用《硝烟中的Scrum和XP-我们如何实施Scrum（Henrik Kniberg著）》 中讲述他们如何编写Product Backlog：
Product Backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。我们叫它故事（Story），有时候也叫做Backlog条目。 我们的故事包括这样一些字段：
ID——统一标识符，就是个自增长的数字而已。以防重命名故事以后找不到它们。 Name（名称）——简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由2到10个字组成。
Importance（重要性）——产品负责人评出一个数值，指示这个故事有多重要。例如10或150。分数越高越重要。 o 我一直都想避免“优先级”这个说法，因为一般说来优先级1都表示“最高”优先级，如果后来有其他更重要的东西就麻烦了。它的优先级评级应该是什么呢？优先级0？优先级-1？
Initial Estimate（初始估算）——团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点（story point），一般大致相当于一个“理想的人天（man-day）”。 o 问一下你的团队，“如果可以投入最适合的人员来完成这个故事（人数要适中，通常为2个），把你们锁到一个屋子里，有很多食物，在完全没有打扰的情况下工作，那么需要几天，才能给出一个经过测试验证，可以交付的完整实现呢？”如果答案是“把3个人关在一起，大约需要4天时间”，那么初始估算的结果就是12个故事点。 o 不需要保证这个估值绝对无误（比如两个故事点的故事就应该花两天时间），而是要保证相对的正确性（即，两个点的故事所花费的时间应该是四个点的故事所需的一半）
How to demo（如何做演示）——它大略描述了这个故事应该如何在sprint 演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果”。 o 如果你在使用TDD（测试驱动开发），那么这段描述就可以作为验收测试的伪码表示。
Product Backlog（示例）
How to demo
登录，打开存款界面，存入10欧元，转到我的账户余额界面，检查我的余额增加了10欧元。
需要UML顺序图。目前不需要考虑加密的问题。
查看自己的交易明细
登录，点击“交易”，存入一笔款项。返回交易页面，看到新的存款显示在页面上。
使用分页技术避免大规模的数据库查询。和查看用户列表的设计相似。
我们曾试过很多字段，但最后发现，只有上面提到的六个字段我们会一直使用下去。通常我们会把backlog存放在共享的Excel文档里面（是为了多个用户可以同时编辑它）。虽然正规意义上这个文档应该归产品负责人所有，但是我们并不想把其他用户排斥在外。开发人员常常要打开这个文档，弄清一些事情，或者修改估算值。基于同样原因，我们没有把这个文档放到版本控制仓库上，而是放到共享的驱动器里面。我们发现，要想保证多用户同时编辑而不会导致锁操作或是合并冲突，这是最简单的方式。但是基本上其它所有的制品都放在了版本控制仓库中。
额外的故事字段
---------------------------------------------------------------------------------------------------------------------------------有时为了便于产品负责人判断优先级别，我们也会在产品backlog中使用一些其它字段。
Track（类别）——当前故事的大致分类，例如“后台系统”或“优化”。这样产品负责人就可以很容易选出所有的“优化”条目，把它们的级别都设得比较低。类似的操作执行起来都很方便。
Components（组件）——通常在Excel文档中用“复选框”实现，例如“数据库，服务器，客户端”。团队或者产品负责人可以在这里进行标识，以明确哪些技术组件在这个故事的实现中会被包含进来。这种做法在多个Scrum团队协作的时候很有用——比如一个后台系统团队和一个客户端团队——他们很容易知道自己应当对哪些故事负责。
Requestor（请求者）——产品负责人可能需要记录是哪个客户或相关干系人最先提出了这项需求，在后续开发过程中向他提供反馈。
Bug tracking ID（Bug跟踪ID）——如果你有个bug跟踪系统，就像我们用的Jira一样，那么了解一下故事与bug之间的直接联系就会对你很有帮助。
我们如何让产品backlog停留在业务层次上
---------------------------------------------------------------------------------------------------------------------------------如果产品负责人有技术相关的背景，那他就可能添加这样一个故事：“给Events表添加索引”。他为啥要这么做？真正的潜在目标也许是“要提高在后台系统中搜索事件表单的响应速度”。到后面我们可能会发现：索引并不是带来表单速度变慢的瓶颈。也许原因与索引完全不相干。指出如何解决问题的应该是开发团队，产品负责人只需要关注业务目标。只要发现这种面向技术的故事，我一般都会问产品负责人 “但是为什么呢”这样的问题，一直问下去，直到我们发现内在的目标为止。然后再用真正的目标来改写这个故事（“提高在后台系统中搜索并生成表单的响应速度”）。最开始的技术描述只会作为一个注解存在（“为事件表添加索引可能会解决这个问题”）。
浏览: 201821 次
来自: 南京
浏览量：1897
学习了 ！Integer i = 100;
还可以，差不多就是这个意思.
相当好用。。。
你好，是这本书的英文版，名字叫&Inside the J ...