概览

1 敏捷革命

团队的成功是从一个演变并适应的过程，而不是先计划再优化的过程。

预测为基础的流程（定义、设计，然后建造），适应为基础的流程（构想、探索，然后适应）

1.1 敏捷商业目标

持续创新- 满足当前客户的需要

产品适应性- 满足未来客户的需要

缩短交付进度- 满足时长，提高投资回报率（return on investment, ROI）

人员和流程适应性- 对产品和企业变化做出迅速反应（人员乐于变革）

可靠的结果- 支持业务增长和盈利能力（规定时间、成本，产品预期的结果；重复或不重复的流程都能产生可靠的结果）

1.2 敏捷的定义

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

敏捷是平衡灵活性和稳定性的能力（组织需要明确哪些因素需要稳定，哪些因素鼓励探索）

1.3 敏捷领导价值观

敏捷强调的是态度而不是流程，它是氛围而不是方法

有远见的公司将业务实践和商业策略（这些将不断的改变，以适应变化的世界）与永恒的核心价值和持久的目的区别开来

领导制定原则，原则管理团队

原则（或规则）影响着工具和实践的实施方式，实践则是将原则付诸行动

敏捷项目管理者应具有的核心价值观：

交付价值胜过满足约束（价值胜过约束）

领导团队胜过管理任务（团队胜过任务，避免陷入微观管理）

适应变化胜过遵循计划（适应胜过遵循）

1.4 敏捷绩效评估

敏捷三角形的演变

3个评估敏捷项目的指标：

价值目标- 提供可交付的产品

质量目标- 提供可靠的、适应性强的可交付产品

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

1.5 敏捷项目管理架构

4个管理层面的组织架构（见第五章）

交付方法包含5个阶段：构想、推测、探索、适应和结束

1.6 敏捷项目成功率

评价维度：成本、进度、缺陷产品累计、人员数量（生产力、软件缺陷、交付期、成本）

一个规律：人员翻一番，产品缺陷率翻两番；敏捷团队要通过自动化测试等手段降低产品缺陷率

1.7 结束语

做法、价值观、原则和概念架构，结合形成了敏捷项目管理

敏捷项目管理定义了如下策略能力：提供可交付的产品、创造和适应变化、在灵活性和结果之间保持平衡、挖掘开发团队的创造力和创新能力以及引导组织度过动荡和不确定的时期

以敏捷价值观和原则为驱动

2 价值胜过约束

2.1 持续创造客户价值

产品交付后，价值取决于产品是否能迅速、高效的适应新出现的要求

符合当前客户需求，但不容易适应未来需要的产品，注定生命周期很短暂

提供价值涉及3个重要话题：

重点放在创新和适应性而不是效率和优化

专注于执行

精益思维

2.1.1 创新

创新不拘泥于任何形式，可以是新的产品、新的商业模式、新的流程、新的业绩

创造新产品将重点放在创新和适应性，创造新服务通常注重效率和优化，二者互相促进

敏捷项目管理的主要目的是创造新产品和新服务

2.1.2 执行

传统项目管理方法流程由计划、控制、执行组成；如计划合理，执行只是照搬机械工作，不需要太多决策和创造力，只是执行计划，控制放在修正错误上

敏捷项目管理侧重执行，项目经理首要任务促进产品构想，指导团队实现构思，而不是制定计划、控制进度

一旦项目团队重点放在执行上，下一步就是集中关注增值活动上，而非只确保合规活动。

2.1.3 精益思维

精益生产基本原则：系统的消除浪费，减少不向客户提供价值的活动

简化项目（做较少的事、做正确的事、消除瓶颈）是区分交付活动和合规活动

项目经理需要分析项目活动，以保证用在交付活动上的时间更多   

2.2 迭代、基于功能的交付

早期捕获价值，提高项目的投资回报率

瀑布模型、螺旋模型、演化模型、快速应用开发（Rapid Application Development，RAD）

敏捷迭代4个关键词：迭代、基于功能、时间框、增量

2.3 卓越技术

高品质确保在未来交付价值

2.4 简化

如果想快速又敏捷，要保持事情简单

速度不是简化的结果，但简化能提高速度

2.4.1 再生规则

规范性方法试图描述团队应该做的每一个活动，容易让人们迷失在众多活动中，有很多可选对象，但没有原则指导如何去除无关的做法

再生做法是一个系统在一起正常运转的最小单位，不规定团队需要做的每件事，而确定哪些具有非常高的价值、几乎适用于每个项目的做法。团队会“再生”其它必要的辅助做法，剪裁和适应

2.4.2 刚刚足够的方法论

将复杂问题简单化、制定刚刚足够的流程，找到快速和仓促之间的分界线，平衡是敏捷的关键之一

“迅速，但不要仓促”、“快速适应，当不要失去控制”

2.4.3 交付活动与合规活动

即使要自己承担合规任务，项目经理也要尽可能的将项目团队从繁多的合规工作中解脱出来

过于关注交付合规，容易将交付产品降到次要位置

2.5 结束语

产品价值评估、追求卓越技术、改变绩效评估方法、提供帮助团队交付价值而不是要素

3 团队胜过任务

敏捷项目中，团队成员关注任务，项目领导关注团队

3.1 领导团队

建立适应能力强的、自我组织的项目团队，领导者应该引导而不是控制

领导者兼顾管理和领导，避免管理太多、领导太少

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

领导者的标志是对不确定性保持自信，能够承认并处理他们

敏捷时社会技术运动，有两个推动力：愿望- 创造一种特定的工作环境；信念- 适应性强的环境是向客户提供创新产品目标的关键

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

自我组织不是无领导的团队，需要正确的方向引导

创建自我组织的团队需要：

找到合适的人员

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

鼓励协作

坚持负责（通过激发使命感和责任感来提高团队绩效）

培养自律（对结果负责、严谨思维对抗现实、参与激烈的交流和政变、愿意在自组织框架内工作、尊重同事）

引导而不是控制

3.3 鼓励协作

协作团队中，领导者一个关键角色就是促进、教导、吸引和影响团队成员，让他们建立健康的关系

“合适的人员是否在适当的时间就适当的事情与其它人协作”

“是否可以在适当的时机得到适当的信息”

如果协作太少、信息交流太少，团队就会分歧严重，整合会变成噩梦；如果协作和交流太多，团队就会陷入会议和信息超载

3.3.1 参与式决策

