Scrum敏捷开发框架规范 中文版

Scrum指南

Scrum的权威指南:

游戏规则

2013年7月由Ken Schwaber和Jeff Sutherland开发并维护

目录

Scrum指南的目的 (3)

Scrum的定义 (3)

Scrum理论 (3)

透明性 (3)

检视 (4)

调整 (4)

Scrum团队 (4)

产品负责人 (4)

开发团队 (5)

Scrum Master (5)

Scrum事件 (6)

Sprint (7)

Sprint计划会议 (8)

每日Scrum站会 (9)

Sprint评审会议 (9)

Sprint回顾会议 (10)

Scrum工件 (11)

产品待办列表 (11)

Sprint待办列表 (12)

增量 (12)

工件的透明性 (12)

“完成”的定义 (13)

结束语 (13)

致谢 (13)

人们 (14)

历史 (14)

翻译 (14)

?2014 https://www.wendangku.net/doc/a711131478.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative

Scrum指南的目的

Scrum是用于开发和支持复杂产品的框架。这份指南包含了Scrum的定义，其中包括Scrum的角色、事件、工件，以及把它们组织到一起的规则。Ken Schwaber和Jeff Sutherland创造了Scrum，Scrum指南也由他们撰写提供。他们是Scrum指南的后盾。

Scrum的定义

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

Scrum是：

?轻量级的

?容易理解的

?难以精通的

自上世纪90年代初期以来，Scrum就已经应用于管理复杂产品的开发。Scrum不是开发产品的一种流程或一项技术，而是一个框架，在这个框架里可以应用各种流程和技术。Scrum能使产品管理和开发实践的相对功效（relative efficacy）显现出来，以便进行改进。

Scrum框架由Scrum团队及其相关的角色、事件、工件和规则组成。框架中的每个模块都有其特定的目的，对Scrum的成功实施和运用都至关重要。

Scrum的规则把事件、角色和工件组织在一起，管理着它们之间的关系和交互。Scrum 的规则会贯穿这份文档。

实施Scrum的方案根据情况不同而不同，在这里不作介绍。

Scrum理论

Scrum基于经验型流程控制理论，或者称为经验主义。经验主义主张知识源于经验，而决策基于已知的事物。Scrum采用迭代增量式的方法来优化可预测性和管理风险。

透明性、检视、调整是经验型流程的三大支柱，支撑起每个经验型控制流程的实施。

透明性

流程中的关键环节必须为那些对产出负责的人可见。要拥有透明性，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事情有统一的理解。

例如：

?2014 https://www.wendangku.net/doc/a711131478.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative

?所有参与者谈及流程的时候都必须使用统一的术语

?负责完成工作和验收工作的人必须对“完成”有一致的定义。

检视

Scrum的使用者必须经常检视Scrum的工件和完成Sprint目标的进度，以发现不必要的偏差。检视不应该过于频繁而阻碍了工作本身。当熟练的检视者认真履行检视工作时，效果最佳。

调整

如果检视者发现流程中的一个或多个方面背离了可接受的标准，并且将会导致产品不合格时，就必须对流程本身或者流程化的内容进行调整。调整工作必须尽快实施以最小化进一步的偏差。

Scrum指定了进行检视和调整的4个正式事件，将在“Scrum事件”一节中详细描述：

?Sprint计划会议

?每日Scrum站会

?Sprint评审会议

?Sprint回顾会议

Scrum团队

Scrum团队由产品负责人、开发团队和Scrum Master组成。Scrum团队是跨职能的自组织团队。自组织团队自己选择如何最好地完成工作，而不是由团队外的人指导。跨职能团队拥有完成工作所需要的全部技能，不需要依赖团队以外的人。这种团队模式的目的是最大限度地优化灵活度、创造力和生产效率。

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

产品负责人

产品负责人负责最大化产品以及开发团队工作的价值。实现这一点的方式会随着组织、Scrum团队以及单个团队成员的不同而不同。

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

?清晰地表达产品待办列表项

?对产品待办列表项进行排序，最好地实现目标和使命

?优化开发团队所执行工作的价值

?2014 https://www.wendangku.net/doc/a711131478.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative

?确保产品待办列表对所有人可见、透明、清晰，并且显示Scrum团队的下一步工作

?确保开发团队对产品待办列表项有足够的理解

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

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

为保证产品负责人的工作顺利进行，组织中的所有人员都必须尊重他的决定。产品负责人所作的决定通过产品待办列表的内容和排序来表达。任何人都不得要求开发团队按照另一套需求开展工作，开发团队也不允许听从任何其他人的指令。

开发团队

开发团队包含了各种专业人员，负责在每个Sprint结束时交付潜在可发布并且“完成”的产品增量。只有开发团队的成员才能开发增量。

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

开发团队有以下几个特点：

?他们是自组织的，没有人（即使是Scrum Master都不可以）告诉开发团队如何把产品待办事项列表变成潜在可发布的功能。

?开发团队是跨职能的，团队作为一个整体，拥有开发产品增量所需要的全部技能。

?Scrum不认可开发团队成员的头衔，无论承担哪种工作他们都叫做开发人员。此规则无一例外。

?Scrum不认可开发团队中的所谓“子团队”，无论是测试还是业务分析的成员都不能划分为“子团队”。此规则无一例外。

?开发团队中的每个成员可以有特长和专注领域，但是责任属于整个开发团队。

开发团队的规模

开发团队最佳规模是：足够小以保持敏捷性，足够大以完成重要的工作。少于3人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大。过小的团队在Sprint 中可能会受到技能的约束，无法交付可发布的产品增量。大于9人的团队需要过多的协调沟通工作。过大的团队会产生太多复杂性，不便于经验过程管理。产品负责人和Scrum Master的角色不包含在此数字中，除非他们也参与执行Sprint代表事项列表中的工作。

Scrum Master

?2014 https://www.wendangku.net/doc/a711131478.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative

Scrum Master负责确保所有人都能正确地理解并实施Scrum。因此，Scrum Master要确保Scrum团队遵循Scrum的理论、实践和规则。

Scrum Master是Scrum团队中的服务型领导。Scrum Master帮助Scrum团队外的人员了解他们如何与Scrum团队交互是有益的，通过改变他们与Scrum团队的互动方式来最大化Scrum团队所创造的价值。

Scrum Master服务于产品负责人

Scrum Master以各种方式服务于产品负责人，包括：

?找到有效管理产品待办列表的技巧

?帮助Scrum团队理解“清晰准确的产品待办列表项”的重要性

?在经验主义的环境中理解长期的产品规划

?确保产品负责人懂得如何安排产品待办列表项来最大化价值

?理解并实践敏捷

?按要求或需要引导Scrum事件

Scrum Master服务于开发团队

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

?在自组织和跨职能方面给予团队指导

?协助开发团队开发高价值的产品

