Sprint计划会议：
1. 2. 3. 确定Sprint目标及演示日期 细化、分配Sprint开发任务，制定详细开发计划 输入产品Backlog，输出Sprint Backlog
关键点：
1.
2. 3.
Scrum Master确保产品负责人和团队充分参与讨论，
对任务和完成标准达成一致 团队从产品Backlog中挑选承诺完成的条目 Sprint Backlog由团队协作完成，包含内部任务（如
1. 2. 3. 4. 经过优先级排序的动态刷新的产品需求清单 按照对用户带来的价值排列优先级 持续管理并及时刷新,在每个Sprint结束的时候更新优 先级的排列 通常使用用户故事来表示backlog条目
Scrum框架的理解
角色 • 产品经理 • Scrum Master • 开发团队 仪式 • Sprint计划会议 • 每日站会 • Sprint演示会议 • Sprint回顾会议 产出物 • 产品Backlog • Sprint Backlog • 燃尽图
1.
2.
由Scrum Master组织，产品经理邀请相关的干系人
（外部或内部利益相关人）参加 通过演示Sprint可工作的软件功能，检查是否满足客 户要求
关键点：
1. 2. 3. 不需要PPT，团队成员全体参加，时长控制在2小时内 在真实环境中展示可运行的软件，判断是否达到 Sprint目标 产品经理根据评审情况及客户反馈意见，及时调整产 品Backlog

敏捷宣言的理解
敏捷宣言
理解：
1. 敏捷开发遵循软件客观规律，是一种更人性化的开发方式
2.
3. 4.

软件开发是一种团队活动，团队是价值的真正创造者，应加强团队协作、激发团队潜能，提升沟通效
率，降低交流成本 聚焦客户价值，交付刚刚好的系统，消除浪费 软件开发是复杂不可预测的经验控制过程，不断的进行迭代增量开发，最终交付符合客户价值的产品

Sprint Backlog：
1. 2. 3. 是团队在一轮Sprint中的任务清单，明确了Sprint的目 标 团队成员自己挑选任务，而不是指派任务，支撑需求 完成的所有工作都可以列为任务 任务分解粒度要小于两天，以小时为估计单位，每日 更新剩余工作量
Scrum框架的理解
持续集成环境搭建等）
Scrum框架的理解
角色 • 产品经理 • Scrum Master • 开发团队 仪式 • Sprint计划会议 • 每日站会 • Sprint演示会议 • Sprint回顾会议 产出物 • 产品Backlog • Sprint Backlog • 燃尽图

敏捷实践的理解
敏捷管理实践
• 迭代计划会议 • 每日站立会议 • 可视化管理 • 迭代回顾会议
敏捷开发实践
• 用户故事 • 结对编程 • 测试驱动开发 • 持续集成
Scrum偏重项目管理，XP偏重开发实践，通常两者 Scrum开发方法理解 Scrum与CMMI差异
每天，站立会议，不记录 成员间随时沟通 高 低

Scrum与CMMI差异—变更管理
Scrum
需求变更 人员变更 开放式的，随时接收变更，加入 产品backlog 在每个Sprint内不允许人员变更


Scrum开发流程的理解
Scrum开发流程：
1. 2. 3. 4. 整个Scrum开发周期包含若干个迭代周期(Sprint)，每个Sprint持续2-4周 使用产品Backlog管理产品需求，在每个Sprint中，总是从产品Backlog中挑选对客户最有价值的需
角色 • 产品经理 • Scrum Master • 开发团队 仪式 • Sprint计划会议 • 每日站会 • Sprint演示会议 • Sprint回顾会议 产出物 • 产品Backlog • Sprint Backlog • 燃尽图

燃尽图：
1. 2. 直观反映Sprint过程中剩余的工作量情况，X轴表示时 间，Y轴表示剩余工作 随着时间的消耗工作量逐渐减少，在开始的时候，由 于遗漏工作量或估算误差有可能出现上升趋势

敏捷开发概念的理解
敏捷开发：
1. 敏捷开发(Agile Development)是一种以人为核心，增量迭代、 及时交付的开发方法；
2. 是一种自下而上的轻量级开发方法，提升开发效率和产品质量；
3. 是一种应对需求快速变化的软件开发能力，重在实践。

Scrum框架的理解
角色 • 产品经理 • Scrum Master • 开发团队 仪式 • Sprint计划会议 • 每日站会 • Sprint演示会议 • Sprint回顾会议 产出物 • 产品Backlog • Sprint Backlog • 燃尽图