高效率的领导“吸收”模糊性、负责做决定并让团队继续其工作，知道何时和如何影响模糊是高效率领导者的一个标志

妥协造成两极分化，重新构思导致联合（双赢思维）

双赢不意味着意见一致的决策，参与也不意味着意见一致

自组织团队的经理，偶尔需要单方面决定，但主要风格是包容，鼓励团队成员广泛的参与决策以便做出最好的决策

自组织团队的自由决定权力与项目经理的权力平衡

3.3.2 共享空间

共享空间有两个要求：直观化和公共性

公共性意味着原型需要得到开发工作的所有利益相关方的理解

3.3.3 客户合作

敏捷项目管理依赖于有效的客户合作，合作越多，越把自己当作团队成员，效果会越好

通常客户和开发团队的合作是困难的，是有效实施敏捷的一个障碍

客户团队的职责见第六章

3.4 不再需要自我组织团队

自组织是敏捷管理的核心，然而在部分敏捷社区，容易混淆“无政府组织”

自组织实际是授权和服务型领导方式

敏捷领导在自上而下的决策中角色“轻”，但在阐述目标、促进交流、提高团队动力、支持协作、鼓励试验和创新活动中角色“重”

3.5 结束语

敏捷领导管理团队，敏捷团队管理自己的任务

敏捷领导阐明团队目的和目标、产品构想、关键性能和约束，然后激励团队成员交付； 团队成员自己弄清如何完成任务细节

敏捷项目管理方法赋予团队灵活性和适应性，而不是盲目遵循既定任务

激励团队自组织，从而找到最好的方法去实现项目目标

4 适应胜过遵循

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

计划应该灵活，是依据而不是约束

适应性原则：

预测变化，然后做出响应调整，而不是遵循过期计划

根据需要调整流程和做法，适应是对变化做出的深思熟虑的回应

4.1 适应学

适应反应的是有机的、进化的“构想-探索-适应”周期

优化流程则是“计划-设计-建造”

复杂适应系统（Complex Adaptive Systems， CAS）理论重塑了科学和管理思想

4.2 探索

适应的速率要超过市场变化的速率

拥有响应变化的能力固然好，但如果能给竞争对手创造变化则更佳；响应变化是防守，创造变化是展开竞争攻势

4.3 响应变化

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

构建- 探索与计划-执行

适应与预见

4.4 产品、流程和人员

需要有同心协力的敏捷团队，对变化有正确的态度；需要有能让团队随时应对变化的流程和做法；还需要有高质量的能自动测试编码

4.5 障碍还是机会

大多数情况，人们感觉适应变化有障碍（成本太贵）是因为做事效率低下，没能抓住机会提高组织适应能力

敏捷开发需要找到通过短期迭代快速、低成本的做重复事情的方法，促进创新，降低变化成本，鼓励团队试验

4.6 可靠，但不重复

重复流程最多只能交付事先规定的东西，而可靠、突发流程可交付比开始时每个人的摄像都更好的结果，要足够机敏且具备预见能力，突发流程就可以产生最初希望的东西

敏捷项目管理是可靠的，但不是一贯正确的，不能消除不确定性的反复无常和在探索中遇到的出乎意料的事情

高级主管不应期望每次都按照产品构想、在规定时间和成本限制内交付，那是组装线，不是产品开发

4.7 反思和回顾

回顾涉及4个领域：

产品- 从客户的角度和技术质量的角度

流程- 团队正在使用的优秀流程和做法

团队- 作为高绩效团队，这个小组工作情况如何

项目- 项目按计划进行的如何

回顾、反馈，然后适应，从而提高绩效

4.8 从原则到做法

原则和做法是向导，确定和加强人们的行为

原则指导敏捷团队，实际工作需要具体做法

4.9 结束语

开发优质的产品需要探索而不是遵循计划

探索和适应是创新的两个行为特质

5 敏捷项目管理模式

5.1 敏捷企业架构

投资组合治理层：提供常见的检查点

项目管理层：对各种项目管理提供指导，洞察运行项目、制定发布计划和日常

迭代管理层、技术实践层：把核心技术做法融合到项目或者迭代管理方法中

5.1.1 投资组合治理层

关注项目价值（及投资回报率）和获取价值的确定性和不确定性；项目进程、投资和风险

5.1.2 项目管理层

管理完整的发布计划，涉及产品和团队构想、开发项目范围、设定边界和制定全面的功能发布计划

与核心小组外围的利益相关者和供应商合作

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

5.1.3 迭代管理层

关注每个短期迭代的计划、执行和团队领导

和项目管理的区分在于：发布计划还是迭代计划，项目外部还是内部的管理活动

5.1.4 技术实践层

技术执行面

5.2 敏捷交付架构

必须是有组织的、灵活的和容易适应的，除了需要支持企业目标，还需要：

支持构想、探索、适应文化

支持自我组织、自律的团队

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

保持灵活和易于适应

支持流程的透明化

合并知识

囊括支持各阶段的做法

提供管理检查点

敏捷项目管理交付架构

构想：确定产品构想、项目目标和控制要素、项目社团以及团队如何共同工作

推测：制定基于性能和\或功能的发布计划，确保交付构想的产品

探索：再短期内计划和提供它经测试的功能，不断致力于减少项目风险和不确定性

适应：审核提交的结果、当前情况以及团队的绩效，必要时做出调整

结束：终止项目、交流主要的学习成果并庆祝

这些是活动不是阶段，不只是线性进行

5.3 扩展的敏捷交付架构

5.4 结束语

敏捷架构应该在结构和灵活性之间保持平衡

随着组织中敏捷项目的数据和规模不断增大，组织需要一个通用的架构、一些通用的指导原则、少许标准做法和一套通用的价值观，同时团队具备适应通用框架和做法的自由权

平衡结构和灵活性的能力，是“敏捷艺术”。有效的领导力和敏捷经验有助于发现每个组织的最佳平衡点

6 构想阶段

6.1 可发布的产品

价值目标：创建可交付的产品

质量目标：创建交付可靠的、适应性强的产品

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

6.2 构想做法

1 产品构想：

产品构想框和电梯测试说明书

产品体系结构和指导原则

2 项目目标和约束：

项目数据表

3 项目社团

找到合适的人选

确定参与者

客户团队- 开发团队界面

4 方法

流程和做法的截取

6.3 产品构想

6.3.1 产品体系结构

目标是促进探索和指导正在进行的产品开发设计

