PMP项目管理敏捷项目管理

---

1 敏捷项目管理的重要性

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

敏捷教练
在敏捷管理中，敏捷教练的主要作用是对团队支持、留意团队状况、及时反
馈意见、引导和教育团队。
敏捷教练的工作包括：
◆ 保护团队不受干扰
◆ 关注结果
◆ 可视化项目管理
◆ 高度协作、传承知识
◆ 开发与测试集中办公、测试提前介入
敏捷管理和传统管理的比较
◆ 传统管理：计划为纲、按部就班、严格执行；范围为先、确定边界。
◆ 敏捷管理：范围不断变化、快速响应价值；鼓励变化、持续改善；滚动
式规划、近详远略。
瀑布模式属于传统项目管理，迭代开发则属于敏捷项目管理。


敏捷型管理的适用范围
敏捷是一种方法、手段、实践、技术或框架，可以在如下场景中使用：
◆ 无法适用于简单的、混乱的问题时
◆ 需要反复循环、频繁调整时
◆ 需要持续不断的调整优先级时
◆ 需要定期更新、频繁交付时
敏捷宣言

1. 我们最重要的目标，是通过持续不断的及早交付有价值的软件，以使客
   户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏
   捷过程掌控变化。
3. 频繁交付可用结果，间隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅
   以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好、效率最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发，责任人、开发人员和用户要能够共同维持其
   步调稳定延续。
9. 坚持不懈的追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计来自于自组织类型的团队。
12. 团队定期反思如何能提高成效，并依此调整自身行为。
    ◆ 个体互动胜过流程和工具
    ◆ 工作软件胜过详尽的文档
    ◆ 客户合作胜过合同谈判
    ◆ 响应变化胜过遵循计划
    敏捷方法十大关键：
    ◆ 主要是领导
    ◆ 自组织团队
    ◆ 充分授权
    ◆ 小而全的团队
    ◆ 客户频繁参与
    ◆ 工期先导
    ◆ 范围渐进明细
    ◆ 滚动规划
    ◆ 原型评审
    ◆ 依价值开发
    敏捷的核心
    ◆ 持续提升
    ◆ 关注价值
    ◆ 不断改进

2 实施敏捷

2.1 Scrum

什么是 Scrum？
Scrum 是一个敏捷开发框架，是一个增量的、迭代的开发过程。
在 Scrum 中，将整个开发周期分为若干个小迭代周期（Sprint），建议长度为
2～4 周。
使用待办事项列表（Backlog）来管理产品或项目需求，在列表中的条目通常
以用户故事（UserStory）来体现。
团队从 Backlog 中挑选需求，经过 Sprint 计划会议分析、讨论、估算得到 Sprint
的任务列表（Sprint Backlog）。
每次迭代结束时，Scrum 团队交付潜在可交付的产品增量。
Scrum 的支柱
◆ 透明：拥有一致的理解。
◆ 检视：及时检查工作和完成进展，以便发现不必要的差异。
◆ 适应：发现偏差后快速反应，并予以调整。
Scrum 方法论
◆ 一个核心：Scrum 把开发任务构造在许多周期中，每个周期为一个 Sprint；
Sprint 的迭代时间为 1～4 周，并且相互衔接；每个 Sprint 都有固定的周
期，称之为“时间盒”。
◆ 二种动物：“鸡”代表用户和利益相关者，“猪”代表全身投入项目和 Scrum
过程的人。
◆ 三个角色：产品负责人（PO）、敏捷教练（Scrum Master）、团队成员（Team）。
◆ 三大工件：产品待办列表（Product Backlog）、迭代列表（Sprint Backlog）、
产品增量。
◆ 四个会议：迭代计划会、迭代复审、迭代回顾、每日站会。
◆ 五个价值观：勇气、专注、承诺、开放、尊重。
产品待办列表（Product Backlog）
◆ 列出了团队正在开发或计划开发的产品需求；
◆ 通常以用户故事的方式展现；
◆ 产品负责人负责列表内容、可用性和优先级；
◆ 不断更新变化，根据产品和开发环境的变化而演进；
◆ 按照优先级排序。
迭代列表/冲刺待办事项列表（Sprint Backlog）
◆ Sprint Backlog 包含了团队在本期 Sprint 中需要执行的所有任务。
◆ 团队需对 Sprint Backlog 进一步补充，对用户故事进行任务分解。
◆ 许多任务在迭代计划会议上已经讨论、定义。
◆ 只有团队可以修改 Sprint Backlog。
发布燃尽图和迭代燃尽图
发布燃尽图和迭代燃尽图记录了在一段时间内产品待办列表和迭代列表的
剩余估算工作量，其提供了可视化的进度预测。
在燃尽图中，估算工作量以 Scrum 团队和组织决定的单位为标准，时间以
Sprint 为单位。

2.2 角色

