1. 敏捷项目管理

• 敏捷项目管理: 是一种能 快速适应环境变化 的管理方式，适用于 需求不清、产品模糊、频繁变更或风险较高 的项目。
• 敏捷项目管理 通过若干迭代周期，不断完善项目需求和范围，并交付最终产品。
• 敏捷方法 强调在最短时间内做最可能的事。
• 在整个项目的生命周期里，通过持续改善来增加项目功能，在每个迭代周期内，都制定详细的计划，但对整个项目则制定粗略计划。
• 在敏捷项目管理中，团队需要与客户密切合作。

1.1 敏捷教练

• 敏捷教练: 在敏捷管理中，敏捷教练的主要作用是对团队支持、留意团队状况、及时反
  馈意见、引导和教育团队

敏捷教练的工作包括:

• 保护团队不收干扰
• 关注结果
• 可视化 项目管理
• 高度协作、传承知识
• 开发与测试集中办公、测试提前介入

1.2 敏捷管理与传统管理

• 传统管理: 计划为纲、按部就班、严格执行、范围为先、确定边界
• 敏捷管理: 范围不断变化、快速响应价值、鼓励变化、持续改善、滚动式规划、近详远略

1.3 敏捷管理的适用范围

• 无法适用于简单的、混乱的问题时
• 需要反复循环、频繁调整时
• 需要持续不断地调整优先级时
• 需要定期更新、频繁交付时

1.4 敏捷宣言

• 个体和互动 > 流程和工具
  • 合作、沟通以及交互能力比单纯的软件编程能力和工具更为重要
  • 方法和工具是死的, 人是活的, 人沟通、协作不好, 在强大的工具和方法都是白扯
• 工作的软件 > 详尽的文档
  • 面面俱到的文档往往比过少的文档更糟,编制内部文档应尽量短小并且主题突出
• 客户合作 > 合同谈判
  • 客户不能一次性表述完整需求, 需要与客户保持密切的合作, 以便随时调整需求
• 响应变化 > 遵循计划
  • 计划必须有足够的灵活性和可塑性, 短期的迭代比中长期计划更有效

1.5 敏捷 12 原则

1. (尽早持续交付): 我们 最高的优先级 是, 通过 尽早和持续 交付 有价值 的软件来满足客户的需求
2. (欢迎变更): 即使在开发的后期, 也 欢迎需求变更, 利用变更为客户创造竞争优势
3. (较短周期): 要不断交付可用的软件, 周期从几周到几个月不等, 越短越好
4. (一起工作): 项目期间, 业务人员和开发人员必须每天 一起工作
5. (激励信任): 要善于 激励和信任 项目成员, 给于他们所需的环境和支持
6. (面对面): 围绕 面对面交流 来传递信息, 这是最有效的和高效的方法
7. (可用衡量): 可用的软件是 衡量进度 的首要指标
8. (可持续开发): 敏捷过程提倡 可持续开发, 发起人、开发人员和用户要能够长期维持稳定的开发步伐
9. (精益求精): 对技术的 精益求精 以及对 设计的不断完善 将提高敏捷性
10. (简洁): 简洁, 即尽最大可能减少不必要的工作
11. (自组织): 最好的架构、需求和设计出自于 自组织的团队
12. (反思调整): 团队要定期反思, 如何更有效地工作, 并不断调整和优化自己的工作方式

1.6 敏捷十大关键

• 主要是领导
• 自组织团队
• 充分授权
• 小而全的团队
• 客户的频繁参与
• 工期先导
• 范围渐进明细
• 滚动式规划
• 原型评审
• 以价值开发

1.7 敏捷的核心

持续提升、关注价值、不断改进

2. 敏捷实施

2.1 Scrum

• Scrum: 敏捷开发框架, 是一个增量的、迭代的开发过程
  • 在 Scrum 中将整个开发周期分为若干个 小迭代周期(Sprint), 长度建议为 2~4 周
  • 使用 待办事项列表(Backlog) 来管理产品或项目需求, 通常以 用户故事(UserStory) 来体现
  • 团队从 Backlog 中挑选需求, 进过 Sprint 计划会议分析、讨论、估算得到 Sprint 任务列表(Sprint Backlog)
  • 每次迭代结束时, Scrum 团队交付潜在可交付产品增量

2.2 Scrum 的支柱

• 透明: 拥有一致的理解
• 检视: 及时检查工作和完成进展, 以便发现不必要的差异
• 适应: 发现偏差后快速反应, 并予以调整

2.3 Scrum 方法论

• 一个核心: Scrum 把开发任务构造在许多周期中, 每个周期为一个 Sprint
  • Sprint 的迭代时间为 2~4 周, 并且相互衔接
  • 每个 Sprint 都有固定的周期, 称之为”时间盒”
• 三个角色: 产品负责人(PO)、敏捷教练(SM)、团队成员(Team)
• 三大工件: 产品待办列表(Product Backlog)、迭代列表(Sprint Backlog)、产品增量
• 四个会议: 迭代计划会、每日站会、迭代评审会、迭代回顾会
• 五个价值观: 勇气、开放、承诺、专注、尊重