体系结构是引导，而不是紧箍咒

6.3.2 指导原则

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

6.4 项目目标和约束

6.4.1 项目数据表

一页纸概括主要商业和质量目标、产品功能和项目管理信息

6.4.2 权衡矩阵

价值、质量、约束，三者之间的健康平衡

6.4.3 探索系数

表示项目的不确定性和风险的指标

阐明项目的探索系数有助于管理客户和主管的期望值

一般包括以下维度，可综合评分：

产品技术- 极其尖端的、尖端的、常见的、熟知的

需求易变性- 无规律、波动、常规、稳定

6.5 项目社团

目标：找到合适的人，“用更有效、更少的人员”

合适的技术能力、适当的自律行为，能力和自律

6.5.1 确定参与者

包括3类：客户、开发团队成员、利益相关方（含内外部）

6.5.2 产品团队- 开发团队交互

6.5.3 交付方法

以组织的标准架构为基础，项目交付团队裁剪流程和做法定义交付方法

6.5.4 自我组织策略

自我组织策略问题：项目沟通计划

我们如何与客户协作？

来自不同功能团队的项目成员如何相互协作？

跨组织团队如何协作？

授权对团队来说意味着什么？

谁需要在何时与谁交谈？

相互交谈的这些人如何决策？

谁负责什么？

他们打算用哪些做法来推动上面提出的问题？

6.5.5 流程架构裁剪

平衡结构和灵活性，共同架构尽可能精简，保持团队级灵活性

6.5.6 做法的选择和剪裁

基本4问：

哪些做法是必须的？

还需要哪些辅助性的做法？

需要对选择的做法做哪些修改？

做法的编档、批准和更改需要什么手续和形式？

6.6 结束语

构想的四要素：

产品构想是什么？
项目目标及其约束是什么？

谁应该包括在项目社团内？

团队如何交付产品？

构想阶段后，构想并没有停止，每次迭代的开头，团队一起思考下一次迭代时，团队成员需要重新审视该构想，重新审视的目的时为了修改这个构想或者在紧张的日常工作之余，提醒团队他们努力的目的地在哪里

7 推测阶段

计划是重要的活动，但随着不确定性的增加，用推测这个术语更为恰当

推测阶段关注产品和项目- 创造和理解产品结构、性能和故事功能清单以及发布计划

7.1 推测产品和项目

推测阶段的产品是发布计划，该计划基于要交付的功能而并非活动

产品经理控制哪些功能包含在产品中，开发工程师控制功能的设计和实施方式

敏捷项目推测有助于项目团队：

确定产品及其功能在当前版本中如何演变

随着项目的开展，平衡预期和适应

在项目早期将重点放在价值最高的功能上

考虑项目、企业目标和客户期望值

为管理层提供必要的预算和进度信息

为权衡决策建立优先级

协调团队之间的相关活动和功能

考虑其它选择和应变措施

为分析项目期间出现的事件提供基准

敏捷项目领导者需要通过行动、绩效评估和构想，不断鼓励团队随着项目的进行，不断的学习并适应

7.2 产品功能清单

产品功能清单是对构想阶段制定的清单的扩充和提炼，理出那些经过可行性分析或市场研究、初步需求收集功能和产品构想等工作收集起来的产品功能

客户、开发人员、产品经理和客服服务人员对清单提出改进建议，并添加到产品清单上，产品经理负责维护清单

清单上的功能具有易变性

7.2.1 功能、故事的概念

故事是一个小的可交付的有用功能，但构不成一个完整的功能

7.2.2 故事的重点

传统的项目计划关注技术任务领域，故事却以客户为导向

在制定计划或交付目标时，团队需要把技术功能包括进去，但在客户沟通之前构建技术功能是有风险的

7.2.3 故事卡片

目的提供简单的媒介，用于收集有关故事的基本信息、记录高层次的需求、开发工作估计和定义验收测试

故事卡片用于列出功能，而不是详细定义功能

7.2.4 创建功能清单

功能清单时产品团队确定产品性能、功能和故事的一个列表

通常情况下功能清单信息有限，包括ID、名称、简要描述、优先级别、探索系数和估算等项目

7.3 发布计划

团队在项目数据表中所描述的项目目标和约束内实现产品构想的路线图

7.3.1 范围演变

产品范围的推动因素包括：客户价值、技术可行性、成本和关键的业务进度

7.3.2 第0次迭代

0意味着在时间限期内没有任何有用的功能可以向客户交付

允许开发人员一开始就构建或编码，有助于团队在预期和适应之间保持平衡

7.3.3 第1-N次迭代

开发团队和产品团队功能制定发布计划，涉及以下活动：

确定已知的风险对迭代计划的影响

确定进度目标

为每次迭代编制主题

将故事卡片分派给每次迭代，必要时，平衡价值、风险、资源和依赖关系

结合故事卡片布局、完整的发布计划或者项目停车场图总结该计划

运用权衡矩阵，必要时，调整完成的计划

部分发布计划 发布计划停车场图

7.3.4 第一个可行的部署

早期部署和测试策略需要同时考虑

7.3.5 估计

如何估计：

估计未知因素

按功能而非活动进行估计

循序渐进的估计

估计会浪费时间

估计与设定界限

使用故事点和员工工作时间估计

7.3.6 其它卡片类型

性能卡片、任务卡片、技术卡片、缓冲区卡片

7.4 结束语

功能开发前，需要完成3个主要活动：

清楚表达产品构想

定义项目的目标和约束

制定迭代的、基于功能的交付计划（推测阶段的主要成果）

8 改进发布计划

8.1 发布（项目）计划

所有参与方必须理解敏捷发布计划的目标：

有助于更好的理解项目的可行性和可实施性

概述风险评估和缓解风险

增强团队排列性能和功能优先级的能力

让团队对项目有一个整体的认知

回答管理层有关价值、进度和成本的问题

创建一个让管理层和团队成员都感到舒适的项目平台

创建部分部署计划

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

很多团队计划做的差，就是平衡组织能力和工作需求的能力不佳

计划常常不是基于能力的，而是基于愿望的

一些项目经理认为只要团队足够努力，就会非常卓越

通常，这种激励导致团队不仅没能高绩效，反而功能失调

随着时间的推移，超越极限的项目计划成为非理性的、基于愿望的计划

8.3 多层计划

多层计划有助于解决一个两难问题：计划急需要预测性又需要灵活性

完整的产品计划结构