?移除开发团队工作中的障碍

?按要求或需要引导Scrum事件

?在Scrum还未被完全采纳和理解的组织环境下指导开发团队

Scrum Master服务于组织

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

?带领并指导组织采用Scrum

?在组织范围内计划Scrum的实施

?帮助员工及相关干系人理解并实施Scrum和经验型产品开发

?发起能够提升Scrum团队生产效率的改变

?与其他Scrum Master一起工作，增加组织中Scrum实施的有效性

Scrum事件

Scrum中指定了一些常规性事件，以减少Scrum之外的会议。Scrum中的事件是有时间盒限定的，也就是说每个事件都有时间限制的。一旦Sprint开始，它的周期也就固定下来了，不能缩短或者延长。而其他事件则可以在该事件的目标达成以后立即终止，这样就确保了在这些事件上花费的时间不会影响项目的进度。

?2014 https://www.wendangku.net/doc/a711131478.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative

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的权力，但他做这样的决定也可能是受到相关干系人、团队或是Scrum Master的影响。

如果某个Sprint的目标过时了，那么也许就需要取消该Sprint。比如公司的发展方向，或是市场、技术条件等发生了改变，这些都可能导致Sprint被取消。总的来说，如果某个Sprint对于其所在环境来说失去了价值和意义，那么它就应该被取消。然而，因为Sprint周期都较短，所以一般来说取消Sprint的意义不大。

当取消某个Sprint时，任何做完和“完成”的产品待办列表项都需要评审。假如有些已经潜在可交付，那产品负责人就会采纳它。所有未完成的就要放回到产品待办列表中，并重新估算。花在它们身上的工作会迅速贬值，所以需要频繁地重估。

?2014 https://www.wendangku.net/doc/a711131478.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative

取消Sprint会消耗资源，因为每个人都需要参加额外的Sprint计划会议来启动新的Sprint。取消Sprint通常会对团队造成重创，这种情况非常罕见。

Sprint计划会议

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

对于周期为一个月的Sprint，计划会议的时限为8小时。对于较短的Sprint，会议时间通常会缩短。Scrum Master要确保会议顺利举行，并且每个参与者都明白会议的目的，同时还要教导大家遵守时间盒的规则。

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 期间按实际情况进行。

产品负责人对选定的产品待办列表项作出澄清，并协助团队权衡取舍。如果团队认为工作量过大或太小，就可以和产品负责人重新协商选中的产品待办列表项。开发团队也可以邀请其他人员参加会议，以获得技术或者领域知识方面的建议。

?2014 https://www.wendangku.net/doc/a711131478.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative

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

Sprint目标

Sprint目标是在当前Sprint通过实现产品待办列表要达到的目的，它为开发团队提供指引，使团队明确构建增量的目的，其在Sprint计划会议中确定。Sprint目标为开发团队在Sprint中所实现的功能留有一定的弹性。Sprint目标可以是为唯一功能服务的产品待办列表项的集合，也可以是能够促使开发团队向着同一目标前进的其他工作，而不应该是孤立的工作。

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

每日Scrum站会

每日Scrum站会是以15分钟为限的事件，开发团队成员在这里分享各自的工作情况，并为接下来的24小时制定计划。这需要检视上个每日站会以来的工作和预测下个每日站会之前所能完成的工作。每日站会在同一时间同一地点进行来降低复杂度。会议上，每个开发团队成员都需要说明：

?昨天我为开发团队达成Sprint目标做了什么

?今天我准备如何帮助团队达成Sprint目标

?有什么事情阻碍了我帮助团队达成Sprint目标

开发团队用每日站会来评估完成Sprint目标的进度，并评估完成Sprint待办列表的进度趋势。每日站会优化开发团队达成Sprint目标的可能性。每天，开发团队应该知道如何以自组织的形式协同工作以达成Sprint的目标，并在Sprint结束时开发出预期中的增量。整个开发团队或者部分团队成员经常在每日站会后聚集到一起进行更详细的讨论，或者为Sprint中剩余的工作做调整或重新计划。

Scrum Master确保开发团队每日站会如期举行，开发团队自己则负责召开会议。Scrum Master指导团队把会议控制在15分钟内。

Scrum Master强制执行每日站会的规则——只有开发团队的成员才能参加。

每日站会可以增强交流沟通、省略其他会议、确定开发过程中需要移除的障碍、强调和提倡快速决策、提高每个成员对项目的认知程度。这是进行检视和调整的关键会议。

Sprint评审会议

?2014 https://www.wendangku.net/doc/a711131478.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative

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

对于周期为一个月的Sprint，评审会议的限时为4小时。对于时间少于一个月的Sprint来说，会议的长度会有所缩短。Scrum Master要确保会议顺利举行，并且每个参与者都明白会议的目的，同时还要教导大家遵守时间盒的规则。

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

?产品负责人邀请Scrum团队以及相关干系人参加会议

?产品负责人说明哪些工作“完成”了，哪些工作没有“完成”

?开发团队讨论在Sprint中哪些工作进展顺利、遇到了什么问题、问题是如何解决的

?开发团队演示完成的工作并解答关于所交付增量的问题

?产品负责人描述当前产品待办列表的完成情况，并根据进度推测可能的完成日期（如果有需要的话）

?参会的所有人就下一步的工作进行探讨，这样，Sprint评审会议就能为接下来的Sprint计划会议提供有价值的信息。

?评审市场或者潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变?为下个产品版本的发布评审时间表、预算、潜在功能和市场

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

Sprint回顾会议

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

Sprint回顾会议发生在Sprint评审会议结束之后，下个Sprint的计划会议之前。对于长度为一个月的Sprint，会议限时为3小时。对于较短的Sprint，会议时间通常会缩短。Scrum Master要确保会议顺利举行，并且每个参与者都明白会议的目的，同时还要教导大家遵守时间盒的规则。Scrum Master作为Scrum流程的监督者，也需要作为团队的一员参加该会议。

Sprint回顾会议的目的是：

?对前一个Sprint周期中的人、关系、过程和工具进行检视

?找出做得好的和潜在需要改进的主要方面，并进行排序

?制定改进Scrum团队工作方式的计划

?2014 https://www.wendangku.net/doc/a711131478.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative

Scrum Master鼓励团队在Scrum的流程框架内改进开发流程和实践，使得他们能在下个Sprint中更高效更愉快。在每个Sprint回顾会议中，Scrum团队通过适当调整“完成”的定义的方式来计划提高产品质量。

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

Scrum工件

Scrum的工件以不同的方式表现工作任务和价值，可以用来提供透明性以及检视和调整的机会。Scrum中的工件就是为了最大化关键信息的透明性，因此每个人都需要有相同的理解。

产品待办列表

