文/明道创始人 任向晖2018年3月16日，上海万企明道软件有限公司创始人、梅花网创始人、湖畔大学一期生任向晖老师在阿里...

文/明道市场副总裁 雷明灿https://mingdao-2.wistia.com/medias/p2q7ngcwr4?...

文/明道市场副总裁 雷明灿

前言

软件开发方法一直处在不断发展过程中。在诸多方法中，敏捷开发以其能持续满足不断变化的用户需求，正在受到越来越多人的重视。从中小项目到进入大型开发项目，近几年来上升势头明显。

在软件工业界，敏捷开发已成为众多高效开发团队的制胜之道。在欧美软件企业中，有近半数企业已采用敏捷方法进行开发，敏捷开发在中国也出现了日渐普及的态势，如腾讯内部几乎所有的开发团队都在实施敏捷方法。

敏捷开发的流行绝非偶然，其最大的推动力是采用这种方法所能带来的受益。相关统计表明，敏捷开发可以将效率提高3~10倍，软件的质量也有更加可靠的保证；同时,还给团队内的每个成员提供了良好的发展机会,技术和合作水平都能得到相应提高。当然，敏捷的成功前提是其方法本身的适用性和团队对它的深入理解和合理运用。

明道本质上也是一家软件开发企业，为了提供更高质量的产品和交付速度，我们也在探索更好的软件开发模式，比如Scrum。由于在实施之前需要搞懂概念和方法论，我们无意中找到了两位Scrum创始人在他们的博客上撰写的官方指南，现在分享给大家。另外，除了阅读这篇文章，你也可以：

• 访问Scrum指南官网
• 下载《Scrum官方指南》英文版.pdf
• 下载《Scrum官方指南》中文版.pdf

另外，如果您希望阅读更高翻译质量的《Scrum官方指南》，请在文末留言，我们会帮助评估和制作。

---

Scrum指南的目的

Scrum是用于开发、交付和持续支持复杂产品的一个框架。本指南包含了Scrum的定义，其中包括Scrum的角色、事件、工件，以及把它们组织在一起的规则。KenSchwaber和JeffSutherland创造了Scrum，Scrum指南也由他们撰写并提供。总之，他们是Scrum指南的后盾。

Scrum的定义

Scrum是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付可能最高价值的产品。Scrum是：

• 轻量的
• 易于理解的
• 难以精通的

Scrum是一个框架，自上世纪90年代初以来，它就已经被应用于管理复杂产品的工作上。Scrum并不是一种过程、技术或决定性方法。倒不如说，它是一个框架，在此框架中，您可以使用各种不同的过程和技术。Scrum让您的产品管理和工作技术的相对成效更加清晰地显现出来，以便您可以持续改进产品、团队和工作环境。

Scrum框架由Scrum团队以及与之相关的角色、事件、工件和规则组成。框架中的每个部分都有其特定的目的，其对于Scrum的成功与使用是至关重要的。

Scrum的规则把角色、事件和工件组织在一起，管理它们之间的关系和交互。对于Scrum的规则描述将会贯穿全文。

使用Scrum框架的其它不同特定技巧将不在本文中描述。

 

Scrum的应用

Scrum最初是为了管理和开发产品而开发的。从上世纪90年代初开始，Scrum在全球范围内已得到了广泛应用，比如：

1. 研究与识别出可行的市场、技术和产品能力；
2. 开发产品和增强功能；
3. 产品和增强功能，频率高到一天发布多次；
4. 开发与支持云（在线、安全、按需）和其他运行环境来提供给产品使用；
5. 支持和更新产品。

Scrum已被用于开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶汽车、学校、政府、市场营销、管理组织运营，以及几乎所有我们（作为个人和群体）日常生活中所使用的一切。

随着技术、市场和环境的复杂性以及它们之间相互作用的快速增长，Scrum在处理复杂性方面的效用日益得到证实。

在迭代与增量式的知识迁移中，Scrum被证明特别有效。现在Scrum广泛用于产品、服务和大型组织管理。

Scrum的精髓在于小团队。个体团队具有高度灵活性与适应性。当单个团队、几个团队、多个团队和网络团队在开发、发布、运营和维护成千上万人的工作和工作产品时，这些优势得以持续运作。他们通过精妙的开发架构和目标发布环境来协作和互操作。

 

Scrum理论

