敏捷项目管理思维导图模板_ProcessOn思维导图、流程图

第8章改进发布计划

8.1 发布（项目）计划

8.2 基于愿望做计划（平衡能力和需求）

8.3 多层计划

8.4 性能

8.4.1 性能用例

8.4.2 创建产品功能清单和路线图

8.4.3 最有计划结构

8.5 价值点分析

8.5.1 价值点确定：角色和时机

8.5.2 计算相对价值点

8.5.3 计算货币价值点

8.5.4 不面向客户地故事

8.5.5 价值和优先级

8.6 发布计划主题

8.6.1 计划主题和优先级

8.6.2 提高生产率

8.6.3 风险分析和降低

8.6.4 计划和扫描

8.6.5 时间框定规律

8.6.6 其它故事类型

8.6.7 在制品与制成品

8.7 新做法

8.7.1 看板

8.7.2 联合开发

8.7.3 超开发和发布

8.8 结束语

第9章探索阶段

9.1 敏捷项目领导

9.2 迭代计划和监督

9.2.1 迭代计划

9.2.2 工作量管理

9.2.3 监督迭代进程

9.3 技术做法

9.3.1 技术债务

9.3.2 简单设计

9.3.3 不断集成

9.3.4 无情测试

9.3.5 不失时机地重构

9.4 提倡和团队开发

9.4.1 是团队精力集中

9.4.2 将一群人塑造成一个团队

9.4.3 开发每个人地能力

9.4.4 移山引水

9.45 教导客户

9.4.6 是团队地节奏保持一致

9.5 参与式决策

9.5.1 决策形式

9.5.2 做决策

9.5.3 决策回顾

9.5.4 领导力和决策

9.5.5 基于组和基于延期的决策

9.6 合作与协调

9.6.1 每日站立会议

9.6.2 与产品团队的日常交互

9.6.3 协调利益相关方

9.7 结束语

第10章适应和结束阶段

10.1 适应

10.2 产品、项目和团队评审即适应措施

10.2.1 客户中心组

10.2.2 技术评审

10.2.3 团队绩效评估

10.2.4 项目进度报告

10.2.5 适应措施

10.3 结束阶段

10.4 结束语

第11章敏捷项目扩展

11.1 规模扩展的挑战

11.1.1 规模扩展要素

11.1.2 向上和向外

11.1.3 不确定性和复杂性

11.2 敏捷扩展模型

11.3 组件大型敏捷团队

11.3.1 组织设计

11.3.2 协作/协调设计

11.3.3 决策设计

11.3.4 知识共享和文档

11.3.5 团队中的自我组织团队

11.3.6 团队自律

11.3.7 流程纪律

11.4 向上扩展-敏捷做法

11.4.1 产品体系结构

11.4.2 路线图和功能清单

11.4.3 多级发布计划

11.4.4 维护可发布产品

11.4.5 团队间职责协议

11.4.6 工具

11.5 向外扩展-分布式项目

11.6 结束语

第12章治理敏捷项目

12.1 投资组合治理

12.1.1 投资和风险

12.1.2 主管级的信息要求

12.1.3 工程级信息的产生

12.1.4 企业级治理模型

12.1.5 使用敏捷治理模型

12.2 投资组合管理主题

12.2.1 设计敏捷投资组合

12.2.2 敏捷方法”拟合“

12.3 结束语

第13章超越范围、进度和成本：评估敏捷绩效

13.1 质量是什么

13.2 计划与评估

13.2.1 适应性绩效-结果和产出

13.2.2 评估问题

13.3 评估概念

13.3.1 超越预算

13.3.2 评估组织绩效

13.3.3 适应性绩效管理系统（APMS）设计指南

13.4 结果绩效的衡量指标

13.4.1 约束

13.4.2 社区责任

13.4.3 提高决策

13.4.4 以计划为指导

13.5 产出绩效的衡量指标

13.5.1 五项核心度量指标