产品待办列表是一个有序的列表，其中包含产品需要的一切可能的东西，也是产品需求变动的唯一来源。产品负责人负责管理产品待办列表的内容、可用性和排序。

产品待办列表永远是不完整的，最早的列表只列举出最初所知的以及理解最透彻的需求。产品待办列表根据产品及其应用环境的改变而演进。待办列表是动态的，需要持续更新以反映出产品需要什么来保持其合理、有竞争力以及有用。只要产品存在，产品待办列表就存在。

产品待办列表列出了所有的特性、功能、需求、改进和修复等对未来要发布的产品进行的改变。产品待办列表项包含描述、次序、估算和价值。

随着产品的使用、价值的获取以及获得市场的反馈，产品待办列表变成了更大、更详尽的列表。因为需求永远不会停止改变，所以产品待办列表是个不断更新的工件。业务需求、市场形势和技术的变化都会引起产品待办列表的改变。

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

“产品待办列表细化”指的是为列表项补充细节、估算和排序。这是一个持续不断的过程，产品负责人和开发团队协作讨论产品待办列表项的细节，并对列表项进行评审和修改。何时如何进行细化的工作是Scrum团队的决定。细化的工作通常占用开发团队不超过10%的时间。然而，产品负责人可以根据自己的判断随时更新产品待办列表。

排序越高的产品待办列表项通常比排序低的更清晰、更具体。根据更清晰的内容和更详尽的信息就能做出更准确的估算；排序越低，细节信息越少。开发团队在接下来的Sprint中将要进行开发的产品待办列表项是细化过的，因此，任一列表项都能够在Sprint的时限内“完成”。我们把这些能够在Sprint中“完成”的列表项称为“准备就绪的”（Ready），它们将作为Sprint计划会议中的待选列表项。这种细化列表项的工作能为产品待办列表项提供足够的透明性。

?2014 https://www.wendangku.net/doc/a711131478.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative

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

监控实现目标的进度

在任何时间，达成目标的剩余工作量是可以累计的。产品负责人至少要在每个Sprint 评审会议的时候追踪剩余工作总量。产品负责人比较这个数量与之前Sprint评审时的剩余工作量，来评估在希望的时间点达成目标的进度。这个信息对所有的相关干系人都透明。

各种趋势燃尽图（burn-downs）、燃烧图（burn-ups）和累积型的工作流（cumulative flows）都能用来预测进度。实践证明这些工具都是有用的。然而，这并不能代替经验主义的重要性。在复杂的环境下，将要发生的东西是未知的，只有已经发生的事情才能用来做前瞻式的决策。

Sprint待办列表

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

开发团队选中用于达成Sprint目标的工作正因为Sprint待办列表变得清晰可见。

Sprint待办列表拥有足够的细节，因此能够在每日站会中对进度的变化有清楚的认识。开发团队会在Sprint期间修改Sprint待办列表，Sprint待办列表也会随着团队工作的开展以及对工作需求了解的深入涌现出来。

当新工作出现时，开发团队需要将其追加到Sprint待办列表中去。随着任务的进行或者完成，团队需要估算并更新剩余的工作量。如果计划中某个部分失去开发的意义，就可以将其删除。在Sprint期间只有开发团队可以修改Sprint待办列表。Sprint待办列表是高度可见的，是对团队计划在当前Sprint内工作完成情况的实时反映，该列表由开发团队全权负责。

监控Sprint进度

在Sprint中的任意时间点都可以计算Sprint待办列表中所有剩余工作的总和。开发团队至少在每日站会时跟踪剩余的工作量，预测达成Sprint目标的可能性。团队通过在Sprint中不断跟踪剩余的工作量来管理自己的进度。

增量

增量是一个Sprint完成的所有产品待办列表项，以及之前所有Sprint所产生的增量价值的总和。在Sprint的结尾，新的增量必须是“完成”的，这意味着它必须可用并且达到了Scrum团队“完成”的定义的标准。无论产品负责人是否决定真正发布它，增量必须可用。

工件的透明性

?2014 https://www.wendangku.net/doc/a711131478.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative

Scrum依赖于透明性。我们作出的优化价值和控制风险的决定都是基于所获知的工件状态。如果工件的状态是完全透明的，那么作出的决定就等于有了一个坚实的基础；否则，作出的决定就是有缺陷的，而价值也有可能因此遭受损失，风险也可能会因此而增加。

Scrum Master必须和产品负责人、开发团队以及其他相关干系人一起合作，以确保所有工件都是完全透明的。有些实践就是为了应对不完全透明的状态而生的，Scrum Master 必须帮助每个人，让他们都能够在遇到不透明的情况下采取最合适的措施。Scrum Master 可以通过检视工件、嗅探（可能造成不透明的）模式、留心倾听以及观察预期和实际结果的差别来检查是否有不透明的表象。

Scrum Master的职责就是要和Scrum团队以及企业一起增加工件的透明性。这项工作通常需要一个学习、说服和改变的过程。获得透明性无法一步登天，但这是一条必经之路。

“完成”的定义

当产品待办列表项或者增量被描述为“完成”的时候，每个人都必须理解“完成”意味着什么。虽然这在不同的Scrum团队之间会有巨大的差别，但是团队成员必须对完成工作意味着什么有相同的理解，这样才能保证透明性。这就是Scrum团队的“完成”定义，用来评估产品增量是否完成。

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

开发团队在每个Sprint都交付产品功能增量。这个增量是可用的，所以产品负责人可以选择立即发布它。如果开发部门制定了“完成”的定义作为规范、标准或者指引，那么所有Scrum团队都必须遵守；如果“完成”的定义还没制定，那么Scrum团队中的开发团队就必须制定符合产品的“完成”的定义。如果系统或者产品由多个团队开发，那么所有Scrum团队中的开发团队必须一起参与制定。

每个增量都添加到之前的所有增量上，并经过充分测试，以此保证所有的增量都能工作。

随着Scrum团队的成熟，“完成”的定义会扩大，包含更严格的标准来保证更高的质量。任何产品和系统都应该对在其上面开发的工作有“完成”的定义。

结束语

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

致谢

?2014 https://www.wendangku.net/doc/a711131478.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative

人们

在千千万万Scrum的贡献者中，我们要特别感谢那些在其最初10年提供帮助的人

们。首先，要提到Jeff Sutherland及与他工作的Jeff McKenna和Ken Schwaber及与他工作的Mike Smith和Chris Martin。许多人在随后的几年中也都作了贡献，没有他们的帮助，Scrum不会像今天这样精炼。

历史

Ken Schwaber 和Jeff Sutherland在1995年的OOPSLA大会中首次共同演说Scrum。那次演讲本质上记录了Ken和Jeff在之前几年使用Scrum时所学到的经验。

Scrum的历史已经算是很长了。我们对首批尝试和提炼Scrum的公司：Individual，Inc.、Fidelity Investments和IDX（现在的GE医疗）表示致敬。

