Scrum简介与实施指南v1.0

一、什么是Scrum

Scrum就是3、3、5、5

二、第一个3——3个角色

1. Product Owner 简称PO

PO是获得授权的一个人

PO职责：WHAT
• 清晰地表达你想要什么
• 对需求功能进行排序，告诉团队你最想先要什么
• 需求都要有价值：优化Team所执行工作的价值，不要提垃圾需求
• 会写PB（Product Backlog）：确保产品待办列表对所有人可见、透明、清晰，并且显示 Scrum团队的下一步工作
• 及时与Team沟通反馈：确保Team对产品待办列表项有足够的理解

PO是墙头草：
• 一方面PO要了解客户需求的紧急性，要代表客户给Team施压
• 另一方面PO要了解Team的进度和产能，顶住来自客户的压力（攘外）

PO最大：
• Team只听PO

2. Team

Team的特点：
• 自管理：没有人分配任务，没有人告诉Team如何将PO的需求实现
• 跨职能：Team中的每个人必须具备实现PO需求的所有技能，包括设计、分析、编码、测试。但可以有特长或专注领域。
• 小团队：团队人数一般3-9人
• 在一起：所有成员是一个整体，没有子团队，没有领袖

Team的职责：HOW
• 会把PO写在Product Backlog中的User Story写AC（Accepance Case）
• 提供每个AC的估算
• 集中投入，按时交付

3. ScrumMaster

ScrumMaster的职责：Guide
• 确保PO和Team能正确理解并实施Scrum（安内）

三、第二个3——3个工件

1. Product Backlog

a. PB的拥有人：

PO

b. PB的内容：

• Story：用户故事，也就是PO提出的原始需求，PO写
• AC：Accepance Case，验收用例，是Team对Story的细化，Team写
• 当前Sprint：当前Sprint的AC，PO自己拖拽过去
• Done：做完的AC，PO自己拖拽过去

c. Story的写法：

作为XX（角色）

需要有XXX（功能）

用于XXX（实现价值）

d. Story的要求：

• 每个Story一个泳道

• 要排优先级

• 适当的详细：近期要做的需求要详细，如下图，用户中心的Story打算近期做，细化成“手机注册”和“登陆”

  

• 可以随时变：每次改变需要重排优先级

e. AC的写法：（ATDD 验收测试驱动 TDD测试驱动，属于XP）

依赖：XX（依赖条件）

输入：XX

输出：XXX

f. PB什么时候写，什么时候拖拽

见第四节

2. Sprint Backlog

a. SB的拥有人：

Team

b. SB的内容：

• 当前Sprint：从PB的的“当前Sprint”复制过来
• TODO：当前Sprint的功能点一旦复制过来就进入TODO
• Doing：Team从TODO中领取功能，拖拽到Doing。注意是Team，不是个人。一次领一个功能，直到Done后才能领下一个功能
• Done：Team完成功能后，从Doing拖拽到Done。注意是完成所有步骤，包括测试

c. Increment

• 增量就是每一个Done的功能，必须是正常可工作的
• 增量可在PO的计划时间发布，也可临时发布

四、第一个5——5个活动

1. Product Backlog Refinement

简称PBR又叫PB进化

PBR是一个持续的阶段，并不是会议，需要Team和PO每天有固定的时间或随时沟通

a. PBR中需要搞定5件事

• PO要把优先级排好

• PO要把PB要写好，近期的要细化

• Team要把近期的PB写成AC

• Team要评估每个AC的工作量：选好一个AC为基准，以倍数的方式评估

  

• PO要制定发布计划：这个迭代周期完成后不发布增量就不制定

b. 为什么要写AC

• 帮助整个Team理解功能( 你以为的你以为真的是你以为么 )
• 分解PO的功能
• 就是在做设计
• 要识别出依赖
• 能减少误判
• 更容易估算复杂度
• Team和PO的合作
• 把PO解放出来去做更重要的事

c. Team与PO的沟通方式

• Team要多给PO选择题和判断题，不要给论述题

  例子：

  • PO在PB上的Story是”要账号登陆功能”
  • Team在写AC的过程中，可以问PO“我们有手机号、邮箱、QQ、微信等登陆功能，你要哪些”，或者问“我们现在先实现手机号登陆比较靠谱，你看行不行”。不要问或少问“你想用哪些方式登陆”

• PO要积极响应和反馈Team，PO决定产品功能的方向和准确性而非Team

• Team写完AC后，PO负责批阅，确定功能的准确性

d. PBR实践

• Team中的所有人都要写AC
• 第一个迭代开始后，每天17：00固定时间Team和PO沟通下一个迭代的功能，写下一个迭代的AC
• 一旦Team中有人暂时没有工作，就去写AC或与PO沟通下一个迭代的功能

2. Sprint Planning

迭代计划会议

a. 会议时间：

每个迭代开始的第一天，早9：30

一般1小时左右，如果PBR做的好，会议应该在30分钟左右

b. 参加人员：

• PO
• Team
• ScrumMaster（非必需）

c. 会议内容：

• Team提供迭代周期的产能，ScrumMaster协助评估产能
• PO根据Team的产能，在PB中选择复杂度之和在产能内的AC，拖拽到“当前Sprint”
• Team把PB“当前Sprint”的AC复制到SB中
• Team和PO简单讨论哪些功能要做，怎么样做

3. Daily Scrum

每日立会

a. 会议时间

迭代周期内每天16：45

会议最多15分钟

b. 参加人员：

• Team（只有Team能发言）
• 所有人（非必需）

c. 会议内容：

所有Team成员回答3个问题

• 昨天做完了什么
• 今天要做完什么
• 有什么问题

4. Sprint Review

迭代评审会议

a. 会议时间

迭代周期最后一天16:00

会议1小时

b. 参加人员

• Team
• PO
• 所有人（非必需）

c. 会议内容

• Team演示所有Done的增量
• PO根据演示或总结用户的看法提出新的需求或修改需求到PB

5. Sprint Retrospective

a. 会议时间

迭代周期最后一天17:00

会议1小时

b. 参加人员

• Team
• PO
• ScrumMaster

c. 会议内容

ScrumMaster和全组讨论改进

• 我们需要开始做点什么
• 我们需要停止做些什么
• 我们需要保持什么

五、第二个5——5个价值观

1. 承诺
2. 勇气
3. 专注
4. 开放
5. 尊重