继以前关于Scrum培训的总结之后，有人提出总结不够全面。所以依据自己更深入的了解与实践之后，进行一个更全面的总结。
什么是Scrum？
Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog 。 在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。
一个简单的框架
三个角色
产品负责人（Product Owner）
Scrum Master
Scrum团队
六个时间箱
Sprint
发布计划会议（Release Planning Meeting）
Sprint计划会议（Sprint Planning Meeting）
每日站会（Daily Scrum Meeting）
Sprint评审会议（Sprint Review Meeting）
Sprint回顾会议（Sprint Retrospective Meeting）
四个工件
产品Backlog（Product Backlog）
发布燃尽图（Release Burndown Chart）
SprintBacklog（Sprint Backlog）
Sprint燃尽图（Sprint Burndown Chart）
SCRUM理论基础
Agile is NOT a methodology, process or framework. It's a thought to deal with the challenges faced by software developing.
challenges:
1) unstable requirements
2) uncertainity
3) unacceptable quality
4) demoralized team
To resolve the problems. Agile has the famous manifesto:
Individual and interactions Over process and tools
Working software Over comprehensive documentation
Customer collaboration Over contract negotiation
Responding to change Over following a plan
Please pay attention that it is "Over", but not "replace". Agile trys to emphasis some key points but do not reject documentation, plan, contract those kinds of things. :-)
应用Scrum不要死记框架，更重要的是理解背后的Aigle思想和对应的Scrum理论基础。
Scrum是以经验过程控制理论作为理论基础，通过迭代、增量的方法来增强产品开发的可预见性，并控制风险。Scrum经验过程控制理论的实施由三大支柱支撑：
第一：透明性（Transparency）
透明性要确保生产过程中影响工作成果的各个方面对管理工作成果的人来说是透明的。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成定义。
第二：检验（Inspection）
开发过程中的各方面必须做到足够频繁地的检验，确保能够及时发现过程中的重大偏差。
第三：适应（Adaptation）
如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么检验员就必须对过程或是材料进行调整。调整工作必须尽快实施以减少进一步的偏差。
Scrum中通过三个活动进行检验和适应：每日站会是用来检验完成Sprint目标的工作进展，调整以优化次日的工作价值。另外，Sprint评审和计划会议是用来检验完成发布目标的工作进展，调整以优化下一个Sprint的工作价值。最后，Sprint回顾会议是用来评审已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。
Scrum的特点
Scrum规定了一个非常简单的开发流程。
Scrum是现有设计流程的总结。
Scrum以团队为基础，是一种在需求迅速变化情况下迭代地、增量地开发系统和产品的方法。
Scrum是一个控制由利益和需求冲突导致的混乱的流程。
Scrum是改善交流并最优化合作的方式。
Scrum是一种检测产品开发和生产过程中障碍并将其去除的方式。
Scrum是最大化生产率的一种方法。
Scrum适用于单一的项目到整个组织。Scrum可以控制并组织多个具有相关性的产品开发以及拥有超过千名开发者和执行者的项目实施过程。
Scrum能让每个参与者都对自己所做的工作以及自己做出的贡献感到骄傲，并让他们发挥到最佳水平。
Scrum三个角色及其职责介绍
每个Scrum团队包括3个角色： 产品负责人（Product Owner）, ScrumMaster和 Scrum 团队。
产品负责人--作为产品的owner，代表客户决定产品需求以及优先级，是Team对于需求的唯一诉求人，帮助团队屏蔽传统的需求纠纷干扰。迅速的需求解释反馈，提高团队的效率。
产品负责人的职责：
确定产品的功能，负责维护产品Backlog。
决定产品的发布日期和发布内容。
为产品的投资回报率(ROI)负责。
根据市场价值确定功能优先级。
在每个Sprint开始前调整功能和调整功能优先级。
在Sprint结束时接受或拒绝接受开发团队的工作成果。
产品负责人是一个人，而不是一个委员会。可能会有一些委员会向产品负责人提出建议或影响他的决策，但要想改变某条目的优先级必须先说服产品负责人。实施Scrum的企业可能发现这样会影响他们制定优先级和需求的方法。
为保证产品负责人的工作取得成功，企业中的所有人员都必须尊重他的决定。任何人都不得要求团队按照另一套优先级开展工作，团队也不允许听从任何人带有威胁恐吓性的指令。产品负责人所作的决定需要通过产品Backlog内容和优先级使其可视化。这种可视化要求产品负责人全力以赴，同时也使其成为一个费心费力但又值得去做的角色。
ScrumMaster--帮助团队屏蔽外接干扰，热别是team内外的管理干扰。使团队focus在开发生产中。
ScrumMaster 作为Team Leader和Product owner紧密地工作在一起，他可以及时地为团队成员提供帮助。他必须:
保证团队资源完全可被利用并且全部是高产出的。
保证各个角色及职责的良好协作。
解决团队开发中的障碍。
做为团队和外部的接口，屏蔽外界对团队成员的干扰。
保证开发过程按计划进行，组织每日站会、Sprint计划会议、Sprint评审会议和Sprint回顾会议。
ScrumMaster 除了主持每日站会（Daily Scrum Meeting）之外，还有三个主要职责：
ScrumMaster 需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估算可能已经发生变化。ScrumMaster 需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图（Burndown Chart）。
ScrumMaster 还必须仔细考虑同时在进行开发的任务数，同时进行的工作需要做到最小化，以实现精益生产率的收益。
该ScrumMaster 需要找出阻碍团队的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。比如：一个电信公司最近实施了Scrum，但后来发现只有两个问题和Scrum Team有关，其他的全是公司的问题需要管理层关注。
最后但并非最不重要， ScrumMaster 可能会注意到，个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清，或通过内部的沟通解决，或向管理层和HR寻求帮助解决。ScrumMaster 必须注意去确保团队资源完全可被利用并且全部是高产出的。
Scrum 团队--专注的，心无杂念的开发团队
Scrum团队的职责是在每个Sprint中将产品Backlog中的条目转化成为潜在可交付的功能增量。
Scrum团队的一些特点：
1. Scrum团队的规模控制在5-9个人。
如果成员少于5人，那么相互交流就减少了，团队的生产力也会下降。更重要的是，团队在Sprint中可能会受到技能限制，从而导致无法交付可发布的产品模块。如果成员多于9人，那么成员之间就需要太多的协调沟通工作。大型团队会产生太多复杂性，不便于经验过程控制。对于大型项目来说，可以采用多个小的Scrum团队，通过Scrum of Scrums解决团队间的沟通协调问题。
2. Scrum团队是跨职能的团队。
团队成员必须具备交付产品增量所需要的各种技能。团队成员常常具备如编程、质量控制、业务分析、架构、用户界面设计或数据库设计等的专业技能。在Scrum团队中没有头衔的概念，每个人都必须尽心尽力完成Sprint目标。团队中不允许包括测试或业务分析等在特定领域工作的子团队。
3. Scrum团队是自组织的。
任何人，包括ScrumMaster都没有权利规定团队如何将产品Backlog转化成可交付的功能增量，而是由团队自己确定。每个团队成员利用自己的专业技能，解决遇到的问题。这种协同配合提高了团队整体效率。
团队的构成在Sprint结束时可能会发生变化，每次团队成员的变化，都会降低通过自组织而获取的生产力。因此，改变团队构成时务必要谨慎。
什么是用户故事？
用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
角色：谁要使用这个功能。
活动：需要完成什么样的功能。
商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：
As a <Role>, I want to <Activity>, so that <Business Value>.
中文：
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
举例：
作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
用户故事的六个特性- INVEST
INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable
一个好的用户故事应该遵循INVEST原则。
独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。
任务板（墙）Task Boards
任务板（墙）展现了我们在Sprint过程中所有要完成的任务。在Sprint过程中我们要不断的更新它。–如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后，如果估计发生了变化，任务会根据变化在任务墙上做相应的调整。
通常的任务板是下面这个样子:
任务墙被横竖分割成许多格子，每一行代表一个Prouct backlog项也可以称作一个用户故事，在Sprint计划会议期间，Scrum团队会分解每个用户故事得到许多的Sprint backlog项，每一项作为一个任务卡放到任务墙上。
每个任务卡从To Do这一列开始。常用的列如下：
用户故事–根据产品需求分解出的一个个用户故事.
To Do–需要完成的，但还未开始的任务。
Doing–刚刚开始，或正在进行中的任务。
doing这一栏还是可以细分的，如下是可选的一些栏：
Coding: 正在编码
Testing: 正在进行测试
Done–所有已经完成的任务卡都会放在这里，Sprint结束的时候可以拿掉它们。
Scrum的四个工件
在Scrum中有四个工件: 产品Backlog（Product Backlog），发布燃尽图（Release Burndown Chart），Sprint Backlog 和Sprint燃尽图（Sprint Burndown Chart）。
产品Backlog（Product Backlog）
产品backlog是一个产品或项目期望的、排列好优先级的功能列表。优先级由商业价值、风险、和必要性决定。产品负责人负责产品Backlog的内容、可用性和优先级。产品Backlog永远不会是完整的，最初的版本只列出最基本的和非常明确的需求，这些需求至少要足够一个Sprint开发。随着团队对产品，以及它的客户或用户的了解，产品Backlog在不断的演进，所以产品Backlog是动态的，它经常发生变化以确保产品更合理、更具竞争力和更有用。只要产品存在，产品Backlog就存在。
产品Backlog中包含开发和交付成功产品需要的所有条件和因素。 产品Backlog条目的属性包括描述、优先级和估算。产品Backlog的条目可以包括功能性需求（使用业务语言描述，以用户为中心），也包括非功能性需求（从技术层面出发，产品需要具备的能力）。使用用户故事来描述产品Backlog条目是一个非常有效的实践，我们通常也把验收条件或验收测试作为产品Backlog条目的一个属性。
优先级高的产品Backlog条目需要立即进行开发。优先级越高的条目越详细，优先级越低的条目越概括。
发布燃尽图（Release Burndown Chart）
在Scrum项目中，团队通过每个Sprint结束时更新的发布燃尽图来跟踪整个发布计划的进展。发布燃尽图记录了在一段时间内产品Backlog的总剩余估算工作量的变化趋势。X轴代表的项目周期，以Sprint为单位， Y轴代表的是剩余工作量，通常以用户故事点、理想人天或者team-days为单位。
Sprint Backlog
Sprint Backlog 是团队承诺在当前Sprint完成的任务列表。Sprint Backlog中的任务是由产品Backlog选取的需求条目细化和分解而来，这些任务要确保将产品Backlog条目转化为潜在可交付的产品增量。在Sprint的中选择完成哪些产品Backlog条目取决于产品Backlog中条目的优先级以及团队完成这些不同条目所花费时间。选择哪些条目和多少条目放入Sprint Backlog由团队决定。因为由团队承诺去完成这些任务，所有必须由他们自己来做决定。
在整个Sprint过程中，团队持续的修改Sprint Backlog，一些新的任务也会在Sprint过程中涌现出来。因为它涉及到个体要完成的任务，所以有时候会遗漏一些任务，或者一些任务不再需要了，亦或某项任务耗费的时间超出了估算或者低于估算。当出现新任务时或者工作量发生变化时，团队需要将其更新到Sprint Backlog中去。随着任务进行或者被完成，需要更新每项任务的剩余工作估算小时数。如果某项任务失去开发的意义，就可以将其除去。在Sprint内只有团队可以对Sprint Backlog进行修改，也只有团队可以对列表的内容或估算进行修改。Sprint Backlog是高可见度的，是对团队计划在当前Sprint内完成工作的实时反映，并且，该列表只属于团队。（评估永远不能代替实际，实际的变动需要实际的反馈。如果新发现的工作量大到超出了当前Sprint的容量，有可能需要调整到下一个Sprint）
Sprint燃尽图（Sprint Burndown Chart）
Sprint Burndown Chart 显示了Sprint中累积剩余的工作量，它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量，X轴代表的是Sprint的工作日。
在Sprint开始的时候，Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成，但没有完成的任务的工作量是累积工作量，Scrum master 会根据进展情况每天更新累积工作量，如果在Sprint结束时，累积工作量降低到0，Sprint就成功结束。
Product Backlog 功能点被放到Sprint的固定周期中，Sprint Backlog 会因为如下原因发生变化:
1. 随着时间的变化，开发团队对于需求有了更好的理解，有可能发现需要增加一些新的任务到Sprint Backlog中。
2. 程序缺陷做为新的任务加进来，这个都做为承诺提交任务中未完成的工作，这些也许可以分开进行跟踪。
Product Owner也许会和Scrum team一起工作，以帮助team更好的理解Sprint的目标，ScrumMaster和team也许会觉得小的调整不会影响sprint的进度，但会给客户带来更多商业价值。
由于在Sprint的刚开始的时候，增加的任务工作量可能大于完成的任务工作量，所以燃尽图有可能呈上升趋势。
Scrum项目管理工具
VersionOne
VersionOne市场排名第一。支持SaaS模式和本地安装模式，web客户端，支持Scrum, Extreme Programming, DSDM and Agile UP等多种敏捷开发方法。团队可以使用“V1：敏捷团队”来管理产品和sprint backlog，通过交互式的“任务板（taskboards）“和"测试板（testboards）" 进行每日开发活动，藉由报表和燃烧图查看进度，以及其他活动。通过这些功能，“V1：敏捷团队”的用户可以做到：
从电子表格中快速导入故事与缺陷，管理合并后的产品backlog。
利用简单的多条目拖放操作，方便地完成计划制定、对故事划分优先级。
使用电子白板界面同时制定多个版本的发布计划，提高效率。
通过交互式的任务板（Taskboard）、测试板（Testboard）、每日Scrum dashboard来对版本和sprint进行可视化追踪。
针对版本和sprints的关键敏捷度量数据生成图表，如Burndown、Velocity、Estimate trends、Cumulative Flow Reports。
官网：http://www.versionone.com/index.asp
Rally
Rally市场排名第二！SaaS模式，支持用户需求的筛选、扩展的筛选标准、改进版本剩余时间表、新的通知规则（notification rules），以及用于Eclipse和CruiseControl.NET的连接器。功能：
程序管理
项目管理
需求管理
测试管理
缺陷管理
产品管理
产品支持管理
社区管理
官网：http://www.rallydev.com/
ScrumWorks
ScrumWorks市场排名前3甲，有两个种版本，Basic是免费版，Pro是收费版。支持BS和CS两种模式，服务器端是要安装的。支持对Bugzilla和Jira的集成，带有主题过滤功能的burndown图表，以及其他辅助了解项目状况和走势的功能，还有众多别的特性。ScrumWorks Pro与Bugzilla和Jira的集成，体现在它可以导入两者中的条目作为backlog条目，并且可以像对其他backlog条目一样，对这些条目 进行操作。可以使用搜索来选择感兴趣的条目，并进行单独或多项导入操作。Burndown图表现在可以按照主题 进行分组。将backlog按照主题进行组织后（类似于web 2.0中使用标签），你可以高亮或是过滤这些backlog，并且能够使用同样的主题针对burndown图进行过滤。
官网：http://www.danube.com/scrumworks
结束语：
Scrum希望最大限度的减少项目开发中的纠纷，使团队专注于项目开发和任务提交。但是现实永远比理想残酷，Scrum并不能完全避免纠纷。如果纠纷发生了，请用敏捷的思想面对问题并加以解决。 :-)
