一、什么是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

1

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打算近期做,细化成“手机注册”和“登陆”

    2

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

e. AC的写法:(ATDD 验收测试驱动 TDD测试驱动,属于XP)

依赖:XX(依赖条件)

输入:XX

输出:XXX

3

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

见第四节

2. Sprint Backlog

4

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为基准,以倍数的方式评估

    5

  • 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. 尊重