Scrum指南记录Ken Schwaber 和Jeff Sutherland开发和培育Scrum已经超过20年了。其他的一些资源从模式、流程和见解方面为Scrum提供了补充，从而提高生产效率、价值、创造力以及提升自豪感。

翻译

这份中文版指南是由李麟德(Derek Li)和王军(Jim Wang)，基于鲍央舟和孙媛翻译的2011版的Scrum Guide，根据2013版的更新进行补充和修改。原版的Scrum Guide由Ken Schwaber和Jeff Sutherland撰写。

?2014 https://www.wendangku.net/doc/a711131478.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative

敏捷开发Scrum

https://www.wendangku.net/doc/a711131478.html, 个人管理－使用Scrum来敏捷自己 每个人都有自己的生活和自己的职业或事业，如果把经营个人成长作为一个项目来看，那么在这个个人管理项目中，我们每个人都是这个项目的管理者和执行者。 Scrum敏捷开发方法 如果你是一名开发人员，那么现在还不知道Scrum方法，那么你就out了。Scrum是一种现在普遍流行并且很好的一种基于管理为主的敏捷项目开发方法。我之前blog中全面概要的介绍了一下Scrum方法，如果你不熟悉的而又想了解下面内容，请你最好去去仔细看看我这篇文章《流程－从IT方法论来谈Scrum》，因为下面我将描述我们如何基于Scrum方法来进行个人管理项目的执行。 价值观 在Agile Software Development with Scrum一书中指出，Scrum的核心价值观是：承诺、专注、公开、敬重和勇气，它提倡自我管理、涌现机制、可视性和评估/适应循环的根本原则，这些价值观对个人管理依然非常有效。 1. 承诺（Commitment）：我们是否经常暗下决心，一定要戒掉游戏，一定要完成这 个任务，但是最后是不是仍旧还存在脑子里。如果你有这种现象，那么你需要做的就是自己对自己承诺，自己相信自己，如果自己都不能相信自己，那么谁又能相信你呢？ 2. 专注（Focus）：要事第一，对一件事情投入100％去做好 3. 公开（Openness）：有人说，能力就像怀孕一样，时间久了才能看出来，你个人 的学习、个人的Open都需要公开的表达才能让别人知道 4. 敬重（Respect）：三人行必有我师，空杯心态，尊重每一个人，向不同的学习

敏捷开发文库-多团队敏捷开发的组织架构和协作模式

多团队敏捷开发的组织架构和协作模式 写这篇文章的背景是：一个项目组实施Scrum取得成效，如何在整个开发部门推广Scrum？看一下我们一个大产品，三个项目组共同完成的具体实践： 我们做了如下的组织调整： 1. 产品部增加一名总监（CPO），负责公司层面的产品思路，整合三个子产品 2. 各个Scrum小组的架构师和DBA成立虚拟架构师团队，架构师团队根据产品部的整体 产品思路，提出并实现公司层面的技术架构（此时每一个项目组需要一个高级开发人员参加）。公司所有产品在这个架构平台上进行开发。这样的好处是：公司整体的开发成本、维护成本降低，质量提高。同时架构师和参加架构开发的高级开发人员在项目组内可以快速将架构平台应用在本项目组。在产品开发迭代开始之前，由“架构师团队”完成系统级的架构，然后架构师团队的成员回到自己的Scrum团队进行每日的工作。3. 各个Scrum小组的QA成立虚拟QA团队，主要的目的是为了整合研发部QA的资源， 推出更加高效的测试方法、测试工具 4. 三个项目组的SM以Scrum of Scrums的方式，每天（需要的时候随时）以会议的方式 沟通10～20分钟，主要是产品间的整合、项目组见资源的协调、遇到的Impediments 如何解决等。 5. 各个Scrum小组的美工成立虚拟美工组组，负责公司所有产品的界面（页面）设计， 最大的好处是页面风格统一，页面层的技术可以共享，同时有利于公司的产品宣传和产品形象。 6. 每个Scrum小组内部以Scrum的方式工作，Scrum of Scrums的沟通介质是Kanban 7.成立部门级的支持团队，分为技术专家团队、公共组件团队、领域专家团队、独立测试 团队，每个团队人数很少，但是可以使整个部门的工作有效率。例如，架构师团队的Leader就是组件团队和技术专家团队的PO，只不过他们的Product Backlog只有技术需求而已。 8.技术专家的工作以Kanban管理，公共组件团队的工作以Scrum管理

Scrum敏捷开发方法实操

龙源期刊网 https://www.wendangku.net/doc/a711131478.html, Scrum敏捷开发方法实操 作者：宋至钧 来源：《建筑与装饰》2016年第06期 如今的移动互联网时代，商业周期快速变化，市场更迭日趋频繁，极致与快速已经成为对软件项目开发管理的基础要求，传统的软件开发模式越来越不能适应当前的商业需求和市场竞争，轻量型的软件迭代开发方法依托其在简化团队建设、优化项目管理的优势，已经成为商业软件项目开发的主流。Scrum敏捷开发便是其中一种能够适应各种规模、体量的软件项目开发的敏捷迭代开发模式，尤其是在开发一些快速交付项目的应用中，具有很大的优势。 1 Scrum敏捷开发介绍 Scrum一词原本是一个橄榄球术语，意为“并列争球”。Scrum敏捷开发是由Ken Schwaber 与Jeff Sutherland在1995的OOPSLA（面向对象技术的高峰会议）上正式提出，之后迅速普及。简而言之，这是一种以人为核心的，迭代、循序渐进的开发方法，强调以人为本，以需求为中心，注重交互和协作，积极响应需求变化，专注于交付对客户有价值的软件。 Scrum敏捷开发没有统一的开发策略，而是基于实用主义的原则，根据项目团队的规模、人员构成、项目目标等方面的不同，来制定灵活的策略，通常有以下几个原则：最优先的目标是尽早并持续性地交付有价值的软件，这是Scrum的核心价值；欢迎需求变化，通过频繁交付和过程控制提高产品的竞争优势；减少文档，努力实现全局视图和软件源代码一起演化；强调业务人员和项目开发人员的同步性，主动沟通、当面交流，信任团队的自我管理能力；简化；定期反思、调整和校正。 和传统的瀑布式和其他迭代式开发方法相比，Scrum敏捷开发主要有以下几个特点： 团队气氛好：Scrum敏捷开发赋予项目团队更大的自主权，将业务团队、设计团队和技术开发团队融合在一起，最大化降低团队的沟通成本，团队气氛活跃，能动性强。 灵活性强：Scrum敏捷开发方法强调灵活，主动拥抱需求变化，由市场驱动技术开发，能够迅速反馈用户需求。 开发成本低：Scrum敏捷开发方法降低了文档维护成本，交流沟通成本，同时快速交付的开发过程也降低了时间成本。 最大化生产率：Scrum敏捷开发以有价值的交付为核心目标，将产品以最快的速度送达用户，并以最快的速度应对市场的最新反馈，生产率大幅提高。 项目风险低：Scrum敏捷开发方法交付时间短，产品迭代速度快，可以有效降应对市场变化，并且迅速布局调整，降低项目风险。