13.5.2 结果和产出

13.6 缩短尾巴

13.7 结束语

第14章可靠的创新

14.1 新产品开发的新趋势

14.2 敏捷人员和流程交付敏捷产品

14.3 可靠的创新

14.4 不断增值的项目经理

14.5 结束语

第1章敏捷革命

客户价值

最终客户价值是在销售时交付，不是在计划时交付

包含的领域

商业软件产品

带嵌入式软件的工业产品（从电子设备到汽车）

内部开发 IT 项目

1.1 敏捷商业目标

1.1.1 持续创新

满足当前客户的需要

新产品

新服务

新意识

提供价值

1.1.2 产品适应性

满足未来客户的需要

产品背景

每周都变

销售市场

技术

特殊要求

数月甚至几年

提高适应能力

why？

变化加速

反应时间缩短

减少技术债务

why？

卓越技术判定

现在提供客户价值的能力

创造适应性产品的能力

提高适应能力

1.1.3 缩短交付进度

满足市场，提高投资回报率

突出重点

简化流程

培养技能

1.1.4 人员和流程适应性

对产品和企业变化做出迅速反应

一支适应能力强的队伍

乐于变革

项目管理

鼓励学习和适应

1.1.5 可靠的结果

支持业务增长和盈利能力

重复的流程是指按照同样的方式做同样的事情并产生同样的结果

可靠是指无论在生产过程中遇到什么障碍，都能达到目标，他意味着为达到一个目标而不断改变

1.2 敏捷的定义

敏捷是制造并响应变化从而在动荡的商业环境中创造利润的能力

敏捷是平衡灵活性和稳定性的能力

1.3 敏捷领导价值观

是态度不是流程

是氛围不是方法

在业绩优良的团队中，领导管理原则，而原则管理团队

4大敏捷宣言

个体和互动高于流程和工具；

工作的软件高于详细的文档

客户合作高于合同谈判；

响应变化高于遵循计划

12大敏捷原则

我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意

欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

业务人员和开发人员必须互相合作，项目中的每一天都不例外。

激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

可工作的软件是进度的首要度量标准。

敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

以简洁为本，它是极力减少不必要工作量的艺术。

最好的架构、需求和设计出自自组织团队。

团队定期地反思如何提高成效，并依此调整自身的举止表现。

1.4 敏捷绩效评估

3个目标

价值

提高可交付的产品

质量

提高可靠的、适应性强的可交付产品

约束

在可接受的约束内，实现价值和质量目标

1.5 敏捷项目管理架构

4个管理层面的敏捷组织架构

敏捷项目管理交付方法的5个阶段

构想

推测

探索

适应

结束

第2章价值胜过约束

2.1 持续创造客户价值

通过持续创造客户价值来提高投资回报率

成功的秘笈很简单，今天交付明天适应

2.1.1 创新

不拘泥于形式

新产品/新服务

不同于产品微小改进

想象不到的产品

探索型项目

帮助探索看似不可能的额事情

新商业模式

新流程

新业绩

2.1.2 执行

项目经理

精力

交付活动增加价值

计划和控制增加管理费用

执行模型

促进产品构想的构思

指导团队实现构想

而不是保证”计划得以施行“

2.1.3 精益思维

分析项目活动保证在交付活动上的时间最多

分析团队成员活动，确定从事交付活动还是合规活动

2.2 迭代、基于功能的交付

如果想创新，必须迭代

组成部分

迭代

建造版本

短期开发

评审

修改

扩展

基于功能

设计团队建造产品功能

模拟

模型

时间狂

1~4个星期

有结果

强制迭代结束

制造出部分实体

增量

2.3 卓越技术

why？

可交付客户价值

高品质确保未来交付价值

why？

问题积累

技术债务

低质量

项目领导

卓越技术的拥护者

why？

适应能力和低成本迭代的关键

必须知道

团队从卓越技术到完美之间的平衡转换点