包括：产品路线图、发布计划、里程碑计划、迭代计划

8.4 性能

性能是指高级的、完整的和有价值的业务或产品功能，而故事是指向客户交付的一项有用和有价值的功能。

产品生命周期

8.5 价值点分析

产品团队通常确定故事或性能的相对价值，要具体量化该价值是很困难的，可使用价值值做表述

以下4个理由表明价值点大有裨益：

使用他们可向管理层展示一个估计价值的定量方法

有助于团队再制定发布、里程碑和迭代计划时做出优先决策

有助于团队深入讨论故事功能

有助于尽早推进高价值的性能和故事，从而提高投资回报率

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

谁确定：产品经理带领下的产品团队负责价值点估计，整个团队（包含开发人员）也应参与价值点的讨论，可以使团队成员对于价值的相对重要性有统一的认知

什么时间确定：可以是准时制（just in time，JIT）

8.5.2 计算相对价值点

单个故事价值点，限于几个简短的数字（1、2、3、5、8、13）

总价值点基于百分比分配给性能，性能点值（1、2、3、5）

如一个项目有5个性能，性能点分别为2、3、3、5、1，那各个性能的百分比就是14%、21%、21%、36%和8%

8.5.3 计算货币价值点

货币价值点和货币故事点一起使用可以提供利润与成本进度报告

交付的价值和成本

8.5.4 不面向客户的故事

不面向客户的故事如何计算其价值，建议可以分配相对较小的值

8.5.5 价值和优先级

价值是决定优先级的最大因素，但其它如主题、风险减低、依存关系等因素也决定是否把性能或故事分配到计划中，不同因素的重要性在整个项目周期有所不同

8.6 发布计划主题

8.6.1 计划主题和优先级

团队在短期迭代中为了急于交付，对于商业价值的追求往往做不到最优化。

为了能合理关注价值，项目既需要一个总体”构想“，也需要有实现该构想的短期”主题“

不同类型的主题可以单独或联合使用，如业务职能、业务职能的广度或深度、业务流程、风险缓解和部署计划等

8.6.2 提高生产率

两种方法：做的更好（提高每单位投入的产出）或者做的更少

敏捷项目通过减少两个维度的工作来提高生产率：广度和深度

8.6.3 风险分析和降低

软件项目中的5个关键风险：

进度计划固有的缺陷

需求膨胀（蔓延）

员工流动

技术规范的分解

生产率低下

解决进度风险的敏捷项目管理技巧：

团队参与计划和估计

尽早获得有关交付速度的反馈信息

不断施加压力以平衡有容量限制的功能数量和深度

工程团队和客户团队之间密切交流

尽早检查/纠正错误，保持工作产品无缺陷

短迭代，将精力放在功能、功能深度和功能价值上，这些虽然不贡献生产率，但通常会减少产品的工作总量，提高投资回报率

8.6.4 计划和扫描

敏捷方法旨在管理不确定性，太过强调适应性胜过预见产生潜在问题，而解决这个问题的一个方法就拓展我们的做法- 既做计划（用我们所知道的知识）又做扫描（展望未来以尽快学习未知的东西）

扫描形式：试验、管理风险、监督假想、预见决策；通过系统的、主动尽早收集信息或者识别在将来某个时刻要收集的信息来减少不确定性

管理风险是扫描的另外一种形式

主动扫描可以防止团队陷入”适应“（或重构）的陷阱，认为适应能解决任何问题和纠正任何错误

尽管适应的确是敏捷开发的主要部分，但是它也不应该成为草率项目管理的借口

坐视不管，等到有事了才采取适应措施会造成非常严重的后果

良好的计划和扫描以及必要时的适应能力构成强大项目管理组合

8.6.5 时间框定规模

固定一个时间期限，而其它要素可以变化

8.6.6 其它故事类型

发布计划中80%-90%的故事都应该面向客户的故事，不直接面向客户的故事既危险又必要。

不成熟的敏捷团队使用这些故事重新陷入非敏捷的习惯，太多技术故事或类似任务表明团队不理解”客户有价值的功能模块“；但不把此类故事包含在内会导致低估整个工作量。

几种方法有助于制定更完善的计划：

1 维护故事（维护和改进需求）

2 任务卡片（有时把几天的工作都囊括在一个小小的故事卡中也不现实，如调研工作，可能会花费大量时间且会影响许多故事）

3 变更卡片（需求变更）

4 团队间职责协议卡片（11章详细解释）

5 决策里程碑（记录了项目的关键节点，决策里程碑不代表决策活动，注意监控决策点）

完整的发布计划

6 性能卡片（关键操作和性能需求）

8.6.7 在制品和制成品

减少项目数量、尽可能让专人负责项目

敏捷做法的原则是让组织开发更多的制成品而不是在制品

8.7 新做法

8.7.1 看板

没有固定的迭代长度，详情可以参看 《看板和Scrum相得益彰》

8.7.2 联合开发

开发、维护、改进人员归为一组，快速修复

多个迭代同时进行

8.7.3 超开发和发布

超快开发、发布、部署

引入保障技术

8.8 结束语

在不同的时间范围内可以制定不同详细程度的发布计划

发布计划为管理层和主管提供了一个基准，用于判定既定的约束内交付高质量、可发布产品的可行性

9 探索阶段

敏捷项目管理构想和探索周期

9.1 敏捷项目领导

敏捷项目领导关注增加项目价值

项目管理应该看作是提供鼓舞领导、集中交付客户价值的管理

而不应看作是日常管理，如合法的需求、工作进度报告、重要事件审批会，都属于日常管理，虽然必要，但都不能直接增加价值

9.2 迭代计划和监督

包括三个活动：迭代计划、工作量管理、监督迭代过程

9.2.1 迭代计划

整个项目团队（含产品、客户、dev team、迭代经理、项目领导）都应该参与会议，了解该迭代要完成的工作有多少，确认迭代的主题

建议一周的迭代计划会议1-2小时，3周的迭代3-6小时

1 估计和任务规模

故事通常需要2-10天的工作量，而任务不超过8个小时

2 迭代长度

遵循标准：交付用户价值功能块（故事）、构建和测试故事（可工作的软件）和产品团队对故事的验收

其它因素：事件范围、探索系数、管理费用、学习需要等

迭代长度应该是个常量，保持一致节奏

9.2.2 工作量管理

工作量管理旨再让团队成员管理必要的日常任务，以便在每个迭代结束时交付故事