Scrum基于经验过程控制理论，或称之为经验主义。经验主义主张知识源自实际经验以及当前已知情况下做出的决定所获得。Scrum采纳一种迭代和增量式的方法来优化对未来的预测和控制风险。

透明、检查和适应是经验过程控制的三大支柱，支撑起每一个经验过程的实施。

透明

过程中的关键环节对于那些对产出负责的人必须是显而易见的。要拥有透明，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事物有统一的理解。例如：

• 所有参与者谈及过程时都必须使用统一的术语。
• 负责完成工作和检查结果增量的人必须对“完成”的定义，有一致的理解。

检查

Scrum的使用者必须经常检查Scrum的工件和完成Sprint目标的进展，以便发现不必要的差异。检查不应该过于频繁而阻碍工作本身。当检查是由技能娴熟的检查者在工作中勤勉地执行时，效果最佳。

适应

如果检查者发现过程中的一个或多个方面偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整。调整工作必须尽快执行如此才能最小化进一步的偏离。

Scrum规定了4个正式事件，用于检查与适应上，这4个事件在Scrum事件章节中会加以描述：

• Sprint计划会议
• 每日Scrum站会
• Sprint评审会议
• Sprint回顾会议

 

Scrum价值观

当承诺、勇气、专注、开放和尊重五大价值观为Scrum团队所践行与内化时，Scrum的透明、检查和适应三大支柱成为现实，并且在每个人之间构建信任。Scrum团队成员通过Scrum的角色、事件和工件来学习和探索这些价值观。

Scrum的成功应用取决于人们变得更为精通践行五项价值观。人们致力于实现Scrum团队的目标。Scrum团队成员有勇气去做正确的事并处理那些棘手的问题。每个人专注于Sprint工作和Scrum团队的目标。Scrum团队及其利益攸关者同意将所有工作和执行工作上的挑战进行公开。Scrum团队成员相互尊重，彼此是有能力和独立的人。

 

Scrum团队

Scrum团队由一名产品负责人、开发团队和一名ScrumMaster组成。Scrum团队是跨职能的自组织团队。自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来指导。跨职能团队拥有完成工作所需的全部技能，不需要依赖团队之外的人。Scrum团队模式仍是设计用来提供最佳的灵活性、创造力和生产力。Scrum团队（自身）已经证明，对于所有之前所述Scrum的应用以及任何复杂工作来说，它都是越来越有效的。

Scrum团队迭代增量式地交付产品，籍此最大化地获得反馈的机会。增量式交付“完成”的产品保证了一个可工作产品的潜在可用版本总是存在。

 

产品负责人

产品负责人的职责是将开发团队开发的产品价值最大化。如何实现这一点的方式会随着跨组织、Scrum团队和团队成员个体的不同而有所不同。

产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括：

• 清晰地表述产品待办列表项；
• 对产品待办列表项进行排序，使其最好地实现目标和使命；
• 优化开发团队所执行工作的价值；
• 确保产品待办列表对所有人是可见、透明和清晰的，同时显示Scrum团队下一步要做的工作；
• 确保开发团队对产品待办列表项有足够深的了解。

产品负责人可以亲自完成上述工作，或者也可以让开发团队来完成。然而无论何者，产品负责人是负最终责任的人。

产品负责人是一个人，而不是一个委员会。产品负责人可能会通过产品待办列表展现一个委员会的期望要求，但是想要改变产品待办列表项的优先级都必须经过产品负责人。

为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定。产品负责人对产品待办列表的内容和排序的决定必须是可见的。没有人可以强迫开发团队按照另一套需求开展工作。

 

开发团队

开发团队包含各种专业人员，负责在每个Sprint结束时交付潜在可发布并且“完成”的产品增量。在Sprint评审会议上，一个“完成”增量是必需的。只有开发团队成员才能创建增量。

开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。由此产生的正面效应能最大化开发团队的整体效率和效用。

开发团队具有下列特点：

• 他们是自组织的。没有人（即使是ScrumMaster）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量；
• 开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能；
• Scrum不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开发人员）。
• Scrum不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或业务分析；同时，
• 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。

 

开发团队的规模

开发团队最佳规模是足够小以保持敏捷性，同时足够大可以在Sprint内完成重要的工

作。少于3个人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大。过小的团队在Sprint中可能会遭遇到技能上的约束，进而导致开发团队无法交付潜在可发布的产品增量。超过9人的团队则需要过多的协调沟通工作。对经验过程而言，大型