产品负责人
产品负责人（Product Owner）代表利益相关方，重点是产品业务方面，从
业务角度出发对需求权重排序，合理的调整产品功能和迭代顺序。
敏捷教练
敏捷教练（Scrum Master）是团队导师和组织者，负责提高团队效率并移除
障碍。敏捷教练负责服务团队并为团队排除障碍，帮助团队实现 PO 所设定的目
标。
◆ SM 负责确保所有人都能正确的理解并实施 Scrum，因此要确保 Scrum 团
队遵循 Scrum 理论、实践和规则。
◆ SM 在 Scrum 团队中是仆人式领导，也帮助团队之外的人了解他们将如何
与团队开展有益的交互，并通过改变他们与团队的互动方式使团队创造
的价值最大化。
敏捷教练（SM）需要了解期望、保持沟通、给予承诺，并且服务
PO、服务组织、服务团队、教导团队、保护团队、引导团队。
SM 的职责
◆ 在项目生命周期早期定义基本规则
◆ 确保团队理解相关方的期望
◆ 与团队沟通项目愿景，有利于确保团队认识到他们的目标与项目总目标
紧密一致
◆ 以连贯的单元模式工作
◆ 对愿景给予承诺
◆ 为团队排除障碍
SM 的基本规则
◆ 设定 Scrum 的开始～结束时间
◆ 保持对主题的专注、减少精力分散
◆ 会议期间杜绝中断
◆ 允许团队成员自由言论
◆ 在制定决策前广泛收集所有成员的意见
敏捷教练并不是团队的“老板”，因此他不负责为团队分配任务、
不帮团队做决定、不承担团队未完成工作的责任。
自组织团队
自组织团队（Team）需要尽一切努力去完成任务，充分理解产品负责人的
产品远景，合作完成 Sprint 中的每一个目标。

2.3 敏捷开发流程

第1步 PO 和开发团队对产品业务目标达成共识。
第2步 PO 建立和维护产品待办事项列表（Backlog），并进行优先级排序。
第3步 PO 在每轮迭代前，回顾待办事项列表（Backlog），并筛选出高优先
级需求进入本轮迭代开发。
第4步 开发团队细化本轮迭代需求，形成迭代列表（Sprint Backlog），并依
次完成任务。
第5步 开发团队通过每日站立会议、特性开发、持续集成，使开发进度真
正透明。
第6步 PO 对每轮迭代交付的成果进行现场验收和反馈。
第7步 开始下一轮迭代（Sprint）。
迭代规划会议（Sprint Plan）
规划会议一般不超过 8 小时：
◆ 前 4 个小时：由产品负责人向团队展示最高优先级的产品，团队则向他
询问关于产品待办事项列表（Backlog）的内容、目的、含义及意图。
◆ 后 4 个小时：由团队计划本次迭代（Sprint）的安排。
迭代复审会议（Sprint Review）
复审会议一般为 4 小时，由团队成员向产品负责人和其他相关方展示迭代
（Sprint）周期内的产品开发情况。
迭代回顾会议（Sprint Retropective）
回顾会议一般为 3 小时，敏捷教练将鼓励团队在 Scrum 过程框架和时间范围
内，对开发过程做出修改，使它在下一个迭代（Sprint）周期中更加有效和令人
满意。
每日站会
由团队成员简述昨天的完成情况、今天的预计任务以及遇到的困难等。

2.4 看板与用户故事

看板
看板是一种轻量级的管理流程方法，它可以实现：
◆ 流程可视化
◆ 限制再制品（WIP）、防止浪费
◆ 量度生产周期
用户故事
以用户的角度来描述功能的方式，主要包括以下内容：
◆ 要素：角色、活动、商业价值。
◆ 描述故事：作为一个“角色”，我想要“活动”，以便于达到“商业价值”。
3C 原则
◆ 卡片（Card）：在小卡片上进行简短的故事描述、工作量估算等。
◆ 交谈（Conversation）：用户故事背后的细节来源于和客户或产品负责人
的交流与沟通。
◆ 确认（Confirmation）：通过验收测试确认用户故事被正确完成。
INVEST 原则
◆ 独立的（Independent）：避免故事之间相互依赖。
◆ 可商榷的（Negotiable）：用户故事卡是功能的简短描述。
◆ 有价值的（Valuable）：清晰的体现对用户或客户的价值。
◆ 可估量的（Estimable）：开发团队需要去估算一个用户故事以便确定优先
级、工作量并安排计划。
◆ 比较小的（Small）：可以在一个迭代或 Sprint 中完成。
◆ 可测试的（Testable）：故事必须是可测试的。
用户故事地图
将用户故事以可视化的方式展现在团队面前，让团队可以仔细梳理、讨论并
确认故事所包含的内容，最终得出需求进行开发。
用户故事地图了解整个产品的全貌，防止片面的理解；找到整个产品的主干
（路径），可以产生更多的用户故事。
◆ 产品全景图：通过价值链可视化来建立大故事、子故事的对应关系。
◆ 开发-测量-认知：在设计原型中学习，在开发过程中学习。
◆ 进度情况：结合看板对进度一目了然。
◆ 用户视角：从整体视角、用户价值的角度来进行优先级排序和 MPV 发布
规划。

3 精益管理

精益生产方式的基本思想是及时生产（Just In Time，JIT），旨在需要的时候、
按需要的量、生产需要的产品。
◆ 精：少而精，不投入多余的生产要素，只在适当时间生产必要的产品。
◆ 益：所有经营活动有益处、有效果，具有经济意义（产出）。
精益管理通过五大原则来消除七大浪费：
◆ 五大原则：价值、拉动、尽善尽美、流动、价值流；
◆ 七大浪费：加工的浪费、不良的浪费、过早/过量生产的浪费、库存的浪
费、搬运的浪费、等待的浪费、动作的浪费。

3.1 精益管理与传统管理的区别