项目领导者通过制定业绩目标并监督其实施，而不是通过制定任务进行监督管理，微观管理人员试图规定详细的活动，然后不断的监督活动是否按时完成

指导型领导者的态度反映在”我如何才能帮助员工交付结果？“而微观管理人员的态度则是”为什么xxx号任务还没有完成？“

9.2.3 监督迭代计划

通过参加日会了解迭代进程，团队保留进程图标或故事/任务检查表

9.3 技术做法

简单设计、持续集成、（无情）自动测试、（不失时机）的重构

9.3.1 技术债务

产品的实际变更成本与最佳成本之间的差额，管理技术债务有助于交付敏捷三角中的质量

增长技术债务时影响产品可行的最大障碍

9.3.2 简单设计

基于已知知识而不是基于对未知的预测而设计

管理变更有两个基本方法：预测和适应，良好的设计策略包含这两方面

产品的可延展性越强，变更成本就越低，在预测与适应的天枰上，就越容易向后者倾斜

简单设计并不意味着简单化设计，通常提出让人理解、适应能力强的简单设计需要额外的时间，摈弃不重要的东西并将重点放在客户价值，以此来减少工作量，就可以节省时间更好的做事-- 这就是简单设计

9.3.3 不断集成

在开发期间尽早、经常确保产品功能组合成一个整体，从而减少无法组合造成的高成本和测试负担

9.3.4 无情测试

确保整个开发过程保持高质量

无情的测试包括：软件工程师不断进行单元测试、将质量保障和验收测试融入每次开发迭代、全系列测试自动化

9.3.5 不失时机的重构

不断的、连续的改造产品设计，让它的适应能力更强，以满足如今和未来交付客户价值的目标

重构不是草率设计的接口，我们的目标不是重构，而是保障可行的、适应能力强的设计

9.4 指导和团队开发

以下列6种方式，为项目成功作出贡献：

1 让团队把精力集中于构想、目标和交付结果

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

3 开发每个人的能力

4 为团队提供所需的资源并清除路障

5 教导客户

6 使团队的节奏保持一致

敏捷项目领导者这个角色的本质不是画甘特图或者编写进度报告（虽然这是工作的一部分），而是将一群人组建成一个高效的探索团队

新产品开发的基础是探索和试验，这涉及出错甚至失败的风险，但也会从错误中学习。经理必须承担风险，从而降低团队的风险

经理的责任：

1 管理自己，”自己的正值、品格、道德规范、知识、智慧、秉性、言辞和行动“

2 管理权力超过自己的人，”经理、上司、高级主管、监督员和其他人“

3 管理同级别的人，”合作者、竞争对手、供应商和客户“

团队管理自己越多，项目经理干预就越少，这样项目经理就有更多的时间用于管理上层和外部，那项目经理的效率就越高

9.4.1 使团队精力集中

优秀的经理和领导者管理结果而不是活动，适当的人员指导需要扮演的角色及弄清楚如何交付这些成果

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

”有凝聚力的团队“，信任、相互交流、圆满解决冲突、参与式决策

有凝聚力的团队经常就某些问题展开激烈的争论和冲突，控制团队”脾气“是领导的软技巧之一，也非常难做，引导争论使他们建立信任和尊重，而不是消弱它们

相互交流促进创新

经理应该协助团队制定一套”交往规则“，作为指导团队成员如何互相对待的级别规则，并视需要调整这些原则，以积极方式引导这些冲突和争论

团队交往规则：

每个人都有平等的发言权

每个人的贡献都是有价值的

对事不对人

在团队内保留隐私

互相尊重并尊重分歧

人人参与

9.4.3 开发每个人的能力

鼓励个人发展，了解与生具有的才能并以此为基础加以发展，而不是试图灌输其不喜欢的

开发指导来自3方面：技术的、专业领域的和行为的

个人通过运用技术能力和从事团队提高（自我组织）的行为，对团队做出贡献:

承担实现结果的责任

严谨思维、面对现实

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

尊重同事

9.4.4 移山，引水

移山：消除障碍、引水：提供资源

9.4.5 教导客户

客户-开发人员合作伙伴关系不好，一般原因:

在客户眼里，开发团队缺乏可信度

缺少客户参与

客户以放对于做决策和承担后果的责任不够

开发时间长，并因为交付毫无意义的中间产品（给客户）而使问题进一步恶化

因需求表达不清而制定不现实的项目进度计划

缺少客户的验收标准和测试

通过指派产品经理，减轻问题，产品经理必须承担识别、定义、确定优先级和验收功能的责任，产品经理的一个工作就是在这个流程中指导客户团队

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.2 协调利益相关方

项目经理必须保证团队获取资源、并给其提供不断的支持

9.7 结束语

探索是敏捷团队的执行方式，敏捷团队不是按书面计划按部就班，而是进行一系列由计划的试验、交付一系列的功能、做一系列的尝试，从而在商业模型的范围内将产品构想变成有形的产品

探索需要在那些胜任的、创造自我组织环境的经理的带领下，由那些胜任的、自律的团队完成

项目经理和产品经理是团队探索流程的直接奉献者，他们鼓励而不是激发，苛求但不武断，授权也自己做决策，指导而不是批评，推动而不是命令；通过集中团队的精力，将个人塑造成有凝聚力的团队，开发每个人的能力，为团队提供资源，与客户和利益相关方交流协调，促进参与式决策流程

敏捷领导阶层是带领团队前进而不是只管理任务的人

10 适应和结束阶段

计划是对未来的推测或假定，频繁而有效的得到反馈对于验证这些假设是必要的

团队在4个方面不断的评估做出适当的改变：

产品价值、产品质量、团队绩效、项目状态

10.1 适应

能像客户交付价值（以可发布产品的形式）吗 （关注里程碑和发布计划，而不是迭代计划，有关可交付的问题，参考的范围要广、视角要更宽）

“生产可靠的、适应能力强的产品”这一质量目标能实现吗

项目在可接受的约束内进展得令人满意吗

对于管理层、客户或者技术施加得更改要求，项目团队做出来有效回应吗

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

主要原因：

反省、学习和适应

改变步伐

主要措施：

客户中心组（向产品团队展示最终产品的现行版本，获得产品如何更好的满足客户需求的定期反馈）

技术评审（定期技术评审，包括非正式和正式的安排）

团队绩效评估，从交付绩效和团队行为着手（超标、达标、不达标）