Scrum介绍(中文版)

Copyright ? 2010 https://www.wendangku.net/doc/a711131478.html, 专业的敏捷开发社区 Scrum 中文网 Scrum介绍 Scrum中文网 https://www.wendangku.net/doc/a711131478.html, 版权说明：本文部分资料及图片翻译自Pete Deemer 的Introduction to Scrum for Managers and Executives 以及Mike Cohn 的An Introduction to Scrum.

专业的敏捷开发社区 Scrum 中文网 许多企业面临的问题与挑战 ? 产品投放市场的时间太慢 ? 项目失败的比例高的离谱 ? 投资回报低，经常失败 ? 对变化与变更的响应，难度大且成本高 ? 客户体验及客户为导向很差 ? 软件质量不过关 ? 生产力需要大幅提高 ? 员工士气，动力及责任感很低 ? 需要普遍的微观管理 ? 人员流失率特别高 ......

专业的敏捷开发社区 Scrum 中文网 越来越多的企业开始使用Scrum 解决这些问题 ?Google ?IBM ?Nokia ?Siemens ?Philips ?Accenture ?Sun ?UbisoB ?Bleum ?SAP ? Microsoft ? Infosys ? Oracle ? Wipro ? Motorola ? Yahoo! ? Schneider ? Agilent ? Irdeto ? Double Click ? Autodesk ? Tencent ? Plenware ? Trendmicro ? Moody ’s ? StarCite

专业的敏捷开发社区 Scrum 中文网 哪些类型的项目已经在使用Scrum ?大型企业级软件项目 ?商业软件产品 ?消费者软件项目/大型网站 ?美国FDA批准的应用于X射线和MRI的软件 ?高可靠性系统（99.9999％以上） ?财务支付系统 ?智能家居项目 ?战斗机项目 ?大型数据库应用 ?嵌入式电信系统 ?手机项目 ?CMMI5级的组织 ?多地点同步开发 ?支撑和维护项目 ?非软件项目 ? ……

敏捷开发简介

敏捷开发简介 2009-04-21 17:46:34.0 来源:https://www.wendangku.net/doc/a711131478.html, 关键词：Scrum精益开发敏捷开发 在软件工业界，敏捷开发已成为众多高效开发团队的制胜之道。它不仅被许多中小公司青睐，在全球一百强的企业中，敏捷也已大行其道，受到许多资深项目管理者和开发人员的推崇。欧美软件企业中，有近半企业已采用敏捷方法进行开发。大多数尚未应用敏捷的企业，也都对其有所了解，而且很多在计划实施。中国的外企，外包公司和许多知名企业也都开始采用了敏捷方法。例如，腾讯内部几乎所有的开发团队都在实施敏捷。 敏捷方法给这些企业也已带来了巨大的收益。据业内资深人士和长期从事敏捷咨询的服务公司透露，采用敏捷开发的团队一般会提高3-10倍的效率，软件的质量也有了更加可靠的保证。同时，敏捷开发的应用也给团队内的每个成员提供了良好的发展机会。他们的技术和合作水平都能得到响应的提高。敏捷的成功来源于其方法本身的适用性和团队对它的深入理解和合理运用。下面我们就对敏捷开发做一个简单的介绍和讨论。 敏捷开发由几种轻量级的软件开发方法组成。它们包括：极限编程（XP），Scrum，精益开发（Lean Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Cristal Clear）等等。所有这些方法都具有以下共同特征，它们也是敏捷开发的原则和方法：1.迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周 期持续的时间一般较短，通常为一到六周。 2.增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使 用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。3.开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化 和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。 4.持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候 集成，有些项目则每天都在这么做。 5.开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给 人。 简史 许多人认为，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。但是，实际上敏捷方法，特别是迭代和增量开发方法（IID）起源于20世纪30年代的一些非软件项目。而最早引入一些敏捷方法的项目之一就是20世纪60年代初的美国航天局水星计划。在这个项目中，一些极限编程方法如测试先行等也被使用。此后，迭代和增量开发被IBM联邦系统部（FSD）和沃森研究中心（Watson Research Center）采纳。有趣的是一些研究人员甚至在关于瀑布开发模式的最早的论文中发现了敏捷开发的线索。在这篇论文中，温斯顿.罗伊斯（Winston Royce）建议在一个项目中使用两次瀑布模式，也就是使用两次迭代。 20世纪70年代，最早的有记载的使用迭代和增量开发的主要项目之一，是为第一艘美国三叉戟潜艇开发的第一指挥和控制系统。该项目有大约一百万行代码，进行得非常成功。迭代和增量开发从此开始稳步发展，越来越多的项目开始使用这种开发模式。在1976年，Tom Gilb在他的著作《软件度量》（“Soft ware Metrics”）一书中阐述了他的迭代和增量开发实践，这可能就是第一部阐述这种方法的书籍。迭代和增量开发的另一次出色发挥，是在一个美国宇航局航天飞机软件的开发项目。这个项目负责开发其航空电子设备的软件系统。改项目由IBM联邦系统部（IBM FSD）在1977至1980年完成。一些典型的敏捷做法，如使用8个周迭代以及用反馈推动开发循序渐进等方法都在该项目中得以应用。 20世纪80年代，更多的出版物和更多的项目应用进一步推进了迭代开发的发展。在1895年，巴里贝母（Barry Boehm）正式定义了使用迭代开发的螺旋模型（Spiral model）。80年代初，在美国国防部发生

敏捷开发文库-敏捷实践(二)-荷兰铁路公司的分布式Scrum开发(项目如何启动)

