《2022年Scrum敏捷开发框架规范中文版 .pdf》由会员分享，可在线阅读，更多相关《2022年Scrum敏捷开发框架规范中文版 .pdf（14页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、Scrum指南Scrum的权威指南 : 游戏规则2013年 7月由 Ken Schwaber和 Jeff Sutherland开发并维护名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 14 页 - - - - - - - - - ?2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible
2、 at http:/creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http:/creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Crea
3、tive Commons.Page | 2 目录Scrum指南的目的 . 3Scrum的定义 . 3Scrum理论 . 3透明性 . 3检视 . 4调整 . 4Scrum团队 . 4产品负责人 . 4开发团队 . 5Scrum Master . 5Scrum事件 . 6Sprint . 7Sprint计划会议 . 8每日 Scrum 站会 . 9Sprint评审会议 . 9Sprint回顾会议 . 10Scrum工件 . 11产品待办列表. 11Sprint待办列表 . 12增量 . 12工件的透明性 . 12“完成”的定义 . 13结束语 . 13致谢 . 13人们 . 14历史 . 14翻
4、译 . 14名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 14 页 - - - - - - - - - ?2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http:/creativecommons.org/licenses/by-sa/4.0/legalcode and
5、 also described in summary form at http:/creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.Page | 3 Scrum指南的目的Scrum是用于开发和支持复杂产品的框架。这份指南包含了Sc
6、rum的定义，其中包括Scrum的角色、事件、工件，以及把它们组织到一起的规则。Ken Schwaber 和 Jeff Sutherland创造了 Scrum，Scrum指南也由他们撰写提供。他们是Scrum指南的后盾。Scrum的定义Scrum: Scrum 是一个框架，在这个框架中人们可以解决复杂的自适应问题，同时也能高效并有创造性地交付尽可能高价值的产品。Scrum是：轻量级的容易理解的难以精通的自上世纪 90 年代初期以来， Scrum就已经应用于管理复杂产品的开发。Scrum 不是开发产品的一种流程或一项技术，而是一个框架，在这个框架里可以应用各种流程和技术。Scrum能使产品管理和
7、开发实践的相对功效（relative efficacy）显现出来，以便进行改进。Scrum框架由 Scrum团队及其相关的角色、事件、工件和规则组成。框架中的每个模块都有其特定的目的，对Scrum的成功实施和运用都至关重要。Scrum的规则把事件、角色和工件组织在一起，管理着它们之间的关系和交互。Scrum的规则会贯穿这份文档。实施 Scrum的方案根据情况不同而不同，在这里不作介绍。Scrum理论Scrum基于经验型流程控制理论，或者称为经验主义。经验主义主张知识源于经验，而决策基于已知的事物。Scrum采用迭代增量式的方法来优化可预测性和管理风险。透明性、检视、调整是经验型流程的三大支柱，
8、支撑起每个经验型控制流程的实施。透明性流程中的关键环节必须为那些对产出负责的人可见。要拥有透明性，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事情有统一的理解。例如：名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 14 页 - - - - - - - - - ?2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of
9、 Creative Commons, accessible at http:/creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http:/creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you acknowledge and agree that you have read and agree to be bound by the terms of the Attributio
10、n Share-Alike license of Creative Commons.Page | 4 所有参与者谈及流程的时候都必须使用统一的术语负责完成工作和验收工作的人必须对“完成”有一致的定义。检视Scrum的使用者必须经常检视Scrum 的工件和完成Sprint目标的进度，以发现不必要的偏差。检视不应该过于频繁而阻碍了工作本身。当熟练的检视者认真履行检视工作时，效果最佳。调整如果检视者发现流程中的一个或多个方面背离了可接受的标准，并且将会导致产品不合格时，就必须对流程本身或者流程化的内容进行调整。调整工作必须尽快实施以最小化进一步的偏差。Scrum指定了进行检视和调整的4个正式事件，将
11、在“Scrum 事件”一节中详细描述：Sprint计划会议每日 Scrum站会Sprint评审会议Sprint回顾会议Scrum团队Scrum团队由产品负责人、开发团队和Scrum Master 组成。 Scrum 团队是跨职能的自组织团队。自组织团队自己选择如何最好地完成工作，而不是由团队外的人指导。跨职能团队拥有完成工作所需要的全部技能，不需要依赖团队以外的人。这种团队模式的目的是最大限度地优化灵活度、创造力和生产效率。Scrum团队迭代增量式地交付产品，最大化获得反馈的机会。增量式地交付“完成”的产品保证了可工作产品的潜在可用版本总是存在。产品负责人产品负责人负责最大化产品以及开发团队工
12、作的价值。实现这一点的方式会随着组织、 Scrum团队以及单个团队成员的不同而不同。产品负责人是管理产品待办列表的唯一责任人。产品待办列表的管理包括：清晰地表达 产品待办列表 项对产品待 办列表项进行排序，最好地实现目标和使命优化开发团队 所执行工作的价 值名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 14 页 - - - - - - - - - ?2014 Scrum.Org and ScrumInc. Offered for license under the At
13、tribution Share-Alike license of Creative Commons, accessible at http:/creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http:/creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you acknowledge and agree that you have read and agree to be boun
14、d by the terms of the Attribution Share-Alike license of Creative Commons.Page | 5 确保产品待 办列表对所有人可 见、透明、清晰，并且显示 Scrum团队 的下一步工作确保开 发团队对产 品待 办列表项有足够的理解产品负责人可以亲自完成上述工作，也可以让开发团队来完成。然而，产品负责人是负最终责任的人。产品负责人是一个人，而不是一个委员会。产品负责人可能会通过产品待办事项列表展现一个委员会的需求，但要想改变某项的优先级必须先经过产品负责人。为保证产品负责人的工作顺利进行，组织中的所有人员都必须尊重他的决定。产品负
15、责人所作的决定通过产品待办列表的内容和排序来表达。任何人都不得要求开发团队按照另一套需求开展工作，开发团队也不允许听从任何其他人的指令。开发团队开发团队包含了各种专业人员，负责在每个Sprint结束时交付潜在可发布并且“完成”的产品增量。只有开发团队的成员才能开发增量。开发团队由组织组建并授权，团队自己组织和管理他们的工作。由此产生的正面效应能最大化开发团队的整体效率和有效性。开发团队有以下几个特点：他们是自 组织的，没有人（即使是Scrum Master 都不可以）告 诉开发团队 如何把产品待办事项列表变成潜在可 发布的功能。开发团队 是跨职能的， 团队作为一个整体， 拥有开发产 品增量所需
16、要的全部技能。Scrum不认可开 发团队 成员的头衔，无 论承担哪种工作他 们都叫做开 发人员。此规则无一例外。Scrum不认可开 发团队 中的所 谓“子 团队”，无 论是测试还 是业务分析的成 员都不能划分 为“子团队”。此 规则 无一例外。开发团队 中的每个成 员可以有特 长和专注领域，但是 责任属于整个开 发团队 。开发团队的规模开发团队最佳规模是：足够小以保持敏捷性，足够大以完成重要的工作。少于3 人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大。过小的团队在Sprint中可能会受到技能的约束，无法交付可发布的产品增量。大于9 人的团队需要过多的协调沟通工作。过大的团队会
17、产生太多复杂性，不便于经验过程管理。产品负责人和Scrum Master 的角色不包含在此数字中，除非他们也参与执行Sprint代表事项列表中的工作。Scrum Master 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 14 页 - - - - - - - - - ?2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
18、 Commons, accessible at http:/creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http:/creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-A
19、like license of Creative Commons.Page | 6 Scrum Master 负责确保所有人都能正确地理解并实施Scrum。因此， Scrum Master 要确保 Scrum团队遵循 Scrum 的理论、实践和规则。Scrum Master 是 Scrum团队中的服务型领导。Scrum Master 帮助 Scrum 团队外的人员了解他们如何与Scrum团队交互是有益的，通过改变他们与Scrum团队的互动方式来最大化 Scrum团队所创造的价值。Scrum Master 服务于产品负责人Scrum Master 以各种方式服务于产品负责人，包括：找到有效管理产
20、品待办列表的技巧帮助 Scrum团队理解“清晰准确的产品待办列表项”的重要性在经验主义的环境中理解长期的产品规划确保产品负责人懂得如何安排产品待办列表项来最大化价值理解并实践敏捷按要求或需要引导Scrum事件Scrum Master 服务于开发团队Scrum Master 以各种方式服务于开发团队，包括：在自组织和跨职能方面给予团队指导协助开发团队开发高价值的产品移除开发团队工作中的障碍按要求或需要引导Scrum事件在 Scrum 还未被完全采纳和理解的组织环境下指导开发团队Scrum Master 服务于组织Scrum Master 以各种方式服务于组织，包括：带领并指导组织采用Scrum
21、在组织范围内计划Scrum的实施帮助员工及相关干系人理解并实施Scrum和经验型产品开发发起能够提升Scrum团队生产效率的改变与其他 Scrum Master 一起工作，增加组织中Scrum实施的有效性Scrum事件Scrum中指定了一些常规性事件，以减少Scrum 之外的会议。 Scrum中的事件是有时间盒限定的，也就是说每个事件都有时间限制的。一旦Sprint开始，它的周期也就固定下来了，不能缩短或者延长。而其他事件则可以在该事件的目标达成以后立即终止，这样就确保了在这些事件上花费的时间不会影响项目的进度。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - -
22、- - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 14 页 - - - - - - - - - ?2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http:/creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http:/creati
23、vecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.Page | 7 Sprint除了本身作为一个事件以外，还是其他所有事件的容器。Scrum中的每个事件都是进行检视和调整的机会。这些事件被特别用来确保至关重要的透明性和检视。如果Sprint不
24、能成功地包含这些事件中的任何一个，透明性就会降低，同时也丧失了进行检视和调整的机会。Sprint Sprint是 Scrum的核心，其周期为小于或者等于一个月，其产出是“完成的”、可用的、潜在可发布的产品增量。Sprint的长度在整个开发过程中保持一致。新的Sprint在上一个 Sprint完成之后立即开始。Sprint由 Sprint计划会议、每日Scrum站会、开发工作、Sprint评审会议和Sprint回顾会议构成。在 Sprint中：不能做出有害于Sprint目标的改变不能降低产品质量随着对信息掌握的增加，产品负责人和开发团队可以澄清或者重新商讨开发范围每个 Sprint都可以被视为一
25、个项目，为期不超过一个月。和普通项目一样，Sprint的目标也是完成一些事情。每个Sprint都会定义要开发什么东西，还有一份设计和灵活的计划能够指导开发过程、工作内容和最终结果。Sprint的周期被限制在一个月内。如果Sprint周期过长，对“要构建什么东西”的定义就有可能会改变，复杂度和风险也有可能会增加。Sprint通过确保至少每月一次对达成目标的进度进行检视和调整，来实现可预见性。Sprint也把风险限制在一个月的成本上。取消 Sprint Sprint可以在 Sprint时间盒结束之前取消。只有产品负责人才有取消Sprint的权力，但他做这样的决定也可能是受到相关干系人、团队或是Sc
26、rum Master 的影响。如果某个 Sprint的目标过时了，那么也许就需要取消该Sprint 。比如公司的发展方向，或是市场、技术条件等发生了改变，这些都可能导致Sprint被取消。总的来说，如果某个 Sprint对于其所在环境来说失去了价值和意义，那么它就应该被取消。然而，因为 Sprint周期都较短，所以一般来说取消Sprint的意义不大。当取消某个 Sprint时，任何做完和“完成”的产品待办列表项都需要评审。假如有些已经潜在可交付，那产品负责人就会采纳它。所有未完成的就要放回到产品待办列表中，并重新估算。花在它们身上的工作会迅速贬值，所以需要频繁地重估。名师资料总结 - - -精
27、品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 14 页 - - - - - - - - - ?2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http:/creativecommons.org/licenses/by-sa/4.0/legalcode and also described in
28、summary form at http:/creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.Page | 8 取消 Sprint会消耗资源，因为每个人都需要参加额外的Sprint计划会议来启动新的Sprint 。取消 Sprin
29、t通常会对团队造成重创，这种情况非常罕见。Sprint计划会议Sprint计划会议的目的就是要为这个Sprint的工作做计划。这份计划是由整个Scrum团队共同协作完成的。对于周期为一个月的Sprint ，计划会议的时限为8小时。对于较短的Sprint ，会议时间通常会缩短。Scrum Master 要确保会议顺利举行，并且每个参与者都明白会议的目的，同时还要教导大家遵守时间盒的规则。Sprint计划会议要解决以下两个问题：接下来的 Sprint交付的增量中要包含什么内容？要如何完成交付增量所需的工作？话题一：接下来的Sprint交付的增量中要包含什么内容? 开发团队预计这个Sprint中要开
30、发的功能。产品负责人讲解Sprint的目标以及达成该目标所需要完成的产品待办列表项。整个Scrum 团队为了更好地了解Sprint的工作进行讨论。Sprint会议的输入是：产品待办列表、最新的产品增量、开发团队在这个Sprint中预计可接受的工作量和以往的表现。开发团队自己决定选择待办列表项的数量。只有开发团队本身可以评估接下来的Sprint可以完成什么工作。在开发团队预测完这个Sprint中可交付的产品待办列表项后，Scrum团队会制定一个Sprint目标。 Sprint目标是在这个Sprint通过实现产品待办列表要达到的目的，它也为开发团队提供指引，使团队明确开发增量的目的。话题二：要如何
31、完成交付增量所需的工作? 设定了 Sprint目标并挑选出这个Sprint要完成的产品待办列表项之后，开发团队将决定如何在Sprint中把这些功能构建成“完成”的产品增量。这个Sprint中所选出的产品待办列表项以及交付它们的计划统称为Sprint待办列表。开发团队通常先由系统设计开始，设计把产品待办列表转换成可工作的产品增量所需要的工作。工作的大小或预估的工作量可能会不同。然而，在Sprint计划会议中，开发团队已经挑选出足够的工作量，并且预计他们在即将到来的Sprint中能够完成。开发团队所计划的Sprint最初几天的工作在会议结束前分解为工作量等于或少于一天的任务。开发团队自组织地领取S
32、print待办列表中的工作，领取工作在Sprint计划会议和 Sprint期间按实际情况进行。产品负责人对选定的产品待办列表项作出澄清，并协助团队权衡取舍。如果团队认为工作量过大或太小，就可以和产品负责人重新协商选中的产品待办列表项。开发团队也可以邀请其他人员参加会议，以获得技术或者领域知识方面的建议。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 14 页 - - - - - - - - - ?2014 Scrum.Org and ScrumInc. Offered f
33、or license under the Attribution Share-Alike license of Creative Commons, accessible at http:/creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http:/creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you acknowledge and agree that you have re
34、ad and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.Page | 9 Sprint计划会议结束时，开发团队应该能够向产品负责人和Scrum Master 解释他们将如何以自组织团队的形式完成Sprint目标并开发期望的产品增量。Sprint目标Sprint目标是在当前Sprint通过实现产品待办列表要达到的目的，它为开发团队提供指引，使团队明确构建增量的目的，其在Sprint计划会议中确定。Sprint目标为开发团队在 Sprint中所实现的功能留有一定
35、的弹性。Sprint目标可以是为唯一功能服务的产品待办列表项的集合，也可以是能够促使开发团队向着同一目标前进的其他工作，而不应该是孤立的工作。开发团队必须在工作中时刻谨记Sprint目标。为了达成目标，需要实现相应的功能和实施所需的技术。如果所需的工作和预期的不同，开发团队需要与产品负责人协商调整Sprint待办列表的范围。每日 Scrum站会每日 Scrum站会是以 15 分钟为限的事件，开发团队成员在这里分享各自的工作情况，并为接下来的24 小时制定计划。这需要检视上个每日站会以来的工作和预测下个每日站会之前所能完成的工作。每日站会在同一时间同一地点进行来降低复杂度。会议上，每个开发团队成
36、员都需要说明：昨天我为开发团队达成Sprint目标做了什么今天我准备如何帮助团队达成Sprint目标有什么事情阻碍了我帮助团队达成Sprint目标开发团队用每日站会来评估完成Sprint目标的进度，并评估完成Sprint待办列表的进度趋势。每日站会优化开发团队达成Sprint目标的可能性。每天，开发团队应该知道如何以自组织的形式协同工作以达成Sprint的目标，并在Sprint结束时开发出预期中的增量。整个开发团队或者部分团队成员经常在每日站会后聚集到一起进行更详细的讨论，或者为 Sprint中剩余的工作做调整或重新计划。Scrum Master 确保开发团队每日站会如期举行，开发团队自己则负
37、责召开会议。Scrum Master 指导团队把会议控制在15 分钟内。Scrum Master 强制执行每日站会的规则只有开发团队的成员才能参加。每日站会可以增强交流沟通、省略其他会议、确定开发过程中需要移除的障碍、强调和提倡快速决策、提高每个成员对项目的认知程度。这是进行检视和调整的关键会议。Sprint评审会议名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 9 页，共 14 页 - - - - - - - - - ?2014 Scrum.Org and ScrumInc. Of
38、fered for license under the Attribution Share-Alike license of Creative Commons, accessible at http:/creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http:/creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you acknowledge and agree that you
39、have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.Page | 10 S print评审会议在 Sprint结束时举行，用以检视所交付的产品增量并按需调整产品待办事项列表。在Sprint评审会议中， Scrum团队和相关干系人讨论Sprint中完成的工作。然后，根据完成情况和Sprint期间产品待办列表的变化，与参会人员讨论接下来可能要做的事情来优化价值。这是一个非正式会议，而不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。
40、对于周期为一个月的Sprint ，评审会议的限时为4小时。对于时间少于一个月的Sprint来说，会议的长度会有所缩短。Scrum Master 要确保会议顺利举行，并且每个参与者都明白会议的目的，同时还要教导大家遵守时间盒的规则。Sprint评审会议包含以下内容：产品负责人邀请Scrum 团队以及相关干系人参加会议产品负责人说明哪些工作“完成”了，哪些工作没有“完成”开发团队讨论在Sprint中哪些工作进展顺利、遇到了什么问题、问题是如何解决的开发团队演示完成的工作并解答关于所交付增量的问题产品负责人描述当前产品待办列表的完成情况，并根据进度推测可能的完成日期（如果有需要的话）参会的所有人就下
41、一步的工作进行探讨，这样，Sprint评审会议就能为接下来的Sprint计划会议提供有价 值的信息。评审市场或者潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变为下个产品版本的发布评审时间表、预算、潜在功能和市场Sprint评审会议的结果是一份修订的产品待办列表，确定很可能进入下个Sprint的产品待办列表项。也有可能为了迎接新机遇而全局调整产品待办列表。Sprint回顾会议Sprint回顾会议是 Scrum团队检视自身并创建下个Sprint改进计划的机会。Sprint回顾会议发生在Sprint评审会议结束之后，下个Sprint的计划会议之前。对于长度为一个月的Sprint ，会议限
42、时为3 小时。对于较短的Sprint ，会议时间通常会缩短。 Scrum Master 要确保会议顺利举行，并且每个参与者都明白会议的目的，同时还要教导大家遵守时间盒的规则。Scrum Master 作为 Scrum流程的监督者，也需要作为团队的一员参加该会议。Sprint回顾会议的目的是：对前一个 Sprint周期中的人、关系、过程和工具进行检视找出做得好的和潜在需要改进的主要方面，并进行排序制定改进 Scrum团队工作方式的计划名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 10
43、 页，共 14 页 - - - - - - - - - ?2014 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http:/creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http:/creativecommons.org/licenses/by-sa/4.0/. By ut
44、ilizing this Scrum Guide you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.Page | 11 Scrum Master 鼓励团队在Scrum的流程框架内改进开发流程和实践，使得他们能在下个 Sprint中更高效更愉快。在每个Sprint回顾会议中， Scrum 团队通过适当调整“完成”的定义的方式来计划提高产品质量。在 Sprint回顾会议结束
45、时，Scrum团队应该明确接下来的Sprint中需要实施的改进。在下一个Sprint中实施这些改进是基于Scrum团队对自己的检视而做出的调整。虽然改进可以在任何时间执行，Sprint回顾会议提供了一个专注于检视和调整的正式机会。Scrum工件Scrum的工件以不同的方式表现工作任务和价值，可以用来提供透明性以及检视和调整的机会。 Scrum 中的工件就是为了最大化关键信息的透明性，因此每个人都需要有相同的理解。产品待办列表产品待办列表是一个有序的列表，其中包含产品需要的一切可能的东西，也是产品需求变动的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。产品待办列表永远是不完整的，
46、最早的列表只列举出最初所知的以及理解最透彻的需求。产品待办列表根据产品及其应用环境的改变而演进。待办列表是动态的，需要持续更新以反映出产品需要什么来保持其合理、有竞争力以及有用。只要产品存在，产品待办列表就存在。产品待办列表列出了所有的特性、功能、需求、改进和修复等对未来要发布的产品进行的改变。产品待办列表项包含描述、次序、估算和价值。随着产品的使用、价值的获取以及获得市场的反馈，产品待办列表变成了更大、更详尽的列表。因为需求永远不会停止改变，所以产品待办列表是个不断更新的工件。业务需求、市场形势和技术的变化都会引起产品待办列表的改变。多个 Scrum团队常常会一起开发某个产品。但描述下一步产
47、品开发工作的产品待办列表只能有一个。那么这就可能需要使用能够对产品待办列表项进行分组的属性。“产品待办列表细化”指的是为列表项补充细节、估算和排序。这是一个持续不断的过程，产品负责人和开发团队协作讨论产品待办列表项的细节，并对列表项进行评审和修改。何时如何进行细化的工作是Scrum团队的决定。细化的工作通常占用开发团队不超过10% 的时间。然而，产品负责人可以根据自己的判断随时更新产品待办列表。排序越高的产品待办列表项通常比排序低的更清晰、更具体。根据更清晰的内容和更详尽的信息就能做出更准确的估算；排序越低，细节信息越少。开发团队在接下来的Sprint中将要进行开发的产品待办列表项是细化过的，
48、因此，任一列表项都能够在Sprint的时限内“完成”。我们把这些能够在Sprint中 “完成”的列表项称为“准备就绪的”（ Ready），它们将作为Sprint计划会议中的待选列表项。这种细化列表项的工作能为产品待办列表项提供足够的透明性。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 11 页，共 14 页 - - - - - - - - - ?2014 Scrum.Org and ScrumInc. Offered for license under the Attributio
49、n Share-Alike license of Creative Commons, accessible at http:/creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http:/creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide you acknowledge and agree that you have read and agree to be bound by the
50、 terms of the Attribution Share-Alike license of Creative Commons.Page | 12 开发团队负责所有的估算工作，产品负责人可以通过帮助团队更好地理解需求，并根据情况权衡取舍来影响他们的决定。但是，最终的估算是由开发团队决定的。监控实现目标的进度在任何时间，达成目标的剩余工作量是可以累计的。产品负责人至少要在每个Sprint评审会议的时候追踪剩余工作总量。产品负责人比较这个数量与之前Sprint评审时的剩余工作量，来评估在希望的时间点达成目标的进度。这个信息对所有的相关干系人都透明。各种趋势燃尽图（burn-downs ）、燃烧