项目进度报告（价值和范围、质量、进度和风险、敏捷性、成本状况、项目团队信息）

适应措施（目前处境、目标、如何实现目标）

10.3 结束阶段

项目评审

10.4 结束语

监督和适应（传统上成为监督和控制）是所有优秀项目管理方法的组成部分

敏捷团队管理也采用一些通用的项目管理做法，但对其态度是独特的：

如敏捷团队更愿意采用适应措施而不是纠正措施，虽然纠正有时是必要的，态度上是适应和前进，而不是责备和写意外报告

交付可用功能的频繁迭代，使敏捷项目团队在可验证的结果基础上经常调整

适应阶段在高度紧张的短期迭代开发中提供了一个短短的暂缓期

11 敏捷项目扩展

处理大型、不确定和复杂项目的做好办法就是缩减项目规模

11.1 规模扩展的挑战

扩展结构的同时，保持灵活和半自治这个特点

11.1.1 规模扩展要素

4个组织扩展要素：组织设计、决策设计、协调设计、敏捷文化

与产品有关的规模扩展要素：多级发布规划、多团队功能清单管理、确保可发布产品组件的流程和工具、计划和协作工具

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 路线图和功能清单

发布计划中，性能开发工作分配到功能团队，功能团队制作里程碑计划

性能拆分成故事，分配到迭代

一般，路线图每6个月更新一次，发布计划每个月更新一次，里程碑计划每次迭代时更新

11.4.3 多级发布计划

4种不同时限的计划：路线图、发布、里程碑、迭代计划

多级计划构成

11.4.4 维护可发布产品

维护可发布产品是一个敏捷原则，应以尽可能保持较短的BIT（构建、集成、测试）周期为目标，但也要遵循实用性原则。是一种平衡艺术

在尽可能短和成本间保持平衡，不要让“每周BIT产品成本太昂贵”成为获取机会的一种障碍，敏捷项目经理必须不断在障碍和机会间需求适当的平衡点

11.4.5 团队间职责协议

ICS（Inter-team Commitment Story, ICS) 团队间职责协议，目的以最小的规则干预使各个分队实现自我管理，通过澄清团队之间的依存关系，也有助于项目组合管理

职责协议：功能单位之间一种简单的数目协议，团队自己决定如何协作，而不是项目经理自上而下的分配工作任务

当项目规模扩大，建立类似机会，容许各分队在一起工作并且相互之间的干预最少

ICS卡示例

ICS卡优点：

将协作工作公诸于众，这样，团队可以找出他们协作反而不如独立工作时效率高的原因

有助于团队管理工作量

有助于建立功能团队之间的合作关系

将协作的任务留给掌握具体信息的人

提高各分队的责任感，因为责任由他们自己决定

11.4.6 工具

分类：协作、开发环境、信息共享、项目管理

11.5 向外扩展- 分布式项目

分布式项目级别上拥有多个开发地点

11.6 结束语

本章介绍了大量的有关组织和产品的做法，帮助把敏捷方法扩展应用到大型项目中

大型敏捷团队也许不如小型敏捷团队灵活，但只要实现敏捷项目管理最基本的目的就可以了，即向客户交付有价值的产品并创造一个令人满意的工作环境

12 治理敏捷项目

挑战：如何从敏捷项目过渡到敏捷组织，主管有必要了解敏捷开发是如何影响他们的组织、项目投资组合以及整个项目的管理

12.1 投资组合治理

有关项目治理，主管对两件事情感兴趣- 投资和风险，治理是在不确定环境中制定投资决策

投资回报率有3个组成部分：产生的价值（资金流入）、消耗的成本（资金留出）和时间（流入和流出的时机）

12.1.1 投资和风险

两种项目类型：产品项目和探索项目

产品项目特点：解决方案是已知的

探索项目特点：问题、解决方案有其一或其二未知

12.1.2 主管级信息要求

管理产品生命周期投资和风险

相当于增量融资模型，在瀑布项目中，主管能够在任何阶段取消项目

敏捷的不同之处在于它生产增量产品，而不只是记录来自活动；敏捷开发的重点是系统的交付高价值的产品功能并降低风险

12.1.3 工程级信息的产生

传统的瀑布阶段- 关卡模型

阶段- 关卡进程

综合线性治理模型和迭代开发模型 每个阶段的多次迭代

“松散耦合”，两个模块一起运行但相互独立，很容易单独修改其中一个，有关联但没有集成

项目治理和业务交付应视为相同模式，有关联但又相互独立

12.1.4 企业级治理模型

4个阶段生命周期：概念、扩展、延伸、部署

1 概念阶段

两个目标：创建并确定产品构想，识别并降低风险

概念阶段由第0次迭代（不交付实际故事）和几次短期开发迭代（交付故事）构成

第0次迭代：开发体系结构、搭建开发环境、做技术和客户调查、钻研旧系统提炼复杂的业务逻辑等

2 扩展阶段

目标是从项目中去除残余的风险因素同时构建高价值的功能

3 延伸阶段

目标把已经知道怎么做的事情延申来做，该阶段会花费大量预算，正常情况下不会有太多意外

4 部署阶段

部署产品进入实际使用阶段

5 关卡

大多数开发生命周期的方法把重点放在阶段上，但如果关注关卡会更加有效。关卡即项目中的关键决策点，也是考虑是否会对对下一个阶段投资的决策点

12.1.5 使用敏捷治理模型

对于敏捷治理模型：可以选择不使用、部分阶段使用、部分组织使用、都使用

对于大型组织、大型项目，使用完整的敏捷阶段-关卡模式十分受益

12.2 投资组合管理主题

12.2.1 设计敏捷投资组合

敏捷项目管理，相对于序列方法的优势在于：

显而易见的结果- 每两周迭代故事

客户反馈

更好的发布计划

灵活性

生成效率，提高潜在生产效率，通过不断与客户进行各个层次的沟通，减少和淘汰掉了一些功能

在投资组合层次应用敏捷做法时，会产生类似好处：

显而易见的结果- 每季度，产品得以开发、实现、测试、验收；短期增量交付

客户反馈

更好的投资计划,由于投资机会基于已部署的整个或部分产品而定义因此更加现实

灵活性

生产效率

项目分开设计大型项目，把该大型项目拆分为较小的组块，这样能够降低风险、实现效益更块，同时还可以提供更多选择从而增加灵活性

分块通过创造机会点和更快的交付价值而帮助应对不确定性和速度

