阅读量:0
从上一篇 「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 把项目中的一切开放给每个人看
尊重 – 每个人都有他独特的背景和经验
勇气 – 有勇气做出承诺，履行承诺，接受别人的尊重