开发团队会产生太多的复杂性而变得无用。产品负责人和ScrumMaster角色不包含在开发团队人数中，除非他们同时也参与执行Sprint待办列表中的工作。

 

Scrum Master

ScrumMaster负责根据Scrum指南中的定义来促进和支持Scrum。ScrumMaster通过帮助每个人理解Scrum理论、实践、规则和价值来做到这一点。

ScrumMaster对Scrum团队而言，他/她是一位服务型领导。ScrumMaster 帮助Scrum

团队之外的人了解他/她如何与Scrum团队交互是有益的，通过改变他/她们与Scrum团队的互动方式来最大化Scrum团队所创造的价值。

 

Scrum Master服务于产品负责人

• ScrumMaster以各种方式服务于产品负责人，包括：
• 确保Scrum团队中的每个人都尽可能地理解目标、范围和产品域；
• 找到有效管理产品待办列表的技巧；
• 帮助Scrum团队理解为何需要清晰且简明的产品待办列表项；
• 理解在经验主义的环境中的产品规划；
• 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
• 理解并实践敏捷性；，
• 当被请求或需要时，引导Scrum事件。

 

Scrum Master服务于开发团队

Scrum Master以各种方式服务于开发团队，包括：

• 作为教练在自组织和跨职能方面给予开发团队以指导；
• 帮助开发团队创造高价值的产品；
• 移除开发团队工作进展中的障碍；
• 按被请求或需要时，引导Scrum事件；
• 在Scrum还未完全采纳和理解的组织环境中，作为教练指导开发团队。

 

Scrum Master服务于组织

ScrumMaster以各种方式服务于组织，包括：

• 带领并作为教练指导组织采纳Scrum；
• 在组织范围内规划Scrum的实施；
• 帮助员工和利益攸关者理解并实施Scrum和经验导向的产品开发；
• 引发能够提升Scrum团队生产率的改变；
• 与其他ScrumMaster一起工作，增强组织中Scrum应用的有效性。

 

Scrum事件

Scrum使用固定的事件来产生规律性，以此来减少Scrum之外的其他会议的必要。所有事件都是有时间盒限定的，也就是说每一个事件限制在最长的时间范围内。一旦Sprint开始，它的持续时间是固定的，不能缩短或延长。而其他事件则可以在该事件的目标达成之后可以立即结束，如此确保时间被适当地使用而不会造成过程中的浪费。

Sprint除了本身作为一个事件以外，它还是其他所有事件的容器，在Scrum中的每个事件都是用来进行检查和适应的正式机会。这些事件都是被特别设计用来确保达成透明和检

视。如果Sprint不能成功地包含这些事件中的任何一个事件，导致透明化的降低，同时也会丧失进行检查与适应的机会。

 

Sprint

Sprint是Scrum的核心，其长度（持续时间）为一个月或更短的限时，这段时间内构建一个“完成”、可用的和潜在可发布的产品增量。在整个开发过程期间，Sprint的长度保持一致。前一个Sprint结束后，下一个新的Sprint紧接着立即开始。

Sprint由Sprint计划会议、每日Scrum站会、开发工作、Sprint评审会议和Sprint回顾会议构成。

在Sprint期间：

• 不能做出有害于Sprint目标的改变；
• 不能降低目标的标准；
• 随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可以加以澄清和重新协商。

每个Sprint都可以被视为一个项目，为期不超过一个月。就如同项目一样，Sprint被用于完成某些事情。每个Sprint都会有一个要构建什么的目标，还有一份设计过和灵活的计划用来指导如何做这些事、工作内容和最终产品增量。

Sprint的长度限制在一个月内。当Sprint的长度太长的话，对要构建什么的定义就有可能会改变，复杂性也有可能会增加，同时风险也有可能会增加。Sprint通过确保至少每月一次对达成目标的进度进行检查和适应，来实现可预测性。Sprint同时也把风险限制在一个月的成本上。

 

取消Sprint

Sprint可以在Sprint时间盒结束之前取消。只有产品负责人才有取消Sprint的权力，虽然他或她做这样的决定也可能受到来自利益攸关者、开发团队或是ScrumMaster的影响。

如果Sprint目标过时，那么Sprint就会被取消。比如公司的发展方向或者市场上或技术上的状况发生改变，这些变化都可能导致Sprint被取消。总的来说，如果某个Sprint对其所在环境来说失去了价值和意义，那么它就应该被取消。然而，由于Sprint的时间都很短，所以取消Sprint通常是不太合理的。