12.2.2 敏捷方法“拟合”

在大量的模型中，对于某一具体项目应该选择适合的方法或做法

水晶（Crystal）系列方法中，确定一系列方法- 透明、黄色、橙色，根据大小、临界程度和其它因素而确定

3个关键因素对于确定拟合方法非常有价值：

项目因素（复杂性和不确定性）

文化因素

治理和合规因素

12.3 结束语

项目经理、客户、中层，主要关注敏捷三角（价值、质量和约束）来评判项目结果

主管审核项目时，更关注投资和风险概述

本章探讨两个关键点：

业务交付方法需要与治理方法分离开来

治理方法应该关注投资和风险信息而不是交付活动

分离这些层面使得组织能够更好的将敏捷项目融入广泛的项目投资组合中，在这些投资组合中有些项目可能不使用敏捷方法

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

敏捷组织变革，需要6个方面的工作：组织、流程、绩效评估、调整（业务和技术）、治理和文化

敏捷组织必须和敏捷团队遵循相同的价值观：

交付价值胜过满足约束

领导团队胜过管理任务

适应变化胜过遵循计划

我们的问题不是好高骛远，而是目标太短浅- 亚里士多德

回顾敏捷三角形：

13.1 质量是什么

客户质量，交付短期价值

技术质量，随着时间演变而持续交付价值

技术（内在的）质量：可靠性（正确运行）和适应性

导致过多测试的3个因素：高缺陷率、冗长的错误定位曲线、高错误反馈率

13.2 计划与评估

选择一个可按时、按质、按成本交付，但低商业价值的项目，还是选择一个几乎不可控缺有着丰厚商业利益的项目。大多数项目经理会选择前者

在传统的项目管理思维中，破坏了时间、预算、范围，或者结束了一个项目，都算不成功

如果想获得敏捷方法的全部收益，成为敏捷、创新的组织，需要变革绩效管理系统

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

APMS，Adaptive Performance Management System,适应性绩效管理系统

面向结果的测量指标：创造的商业价值

测量指标：生产效率、成本等

APMS 目标：

使任何企业集团把重点放在一套希望获得的战略结果上

鼓励这些团体（项目团队）实现高水平产出

13.2.2 评估问题

创建适应性组织，3个关键的评估理念：

1 承认绩效评估系统影响组织的敏捷性

2 从过于关注时间改变为重视结果，也就是对客户的价值

3 把结果绩效评估与产出绩效评估分割开来

传统绩效希望可预见性更强，敏捷强调适应性，但适应性不是不良绩效的借口

“可预见性悖论” 当对偏差的承受能力变大时，各方面的绩效通常都有改善。- 迈克尔.马赫

13.3 评估概念

13.3.1 超越预算

花费时间和金钱，制定过于详细的计划，根据的是对项目的模糊认知和对未来严重的不确定性

固定预算或者计划与竞争环境格格不入，事情变化了，当初所作的一些假定失效了

在固定的绩效合同中，无论时预算还是项目计划，“数字游戏”都过于泛滥

自适应管理方式- 分权、协作、创新，6个共同原则：

”没有计划和预算进行管理的主要优点之一是管理人能够全神贯注的响应不断出现的变化并向客户和利益相关方提供价值“

需要摈弃固定的绩效合同、命令-控制的管理模式、依赖文化、中央分配资源的模式、多层次的功能层级结果和封闭的信息系统

”有效的授权是自由与能力相结合的产物“

13.3.2 评估组织绩效

Measuring and Managing Performance in Organization- 罗布.奥斯丁

评估”系统“非常困难，信任、诚实和良好的意愿要比核查、狡黠和利己主义更加有效

1 度量程序失败

评估失衡模式，最初评估系统可以改善结果，由于员工并不真正了解这个系统，因此他们的行动会试图满足该系统的意愿，但随着时间的推移，增加的”改进“压力，迫使人们颠覆该意愿以实现评估目标

因为预期结果和实现该结果的衡量指标总是互相脱节，因此，随着时间的推移，评估业务不断攀升，而真正业绩严重下滑

评估系统如何变得功能失调

CMM(Capbility Maturity Model) 能力成熟度模型

许多传统项目管理的度量指标导致了功能失调，他们不在鼓励真正的绩效，而是诱导功能失调的行为

2 两种管理方式

自我组织意味着依靠团队内在动力而非外在动力（如评估目标）

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

建立基于信任、诚实、旨在提供组织价值的评估系统

把大多数重点放在评估结果而不是输入上，即使在度量指标不容易获取、也不精确的情况下

对于偏差宽容对待约束指标，以鼓励适应

创建产出信息度量指标以支持人类天生的内在动机的需要，结合使用评估方式以促进全面进步

13.4 结果绩效的衡量指标

关键问题（涉及敏捷三角形）

项目社区是否持续向客户交付价值

项目社区是否交付高质量产品，使得未来也能持续交付客户价值

项目社区是否在可接受的范围、进度和成本约束内交付了产品

如IRACIS价值评估系统：IR代表增加收入、AC代表避免成本、IS代表提高服务

13.4.1 约束

范围、进度、成本

约束越严格，团队拥有的灵活性越少，团队交付最高优先级结果的可能性就越小

13.4.2 社区责任

产品团队、开发团队和项目赞助商必须致力于项目结果的实现

通常在传统项目中产品团队为开发团队提供需求和约束信息，但是他们不直接对结果负责

敏捷项目中，整个项目社区是一个统一的整体，共同致力于结果的实现

13.4.3 提高决策

目标结果和约束对评估绩效非常重要，且有助于有效决策

目标和约束需要调整并适应不断变化条件的决策流程

项目管理与两件事有关：管理人和管理决策

13.4.4 以计划为指导

计划，包括对范围、进度和成本进行估计，制定计划非常有用，但用途不同

计划用来指导团队，而不是团队的紧箍咒

团队会努力按约束交付，但交付预期结果更加优先

意愿，对于任何评估系统都非常关键

13.5 产出绩效的衡量指标

13.5.1 五项核心度量指标

SLIM（软件方程式）模型 用到了五项核心度量指标：

功能的数量：以用户故事、用例、需求

13.5.2 结果和产出

除非我们明确的认为结果非常关键，并且以客观的方式定量或定性的的衡量，否则产出指标将会起到主导作用，使得预期绩效和评估绩效背道而驰，导致功能失调

