敏捷培训宣讲专题培训课件
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
保护团队不受干扰，并消除团队进步的障碍 推动团队不断改进
软件开发，代码交付 对需求提出开发层面的专业建议，并对未来的设计架构提出
建议
项目交付质量保证 记录缺陷 测试用例和测试数据
在业务和IT领域之间的沟通，以支持架构师和指导技术 协助规划和估计活动 确保应用程序/技术与路线图一致
协调敏捷团队内部和整个敏捷团队的开发人员和测试人员 向团队提供技术专长 协调环境，代码升级和环境刷新 技术负责人应该是开发组长
产出
产品backlog 产品级别的需求和优先级 用户故事grooming 需求文档 和SME(Subject Matter Experts)互动 用户故事验收标准
•议程
1
敏捷工作机制
2
敏捷团队角色及职责
3
敏捷团结架构
* 名词解释
我们在敏捷项目管理中常见的一些名词：PO、SM、TEAM、Sprint、Product Backlog等
•1. 敏捷工作机制
•敏捷开发模式
敏捷是一种有时间约束的、迭代的开发软件的方法。它可以在业务优先级确定之后的短时间内提供潜在的可交付的工作代码，同时提供处理不确定性并适 应不断变化的需求的能力。它是从项目开始逐步构建软件，而不是在交付期将至时尝试一次性交付。
•2. 敏捷团队角色及职责
•敏捷团队角色
角色
产品负责人
Scrum Master 开发 测试
方案架构师 技术负责人
职责
设定产品愿景和业务重点 确保工作优先级在backlog中体现 参与需求预估 引出并充分记录功能和非功能性需求 代表开发团队和业务交流，代表业务和开发团队交流 促进团队的协作
Agile Unified Process
敏捷统一(A流UP程) (AUP)
一个由7个重要原则组成 的迭代增量过程，重点 在于每个步骤中较长的 生命周期和迭代
精Le益an,,FFDDDD,,DTSDDMD,,eetct.c
精益消除非增值活动， 增加客户价值。 FDD是 一个模型驱动的短迭代 过程
大型组织实施不同框架（或者不同框架的不同部分）的组合，以实现企业级别的敏捷
流程和工具方面 的进展情况
依赖关系？
• 提出问题和改进 • 我们团队对哪些
建议
团队有具体什么
样的期待？
• 我们团队有哪些
问题和风险也会
存在其他团队中？
图例
必须参与
选择性参与
不必参与
•每日工作围绕用户故事展开
•什么是用户故事
• 描述高级的功能 • 代表一小部分终端用户功能 • 是合作书写的结果 • 是对未来的承诺，是“更为详细的”语言 • 包含书面文字、口头叙述、图片等 • 包含了用户故事的验收标准的边界
为什么使用看板？
• 看板促进流动的概念，以持续为客户/最终用户提供价 值
• 通过可视化工作流程，我们可以为每个人都看到任务， 活动和瓶颈
• 正在进行中的工作（WIP）确保我们专注于提高质量， 增加对任务的关注，并确保我们停止启动并开始整理
主要原则：
• 可视化工作 • 限制正在进行的工作（WIP） • 管理流程 • 明确制定流程政策 • 实施反馈回路 • 协同改进，实验演变
* 敏捷原则同样适用于产品和项目管理
•Scrum工作机制
•每个Sprint的活动
Sprint 计划会议
Backlog 梳理会议
Sprint Demo Sprint 回顾会议
1
2
3
4
5
6
7
8
9 10
每日站会
•Sprint 会议安排
事件
频率 时间
主要议程
参与者
敏捷教练 产品负责人 开发团队 技术架构师 传统项目敏捷联系人
例子 : 叙述：
作为一个…手机银行的用户 我想要…查看我的账户信息 所以…我可以了解我的账户活动情况
wenku.baidu.com验收标准:
给定……我已经登录系统 当……我选择在我的手机银行账户查看账 户信息时
然后……我能根据所选择的账户（账户名 称、投资理财方案、外汇购买等）查看账 户细节
•故事大小——运用分数进行估计
• 选择一个中等故事， 给出5分 • 评估与此相关的其他故事：与此相关的其他故事 - 一半大 - 两倍大 - 大一点 • 使用下面范围的值
敏捷
Extreme Programming
极限编(X程P)(XP)
专注于应对不断变化的 客户需求。 与Scrum相 比，XP团队的工作时间 通常较短
SSccrruumm
使所有关键利益相关者 定期合作，提供高品质 的工作，提高可见度和 适应性
KKaannbbaann
不是过程框架，而是通 过增量改进来改变的一 种模型。 结构比Scrum 少
迭代计划会 需求梳理会 每日站立会 迭代评审会 迭代回顾会 迭代协同会
每个迭代1次
每个迭代1-2次
每天1次
每个迭代1次
每个迭代1次
每周一次
120分钟
90分钟
15分钟
60分钟
60分钟
30分钟
• 确定在即将到来 的冲刺中可以交 付哪些用户故事
• 创建冲刺待办事 项（从产品待办 事项中来的用户 故事）
• 将用户故事分解 成任务（“如 何”），并包括 时间预估和人员 分配
用户故事, 接近Sprint
阶段用户故事– 几个Sprint之后
0 .5
1
2
3
5
8 13 20 40 100 ∞
•估分流程
This loop only takes 15 minutes
This loop only takes 35 minutes
•我们怎么追踪进度？——看板
看板是一个“拉拽”的系统，通过优化“系统”中的工作流程，提供重点，可持续发展和频繁交付
• 完整的用户故事 （使之达到“准 备好”的状态）
• 昨天我做了什么 帮助团队达到冲 刺目标？
• 我今天要做什么 帮助团队达到冲 刺目标？
• 有哪些阻碍我达 到目标的障碍？
• 向产品负责人展 示“完成的”工 作
• 请产品负责人提 供审阅意见（同 意或拒绝）
• 评估整个冲刺过 • 我们团队对外部
程的人员，关系， 团队有什么样的
促进团队互动 消除障碍 开展会议
参与需求预估 帮助需出要求并定义最佳设计 提供业务的功能和非功能性要求，同时遵守编码标准 开发单元测试和重构代码
帮助定义需求并协助估算 定义测试用例，脚本和步骤，以完全测试根据需求交付的软件 定义和准备测试数据，进行手动和自动测试 与团队沟通，提供诚实的反馈
软件开发，代码交付 对需求提出开发层面的专业建议，并对未来的设计架构提出
建议
项目交付质量保证 记录缺陷 测试用例和测试数据
在业务和IT领域之间的沟通，以支持架构师和指导技术 协助规划和估计活动 确保应用程序/技术与路线图一致
协调敏捷团队内部和整个敏捷团队的开发人员和测试人员 向团队提供技术专长 协调环境，代码升级和环境刷新 技术负责人应该是开发组长
产出
产品backlog 产品级别的需求和优先级 用户故事grooming 需求文档 和SME(Subject Matter Experts)互动 用户故事验收标准
•议程
1
敏捷工作机制
2
敏捷团队角色及职责
3
敏捷团结架构
* 名词解释
我们在敏捷项目管理中常见的一些名词：PO、SM、TEAM、Sprint、Product Backlog等
•1. 敏捷工作机制
•敏捷开发模式
敏捷是一种有时间约束的、迭代的开发软件的方法。它可以在业务优先级确定之后的短时间内提供潜在的可交付的工作代码，同时提供处理不确定性并适 应不断变化的需求的能力。它是从项目开始逐步构建软件，而不是在交付期将至时尝试一次性交付。
•2. 敏捷团队角色及职责
•敏捷团队角色
角色
产品负责人
Scrum Master 开发 测试
方案架构师 技术负责人
职责
设定产品愿景和业务重点 确保工作优先级在backlog中体现 参与需求预估 引出并充分记录功能和非功能性需求 代表开发团队和业务交流，代表业务和开发团队交流 促进团队的协作
Agile Unified Process
敏捷统一(A流UP程) (AUP)
一个由7个重要原则组成 的迭代增量过程，重点 在于每个步骤中较长的 生命周期和迭代
精Le益an,,FFDDDD,,DTSDDMD,,eetct.c
精益消除非增值活动， 增加客户价值。 FDD是 一个模型驱动的短迭代 过程
大型组织实施不同框架（或者不同框架的不同部分）的组合，以实现企业级别的敏捷
流程和工具方面 的进展情况
依赖关系？
• 提出问题和改进 • 我们团队对哪些
建议
团队有具体什么
样的期待？
• 我们团队有哪些
问题和风险也会
存在其他团队中？
图例
必须参与
选择性参与
不必参与
•每日工作围绕用户故事展开
•什么是用户故事
• 描述高级的功能 • 代表一小部分终端用户功能 • 是合作书写的结果 • 是对未来的承诺，是“更为详细的”语言 • 包含书面文字、口头叙述、图片等 • 包含了用户故事的验收标准的边界
为什么使用看板？
• 看板促进流动的概念，以持续为客户/最终用户提供价 值
• 通过可视化工作流程，我们可以为每个人都看到任务， 活动和瓶颈
• 正在进行中的工作（WIP）确保我们专注于提高质量， 增加对任务的关注，并确保我们停止启动并开始整理
主要原则：
• 可视化工作 • 限制正在进行的工作（WIP） • 管理流程 • 明确制定流程政策 • 实施反馈回路 • 协同改进，实验演变
* 敏捷原则同样适用于产品和项目管理
•Scrum工作机制
•每个Sprint的活动
Sprint 计划会议
Backlog 梳理会议
Sprint Demo Sprint 回顾会议
1
2
3
4
5
6
7
8
9 10
每日站会
•Sprint 会议安排
事件
频率 时间
主要议程
参与者
敏捷教练 产品负责人 开发团队 技术架构师 传统项目敏捷联系人
例子 : 叙述：
作为一个…手机银行的用户 我想要…查看我的账户信息 所以…我可以了解我的账户活动情况
wenku.baidu.com验收标准:
给定……我已经登录系统 当……我选择在我的手机银行账户查看账 户信息时
然后……我能根据所选择的账户（账户名 称、投资理财方案、外汇购买等）查看账 户细节
•故事大小——运用分数进行估计
• 选择一个中等故事， 给出5分 • 评估与此相关的其他故事：与此相关的其他故事 - 一半大 - 两倍大 - 大一点 • 使用下面范围的值
敏捷
Extreme Programming
极限编(X程P)(XP)
专注于应对不断变化的 客户需求。 与Scrum相 比，XP团队的工作时间 通常较短
SSccrruumm
使所有关键利益相关者 定期合作，提供高品质 的工作，提高可见度和 适应性
KKaannbbaann
不是过程框架，而是通 过增量改进来改变的一 种模型。 结构比Scrum 少
迭代计划会 需求梳理会 每日站立会 迭代评审会 迭代回顾会 迭代协同会
每个迭代1次
每个迭代1-2次
每天1次
每个迭代1次
每个迭代1次
每周一次
120分钟
90分钟
15分钟
60分钟
60分钟
30分钟
• 确定在即将到来 的冲刺中可以交 付哪些用户故事
• 创建冲刺待办事 项（从产品待办 事项中来的用户 故事）
• 将用户故事分解 成任务（“如 何”），并包括 时间预估和人员 分配
用户故事, 接近Sprint
阶段用户故事– 几个Sprint之后
0 .5
1
2
3
5
8 13 20 40 100 ∞
•估分流程
This loop only takes 15 minutes
This loop only takes 35 minutes
•我们怎么追踪进度？——看板
看板是一个“拉拽”的系统，通过优化“系统”中的工作流程，提供重点，可持续发展和频繁交付
• 完整的用户故事 （使之达到“准 备好”的状态）
• 昨天我做了什么 帮助团队达到冲 刺目标？
• 我今天要做什么 帮助团队达到冲 刺目标？
• 有哪些阻碍我达 到目标的障碍？
• 向产品负责人展 示“完成的”工 作
• 请产品负责人提 供审阅意见（同 意或拒绝）
• 评估整个冲刺过 • 我们团队对外部
程的人员，关系， 团队有什么样的
促进团队互动 消除障碍 开展会议
参与需求预估 帮助需出要求并定义最佳设计 提供业务的功能和非功能性要求，同时遵守编码标准 开发单元测试和重构代码
帮助定义需求并协助估算 定义测试用例，脚本和步骤，以完全测试根据需求交付的软件 定义和准备测试数据，进行手动和自动测试 与团队沟通，提供诚实的反馈