个人整理的Scrum流程

上一篇文章介绍了 Scrum的角色，一些内容是根据网上的一篇Scrum Ckecklist结合自己的工作内容进行梳理的流程。

 

 

• Sprint 计划会议 1：原始需求者、产品负责人及团队一起，确定任务优先级，定出 Sprint 目标和既定产品 Backlog。
• Sprint 计划会议 2：团队将既定产品 Backlog 中的每一项细化成多个任务。每个任务完成的时间限定在一天内。
• Scrum 每日例会：项目团队成员间的一个进度协调会议。会议每天都在同一时间同一地点举行。时间限定在 15 分钟内。
• Sprint 验收会议：由原始需求者或产品负责人断定实际所发布的功能是否与既定的 Sprint 目标一致。
• Sprint 回顾会议：项目团队分析Sprint中的成功经验和所遇到的障碍。

整个Sprint的周期（时间盒）确定为10天（两周），具体的时间安排为：

• Sprint会议（0.5天）
• 开发（8天）
• 验收&总结（0.5天）
• 技术提升日（1天），自主学习技术

1、 需求收集

1.1  需求的分类

需求可与分为业务团队的，也可以包括团度内部的，比如性能优化。

1.2  需求提交模板

需求种类	优先级	需求类型	需求标题	详细描述	验收条件	价值验证	提交时间	需求人	备注

① 需求种类 可从以下四种情况中选择

• - 任务
• - 可用性问题（Bug）
• - 性能问题
• - 概念想法

注意：即使是概念性的想法，目前技术上无法实现的想法都可以收集。

② 优先级 可从以下五种情况中选择

• - 特别的严重
• - 非常重要
• - 很重要
• - 普通
• - 低

注意：切忌将所有的任务的优先级都设置的非常的高，这里不提供非常紧急这样的表述。我们只会根据重要程度去执行任务，所以紧急的任务需要业务部门及需求方尽早的提出。

③ 需求类型 可以是两种类型

• - 详细需求
• - 毛坯需求

注意：我们的需求并不是要求一定要完整的，及时是一些非常毛坯的需求，也可以提交过来，毛坯的需求由产品负责人进行分析和梳理，暂不清楚的可选择搁置。

④ 需求标题 有自己进行书写，但是需要遵守的规范是采用动宾短语格式。

比如：“导出+CN酒店每天的PV、UV等流量数据”

注意：这里的需求内容一定是站长使用者角度是提出的，切勿出现专业的程序方面的表述：如添加一个导出的按钮。还有需要注意的是动词切忌使用大而宽泛的词，比如“管理”，类似“管理关键词”这样的需求是严格避免的，这样会使得要开发的内容变得没有清晰的边界。

⑤ 详细描述 需要按照用户故事的格式进行书写。具体用户故事格式的要求如下：

用户故事是从用户的角度来描述用户渴望得到的功能。需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。一个好的用户故事包括三个要素：

• 角色：谁要使用这个功能。
• 活动：需要完成什么样的功能。
• 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：作为一个<角色>, 我想要<活动>, 以便于<商业价值>

比如：作为一名酒店前端开发人员，我期望查看所有酒店页面的页面打开时间，以便了解哪些页面需要进行技能优化。

一个好的用户故事同时要符合INVEST原则，INVEST原则分别是：

• 独立性（Independent）: 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
• 可协商性（Negotiable）: 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事带有了太多的细节，实际上限制了和用户的沟通。
• 有价值（Valuable）: 每个故事必须对客户具有价值。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
• 可以估算性（Estimable）:开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
• 短小（Small）: 一个好的故事在工作量上要尽量短小，最好不要超过8个人/天的工作量,至少要确保的是在一个迭代能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
• 可测试性（Testable）: 一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。

注意：

• 角色的范围不能过大，比如是作为一名“用户”，这样是的不被接受的。
• 商业价值也不能大而宽泛，比如，能为公司创造业绩。如果要写也一定要对业绩做初步估算，比如，预期会给公司带来每月1万张订单。

⑥ 验收条件 是开发完成后检验的标准，所以一定要认真填写，否则可能开发出来的东西与预期不达标。

以上面的“导出+CN酒店每天的PV、UV等流量数据”为例，它的验收条件可以为：

• 1)   可以为每个用户设置是否拥有此导出权限
• 2)   导出的时间可以细化的天。即可导出每天的流量。
• 3)   导出数据的最大时间跨度为31天
• 4)   对于导出数据做好日志记录，后期可查是谁进行了导出。
• 5)   导出的字段包括：PV、UV、跳出率、新访客占比。

⑦    价值验证 说明如何跟踪上线后的效果