敏捷实践（二）－荷兰铁路公司的分布式Scrum开发（项目如何启动） Scrum为项目执行提供了可靠的、已被证实的基础。但是，在每个项目中，Scrum都必须根据具体需求和环境进行调整，这是项目成败的决定性因素。在这篇文章中，我们将会介绍我们如何成功地完成了一个大型的（20人年，超过十万行代码）、分布式（开发人员位于印度和荷兰）Scrum项目，而这个项目曾经在传统开发方式下被废弃过。为了帮助读者顺利运作大规模项目，在这里我也会历数我们的经验教训，包括：项目启动、找到合适的产品负责人、估算的重要性、有效沟通、测试、文档。本篇介绍“项目如何启动” 项目开始的时候，我们在第一个sprint开始前安排了一个启动阶段，耗时三周，准备好了sprint中所需的一切。这个启动阶段由一个项目经理，一个架构师和一个Scrum Master 参与完成。 选择产品负责人是个很有难度的事情，我们找不到一个人能够有时间、具备领域知识、而且有权利设置需求优先级。我们提名了两个业务分析师来一起承担产品负责人的职责。他们能抽出时间来，而且他们从前也参与过构建PUB的工作，所以业务知识很丰富，足以担当起产品负责人的角色，为多组客户充当优秀的代理。有关优先级的和范围的高级决策，是由客户委任的项目经理负责，但是他时间不够用，对于需求的理解也有所欠缺。一般情况下大家的配合还可以，但偶尔项目经理也会对（他所缺席的）计划会议上制定的优先级进行调整，于是这个会议就得重新来过。在理想状态中，对优先级有最终决策权的人应当每次都参加 sprint计划会议。 因为先前有人试着构建过PUB系统，所以有些部分的详细需求文档已经是现成的了。它们遵守了MIL标准，不过其形式不适于敏捷计划和估算，因为在敏捷开发中，需求应当被组织成小块的段落，每一块都可以在一个sprint中进行实现、测试和演示，但是现有的文档与此要求不符。产品负责人也没有多少编写用户故事的经验，为了解决这个问题，Scrum Master帮他们弄出了最原始的产品backlog，里面放着一些细粒度的、经过估算的用户故事，供前几个迭代使用。 我们所构建的软件只是某个大型软件系统的一部分，它还包括很多相关的软件系统，那些系统负责显示信息，还要在车站内安装相关显示设备。我们得保证每件事情都可以按时完成，才能把复杂的系统理顺。所以需要有一个整体的计划方案。经历了几次迭代，我们对系统的各个功能都按照自己的最大能力做出估算，这个问题也解决掉了，而且也有了一个比较靠谱的生产率。于是就可以用发布版本燃尽图来记录和沟通进度了。这里我们学到的东西就是，即使是信息量很少的情况下，有估算也比没估算好。

Scrum敏捷开发框架规范 中文版

Scrum指南 Scrum的权威指南: 游戏规则 2013年7月由Ken Schwaber和Jeff Sutherland开发并维护

目录 Scrum指南的目的 (3) Scrum的定义 (3) Scrum理论 (3) 透明性 (3) 检视 (4) 调整 (4) Scrum团队 (4) 产品负责人 (4) 开发团队 (5) Scrum Master (5) Scrum事件 (6) Sprint (7) Sprint计划会议 (8) 每日Scrum站会 (9) Sprint评审会议 (9) Sprint回顾会议 (10) Scrum工件 (11) 产品待办列表 (11) Sprint待办列表 (12) 增量 (12) 工件的透明性 (12) “完成”的定义 (13) 结束语 (13) 致谢 (13) 人们 (14) 历史 (14) 翻译 (14) ?2014 https://www.wendangku.net/doc/a711131478.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative

Scrum指南的目的 Scrum是用于开发和支持复杂产品的框架。这份指南包含了Scrum的定义，其中包括Scrum的角色、事件、工件，以及把它们组织到一起的规则。Ken Schwaber和Jeff Sutherland创造了Scrum，Scrum指南也由他们撰写提供。他们是Scrum指南的后盾。 Scrum的定义 Scrum: Scrum是一个框架，在这个框架中人们可以解决复杂的自适应问题，同时也能高效并有创造性地交付尽可能高价值的产品。 Scrum是： ?轻量级的 ?容易理解的 ?难以精通的 自上世纪90年代初期以来，Scrum就已经应用于管理复杂产品的开发。Scrum不是开发产品的一种流程或一项技术，而是一个框架，在这个框架里可以应用各种流程和技术。Scrum能使产品管理和开发实践的相对功效（relative efficacy）显现出来，以便进行改进。 Scrum框架由Scrum团队及其相关的角色、事件、工件和规则组成。框架中的每个模块都有其特定的目的，对Scrum的成功实施和运用都至关重要。 Scrum的规则把事件、角色和工件组织在一起，管理着它们之间的关系和交互。Scrum 的规则会贯穿这份文档。 实施Scrum的方案根据情况不同而不同，在这里不作介绍。 Scrum理论 Scrum基于经验型流程控制理论，或者称为经验主义。经验主义主张知识源于经验，而决策基于已知的事物。Scrum采用迭代增量式的方法来优化可预测性和管理风险。 透明性、检视、调整是经验型流程的三大支柱，支撑起每个经验型控制流程的实施。 透明性 流程中的关键环节必须为那些对产出负责的人可见。要拥有透明性，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事情有统一的理解。 例如： ?2014 https://www.wendangku.net/doc/a711131478.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative

SCRUM框架及基本知识

1什么是SCRUM 一个轻量级的软件开发方法 Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程.。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。 一个简单的开发框架 图表 1 一个简单的开发框架 Scrum由三个角色，六个时间箱，四个工件组成： 三个角色： 1. 产品负责人（Product Owner） 2. Scrum Master 3. Scrum团队 六个时间箱: 1. Sprint 2. 发布计划会议（Release Planning Meeting） 3. Sprint计划会议（Sprint Planning Meeting）

4. 每日站会（Daily Scrum Meeting） 5. Sprint评审会议（Sprint Review Meeting） 6. Sprint回顾会议（Sprint Retrospective Meeting） 四个工件 1. 产品Backlog（Product Backlog） 2. 发布燃尽图（Release Burndown Chart） 3. SprintBacklog（Sprint Backlog） 4. Sprint燃尽图（Sprint Burndown Chart） 一个经历过时间考验的开发过程 Scrum最早由Jeff Sutherland在1993年提出，Ken Schwaber 在1995年OOPSLA会议上形式化了Scrum开发过程，并向业界公布。之后，Scrum成为领先的敏捷开发方法之一，目前世界上有超过500家公司在使用Scrum。 2Scrum三个角色及其职责介绍 每个Scrum团队包括3个角色：产品负责人（Product Owner）, ScrumMaster和 Scrum 团队。产品负责人 产品负责人的职责： 确定产品的功能，负责维护产品Backlog。 决定产品的发布日期和发布内容。 为产品的投资回报率(ROI)负责。 根据市场价值确定功能优先级。 在每个Sprint开始前调整功能和调整功能优先级。 在Sprint结束时接受或拒绝接受开发团队的工作成果。 产品负责人是一个人，而不是一个委员会。可能会有一些委员会向产品负责人提出建议或影响他的决策，但要想改变某条目的优先级必须先说服产品负责人。实施Scrum的企业可能发现这样会影响他们制定优先级和需求的方法。 为保证产品负责人的工作取得成功，企业中的所有人员都必须尊重他的决定。任何人都不得要求团队按照另一套优先级开展工作，团队也不允许听从任何人带有威胁恐吓性的指令。产品负责人

SCRUM敏捷开发基础及失败成功案例分析