产品经理在紧盯速度和功能时，忽略了适应能力

不必权威

足够的知识

具有技术背景

why？

讨论和决定开发的技术方法

不忘企业目标

确保团队重复消化吸收项目资料

避免不良技术决策导致流程问题

敏捷方法权宜之计？无纪律？技术低下？

流程、过程和文档

支持纪律

执行说过要做的事情

反对形式化

技术质量未忽略设计

反对大量直观设计

支持

迭代

新兴设计

频繁反馈

2.4 简化

如果想让船走得更快，那么割断锚绳比加大马力要来得容易。--- 卢克。霍

简化非常关键，它是最大程度地减少不必要工作地艺术。 --- 《敏捷宣言》

2.4.1 再生规则

一套简单正确地规则，应用到一个高度相互作用地群体中，然后产生诸如创新和创造力之类地复杂行为

一个系统在一起正常运转地最小单元。

非常高地价值

适用于几乎每个项目

4条规则确保共同奋斗目标

总是将 IT 活动与商业活动保持一致

云用良好地经济学判断

灵活变通

对组织地其他人产生共鸣

2.4.2 刚刚足够的方法论

迅速但不仓促

领导者

复杂问题简单化

制定刚刚足够地流程

找到快速和仓促之间地分界线

无疑有更高地成功几率

2.4.3 交付活动与合规活动

首要任务

交付价值

合规活动

减少错误、欺骗、劣迹和财务透支地风险

2.5 结束语

子主题

第3章团队胜过任务

3.1 领导团队

在战斗中，你管不了人，你只能管事情，并领导别人。---- 海军上将格雷斯。霍珀

领导者真正的权力不是自上而下委派的，而是自下而上赢得的。

指挥者知道目标，领导者把握方向；指挥者发号施令，领导者施加影响；控制者提出要求，协作者加以促进；控制者事事管理，协作者不断鼓励。支持领导-协作模式的经理非常清楚他们的主要角色是设定方向、提高指导以及促进人们与团队之间的联系。

在混沌时代，成功较少取决于生搬硬套而更多的是依赖于理智；较少取决于少数人的权力而更多的是依赖于多数人的判断；较少取决于强制而更多的是依赖于鼓励；较少取决于外部控制而更多的是依赖于内部纪律。--- 迪。霍克

3.2 建立自我组织（自律）团队

自我组织的团队的特征不是缺乏领导，而是一种领导风格。

创建自我组织的团队需要

找到合适的人员

清楚表述产品构想、界限和团队角色

鼓励协作

坚持负责

培养自律

引导而不是控制

3.2.1 找到合适的人员

人员比流程重要

产品是由能干的、技术熟练的人员制造的，不是由流程控制的

重点依次是人员、产品、流程

没有合适的人员，不能建造任何产品

精力不在产品上，无关系活动会渗入

没有最低限度流程框架，会效率低下，甚至混乱

3.2.2 坚持负责

激发成员使命感和责任感

每个团队成员都有责任提高团队协作

3.2.3 培养自律

自律是自由和授权的前提

自律的个人

对结果负责

用严谨的思维对抗现实

参与激烈的交流和争辩

愿意在自我组织框架内工作

尊重同事

自律

建立在能力、坚持和愿意程度结果的责任之上

才干不仅是技能和能力，是态度和经验

3.3 鼓励协作

3.3.1 参与式决策

决策是协作的心脏和灵魂

妥协造成两极分化，重新构思导致联合

3.3.2 共享空间

演示、原型、模拟和模型是相互交流的催化剂

开发、市场、客户、经理做重大意义的相互交流

要求

直观化

需求文档缺乏质量

讨论原型、致力于功能

公共性

原型得到所有利益相关方的理解

3.3.3 客户合作

客户参与敏捷项目的部分责任

创造并管理功能清单

确定发布和迭代计划的优先级

辨别并定义功能

定义接受标准

审核并接受完整的功能