2、 Sprint 计划会议 1

目标：定出 Sprint 目标和既定产品 Backlog。

2.1 会议准备

□ 所有会议资源都已预订

□ 会议室

□ 投影仪

□ 笔记本

□ 在会议前一天确定议程，将目标和议程发送给所有与会者

□ 原始需求人（可选择不来）

□ 产品负责人

□ Scrum Master

□ 开发团队

□ 已按优先级排列产品 Backlog整理完毕

□ Sprint 时间表已经安排

□ Sprint 计划会议 1 的时间安排

□ Sprint 计划会议 2 的时间安排

□ Sprint 的第一天已确定

□ Sprint 的最后一天已确定

□ Scrum 每日例会的时间安排

□ Sprint 验收会议的时间安排

□ Sprint 回顾会议的时间安排

2.2 会议议程

□ 把 Sprint 时间表公开给所有人

□ 产品负责人向团队产品阐述需求（用户故事）

□ 开发人员对用户故事不清楚的点可以及时提出。

□ 产品负责人或者原始需求者负责解答不清楚的故事点。

□ 如果讨论现场发现有遗漏的需求，可由产品负责人添加至产品Backlog。

□ 如果对需求的优先级存在异议，可会上讨论，确定最终的执行顺序。

□ 产品负责人& 需求方和小组成员相互认可这 Sprint 目标和既定产品 Backlog

2.3 会议结果

□ 为 Sprint 计划会议2的进行准备好既定产品 Backlog

2.4 补充内容

产品Backlog模板（基本同需求模板）

需求种类

优先级

需求类型

需求标题

详细描述

验收条件

提交时间

需求人

备注

跟进人

预计完成时间

实际完成时间

Sprint版本号

处理情况

处理情况可从以下几种类型中选择

• -    等待处理
• -    正在进行
• -    已经完成
• -    不予处理
• -    暂时搁置
• -    需要讨论

3、Sprint 计划会议 2

目标：确定所有任务，生成 Sprint Backlog，确认 Sprint 目标

3.1 会议准备

□ 要求原始需求者离开会议，参会人员为

□ 产品负责人

□ Scrum Master

□ 开发团队

□ 在Sprint 计划会议1后10分钟举行

□ Sprint 计划会议1中整理的既定产品 Backlog

□  任务估时牌（按1,2,3,5,8,13估算）

3.2 会议进程

□ 团队成员按顺序分析既定产品 Backlog的讨论实现细节

□ 编码

□ 测试

□ 代码审核

□ 学习新技术

□ 编写文档

□ 部署

□ 上传

□ 可看情况确定是否使用扑克估时

□ 任务超过一天时，需要拆成多个小任务

□ 如果团队评估下来任务过多，可和产品负责人一起删减任务

□ 如果团队评估下来任务过少，可和产品负责人一起从产品Blaclog中引入新的需求。

3.3 会议结果

□ 将最终确认的可完成的需求清单邮件至

□ 原始需求人

□ 产品负责人

□ Scrum Master

□ 开发团队

□ 将最终确认的任务列表邮件至

□ 产品负责人

□ Scrum Master

□ 开发团队

3.4 补充内容

Sprint Backlog模板

优先级	需求标题	详细描述	验收条件	需求人	跟进人	处理人	任务描述	处理日期	估时	实际耗时

需求和任务是一对多的关系，及一个需求可以产生多个任务，任务可以是程序类描述，如“数据数据库设计”

4、 Scrum 每日例会

目标：团队成员间工作进度的沟通和协调

4.1 会议准备

□ 邀请与会者

□ 外部团队协助人员（如有有需要的话）

□ 原始需求人（只有选择是否参加，过程中不可发言）

□ 在 Sprint Backlog 上的所有任务都是可以增删修改，可重排序的

□ 一台电脑，中间标识任务的状态，可设为“待处理”，“正在处理”，“已完成”的。

4.2 会议进程

注意：

• - 会议限定在15分钟内
• - 团队里的每个成员都必须回答以下三个问题，并考虑其相关的行动。

□ 上次会议时的任务哪些已经完成?

□把任务从“正在处理”状态转为“已完成”状态

□ 下一次会议之前，你计划完成什么任务？

□ 如果任务状态为“待处理”：转为“正在处理”状态

□ 如果任务不在 Sprint Backlog 上：添加这个任务

□ 如果任务不能在一天内完成：把这任务细分成多个任务

□ 如果任务可以在一天内完成：把任务状态设为“正在处理”

□ 如果任务状态已经是“正在处理”：询问是否存在阻碍任务完成得问题

□ 有什么问题阻碍了你的开发

