从上一篇 「16 敏捷开发实践（1）」中了解了Scrum是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程。一般由多个Sprint（迭代冲刺）组成，每个Sprint长度一般为2-4周。下面全面介绍Scrumde 角色、流程等。
3个角色
产品所有者（Product Owner）
-
定义所有产品功能，决定产品发布的内容以及日期。
-
根据市场变化对需求排列优先顺序。
-
确保干系人了解待办工作项。
-
合理调整产品功能和迭代顺序。
-
认同或者拒绝迭代的交付。
Scrum Master
-
指导团队完成Scrum的实践。
-
帮助团队排除遇到的困难，确保团队胜任其工作。
-
对团队、产品负责人和企业进行 Scrum 流程方面的培训，并从实践中优化调整Scrum流程。
-
负责安排冲刺规划、每日站会、冲刺评审和冲刺回顾所需的资源。
开发团队(Team)
-
经典团队拥有 5-7人，成员包含开发、测试、产品、UI。
-
团队关系在一个迭代中保持固定，且熟练掌握不同的技能。
-
团队自我组织和管理（自组织，自驱动）。
-
团队的所有成员互相帮助，以确保成功完成冲刺。
-
团队预测认为自己在迭代过程中可以完成的工作量（尽量保持迭代长度固定，有助于准确预估）。
3个Scrum 工件
产品待办事项
-
产品负责人或产品经理需要完成和维护的主要工作列表。
-
功能、要求、增强功能和修复的动态列表，并用作 Sprint 待办事项的输入。
-
产品负责人对产品待办事项进行不断反思、重新排定优先级和维护以适应变化。
Sprint 待办事项
-
开发团队为实现当前冲刺周期而选择的需求或缺陷修复列表。
-
冲刺之前，从产品待办事项中选择要通过冲刺处理的待办项。
-
Sprint 待办事项较为灵活，可以在冲刺期间调整。
-
保证基本的冲刺目标不能受到影响。
Sprint 迭代目标(增量)
-
迭代目标即冲刺中可用的最终产品。
-
冲刺结束团队展示在冲刺期间完成的“增量”。
Scrum研发流程
需求梳理，整理产品待办事项
-
将收集的工单和反馈过滤后快速转化为需求，整理出产品 Backlog。
-
需求原型设计、输出相关文档。
-
对需求进行分级管理，设定需求优先级，指定需求的业务价值
迭代规划
-
根据需求优先级，将产品待办列表中的需求规划至对应迭代。
-
在迭代计划会议上，产品负责人按优先级讲解需求，与团队共同进行评审。
-
确定当前迭代要完成的需求与验收标准达成一致后，形成迭代待办列表。
-
细化需求，拆分成具体的子任务，方便后续处理和跟踪。
迭代开发
-
开发人员领取相应的开发任务进行编码实现，完成代码构建、部署等。
缺陷跟踪
-
测试工程师可根据迭代要完成的需求与验收标准编写测试用例。
-
未通过用例转换为缺陷，提交给对应的开发人员。
-
测试与开发共同关注需求的测试情况与缺陷修复进度，让缺陷在开发和测试之间高效流转，推动需求高质量上线。
迭代进度跟踪（每日站立会）
-
在每日站立会议中，团队对齐迭代进度，尽早识别迭代可能出现的风险点，排除问题。
迭代评审与复盘
-
迭代完成后，由团队成员对当前迭代的成果进行演示，产品负责人进行成果评判，与其他成员提出反馈建议。
-
记录迭代中做的好的、做的不好的以及改进建议。
ONES支持的Scrum研发流程场景图
5个会议
待办事项整理会议（Backlog Grooming Meeting）
-
时间：迭代计划会议开始之前2-3天召开
-
目的：整理下个迭代的待办事项，解决产品负责人方工作阻碍。
-
流程：
-
Product Owner建立产品功能列表（Product Backlog），并按优先级排序。
-
Product Owner按照实现顺序描述给在场的团队成员，Scrum Master与在场成员分析并提出疑问。
-
Product Owner现场解答、记录，会后补全不确定地方
-
Scrum Master与架构师分析包含哪些技术任务
-
Scrum Master子任务建立，方便迭代计划会议的时候团队可以更准确地预估任务故事点。
-
-
目标：
-
会议结束时，Product Owner确保在迭代计划会议开始之前团队提出的问题都能被解决
-
如果团队发现需要加强或是完善的地方，Product Owner还有2-3天的时间可以补强，不浪费迭代计划会议的时间去做这件事情。
-
迭代计划会议（Sprint Planning Meeting）
-
时间：每个迭代第一天召开，时长控制在1-2小时内。
-
目的：选择本次迭代的Backlog和估算本次迭代的工作量。
-
流程：
-
产品负责人逐条讲解最重要的产品功能，开发团队共同估算Backlog所需工作量，直到本迭代工作量达到饱和。
-
产品负责人参与讨论并回答和需求相关的问题，但不干扰估算结果。
-
认领任务（或由组长协商分发），独立或与别人一起完成任务；
-
每日站会（Daily Meeting）
-
时长控制：10-15分钟
-
内容：
-
昨天工作内容
-
今天工作内容
-
遇到的困难，有没有找到解决方案，是否需要队友帮忙。
-
评审会（Retrospective Meeting）
-
时间：开发完成测试环境后。
-
小组向产品负责人展示迭代工作结果，产品负责人验收给出评价和反馈。
回顾会（Review Meeting）
-
时间：迭代评审演示会结束后。
-
内容：
-
总结哪些事情做得好、哪些事情做得不好。
-
改进方案。
-
备注：
-
产品负责人可能会在当前迭代开始后就着手准备下个迭代的「待办事项整理」，边整理边插空去跟Scrum Master或团队成员沟通完成这些工作，省去待办事项整理会议（Backlog Grooming Meeting）。
-
迭代计划会议（Sprint Planning Meeting）上可以进行技术方案的确定以及Scrum Master子任务建立。
-
技术难度较大时，将技术调研、技术实现需求加入当前迭代并进行预估。调整其他需求优先级。
-
-
一般评审会（Retrospective Meeting）和回顾会（Review Meeting）在迭代结束的最后一天先后开，评审结束就进行回顾总结，时长控制在1-2小时。
5个价值观
-
承诺 – 愿意对目标做出承诺
-
专注 – 把你的心思和能力都用到你承诺的工作上去
-
开放 – Scrum 把项目中的一切开放给每个人看
-
尊重 – 每个人都有他独特的背景和经验
-
勇气 – 有勇气做出承诺，履行承诺，接受别人的尊重