当取消某个Sprint时，任何做完和“完成”的产品待办列表项都需要评审。假如成果的任何部分具有潜在可发布的话，产品负责人通常会接受这个成果。所有未完成的产品待办列表项都会被放回到产品待办列表中，并重新估算。花在它们身上的工作会很快地贬值，所以必须经常性地重估。

取消Sprint会消耗资源，因为每个人都重新集合在另外一个Sprint计划会议来开始另一个Sprint。取消Sprint通常会对Scrum团队造成重创，这种情况非常罕见。

 

Sprint计划会议

Sprint中要做的工作在Sprint计划会议中来做计划。这份工作计划是由整个Scrum团队共同协作完成的。

Sprint计划会议是有时间盒限定的，以一个月的Sprint来说最长为8小时。对于较短的Sprint，会议时间通常会缩短。ScrumMaster要确保会议顺利举行，并且每个参会者都理解会议的目的。ScrumMaster要教导Scrum团队遵守时间盒的规则。

Sprint计划会议回答以下问题：

• 接下来的Sprint交付的增量中要包含什么内容？
• 要如何完成交付增量所需的工作？

 

话题一：这次Sprint能做什么？

开发团队预测在这次Sprint中要开发的功能。产品负责人讲解Sprint的目标以及达成该目标所需完成的产品待办列表项。整个Scrum团队协同工作来理解Sprint的工作。

Sprint会议的输入是产品待办列表、最新的产品增量、开发团队在这个Sprint中能力的预测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发团队可以评估接下来的Sprint可以完成什么工作。

在Sprint计划会议中，Scrum团队还草拟一个Sprint目标。Sprint目标是在这个Sprint通过实现产品待办列表要达到的目的，同时它也为开发团队提供指引，使得开发团队明确开发增量的目的。

 

话题二:如何完成所选的工作？

在设定了Sprint目标并选出这个Sprint要完成的产品待办列表项之后，开发团队将决定如何在Sprint中把这些功能构建成“完成”的产品增量。这个Sprint中所选出的产品待办列表项加上如何交付它们的计划称之为Sprint待办列表。

开发团队通常从设计整个系统开始，到如何将产品待办列表转换成可工作的产品增量所需要的工作。工作有不同的大小，或者不同的预估工作量。然而，在Sprint计划会议中，开发团队已经挑选出足够量的工作，以此来预估他们在即将到来的Sprint中能够完成。

在Sprint计划会议的最后，开发团队规划出在Sprint最初几天内所要做的工作，通常以一天或更少为一个单位。开发团队自组织地领取Sprint待办产品列表中的工作，领取工作在Sprint计划会议和Sprint期间按需进行。

产品负责人能够帮助解释清楚所选定的产品待办列表项，并做出权衡。如果开发团队认为工作过多或过少，他们可以与产品负责人重新协商所选的产品待办列表项。开发团队也可以邀请其他人员参加会议，以获得技术或领域知识方面的建议。

在Sprint计划会议结束时，开发团队应该能够向产品负责人和ScrumMaster解释他们将如何以自组织团队的形式完成Sprint目标并开发出预期的产品增量。

 

Sprint目标

Sprint目标是在当前Sprint通过实现产品待办列表要达到的目的。它为开发团队提供指引，使得团队明确为什么要构建增量。Sprint目标在Sprint计划会议中确定。Sprint目标为开发团队在Sprint中所实现的功能留有一定的弹性。所选定的产品待办列表项会提供

一个连贯一致的功能，也即是Sprint目标。Sprint目标可以是任何其他的连贯性来促使开发团队一起工作而不是分开独自做。

开发团队必须在工作中时刻谨记Sprint目标。为了达成Sprint目标，需要实现相应的功能和实施所需的技术。如果所需工作和预期的不同，开发团队需要与产品负责人沟通协商

Sprint待办列表的范围。

 

每日Scrum站会

每日Scrum站会是开发团队的一个时间盒限定为15分钟的事件。每日Scrum站会在Sprint的每一天都举行。在每日Scrum站会上，开发团队为接下来的24小时的工作制定计划。通过检查上次每日Scrum站会以来的工作和预测即将到来的Sprint工作来优化团队协作和效能。每日Scrum站会在同一时间同一地点举行，以便降低复杂性。