□ 如果有阻碍你开发进度的问题：把该障碍加入到障碍 Backlog 中，Scrum Master负责记录

□ 如果展开了一个问题的讨论

□ 提醒团队的成员们注意把精力集中在回答关键问题上

□ 如果相关人员想发表些言论

□ 礼貌地提醒他，该会议只允许让小组成员讨论

4.3 会议结果

□ 得到最新的障碍 Backlog

□ 得到最新的 Sprint Backlog

□ 最新的工作进度图（燃尽图）

□ 第一次的例会创建一封邮件，由Scrum Master会议后将例会内容回复此邮件。

4.4 障碍Backlog

障碍 Backlog 列举了所有团队内部和团队相关的和阻碍项目进度的问题。Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。

10 大典型障碍

-    会议规则没能被遵循

-    产品远景和 Sprint 目标不清晰

-    没有产品负责人负责回答提问

-    产品 Backlog 未能按商业价值区分优先级

-    并不是所有负责交付产品的人员都是团队里的成员

-    Scrum Master 还要处理其他任务，不能集中精力

-    团队人数过多

-    团队没有能坐在一起工作的空间

-    团队的 Sprint Backlog 混乱

-    中间遇到了技术难题

5、 Sprint 验收会议

目标：根据团队这次 Sprint 所发布的版本，评审相关的 Backlog 中的问题，检查是否已达到 Sprint 的目标。

5.1 会议准备

□ 所有会议资源都已预订

□ 会议室

□ 投影仪

□ 笔记本

□ 在会议前一天确定议程，将目标和议程发送给所有与会者

□ 原始需求人（可选择不来）

□ 产品负责人

□ Scrum Master

□ 开发团队

□ 对于每个人来说 Sprint 目标都是公开的

□ 对每个人来说既定产品 Backlog 是公开的，可获取的

5.2 会议进程

□ 团队按 Backlog 中的问题，逐个地介绍这次 Sprint 的结果，和演示新功能。

□ 如果产品负责人或需求方想要改变功能：添加一个新问题到产品 Backlog 中

□ 如果对功能有一个新的想法：添加一个新问题到产品 Backlog 中

□ 如果小组报告项目遇到阻碍现在还没能解决：把该障碍加入到障碍 Backlog

5.3 会议结果

□ 对这次 Sprint 的结果和整个产品的开发状态的共识

6、 Sprint 回顾会议

目标：通过总结以往的实践经验来提高团队生产力。

注意：主要指导原则：不管我们现在发现了什么问题，我们必须懂得并坚信每个人通过他们当时所知的，他所拥有的技能和可得到的资源，在限定的环境下，都尽其所能做出了最好的成绩。

6.1 会议准备

□ 邀请与会者：

□ Scrum Master

□ 团队所有成员

□ 产品负责人（可选）

□ 附属工具

□ 便签纸

□ 白板

□ 在白板上写上主要指导原则

□ 在白板上画上一个至少三页纸连在一起长的时间轴

□ 在白板上写上“我们的成功经验是什么”

□ 在白板上写上“有什么能够改进”

□ 在白板上写上“谁负责”，然后分成两个区域——“团队”和“公司”

附属工具：

6.2 会议进程

□ 介绍会议目标

□ 介绍会议主要指导原则

□ 在时间轴上，标记出 Sprint 的开始和结束时间

□ 向与会者解说如何使用该便签纸进行工作

□ 派发便签，并且让每人写上他们认为这次 Sprint 中最为重要的事，限时 5 分钟

□ 每个与会者轮流把他的贴纸贴到白板的时间轴上，并用两句话来解说这事有什么特别的地方

□ 分发便签纸，并让每人写上“我们的成功经验是什么”，限时5分钟

□ 每个与会者轮流把他的贴纸贴到白板“我们的成功经验是什么”的区域上，并解说。

□ 分发便签纸，并让每人写上“有什么能够改进的”，限时5分钟

□ 每个与会者轮流把他的贴纸贴到白板“有什么能够改进的”的区域上，并解说。

□ 对于挂纸板上“有什么能够改进”的区域中的每一项

□ 询问团队“谁去负责解决这个问题？”

□ 把便签纸移到挂纸板中“谁负责”的区域中

□ 和团队一起把这些区域按优先次序排好

□ 给会议做个总结

□每个与会者对 Sprint 回顾会议作简短的回馈

6.3 会议结果

□ 白板上“谁负责”这栏对于公司内所有人是公开的

□ 把与公司范围相关的障碍增加到障碍 Backlog 中去

□ 把与团队范围相关的障碍增加到障碍 Backlog 中去

□ 整理所有会议结果，邮件至团队中所有人