和开发团队持续交流

为结果和调整约束负责

3.4 不再需要自我组织团队

问题

摆脱观点

敏捷项目无领导或者谁是领导却决于不同的情境

改变领导方式

授权型过时

授权型自我组织团队的支持者已经过时

适宜的领导保留适当的决策权与授权给团队结合的方式

第4章适应胜过遵循

传统项目管理者注重按计划行事，尽量做到和计划没有出入；而敏捷项目领导这关注如何成功的去适应不可避免出现的变化。

适应性原则

《敏捷宣言》和《相互依赖声明》

预测不确定性，并设法通过迭代、预防、适应来应对不确定性；

通过使用根据具体情况而定的策略、流程和实践来提高效率和可靠性

响应变化胜过遵循计划

即使在开发后期，也乐于接受变化的需求，敏捷流程重复利用变化以增加客户竞争优势

团队定期反省如何做到更有效，然后相应调整团队行为

概括

预测变化（不确定性），然后做相应调整，而不是遵循国企计划

根据需要调整流程和做法

评估流程得4个问题

在发布产品得同时，是否交付了价值？

是否实现了创造可靠的、具有适应性得产品质量目标？

项目进度是否满足可接受得要素范围？

团队是否在有效地适应管理、客户和技术等方面的变化？

适应可以看作是对变化做出的深思熟虑的回应

4.1 适应学

4.2 探索

4.3 响应变化

4.4 产品、流程和人员

4.5 障碍还是机会

4.6 可靠但不重复

4.7 反思和回顾

4.8 从原则到做法

4.9 结束语

第5章敏捷项目管理模式

5.1 敏捷企业架构

5.1.1 投资组合治理层

一套管理机制

主管们需要一个通用的而架构，评估所有的项目

解决

投资

项目的价值

风险

获取该价值的确定性和不确定性

5.1.2 项目管理层

项目管理

项目发布计划

构建产品

团队构想

开发项目范围

设定边界

制定全面的功能发布计划

与核心小组外围利益相关者合作

与供应商合作

全面的项目/发布活动

项目管理和迭代管理可以是同一个领导者也可以是不同领导者，取决于项目大小

4个团队的大项目可能

每个团队一个迭代经理

整个项目一个项目经理

5.1.3 迭代管理层

短期迭代

计划

执行

团队领导

5.1.4 技术实践层

变革技术实践

敏捷软件的核心

持续集成

自动化测试

5.2 敏捷交付架构

支持

企业目标

构想、探索、适应文化

自我组织、自律的团队

根据项目的不确定性程度，尽量提高可靠性和连贯性

保持灵活的易于适应

流程透明化

合并知识

囊括支持各阶段的做法

提供管理检查点

图片

子主题

5.2.1 阶段：构想

构想

产品构想

提供什么

产品及项目范围构想

项目目标

控制要素

项目社团

构想参与者都有谁

客户

产品经理

项目团队成员

利益相关方

团队如何工作

5.2.2 阶段：推测

推测

发布计划

确保交付构想的产品

推测阶段

收集初始的、广泛的产品要求

将工作量定义为一个产品功能清单

制定一个迭代、基于功能的交付计划

将风险策略纳入计划

估计项目成本，并生成其它必须要的行政管理和财务信息

5.2.3 阶段：探索

探索

短期内计划

经测试的功能

减少项目风险

减少不确定性

探索交付产品功能

3个关键的活动区域

通过管理工作量和使用适当的家属方法和风险降低策略，按计划交付产品功能

建立协作的、自我组织的项目社团，是每个人的责任但需要项目经理和迭代领导者推动

管理团队与客户、产品经理和其他利益相关方的相互交流

5.2.4 阶段：适应

适应

审核提交的结果

审核当前情况

审核团队绩效

必要时做出调整

控制和纠正

5.2.5 阶段：结束

结束

终止项目

交流主要的学习成功

融入下一次迭代

传递给下一个项目团队