S C R U M敏捷开发基础及失败成功案例分析 Company Document number：WTUT-WT88Y-W8BBGB-BWYTT-19998

什么是敏捷开发方法什么是SCRUM 有人在这个字面上下功夫，说敏捷就是反应要灵敏，动作要快捷；有人还在字面上进行延伸，说敏捷就是又好又快，或者就是多快好省；有人说敏捷就是光写代码不写文档；有人觉得敏捷就是没有制度，管理松散的工作方式；有人觉得只要敏捷了，就代表高软件交付水平。 那么，敏捷这个词到底由何而来呢在九十世纪中期，涌现了一批软件行业的激进人士，他们反对那些以过程为本的重型软件开发方法（例如：传统的瀑布开发方法）。在2001年，17位软件业界的专家们齐聚一堂，讨论正在兴起的轻量级开发方法（Lightweight methods）。专家们给这类轻量级的方法学起了一个新的名字叫做敏捷，并发布了敏捷开发者宣言。 敏捷方法强调以人为本，专注于交付对客户有价值的软件。在高度协作的开环境中，使用迭代式的方式进行增量开发，经常使用反馈进行思考、反省和总结，不停的进行自我调整和完善。 敏捷开发方法是这些轻量级方法的总称，它旗下有很多具体的开发过程和方法。主要的有：极限编程（XP）、特征驱动软件开发（FDD）、SCRUM开发方法等等。SCRUM开发方法是由Jeff Sutherland在1993年创立，Jeff也是制定敏捷宣言的17位专家之一。SCRUM借用了橄榄球运动中的术语——一个团队拿球向前冲。 严格的说，SCRUM是遵循敏捷方法的一个软件开发框架。在SCRUM框架中，融入敏捷开发的精神和思想，就被称作SCRUM开发方法。SCRUM是一个什么样的开发框架呢简单说，它由三个角色（Role），三种会议（Ceremonie），三项工件（Artifact）组成。 ·角色（Role）：产品主管（Procuct Owner），他负责项目的商业价值；SCRUM师傅（ScrumMaster），他负责团队的运转和生产；以及自组织的团队。 ·会议（Ceremonie）：迭代计划会议，每日晨会（daily scrum meetings），迭代回顾会议。

一个真实的敏捷开发案例

一个真实的敏捷开发案例 摘要：Scrum为项目执行提供了可靠的、已被证实的基础。但是，在每个项目中，Scrum都必须根据具体需求和环境进行调整，这是项目成败的决定性因素。在这篇文章中，将会介绍如何成功地完成 Scrum为项目执行提供了可靠的、已被证实的基础。但是，在每个项目中，Scrum都必须根据具体需求和环境进行调整，这是项目成败的决定性因素。在这篇文章中，将会介绍如何成功地完成了一个大型的（20人年，超过十万行代码）、分布式（开发人员位于印度和荷兰）Scrum项目，而这个项目曾经在传统开发方式下被废弃过。为了帮助读者顺利运作大规模项目，在这里我也会历数我们的经验教训，包括：项目启动、找到合适的产品负责人、估算的重要性、有效沟通、测试、文档。 背景 荷兰铁路可以跻身于世界上使用量最大的铁路系统之列，每天要运送120万乘客。该部门打造了一套全新的信息系统，为乘客提供更准确的列车信息，减少人为干预。作为该系统的一部分，我们做了这个PUB发布系统，对所有车站中的信息显示和音频广播做集中控制。 有人之前试过完成这个PUB系统，但是他们当时用的是传统的瀑布方法。客户把详细的需求文档规范交给了开发商，然后放任自流，等着完整的系统成形交付。三年之后，这个项目被取消掉了，因为开发商没能开发出一个可以工作的系统来。然后客户雇佣了我们公司从头做起，我们引入了敏捷开发方式，用上了Scrum，跟客户紧密协作，开放交流，小步前进。起步 项目开始的时候，我们在第一个sprint开始前安排了一个启动阶段，耗时三周，准备好了sprint中所需的一切。这个启动阶段由一个项目经理，一个架构师和一个Scrum___ master 参与完成。 选择产品负责人是个很有难度的事情，我们找不到一个人能够有时间、具备领域知识、而且有权利设置需求优先级。我们提名了两个业务分析师来一起承担产品负责人的职责。他们能抽出时间来，而且他们从前也参与过构建PUB的工作，所以业务知识很丰富，足以担当起产品负责人的角色，为多组客户充当优秀的代理。有关优先级的和范围的高级决策，是由客户委任的项目经理负责，但是他时间不够用，对于需求的理解也有所欠缺。一般情况下大家的配合还可以，但偶尔项目经理也会对（他所缺席的）计划会议上制定的优先级进行调整，于是这个会议就得重新来过。在理想状态中，对优先级有最终决策权的人应当每次都参加sprint计划会议。 因为先前有人试着构建过PUB系统，所以有些部分的详细需求文档已经是现成的了。它们遵守了MIL标准[1]，不过其形式不适于敏捷计划和估算[2]，因为在敏捷开发中，需求应当被组织成小块的段落，每一块都可以在一个sprint中进行实现、测试和演示，但是现有的文档与此要求不符。产品负责人也没有多少编写用户故事的经验，为了解决这个问题，Scrum___ master帮他们弄出了最原始的产品backlog，里面放着一些细粒度的、经过估算的用户故事，供前几个迭代使用。 我们所构建的软件只是某个大型软件系统的一部分，它还包括很多相关的软件系统，那些系统负责显示信息，还要在车站内安装相关显示设备。我们得保证每件事情都可以按时完成，才能把复杂的系统理顺。所以需要有一个整体的计划方案。经历了几次迭代，我们对系统的各个功能都按照自己的最大能力做出估算，这个问题也解决掉了，而且也有了一个比较靠谱的生产率。于是就可以用发布版本燃尽图来记录和沟通进度了。这里我们学到的东西就是，即使是信息量很少的情况下，有估算也比没估算好。 扩展到分布式团队

敏捷开发scrum-燃尽图

“燃尽图”--保持项目可视性 “燃尽图解释与表示方法” 燃尽图，在Wiki上面没有单独的解释，只有在Scrum上面对其有基本的解释，燃尽图 燃尽图（burn down chart）是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。不要把燃尽图与挣值图相混淆。 A burn down chart could be flat for most of the period covered by a sprint and yet the project could still be on schedule. 我找寻了几张燃尽图，比较具有代表性意义： 手工燃尽图 详尽“燃尽图”