2.4 冲刺待办事项/迭代待办列表(Sprint Backlog)

• Sprint Backlog 包含了团队在本期 Sprint 中需要执行的所有任务
• 团队需要对 Sprint Backlog 进一步补充, 对用户故事进行任务分解
• 许多任务在迭代计划会议上已经讨论、定义
• 只有团队可以修改 Sprint Backlog

2.5 发布燃尽图和迭代燃尽图

发布燃尽图和迭代燃尽图记录了在一段时间内产品待办列表和迭代列表的剩余估算工作量, 其提供了可视化的进度预测

在燃尽图中, 估算工作量以 Scrum 团队和组织决定的单位为标准, 时间以 Sprint 为单位

3. 敏捷角色

3.1 产品负责人(PO)

• 产品负责人(Product Owner): 代表利益相关方, 重点时产品业务方面, 从业务角度出发对需求权重排序, 合理的调整产品功能和迭代顺序

3.2 敏捷教练(Scrum Master)

• 敏捷教练(SM): 是团队导师和组织者, 负责提高团队效率并移除障碍, 帮助团队实现 PO 设定的目标
• SM 负责确保所有人都能正确的理解并实施 Scrum, 因此要确保 Scrum 团队遵循 Scrum 理论、实践和规则
• SM 在 Scrum 团队中是仆人式领导, 也帮助团队之外的人了解他们将如何与团队开展有益的交互, 并通过改变他们与团队的互动方式使团队创造的价值最大化
• SM 需要了解期望、保持沟通、给予承诺, 并且服务 PO、服务组织、服务团队、教导团队、保护团队、引导团队

3.3 SM 的职责

• 在项目生命周期早期定义基本规则
• 确保团队理解相关方的期望
• 与团队沟通项目愿景, 有利于确保团队认识到他们的目标域项目总目标紧密一致
• 以连贯的单元模式工作
• 对愿景给予承诺
• 为团队排除障碍

3.4 自组织团队

• 自组织团队: 需要尽一切努力去完成任务, 充分理解产品负责人的产品远景, 合作完成 Sprint 中的每个目标

3.5 SM 的基本规则

• 设定 Scrum 的开始 ~ 结束时间
• 保持对主题的专注、减少精力分散
• 会议期间杜绝中断
• 允许团队成员自由言论
• 在制定决策前广泛收集所有成员意见

敏捷教练并不是团队的”老板”, 因此他不负责为团队分配任务、不帮助团队做决定、不承担团队未完成工作的责任

4. 敏捷开发流程

• 1.PO 和开发团队对产品业务目标达成共识。
• 2.PO 建立和维护产品待办事项列表（Backlog），并进行优先级排序。
• 3.PO 在每轮迭代前，回顾待办事项列表（Backlog），并筛选出高优先级需求进入本轮迭代开发。
• 4.开发团队细化本轮迭代需求，形成迭代列表（Sprint Backlog），并依次完成任务。
• 5.开发团队通过每日站立会议、特性开发、持续集成，使开发进度真正透明。
• 6.PO 对每轮迭代交付的成果进行现场验收和反馈。
• 7.开始下一轮迭代（Sprint）。

4.1 迭代规划会议（Sprint Plan）

规划会议一般不超过 8 小时：

• 前 4 个小时：由产品负责人向团队展示最高优先级的产品，团队则向他询问关于产品待办事项列表（Backlog）的内容、目的、含义及意图。
• 后 4 个小时：由团队计划本次迭代（Sprint）的安排。

4.2 迭代复审会议（Sprint Review）

复审会议一般为 4 小时，由团队成员向产品负责人和其他相关方展示迭代（Sprint）周期内的产品开发情况。

4.3 迭代回顾会议（Sprint Retropective）

回顾会议一般为 3 小时，敏捷教练将鼓励团队在 Scrum 过程框架和时间范围内，对开发过程做出修改，使它在下一个迭代（Sprint）周期中更加有效和令人满意。

4.4 每日站会

由团队成员简述昨天的完成情况、今天的预计任务以及遇到的困难等

5. 看板与用户故事

5.1 看板

• 看板: 一种轻量级的管理流程方法, 可以实现: 流程可视化、限制再制品(WIP)、防止浪费、度量生产周期

5.2 用户故事

• 用户故事: 以用户的角度来描述功能的方式
  • 要读: 角色、活动、商业价值
  • 描述故事: 作为一个”角色”, 我想要”活动”, 以便于达到”商业价值”

5.3 3C 原则

• 卡片（Card）：在小卡片上进行简短的故事描述、工作量估算等。
• 交谈（Conversation）：用户故事背后的细节来源于和客户或产品负责人的交流与沟通。
• 确认（Confirmation）：通过验收测试确认用户故事被正确完成。

5.4 INVEST 原则

• 独立的（Independent）：避免故事之间相互依赖。
• 可商榷的（Negotiable）：用户故事卡是功能的简短描述。
• 有价值的（Valuable）：清晰的体现对用户或客户的价值。
• 可估量的（Estimable）：开发团队需要去估算一个用户故事以便确定优先级、工作量并安排计划。
• 比较小的（Small）：可以在一个迭代或 Sprint 中完成。
• 可测试的（Testable）：故事必须是可测试的。