产品Backlog：
每日站会：
1.
2.
每天工作前，团队成员的例行沟通机制，由Scrum
Master组织，团队成员全体站立参加 聚焦三个主题： ① 昨天我做了什么？
② 今天我计划做什么？
③ 我需要什么帮助以更高效的工作？
关键点：
1. 2. 3. 按确定的时间地点开会，形成团队成员的习惯 会议限时15分钟，每个人都保持站立，依次发言，不 讨论与会议三个主题无关的事情 Scrum Master记录下所有的问题并跟踪解决
团队成员：
1. 2. 3. 4. 5. 共同参与计划制定和任务安排 团队协作贯穿工作始终 广泛的、面对面的交流是团队工作最高效的方式 关注团队目标，共担责任 能力要求更广，主动学习适应岗位要求
2.
3. 4.
营造团队自我管理的工作氛围
作为教练辅导团队进步 基于简单原则的管理，原则简单但必须被遵守

目录
敏捷开发思想理解 Scrum开发方法理解 Scrum与CMMI差异


敏捷诞生背景的理解
敏捷 软件 软件危 工程 机 软件 作坊
软件项目的最大挑战在于既要应付变动中的需求，
又要在紧张的工期内完成项目
2001年以来更能适应变化的敏捷开发方法被普 遍认可并迅速流行
5.
激励团队提高开发效率
开发团队：
1. 2. 3. 负责估计工作量并根据自身能力找出最佳方案去完成 任务且保证交付质量 向利益相关人演示可运行的软件 团队自我管理、持续改进
Scrum框架的理解
角色 • 产品经理 • Scrum Master • 开发团队 仪式 • Sprint计划会议 • 每日站会 • Sprint演示会议 • Sprint回顾会议 产出物 • 产品Backlog • Sprint Backlog • 燃尽图
自组织团队的理解
“最好的架构、需求和设计出自自组织团队。”《敏捷12条原则》
“自组织团队要自我决择如何最好地完成他们的工作，而不是由其他外
部团队来决定。”《Scrum指南》
权力矩阵
自组织不仅是一种团队形式， 更是一种管理手段。

敏捷团队的理解
管理者：
1. 通过目标来牵引团队自主工作
1.
2.
每个Sprint结束后进行的总结会，目的是分享好的经
验和发现改进点，促进团队不断进步 围绕三个主题 ① 本次Sprint哪些方面做得好
② 本次Sprint哪些方面还能做得更好
③ 下次Sprint在哪些方面进行改进
关键点：
1. 2. 3. 每个Sprint结束后都要组织，时长控制在30分钟内 全员参加，畅所欲言 将精力放在最关键的几个改进
面对面、会议，减少书面沟通 站立会议 全体实时传递信息
书面沟通、会议、电话、邮件、面对 面等 坐着开会 信息传递存在延迟现象 管理文档不可缺少，如项目计划、个 人周报、项目周报、会议纪要等
每周，项目例会，产出会议纪要 上下级沟通多，成员间沟通少 低 高，重要信息主要通过文档传递
沟通频次 沟通效率 沟通成本

产品经理：
1. 2. 3. 4. 代表利益相关人，对产品投资回报负责 负责定义产品需求并确定优先级 确定产品发布计划 验收迭代结果，根据需要调整功能和优先级
Scrum Master：
1.
2. 3. 4.
辅导团队正确应用敏捷实践
引导团队建立并遵守规则 保护团队不受打扰 推动解决团队遇到的障碍
敏捷核心思想的理解
敏捷核心思想：以人为本，适应变化
理解：
1. 传统开发模式中一切以文档为依据，而敏捷开发只写有必要的文 档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的 交流，所以它强调以人为核心，人是软件项目获得成功的最重要 因素。 2. 需求变化是不可避免的，传统开发模式采取“堵”的思想来控制 变更，变更对项目进度、质量造成不利影响，而敏捷面对变化采 取“疏”的思想坦然面对，通过多次短期迭代快速响应变更。 3. 敏捷核心思想通过敏捷4条宣言和12条原则来概括体现。
求，并通过分析估算形成Sprint Backlog
在Sprint过程中不允许发生变更，通过每日站会、每日更新Sprint Backlog跟踪Sprint进度 Sprint结束时，开发团队交付可工作的软件，并通过Sprint回顾会议进行总结

Scrum框架的理解
角色 • 产品经理 • Scrum Master • 开发团队 仪式 • Sprint计划会议 • 每日站会 • Sprint演示会议 • Sprint回顾会议 产出物 • 产品Backlog • Sprint Backlog • 燃尽图
CMMI
需求、设计、开发、测试、上线等 不定
大多是一堆文档 里程碑完成情况，后续工作计划、 存在的风险和问题等 不同阶段评审参加的人员也不同 没有单独的回顾
里程碑回顾 Sprint回顾会议

Scrum与CMMI差异—沟通管理
Scrum
沟通形式 非正式居多 正式居多