scrum敏捷项目开发
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
产出
•产品backlog •迭代 backlog •进度曲线图
Scrum 结构框架
职能
•产品所有者 •ScrumMaster •团队
1.1角色一:产品所有者
• 定义所有产品功能 • 决定产品发布的内容以及日期 • 对产品的投入产出负责 • 根据市场变化对需要开发的功能排列优先顺
序
• 合理的调整产品功能和迭代顺序 • 认同或者拒绝迭代的交付
开始做
停止做
仅仅是诸多迭代 回顾的活动的一 种参考.
继续做
3.4每天的Scrum会议
• 属性
• • •
• •
每天都会开 15分钟结束 站着开会
• 不是为了解决问题
• 避免无关的讨论
所有相关的人被邀请 只有Scrum master，产品所有者，团队成员能 够在会上发言
团队成员需要回答3个问题
昨天你做了什么? 今天你将要做什么? 你有需要帮助的地方吗?
资源来自: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.
确保一个迭代周期的稳定
变化
• 一个迭代周期的长短的设定取决于您能够保
障多长时间需求变化不影响到产品开发
全面视角的Scrum开发
24 小时
Sprint 目标
迭代周期 2-4 周
功能1
Return 功能2 Gift wrap 功能3 Cancel 功能4 产品backlog 迭代 backlog 功能3 潜在可以发布的 增量产品
核心：Sprints
• • • •
Scrum项目周期以一组迭代周期“sprints”组成
团队能力
迭代 计划会议
迭代 优先级
产品 backlog
• 分析和评估产品Backlog各项
•
目 选择一些作为迭代的目标
迭代目 标
商业机会
迭代 计划
现有产品
• • •
决定如何实现迭代目标 从产品的backlog中选择一些创 建迭代backlog(任务) 以小时为单位评估迭代任务工 作量
迭代 backlog
应用可以运行于Oracle和 SQL Server环境.
金融服务
提供比ABC更实时的数据流 量来支持更多的技术指标.
管理迭代的 backlog
•
团队的个人将要签收其将拥有的工作
• • • •
•
•
工作不是单向的分配
对于剩余工作量的估计每天需要更新 团队中任何人都可以添加，删减或者更改迭代中 的工作项目 为了迭代目标以及将发布的结果而工作 如果对将要面对的困难不清楚，最好先定义一个 相对工作量较大的工作项目然后适时在以后将其 分散成较小额工作量的几个部分 更新每个项目的剩余工作量
内容提纲
• 敏捷开发简介 • Scrum特点 • Scrum流程及框架 • 注意事项
Scrum总体流程
阶段 开发调研 参与人 PO，SM， 团队 讨论产品需求条目 问卷调查 分析 事务 输出 故事列表
工作量估 算
发布计划 会议
SM，团队
PO，SM
使用估算扑克估算故事点 确定故事的依赖关系
PO确定当前发布的时间和应该包含的故事 PO向各干系人公开发布规划
• 整个团队都需要参加 • 邀请所有关注产品的人参加
3.3 迭代总结会议
• 周期性的回顾，总结工作中的经验和教训 • 一般 15–30 分钟 • 在每个迭代结束时开始做 • 整个团队都需要参加
• • • •
ScrumMaster 产品所有者 团队 可能还包括客户
总结会议讨论内容：
• 整个团队集结一起讨论以下方案:
敏捷宣言作者们的价值观
重视
个人与交互 可用的软件 寻求客户的合作 对变化的响应变化
重于
开发过程和工具 复杂的文档 对合同的谈判 始终遵循固定的计划
重于
重于
重于
资源来自:
内容提纲
• 敏捷开发简介 • Scrum特点 • Scrum流程及框架 • 注意事项
1 2
3
• 对于 ScrumMaster来说这些问答不是工作进
•
度报告
他们是团队成员彼此的承诺
内容提纲
• 敏捷开发简介 • Scrum特点 • Scrum流程及框架 • 注意事项
注意事项：
1、提供建议而不是规则。 2、团队自管理，项目经理、小组长的领 导、指导、协同职能大于其指令职能。 3、团队共同估算。 4、每日站会，不是工作汇报。 5、必须严格保证每个迭代按时发布。
Sprint Backlog
Sprint
SM，团队
潜在可交付 的产品增量
Sprint评 审会议 Sprint回 顾会议
PO，SM， 团队 PO，SM， 团队
更好的 Scrum流程
Scrum 结构框架
职能
•产品所有者 •ScrumMaster •团队 仪式 •迭代计划 •迭代验收 •迭代回顾 •每天召开的 scrum 会议
迭代backlog的样例
任务
编写用户界面 编写中间层 测试中间层
Mon Tues Wed Thur Fri
8 16 8 4 12 16 8 10 16 4 11 8
编写在线帮助 编写Foo类 增加对错误的日志记录
12 8 8 8 8 8 4 8
2.3迭代耗散图
小时数
任务
编写用户界面 编写中间层 测试中间层 编写在线帮助
1.3角色三：团队
• • • • •
经典团队拥有 5-9 人 团队成员都是是多面手:
•
程序员, 测试员, 用户体验设计, 等等.
团队成员都全职工作
•
特殊职能可以例外 (例如, 数据库管理员)
团队自我组织和管理 团队关系在一个迭代中应该是固定的，个人的 职能可以在新迭代开始时发生调整
Scrum 结构框架
产出
•产品backlog •迭代 backlog •进度曲线图
2.1产品 backlog
• 需求 • 项目中待完成的工作列表 • 理想的是每一个待完成的工
作都将对客户和用户产生价 值 • 产品所有者将对这个列表进 行优先级排序 • 每个迭代开始前优先级的排 序工作还需要再度修正
一组产品 backlog
品。此时，就可以下一步的决定是继续完善需求或者直 接发布了。
特点
• 自我管理的团队 • 以“sprint（冲刺）”为周期迭代的产品开 • • • •
发 以一系列“产品 Backlog（待处理任务）” 记录了产品需求 没有特定的工程实践规则 有富有创造力的敏捷开发环境，交付产品 它是 “敏捷方法”之一，可以和其它方法 互补使用。
一个好的用户故事（backlog）包括三个要素：
• 1. • 2. • 3.
角色：谁要使用这个功能。 活动：需要完成什么样的功能。
商业价值：为什么需要这个功能，这个 功能带来什么样的价值。
产品 backlog的样例
2.2迭代目标
• 简短陈述这个迭代将要完成什么
生命科学
功能用于人口遗传学研究.
数据库应用
•
可以和极限开发的迭代周期类比
典型的迭代周期为2-4周或者最多一个自然月 一个固定的周期能够创造出项目的更优美的节奏 感 产品的设计，开发，测试全部都在一个迭代内完 成
顺序 vs. 重叠开发过程
需求 设计 代码 测试
Scrum并非以一段时间 集中完成一个过程 ...而是将所有过程中必 须的每一部分集中在这 段时间内完成
为了选择好去处度 过这个假期，我需 要先看到酒店的照 片.
编写后台和中间层(8 小时) 编写界面(4) 编写测试用例(4) 写类foo(6) 更新性能测试用例(4)
3.2迭代验收会议
• 团队需要演示所完成的迭代工作 • 典型的做法是使用演示形式展示新功能或者 •
• •
底层架构的实现 非正式的
2小时的提前准备 不需要正式演示文档
结束语：没有银弹！
完
谢谢大家！
技术
迭代计划成果
•
• •
团队自己从产品的backlog中选择一些他们能够完成的 任务作为迭代的backlog 迭代backlog被创建
ห้องสมุดไป่ตู้
• •
任务被确认并且每一任务估计工作量应该在1-16小时左右 迭代的backlog的确定是团队协作的结果，而不是只有 scrummaster的决定
概要设计已经讨论完成
1.2角色二：ScrumMaster
• • • • •
对项目的直接管理
领导团队完成Scrum的实践以及体现其价值
排除团队遇到的困难 确保团队的胜任其工作，并保持高效的生产率
使得团队紧密合作，使得团队个人具有多方面 职能的工作能力
保护团队不受到外来无端影响
•
• 保证开发过程按计划进行，组织 各种会议。
Scrum敏捷项目开发
内容提纲
• 敏捷开发简介 • Scrum特点 • Scrum流程及框架 • 注意事项
内容提纲
• 敏捷开发简介 • Scrum特点 • Scrum流程及框架 • 注意事项
敏捷开发
• 敏捷开发是一种以人为核心、迭代、循序渐进
的开发方法
• 主要有如下几个方法：
极限编程(XP) 、 特性驱动开发(FDD) 、 Scrum、 测试驱动开发(TDD) 等等 这些方法的侧重点各有不同，可以相互之间互补使用。
Scrum 的精髓
• Scrum使得我们能够专注于如何在最短的时间内实现最
有价值的部分。
•
Scrum使得我们能够快速的和周期性的监督实际产品发 展的状况.（每2~4周）
• 设定商业价值优先级；团队通过自主管理采用定最好的
方法，交付优先级最高的需求。
• 每隔每2~4周，我们就可以看到实实在在的可以上线的产
带估算的故 事列表
产品 Backlog
Sprint计 划会议
SM，团队
PO确定最近1-2个Sprint的最优先级故事 团队从产品Backlog中的最高优先级故事中挑选承诺 完成的条目 分解条目成为工作项 评估工作项工时（小时为单位）
按Sprint Backlog产出软件产品 软件产品必须是潜在可交付的（经过完整测试，可运 行，有完整用户文档） 团队向PO及相关干系人演示产品增量 收集意见，为下一个Sprint作准备 对开发流程进行回顾，检查哪些方法是值得保留的， 哪些是要废弃的。
Mon Tues Wed Thur Fri
8 16 8 12 4 12 16 8 10 16 7 11
8
50 40 小时数 30 20 10 0 Mon Tue Wed Thu Fri
Scrum 结构框架
会议
•迭代计划会议 •迭代验收会议 •迭代总结会议 •每天召开的 scrum 会议
3.1迭代计划会议
•产品backlog •迭代 backlog •进度曲线图
Scrum 结构框架
职能
•产品所有者 •ScrumMaster •团队
1.1角色一:产品所有者
• 定义所有产品功能 • 决定产品发布的内容以及日期 • 对产品的投入产出负责 • 根据市场变化对需要开发的功能排列优先顺
序
• 合理的调整产品功能和迭代顺序 • 认同或者拒绝迭代的交付
开始做
停止做
仅仅是诸多迭代 回顾的活动的一 种参考.
继续做
3.4每天的Scrum会议
• 属性
• • •
• •
每天都会开 15分钟结束 站着开会
• 不是为了解决问题
• 避免无关的讨论
所有相关的人被邀请 只有Scrum master，产品所有者，团队成员能 够在会上发言
团队成员需要回答3个问题
昨天你做了什么? 今天你将要做什么? 你有需要帮助的地方吗?
资源来自: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.
确保一个迭代周期的稳定
变化
• 一个迭代周期的长短的设定取决于您能够保
障多长时间需求变化不影响到产品开发
全面视角的Scrum开发
24 小时
Sprint 目标
迭代周期 2-4 周
功能1
Return 功能2 Gift wrap 功能3 Cancel 功能4 产品backlog 迭代 backlog 功能3 潜在可以发布的 增量产品
核心：Sprints
• • • •
Scrum项目周期以一组迭代周期“sprints”组成
团队能力
迭代 计划会议
迭代 优先级
产品 backlog
• 分析和评估产品Backlog各项
•
目 选择一些作为迭代的目标
迭代目 标
商业机会
迭代 计划
现有产品
• • •
决定如何实现迭代目标 从产品的backlog中选择一些创 建迭代backlog(任务) 以小时为单位评估迭代任务工 作量
迭代 backlog
应用可以运行于Oracle和 SQL Server环境.
金融服务
提供比ABC更实时的数据流 量来支持更多的技术指标.
管理迭代的 backlog
•
团队的个人将要签收其将拥有的工作
• • • •
•
•
工作不是单向的分配
对于剩余工作量的估计每天需要更新 团队中任何人都可以添加，删减或者更改迭代中 的工作项目 为了迭代目标以及将发布的结果而工作 如果对将要面对的困难不清楚，最好先定义一个 相对工作量较大的工作项目然后适时在以后将其 分散成较小额工作量的几个部分 更新每个项目的剩余工作量
内容提纲
• 敏捷开发简介 • Scrum特点 • Scrum流程及框架 • 注意事项
Scrum总体流程
阶段 开发调研 参与人 PO，SM， 团队 讨论产品需求条目 问卷调查 分析 事务 输出 故事列表
工作量估 算
发布计划 会议
SM，团队
PO，SM
使用估算扑克估算故事点 确定故事的依赖关系
PO确定当前发布的时间和应该包含的故事 PO向各干系人公开发布规划
• 整个团队都需要参加 • 邀请所有关注产品的人参加
3.3 迭代总结会议
• 周期性的回顾，总结工作中的经验和教训 • 一般 15–30 分钟 • 在每个迭代结束时开始做 • 整个团队都需要参加
• • • •
ScrumMaster 产品所有者 团队 可能还包括客户
总结会议讨论内容：
• 整个团队集结一起讨论以下方案:
敏捷宣言作者们的价值观
重视
个人与交互 可用的软件 寻求客户的合作 对变化的响应变化
重于
开发过程和工具 复杂的文档 对合同的谈判 始终遵循固定的计划
重于
重于
重于
资源来自:
内容提纲
• 敏捷开发简介 • Scrum特点 • Scrum流程及框架 • 注意事项
1 2
3
• 对于 ScrumMaster来说这些问答不是工作进
•
度报告
他们是团队成员彼此的承诺
内容提纲
• 敏捷开发简介 • Scrum特点 • Scrum流程及框架 • 注意事项
注意事项：
1、提供建议而不是规则。 2、团队自管理，项目经理、小组长的领 导、指导、协同职能大于其指令职能。 3、团队共同估算。 4、每日站会，不是工作汇报。 5、必须严格保证每个迭代按时发布。
Sprint Backlog
Sprint
SM，团队
潜在可交付 的产品增量
Sprint评 审会议 Sprint回 顾会议
PO，SM， 团队 PO，SM， 团队
更好的 Scrum流程
Scrum 结构框架
职能
•产品所有者 •ScrumMaster •团队 仪式 •迭代计划 •迭代验收 •迭代回顾 •每天召开的 scrum 会议
迭代backlog的样例
任务
编写用户界面 编写中间层 测试中间层
Mon Tues Wed Thur Fri
8 16 8 4 12 16 8 10 16 4 11 8
编写在线帮助 编写Foo类 增加对错误的日志记录
12 8 8 8 8 8 4 8
2.3迭代耗散图
小时数
任务
编写用户界面 编写中间层 测试中间层 编写在线帮助
1.3角色三：团队
• • • • •
经典团队拥有 5-9 人 团队成员都是是多面手:
•
程序员, 测试员, 用户体验设计, 等等.
团队成员都全职工作
•
特殊职能可以例外 (例如, 数据库管理员)
团队自我组织和管理 团队关系在一个迭代中应该是固定的，个人的 职能可以在新迭代开始时发生调整
Scrum 结构框架
产出
•产品backlog •迭代 backlog •进度曲线图
2.1产品 backlog
• 需求 • 项目中待完成的工作列表 • 理想的是每一个待完成的工
作都将对客户和用户产生价 值 • 产品所有者将对这个列表进 行优先级排序 • 每个迭代开始前优先级的排 序工作还需要再度修正
一组产品 backlog
品。此时，就可以下一步的决定是继续完善需求或者直 接发布了。
特点
• 自我管理的团队 • 以“sprint（冲刺）”为周期迭代的产品开 • • • •
发 以一系列“产品 Backlog（待处理任务）” 记录了产品需求 没有特定的工程实践规则 有富有创造力的敏捷开发环境，交付产品 它是 “敏捷方法”之一，可以和其它方法 互补使用。
一个好的用户故事（backlog）包括三个要素：
• 1. • 2. • 3.
角色：谁要使用这个功能。 活动：需要完成什么样的功能。
商业价值：为什么需要这个功能，这个 功能带来什么样的价值。
产品 backlog的样例
2.2迭代目标
• 简短陈述这个迭代将要完成什么
生命科学
功能用于人口遗传学研究.
数据库应用
•
可以和极限开发的迭代周期类比
典型的迭代周期为2-4周或者最多一个自然月 一个固定的周期能够创造出项目的更优美的节奏 感 产品的设计，开发，测试全部都在一个迭代内完 成
顺序 vs. 重叠开发过程
需求 设计 代码 测试
Scrum并非以一段时间 集中完成一个过程 ...而是将所有过程中必 须的每一部分集中在这 段时间内完成
为了选择好去处度 过这个假期，我需 要先看到酒店的照 片.
编写后台和中间层(8 小时) 编写界面(4) 编写测试用例(4) 写类foo(6) 更新性能测试用例(4)
3.2迭代验收会议
• 团队需要演示所完成的迭代工作 • 典型的做法是使用演示形式展示新功能或者 •
• •
底层架构的实现 非正式的
2小时的提前准备 不需要正式演示文档
结束语：没有银弹！
完
谢谢大家！
技术
迭代计划成果
•
• •
团队自己从产品的backlog中选择一些他们能够完成的 任务作为迭代的backlog 迭代backlog被创建
ห้องสมุดไป่ตู้
• •
任务被确认并且每一任务估计工作量应该在1-16小时左右 迭代的backlog的确定是团队协作的结果，而不是只有 scrummaster的决定
概要设计已经讨论完成
1.2角色二：ScrumMaster
• • • • •
对项目的直接管理
领导团队完成Scrum的实践以及体现其价值
排除团队遇到的困难 确保团队的胜任其工作，并保持高效的生产率
使得团队紧密合作，使得团队个人具有多方面 职能的工作能力
保护团队不受到外来无端影响
•
• 保证开发过程按计划进行，组织 各种会议。
Scrum敏捷项目开发
内容提纲
• 敏捷开发简介 • Scrum特点 • Scrum流程及框架 • 注意事项
内容提纲
• 敏捷开发简介 • Scrum特点 • Scrum流程及框架 • 注意事项
敏捷开发
• 敏捷开发是一种以人为核心、迭代、循序渐进
的开发方法
• 主要有如下几个方法：
极限编程(XP) 、 特性驱动开发(FDD) 、 Scrum、 测试驱动开发(TDD) 等等 这些方法的侧重点各有不同，可以相互之间互补使用。
Scrum 的精髓
• Scrum使得我们能够专注于如何在最短的时间内实现最
有价值的部分。
•
Scrum使得我们能够快速的和周期性的监督实际产品发 展的状况.（每2~4周）
• 设定商业价值优先级；团队通过自主管理采用定最好的
方法，交付优先级最高的需求。
• 每隔每2~4周，我们就可以看到实实在在的可以上线的产
带估算的故 事列表
产品 Backlog
Sprint计 划会议
SM，团队
PO确定最近1-2个Sprint的最优先级故事 团队从产品Backlog中的最高优先级故事中挑选承诺 完成的条目 分解条目成为工作项 评估工作项工时（小时为单位）
按Sprint Backlog产出软件产品 软件产品必须是潜在可交付的（经过完整测试，可运 行，有完整用户文档） 团队向PO及相关干系人演示产品增量 收集意见，为下一个Sprint作准备 对开发流程进行回顾，检查哪些方法是值得保留的， 哪些是要废弃的。
Mon Tues Wed Thur Fri
8 16 8 12 4 12 16 8 10 16 7 11
8
50 40 小时数 30 20 10 0 Mon Tue Wed Thu Fri
Scrum 结构框架
会议
•迭代计划会议 •迭代验收会议 •迭代总结会议 •每天召开的 scrum 会议
3.1迭代计划会议