中国原创的说法：燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。 燃尽图有多种表示方法与意义，每一个公司，每一个项目可能都不同，公司可以根据需要定制自己燃尽图，甚至进行特别的修饰与修改，但无论如何表示与修改，燃尽图具有一个共同的特点：就是可视性 “为什么需要燃尽图”? 上面展示的燃尽图的表示方法与意义，我们可以看到很多公司在实行敏捷过程都使用了这个燃尽图，显然这个燃尽图有它存在的合理与意义，在讨论这个意义之前，我们需要回答几个问题: 1.“燃尽图”到底谁会关注？ 2.“燃尽图”需要谁去填写？ 3.“燃尽图”应该如何填写？ 上面这三个问题留给读者先去思考，随着后面章节讲述，上面三个问题会得一解决，读者可以带着以上三个看这篇文章，希望在读完文章之后，读者会自己答复以上三个问题。 “燃尽图”展示了一种新的管理工作报告，他向管理者与利益相关展示了目前产品BackLog完成情况与整体进度，管理层与利益相关者可以很容易地通过燃尽图了解实时的进度以及细节，管理层更能够实时把握产品的进度并做出正确的决策，并且预计风险，同时随时调整计划。 传统的项目报告一般是固定，系统的，向管理者展示了项目的进展，完成百分比，以及遇到的问题，需要解决与补救的方法，而实际上在开发过程当中，又会有不断的需求加进来，这种传统的项目报告无法应对这种需求，导致往往项目执行者将项目的失败都归咎于需求的增加与变化，并且责备管理层不能做出正确决策。

单团队scrum敏捷开发(1)

Leangoo单团队敏捷开发 1.概述 本场景描述的是针对10以下小型产品研发团队或小型项目的敏捷应用场景。Leangoo单团队敏捷开发项目模板是基于Scrum模型定义的，所以这里所说的单团队是指只有一个Scrum 团队的场景。 Scrum是用于开发和维护复杂产品的一个框架。上世纪90年代，Scrum在全球已得到广泛应用,Scrum最初用于产品研发，目前已广泛用于软硬件开发、互联网、人工智能、学校、政府、市场、管理组织运营等诸多领域。随着技术、市场和环境的复杂度和不确定性持续增长，Scrum在处理复杂性方面的效用日益得到证实。下图是Scrum的框架和流程： Scrum流程 在Leangoo中建立敏捷项目 对小型团队来说，在Leangoo中建立一个敏捷项目就可以很好的支持团队的产品或项目研发。如果下图所示：

项目示例： Leangoo的敏捷项目模板会默认创建“产品Backlog”看板，缺陷看板和第一个迭代的迭代看板（在Scrum中，迭代叫做Sprint），您可以根据需要创建后续迭代的看板。您也可以根据产品和项目的特征，判断是否需要通过使用Leangoo脑图工具创建产品路线图规划。 产品路线图规划和需求管理 产品路线图是重要的产品管理工具。产品路线图是一个高层次的战略计划，它描述了产品在未来一段时间可能会如何发展和壮大。产品路线图确保整个产品团队持续关注产品的目标，帮助产品负责人把握产品的战略方向，调整产品的优先级和产品规划。通过Leangoo可以帮助您创建价值和目标驱动的敏捷产品路线图。 以下场景产品路线图规划是可选的 ： ?已经进入稳定期，处在持续微调阶段的互联网产品、SaaS软件或平台 ?已经进入维护期的产品，如已经趋于稳定的银行、保险、运营商的业务支持平台 ?短期定制外包项目 ?短期小型项目

scrum敏捷开发项目管理

Scrum敏捷开发项目管理 一.什么是Scrum敏捷开发 Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。 二.Scrum敏捷开发的好处 Scrum敏捷开发可以显著增加项目成功的可能。 目前，淘宝，腾讯这样的大公司早已实行了敏捷开发管理。在北京，上海的中小型公司里Scrum敏捷开发也很流行，有很成功的项目经验。 三. Scrum敏捷开发在G3项目课程中的作用 1.可以有效监督学生项目开发的进度 2.通过“站立会议”推动项目进程，带项目的老师可以和学生项目小组进行有效的沟通 3.形象直观得观察出项目小组的模块完成比率 4.体验软件公司当前流行的项目管理，提前适应敏捷开发管理。 四. Scrum敏捷开发在G3项目课程中的实施办法 1.准备材料：白板，笔，几叠四色贴纸 2. Scrum敏捷开发在项目授课中的流程 ①召开Scrum敏捷开发第一阶段会议，把整个项目的需求进行讲解，并且分解项目模块。把四种颜色的贴纸每个学生每种颜色分发3-6张。贴纸的多少和项目的总模块数相关。 红色贴纸代表优先开发的模块和任务 黄色贴纸代表次优先开发的模块和任务 淡绿色贴纸代表优先级最低的模块和任务 (备注：贴纸的颜色不同代表模块和任务的紧急情况，授课老师可以自己定义) ②让学生把分解的模块和任务写到分发到手上的贴纸上，按模块和任务的紧急不同，选择不同的颜色，并且写上学生自己预计的完成时间（以天为单位），最后签上自己的名字。如下图所示： ③在白板上绘制如下表格，让学生把贴纸贴到自己姓名所属的那一行，如图所示:

敏捷开发生命周期

The Agile System Development Life Cycle (SDLC) This article covers: 1. The scope of life cycles 2. Concept: Pre-planning 3. Inception 4. Construction iterations 5. Release iterations 6. Production 7. Retirement 8. Enterprise IT Lifecycles 1. The Scope of Life Cycles As we described in the book The Enterprise Unified Process (EUP) the scope of life cycles can vary dramatically. For example, Figure 1 depicts the Scrum construction life cycle whereas Figure 2 depicts an extended version of that diagram which covers the full system development life cycle (SDLC). Later in this article we talk about an Enterprise IT Lifecycle. My points are: ?Solution development is complicated. Although it's comforting to think that development is as simple as Figure 1 makes it out to be, the fact is that we know that it's not. If you adopt a development process that doesn't actually address the full development cycle then you've adopted little more than consultantware in the end. My experience is that you need to go beyond the construction life cycle of Figure 1 to the full SDLC of Figure 2 (ok, Retirement may not be all that critical) if you're to be successful. ?There's more to IT than development. To be successful at IT you must take a multi-system, multi-life cycle stage view as we show in the discussion of the Enterprise IT Lifecycles. The reality is that organizations have many potential endeavours in the planning stage (which I'll call the Concept Phase in this article), many in development, and many in production. Figure 1 uses the terminology of the Scrum methodology. The rest of this article uses the terminology popularized in the mid-1990s by the Unified Process (Sprint = Iteration, Backlog = Stack, Daily Scrum Meeting = Daily Meeting) and also adopted by Disciplined Agile Delivery (DAD). Figure 1 shows how agilists treat requirements like a prioritized stack, pulling just enough work off the stack for the current iteration (in Scrum iterations/sprints are often 2-4 weeks long, although this can vary). At the end of the iteration the system is demoed to the stakeholders to verify that the work that the team promised to do at the beginning of the iteration was in fact accomplished.