5.5 用户故事地图

将用户故事以可视化的方式展现在团队面前，让团队可以仔细梳理、讨论并确认故事所包含的内容，最终得出需求进行开发。

用户故事地图了解整个产品的全貌，防止片面的理解；找到整个产品的主干（路径），可以产生更多的用户故事。

• 产品全景图：通过价值链可视化来建立大故事、子故事的对应关系。
• 开发-测量-认知：在设计原型中学习，在开发过程中学习。
• 进度情况：结合看板对进度一目了然。
• 用户视角：从整体视角、用户价值的角度来进行优先级排序和 MPV 发布规划。

6. 精益管理

精益生产方式的基本思想是及时生产（Just In Time，JIT），旨在需要的时候、按需要的量、生产需要的产品。

• 精：少而精，不投入多余的生产要素，只在适当时间生产必要的产品。
• 益：所有经营活动有益处、有效果，具有经济意义（产出）。

精益管理通过五大原则来消除七大浪费：

• 五大原则：价值、拉动、尽善尽美、流动、价值流；
• 七大浪费：加工的浪费、不良的浪费、过早/过量生产的浪费、库存的浪费、搬运的浪费、等待的浪费、动作的浪费。

1.4 不确定性、风险和生命周期选择

项目团队可以通过 不同的生命周期选择 来应对不同的风险和不确定性

7. Scrum 体系

7.1 三个角色

• 产品负责人: 主要负责确定产品的功能是否达到要求, 维护产品待办事项列表, 指定软件的交付的内容, 同时有权利接受或拒接开发团队的工作成果.
• 开发团队: 由 3-9 人组成, 负责完成产品的开发工作, 他们是自组织的, 跨职能的团队.
• 敏捷教练: 主要负责指导团队, 使团队更好地运用 Scrum 框架, 以及解决团队在实践中遇到的问题.

7.2 三个工件

• 产品待办事项列表: 是所有工作的有序列表, 以故事形式呈现给团队, 价值越大的故事越靠前.
• 迭代待办事项列表: 是团队在迭代中要完成的工作的有序列表, 由团队自己决定.
  • 是产品待办列表的子表, 只记录当前迭代的工作
  • 将用户故事拆分成任务, 团队成员主动领取任务
  • 团队成员可以添加、删除或更改迭代中的任务
• 产品增量表: 团队在迭代内完成交付成果, 集成到以往的迭代成果中, 形成增量式交付
  • 每次交付的用户故事必须符合验收的条件

7.3 四个事件

• 冲刺计划会议: 用来决定本次 Sprint 的交付成果以及为了达成目标应该如何工作
  • 标志着 Sprint 的开始, 确定哪些用户故事会被纳入本次迭代中
• 每日站会: 每日 15 分钟的站会, 用来讨论昨天的工作、今天的工作、遇到的问题
• 冲刺评审会议: 用来展示本次 Sprint 的交付成果, 以及接受用户的反馈
• 冲刺回顾会议: 用来总结本次 Sprint 的过程, 以及如何改进下次 Sprint 的工作

7.4 五个价值观

• 承诺: 团队成员要承诺完成自己的工作, 以及尽量完成团队的工作.
• 专注: 团队成员要专注于自己的工作, 以及尽量完成团队的工作.
• 开放: 团队成员要开放地接受他人的意见, 并且尊重他人的意见.
• 尊重: 团队成员要尊重他人的意见, 并且尊重他人的意见.
• 勇气: 团队成员要有勇气面对困难, 并且尽量解决困难.

8. 敏捷生命周期

8.1 不确定性、风险和生命周期选择

项目团队可以通过 不同的生命周期选择 来应对不同的风险和不确定性

8.2 生命周期选择

• 预测型: 适用于需求稳定的项目, 需求一般不会变化, 项目的目标和范围都是确定的
  预测型生命周期

  

• 迭代型: 适用于需求不稳定的项目, 需求可能会随着项目的推进而变化
  迭代型生命周期

  

• 增量型: 向客户提供已经完成的可交付成果, 让客户能做立即使用
  增量型生命周期

  

• 敏捷型: 既有迭代又有增量, 适用于需求不稳定的项目, 频繁交付
  敏捷型生命周期

  

8.3 燃起图与燃尽图

• 燃尽图: 用来展示剩余的工作量及时间
• 燃起图: 用来展示已经完成的工作量及时间

8.4 常用衡量指标

• 交付周期: 完成一个工作项目所需的总时间
• 周期时间: 处理一个工作项目所需的时间
• 响应时间: 一个工作项目等待工作开始的时间

8.5 瀑布型与敏捷型

• 瀑布型: 传统的软件开发方法, 项目按照一定的顺序进行, 一旦进入下一阶段, 就不再回头
  • 需求/范围不变, 成本和进度可变
• 敏捷型: 项目按照迭代的方式进行, 每个迭代都是一个小型的项目, 有自己的计划、需求、设计、开发、测试和交付
  • 成本和进度不变, 功能可以变更

8.6 传统项目管理与敏捷项目管理