开发团队籍由每日Scrum站会来检查完成Sprint目标的进度，并检查完成Sprint待办列表的工作进度趋势。每日Scrum站会优化了开发团队达成Sprint目标的可能性。每天，开发团队应该知道如何以自组织团队来协同工作以达成Sprint目标，并在Sprint结束时开发出预期中的增量。

会议的结构由开发团队设定。只要会议专注于达成Sprint目标的进展，开发团队可以采用不同的方式进行。一些开发团队会以问题为导向来开会，有些开发团队会基于更多的讨论来开会。以下是一个可以使用的范例：

• 昨天，我为帮助开发团队达成Sprint目标做了什么？
• 今天，我为帮助开发团队达成Sprint目标准备做什么？
• 是否有任何障碍在阻碍我或开发团队达成Sprint目标？

开发团队或者开发团队成员通常会在每日Scrum站会后立即聚到一起进行更详细的讨论，或者为Sprint中剩余的工作进行调整或重新计划。

ScrumMaster确保开发团队每日站会如期举行，但开发团队自己负责召开会议。ScrumMaster教导开发团队将每日Scrum会议时间控制在15分钟内。

每日Scrum站会是开发团队的内部会议。如果有开发团队之外的人出席会议，ScrumMaster必须确保他们不会干扰会议进行。

每日Scrum站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显并促进快速地做决策、提高开发团队的认知程度。这是一个进行检查与适应的关键会议。

 

Sprint评审会议

Sprint评审会议在Sprint快结束时举行，用以检查所交付的产品增量并按需调整产品待办列表。在Sprint评审会议中，Scrum团队和利益攸关者协同讨论在这次Sprint中所完成的工作。根据完成情况和Sprint期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。

对于长度为一个月的Sprint来说，评审会议时间最长不超过4小时。对于较短的Sprint来说，会议时间通常会缩短。ScrumMaster要确保会议举行，并且每个参会者都明白会议的目的。ScrumMaster教导每位参会者遵守时间盒的规则。

Sprint评审会议包含以下内容：

• 参会者包括Scrum团队和产品负责人邀请的主要利益攸关者；
• 产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”；
• 开发团队讨论在Sprint期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的；
• 开发团队演示“完成”的工作并解答关于所交付增量的问题；
• 产品负责人讨论当前的产品待办列表的情况。他／她根据到目前为止的进度来预测可能的目标交付日期（如果有需要的话）；
• 参会的所有人就下一步的工作进行探讨，这样，Sprint评审会议就能够为接下了的Sprint计划会议提供有价值的输入信息；
• 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变；
• 为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。

Sprint评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个Sprint的产品待办列表项。产品待办列表也有可能为了迎接新的机会而进行全局性地调整。

 

Sprint回顾会议

Sprint回顾会议是Scrum团队检查自身并创建下一个Sprint改进计划的机会。

回顾会议发生在Sprint评审会议结束之后，下个Sprint计划会议之前。对于长度为一个月的Sprint来说，回顾会议时间最长不超过3小时。对于较短的Sprint来说，会议时间通常会缩短。ScrumMaster要确保会议举行，并且每个参会者都明白会议的目的。

ScrumMaster确保会议是积极的和富有成效的。ScrumMaster教导大家遵守时间盒的规则。ScrumMaster对Scrum过程负责，作为团队的一员参加该会议。

Sprint回顾会议的目的在于：

• 检查前一个Sprint中关于人、关系、过程和工具的情况如何；
• 找出并加以排序做得好的和潜在需要改进的主要方面；同时，
• 制定改进Scrum团队工作方式的计划。

ScrumMaster鼓励Scrum团队在Scrum的过程框架内改进开发过程和实践，使得他们能在下个Sprint中更高效更愉快。在每个Sprint回顾会议中，如果适用并且不与产品或

组织标准相冲突，Scrum团队计划不同的方式通过改进工作过程或调整“完成”的定义来提高产品质量。

ÔÚ Sprint回顾会议结束时，Scrum团队应该明确接下来的Sprint中需要实施的改进。在下一个Sprint中实施这些改进是基于Scrum团队对自身的检查而做出的适当调整。虽然改进可以在任何时间执行，但Sprint回顾会议提供了一个专注于检查和适应的正式机会。

 

Scrum工件

Scrum的工件以不同的方式表现工作任务和价值，可以用来提供透明以及检查和适应的机会。Scrum所定义的工件是特别地设计的，是为了给关键信息提供最大透明化，因此每个人对工件都需要有相同的理解。

