任你选择
课程大纲
第一天 3:00 PM-6:00 PM | 什么是敏捷 | 传统模式遇到的问题 |
为什么引入敏捷 | ||
敏捷开发定义 | ||
敏捷开发原则 | ||
敏捷开发过程 | ||
敏捷测试设计 | ||
敏捷采用的技术分析 | ||
敏捷的本质 | ||
敏捷派别 | ||
Scrum
| Scrum定义与框架 | |
Scrum团队构建 | ||
Scrum角色分类 | ||
Scrum流程及架构 | ||
Scrum运作模式 | ||
Scrum各类方法 | ||
Scrum实践 | ||
项目管理与开发模式 | ||
案例分析
| 他/她家案例 | |
实施场景分析 | ||
敏捷项目管理
| 背景与动机 | |
复杂性问题 | ||
敏捷宣言 | ||
敏捷开发原则详细分析 | ||
敏捷管理与传统管理的对比 | ||
敏捷与CMMI | ||
敏捷与XP模式 | ||
第二天全天 | 敏捷项目管理实践
| 4种主要实践 |
其他实践 | ||
有效性分析 | ||
人的角色与重要因素 | ||
流程与工作流 | ||
正确理解敏捷
| 实践解读与过程分解 | |
敏捷遇到的问题 | ||
需求条目化 | ||
如何适应变化 | ||
大项目中的敏捷伸缩 | ||
Kanban与精益 | ||
拥抱DevOps | ||
常见误解与总结 | ||
Kanban构建
| User Story Kanban | |
计划项目启动会议Kanban | ||
Daily Meeting Kanban | ||
展示会议Kanban | ||
回顾会议Kanban | ||
其他信息 | ||
举例 | ||
Scrum的适应性场景
| 敏捷开发中的问题总结 | |
人的因素对于敏捷的影响 | ||
瀑布、敏捷、DevOps之间的关系 | ||
敏捷为何要讲文化 | ||
作为敏捷教练，如何应对敏捷中的各种问题 | ||
大规模敏捷
| 大规模敏捷SAFe与LeSS | |
为何选择SAFe | ||
SAFe的框架介绍 | ||
如何进行PI Planning | ||
沙盘：大规模敏捷下的研讨 | ||
第三天全天敏捷沙盘 | 第一部分 预期分析 | 项目愿景澄清与干系人划分 |
1. 项目初步预期（Why）的澄清 | ||
2. 项目干系人澄清与划分（Who） | ||
3. 干系人对于产品期望的功能（How） | ||
可视化方式 | ||
第二部分 业务需求分析 | 业务需求分析 | |
1. 进行业务需求的分解 | ||
2. 在每一级的How下面，构建What | ||
3.关键路径分析 | ||
4. What方面进行排序 | ||
5. 划分业务迭代顺序 | ||
可视化方式 | ||
第三部分 冰山模型 | 冰山模型（复杂业务的需求建模） | |
1. 使用冰山模型替代繁琐的需求评审 | ||
2. 行业需求（监管需求）：需求分析与测试快速构建 | ||
3. 质量需求：测试构建 | ||
4. 技术需求：研发与运维构建 | ||
5. 全链路需求：需求分析与研发构建 | ||
6. 快速review内容，评估其时间输入是否满足预期 | ||
7. 风险与时间的快速确认 | ||
可视化方式 | ||
第四部分 日常任务看板 | 1. 构建价值流走向与反馈机制 | |
2. 设置当前的卡控点、约束与资源瓶颈点 | ||
3. 设置详细的流转规则规则 | ||
4. 试点一个需求，进行看板改进 | ||
5. 可视化方式 | ||
第五部分 模拟迭代工作 | 模拟迭代工作 | |
1、将划分的详细任务，转移到日常任务看板中 | ||
2. 设定角色日常的工作效率， | ||
3. PM/PO进行时间评估与风险预防 | ||
4. 开启2周的迭代，进行任务开发与价值流程 | ||
5. 记录当前的真实迭代速度，发现问题与风险 | ||
第六部分 复盘回顾 | 复盘回顾 | |
1. 需求的价值与目标客户 | ||
2. 业务需求的分析与迭代划分 | ||
3. 基于冰山模型的所有需求划分与任务细分 | ||
4. 日常看板的可视化控制 | ||
5. 迭代流转的监控、需求完成度与风险发现及预防 | ||
第四天下午 | 敏捷下的DevOps概念与组成 | DevOps理论、文化、收益、反模式 |
DevOps团队组织、架构演变模式 | ||
正确与错误的DevOps思维，及场景分析 | ||
DevOps中敏捷与精益的作用（快速视频呈现） | ||
DevOps对企业带来的好处 | ||
DevOps与不同的运营方法论的组合 | ||
敏捷与DevOps转型推动 | 敏捷与DevOps中，不可忽视文化 | |
团队化规模化思考，痛点分析 | ||
敏捷团队转型到DevOps体系 | ||
传统团队转型到DevOps体系 | ||
DevOps组织结构的自我演进 | ||
DevOps中流程的正确性保证 | ||
传统模式转变中的双态模式：稳态+敏态 | ||
第四天晚上 | 转型路线设计 | 根据业务特征与技术堆栈，进行目标选型 |
文化认知与反馈，团队选择与构建 | ||
组织过程的自我优化与演进，小范围投资 | ||
流程的正确性保证 | ||
双峰挑战下的质量与监管落地 | ||
安全的要求与融合 | ||
DevOps转型中的风险与痛点 | ||
文化 | 传统模式转型到DevOps，需要注意什么 | |
敏捷模式转型到DevOps，需要注意什么 | ||
高层、中层、基层，如何构建DevOps的文化 | ||
DevOps转型中，最大的挑战和困难 | ||
DevOps转型中，最重要的是什么 | ||
成功案例分析：某银行文化组织转型 | ||
失败案例分析：某互联网金融公司，转型失败分析 | ||
构建的整体技术平台方向 | 整体构建详细思路，项目管控、需求、工程三合一 | |
开发转型落地点 | ||
持续测试、分层测试、测试建模的切入 | ||
运维的挑战与转型实施 | ||
整体沟通链条的构建 | ||
KPI/OKR的持续考核与持续反馈 | ||
需要哪些团队的何种投入 | ||
DevOps沙盘演练 | 四轮沙盘，演练DevOps下各种配置管理相关要求 | |
沙盘各团队总结 | ||
第五天下午 | 应用、需求和开发设计 | 应用生命周期与服务生命周期 |
项目章程及可视化控制, 需求分析的快速变更自适应 | ||
基础设施支持，云和虚拟化 | ||
开发架构设计，SOA、微服务等模式的引入 | ||
组件和依赖 | ||
架构考虑运营时的要求 | ||
持续集成、快速研发与Pipeline | 持续集成、持续交付与持续部署 | |
持续集成平台 | ||
单分支开发策略 | ||
规律性增量发布策略 | ||
特性开关技术、服务降级与抽象分支 | ||
产出管理 | ||
Pipeline建设相关实践 | ||
测试分析 | 质量目标的变化 | |
当前挑战与趋势，大型系统持续交付难点 | ||
各阶段KPI定义 | ||
各阶段测试策略 | ||
第四天下午 | 持续测试 | DevOps中，测试策略改变与测试前置 |
持续测试在DevOps全局链中的作用，构建持续反馈 | ||
分级测试及对应测试域的介绍 | ||
复杂场景与简单场景的持续测试举例 | ||
自动化测试的作用，与不同场景下的应用 | ||
移动端测试自动化，及App专项测试 | ||
持续交付与持续部署 | Canary发布策略 | |
Blue-Green发布方法 | ||
灰度发布、抹黑启动 | ||
标准化一切 | ||
组件与依赖管理实践 | ||
建立数据沙盒 | ||
自动化数据库变更管理 | ||
同源版本管理实践 | ||
运维 | 服务级别协议 | |
应用管理与资源管理 | ||
数据管理 | ||
基础设施维护 | ||
持续交付的架构角度 | ||
配置管理与版本管理 | ||
业务连续性维护的相关运维措施，业务终止 | ||
伸缩与发布策略 | ||
运维PaaS平台化实现 | ||
第五天晚上 | 敏捷的质量需求设定 | 讨论：互联网与传统企业的敏捷需求，质量需求 |
讨论：复杂业务与简单业务，前期分析是的区别 | ||
一生二，二生三，三生万物：测试为万物 | ||
构建业务需求的Backlog | ||
构建基于开发测试规则出发的完整Backlog | ||
需求与后续测试点匹配的模型设定 | ||
敏捷测试 | 讨论：结对编程为何没有流行开？ | |
解释TDD测试驱动开发内涵 | ||
解释ATDD与BDD的测试开发 | ||
对比测试驱动开发与单元测试 | ||
讨论：如何减少TDD与unit test工作量？ | ||
探索性测试提升黑盒测试效率 | ||
持续集成构建的冒烟测试 | ||
讨论：哪里测试中最消耗时间环节 | ||
测试数据构造与复用 | ||
第六天下午 | 分级测试 | 分级测试的原因 |
分级测试的必备伴侣： CI持续集成 | ||
分级测试的必备规则与约定 | ||
开发与测试的密切配合 | ||
测试的重点投入 | ||
测试建模（复杂业务的测试快速构建与维护） | 测试建模原理 | |
有限状态机：降低用例维护性代价 | ||
去用例化的建模 | ||
与需求构建的一一对应 |
