参加一个敏捷的培训，发了一份资料，不知道讲的是什么，直接翻译出来看看，也许会有点收获！
Scrum in five minutes
译注：scrum是敏捷开发的一种流程模型，它将敏捷开发分为几个步骤，这里是介绍这种敏捷开发的过程。
Scrum和敏捷方法最近是比较热闹的话题
一个简单的管理复杂项目的方法：
老的方法集中精力在持续的srack上，而scrum是一直将目标放在发布有价值的商业版本。
市场的变化是很快的，外部的因素变得更加复杂，而scrum将让它变得可以适应变化。
Scrum直接面向项目中的开发人员，而不是技术
Scrum简单的说，就是－－这是一种实践和测试的智能组合方法
试问一下：
1、你想更高效的处理需求变化吗？你想推进你的设计激情以及增进客户与项目之间的交流吗？
2、你已经准备介绍一种新的领导力文化吗？也就是，更换角色以及工作方法，如从管理人员那里把一些职责转化到项目组中。
3、你将会跟随类似IBM，微软和Xerox这样公司的脚步吗？而且能成功的指出你的软件开发流程中的错误！
如果你的回答是“YES”，那你就确实要读一读了！
Scrum介绍
Scrum是基于Sprint的，而Sprint就是一种集中努力，以30天为周期，完成固定目标（的开发流程）。
一个产品主人（Product Owner）为所有的产品编写修改计划，并且对可能的功能做出优先级。
产品主人的工作结果就是产品存货（Product backlog），其实就是一个固定优先级，要做什么的表单。在每个sprint之前，具有最高优先级的目标就转化为sprint backlog!
和用户一起，一个开发组的成员固定在5－9人之间。在与产品主人进行讨论时，Sprint的目标就开始定下来，然后，标明了优先级的功能就分解成为具体的任务。而项目组是自我管理的，而且组员对结果是有连带责任的(joint responsibility)！
Scrum主人（Scrum Master）对开发组进行培训，消除所有可能的阻碍，并固定工作量，以确保项目组有最可能好的环境来实现Sprint的固定目标。
每一个Sprint都要增加产品的市场价值，以及增加新的功能，并增强它们，以便产品可以发布给用户！
角色
Scrum组
Scrum组是实际的工作者，是问题的解决者和特性功能的设计者。根据经验，以及研究显示，通常一个组的成员固定在5－9之间是最好的工作形式。
组员决定工作如何安排，以及指定的任务如何分配。这里没有给定的项目角色，每个成功必须可以与另外的成员切换任务。自然的，这样不会防碍一些个别成员在其一领域的专长。
产品主人
产品主人就是表达客户声音的人，并从商业的角度，度量Scrum组的工作是否是在做正确的事。产品主人管理产品的库存（也就是需求库存，后面都是这个意思），即一个当前要完成事项的任务列表。该任务列表是根据哪些更有利的原则来处理它们。文档对组织的所有人都是可见的，这样所有的人就可以感觉到以后的发布产品是什么样子的。
产品的主人通常是客户，但也可以是内部组织的一部份。整个任务需要理解有关工程，市场以及商业的处理流程。
Scrum导师（Master，这里就是指导Scrum开发的人，可以理解为导师）
Scrum导师是一个教练，仲介人，看管者的组合。Scrum导师就是每天与项目组一起参加每天的简短会议，每天的Scrum。当项目组以外的人有一些重要的事与项目进行讨论时，Scrum导师就要确保开发人员尽可能少的分散他的工作精力。
Scrum导师总是采取当前的情形来处理工作，总是集中精力为项目组提供最好的环境来实现Sprint中给定的任务。
在每一个Sprint之后后，Scrum导师要招开一个对Scrum组的评估会，称为Sprint回顾会，在这个会议中，要经验和总结要回顾一下。目的就是为了提升项目组的知识，并增强项目组在下一个Sprint中的动力。
流程
创建需求储存（backlog）
产品主人编辑所有的需求和特殊功能，这些是产品变更的基础，例如一个新功能，bug的修改。在目标制定以后，每个功能实体就分解成一些小片段。每一个小片段
应该是在一个小的方面来创建商业价值的，而且是可以用小部份来以子集的形式发布的。（就是可以类似补丁的形式发布）
同时，一个以优先级排序的列表应该完成，这在一点上，产品主人是个人做的这个决策。这些修改或者发布应该以什么样的优先级来给定？这个结果是一个要去做什么的决策表，它就是由市场的要求以及用户随着时间的流逝会改变的需求所决定的。当是时候来进行一个新的Sprint时，产品主人“冻结”任务列表中最首要的条目，并招集项目组开一个Sprint开工会。
Sprint阶段
在Sprint的30天里，最首要的事是帮助创建一个Sprint需求库。当任务和需求已经被决定时，产品主人就要放手让开发人员去做了。
从这时起，Scrum组就在自己的责任驱使下工作了。如果组已经被安定，工作就是自我组织的了。
每日Scrum
每天，在同一时间，Scrum导师以及Scrum成员会有一个简短的会。这个会的目的就是为了排除所有阻碍项目组进度的因素。每一位与会者都应该回答这三个问题：
1、在上次会议之后，你做了些什么？
2、你在次会议到下次会议之间，你准备做什么？
3、有任何因素阻碍你做计划中的事吗？
前面两个问题给了所有与会者对项目进度的整体了解。第三个问题为困难的解决提供了一个基础－－从修正电脑的鼠标到公司管理的改进。
任何人都可以参与会议的旁听，但只有Scrum主人和项目组成员才可以讲话。
演示和评估
在每一个Sprint结束时，会有一个演示。这个演示就是在一个大的功能组合并以前看看软件的功能是否可以运行，包括产品主人在内，用户和代表们协同管理。这是轮流评估会议的基础，也是下一个Sprint的开始。
一个burndown图是以天为单位用于标识计划好的省下的工作。这个图表非常清楚的展示了以小时为单位，一个Sprint所搞定的工作。
敏捷开发方法
什么叫做敏捷开发是以Scrum来划分的，它集中于一些工作方法和工作箱：
＊提高对市场的需求和需要的反应能力
＊削减浪费和等待
＊减少员工工作压力的同时增加产出
所有这些，只要是在工作中能与敏捷走在一起的都会是被关注。可以不夸张的说，整个IT工业都面临一个敏捷潮流。哲学上已经总结了下面这张表：
重要的 更重要的
过程与工具 独特与交互
详细的文档 可工作的软件
合同和谈判 与客户一起合作
按计划办事 适应变化
从理论上看，敏捷是对流程有好处的，但在实践中并不总是这样。所以敏捷方法也被描述成经验化的东西－－它们完全基于实际的经验以及那些验证过的工作方法。
敏捷方法的一个明确概念就是适应外部因素的变化。当老的方法去预计和试着预测将来的需求时，敏捷方法积极而快速的去适应新的需求，与“拥抱变化”的格言走在一起。唯一用来衡量成功的方法就是可工作的产品。
另一个重要的原则就是简单和精益思想。根据敏捷的思想概念，大规模的项目不是它们自己可以描述的。取而代之的，它更有可能最大化工作量，而这些工作其实是不需要的。这些就包括花时间写一些无用的文档，
其它的敏捷方法
与Scrum一起，极限编程是一个众所周知的敏捷方法。极限编程（XP）很难实现，它更多的只是一个方法，一个在项目中应该怎样做的方法。在12条固定的基础实践中，在编码以前，结队编程和输出测试用例是两个好的例子。
另一个敏捷方法就是益精开发，它源于制造工业的Just-in-Time，以及益精产品概念。益精开发更多的是在管理级上处理公司的开发活动。
这些敏捷方法可以认为是一些补充：
＊精益开发处理一些在整个开发组织中要理解的原则
＊Scrum处理项目应该如何组织和计划、
＊XP处理编码应该如何工作
精益敏捷的常见问题：
会不会因为每个人做的与他们设计的不一样而导致Scrum走野了呢？会存在这样重要的风险吗？
从大量的项目经验中表明，这样的情况不会发生。原因是这些原则很容易理解，而且项目组每30天就会有一个可用的版本发布。他们共同为所有的代码承担责任，同样会让Scrum开发组的成员更加激情的去固化例程和规则。
Scrum只能用于小项目吗？
不，这些方法可以通过把几个小项目组放在一起合并在一个大规模的项目。一个称为Scrum中的Scrum可以包括几百个开发人员，组织和管理几打的Scrum组。
我应该如何开始？
一个常见的方法就是先一个或者几个人去学习一下，成为Scrum导师。现在很多公司都提供这样的课程。另一个可选的方法就是开始一个引导项目，让几个有过Scrum经验的开发人员在组中承担导师的角色，例如Scrum导师或者Scrum主人。
如果不能按完成工作会怎样？
Scrum不充许发布日期更改！如果你落后了，你就从Scrum组的产品库中删除你的功能；如果你超前完成了，你就找产品主人要更多的功能点来实现。
一个Scrum必须是30天吗？
不是必须的，但每个Scrum的时间在整个项目的开发过程是应该是相同的。另外，经验告诉我们30天（大概一个组是1000个有效的工作小时），在舒适的工作环境和适应性之间是一个比较好的折衷。
项目经理应该做什么？
Scrum中没有这个角色。一个产品的经理更倾向于管理员，通常是以产品主人的角色出现。那些最合适去执教的人很可能更适合成为Scrum导师。
Scrum如何和CMM混合？
好的CMM方法在Scrum项目中是需要的，但通常没有专一的CMM角色。运行中的CMM流程是一个自我管理和进化的组。对于一个小的CMM流程，持续集成和自动化测试应该尽可能多的使用。
Scrum方法只适应软件开发吗？
不是。这些方法可以适应所有不同类型的项目－－例如报纸生产或者医疗开发。
Scrum这个词是从哪来的？
Scrum这个词是从橄榄球中来的，它描述的是紧密的肩并肩一种橄榄球阵形，用于所有队员一起将球向前推进。这个词最先被Takeuchi和Nonoka在一篇著名的文章使用，这些文章Harvard Business Review上，用来描述在日本的最成功的产品开发项目。
词汇表
adaptive 适应的 可适应的，在这里，就是项目的目标或者计划应该适应外部因素的变化。
Burn-Down Char 一个用于监控在一个Sprint中，一个片段的软件工作还有多少没有实现。
Daily Scrum 简短的，每天会议（大概15分钟），在Scrum导师和Scrum成员之间招开。它的目的就是为了保持工作流程顺利的进行并清除所有的障碍。
Empirical，基于经验的。
Agile development 一种软件开发的理论。它重点集中在，适应力，想法和实现的短路径，简化的合作。敏捷开发方法的一个例子包括XP和Scrum。
Sprint Retrospective 每个Sprint完成之后的回顾会议（大概3个小时）。Scrum导师和Scrm主人回顾哪些做的好的，哪些在下个Sprint中还要增加的。
Predictive 前瞻性，在这里，是指产品的目标和计划基于预后的在项目开始以前所确定的外部因素。
Product backlog 就是当前要做的任务列表，它包括了项目的目的和优先级。由产品主人管理。
Product Owner，产品主人，他是对产品的backlog负责的人，而且他要确保项目是朝着商业利益最大化的目标去的。
Release backlog，与Product backlog一样，但它是指已经完成了的。
Scrum Master Scrum导师，可以认为是Scrum组的组长。
Scrum Team 在这里就是工作的生力军，在Scrum项目中就是软件的设计者，自己管理自己的工作，不需要正式的组管理员（组长）。
Sprint Scrum开发组的一个承诺的迭代，通常是30天，用于集中精力实现项目的Sprint backlog中制定的目标。
Srpint backlog 一个为一次Sprint制定的任务列表，固定了由产品主人制定的具有最高优先级的目标，它的最终形式是在一个Sprint的开始的会议上给出的，这个会议由产品主人和项目组一起参与。
Sprint Review 一个非正式的会议（大概4个小时），在每次的Srping结束之后。开发组必须参加，如果可能，要给管理者，客户和产品主人演示功能，说明在这个Sprint中完成了那些事情。
TimeBox 一个时间周期，在这个时间周期中，一些东西应该开发出来。一个Sprint就是时间周期所思考的结果。最后期限不应该被超过－－否则就删除一部给定的份任务。