Scrum敏捷项目开发介绍
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Scrum敏捷项目开发介绍
软件工程 Scrum敏捷开发介绍 Scrum的目的和意义 Scrum的实施
2
软件危机
①软件开发费用和进度失控 ②软件的可靠性差 ③生产出来的软件难以维护 ④用户对“已完成”的系统不满意现象经常发生
3
软件工程– 瀑布模型
4
需求危机
5
程序猿
6
瀑布模型开发的缺陷
Scrum的优势
聚焦设计 关注市场的价值 团队没有领导者角色 障碍及时反馈 发现错误越早,付出的代价越少 创建学习型的团队 减少不必要的文档
18
Scrum的经典案例
•微软 •雅虎 •谷歌 •电艺 •飞利浦 •西门子 •诺基亚 •英国广播公司 •尼尔森视界公司 •第一美国不动产经纪公司 •美国第一资本投资国际集团 •Intuit •High Moon Studios •Lockheed Martin •BMC Software •Ipswitch •John Deere •Lexis Nexis •Sabre •Salesforce.com •Time Warner •Turner Broadcasting •Oce
源自文库19
Scrum的缺陷
压力大 不要方便异步开发 程序维护成本高 无法被中断
20
Scrum的精髓
• SCRUM使得我们能够专注于如何在最短的时间内实
•
•
•
现最有价值的部分。 SCRUM使得我们能够快速的经常的监督实际产品发 展的状况.（每两周或一个月） 团队按照商业价值的高低先完成高优先级的产品功 能，并自主管理，凝结了团队智慧创造出最好的方 法因而提高效率。 每隔一两周或者一个月，我们就可以看到实实在在 的可以上线的产品。此时，就可以下一步的决定是 继续完善功能实现更多需求或者直接发布了。
产品backlog是一个产品或项目期望的、排列好优先 级的功能列表。 优先级由商业价值、风险、和必要性决定。 产品负责人负责产品Backlog的内容、可用性和优先 级。 产品Backlog永远不会是完整的，最初的版本只列出 最基本的和非常明确的需求，这些需求至少要足够 一个Sprint开发。
14
对项目的直接管理
Scrum Master
领导团队完成Scrum的实践以及体现其价值
排除团队遇到的困难
确保团队的胜任其工作，并保持高效的生产 率 使得团队紧密合作，使得团队个人具有多方 面职能的工作能力 保护团队不受到外来无端影响
15
Scrum Team 经典团队拥有 5-9 人
23
发布燃尽图（Release Burndown Chart）
在Scrum项目中，团队通过每个Sprint结束时更新的 发布燃尽图来跟踪整个发布计划的进展。 发布燃尽图记录了在一段时间内产品Backlog的总剩 余估算工作量的变化趋势。
21
Scrum的4个工件
产品Backlog（Product Backlog） 发布燃尽图（Release Burndown Chart） Sprint Backlog Sprint燃尽图（Sprint Burndown Chart）
22
产品Backlog（Product Backlog）
维护成本维护成本非常高 人力成本非常多 团队氛围压抑 团队成员非常累 文档沟通,不是人之间的沟通
7
1. Individuals and interactions over processes and tools个体与交 互比过程与工具更加有效 2. Working software over comprehensive documentation能够满 足用户的软件比综合的文档更加有效 3. Customer collaboration over contract negotiation客户协作比 守住合同条款更加重要 4. Responding to change over following a plan响应变化比遵守计 划更加有用
项目经理 Scrum Master 确保参与者都遵守Scrum的流程和规则 团队成员 Team 自组织，自管理寻找最优方案实现需求
13
Product Owner
定义所有产品功能 决定产品发布的内容以及日期
对产品的投入产出负责
根据市场变化对需要开发的功能排列优先顺序 合理的调整产品功能和迭代顺序 认同或者拒绝迭代的交付
敏捷开发的四个核心思想
8
敏捷开发宣言
个人与交互 可用的软件
重于
开发过程和工具 复杂的文档
重于
寻求客户的合作
对变化的响应变化
9
重于
对合同的谈判
始终遵循固定的计划
重于
两种敏捷开发的方法
Scrum 极限开发ExtremeProgramming，简称XP
10
Scrum角色及职责 猪和鸡的故事
Scrum 三思过后我决定 好的，我很 你想不想 不和你开餐馆了。 “猪”类 “鸡”类 乐意。你想 和我一起 因为我全身心投 火腿鸡蛋！ 为餐馆取个 开家餐厅？ 入，而你只牵涉 对项目感兴趣，从 产品负责人 什么名字呢？ 入内！ 项目收益但不承担 Scrum Master 团队Team
项目责任的人
在项目中需要分清楚谁是“猪”类谁是“鸡”类，以免项 目受到不必要的干扰。
11
Scrum的流程
12
人员和角色
产品负责人 Product Owner 规划产品需求，投资回报ROI和发布计 划；督促团队开发最具价值的功能。
Product Owner Team Master Team
团队成员都是是多面手:
程序员, 测试员, 用户经验设计, 等等.
团队成员都全职工作
特殊职能可以例外 (例如, 数据库管理员)
团队自我组织和管理 团队关系在一个迭代中应该是固定的，个 人的职能可以在新迭代开始时发生调整
16
软件开发失败的原因
17
软件存在不确定性,根源 软件预估的办法的没有很好的发展 代码质量难以估计 乐观主义性思想 太多的管理活动参与,不是件好事 程序员多数比较自负 英文非常重要,易于维护 大多程序员只有堆彻代码的能力
软件工程 Scrum敏捷开发介绍 Scrum的目的和意义 Scrum的实施
2
软件危机
①软件开发费用和进度失控 ②软件的可靠性差 ③生产出来的软件难以维护 ④用户对“已完成”的系统不满意现象经常发生
3
软件工程– 瀑布模型
4
需求危机
5
程序猿
6
瀑布模型开发的缺陷
Scrum的优势
聚焦设计 关注市场的价值 团队没有领导者角色 障碍及时反馈 发现错误越早,付出的代价越少 创建学习型的团队 减少不必要的文档
18
Scrum的经典案例
•微软 •雅虎 •谷歌 •电艺 •飞利浦 •西门子 •诺基亚 •英国广播公司 •尼尔森视界公司 •第一美国不动产经纪公司 •美国第一资本投资国际集团 •Intuit •High Moon Studios •Lockheed Martin •BMC Software •Ipswitch •John Deere •Lexis Nexis •Sabre •Salesforce.com •Time Warner •Turner Broadcasting •Oce
源自文库19
Scrum的缺陷
压力大 不要方便异步开发 程序维护成本高 无法被中断
20
Scrum的精髓
• SCRUM使得我们能够专注于如何在最短的时间内实
•
•
•
现最有价值的部分。 SCRUM使得我们能够快速的经常的监督实际产品发 展的状况.（每两周或一个月） 团队按照商业价值的高低先完成高优先级的产品功 能，并自主管理，凝结了团队智慧创造出最好的方 法因而提高效率。 每隔一两周或者一个月，我们就可以看到实实在在 的可以上线的产品。此时，就可以下一步的决定是 继续完善功能实现更多需求或者直接发布了。
产品backlog是一个产品或项目期望的、排列好优先 级的功能列表。 优先级由商业价值、风险、和必要性决定。 产品负责人负责产品Backlog的内容、可用性和优先 级。 产品Backlog永远不会是完整的，最初的版本只列出 最基本的和非常明确的需求，这些需求至少要足够 一个Sprint开发。
14
对项目的直接管理
Scrum Master
领导团队完成Scrum的实践以及体现其价值
排除团队遇到的困难
确保团队的胜任其工作，并保持高效的生产 率 使得团队紧密合作，使得团队个人具有多方 面职能的工作能力 保护团队不受到外来无端影响
15
Scrum Team 经典团队拥有 5-9 人
23
发布燃尽图（Release Burndown Chart）
在Scrum项目中，团队通过每个Sprint结束时更新的 发布燃尽图来跟踪整个发布计划的进展。 发布燃尽图记录了在一段时间内产品Backlog的总剩 余估算工作量的变化趋势。
21
Scrum的4个工件
产品Backlog（Product Backlog） 发布燃尽图（Release Burndown Chart） Sprint Backlog Sprint燃尽图（Sprint Burndown Chart）
22
产品Backlog（Product Backlog）
维护成本维护成本非常高 人力成本非常多 团队氛围压抑 团队成员非常累 文档沟通,不是人之间的沟通
7
1. Individuals and interactions over processes and tools个体与交 互比过程与工具更加有效 2. Working software over comprehensive documentation能够满 足用户的软件比综合的文档更加有效 3. Customer collaboration over contract negotiation客户协作比 守住合同条款更加重要 4. Responding to change over following a plan响应变化比遵守计 划更加有用
项目经理 Scrum Master 确保参与者都遵守Scrum的流程和规则 团队成员 Team 自组织，自管理寻找最优方案实现需求
13
Product Owner
定义所有产品功能 决定产品发布的内容以及日期
对产品的投入产出负责
根据市场变化对需要开发的功能排列优先顺序 合理的调整产品功能和迭代顺序 认同或者拒绝迭代的交付
敏捷开发的四个核心思想
8
敏捷开发宣言
个人与交互 可用的软件
重于
开发过程和工具 复杂的文档
重于
寻求客户的合作
对变化的响应变化
9
重于
对合同的谈判
始终遵循固定的计划
重于
两种敏捷开发的方法
Scrum 极限开发ExtremeProgramming，简称XP
10
Scrum角色及职责 猪和鸡的故事
Scrum 三思过后我决定 好的，我很 你想不想 不和你开餐馆了。 “猪”类 “鸡”类 乐意。你想 和我一起 因为我全身心投 火腿鸡蛋！ 为餐馆取个 开家餐厅？ 入，而你只牵涉 对项目感兴趣，从 产品负责人 什么名字呢？ 入内！ 项目收益但不承担 Scrum Master 团队Team
项目责任的人
在项目中需要分清楚谁是“猪”类谁是“鸡”类，以免项 目受到不必要的干扰。
11
Scrum的流程
12
人员和角色
产品负责人 Product Owner 规划产品需求，投资回报ROI和发布计 划；督促团队开发最具价值的功能。
Product Owner Team Master Team
团队成员都是是多面手:
程序员, 测试员, 用户经验设计, 等等.
团队成员都全职工作
特殊职能可以例外 (例如, 数据库管理员)
团队自我组织和管理 团队关系在一个迭代中应该是固定的，个 人的职能可以在新迭代开始时发生调整
16
软件开发失败的原因
17
软件存在不确定性,根源 软件预估的办法的没有很好的发展 代码质量难以估计 乐观主义性思想 太多的管理活动参与,不是件好事 程序员多数比较自负 英文非常重要,易于维护 大多程序员只有堆彻代码的能力