指南
Scrum
Scrum指南
2010年2月
Scrum由Ken Schwaber和Jeff Sutherland开发并维护
版权说明：本文由社区志愿者翻译，版权归原著者所有，Scrum中文网仅对其中的用词进行了统一和部分错误进行了更正。
概要
Scrum基于业界认可的最佳实践，这些实践已在过去的几十年被使用并证实有效。之后，Scrum被置于基于经验过程的理论中。正如Jim Coplien一次对Jeff所说：“每个人都会喜欢Scrum；因为这是当我们被逼到墙角时的自然反应。”
人
在千千万万对Scrum做出贡献的人中，我们要特别感谢那些在其最初10年提供帮助的人们。首先，要提到Jeff Sutherland及与之工作的Jeff McKenna，Ken Schwaber和Mike Smith 还有Chris Martin。Scrum在1995年的OOPSLA上首次被正式介绍和发布。在之后5年中，Mike Beedle和Martine Devos做出了重大贡献。还有所有其他人，没有你们的帮助，Scrum不会被提炼至今天的高度。
历史
在软件开发的世界中，Scrum的历史已经算是很长了。我们对首批尝试和提炼Scrum的公司：Individual，Inc.，、Fidelity Investments和IDX（现在的GE医疗）表示致敬。目标
自从上世纪90年代初期，Scrum方法就已经应用于开发复杂的产品。本篇文章介绍了如何应用Scrum构建产品。Scrum不是一种过程，也不是一项构建产品的技术，而是一个框架，在这个框架里可以应用各种过程和技术。Scrum的作用就是让开发实践方法的相对功效显现出来以便随时改进，同时也为开发复杂产品提供了框架。
Scrum理论
Scrum是以经验过程控制理论为依据，采用迭代、增量的方法来提高产品开发的可预见性并控制风险。Scrum的三大支柱支撑起每个经验过程控制的实现。
第一大支柱是高透明度
高透明度确保管理结果的人看得到那些影响结果的过程方面。这些过程方面不仅要透明，而且那些被观察到的方面也必须被充分了解。这就是说，当某人检验某个过程并认为完成了某些任务时，这个完成必须等同于他们的完成定义。
第二大支柱是检验
开发过程中的各方面必须做到经常性的检验，以确保及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能允许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和勤勉程度。
第三大支柱是适应
如果检验员经检验发现过程中的一个或多个方面不满足可接受标准，并且最终产品是不合格的，那么检验员就必须对过程或是材料进行调整。调整工作必须尽快实施以减少进一步的偏差。
Scrum中有三个进行检验和适应的时刻：每日站会是用来检验朝向Sprint目标的工作进程，调整以优化次日的工作价值。另外，Sprint评审和计划会议是用来检验朝向发布目标的工作进程，调整以优化下一个Sprint的价值。最后，Sprint回顾会议是用来评审完成的Sprint，并确定什么样的调整可以使下一Sprint的效率更高、结果更令人满意和更易于工作。
Scrum内容
Scrum框架包括一组Scrum团队和与其相关的事物：时间箱、工件和规则。
Scrum团队的目标是提高灵活性和生产能力。为此，他们自组织、跨职能，并且以迭代方式工作。每个Scrum团队都有三个角色：1）ScrumMaster，负责确保成员都能理解并遵循过程；2）产品负责人，负责最大化Scrum团队的工作价值；3）团队，负责具体工作。团队包括的开发人员具备开发所需的各种技能，负责在每个Sprint结束之前将产品负责人的需求转化成为潜在可发布的产品模块。
Scrum利用时间箱实现规律性。被时间箱限定的Scrum要素有：发布计划会议、Sprint 计划会议、Sprint、每日站会、Sprint评审会议和Sprint回顾会议。Scrum
的核心是Sprint，即贯穿于开发工作中保持不变的一个月（或更短时间）迭代。所有的Sprint都采用相同的Scrum框架，并且都交付潜在可发布的最终产品增量。Sprint的交替没有间隔期。
Scrum采用四个主要的工件：产品Backlog是囊括了开发产品可能需要的所有事项的优先排列表。SprintBacklog包含了在一个Sprint内将产品Backlog转化成最终可交付产品增量的所有任务。燃尽图是用来衡量剩余的Backlog。发布燃尽图衡量在一个发布计划的时间段内剩余的产品Backlog。Sprint燃尽图衡量在一个Sprint时间段内剩余的SprintBacklog条目。
规则将Scrum的时间箱、角色和工件联系起来。对于Scrum规则的描述将贯穿整个文章。例如，Scrum规则规定：只有团队成员，即承诺将产品Backlog转换成产品增量的人员，才可以在每日站会上发言。在“提示”框中描述的实现方法并不是规则而是建议。
提示：当规则未明确时，Scrum的使用者们要自己想出如何去做。不要试图去寻找完美的解决方法，因为问题通常变化的很快。相反的，尝试一些做法并观察效果如何。Scrum经验本性中的检验和适应的特性会指导你。
Scrum角色
Scrum团队包括ScrumMaster、产品负责人和团队。Scrum团队成员被称为“猪”。产品负责人是产品Backlog的“猪”。团队是Sprint任务的“猪”。ScrumMaster是Scrum过程的“猪”。其他人被称为“鸡”。“鸡”没有权利要求“猪”如何去开展工作。“鸡”和“猪”的比喻来自于以下的故事：
一只鸡对一头猪说：“我们合伙开家饭店吧！”猪想了想，说：“那我们给这个饭店起什么名字呢？”鸡说：“鸡蛋和火腿！”猪回答到：“那还是算了吧，你要做的只是下几只鸡蛋，我把命都搭上了！”
提示：ScrumMaster与客户和管理层共同确定和具体化产品负责人人选。ScrumMaster负责教授产品负责人如何进行工作。产品负责人应当了解如何使用Scrum优化产品开发带来的价值。如果他们不能做到这点，那么我们认为ScrumMaster是负有责任的。
ScrumMaster
ScrumMaster负责确保Scrum团队遵守Scrum价值、实践和规则；帮助Scrum团队和整个组织采用Scrum；通过指导和引导，教授Scrum团队更高效工作、生产出高质量的产品；帮助Scrum团队理解并采用自组织和跨职能。ScrumMaster也帮助Scrum团队在现有的组织环境中做到最好，即使环境并没有优化到适应复杂产品开发的程度。当ScrumMaster帮助进行改变时，这些活动被称为“去除障碍”。ScrumMaster的角色是Scrum团队的服务型领导者。
提示：ScrumMaster可以是团队的成员，例如，他可以是承担Sprint任务的开发人员。但是，当他需要在排除障碍和执行任务之间选择权衡的时候，这种身兼二职的情况常常会对做决定带来矛盾。ScrumMaster绝对不能是产品负责人。
产品负责人
产品负责人是管理产品Backlog、确保团队工作价值的唯一责任人。他负责维护产品Backlog，确保每个成员明晰列表内容、明确哪些条目具有最高优先级，从而了解下个需要开发的条目。产品负责人是一个人，而不是一个委员会。可能会有一些委员会向产品负责人提出建议或影响他的决策，但要想改变某条目的优先级必须先说服产品负责人。采用Scrum 的企业可能发现这样会对他们制定优先级和需求的方法产生影响。
提示：对于商业开发，产品负责人可能就是产品经理。对内部开发而言，产品负责人可能来自其业务会被该产品自动化的职能部门经理。
为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他的决定。任何人都不得要求团队按照另一套优先级开展工作，团队也不允许听从任何人带有威胁恐吓性的指令。产品负责人所作的决定需要明确的包括在产品Backlog的目录和优先级中。这就要求产品负责人竭尽全力，同时也使其成为一个费心费力但又值得去做的角色。
提示：产品负责人可以是团队成员，承担开发任务。但是这样可能会牵掣其精力，影响产品负责人和利益相关人协调工作。但是，产品负责人绝对不能是ScrumMaster。
团队
开发人员组成的团队负责在每个Sprint将产品Backlog转化成为潜在可交付的功能增量。团队同时是跨职能的；团队成员必须具备创造产品增量所需要的技能。团队成员常常具备如编程、质量控制、业务分析、架构、用户界面设计或数据库设计等的专业技能。然而，团队成员所共同分享的技能即访问需求并将需求转化成可用产品的能力，往往比那些专业技能更重要。因为是架构师或设计人员而不愿意编码的人不适合成为团队成员。每个人都尽心尽力参与，即使需要学习新技能或巩固现有技能。团队中没有头衔的概念，这一规则无例外。团队也不允许包括测试或业务分析等在特定领域工作的子团队。
团队同时是自组织的。任何人，包括ScrumMaster都没有权利规定团队如何将产品Backlog转化成可交付的功能增量，而是由团队自己确定。每个团队成员利用自己的专业技能，解决遇到的问题。这种协同配合提高了团队整体的效率和效力。
团队的理想规模是7个（加或减2个）人。如果成员少于5人，那么相互交流就减少了，团队的生产力也会下降。更重要的是，团队在Sprint中可能会受到技能限制，从而导致无法交付可发布的产品模块。如果成员多于9人，那么成员之间就需要太多的协调沟通工作。大型团队会产生太多复杂性，不便于经验过程控制。但是，我们也遇见过一些超过规模上或下限人数的团队取得成功。产品负责人和ScrumMaster这两个角色不计入成员人数，除非他们也是“猪”。
团队的构成在Sprint结束时可能会发生变化，每次团队成员的变化，都会降低通过自
组织而获取的生产力。因此，改变团队构成时务必要谨慎。
时间箱
Scrum中的时间箱包括：发布计划会议、Sprint、Sprint计划会议、Sprint评审会议、Sprint回顾会议和每日站会。
发布计划会议
发布计划会议的目的是建立Scrum团队与组织内的其他部门能够理解和沟通的计划和目标。发布计划会议需要回答以下两个问题：“我们如何以最佳方式将愿景转化为成功的产品？我们怎样才能达到或甚至超越客户的满意度和投资回报？”发布计划确定发布目标、具有最高优先级的产品Backlog、重大风险和发布所包含的全部特性和功能。另外，发布计划会议确立大致交付日期和费用，如果没有任何变化就应当保持该日期和费用。因此，组织就可以检验开发进程，以每个Sprint为基础调整发布计划。
发布计划会议是非强制性的。如果Scrum团队没有召开该会议就开始工作，那么缺乏的工件就会变得非常明显并成为需要解决的障碍。解决障碍的工作将成为产品Backlog中的条目。
产品应用Scrum以迭代的方式构建，每个Sprint中都会创造出产品增量，通常先开发价值最高和风险最大的产品。产品增量随着Sprint交替而完成，每个增量都是整个产品的可交付部分。当创造出足够多有价值、对投资人有益的增量时，产品就可以发布了。
大多数组织已经有自己的发布计划过程，并且在大多数过程中的大部分计划已经在发布之初完成，而且也不会更改。在Scrum发布计划会议上确立一个整体目标和预期结果。发布计划会议通常不超过组织构建传统发布计划的15-20%时间。然而，Scrum发布在每个Sprint 评审和计划会议上都执行及时计划，同时，在每日站会上执行每日及时计划。总的看来，Scrum 发布可能比传统的发布计划耗费略多的工作。
发布计划会议需要为发布估算并优先排列产品Backlog。完成这项工作的技巧很多，但都不属于Scrum的范围，虽说如此，这些技术仍有其使用价值。
Sprint
一个Sprint就是一个迭代，Sprint是以时间箱限定的。在Sprint中，ScrumMaster负责确保不出现任何影响Sprint目标的变化。团队构成和质量目标在Sprint中均保持不变。Sprint包括，或者说由Sprint计划会议、开发工作、Sprint评审会议和Sprint回顾会议组成。Sprint一个紧跟一个进行，之间没有任何时间间隔。
项目旨在完成某个目标，对于软件开发而言，其目的在于构建一个产品或系统。每个项目都包括构建目标的定义、构建计划、工作完成进度和最终产品。每个项目都应该制定范围，即计划精准的时间范围。如果时间过长，某些定义可能会发生变化，另外也会牵扯进很多变量，因而引发巨大的风险等等。Scrum框架使得项目的视野不会超过一个月，项目过于复杂势必会使开发周期延长，从而增加风险。至少每个月应该针对项目的可预见性进行控制，这样每个月都可以遏制项目变得不可控制或不可预测而产生的风险。
提示：如果团队发现承诺的任务过多，可以和产品负责人沟通，以减小Sprint
中选定的产品Backlog范围。如果团队发现有富余的时间，可以和产品负责人商议追加额外的产品Backlog。
提示：当团队刚刚开始使用Scrum，为期两周的Sprint可以让团队在学习中进步，避免在不
确定中挣扎。两周时间的Sprint可以通过将两个增量添加在一起，从而和其他团队同步。
Sprint可以在Sprint时间盒结束之前取消。只有产品负责人才有取消Sprint的权力，但他做这样的决定也可能是受到利益相关人、团队或是ScrumMaster的影响。那么，在什么情况下必须取消Sprint呢？如果某个Sprint的目标过时了，那么管理层就需要取消该Sprint。比如公司的发展方向，或是市场、技术等情况发生变化，这些变化都可能导致取消Sprint。总的来说，如果某个Sprint对于其所在环境来说失去价值和意义，那么它就应该被取消。然而，因为Sprint周期都较短，所以很少发生取消Sprint的情况。
当某个Sprint被取消时，任何做完和“完成”的产品Backlog条目都需要评审。假如有些条目已经相当于潜在可交付的产品增量，那么它们是可以被取纳的。其他的条目就都要复原到最初的估算，放回到产品Backlog中去，任何相关工作就都被看作是徒劳的了。Sprint 终止会消耗资源，因为每个人都需要在新召开的Sprint计划会议中重新组合，开始另一个Sprint。Sprint终止对团队的不利影响非常大，被终止的情况也非常的少见。
Sprint计划会议
Sprint计划会议制定迭代计划。对于一个月为周期的Sprint，计划会议的时间盒限定为8小时。对于较短的Sprint，根据Sprint的长度，按比例缩小会议的时间。（比如，两周的Sprint对应4小时的Sprint计划会议。）Sprint计划会议的内容包括以下两个部分：在第一部分中决定Sprint需要做什么。第二部分（4小时的时间盒对应一个月的Sprint），团队研究在Sprint内如何将功能构建成产品增量。
Sprint计划会议包含两部分内容：“做什么”和“怎么做”。一些Scrum团队将这两部分结合起来。第一部分，Scrum团队处理“做什么”的问题。产品负责人把具有最高优先级的产品Backlog呈现给团队，并一起决定接下来的Sprint中开发什么功能。Sprint会议需要投入的要素包括产品Backlog、最新的产品增量、团队的能力和以往的表现。团队自己决定选择Backlog的数量，因为只有团队可以评估在接下来的Sprint内可以完成什么工作。
选定产品Backlog后，Sprint目标也就明确了。Sprint目标通过实现产品Backlog来达到。Sprint目标为团队提供指导，使团队明确构建增量的目的。Sprint目标是发布目标的子集。
确定Sprint目标的原因是在功能方面为团队留出一定的回旋余地。例如，上一个Sprint 的目标可能是：“通过一种安全、可重获的交易中间件实现客户账户修改功能的自动化”。所以当团队工作时，就会紧记这个目标。为了达到这个目标，团队就需要实现该功能和技术。如果团队感觉实现过程比预期的难度大，那么就可以和产品负责人协商，只实现部分功能。在Sprint计划会议的第二部分，团队需要处理“怎么做”的问题。在Sprint计划会议的第二部分（4小时时间盒对应一个月的Sprint）中，团队需要弄清楚如何将“做什么”会议阶段选定的产品Backlog转化成完成的增量。通常团队会先以设计展开工作，设计过程中，团队确定任务，这些任务就是将产品Backlog转化成可用软件的具体工作。任务需要被分解，以便在一天之内完成。这个任务列表就是SprintBacklog。团队自组织承担该列表中的工作，也可以在Sprint计划会议或在Sprint中及时确定。
提示：通常，Sprint计划会议上只设计出SprintBacklog的60-70%。剩余部分后续完成，或者给出大体的估算并在Sprint中再分解。
产品负责人会参加Sprint计划会议的第二部分，对产品Backlog做一说明，并协助团队权衡取舍。如果团队认为工作量过大或太小，就可以和产品负责人重新协商、确定产品Backlog。团队也可以邀请其他人员参加会议，以寻求技术和领域建议。新组建的团队常常在这次会议中第一次意识到：整个团队要么一起成功，要么一起灭亡，没有个体这个概念。
团队同时认识到必须依靠自己。正因为意识到这一点，整个团队才逐渐自组织并形成自己的特色，真正成为一个团队。
Sprint评审会议
Sprint末尾时要举行Sprint评审会议，一个月的Sprint通常对应4小时时间盒的评审会议。对于时间少于一个月的Sprint来说，根据Sprint的长度，按比例缩小会议的时间。（比如，两周的Sprint对应2小时的Sprint评审会议。）在Sprint评审会议中，Scrum团队和利益相关人沟通Sprint中完成了哪些工作。然后，根据完成情况和Sprint期间产品Backlog的变化，他们确定接下来的工作。这是一个非正式会议，会议中进行功能演示，以促进下一步工作的互助与合作。
评审会议至少要包含以下因素：产品负责人确定完成了哪些工作和剩余哪些工作。团队讨论在Sprint中哪些工作进展顺利、遇到了什么问题、问题是如何解决的。然后，团队演示完成的工作并答疑。产品负责人和与会人员讨论产品Backlog，并根据不同的速率计划出可能的完成日期。接着，整个团体就哪些工作已经完成，同时这对下一步工作有何意义进行探讨。Sprint评审会议为接下来的Sprint计划会议提供了宝贵的参考信息。
Sprint回顾会议
在Sprint评审会议结束之后和下个Sprint计划会议之前，Scrum团队需要举行Sprint回顾会议。对于长度为一个月的Sprint，这是一个3小时时间盒的会议（根据Sprint的长度，按比例缩小会议的时间）。在这个会议上，ScrumMaster鼓励团队在Scrum过程框架和时间的范围内，对自己的开发过程进行改进，使下一个Sprint的效率更高、更易工作。许多书籍都介绍了召开回顾会议的技巧。
回顾会议旨在对前一个Sprint周期中的人、关系、过程和工具进行检验。检验应当确定并重点发展那些进展顺利的，和那些如果采用不同方法可以取得更好效果的条目。这些包括：Scrum团队构成、会议安排、工具、“完成”定义、沟通方法和将产品Backlog条目转化成“完成”工作的过程。在Sprint回顾会议的末尾，Scrum团队应该确定将要在下个Sprint 中实现的有效改进方法。这些变化更适应于经验检验。
每日站会
团队每天进行15分钟的检验和适应的会议就称为Scrum每日站会。每日站会在各个Sprint都是在同一时间，同一地点进行。会议上，每个团队成员需要汇报以下三个问题：
1.从上次会议到现在都完成了哪些工作；
2.下次每日站会之前准备完成什么；
3.工作中遇到了哪些障碍。
每日站会可以增强交流沟通、省略其他会议、确定并排除开发遇到的障碍、强调和提倡快速决策、提高每个成员对项目的认知程度。
ScrumMaster要确保团队举行每日站会，团队则负责召开会议。ScrumMaster指导团队执行规则来控制会议时间，并保证团队成员进行简短有效的汇报。ScrumMaster也执行“鸡”不允许在会议上发言或以各种方式干扰会议的规则。
每日站会不是进度汇报会议。这个会议是为将产品Backlog条目转化成为增量的人（团队）召开的。团队承诺实现Sprint目标和完成产品Backlog条目。每日站会是检验朝向Sprint 目标的进程（三个问题）。跟踪会议通常是对Sprint中的下一步工作进行调整，目的在于增加团队实现目标的可能性。这是Scrum经验过程中的重要检验和适应的会议。
Scrum工件
Scrum的工件包括产品Backlog、发布燃尽图、SprintBacklog和Sprint燃尽图。
产品Backlog和发布燃尽图
产品Backlog列出团队正在开发的产品需求。产品负责人负责产品Backlog的内容、可用性和优先级。产品Backlog永远不会是全面的，最初的版本只列出最基本的和众所周知的需求。产品Backlog根据产品和开发环境的变化而演进。Backlog是动态的，它经常发生变化以确保产品更合理、更具竞争力和更有用。只要产品存在，产品Backlog就存在。
产品Backlog中包含产品开发和交付成功产品需要的所有条件和因素。表中列出了所有的特性、功能、技术、改进方法和故障修复等对未来发布产品进行的改变。产品Backlog条目包含描述、优先级和估算的特征。优先级是以风险、价值和必要性驱动的。评估这些特征的技巧有很多。
提示：产品Backlog条目通常是以用户故事的形式展现。也有可能是用户案例，但是用户案例更适用于开发生命关键型或任务关键型软件。
产品Backlog按照优先级排序。优先级高的产品Backlog需要立即进行开发。优先级越高，产品Backlog越紧急，就越仔细斟酌，而且对其价值的意见越一致。优先级高的产品Backlog更清晰直观，细节信息比低优先级Backlog的多，根据清晰的内容和详尽的信息做出的估算就更具价值。优先级越低，细节信息越少，少到只能勉强辨认出该条目。
随着产品的应用、价值的增加、市场的反馈，产品Backlog变成了庞大、更详尽的列表。因为需求不断发生变化，所以产品Backlog是个不断更新的文档。业务需求、市场形势、技术和员工的变化都会引起产品Backlog的变化。为了减少返工，只需要细化最高优先级的条目。在接下来的若干Sprint内将要进行开发的产品Backlog条目是细粒度的，已经被分解过，因此，任何一个条目在Sprint内都可以被完成。
提示：Scrum团队通常利用每个Sprint的10%时间，提炼产品Backlog以达到上面的要求。当达到粒度要求时，产品Backlog顶端的（最高优先级、最高价值）条目会被分解，分解后的条目适合在单个Sprint内完成。在提炼阶段就已经对这些条目进行分析和考虑。当进行Sprint计划会议时，这些高优先级的条目就能充分地被理解，也可以很容易挑选出来。
若干个Scrum团队常常会一起开发某个产品。但描述下一步产品开发工作的产品Backlog只能有一个。那么这就需要使用产品Backlog的特征对条目进行分组。分组可以根据特性集、技术或架构进行。这也是Scrum团队经常采用的一种组织工作的方法。
提示：验收测试常常作为产品Backlog条目的属性。验收测试经常以条目开发完成后应实现功能的可测试描述取代细节文字描述。
发布燃尽图记录了在一段时间内产品Backlog的总剩余估算工作量。估算工作量以Scrum团队和组织决定的单位为标准，时间是以Sprint为单位。
在发布计划会议中对产品Backlog条目进行原始估算，之后创建条目。在产品Backlog提炼阶段，这些条目会被评审和修改。然而，对产品Backlog的估算可以随时更新，团队负责所有的估算工作。产品负责人在协助和指导团队权衡取舍时可能对团队所做决定带来一定影响。但是，最后的估算是由团队进行。产品负责人总是留有一份最新的产品Backlog/发布Backlog 燃尽图。可以根据剩余工作量的变化绘制一张趋势图。
提示：在某些组织中，向Backlog中追加的工作任务比完成的还要多。这就可能造成绘制的趋势图曲线是水平甚者是上升的。为了应对这种情况并保证高透明度，在追加或减少工作量
时，标记新的底线。只有工作量发生重大变化时才有可能需要增加或除去底线，而且也应该详细记入文档。
提示：趋势图曲线对于发布的前两三个Sprint的可参考性也许不大，除非这些团队曾经在一起工作过，对产品认识深刻，并且理解基本技术。
SprintBacklog和Sprint燃尽图
SprintBacklog包含团队需要执行的任务，从而将产品Backlog条目转化成“完成”的增量。许多条目在Sprint计划会议中已经定义。这些就是团队确认的完成Sprint目标所必须做的工作。SprintBacklog条目必须被分解。进行充分的分解，那么过程中发生的变化就可以在每日站会上得到理解。一天或一天之内的工作量对SprintBacklog条目来说是比较适合的。
团队在整个Sprint内都会修改SprintBacklog，同时在Sprint内合并SprintBacklog。因为它是针对每个成员的任务，所以可能有时任务会偏多或偏少，亦或某项任务耗费的时间超出或提前于预期。当出现新工作时，团队需要将其追加到SprintBacklog中去。随着任务进行或者被完成，需要更新每项任务的估算剩余工作量。如果某项任务失去开发的意义，就可以将其除去。在Sprint内只有团队可以对SprintBacklog进行修改，也只有团队可以对列表的内容或估算进行修改。SprintBacklog是高可见度的，是对团队计划在当前Sprint内完成工作的实时反映，并且，该列表只属于团队。
SprintBacklog燃尽图展现的是当前Sprint内剩余的SprintBacklog工作数量。创建该图需要通过累计Sprint中每日Backlog估算来确定剩余工作量。Sprint内的剩余工作量就是所有SprintBacklog的剩余工作总量。每天对这些数据进行跟踪，并绘制燃尽图，时刻显示剩余工作量。用线将图上的点依次连接起来，团队就可以控制完成Sprint工作的进程。所耗时长并不属于Scrum的关注范围，剩余工作量和完成日期才是利益相关因素。
提示：尽可能在一大张纸上手绘燃尽图，并将其悬挂在团队工作区域内。因为团队更倾向于去看一张大幅、清晰可见的图，而不是去打开Excel表格或其他文档工具。
Scrum的一个规则是关于每个Sprint目标的，即严格按照“完成”的定义开发潜在可交付的产品增量。
完成
Scrum要求团队在每个Sprint内构建产品功能的增量。这个增量必须是潜在可交付的，因为产品负责人可能会要求立即实现该功能。为了做到这一点，增量必须是最终产品完整的一部分，必须是“完成”的。每个增量都必须可以和前面所有增量累加起来，并且进行过彻底的测试，以保证所有的增量能兼容工作。
在产品开发中，宣称功能已经完成会让有些人认为这个功能至少拥有整洁的代码、经过重构、进行了单元测试、通过构建、完成了验收测试。另外一些人也许只认为该功能只是构建了代码。如果每个人对“完成”定义的理解不同，经验过程的另外两个支柱也就无法发挥作用。当有人说某个工作“完成”了，每个人都需要明白“完成”的含义。
“完成”解释了当团队在Sprint中承诺“进行”某个产品Backlog条目工作的意义。有一些产品不包含文档，所以“完成”的定义不包含对文档的要求。真正“完成”的增量包含了增量和其中所有产品Backlog条目必须的分析、设计、重构、编码、文档和测试工作。测试包括单元测试、系统测试、用户测试和回归测试，另外还有非功能测试如性能测试、稳定性测
试、安全性测试和集成测试。“完成”也包含所有的国际化工作。有些团队尚没有能力将实现他们“完成”定义的所有要求都包含在内。这一点必须告知产品负责人。产品在实现、投入使用之前要把所有的剩余工作都完成。
提示：“未完成”的工作常常会累积到产品Backlog中的条目，称为“未完成工作”或“实现工作”。随着这些工作的积累，产品Backlog燃尽图会比未进行累积时更精确。
最后总结
一些组织没有能力在一个Sprint内构建完整的增量。这可能是因为他们还没有自动化测试基础结构来完成所有的测试。这种情况下，需要为每个增量创建两种归类：“完成”的工作和“未完成”的工作。“未完成”的工作是每个增量中需要稍后完成的部分。因为增量符合“完成”的定义，而且产品负责人同样清楚这个定义，所以他就会知道在Sprint结束时应该检验什么。“未完成”的工作会追加到产品Backlog的“未完成工作”条目中，因此随着条目的累积，就可以准确地反映到发布燃尽图中。这个技巧为发布的进程创造了高透明度。Sprint评审中的检验和适应也符合这个透明的标准。
例如，如果某个团队没有能力对每个产品待办事项列表条目进行性能、回归、稳定性、安全性和集成测试，那么这部分的工作相对于可以完成的工作（分析、设计、重构、编码、文档、单元测试和用户测试）来说就被累积下来。比如说，这部分有六项“完成”的和四项“未完成”的工作，即团队完成了一个产品待办事项列表条目的六个单位工作（团队根据其对如何去“完成”的理解基础上估算），那么当工作完成后，就在“未完成工作”产品待办事项列表条目中追加四个单位的工作。
Sprint一个接一个进行，每个增量的“未完成”工作也就累积起来，这些累积的工作必须在产品发布之前得到解决。未完成工作以线性累积，尽管事实上这些工作根据不同组织特性会呈指数形式累积。发布Sprint可以追加到任何发布末尾，以解决“未完成”的工作。因为“未完成”的工作不是以线性形式增加的，因此追加的Sprint数目是不可预知的。
Scrum介绍 新领航创新事业部 吴楠 广东亿迅-新领航创新事业部/ 2013 . 10
功能的对比 许多企业面临的问题与挑战敏捷宣言敏捷原则Scrum 1234
许多企业面临的问题与挑战 产品投放市场的时间太慢 项目失败的比例高的离谱 对变化与变更的响应，难度大且成本高 客户体验及客户为导向很差 生产力需要大幅提高 员工士气，动力及责任感很低 人员流失率引起的问题
> 个体与交互过程与工具 > 可用的软件完备的文档 > 客户协助合同谈判 > 相应变化遵循计划
?我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。 ?欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。?要不断交付可用的软件，周期从几周到几个月不等，且越短越好。 ?项目过程中，业务人员与开发人员必须在一起工作。 ?要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。 ?无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。 ?可用的软件是衡量进度的主要指标。 ?敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。 ?对技术的精益求精以及对设计的不断完善将提升敏捷性。 ?要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。 ?最佳的架构、需求和设计出自于自组织的团队。 ?团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
Scrum （重点）的简单框架 Product Backlog Sprint Backlog Potentially Shippable Product Increment 2-4weeks 24 hours
关于腾讯敏捷框架TAPD（Tencent Agile Product Development） 腾讯是一家典型的互联网企业，互联网行业有其鲜明的特点： 1．关注用户行为 2．追求创新（腾讯有一个创新中心部门） 3．需求不确定性高 4．快速适应变化 5．快鱼吃慢鱼 腾讯在敏捷开发方面的实践大致包括3个部分： 1．产品：采用FDD，即产品特性开发驱动的一种模式，腾讯的产品会有一个明确的产品经理这样一个角色，他会负责整个产品，包括产品的验证、产品的方向、市场调研、用户调研等。FDD模式是一种非常适合产品经理来对产品做一些滚动的要求，腾讯在产品设计上引入了类似FDD这样的模式，但是也不完全是FDD，只是参考FDD，所有的开发团队都是由产品经理所归纳出来的产品特性去驱动整个产品的研发。 2．项目管理过程：腾讯采取了SCRUM，但也不完全是SCRUM，有腾讯根据自己的特点去总结的一些实践，大概的项目管理过程同SCRUM的过程是比较类似的，包括每天的晨会、迭代、timebox、每个迭代完成的时候会有showcase、回顾总结等。 3．开发实践：参考了很多XP的实践，就XP完整的实践来说会比较理想化，很多东西不一定在实际开发中能够采纳，所以腾讯也是采纳其中的某些实践，比如自动化测试和持续集成，通过这样的实践就能保证产品有一个快速发布的过程。 在腾讯的敏捷实践中，具体的实践情况是这样的： 1．故事墙：就是白板story wall，平时工作中很多团队都会使用，这些团队会把每天开发的一些产品特性采用story的方式每天都在白板里面展示出来，整个团队每天都会围绕这个白板能够清晰的看到整个产品或者整个项目的一个过程，包括整个产品特性的过程。 2．迭代总结：在每一个产品发布的时候都会有一个总结。具体的做法是，把做得好的、不好的总结出来，做得好的在下一次迭代发扬光大，做得不好的在下一次迭代就要注意改进。这样的总结是要求项目的所有成员都必须参加，包括项目的开发人员、测试人员、QA、项目经理、产品经理等，每个人都要去去总结他在上一个迭代中碰到了什么问题，通过便签纸的方式贴出来，项目经理实际上可以看成是SCRUM Master，包括站起来总结这样一些东西，包括我们下一次迭代继续发扬什么，必须要注意什么东西，最后就会得出一个excel的文档，包括上一个迭代中出的问题，具体的解决办法，都会有。 3．每日晨会：每个团队每天大概花15-30分钟，回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作（特点：是站着开会）。最早是通过白板的方式去做，就是每天项目经理组织团队成员对着白板，白板上体现项目的进展情况，通过会议可以很明确的知道昨天大家做到什么样子，今天大家计划做什么，最早的时候每个成员都是口头汇报的。实践一段时间就发现了一些问题，第一、对于一个20、30人的团队，每天要怎样做晨会，这是目前遇到的比较大的困惑；第二、晨会很容易形式化，究竟带来什么样的效率和效果，目前也在通过一些方式去研究，去探讨。第三、有一些形式上的呆板，刚开始做会觉得比较有意思，觉得这跟传统做法不一样，每天这样做并且做多了就感觉很枯燥，这也是面临一个挑战。后来腾讯也做了一些改进，比如为了让成员的参与程度更强一些，包括形式上会更强一些，现在有些团队就会采取每个人轮流主持的方式，刚开始晨会的时候我们也会通过一些好玩的东西去刺激一下某些东西，但是现在看来的话，感觉改进的还是不是很透。
Scrum在中国——企业实施情况调查实录 最近，InfoQ中文站就Scrum实施情况对国内一些企业的相关人士进行了问卷调查。从调查结果中我们选出了5个比较有代表性的案例，其中既有来自大型企业的，也有来自创业型公司的；既有采取自底向上的实施方式的，也有自顶向下实施的；有成功，也有失败。 尽管这仅仅是一个小范围调查，每个企业的具体情况也不尽相同，而成功案例所讲述的做法仅能说明在具体情况下使用者认为最合适的某种实施方式，（实际上，他们的做法都是迥异的），但通过了解其他人如何实施Scrum（无论成功也好，失败也罢），我们都可以从中汲取营养。正如Mike Cohn（《敏捷估计与规划》和《User Stories Applied for Agile Software Development》的作者）在《Scrum and XP from the Trenches》一书的代序中所说的：“我们应该了解的是哪些是优秀的实践，它们的应用范围是什么……在读过足够多成功团队的实践经验以后，你便会做好充分的准备，来面对实施Scrum和XP的过程中将会遇到的艰难险阻”。出于保护企业和个人隐私的缘故，大部分被采访人的具体信息均已隐去，其名单如下： 在交流中谈到的主要问题包括： 1. 在项目中使用Scrum的原因是什么？ 2. 在实施Scrum时采用了怎样的路线，为什么这样做？ 3. 在实施时遇到的最大的困难是什么，你又是如何解决的？ 4. 实施Scrum以后，给项目、公司带来了哪些收益？ 5. Scrum实施为何遭遇失败？ Q1. 在项目中使用Scrum的原因是什么？ 璎珞天色：
需求变化太快；产品路线图不明；提高效率；增强交流；尽快让业务部门看到结果。kaverjody： 由于当前组织中使用的瀑布开发模型所固有的一些缺陷，以及我们研发部门当前的一些问题，沿用当前的方法无法有效地解决问题或改变现状。上层经过研究论证后决定采用Scrum模式，同时通过其他的一些手段辅助，来解决当前的这些问题。包括交付新的软件发布版本时间太长、软件维护效率低成本高，等等。 张汉东： 我在07年10月份到NibiruTech的时候，初次接触敏捷。当时团队内部普遍的敏捷做法是每天按时召开的例会。当时我不太明白这个例会有什么作用？一直到11月底，强烈的好奇心让我想搞清楚这个问题。于是我找到了Scrum。因为创业团队嘛，刚开始项目管理方面只是用Trac 和我们公司自己写的管理系统。Scrum先进的思想让我们当时的管理现状黯然失色。于是我就决心在公司推广Scrum。 Q2. 在实施Scrum时采用了怎样的路线，为什么这样做？ 璎珞天色： 我们不是采用纯粹的Scrum，而是将Agile中的很多理念，包括XP的部分做法，然后结合现有的开发环境与要求，用Scrum的回顾不断地做改进，从而趟出自己的一条路。如果这个Sprint 我们回顾时觉得自己代码Review（审查）做的不好，下个Sprint就会引入新的代码Review 机制。这个Sprint觉得重复性的bug较多，下个Sprint就会引入缺陷预防机制。 我们是自底向上，先做小范围试点，再全面推广，中间对过程进行不断改进： 06年3月——06年6月（1个团队，8人左右采用） 06年6月——07年12月（3个团队，25人左右采用） 07年12月——08年1月（一个部门，6个团队，50人左右采用） 08年1月——至今（异地开发，原有团队的Scrum继续走下去。异地的配合方式，工具，流程等建设中……）
https://www.doczj.com/doc/5112002697.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开发流程介绍 SCRUM 方法是由Ken Schwaber 和Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进，名称来自英式橄榄球（在比赛中每个队员都应时刻保持对场上全局的判断，然后通过集体行动，奋力实现同一目标──胜利）。SCRUM 方法最初实践于Easel 公司(1993 年) ，现已被数十家公司数百个项目开发中应用，适用于需求难以预测的复杂商务应用产品的开发。SCRUM 提出的SCRUM Meeting、Sprint、Backlog、SCRUM Master 、SCRUM Team 、Demo 等模式已被PLOP 作为组织和过程模式（Organizational and Process Pattern）的标准。 SCRUM 的基本假设是：开发软件就像开发新产品，无法一开始就能定义Final Product 的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证项目成功。Scrum 有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进，因此，SCRUM 非常适用于产品开发项目。 SCRUM 开发流程通常以1-6 周为一个迭代周期，每个迭代周期叫做一个Sprint，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部份，开发团队必须尽力于每个周期后交付成果，团队每天用15 分钟开会检视每个成员的进度与计划，了解所遭遇的困难并设法排除，决定第二天的任务安排，这样的短会就叫做scrum meeting。 SCRUM 较为有特色的，是它特别强调开发队伍和管理层的交流协作。每天，开发队伍都会向管理层汇报进度，如果有问题，也会向管理层要求帮助解决。SCRUM方法的开发过程包括三个过程：(1) 计划和体系结构设计（确定性过程）Backlog；(2) Sprint（经验性过程）(3) 交付和巩固（确定性过程）SCRUM 过程认为一个产品的开发将一直持续下去，除非经风险评估后认为应停止。产品交付后的巩固活动类似于传统方法中的维护和改善，目的在于整理Sprint 期压力下忽略的工作，为下一阶段的开发做准备，以便轻装上阵。SCRUM 对过程的管理有很多独特的方法。SCRUM 在实践中大大提高了生产率（据软件生产率组织的Capers Jones 称可提高 6 倍）。 名词解释: 1、SCRUM Meeting:团队每天用15 分钟开会检视每个成员的进度与计划，了 解所遭遇的困难并设法排除，决定第二天的任务安排，这样的短会就叫做
龙源期刊网 https://www.doczj.com/doc/5112002697.html, Scrum敏捷开发方法实操 作者：宋至钧 来源：《建筑与装饰》2016年第06期 如今的移动互联网时代，商业周期快速变化，市场更迭日趋频繁，极致与快速已经成为对软件项目开发管理的基础要求，传统的软件开发模式越来越不能适应当前的商业需求和市场竞争，轻量型的软件迭代开发方法依托其在简化团队建设、优化项目管理的优势，已经成为商业软件项目开发的主流。Scrum敏捷开发便是其中一种能够适应各种规模、体量的软件项目开发的敏捷迭代开发模式，尤其是在开发一些快速交付项目的应用中，具有很大的优势。 1 Scrum敏捷开发介绍 Scrum一词原本是一个橄榄球术语，意为“并列争球”。Scrum敏捷开发是由Ken Schwaber 与Jeff Sutherland在1995的OOPSLA（面向对象技术的高峰会议）上正式提出，之后迅速普及。简而言之，这是一种以人为核心的，迭代、循序渐进的开发方法，强调以人为本，以需求为中心，注重交互和协作，积极响应需求变化，专注于交付对客户有价值的软件。 Scrum敏捷开发没有统一的开发策略，而是基于实用主义的原则，根据项目团队的规模、人员构成、项目目标等方面的不同，来制定灵活的策略，通常有以下几个原则：最优先的目标是尽早并持续性地交付有价值的软件，这是Scrum的核心价值；欢迎需求变化，通过频繁交付和过程控制提高产品的竞争优势；减少文档，努力实现全局视图和软件源代码一起演化；强调业务人员和项目开发人员的同步性，主动沟通、当面交流，信任团队的自我管理能力；简化；定期反思、调整和校正。 和传统的瀑布式和其他迭代式开发方法相比，Scrum敏捷开发主要有以下几个特点： 团队气氛好：Scrum敏捷开发赋予项目团队更大的自主权，将业务团队、设计团队和技术开发团队融合在一起，最大化降低团队的沟通成本，团队气氛活跃，能动性强。 灵活性强：Scrum敏捷开发方法强调灵活，主动拥抱需求变化，由市场驱动技术开发，能够迅速反馈用户需求。 开发成本低：Scrum敏捷开发方法降低了文档维护成本，交流沟通成本，同时快速交付的开发过程也降低了时间成本。 最大化生产率：Scrum敏捷开发以有价值的交付为核心目标，将产品以最快的速度送达用户，并以最快的速度应对市场的最新反馈，生产率大幅提高。 项目风险低：Scrum敏捷开发方法交付时间短，产品迭代速度快，可以有效降应对市场变化，并且迅速布局调整，降低项目风险。
Copyright ? 2010 https://www.doczj.com/doc/5112002697.html, 专业的敏捷开发社区 Scrum 中文网 Scrum介绍 Scrum中文网 https://www.doczj.com/doc/5112002697.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.doczj.com/doc/5112002697.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年代初，在美国国防部发生
ScrumWorks 使用简介 1.ScrumWroks客户端支持两种模式：一种是WEB客户端登录，在浏览器中输入： http://172.20.32.72:8080/scrumworks/login； 2.另一种是运行JAVA客户端程序，本机需要提前安装jdk1.6；点击“运行”－>“cmd” －>“javaws http://172.20.32.72:8080/scrumworks/jnlp/scrumworkspro.jnlp”。默认的用户名和密码是：administrator, password； 3.登录用户名为姓名全拼，密码是6个1。 1.JAVA客户端简介 JAVA客户端允许用户操作所有的Scrum数据，譬如添加、修改、删除、移动Backlog条目，从Excel中导入或导出数据到Execl，后台数据备份，阻碍(Impediment)管理等。
JAVA客户端桌面视图： 右侧是未分配的Product Backlog，通过Release Version进行分类。 左侧是以时间排序的Sprint列表以及对应的Sprint Backlog。可以查看多个团队的迭代列表。 左侧的Backlog和右侧的Backlog可以根据需要，用鼠标来回拖动，非常方便。 Web客户端提供了一个轻量级的基于浏览器的访问方式，可以从任何一台装有Web浏览器的设备上访问。它提供了一个非常个性化的总结性的Web页面，不仅有Sprint 的Burndown Chart，还单独区分“用户自己的任务”、“全部任务”及“所有阻塞”, 方便单个用户更新任务状态、剩余工作量，添加备注，查看阻碍等。 简单高效的Sprint管理 ScrumWorks Basic提供了一个单独的Sprint管理接口，让我们的每个Sprint 都变得有条不紊。 每次新开一个Sprint时，会有一个单独的对话框，只需要输入起止时间、Sprint 名称、Sprint目标，以及选择对应的Scrum 团队即可。在Scrum开发模式下，为每个Sprint起一个名字，不但可以增加团队软件开发的乐趣，提高大家的参与程度，还可以记录下Scrum Team当时的心情，这点非常重要，而ScrumWorks Basic正好提供了这个接口。列举我们的几个Sprint名称，创意来自于《加里森敢死队》： ?Sprint1---"兵不厌诈（the Big Con）" 因为大家第一次采用Scrum, 对这个Agile流程都很期待，同时呢，对于怎么做，如何用，还很模糊 ?Sprint2---"越狱记（Breakout） 经过了第一个Sprint后，大家干劲十足，士气高涨，认为我们可以在第 二个Sprint取得重大突破（breakout） ?Sprint3---"虎口余生（Hours to doom day）" 这个Sprint里面有很多技术难点需要破解，如果解决不了，那么后面的 工作就无法进行，将是非常关键的一次攻坚战。 ?Sprint4---"大结局(The Big End)" 这次计划会议，作为Scrum Master，自己因为有事没有参加，汗！但大 家认为工作基本差不多可以做完了，起了个结局的名字。 每天开站立例会时，可以把如下图所示的Sprint明细窗口用投影仪直接投放到墙上。让大家可以看到Sprint目标、Burndown Chart、Sprint Backlog 条目的状态及剩余时间等，提高沟通的效率和紧迫感。
敏捷实践（二）－荷兰铁路公司的分布式Scrum开发（项目如何启动） Scrum为项目执行提供了可靠的、已被证实的基础。但是，在每个项目中，Scrum都必须根据具体需求和环境进行调整，这是项目成败的决定性因素。在这篇文章中，我们将会介绍我们如何成功地完成了一个大型的（20人年，超过十万行代码）、分布式（开发人员位于印度和荷兰）Scrum项目，而这个项目曾经在传统开发方式下被废弃过。为了帮助读者顺利运作大规模项目，在这里我也会历数我们的经验教训，包括：项目启动、找到合适的产品负责人、估算的重要性、有效沟通、测试、文档。本篇介绍“项目如何启动” 项目开始的时候，我们在第一个sprint开始前安排了一个启动阶段，耗时三周，准备好了sprint中所需的一切。这个启动阶段由一个项目经理，一个架构师和一个Scrum Master 参与完成。 选择产品负责人是个很有难度的事情，我们找不到一个人能够有时间、具备领域知识、而且有权利设置需求优先级。我们提名了两个业务分析师来一起承担产品负责人的职责。他们能抽出时间来，而且他们从前也参与过构建PUB的工作，所以业务知识很丰富，足以担当起产品负责人的角色，为多组客户充当优秀的代理。有关优先级的和范围的高级决策，是由客户委任的项目经理负责，但是他时间不够用，对于需求的理解也有所欠缺。一般情况下大家的配合还可以，但偶尔项目经理也会对（他所缺席的）计划会议上制定的优先级进行调整，于是这个会议就得重新来过。在理想状态中，对优先级有最终决策权的人应当每次都参加 sprint计划会议。 因为先前有人试着构建过PUB系统，所以有些部分的详细需求文档已经是现成的了。它们遵守了MIL标准，不过其形式不适于敏捷计划和估算，因为在敏捷开发中，需求应当被组织成小块的段落，每一块都可以在一个sprint中进行实现、测试和演示，但是现有的文档与此要求不符。产品负责人也没有多少编写用户故事的经验，为了解决这个问题，Scrum Master帮他们弄出了最原始的产品backlog，里面放着一些细粒度的、经过估算的用户故事，供前几个迭代使用。 我们所构建的软件只是某个大型软件系统的一部分，它还包括很多相关的软件系统，那些系统负责显示信息，还要在车站内安装相关显示设备。我们得保证每件事情都可以按时完成，才能把复杂的系统理顺。所以需要有一个整体的计划方案。经历了几次迭代，我们对系统的各个功能都按照自己的最大能力做出估算，这个问题也解决掉了，而且也有了一个比较靠谱的生产率。于是就可以用发布版本燃尽图来记录和沟通进度了。这里我们学到的东西就是，即使是信息量很少的情况下，有估算也比没估算好。
指南 Scrum Scrum指南 2010年2月 Scrum由Ken Schwaber和Jeff Sutherland开发并维护 版权说明：本文由社区志愿者翻译，版权归原著者所有，Scrum中文网仅对其中的用词进行了统一和部分错误进行了更正。 概要 Scrum基于业界认可的最佳实践，这些实践已在过去的几十年被使用并证实有效。之后，Scrum被置于基于经验过程的理论中。正如Jim Coplien一次对Jeff所说：“每个人都会喜欢Scrum；因为这是当我们被逼到墙角时的自然反应。” 人 在千千万万对Scrum做出贡献的人中，我们要特别感谢那些在其最初10年提供帮助的人们。首先，要提到Jeff Sutherland及与之工作的Jeff McKenna，Ken Schwaber和Mike Smith 还有Chris Martin。Scrum在1995年的OOPSLA上首次被正式介绍和发布。在之后5年中，Mike Beedle和Martine Devos做出了重大贡献。还有所有其他人，没有你们的帮助，Scrum不会被提炼至今天的高度。 历史 在软件开发的世界中，Scrum的历史已经算是很长了。我们对首批尝试和提炼Scrum的公司：Individual，Inc.，、Fidelity Investments和IDX（现在的GE医疗）表示致敬。目标 自从上世纪90年代初期，Scrum方法就已经应用于开发复杂的产品。本篇文章介绍了如何应用Scrum构建产品。Scrum不是一种过程，也不是一项构建产品的技术，而是一个框架，在这个框架里可以应用各种过程和技术。Scrum的作用就是让开发实践方法的相对功效显现出来以便随时改进，同时也为开发复杂产品提供了框架。 Scrum理论 Scrum是以经验过程控制理论为依据，采用迭代、增量的方法来提高产品开发的可预见性并控制风险。Scrum的三大支柱支撑起每个经验过程控制的实现。
SCRUM敏捷管理知识 一、什么是scrum Scrum是一种用于开发和维持复杂产品框架，是一种增量、迭代开发过程。在这个框架中，整个开发过程由若干个短迭代周期构成，一种短迭代周期称为一种Sprint，每个Sprint 建议长度是2到4周(互联网产品研发可以使用1周Sprint)。在Scrum中，使用产品Backlog 来管理产品需求，产品backlog是一种按照商业价值排序需求列表，列表条目体现形式普通为顾客故事。Scrum团队总是先开发对客户具备较高价值需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级需求进行开发。挑选需求在Sprint筹划会议上通过讨论、分析和估算得到相应任务列表，咱们称它为Sprintbacklog。在每个迭代结束时，Scrum团队将递交潜在可交付产品增量。Scrum来源于软件开发项目，但它合用于任何复杂或是创新性项目。 Scrum流程如下图： SCRUM框架涉及3个角色、3个工件、5个活动、5个价值，详细阐明如下： 3个角色 1.产品负责人（ProductOwner） 2.ScrumMaster 3.Scrum团队
3个工件 1.产品Backlog（ProductBacklog） 2.SprintBacklog 3.产品增量（Increment） 5个活动 1.产品Backlog梳理睬议（ProductBacklogRefinement） 2.Sprint筹划会议（SprintPlanningMeeting） 3.每日站会（DailyScrumMeeting） 4.Sprint评审会议（SprintReviewMeeting） 5.Sprint回顾会议（SprintRetrospectiveMeeting） 5个价值 1.承诺–乐意对目的做出承诺 2.专注–把你心思和能力都用到你承诺工作上去 3.开放–Scrum把项目中一切开放给每个人看 4.尊重–每个人均有她独特背景和经验 5.勇气–有勇气做出承诺，履行承诺，接受别人尊重 SCRUM理论基本 Scrum以经验性过程控制理论（经验主义）做为理论基本过程。经验主义主张知识源于经验,以及基于已知东西做决定。Scrum采用迭代、增量办法来优化可预见性并控制风险。Scrum三大支柱支撑起每个经验性过程控制实现:透明性、检查和适应。Scrum三大支柱如下：第一：透明性（Transparency） 透明度是指，在软件开发过程各个环节保持高度可见性，影响交付成果各个方面对于参加交付所有人、管理生产成果人保持透明。管理生产成果人不但要可以看到过程这些方面，并且必要理解她们看到内容。也就是说，当某个人在检查一种过程，并确信某一种任务已经完毕时，这个完毕必要等同于她们对完毕定义。
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.doczj.com/doc/5112002697.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.doczj.com/doc/5112002697.html, and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative
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的企业可能发现这样会影响他们制定优先级和需求的方法。 为保证产品负责人的工作取得成功，企业中的所有人员都必须尊重他的决定。任何人都不得要求团队按照另一套优先级开展工作，团队也不允许听从任何人带有威胁恐吓性的指令。产品负责人
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），迭代回顾会议。