庆祝

5.2.6 不是完整地生命周期

未包含

早期概念构想阶段

晚期配置阶段

5.2.7 选择和整合做法

没有最好的做法，只有更适合具体情况的做法

指导原则

简单的

再生的而非常规性的

与敏捷价值观和原则一致的

关注交付活动（增值）和非合规活动

最少数量的

刚好可以完成工作的

相互支持的

做法系统

5.2.8 需要具备地判断力

一切工作都应该是循序渐进的，即使是架构开发。序列开发中前期架构出错通常意味着长期适应性较差，因为没有人能够承受得起在项目晚期再改变架构

无论规模大小均适用

5.3 扩展地敏捷交付架构

扩展的 APM 交付架构图片

子主题

扩展的 APM 交付架构

构想阶段

项目章程

产品构想

项目范围和界限

准确性评估

骨架结构

团队构想

推测阶段

故事 ID

发布计划

探索阶段

迭代交付

第 1~N 次迭代

1-4 周一次

准备和计划

需求

开发

需求估计

迭代计划

开发

编程

需求测试 TOO

演变设计

重组

结对

需求对话

质量评估和接受测试

系统和集成测试

客户接受测试

用途测试

评审和适应

客户关注小组

技术评审

项目状态

迭代反思

更新发布计划

持续

架构设计演变

持续构建和集成

项目管理

日常站立会议

文档

变化协调

迁移和集成

故事部署

项目领导

产品开始阶段

最终评审和接受

最终质量评估和文档

增量交付和最终产品部署

结束阶段

项目反思

最终项目、产品文档

清理余下问题

第6章构想阶段

项目计划演变图

子主题

6.1 可发布地产品

敏捷项目成功定义

价值目标

创建可交付产品

产品构想框

项目数据表

项目目标声明

企业目标

性能

性能价值

质量目标

创建交付可靠的、适应性强的产品

项目数据表

质量目标

约束目标

在可接受的约束内，实现价值和质量目标

均衡矩阵

范围

进度

成本

每次迭代末回答的问题

什么是可发布的产品？

今天是什么阻止我们发布这个产品？

定义

可发布产品

6.2 构想做法

问题

客户的产品构想是什么？

该产品主要性能是什么？

项目的商业目标是什么？

项目的质量目标是什么？

项目的约束是什么（范围、进度、成本）

谁属项目社团的合适参与者？

团队将如何交付产品（方法）？

大型项目

第 0 次迭代

章程

需求收集

额外培训

资源采购

体系结构

产品构想达成一致

辩论

讨论

构想

构想阶段

随新信息不断演变

项目启动

可行性研究

营销研究

构想阶段后

定期审核

确保持续理解

流程

产品构想

产品体系结构和指导原则

产品体系结构

定义

描述项目内部沟通渠道

促进探索

指导正在进行的产品开发的设计

敏捷开发中，体系结构是引导而不是紧箍咒

指导原则

协助开发团队塑造产品，满足客户需求

敏捷 12 大原则

项目目标和约束

项目数据表

定义

用一页纸概况主要商业和质量目标、产品功能和项目管理信息。是一个简单却有重要影响力的文档。它简介的格式，对整个项目社区呼吁并不断提醒他们哪些是项目的战略方向。

举例图片

子主题

举例说明

顾客/客户

主要顾客/客户一览表

项目经理

项目经理名称

产品经理

产品经理名称/产品拥有者

高级主管

负责决策项目计划和约束的人

项目目标声明

明确而简短的声明

范围

进度

成本

举例图片

子主题

商业目标

做这个项目的总金额和商业原因

权衡矩阵

确立项目范围、进度和成本的相对优先次序的表格

当项目启动的时候，项目计划保持在价值、质量和约束三者之间的健康平衡非常重要。当这个平衡被打破的时候，权衡矩阵就开始发挥作用。--- 肯。克利尔

权衡矩阵图片

子主题

行

固定