结果和产出有区别但不能独立看待，如创新项目，预期结果在业务和技术价值上创新，交付这样的结果就容易导致产出指标（如生产率）较为低下

13.6 缩短尾巴

尾巴指“代码变动缓行（Code Slush）”（真正的代码冻结很少）或者“特征冻结”阶段到发布生产之间的时间段

这段时间公司有下列工作：如Beta测试、回归测试、产品集成、集成测试、文档、缺陷修复

缩短尾巴是评估敏捷进展的一个简单而有力的度量指标

缩短尾巴：如自动化测试、每次迭代驱动回归和集成测试，花时间做系统重构减少技术债务、从而减少测试和缺陷修复的时间

13.7 结束语

一些投资组合治理系统把IT项目归为4大类：

基础设施、公益事业、改进和前沿项目

前沿项目：指那些创新产品、新业务服务和新的商业流程的项目，需要团队密切合作，明确的需求较少，风险较高，潜在的投资回报最高。许多组织，前沿项目仅占投资预算的10%-20%，以最低成本完成它们或许就是目标，以进度和成本来评估

建立基于信任、诚实，旨在提高组织价值的评估系统

我们要想适应性组织，就必须长时间认真仔细思考成功和绩效意味着什么，并使我们的绩效评估与所选择的管理模式的价值观保持一致

我们的绩效系统必须建立在正确的意愿之上，去指引而不是惩罚，去学习而不是重复，去适应而不是拒绝改变

如果想建立适应性组织，那么必须摈弃固定的绩效合同，而去追寻一种符合这些新的意图的评估系统

14 可靠的创新

新产品开发不是计划-执行，而是构想-探索，没有不确定性和风险，就没有机会。新产品开发流程是为了实现构想而制定进度计划和成本约束，范围有限而构想无限，不现实的构想会导致试验失控

任何产品、组织都不可能在各个领域做到无限的敏捷。找到平衡是敏捷的关键点

14.1 新产品开发的新趋势

新产品研发受两个决定性因素推动，创新的持续需求与变更的成本急剧下降（低成本探索）

努力做到：

让产品充满“比特”（而非“原子”）

创造面向比特的产品开发周期（即在开发周期尽可能的用软件建立和/或模拟产品模型）

持续不断的降低软件的变更成本（低成本迭代）

培养胜任上述策略的人员和制定响应的流程（敏捷人员及流程）

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

敏捷、适应的项目管理和开发要求开发队伍、项目经理和组织的管理层实行重大的文化变革

优秀的组织会找到一个办法处理探索和生产流程两方面的问题

随着变革速度的不断加快，组织中探索活动与生产活动的组合发生了转换，从而为那些以适应型文化为主的公司创造了竞争优势

14.3 可靠的创新

只要高级主管能够清楚表达产品构想，敏捷团队就能交付产品

只要高级主管能够制定合理的成本和进度时间范围，敏捷团队就能交付产品

只要客户和产品经理能够接受他们自己对产品的要求所带来的后果，敏捷团队就能交付产品

只要参与者能够处理组织结构的模糊性和灵活性，能过着重于结果而不是活动，敏捷团队就能交付产品

尽管有很多“可能性”“不确定性”，敏捷项目管理和开发仍然能够交付产品，归功于项目团队成员的热情、积极、坚持不懈和独创性

4种项目类型，神风特攻队型、自杀型、丑陋型、不可能型

神风特攻队：从一开始注定失败，但每个人都认为这种飞行很有乐趣，如“成迷于技术”的项目

自杀型：每个参与者，都知道这个项目将会失败并且会很痛苦，失业威胁是促使他们参加这个项目的唯一原因

丑陋型：项目经理为了个人的荣耀而牺牲他人的劳动，随之而来的肯定是长时间的工作和恶劣的工作环境

不可能型：凭借运气和格外的努力开展项目，几乎不可能完成，但不可能的任务通常也是令人兴奋的，他们是高风险、高回报的项目

前三种，不管任何项目流程都不会有作用，如果高级主管无论在什么情况下、对于什么项目都要求成功，那是在扼杀项目团队的才能

敏捷项目管理不只是项目管理流程，还是一种组织流程，敏捷团队不能在充满敌意的、走向死亡的环境中生存

新产品的开发总是涉及不确定性和风险，随着探索系数的加大、前沿技术的更新、市场力量迅速变化，任何流程和最出色的团队都不能确保成功

然而，合适的人员加上敏捷探索流程可以为成功创造最佳机会

14.4 不断增值的项目经理

高效率的敏捷团队（和组织）创造了管理人员和团队成员之间的平衡，一种自律和自我组织的平衡

敏捷项目经理的风格是领导-协作式而不是命令-控制式，项目经理是敏捷项目成功的关键

相比发号施令，领导难度更大，但回报也更多

营造一个协作的工作环境与控制相比难度更大，更有意义

项目和产品领导都是构想的支持者，他们清楚的表述它，让每个人理解，精心培养它，让所有人不会忘记

构想，以客户为中心-交付价值，以技术为中心-支持卓越技术一遍能够未来继续交付价值

领导帮助团队专注于交付产品，同时最大限度的减少合规工作的干扰

领导工作还包括：员工挑选、员工培养、不断的鼓励

营造“无畏”的环境：“鼓励合作、交互、参与式决策、解决冲突、激烈争论和互相尊重”

软技能（上述）、硬技能（计划、预算、报告、发布计划）相结合，困难部分就是容易的部分

项目经理要与客户团队、高级主管和其它利益相关方一起设立并满足他们的期望值，说服他们作为项目团队的伙伴共同参与项目

考虑敏捷项目的不确定性、模糊性、速度、焦虑和不断变化，项目经理工作是在顾问、调解人和决策人、协助者之间的不断沟通

14.5 结束语

仅有观点不足以创造创新产品和适应能力强的组织，要有深刻的信仰和坚决的承诺，需要建立在核心价值观和原则基础上的流程和实践

敏捷的关键因素是认识到原则比实践更重要，信仰推动行动

没有具体的实践，原则不会产生任何结果；没有原则，实践就没有生命、特征、信仰

优秀的产品和优秀的团队互相促进

敏捷运动核心信念创造了更好的工作环境，解除了暴政、专制和独裁，但不是解除组织结构、责任、项目经理和高级主管的决策权

当自我组织和自律盛行时，当设计（和采用）流程是为了支持而非限制人们时，当个人才能和技巧得到重视时，伟大的产品自然就会出现