产品待办列表

产品待办列表是一份涵盖产品中已知所需每项内容的有序列表，它是产品需求变动的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。

产品待办列表永远是不完整的。最早开发的产品待办列表列举最初所知的以及理解最透彻的需求。产品待办列表会随着产品及其应用环境的改变而演进。产品待办列表是动态的，需要持续更新以反映出产品需要什么来保持其适用性、竞争力和有用。如果产品存在，产品待办列表也就同样存在。

产品待办列表列出所有的特性、功能、需求、增强和修复等对未来要发布的产品进行的更新。产品待办列表项具有这些属性：描述、次序、估算和价值。产品待办列表项通常包括测试描述，将在“完成”时证明其完整性。

随着产品的使用、价值的获取和获得市场的反馈，产品待办列表会成长为更大和更详尽的列表。因为需求永不停止改变，所以产品待办列表就如一份活的工件。业务需求、市场形势或者技术的变化都会引起产品待办列表的改变。

多个Scrum团队常常会一起参与对同一产品的开发。一个产品只有一个产品待办列表用于描述下一步产品开发工作。那么这就可能需要使用能够对产品待办列表项进行分组的属性。

产品待办列表精化指的是为产品待办列表项增添细节、估算和排序的动作。这是一个持续的过程，产品负责人和开发团队协同工作在产品待办列表项的细节上。在产品待办列表精

化过程中，产品待办列表项被重新评审和修改。Scrum团队决定如何来完成精化以及何时来完成。精化的工作通常占用开发团队不超过10%的产能。然而，产品负责人或者其他人在产品负责人的斟酌下，产品待办列表项可以在任何时间来更新。

排序越高的产品待办列表项通常比排序低的更清晰同时包含更多细节。根据更清晰的内容和更详尽的细节信息就能做出更为准确的估算；同样，排序越低，则细节信息越少。产品

待办列表项中那些即将会占用开发团队下一个Sprint大部分时间的项会被加以精化，因此，任一产品待办列表项都能够在Sprint的时间盒期限内适当地“完成”。这些能够被开发团队在一个Sprint中“完成”的产品待办列表项称为“准备就绪”，它们将作为

Sprint计划会议中的待选产品列表项。产品待办列表项的足够透明程度通常要经过上述的精化活动来获得。

开发团队负责所有估算工作。产品负责人可以通过帮助开发团队更好地理解需求，并根据情况权衡取舍来影响他们，但是最终估算是由开发团队决定的。

监控目标实现的进度

在任何时刻，达成目标的剩余工作是可以累计的。产品负责人至少在每个Sprint评审会议中都必须跟踪剩余工作总量。产品负责人比较这次的剩余工作量与之前Sprint评审会

议时的剩余工作量，来评估在期望的时间点达成目标的进度。这个信息对所有的利益攸关者都是透明的。

各种不同趋势走向的实践已经被使用在预测进度方面，例如，燃尽图（burn-downs）、燃烧图（burn-ups）或者累积流图（cumulativeflows）。这些工具都被证实是有用的。然而，它们并不能用来取代经验主义的重要性。在复杂的环境中，未来将要发生的事是无法预知的。只有已经发生的事情才能用来做前瞻性的决策。

Sprint待办列表

Sprint待办列表是一组为当前Sprint选出的产品待办列表项，同时加上交付产品增量和实现Sprint目标的计划。Sprint待办列表是开发团队对于下一个产品增量所需的那些功能以及交付那些功能到“完成”的增量中所需工作的预测。

Sprint产品待办列表将开发团队用来达成Sprint目标的所有工作变得清晰可见。为了确保持续改进，它至少包括一项在前次回顾会议中确定下来的高优先级的过程改进。

Sprint产品待办列表是拥有足够细节的计划，任何进度的变化可以在每日Scrum站会中清晰地看到。开发团队在Sprint期间修改Sprint待办列表，使得Sprint待办列表在

Sprint期间涌现。涌现发生在开发团队按计划开展工作并学习到更多的关于哪些工作是达成Sprint目标所必需的工作时。

当新工作出现时，开发团队需要将其加入到Sprint待办列表中去。随着工作的执行或完成，剩余的工作量被估算并更新。当计划中的某个部分失去开发意义，就可以将其移除。

