1 Scrum概览
Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。
而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。
Scrum是一种兼顾计划性与灵活性的敏捷开发过程，原词来自于橄榄球中的“带球过人”，在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应变。
不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周。
在日常工作时，产品负责人会维护一个按优先级排序的“产品待开发项”（Product Backlog），即从客户价值理解和描述的产品功能条目。
在每次迭代的第一天，召开迭代计划会(Sprint Planning Meeting)，产品负责人会逐一挑选最高优先级的部分进行讲解，团队可就需求细节、完成标准等进行询问，并逐条估算，放入本次迭代的开发任务中，直至任务量饱和，一旦迭代开始，这些任务将不会发生大的变化。
在每个迭代的最后一天，团队会召集评审会(Review Meeting)，邀请产品负责人等参加，对已经完成的产品功能条目进行评审，后者做出判断并给出改进反馈，当天还会召开反思会(Retrospective Meeting)，对本次迭代中的成功与失败之处做出总结，并在以后迭代中进行改进。
1.2 理论基础
Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。
经验主义主张知识源于经验, 以及基于已知的东西做决定，Scrum 采用迭代、增量的方法来优化可预见性并控制风险，Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。
1.2.1 透明性（Transparency）
透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明，管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容，也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。
1.2.2 检验（Inspection）
开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差，在确定检验频率时，需要考虑到检验会引起所有过程发生变化，当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题，幸运的是，软件开发并不会出现这种情况，另一个因素就是检验工作成果人员的技能水平和积极性。
1.2.3 适应（Adaptation）
如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整，调整工作必须尽快实施，以减少进一步的偏差。
Scrum中通过三个活动进行检验和适应：
- 每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；
- Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；
- Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。
2 三个角色
2.1 产品负责人（Product Owner）
Product Owner（产品负责人）负责产品需求的提炼、条目化、优先级排序。
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果
2.1.1 职责
- 与客户沟通、确定客户正在意图、产品交付日期等
- 与团队沟通、共同确定需求
- 考虑团队的研发实力
2.1.2 人选
- 部门经理、产品经理、策划人员等都可能做产品负责人。
- 产品负责人是产品的指路人，必须对产品有长远的规划和深入了解，因此不能简单地选择销售人员甚至客户作为产品负责人。
- 大型产品如嵌入式产品和网络游戏，常常使用有层级的产品负责人团队，来解决广度与深度的矛盾，如产品总监-产品经理 / 主策划-策划团队。
2.2 流程管理员（Scrum Master）
Scrum Master（Scrum“大师”）负责维护Scrum方法的秩序，并协助解决非技术问题。
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发
2.2.1 职责
- 负责整个Scrum流程在项目中顺利实施和进行
- 没有行政权力
- 不帮团队做决定、但是可以提出建议
2.2.2 人选
- Scrum Master的工作方式是靠领导力(leadership)而非权力工作，因此首先应服务于团队。
- 一种人选是原来的项目经理转型，保留原有的管理和技术职能，但弱化指派任务、下达时间点指令等内容，而增强其组织协调能力。
- 另一种人选是企业原有的过程改进人员，协助不太了解Scrum的项目经理按照Scrum的方法工作，可以每人负责多个项目，接近全职的Scrum Master。
2.3 开发团队（Scrum Team）
Team（团队）以“自组织”的相对扁平方式进行管理，负责完成开发工作。
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标
2.3.1 职责
- 负责整个Scrum流程在项目中顺利实施和进行和自组织的开发团队
- 一般5~10人
- 跨职能团队（业务分析师、程序员、测试人员、架构师、数据库设计师）
3 三个工件
3.1 产品待办列表（Product Backlog）
产品待开发项 Product Backlog是从客户价值角度理解的产品功能列表。
产品待办列表是一份有序列表，其中包含产品需要的一切可能的东西，也是产品需求变 动的唯一来源，产品负责人负责管理产品待办列表的内容、可用性和排序。
- 功能、缺陷、增强等都可以是待开发项。
- 一般以条目化的方式描述。
- 客户和用户必须能够理解。
- 描述怎样使用而非怎样制造。
- 整体上从客户价值优先级排序。
- 总工作量一般需要0.5～10人天。
- 高优先级的条目应有较详尽的描述，低优先级的条目可只有一个名称。
3.2 Sprint待办列表（Sprint Backlog）
冲刺待开发项 Sprint Backlog是从开发技术角度理解的迭代开发任务
Sprint 待办列表是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划，Sprint 待办列表是开发团队对于下一个产品增量所需的那 些功能以 及交付那些功能到"完成"的增量中所需工作的预测
- 在简单的纯软件环境中，可以直接把产品待开发项当作冲刺待开发项分配到迭代中。
- 在复杂的开发环境中，可以把一个产品待开发项分解为Web/后台……软件/硬件……程序/美术……等开发任务。
3.3 增量
产品增量是在Sprint内开发团队交付的所有产品待办列表条目的综合，增量必须是符合团队定义的"完成的定义"（Definition of Done）
4 五个事件
4.1 Sprint
也翻译做冲刺，是Scrum的核心，也是一个容器
Sprint是一个时间盒（固定的开始和结束时间），下一个Sprint会紧随上一个Sprint，在这之间没有停顿。Sprint由Sprint计划、每日例会、Sprint执行、Sprint评审及Sprint回顾组成。
4.2 Sprint计划
一个Sprint中准备做的所有工作是在Sprint计划会议中完成的。这份计划是整个团队（产品负责人、Scrum Master和开发团队）共同完成的
4.2.1 目的
Sprint计划最主要完成两件事情：
- 在这个Sprint中要完成什么产品待办列表条目？（What）
- 如何完成这些条目？（How）
4.2.2 流程
- 迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。
- 产品负责人逐条讲解最重要的产品功能。
- 开发团队共同估算故事所需工作量，直到本迭代工作量达到饱和。
- 产品负责人参与讨论并回答与需求相关的问题，但不干扰估算结果。
4.3 每日站会
开发团队15分钟同步进度并每日调整的一个事件
在每日站会上，每个团队成员回答以下三个问题（基本的，可以根据情况增加新问题）
- 昨天，我为帮助开发团队达成 Sprint 目标做了什么?
- 今天，我为帮助开发团队达成 Sprint 目标准备做什么?
- 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标?
4.3.1 流程
- 队员认领任务（或由组长协商分发），独立或与别人一起完成任务。
- 团队内部利用每日立会来沟通进度。
- 开发团队利用燃尽图来展示整体进度。
- 如无特殊原因，迭代期内无变更。
4.4 Sprint评审
在Sprint快结束时，Scrum团队在一起检视所交付的产品增量，并调整产品待办列表
Sprint评审不是Sprint演示、也不叫做Sprint demo，一定要包括收集反馈和调整的环节
4.4.1 流程
- 小组向产品负责人展示迭代工作结果。
- 产品负责人给出评价和反馈。
- 以用户故事是否能成功交付来评价任务完成情况。
4.5 Sprint回顾
Scrum团队检视和调整工作方法、流程，持续改进的事件
4.5.1 目的
Sprint回顾的主要目的是
- 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何
- 找出并加以排序做得好的和潜在需要改进的主要方面
- 制定改进 Scrum 团队工作方式的计划
4.5.2 流程
- 在每个迭代后召开简短的反思会。
- 总结哪些事情做的好，哪些事情做的不好。
- 制定改进计划。
4.6 产品待办列表梳理（Refinement）
即需求梳理会，每周Scrum团队在一起为下一个Sprint进行准备工作。
4.7 五个价值观
- 承诺 – 愿意对目标做出承诺
- 专注– 把你的心思和能力都用到你承诺的工作上去
- 开放– Scrum 把项目中的一切开放给每个人看
- 尊重– 每个人都有他独特的背景和经验
- 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
5 用户故事
用户故事：描述具体的需求的卡片，按
作为一个……，可以……，以便……样式和思路写成的用户需求，就是用户故事
这种样式是技法层面的东西，它保证了无需太多思考，用户故事中即可全面包含角色、功能、价值这三个要素，要想写好用户故事，要改变那种面向功能而非客户需求的纯技术观念。
5.1 角色
切记不要总是写“作为一个用户”，而是要把用户区别对待，这样才能更好地理解他们使用什么功能，如何使用，为何使用。
5.2 功能
即用户能亲自执行的操作，应区分用户操作和产品功能之间的关系，因为产品功能可能也提供了用户所需的价值，但却极可能不便于操作。
5.3 价值
是完成操作后，客户所得到的好处，价值里边，常常要带有一点褒义词，或有一些吸引人的内容，比如“高效地……”“……可以节省话费”等。
6 敏捷日常跟进
6.1 看板
- 看板又叫任务版，对于Sprint进度的沟通，看板是一种简单而强大的方式，从形式上看，看板显示的是Sprint冲刺待开发项随时间的进展状态。
- 故事板简单说就是把所有正在工作的内容，张贴到一个板状空间中。
- 看板（Kanban）一词来自日语，指的是制造业中的一种可视化方法，有相当复杂的思想和流程。由于两者看上去很类似，两个词汇经常混用。
6.2 燃尽图
- 在Sprint执行的每一天，团队成员都要更新未完成任务的剩余工作量估算，我们可以创建一个表来是使数据可视化，就是燃尽图
- 根据整个团队的剩余工作总量，每天进行更新，就可以得到燃尽图。
