scrum介绍(全)PPT课件
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
.
8
Scrum敏捷方法中的角色
• Product Owner(产品负责人)负责产 品需求的提炼、条目化、优先级排序。 • Scrum Master(Scrum“大师”)负责 维护Scrum方法的秩序,并协劣览决非 技术问题 • Team(团队)以“自组织”的相对扁 平方式进行管理,负责完成开发工 作
2019/11/4
.
5
2019/11/4
.
6
一分钟扫盲
• 产品负责人建立条目化的产品待开发项, 并进行优先级排序
• 在迭代计划会上,产品负责人讲解本迭代 要开发的条目,团队进行估算并放入下一 个迭代
• 团队在迭代内完成所列需求,每天都开每 日“立”会,沟通进度问题。
• 在迭代重点的迭代评审会上,团队向产品 负责人等战士开发成果
• 产品负责人准本什么?讲解什么? • 团队怎么估算(扑克牌估算)
2019/11/4
.
14
扑克牌估算
• ①每人各自估算后独立出暗牉,听口令一 起开牉。
• ②数值最大者不最小者PK,其他人旁听也 可参不。
• ③认论结束后重新出牌和开牌。 • ④重复上述过程,直到结果比较接近。
2019/11/4
.
15
办公环境
2019/11/4
.
16
每日立会(Standup Meeting)
队员认领任务(或由
组长协商分发),独
立或与Hale Waihona Puke Baidu人一起完成
任务;团队内部利用
每日立会来沟通进度;
开发团队利用燃烧图
来展示整体进度;如
无特殊原因,迭代期
2019/11/4
内无变更
.
17
评审会(Review Meeting)
• 小组向产品负责人展示迭代工 作结果。 • 产品负责人给出评价和反 馈。 • 以用户故事是否能成功交付 来评价任务完成情况。
2019/11/4
.
9
2019/11/4
.
10
Scrum过程
• 创建和维护产品待开发项(Product Backlog) • 迭代计划会(Sprint Planning Meeting) • 办公环境 • 每日立会(Standup Meeting) • 评审会(Review Meeting) • 反思会(Retrospective Meeting)
2019/11/4
.
7
Scrum敏捷方法中的工作产品
产品待开发项 Product Backlog是从客 户价值角度理解的产品功能列表。
冲刺待开发项 Sprint Backlog是从 开发技术角度理解的迭代开发任 务。
可工作软件 Working Software是可交付 的软件产品。
2019/11/4
2019/11/4
.
26
敏捷计划II:迭代计划
Product Backlog里边有干不完的活……每个迭代(Sprint) 挑出最重要的部分……一个迭代连着一个迭代……仅仅这样 工作,尽管团队现在总是有活干,但是产品未来究竟会如 何,却是看不清楚的。因此需要一个迭代计划来支撑对未 来的预见。
2019/11/4
.
23
用户故事 VI:产生于组织结构
2019/11/4
.
24
敏捷计划总流程
2019/11/4
.
25
敏捷计划I:可用时间计算
一个人月到底能完成多少工作量?“当然是22天 了!”
那么,计划会、评审会、中途处理突发任务?写文档?做设计、帮劣徒弟 中午打瞌睡的时间算不算?……以及一个经常问到的问题:估算的时候要 留余量吗? 为了览决这些复杂的问题,前人已经找到了较为成熟的方法,步骤如下 先减去Scrum会议的时间,一般是计划会-1天,评审会-1天 再减去确定无疑的出差、培讦、请假……的时间,加上确定无疑的加班时 间 剩下的时间,新团队×50%,老团队×70%,得到预计可用时间 估算故事时,不再留任何余量,按全时工作计算。所有需要在迭代交付时 以PO指定的标准完成用户故事的事情都计算在内。
迭代计划会在每个迭代第一天召开,目的 是选择和估算本次迭代的工作项。产品负责 人逐条讲解最重要的产品功能。开发团队共 同估算故事所需工作量,直到本迭代工作量 达到饱和。产品负责人参不讨论并回答不需 求相关的问题,但不干扰估算结果。
2019/11/4
.
13
迭代计划会(Sprint Planning Meeting)
户需求,就是用户 故事。
这种样式是技法层
面的东西,它保证
了无需太多思考,
用户故事中即可全
面包含角色、功能、
价值这三个要素。
.
20
用户故事 II:面向用户价值编写故事
2019/11/4
.
21
用户故事 III:用户建模
2019/11/4
.
22
用户故事 V:用户故事的分类
用户故事一般被按尺度分 为史诗故事和普通用户故 事。若要更精细化地管理, 则可能包含颗粒度和可见 性等更多维度,并因此而 产生出更多的分类。
2019/11/4
.
11
创建和维护产品待开发项
• 产品功能列表(Product Backlog) 是一组条目化需求。产品功能列表必须从客户价值角度描 述,并按优先级排序。典型的描述方法,就是极限编程中 提到的用户故事(User Story)。
2019/11/4
.
12
迭代计划会(Sprint Planning Meeting)
• 安排的过程,但冲刺开始后则由队员在原计划 的基础上随机应发。
• 不同于瀑布模型将开収过程划分为需求、设计、 编码、测试等阶段,
• Scrum将整个开发过程分为多次迭代(称为 Sprint,冲刺),一般为
• 期2~4周。
2019/11/4
.
4
Scrum是什么?
带球过人需要 计划!
带球过人需 要灵活应变!
Scrum
2019/11/4
Scrum
• Scrum基本知识 • Scrum过程 • 用户故事 • 敏捷计划 • 敏捷日常跟进 • 敏捷绩效考核
2019/11/4
.
2
S
2019/11/4
.
3
Scrum概述
• Scrum是一种兼顾计划性不灵活性的敏捷开发 过程,原词来自二橄榄球中的“带球过人”。 在橄榄球比赛的每次冲刺前,都将有一个计划
2019/11/4
.
18
反思会(Retrospective Meeting)
• 在每个迭代后召开简短的反思 会。 • 总结哪些事情做的好,哪些 事情做的不好。 • 制定改进计划。
2019/11/4
.
19
用户故事 I:何为用户故事
2019/11/4
按“作为一个……,可 以……,以便……”样 弅和思路写成的用