1. 概述
Scrum是跨职能团队以迭代、增量的方式开发产品或项目的一种开发框架。
它把开发组织成被称为Sprint的工作周期。这些迭代每个都不超过4周（最常见的是两周），并且无间歇地相继进行。Sprint是受时间箱限制的，无论工作完成与否它们都会在特定日期结束，并且从不延长。通常由Scrum团队来选定一个Sprint的时长，并且对于他们所有的Sprint都使用这一时长，直到这个团队能力提高，可以使用较短周期。
在每个Sprint的初始，跨职能团队（大约7名成员）从排好优先级的列表中选择事项（客户需求）。团队对于在Sprint结尾他们相信自己可以交付哪些目标集合达成一致意见，这些交付应该是有形的并且能被真正“完成”的。
在Sprint过程中不可以增加新事项，Scrum在下一Sprint时才接受变化，当前这么短的一个Sprint周期里只注重于短小、清晰、相对固定的目标。团队每天都进行简短会面来检验工作进程，并调整后续步骤以确保完成剩余工作。
在Sprint结尾，团队与利益关系人一起回顾这个Sprint，并演示所构建的产品。团队成员从中获取可以结合到下一Sprint中的反馈。Scrum强调在Sprint结尾产生真正“完成”了的可工作产品。在软件领域是指已经集成的、完全测试过的、已经为最终用户生成文档的、潜在可交付的系统。
2. 主要角色
2.1 Product Owner
- 确定产品的功能，负责维护产品Backlog。
- 决定产品的发布日期和发布内容。
- 为产品的投资回报率(ROI)负责。
- 根据市场价值确定功能优先级。
- 在每个Sprint开始前调整功能和调整功能优先级。
- 在Sprint结束时接受或拒绝接受开发团队的工作成果。
产品负责人是一个人，而不是一个委员会。可能会有一些委员会向产品负责人提出建议或影响他的决策，但要想改变某条目的优先级必须先说服产品负责人。
实施Scrum的企业可能发现这样会影响他们制定优先级和需求的方法。
为保证产品负责人的工作取得成功，企业中的所有人员都必须尊重他的决定。任何人都不得要求团队按照另一套优先级开展工作，团队也不允许听从任何人带有威胁恐吓性的指令。产品负责人所作的决定需要通过产品Backlog内容和优先级使其可视化。这种可视化要求产品负责人全力以赴，同时也使其成为一个费心费力但又值得去做的角色。
2.2 Scrum Master
- 保证团队资源完全可被利用并且全部是高产出的。
- 保证各个角色及职责的良好协作。
- 解决团队开发中的障碍。
- 做为团队和外部的接口，屏蔽外界对团队成员的干扰。
- 保证开发过程按计划进行，组织每日站会、Sprint计划会议、Sprint评审会议和Sprint回顾会议。
Scrum Master 需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估算可能已经发生变化。
Scrum Master 需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图（Burndown Chart）。
Scrum Master 还必须仔细考虑同时在进行开发的任务数，同时进行的工作需要做到最小化，以实现精益生产率的收益。
Scrum Master需要找出阻碍团队的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。比如：一个电信公司最近实施了Scrum，但后来发现只有两个问题和Scrum Team有关，其他的全是公司的问题需要管理层关注。
最后但并非最不重要， Scrum Master 可能会注意到，个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清，或通过内部的沟通解决，或向管理层和HR寻求帮助解决。Scrum Master 必须注意去确保团队资源完全可被利用并且全部是高产出的。
2.3 Team
- Scrum团队的规模控制在5-9个人
- 如果成员少于5人，那么相互交流就减少了，团队的生产力也会下降。更重要的是，团队在Sprint中可能会受到技能限制，从而导致无法交付可发布的产品模块。
- 如果成员多于9人，那么成员之间就需要太多的协调沟通工作。
- 大型团队会产生太多复杂性，不便于经验过程控制。
- 对于大型项目来说，可以采用多个小的Scrum团队，通过Scrum of Scrums解决团队间的沟通协调问题。
- Scrum团队是跨职能的团队
- 团队成员必须具备交付产品增量所需要的各种技能。
- 团队成员常常具备如编程、质量控制、业务分析、架构、用户界面设计或数据库设计等的专业技能。
- 在Scrum团队中没有头衔的概念，每个人都必须尽心尽力完成Sprint目标。
- 团队中不允许包括测试或业务分析等在特定领域工作的子团队。
- Scrum团队是自组织的
- 任何人，包括Scrum Master都没有权利规定团队如何将产品Backlog转化成可交付的功能增量，而是由团队自己确定。
- 每个团队成员利用自己的专业技能，解决遇到的问题。这种协同配合提高了团队整体效率。
- 团队的构成在Sprint结束时可能会发生变化，每次团队成员的变化，都会降低通过自组织而获取的生产力。因此，改变团队构成时务必要谨慎。
2.4 用户和利益相关者（客户，提供商）
3. 工件
3.1 Product Backlog
- 产品待办事项列表存在（并演化）于产品的整个生命周期，它是产品的路线图。
- 任何时候，产品待办事项列表都是“团队依照优先排列顺序完成工作”的唯一、最终的概括。
- 一个产品只有一个产品待办事项列表，这就意味着产品负责人必须纵观全局做出优先级排列的决策，以体现利益相关人（包括团队）的意愿。
产品待办事项列表包括不同种类的事项：
- 全新的客户特性（“使所有用户可以将书籍放入购物车”），
- 也有主要的技术改进目标（如“用Java代替C++重写系统”），
- 还有改进目标（如“加速测试”）、调研工作（“探讨加速信用卡有效验证的解决方法”），
- 还可能会有已知的缺陷（“分析并修复订单处理脚本错误”），
- 如果问题不多的话（如果系统有很多缺陷，通常就会有单独的缺陷跟踪系统）。
一个好的产品待办事项列表要做到：
- 粗细适宜的（Detailed appropriately）
优先级列表顶端的事项比低级别的事项更为精确和详细，因为前者要比后者先被开发。比如，待办事项列表顶端的百分之十可能包含非常小且分析得很详细的事项，而其他的百分之九十则不是那么具体。
- 估算过的（Estimated）
当前发布版本的事项需要有估算，而且随着大家了解得更多和新信息的融入应当在每个Sprint中重新考虑这些估算。 团队提供给产品负责人产品待办事项列表中每个事项的工作量估算和技术风险估算。 产品负责人和其他商业利益相关人提供产品需求的价值信息，其中可能会包括获得的收益、减少的成本、商业风险、对不同利益相关人的重要性等等。
- 涌现式的（Emergent）
为了响应学习和变化，要定期梳理产品待办事项列表。 每个Sprint，可能要加入、删除、修改、分解或者调整事项的优先级别。因此，产品负责人会不断地更新产品待办事项列表，以反映客户需求的变化、新想法或见解、竞争而导致的变化、出现的技术障碍等等。
- 排好优先级的（Prioritized）
在产品待办事项列表顶端的事项具有最高优先级，或者是从1开始顺序排列。 一般来说，最高优先级别的事项应当最物超所值：高收益（商业价值）低花销（成本）。 提高某事项优先级的另一诱因是在高风险来袭之前及早解决掉它。
3.2 Sprint Backlog
团队为每个Product Backlog事项建立一个工作列表，有时由产品待办事项列表中的事项分解出的任务组成。或者当产品待办事项列表中的事项很小，只要几个小时就能实现时，就简单的由产品待办事项列表事项组成。
4. Scrum开发流程事件
4.1 Sprint计划会议
通常分成两部分：
- 关于做什么
- 参与者：产品负责人、团队、ScrumMaster
- 长度：时间箱的小时数与Sprint的周数相等
- 产品负责人和团队审视产品待办事项列表中产品负责人有兴趣在这个Sprint中实现的那些高优先级的事项。通常，这些事项应当已经在前一个Sprint中（的产品待办事项列表梳理会议里）被很好地分析过了，因此在这个会上只有较少的需要在最后时刻澄清的问题。在这个会议中，产品负责人和团队讨论产品待办事项列表中这些高优先级事项的目标和上下关联，让团队洞悉产品负责人的思想，关注于理解产品负责人想要什么以及为什么需要它。
- 关于怎么做
- 参与者：团队、ScrumMaster、产品负责人（不强制参加，但是要能被找到来回答问题）
- 长度：时间箱的小时数与Sprint的周数相等
- 关注于如何实现团队决定要开始做的那些事项。团队预期他们在Sprint结尾能够完成多少事项，从产品待办事项列表的顶部开始（换句话说，就是从对于产品负责人来讲最高优先级的事项开始），并依次查看事项。以下是Scrum中的关键实践：由团队决定将完成多少工作，而不是由产品负责人分配给他们。因为团队是基于他们自己的分析和计划，这使得预期更可靠。虽然产品负责人对于团队接受多少工作没有控制权，但他明白产品待办事项列表中的事项是从顶部开始拿取的，换句话说，就是先拿那些被他评为重要的事项。团队可以为列表中很后面的事项进行游说，这通常发生在团队和产品负责人发现低优先级的某些东西很容易并可以恰当地与高优先级的事项合并时。
4.2 产品待办事项列表梳理
概述 ： 为了将来的Sprint拆分大事项、分析事项、重新估计并重排优先级。
参与者 ： 团队；如果产品负责人是能够帮助梳理细节的专家，那么他会全程参与整个活动，否则他可以只参与其中一部分来设定方向或者重排优先级；其他理解需求并能给予团队帮助的人；Scrum Master将在会议的开始部分来指导团队如何有效地开这个会，否则的话他不必参加。
时长 ： 通常来讲不多于团队一个Sprint工作容量的10％，但有时对于“有大量分析工作”的事项来讲要更长一些。例如，对于两周的Sprint，可能要有一天的时间花在梳理上。
4.3 Sprint评审会议
概述 ： 演示产品增量，并且在会议上对于功能性的产品增量进行审视并调整。它让产品负责人了解产品和团队的当前状况（也就是对于这个Sprint的评审），也让团队了解产品负责人和市场的当前状况。
参与者 ： 团队、产品负责人、ScrumMaster。产品负责人可以邀请其他恰当的利益相关人参加。
时长 ： 时间箱为Sprint中的每一周对应一个小时。
4.4 Sprint回顾会议
概述 ： 针对流程和环境进行审视并调整。
参与者 ： 团队、ScrumMaster、产品负责人（非必须）。团队可能会邀请其他利益相关人，否则这些人不准参加。
时长 ： 时间箱为对应Sprint中的每一周为45分钟。
4.5 开始下一个Sprint
Sprint评审之后，产品负责人可以根据任何新的见解来更新产品待办事项列表，如添加新事项、删除过时事项或修改现有事项。产品负责人负责保证这些变化反映在产品待办事项列表中。
5. 其他
5.1 工作量估算
//todo
5.2 “完成”的定义
是所有代码被check-in就算故事做完了，或者是放到测试环境并且被整合测试团队验证过，才算是做完？
这一点是非常重要的，产品负责人和团队必須同意，要對“做完”有一致的定义。
5.3 每日会议
概述 ： 在团队成员间更新信息和进行协调。
参与者 ： 团队必须参加；产品负责人不是必须的；ScrumMaster通常会在场，但要保证团队自己主持会议。
时长 ： 最长15分钟。
这是一个自组织团队互相分享目前工作情况的时刻，每个团队成员一个接一个地向团队的其他成员报告三件事：
- 自上次会议以来完成了哪些工作？
- 在下次会议前有哪些工作会被做完？
- 遇到了什么阻碍？
5.4 Sprint过程中跟踪进度
Scrum中的团队是自管理的，想要做到这一点，团队必须要知道自己做得怎么样。每天，团队成员都会在Sprint Backlog上更新他们对还需要多少工作量来完成他们当前工作的估计。一个也很常见的做法是有人把这些剩余工作量加起来，然后在Sprint燃尽图上画点。这个图显示每天新的对团队完成工作所剩余工作量的估计。理想中，这应该是一条向下的斜线图，其轨迹指向Sprint最后一天没有剩余工作量的那一点。所以它被称为燃尽图。