在Sprint期间，只有开发团队可以改变Sprint待办列表。Sprint待办列表是高度可见的，是对开发团队计划在当前Sprint内工作完成情况的实时反映，该列表由开发团队全权负责。

监控Sprint进度

在 Sprint的任何时间点都可以计算Sprint待办列表中所有剩余工作的总和。开发团队至少在每日Scrum站会时跟踪剩余工作的总和，预测达成Sprint目标的可能性。通过在

Sprint中不断跟踪剩余的工作量，开发团队可以管理自己的进度。

增量

增量是一个Sprint完成的所有产品待办列表项的总和，以及之前所有Sprint所产生的增量的价值总和。在Sprint的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了Scrum团队“完成”的定义的标准。增量是在Sprint结束时支持经验主义的、可检查的和已完成的产品组成部分。增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它，增量必须可用。

工件透明

Scrum依赖于透明。优化价值和控制风险的决定都是基于所获知的工件状态。当工件的状态是完全透明时，这些做出的决定才有一个坚实的基础；当工件的状态是不完全透明时，这些做出的决定就会有瑕疵，而价值也可能因此遭受损失，同时风险也可能会因此而增加。

ScrumMaster必须和产品负责人、开发团队和其他相关人员一起合作，以确保所有工件都是完全透明的。有些实践就是为应对不完全透明的状态而生的，ScrumMaster必须帮助每个人，让他们能够在遇到不透明的情况下采取最合适的实践。ScrumMaster能够通过检查工件、嗅探模式、倾听周围的声音以及观察预期和实际结果之间的差异来发现不完全透明。

ScrumMaster的职责就是和Scrum团队以及组织一起合作增加工件的透明化。这一工作通常包括学习、说服和改变。透明化不会在一夜之间发生，但是这是一条必经之路。

“完成”的定义

当产品待办列表项或增量被描述为“完成”时，每个人都必须理解“完成”意味着什么。虽然在不同Scrum团队之间或许会存在显著差异，但是每个团队成员必须对完成工作意味着什么有相同的理解以便确保透明化。这就是Scrum团队的“完成”定义，用来评估产品增量是否完成。

这一定义也同时被用来指导开发团队了解在Sprint计划会议时能够选择多少产品待办列表项。每个Sprint的目标在于交付符合Scrum团队当前“完成”的定义的潜在可交付功能增量。

开发团队在每个Sprint都交付产品功能增量。这一增量是可用的，所以产品负责人可以选择立即发布它。如果“完成”的定义对增量来说是开发组织的惯例、标准或指南，那么所有Scrum团队都必须遵守它，以此为最低标准。

如果增量“完成”的定义不是开发组织的惯例，那么Scrum团队中的开发团队就必须制定

适合于产品的“完成”的定义。如果系统或产品发布由多个Scrum团队一起开发，那么所

有Scrum团队中的开发团队必须一起参与制定“完成”的定义。

每个增量都添加至之前的所有增量上，并且经过彻底地测试，以此确保整合在一起的所有增量都能工作。

随着Scrum团队的成熟，“完成”的定义会扩大，包含更为严格的标准来保证更高的质量。当使用新定义时，在先前“完成”增量中可能会发现尚需完成的工作。任何产品或系统都应该对其上面开发的工作有“完成”的定义。

结束语

Scrum是免费的，在本指南中提供。Scrum的角色、事件、工件和规则是不可改变的。虽然只实施部分的Scrum是可能的，但这样就不是Scrum了。Scrum只以整体形式而存在，唯其如此才能作为其他技术、方法和实践的容器运作良好。

随后的几年中，许多人都作出了贡献，没有他们的帮助，Scrum不会被提炼至如今这般。

 

继续阅读

前言虽说明道是一款通用型协作软件，适合各行各业，但是经过几年的市场开拓，我们发现有几个行业成为了明道的主流客户，包括：科...

文/明道CTO 金可伟明道是一款较为通用的协作软件，目前尚未针对IT行业做特殊定制化的开发。研发团队在使用明道的过程中，...

各位明道中人新年好！祝您狗年吉祥，万事顺意明道团队已经在准备2018年重要的产品迭代。今年，我们将发布第4个大型版本...

温馨提示时隔一个月左右，明道又迎来一次重要的产品更新。本次更新将于02月07日（本周三）凌晨0点～2点进行，耗时约两个...

本次更新中，我们在手机端新增位置定位和视频上传两种功能控件，可在动态、项目、日程等多个模块使用，随时随地记录重要信息。其...