（1/2）敏捷实践指南 Agile Practice Guide （[美] Project Management institute 著）

电子工业出版社 Publishing House Of Electronics Industry 北京·BeiJing

版次：2018年10月第1版

印次：2023年2月第22次印刷

定价：68元

声明

作为项目管理协会（PMI）的标准和指南，本指南是通过相关人员的自愿参与和共同协商而开发的。其开发过程汇集了一批志愿者，并广泛收集了对本指南内容感兴趣的人士的观点。PMI管理该开发过程并制定规则以促进协商的公平性，但并没有直接参与写作，也没有独立测试、评估或核实本指南所含任何信息的准确性、完整性或本指南所含任何判断的有效性。

因本指南或对本指南的应用或依赖而直接或间接造成的任何人身伤害、财产或其他损失，PMI不承担任何责任，无论特殊、间接、因果还是补偿性的责任。PMI不明示或暗示地保证或担保本指南所含信息的准确性与完整性，也不保证本指南所含信息能满足你的特殊目的或需要。PMI不为任何使用本标准或指南的制造商或供应商的产品或服务提供担保。

PMI出版和发行本指南，既不代表向任何个人或团队提供专业或其他服务，也不为任何个人或团队履行对他人的任何义务。在处理任何具体情况时，本指南的使用者都应依据自身的独立判断，或在必要时向资深专业人士寻求建议。与本指南议题相关的的信息或标准亦可从其他途径获得。

读者可以从这些途径获取本指南未包含的观点或信息。PMI无权也不会监督或强迫他人遵循本指南的内容，不会为安全或健康原因对产品、设计或安装进行认证、测试或检查。本指南中关于符合健康或安全要求的任何证明或声明，都不是PMI做出的，而应由认证者或声明者承担全部责任。

序言

项目管理协会和敏捷联盟特许编写本实践指南，目的是在社区内建立对敏捷方法的更深入的理解。

本实践指南的愿景是：为项目团队提供相关工具、针对不同情景的的指导方针、对目前敏捷技术和方法的理解，以获得更好的项目成果。

在软件开发之外的各行各业中，不同项目团队都在使用敏捷方法。我们两个组织都认识到，在将产品和可交付成果推向市场时，敏捷方法的发展要求我们需要有一种通用的语言、开放的思维和灵活运用的愿望。此外，我们两个组织还认识到，实现成功交付的方法多种多样。目前存在大量工具、技术和框架；为达成期望的成果，各团队可选择适合其项目和组织文化的不同方法和实践。

《敏捷实践指南》核心委员会的成员们有着不同的背景，并且使用不同的方法。有些委员会成员身为顾问，有些则在组织内工作。他们都已经在工作中使用敏捷方法很多年。

1.引论

欢迎阅读《敏捷实践指南》！

本指南是项目管理协会PMI和敏捷联盟携手努力的成果。负责编写本实践指南的核心创作团队成员分别来自这两个组织，他们广泛汲取了当前拥有不同背景、信仰和文化的广大从业者和领导者的专业知识。

本实践指南为项目领导者和项目团队成员提供实践指导，帮助他们在项目规划和执行过程中适应敏捷方法。我们的核心创作团队发现，目前，人们坚定支持预测法，而对转变为敏捷思维模式、价值观和原则的热情却不高，本实践指南涵盖了项目敏捷性的实践方法。本实践指南就是一座桥梁，可以帮助理解从预测法转向敏捷方法的途径。实际上，二者之间也存在一些类似的活动（例如规划），尽管处理方式不同，但两种情况下都会发生。

我们的核心创作团队使用了敏捷思维模式来合作并管理本实践指南第一版的编写。随着技术和文化的的发展变化，未来对本实践指南的更新和改进将反映现行的方法。

与项目管理协会的标准写作风格相比，在编写本实践指南时，我们核心团队采用了一种更为轻松的、通俗易懂的写作风格。为了更好地阐明有关要点和概念，本指南纳入新元素，如提示、侧栏和案例研究。我们实际上变更的原因是为了加强本实践指南的可读性，方便用户使用。

本实践指南并不仅仅是为了帮助计算机软件开发行业解决敏捷方法应用问题，因为敏捷方法的应用已经扩展到各种非软件开发环境中。制造、教育、医疗保健等其他行业日益向不同的敏捷程度发展，这种超出软件行业的敏捷应用也属于本实践指南的范围。

敏捷型学习

除软件开发外，教育业也为敏捷实践的扩展提供了良好的环境。世界各地的初中、高中和大学教师都开始使用敏捷方法营造一种学习文化。人们利用敏捷技术来为重要工作排优先级。面对面的交流、有意义的学习、自组织团队以及利用想象力的增量型学习和/或迭代型学习都是敏捷原则，这些原则可能改变人们在课堂上的思维模式，促进教育目标的实现。

那么为何要编写《敏捷实践指南》？又为何要现在编写呢？项目团队使用各种形式的敏捷技术和方法至少已经长达几十年。伴随着敏捷方法迅猛的应用势头，《敏捷宣言》明确阐述敏捷方法的价值观和原则。如今，项目领导者和项目团队发现自己正处于一个日新月异的环境中，技术进步呈现指数级增长，客户对价值交付的要求日趋紧迫。敏捷技术和敏捷方法将有效地管理各种颠覆性技术。此外，敏捷第一原则将客户满意视为最高要求，而这也是交付让客户满意的产品和服务的关键。随着社交媒体的广泛使用，快速而透明的客户反馈循环唾手可得。因此，为保持竞争优势，与时俱进，各组织不能只关注内部，而是要放眼外部世界，关注客户体验。

各种颠覆性技术正在通过降低进入门槛来迅速改变竞争环境。越来越多的成熟组织日趋复杂，创新能力发展迟缓，在为客户提供新的解决方案方面滞后。在竞争中，这些组织发现，小型组织和初创公司能够更快地生产出满足客户需求的产品。形势的不断变化将继续促使大型组织采用敏捷思维模式，以保持竞争力和现有的市场份额。

《敏捷实践指南》关注项目，解决项目生命周期选择、实施敏捷方法和组织对敏捷项目的考虑因素。组织变革管理（OCM）对于实践的实施和变革必不可少，但是，由于它本身就是一门学科，因而已经超出本实践指南的范围。希望了解组织变革管理有关指导方针的读者可参阅《组织变革管理实践指南》。

颠覆性技术

向云计算的过渡，尤其促进了颠覆性技术的应用。全球各地的公司都在利用这种模式迅速廉价获取计算资源，以进入传统市场。云计算要求减少预付款，但会基于即付即用或按需付费的机制，通过订阅服务随时付款。更新的应用程序、基础设施和平台以一种迭代的增量方式发布到云端，与技术进步和不断变化的客户需求保持同步。

范围内的事项	范围外的事项
在项目或团队层面实施敏捷方法	在整个组织或创建敏捷项目集时实施敏捷方法
涵盖行业调查中最流行的敏捷方法	涵盖利基方法、特定公司的方法或不完整的生命周期技术
在选择敏捷方法和/或实践时要考虑的适应性因素	推荐或支持一个特定的方法/实践
将敏捷与《PMBOK指南》的过程和知识领域对应起来	变更或修改《PMBOK指南》的过程和/或知识领域
讨论将敏捷应用扩展到软件开发以外	消除软件开发行业对敏捷方法的影响（请注意，尽管敏捷方法在软件行业以外的其他许多行业的应用日益增多，但本实践指南中包括软件业）
在项目或组织中实施敏捷方法时，需要考虑的指导、技术和方法	在项目或组织中如何实施敏捷方法的规范性分步说明
通用术语的定义	新术语和/或新定义

本实践指南适用于对于预测法和敏捷方法难以取舍的项目团队、试图解决快速创新和复杂性问题的项目团队，以及致力于团队改进的项目团队。本实践指南将提供有益的指导方针，它们将有助于项目取得成功，帮助项目团队顺利交付商业价值，满足客户的期望和需求。

2.敏捷概述

2.1可确定的工作与高度不确定的工作

项目工作包括可确定的工作和高度不确定的工作。

可确定的工作项目，具有明确流程，他们在以往类似的项目中被证明是行之有效的。在完成设计后制造汽车、电器、建造住宅，这些都是可确定的工作的例子，其所设计的生产领域和过程通常都很好理解，并且执行的不确定性和风险通常较低。

新的设计、解决问题和之前做过的工作都是探索性的。它要求主题专家携手合作，解决问题，并创建解决方案。遭遇高度不确定的工作的人员包括软件系统工程师、产品设计师、医生、教师、律师、许多解决问题的工程师等。随着可确定的工作日益实现自动化，项目团队也越来越多地从事高度不确定的工作，从事这些工作就需要使用本实践指南所述的有关技术

高度不确定的项目变化速度快，复杂性和风险也高。这些特点可能会给传统预测法带来问题，传统预测法旨在预先确定大部分需求，并通过变更请求过程控制变更。而敏捷方法的出现是为了在短时间内探讨可行性，根据评估和反馈快速进行。

2.2《敏捷宣言》及思维模式

2001年，软件业思想领袖共同发表《敏捷宣言》，正式宣告敏捷开发运动的开始

《敏捷宣言》四大价值观：

我们正在通过亲自开发和帮助他人开发，发现开发软件的更好方法。通过这项工作，我们开始更重视：

个体以及互动，而不是过程和工具
可用的软件，而不是完整的文档
客户合作，而不是合同谈判
应对变更，而不是遵循计划

也就是说，右栏中的项目固然有价值，但我们更重视左栏中的项目

源自这些价值观的十二大原则：

我们的最高目标是：通过尽早持续交付有价值的软件来满足客户的需求
欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势
要经常交付可用的软件，周期从几周到几个月不等，且越短越好
项目实施过程中，业务人员与开发人员必须始终通力协作
要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务
无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面交谈
可用的软件是衡量进度的首要衡量标准
敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该能够始终保持步调稳定
对技术的精益求精以及对设计的不断完善将提高敏捷性（越了解，交付的越快）
简洁，即尽最大可能减少不必要的工作，这是一门艺术
最佳的架构、需求、设计将出自于自组织团队（自觉）
团队要定期反省怎样做才能有效，并相应地调整团队的行为

敏捷思维模式：四大价值观、十二大原则、实践

敏捷思维模式由“价值观”定义，以“原则”为指导，并在许多不同的实践中体现（敏捷实践者根据自身需求选择不同的实践）

在艾哈迈德·西德基 Ahmed Sidky 启发下出的模式将敏捷明确表述为一种思维模式，它由《敏捷宣言》的价值观界定，受《敏捷宣言》原则指导，并通过各种实践实现。

值得关注的是，虽然术语“敏捷”在《敏捷宣言》发表后流行起来，但今天项目团队所使用的方法和技术却在《敏捷宣言》发表前已经使用多年，有些已经使用了几十年之久。

“敏捷”是一种方法、手段、实践、技术还是框架？

根据具体情况，上述词语均适用。除非使用其他词语明显更为合适，否则，本实践指南使用“方法”一词。

“敏捷方法”是一个囊括了各种框架和方法的涵盖性术语。

图2-4结合上下文将敏捷定位为一个总称，它指的是符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段、实践。

图2-4还将敏捷方法和看板方法视为精益方法的子集。这样做的原因是，他们都是精益思想的具体实例，都反映了诸如以下概念：“关注价值”、“小批量”、“消除浪费”

精益
- 看板
- 敏捷
  - ScrumBan
  - Aup
  - 水晶
  - Fdd
  - Dsdm（和Fdd有借鉴）
  - Scrum（和xp有借鉴）
  - Xp

一般而言，可通过两种策略践行敏捷价值观和原则

采用正规的敏捷方法，它们为特意设计，经证明可达成期望的成果。那么，在变更和裁剪之前，就需要花时间学习和理解敏捷方法。不成熟和随意的裁剪会让敏捷方法的效果大打折扣，从而限制了收益。（参见附录X2中的“建议”）
以一种适合项目背景的方式对项目实践进行变更，以便在核心价值观或原则方面取得进展。使用时间盒创建功能，或者使用特定技术迭代优化功能。在适用于特定项目背景下，考虑将一个大项目划分为几部分发布。实现有助于项目成功的变更，这些变更不必是组织的正式实践的组成部分。最终目标不是为了敏捷而敏捷，而是为了客户持续交付价值流，并达成更好的商业成果。

2.3 精益与看板方法

看待精益、敏捷、看板方法三者之间关系的一种思路是，将敏捷和看板方法视为精益思想的衍生物。换言之， 精益思想是一个超集，与敏捷和看板方法拥有共性。

这种共性非常相似，重点在于交付价值、尊重人、减少浪费、透明化、适应变更、持续改善等方面。项目团队有时会发现将各种方法结合起来使用更为有用，只要是对组织或团队有效的方法，无论来源如何，都应该采纳。无论使用什么方法，目标都是为了实现最佳结果。

看板方法受到最初的精益制造体系的启发，专门用知识型工作。它在2000年代中期出现，是当时非常盛行的敏捷方法的一种替代方法。

看板方法不如某些敏捷方法规范，破坏性也较小，原因在于它是原始的“原地出发”方法。在有必要或适当的情况下，项目团队可以相对轻松地应用看板方法，并向其他敏捷方法发展。关于看板方法的更多信息，请参见“附录A3敏捷和精益框架概述”。

案例：

围绕看板方法以及其是否属于精益或敏捷运动可能总是会有大量讨论。看板从精益制造构思出来，也围绕精益制造，但更广泛地应用于敏捷环境中。

2.4 不确定性、风险、生命周期选择(stacy矩阵)

有些项目在项目需求，以及如何使用现有知识和技术满足这些需求方面，具有很大的不确定性。这些不确定因素可能导致大量变更和项目复杂性的提高。上述特点如图2-5所示

随着项目不确定性的增加，返工的风险和使用不同方法的需求也会增加。为了减轻这些风险的影响，团队选择的生性周期要能够通过较少的工作增量解决项目的大量不确定性问题

团队可以利用较少的工作增量验证自身的工作，并且可以对接下来的工作做出相应变更。与静态书面规范相比，当团队交付小的增量时，他们能够更快更准确地理解真正的客户需求

团队可以用明确稳定的管理要求规划并管理项目，轻松解决各种技术挑战。但是，随着项目不确定性的增加，变更、做无用功和返工的可能性也会随之增加（试错程度），而这不仅代价高昂，而且耗费时间。

有些团队让项目生命周期发生演变，以便使用迭代和增量方法。

许多团队发现，在探讨需求、更频繁地交付增量时，团队会更容易适应变更。由于团队获得反馈，这些迭代和增量方法减少了浪费和返工。这些方法应用了：

非常短的反馈循环
频繁地调整过程
重新进行优先级排序
定期更新计划
频繁交付

要点

简单项目、繁杂项目、复杂项目，分别意味着什么？

考虑一些大型的项目，比如波士顿“大开挖”隧道工程项目。表面上，该项目似乎相当简单：将高架公路移到地下。对需求也有高度的共识（参见图2-5 Y轴）。在项目开始之前，项目继续推进的不确定性很低。而且，像许多大型项目一样，该项目在进行过程中也遇到了一些意外

在从事一个几乎没有中间可交付成果或者几乎没有机会进行原型开发的项目时，团队最有可能会使用 预测型生命周期 进行项目管理。团队可以根据其发现的情况做出调整，但却无法使用敏捷方法管理新增迭代需求或增量交付成果，进而获得反馈。

“大开挖”项目无论如何都不是一个简单的项目。但是许多项目一开始处于斯泰西复杂性模型的左下部分，并无真正的手段转而使用其他方法。从需求和交付手段两方面对项目进行评估后确定了项目生命周期的最佳方法。

对于涉及新颖的工具、技术、材料、应用领域的项目，这些迭代、增量、敏捷方法非常有效（参见第3章“生命周期选择”）它们也适用于具有以下特点的项目：

需要研究和开发
变更速度极快
具有不明确或未知的需求、不确定性风险
最终目标难以描述

通过构建一个小的增量，然后对其进行测试和评估，团队可以在短时间内以低成本探索不确定性，降低风险，最大程度地实现商业价值的交付。这种不确定性可能集中于适用性和需求（正在构建的产品是否正确？）、技术可行性和性能（产品是否可以采用这种方法构建？）、过程和人员（这是否为团队工作的一种有效方式？）。以上三个特点（产品规格、生产能力、过程适用性）通常都具有高度不确定的因素。

不过，迭代和增量管理方法也有其应用局限性。当技术和需求的不确定性都很高时（图2-5 右上部分），项目就会极端复杂，陷入无序状态。为了使项目尽可能可靠，需要遏制其中一个不确定性变量

3 生命周期选择

项目有多种形式，也有多种实施方式。项目团队需要认识到相关特征和方案，以选择最可能使项目成功的方法

本实践指南涉及四种生命周期，分别定义如下：

预测型生命周期：这是一种更为传统的方法，提前进行大量的计划工作，然后一次性执行；执行是一个连续的过程
迭代行生命周期：这种方法允许对未完成的工作进行反馈，从而改进和修改该工作
增量型生命周期：这种方法向客户提供各个已完成的、可能立即使用的交付成果
敏捷生命周期：这种方法既有迭代，也有增量，便于完善工作，频繁交付

非敏捷方法应该如何称呼？

并没有一个通用的术语用于描述非敏捷方法。起初，本实践指南用术语“计划驱动型”描述强调提前计划，然后再实施该计划。有些人更喜欢用术语“瀑布式”或“系列式”描述这种生命周期。最终，我们选定使用术语“预测型”，因为预测型在《项目管理知识体系指南》（PMBOK指南）和《项目管理只是体系指南（PMBOK指南）（第5版）--软件分册》中也曾用到

许多组织都不曾遇到过这两种极端的情况，而只遇到过某些中间情况。这是很正常的，但我们仍然需要一种方法来讨论这两个极端。如果敏捷是其中一个极端，我们将另一个极端称为预测型

3.1 项目生命周期的特征

4 种生命周期的特征
方法	需求	活动	交付	目标
预测型	固定	整个项目仅执行一次	一次交付	管理成本
迭代型	动态	反复执行直至修正	一次交付	解决方案的正确性
增量型	动态	对给定增量执行一次	频繁更小规模交付	速度
敏捷型	动态	反复执行直至修正	频繁小规模交付	通过频繁小规模交付和反馈实现的客户价值

需要注意的是，所有的项目都具有这些特征，没有一个项目能够完全不考虑需求、交付、变更、目标这些因素。项目的固有特征决定了其适合采用哪种生命周期

另一种理解不同项目生命周期的方法是，使用一个连续区间，从一端的预测型生命周期到另一端的敏捷型生命周期，连续区间中间还有更多的迭代型周期或增量型周期

第六版《PMBOK指南》附录X3图X3-1将连续区间显示为一条直线。该图强调了从线的一端到另一端，项目特征的变化情况。另一种形象化的方法是，用一个二维正方形表示这个连续区间，如图3-1所示

没有哪个生命周期能够完美的适用于所有项目。相反，每个项目都能在连续区间中找到一个点，根据其背景特征，实现最佳平衡

预测型生命周期：充分利用已知和已经证明的事物。不确定性和复杂性的减少，允许项目团队将工作分解为一系列可预测的小组
迭代型生命周期：允许对部分完成或未完成的工作进行反馈，从而对该工作改进和修改
增量型生命周期：可向客户提供完成的可交付成果，让客户能够立即使用
敏捷型生命周期：它同时利用迭代属性和增量特征。团队使用敏捷方法时，他们会对产品进行迭代，创建完成的可交付成果。团队将获得早期的反馈，并能提供客户可见性、信心、对产品的控制。由于团队可以提前发布产品，而团队将率先交付价值最高的工作，所以项目可以更早产生投资回报。

3.1.1 预测型生命周期的特征

计划始终贯穿其中

要记住的关键一点是，每种生命周都有计划要素。生命周期的不同之处并非在于计划是否完成，而在于完成了多少计划以及何时完成

在连续区间的预测一端，是计划驱动着工作。有多少计划，就有多少提前执行的可能性。尽可能详细地定义需求。团队估算何时能够交付可交付成果，并全面开展采购工作

在迭代方法中，也计划了原型和验证，但是输出的目的是修改一开始所创建的计划。对未完成的工作的早期评审将有助于未来的项目工作

与此同时，增量方法计划交付整个项目后续部分。团队可以提前计划可交付成果的若干次连续交付，或者一次只计划交付一个。可交付成果为未来的项目工作提供了相关信息

敏捷项目也有计划。主要区别在于，通过对频繁交付的可交付成果的评审，团队将能获得更多的信息，从而在此基础上进行计划和重新计划。

无论采用哪种项目生命周期，项目都需要计划。

预测型生命周期预计会从高确定性的明确的需求、稳定的团队和低风险中获益。因此，项目活动通常以顺序方式执行，如图3-2所示

为了实现这种方法，团队需要详细的计划，了解要交付什么以及怎样交付。当其他潜在变更收到限制时，这些项目就会成功（例如，需求变更；项目团队成员修改团队交付的成果）。团队领导的目标是尽可能减少预测型项目的变更‘。

团队在项目开始时创建详细的需求和计划时，他们可以阐明各种制约因素。然后，团队可以利用这些制约因素管理风险和成本。进而，团队在实施详细计划时，他们会监督并控制可能影响范围、进度计划或预算的变更。

预测型项目强调根据部门划分的、有效的、顺序的工作，并且通常不会在项目结束前交付商业价值。如果遇到变更或需求分歧，或者技术解决方案变得不再简单明了，预测型项目就将产生意想不到的成本。

3.1.2 迭代型生命周期的特征

迭代型生命周期通过连续的原型或概念验证来改进产品或成果。每一个新的原型都能带来新的相关方新的反馈和团队见解。然后，团队在下一周期重复一个或多个项目活动，在其中纳入新的信息。团队可能会在长达数周时间的一个特定迭代中使用时间盒，集中各种见解，然后根据这些见解对活动进行返工。这样，迭代有利于识别和减少项目的不确定性，

当项目复杂性高、变更频繁或当项目范围受到相关方对所需最终产品的不同观点的支配时，采用迭代型生命周期会有优势。迭代型生命周期可能需要更长的时间，因为它是为学习而优化，而不是为交付速度而优化。（增量，是为了速度而交付）

3.1.3 增量型生命周期的特征

您是否曾经参与过这样的项目，在项目过程中，需求似乎每天都在变化，您认为，“我们在交付企业批准的原型时，就会了解需求。”如果情况如此，那么，采用敏捷方法将有助于这个项目。

原型法，鼓励反馈，并有助于更好地理解可纳入每个可交付成果的需求。

有些项目优化是为了加快交付速度。许多企业和项目无法等待所有的事情全部完成；这种情况下，客户愿意接受整个解决方案的一个部分。这种少量可交付成果的频繁交付称为“增量型生命周期”

完整性和交付是主观的。团队可能需要获得关于原型的反馈，然后可能选择将最小可行性产品(MVP)交付给部分客户。客户的反馈将帮助团队了解他们需要为随后交付的最终功能的完善提供些什么。

敏捷团队的一个重要差异化优势在于，他们会经常交付商业价值。由于产品的功能得到增加，就能吸引更多的消费者，因而我们就可以说，它是增量交付的。

与一次交付一个最终产品（迭代型）相比，增量型生命周期将经常优化为项目发起人或客户交付价值的工作。在开始工作之前，团队就计划了最初的的可交付成果，他们还会尽快开始第一次交付的工作。某些敏捷项目在项目启动后几天内就开始交付价值。有的项目可能需要更长的时间，从1周到几周时间不等。

随着项目的继续，团队可能会偏离最初的设想。由于可以更快地交付价值，因而团队可以管理偏差。与客户在项目结束时获得价值相比，确保客户能尽早获得价值，其变更和差异程度的重要性变得不那么重要。（因为可以频繁交付，所以变更和差异可以更快得到纠正）

采用增量方法的一个例子是：

为客户提供一个单一功能或是交付一项完成的工作

例如：

在继续修建大楼的其他部分之前，施工人员可能希望先展示一间已完工的房间或一层楼。这种情况下，在继续修建大楼的下一层前，他们可能会为已完工的楼层布置家具、刷漆等。客户可以查看和批准有关样式、颜色和其他细节，以便在进一步投入时间和金钱之前做出相应的调整。这样做将减少潜在的返工和 / 客户的不满。

3.1.4 敏捷生命周期的特征

在敏捷环境中，团队预料需求会发生变更。

迭代和增量方法能够提供反馈，以便改善项目下一部分的计划

不过，在敏捷项目中，增量交付会发现隐藏或误解的需求。图3-5显示了实现增量交付的两种可能的方法，这样将便于项目与客户需求保持一致，并根据需要进行调整

在基于迭代的敏捷中（一次交付、各时间盒相等），团队以迭代（相等持续时间的时间盒）形式交付完整的功能。团队集中于最重要的功能，作为一个团队合作完成其工作。然后，团队再集中于下一项最重要的功能，并合作完成其工作。团队可决定一次进行若干功能的开发工作，但团队不会同时完成所有的迭代工作（即团队不会在完成全部分析等工作后再解决所有需求）

在基于流程的敏捷中（多次交付、各时间盒不等，由功能决定），团队将根据自身能力，从待办事项列表中提取若干功能开始工作，而不是按照基于迭代的进度计划开始工作。团队定义任务板各列的工作流，并管理各列的进行中的工作。完成不同功能所花费的时间可能有所不同。团队让进行中的工作的规模尽量小，以便尽早发现问题，并在需要变更时减少返工。无需利用迭代定义计划和审核点，而由团队和业务相关方决定规划、产品评审与回顾的最适当的进度计划。

敏捷生命周期是符合《敏捷宣言》原则的周期。特别是，客户满意度将随着价值产品的早期交付和持续交付不断提升。此外，功能性的、提供价值的增量可交付成果，是衡量进展的主要尺度。为了适应更频繁的变更和更频繁地交付项目价值，敏捷生命周期结合了迭代和增量方法。

3.1.5 敏捷适用性筛选器

有各种评估模型，可用来帮助确定使用敏捷方法的适合性或差距。这些模型，评估项目和具有适应性和适用性的组织因素，然后提供分数表明一致性或潜在风险领域。附录X3综合提供了各种流行的模型，它们可用作敏捷适用性筛选器

3.1.6 混合生命周期的特征

混合生命周期项目示例

医药行业，关系到人命，所以对药物、对治疗的任何过程，都需要做到精细

某制药公司进入旷日持久的美国食品药品管理局（FDA）审批过程，该过程一直延续到开发过程结束及整个生命周期，如图3-6所示。当项目团队以一种敏捷的方式进行药物试验时，为执行FDA的审批过程，他们必须将药物展示给一个外部团队。一位顾问帮助将FDA的审批过程部分集成到敏捷开发过程中，以创建一种更加合理的混合方法。（先交付一部分可行性产品，对外找受试群体进行试验（本质与软件行业的灰度测试一致，都是先找部分群体进行实验，看产品有没有缺陷，如果没重大缺陷，就开始全量），如果没问题，就开始批量生产）

这个故事的简短版本是：因为FDA的审批过程需要在开发过程结束时完成，或者在发生任何变更之后重复执行（这包括：即使发生了最微小的变更后），所以这个过程必须在开发过程结束后作为一个单独的阶段而存在。使用迭代过程集成并不成功（因为迭代型，只交付一次。药物需要多次交付，以便进行多次试验，来保障药物的安全、稳定）。不过，这位顾问创造了一些有用的快速入门指南和测试协议，它们缩短了最终的FDA审批过程。

3.1.7 结合了敏捷和预测的方法

另一种方法是在整个生命周期中结合使用敏捷方法和预测法

在图3-7中，在同一项目中结合使用了预测法和敏捷法。也许团队正在逐渐地向敏捷过渡，并使用一些方法，如短迭代、每日站会、回顾会，但在项目的其他方面，如前期评估、工作分配、进度跟踪等，仍然遵循了预测法

同时使用预测法和敏捷法是一个常见的情况。将这种方法称为“敏捷方法”是一种误导，因为他显然没有充分体现敏捷思维模式、价值观、原则。不过，由于这是一种混合方法，所以称其为“预测法”也是不准确的

3.1.8 以预测法为主、敏捷方法为辅的方法

图3-8所示为一个以预测法为主的项目中一个小的敏捷要素。在这种情况下，以敏捷方法处理具有不确定性、复杂性、范围蔓延机会项目的一部分，而使用预测法管理项目的其余部分。这种方法的一个例子是，某工程公司正在使用一个新的组件建造一个设施。

虽然大部分项目可能是常规的、可预测的，就像组织实施的许多其他的设施项目一样，但这个项目包含了一种新的屋顶材料。承包商可能计划首先在地面上进行一些小规模的安装试验，以确定最佳的安装方法，并在有足够时间解决问题时尽早发现问题，随后通过试验和调整，增量地改进过程

3.1.9 以敏捷方法为主、预测法为辅的方法

图3-9描述了一个以敏捷方法为主、预测方法为辅的方法。当某个特定要素不可协商（需求非常确定、技术非常确定），或者使用敏捷方法不可执行时，可能会使用这种方法。这种情况的例子包括：集成由不同供应商开发的外部组件，这些外部组件不能或不会以协作或增量方式合作。在组件交付后，需要单独集成。

3.1.10 符合目的的混合生命周期

某政府部门有一个信贷保险申请开发项目。这个多年期项目使用新的、响应能力更强的用户界面和系统集成来取代其过时的保险体系。项目的大部分使用敏捷方法实施，并伴有持续的业务输入。

保险费率根据经济合作与发展组织（OECD）下发的一个200页的规范进行计算。计算步骤解释非常清楚，几乎不会有混淆机会（也几乎没有中间结果需要企业确认），并且计算步骤的编码由一个独立团队完成。两个团队合作计算所需的输入变量，以及如何使用和显示输出值，但除此之外，计算团队在很大程度上以预测的方法工作。

在计算团队的工作完成时，屏幕和报告中就会显示保险费率计算的输出。随后，企业用户提供关于外观和信息使用的反馈。这两个团队的工作同时进行，但几乎不需要进行交互。让两个团队彼此空间上的靠近可以更容易地检查开发进度，但它们主要还是独立的子项目

项目团队可能基于项目风险设计一个混合生命周期。

例如，某校园建设项目可能会有很多个建筑需要改善和建设。增量方法会将资源集中，使某些建筑比其他建筑更早完工，从而加快投资回报。众所周知，每个建筑的独自交付都能得益于该建筑独自采用预测型生命周期。

项目管理的目标是在给定的当前环境下尽可能以最好的方式创造商业价值。项目采用敏捷方法抑或预测方法，都无关紧要。要提出的问题是：我们怎样做才能最成功？

当团队创造价值时，是否需要反馈？如果需要，增量方法将会有所帮助。在探讨各种想法时。是否需要管理风险？如果需要，迭代方法或敏捷方法将会有所帮助。

当组织无法交付中间价值时，敏捷方法可能不是很有用。这样没有问题，但为了敏捷而敏捷并不是目标。关键在于，要选择一个对项目、风险、文化管理有用的生命周期或生命周期的组合。

敏捷关乎频繁向客户交付。而这种交付要给团队带来反馈。团队利用上述反馈规划并重新规划下一部分的工作。

3.1.11 混合生命周期作为过渡战略

许多团队无法在一夜之间切换到敏捷工作方式。对于那些已经习惯于预测型环境、并在其中获得成功的人士，敏捷技术的观感截然不同。组织越大，活动部件越多，转换需要的时间就越长。因此，计划一个渐进的过渡是有意义的

渐进的过渡涉及要增加更多的迭代技术，以便改进学习，加强团队和相关方的一致性。之后，还要考虑增加更多的增量技术，以加快发起人的价值和投资回报。（迭代：为了学习而改进；增量：为了速度和投资回报/商业价值而改进）上述各种方法的组合被视为一种混合方法

可以先在一个风险不大、具有中低程度不确定性的项目中尝试这些技术。在组织成功地使用混合方法后，再尝试更复杂的项目，这些项目需要增加更多的技术。这是一种根据组织的情况、特定的风险，以及团队适应并接受变革的就绪情况而调整的渐进混合过渡

3.2 混合敏捷方法

敏捷团队很少将其实践局限于一种敏捷方法。每个项目背景都有各自的独特性，比如团队成员技能和背景的不同组合；开发中的产品的各个组成部分；工作环境中的年龄、规模、关键性、复杂性、监管制约因素等

敏捷框架并不是针对团队定制的。为了定期交付价值，团队可能需要对实践进行裁剪。通常，团队都会实践各自特殊的敏捷组合，即便他们使用一个特定的框架作为起点也不例外
协调方法

裁剪敏捷框架的一个例子是，一个广泛使用的常见协调方法涉及到协调使用Scrum框架、看板方法、极限编程（XP）方法的要素。

Scrum为产品待办事项列表、产品负责人、Scrum主管、跨职能开发团队的使用提供指导，包括冲刺计划（Sprint）、每日例会、冲刺Sprint评审、冲刺Sprint回顾会议

看板面板帮助团队进一步提高效率，方法是将工作流可视化、使障碍更容易被察觉，通过调整在制品（WIP）限制来实现流程管理

受极限编程（XP）启发的工程实践，如：使用故事卡、持续集成、重构、自动化测试、测试驱动开发，将进一步提高敏捷团队的效力

总之，与孤立采用各种实践相比，协调这些不同来源的实践将产生更好的协同效果

3.3 影响裁剪的项目因素

有时，为了更好地配合，根据项目属性对方法进行裁剪

表中列出了一些要考虑的项目因素和裁剪方案（关于影响裁剪的因素的更多指导），请参见附录X2“影响裁剪的属性”

项目因素	裁剪方案
需求模型：稳定型或偶发型	许多团队发现，使用节奏（以定期时间盒的形式）能帮助他们演示、回顾、理解新任务此外，有些团队在接受更多任务时需要更多的灵活性团队可使用基于流的敏捷方法，利用节奏实现两全其美
团队经验水平所要求的过程改进速度	更频繁地回顾并选择改进措施
工作流往往被各种延误或障碍打断	考虑利用看板面板让工作可见，对工作过程的不同领域尝试限制，从而改进工作流
产品增量的质量不佳	考虑利用各种测试驱动开发的实践这种防错机制使缺陷难以不被发现
创建某个产品需要不止一个团队	从一个敏捷团队扩展到数个敏捷团队，同时只有轻微干扰首先要了解敏捷项目集管理或者正规扩展框架其次要精心制定一种适合项目背景的方法
项目团队成员缺乏使用敏捷方法的经验	考虑从培训成员敏捷思维模式和敏捷原则的基本原理开始如果团队决定使用特定的方法，如Scrum 或看板kanban，则要针对上述方法举办研讨会，让团队成员学习如何使用

4 实施敏捷：创建敏捷环境

4.1 从敏捷思维模式开始

使用敏捷方法管理项目，要求项目团队采用敏捷思维模式。

以下问题的答案将有助于制定实施策略：

项目团队如何以敏捷方式行动？
为了使下一交付周期受益，团队需要快速交付哪些成果并获得早起反馈？
团队如何以一种透明的方式行动？
为了专注于高优先级的项目，可以避免哪些工作？
仆人式领导对团队达成目标有何益处？

4.2 仆人式领导为团队赋权

敏捷方法强调，仆人式领导是一种为团队赋权的方法

仆人式领导是通过对团队服务来领导团队的实践，仆人式领导注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效

仆人式领导的作用是促进团队发展和定义敏捷

仆人式领导实践并传播敏捷

仆人式领导按照以下顺序从事项目工作：

目的：与团队一起定义“为什么” 或目的，以便他们能围绕项目目标进行合作互动。整个团队在项目层面，而不是在人员层面优化（各尽所能。因才分工，每个人做自己最拿手的工作）
人员：目标确立后，鼓励团队创造一个人人都能成功的环境。要求每个团队成员在项目工作中做出贡献
过程：不要计划遵循“完美”的敏捷过程，而要注重结果。如果跨职能团队能够常常交付完成的价值，并反思产品和过程，团队就是敏捷的。团队将其过程称作什么并不重要

以下仆人式领导的特征让项目领导变得更加敏捷，促进团队成功：

提升自我意识
倾听
为团队服务
帮助他人成长
引导与控制
促进安全、尊重、信任
促进他人精力和才智提升

仆人式领导并不是敏捷所独有的。但经过实践，仆人式领导通常能了解到仆人式领导是怎样融入敏捷思维模式和价值观的

领导在发展自身仆人式领导或促进技巧后，他们就更愿意成为敏捷践行者。因此，仆人式领导可以帮助他们的团队通过合作更快地交付价值

成功的敏捷团队信奉成长思维模式，团队成员自己能够学到新技能。如果团队和仆人式领导都相信自己能够学习，那么所有人的能力都能得到提高

4.2.1 仆人式领导的职责

仆人式领导通过管理关系，在团队内和组织中建立沟通与协作。这些关系可以帮助领导在组织中得心应手地为团队提供支持。这种支持有助于消除障碍，促进团队理顺过程。由于仆人式领导了解敏捷，在应用具体方法时践行敏捷，因而他们能帮助满足团队的需要

4.2.1.1 仆人式领导的促进作用

项目经理成为仆人式领导时，工作重点从“管理协调”转向“促进合作”。促进者将帮助每个人各尽所能地思考和工作。促进者鼓励团队参与、理解、并对团队输出共同承担责任。促进者帮助团队创建可接受的解决方案

仆人式领导促进团队内部和团队之间的合作与对话。例如，仆人式领导在团队内部和团队之间帮助发现瓶颈问题，并进行相应沟通。然后，团队将解决这些瓶颈问题

此外，促进者还鼓励大家通过交互式会议、非正式对话、知识共享展开写作。仆人式领导要通过成为公正的搭桥者和教练来做到这一点，而不是代替其他责任人做出决策

4.2.1.2 仆人式领导消除组织障碍

《敏捷宣言》的第一个价值观关乎个人与过程和工具的交互。对仆人式领导而言，更好的职责是认真审视那些阻碍团队敏捷或组织敏捷的过程，并努力使其合理化。例如，如果一个部门需要大量文档，仆人式领导的角色就能发挥作用，他们可以与部门合作审查所需的文档，就敏捷交付如何满足这些需求达成共识提供协助，并对所需的文档数量进行评估，从而使团队能够将时间更多地用于提供有价值的产品，而不是创建详尽的文档

仆人式领导还应该关注其他冗长的过程，这些过程往往造成瓶颈问题，阻碍团队或组织的敏捷性。可能需要处理的过程或部门的例子包括：财务部门、变更控制委员会、审计部门。仆人式领导可以与他人携手合作，共同质疑和审核他们的过程，为敏捷团队和领导提供支持。例如，对团队而言，每两周交付一个工作产品仅仅是为了让产品进入队列或过程，而冗长的发布过程却可能需要6周或更长时间，这样做有什么好处呢？太多的组织都有这些“瓶颈”过程，正是它们阻碍了团队快速交付有价值的产品或服务。仆人式领导有能力改变或消除这些组织障碍，为交付团队提供支持

4.2.1.3 仆人式领导为他人贡献铺路

在敏捷中，团队管理其工作过程及其工作产品。自我管理和自我组织适用于所有为组织和项目提供支持的人。仆人式领导为满足团队、项目、组织的需求而工作。仆人式领导可以在团队工作场所与团队一起工作，与管理层一起工作，使团队能够一次专注于一个项目，或者与产品负责人合作，与团队共同开发故事。有些仆人式领导与审计人员合作，改善监管环境中所需的过程；有些仆人式领导与财务部门合作，帮助组织向增量预算过渡。

仆人式领导注重为团队铺路，让团队尽其所能。仆人式领导影响项目，鼓励组织以不同方式思考

4.2.1.4 考虑这些仆人式领导的职责

仆人式领导可能有很多头衔，但最重要的还是他们所做的工作。以下是一些仆人式领导的职责示例：

教育相关方，使其了解为什么要敏捷以及如何敏捷。根据优先级说明商业价值的好处，对被赋权团队加强问责，提高工作效率，并通过更频繁的评审改进质量
通过指导、鼓励、帮助为团队提供支持。倡导团队成员的培训和职业发展。“我们通过支持的方式领导团队“，这句话说的是领导在发展团队成员时所扮演的角色。通过支持、鼓励和专业发展，团队成员将获得信心，承担更多的职责，并在组织中做出更大的贡献。仆人式领导的一个关键作用是，培养和发展团队成员，帮助他们超越自身当前的角色，即使团队将失去他们也在所不惜
通过技术项目管理活动，如量化风险分析来帮助团队。有时团队成员可能并不具备在某些角色或功能方面的知识或经验。对相关技能有更多接触或接受过相关培训的仆人式领导可以通过提供培训或开展这些活动来为团队提供支持
庆祝团队的成功，为团队与外部团队合作提供支持，并起到桥梁作用。创造相互欣赏的积极氛围，建立加强合作的良好意愿

人际关系技能与专业技能

除仆人式领导外，团队成员还要重视自身的人际关系技能和情商技能，而不仅仅是专业技能。团队中的每一个人都要努力展示更多的主动性、正直、情商、诚实、合作态度、谦逊、以不同方式沟通的意愿，才能促进整个团队的携手共进

团队需要上述技能，才能对项目方向的变化和技术产品的变更做出积极应对。只有每个人都能适应工作并彼此适应，整个团队才更有可能迈向成功

4.2.2 项目经理在敏捷环境中的角色

（~~项目经理~~->产品负责人->敏捷教练->开发团队）（跨职能的自组织团队，其实不需要项目经理，开发产品和产品负责人足以很好地完成工作）

项目经理在敏捷项目中的角色有些是未知的，原因是许多敏捷框架和方法都不涉及项目经理的角色。一些敏捷实践者认为，并不需要项目经理的角色，因为自组织团队承担了项目经理之前的职责。不过，务实的敏捷实践者和组织认识到，在许多情况下，项目经理都能够创造重要的价值。关键的区别在于，他们的角色和职责看起来有些不同

4.2.3 项目经理应用仆人式领导

第六版《PMBOK指南》将项目经理定义为“由执行组织委派，领导团队实现项目目标的个人”

许多项目经理已经习惯于作为项目的协调中心，负责跟踪团队的状态，并向组织中的其他成员反映。当项目被分解为孤立的功能时。这种方法没有问题。

然而，对于高不确定性项目，项目的复杂性是一个人所无法管理的。而跨职能团队既能协调自身的工作，还能与业务代表（产品负责人）开展合作

从事敏捷项目工作时，项目经理的角色就会从 “团队的中心” 转变成 “为团队和管理人员提供服务”。在敏捷环境中，项目经理充当仆人式领导，其工作重点转变为“引导需要帮助的人，促进团队的合作，保持与相关的需要一致”，作为仆人式领导，项目经理要鼓励将责任分配给团队成员，分配给那些掌握完成任务所需知识的人。

4.3 团队构成

《敏捷宣言》的价值观和原则的一个核心宗旨是“强调个人和交互的重要性”。敏捷优化了价值流，强调了向客户快速交付功能，而不是怎样“用”人

团队在考虑如何优化价值流时，以下好处是显而易见的：

人员更有可能合作
团队更快地完成有价值的工作
由于不从事多任务，也不必重新建立环境，团队减少了时间浪费

4.3.1 敏捷团队

敏捷团队注重快速开发产品，以便能获得反馈。在实践中，最有效的敏捷团队往往由 3 到 9 个成员组成。理想情况下，敏捷团队应该集中在一个团队工作场所工作（集中式，面对面工作），团队成员100%为专职成员（只专注当下工作）。敏捷团队鼓励自我管理团队，由团队成员决定谁执行下一阶段定义的范围内的工作。敏捷团队与仆人式领导一起茁壮成长。领导支持团队的工作方法

跨职能敏捷团队频繁创造功能性增量。这是因为团队集体对工作负责并共同拥有完成工作所需的所有必要技能。

无论整体的敏捷方法是什么，团队越是限制其在制品，团队成员就越有可能通过合作来加快整个团队的工作（倡导专注当前工作，不要多任务）。在成功的敏捷团队中，团队成员在工作中以各种方式开展合作（如结对、群集、群体开发），因而，他们会协同工作，而不会落入迷你瀑布的陷阱中。团队在给定时间解决所有的需求，然后试图完成所有的设计，继而又去完成所有的构建，就会发生迷你瀑布的情况（中间缺失了反馈）。使用这个场景，在构建中或构建后测试中的某一时刻，团队可能会意识到，原先的假设已经不再有效。这种情况下，团队解决所有的需求根本是在浪费时间。相反，当团队成员合作打造全部功能中的少量功能时，随着工作的推进和交付少量已完成的功能，他们也在不断学习

敏捷项目得益于项目团队结构，这种结构能改善团队内部和团队之间的合作。

下表展示了团队成员如何通过合作提高工作效率和促进创造性地解决问题

成功敏捷团队的属性
属性	目标
1. 专门人员	专心致志，提高工作效率少于 10 人（3～9人）
2. 跨职能团队成员	频繁开发与交付作为一个独立团队交付完成的价值为完成任务，整合所有工作活动从团队内部和外部（如产品负责人）提供反馈
3. 集中办公或有能力应对办公地点不同带来的任何挑战	改善沟通提高团队动力知识共享降低学习成本能够致力于相互合作
4. 由通才和专家组成的混合团队	专家提供专门技能，通才提供从事工作的灵活性团队具有专业能力，往往成为通才型专家，他们既有专长又有多种技能经验
5. 稳定的工作环境	彼此依赖，实现交付。（成员基本不发生变动）对工作方法相互认同简化团队成本核算（运转率）知识资本的保有和发展

4.3.2 敏捷的角色

敏捷团队中有三种常见的角色

跨职能团队成员
产品负责人
团队促进者

敏捷团队角色
角色	描述
跨职能团队成员	跨职能团队成员，包括：具有生产可行性产品所需的各种必要技能的团队成员在软件开发中，跨职能团队通常包括：设计人员、开发人员、测试人员、其他所需的角色跨职能开发团队包括：能够以常规节奏交付潜在可发布产品的专业人员跨职能团队至关重要，原因是他们能够在尽可能短的时间内，交付已完成的、高质量的、无外部依赖关系的任务
产品负责人（PO）	产品负责人指导产品的开发方向产品负责人根据商业价值对任务进行排序产品度责任与团队开展日常合作，提供产品反馈，为将要开发/交付的下一个功能设定方向这意味着产品负责人的任务不大，往往能一张索引卡就能描述产品负责人与相关方、客户、团队合作，定义产品开发方向通常，产品度责任拥有相关工作背景，会为决策提供丰富的专业知识技能有时，产品负责人需要请求有关人员提供帮助，如具有丰富的专业领域知识的架构师或具有丰富客户经验的产品经理产品负责人需要关于如何组织和管理整个团队工作流的培训敏捷开发中，产品负责人将为团队创建待办事项列表，或者与团队共同创建待办事项列表帮助团队了解怎样在不产生浪费的情况下交付最大的价值敏捷团队的一个关键成功因素是强烈的产品责任感如果不重视为客户创造最大价值，敏捷团队就可能创造一些不被理解的功能、或者价值不高的功能，因而会浪费精力
团队促进者	敏捷团队常见的第三个角色通常为团队促进者，也是一种仆人式领导上述角色也称为项目经理，Scrum主管、项目团队领导、团队教练、团队促进者所有敏捷团队在团队中都需要有仆人式领导人员需要时间来建立自己的仆人式领导技能，包括引导、指导、消除障碍技能起初，在内部培训能力不足时，很多组织会邀请外部敏捷教练提供帮助外部教练拥有经验优势，但缺点是：在客户组织关系中关系薄弱另一方面，内部教练虽然可能在本组织中拥有强大的人际关系，但他们却可能缺乏足够的经验让自己的工作卓有成效

4.3.3 通才型专家

“I”型人才和 “T”型人才

有些人在一个领域非常专业，但是，在这个领域之外，他却很少做出贡献。在敏捷领域，这种人才被称为“I”型人才。就像字母“I”一样，这种人有深度，但却缺乏广度。

“T”型人才，能够通过支持在一个领域补充自身的专业知识，他们在相关领域的技能虽有所欠缺，但拥有良好的合作技能。例如，一个人能够测试一些领域的产品，还能开发其他不同领域的产品，他就被认为是一个“T”型人才

T型人才，有一个明确的、公认的专业化的主要角色，同时还具有必要时与人协作、帮助他人的技能、多种才能及能力。这种协作减少了移交工作以及只有一个人能够完成特定工作所带来的制约因素

敏捷团队是跨职能的，但其人员往往不会一开始就做到这样。不过，许多成功的敏捷团队都由通才型专家组成，他们也称为“T”型人才

这意味着这些团队成员在具备一项擅长的专业化技能的同时，还拥有多种技能的工作经验，而不是单一的专业化。由于密切协作和自我组织，敏捷团队成员才能够敏捷开发并迅速完成工作，而这就需要使互相帮助成为常态。敏捷团队成员都要致力于培养这样的特质

一个人的能力大小无关紧要。如果给团队其他成员带来瓶颈问题，集中于某一个人的能力甚至是有害的。团队的目的是优化已完成的工作，并获得反馈

如果客户希望获得好的结果，如快速交付功能并且质量优良，那么团队就不能仅仅为了尽可能有效利用资源而构建专门的角色。团队的目标是提高过程效率，优化整个团队的产能。团队规模小，会促进团队的合作。产品负责人的工作是确保团队从事最高价值的工作

4.3.4 团队结构

许多行业的团队都会采用敏捷原则和实践。他们将人员组织到跨职能团队中，迭代开发工作产品

案例：

编写本实践指南的核心团队拥有不同的的背景，他们有些人代表项目管理协会，有些人代表敏捷联盟。他们是自组织团队，以增量方式来完成了这项工作。项目管理协会召集一个主题专家小组来检查工作，这使得团队能够在开发过程中纳入反馈并改进产品。然而，该核心团队并不代表典型的敏捷团队，因为其成员并不是100%专职从事这项工作。

有些组织已经能够建立集中办公的跨职能团队；还有组织有不同的情况。有些组织并不是所有团队成员都为集中办公，而是拥有分布式或分散式团队。

分布式团队可以在不同地点拥有多个跨职能团队。

分散式团队可能会让各团队成员分别在不同的地点工作，或在办公室，或在家里。

鉴于通信成本的增加，这些安排并非理想，但它们仍然是可行的

案例：

美国一家大型金融机构有一个项目，设有一组团队，其团队成员分别在美国东海岸和印度的几个地点工作。一开始，团队是一个大型分散式团队（用户体验设计人员、分析师、开发人员、测试人员），他们从事“追逐太阳”（追逐太阳的开发过程是一种每天结束时将工作移交给下一工作地点（可能相差很多时区）的方法，旨在为加快产品的开发）的开发实践，团队成员有些工作时间彼此重叠，以便进行工作交接。团队成员一起召开每日例会，利用网络摄像头让所有团队成员都能参加会议。在美国工作的关键角色（分析师、产品负责人、用户体验设计人员、开发人员）会先开始，回答其印度团队成员的问题，帮助他们消除障碍

随着产品规模越来越大，投入资金也越来越多，他们决定分成5个小团队。为此，他们决定在不同的地点建立有组织的、分布式团队。他们决定在各个地点建立由开发人员和测试人员组成的的、相互协作的跨职能团队

他们也有一组核心分析师，在美国的两个地点工作。他们与其他在美国工作的产品经理和产品负责人合作，然后再分别与各个团队合作。尽管他们安排了一些结构，将产品评审作为一个完整的项目进行，但是大多数其他活动都是在团队层面进行的，这对于每个团队而言是最有效的，因为他们能够自组织

4.3.5 专职小组成员

如果团队成员并非100%为团队专职工作，会有什么情况发生？

遗憾的是，这种情况虽然并不理想，但有时却无法避免

让一个人在团队中只投入25% 或 50%的能力，这带来的关键问题是，他们会进行多任务处理和任务切换。多任务处理会降低团队工作的产出，并影响团队预测交付能力的一致性

任务切换时，人员工作效率的损失在20%到40%之间。随着任务数量的增加，效率损失会呈指数级增长

当一个人在两个项目之间进行多任务切换时，他投入到每个项目上的精力并非各占 50% 。相反，由于存在任务切换成本，他在每个项目上的投入降低到20%到40%之间

人们在一心多用的的时候更容易犯错误。任务切换消耗工作记忆，人们在多任务处理时不太可能记住相应工作的背景

当团队中所有的人都被分配到一个项目时，他们能够作为一个团队持续协作，从而使每个人的工作更加有效

关于在敏捷环境中团队工作的更多提示，请参见表A1-1“项目管理过程组与知识领域”，请特别关注“项目资源管理”知识领域的有关过程

要点：

多任务处理减缓了整个团队的进展，因为团队成员要浪费时间切换环境和/或互相等待完成其他工作。当人员100%为团队专职工作时，团队最有可能最快地产出
不是所有团队都拥有自身需要的所有角色。例如：有些团队需要获得数据库管理员或研究分析师的支持。当一个团队临时委派专家时，重要的是确保每个人对此要有相同的期望。这位专家是100%专职分配给团队的吗？分配多长时间？对每个人（专家和团队）设定期望，阐明团队承诺交付的水平。分配兼职人员会给项目带来风险（因为兼职，不能100%投入）

案例：

由于编写本实践指南的核心团队成员无法100%全力投入团队的工作，他们的产出要比他们分工协作专职投入项目低得多。然而，从经济角度而言，协作是划算的。但是，即便他们分散工作，并将全部产能的一小部分投入项目，让他们集中并全力协作也是不可行的。因此，团队将分散工作识别为潜在的风险。团队通过使用协作工具来跟踪和监督他们的工作进度，并根据个人的能力来调整工作分配

4.3.6 团队工作场所

团队需要一个工作场所，他们可以一起工作，了解他们作为团队的状态，并进行协作。有些敏捷团队的所有成员都集中在一个房间里工作。有些团队拥有一个团队工作场所用于开例会以及张贴各种图表，但团队成员分别在各自的小隔间或办公室里独立工作

随着各公司迈向开放、协作的工作环境，组织也必须为需要不间断时间来思考和工作的员工创造安静的空间。因此，各公司纷纷设计各自的办公室，以平衡公共和社交区域（有时被称为“公共区”）与个人工作不被打扰的安静区域或私人区域

拥有在不同地点工作的成员时，团队会决定他们各自的工作场所有多少是虚拟的，多少是实际的。诸如文档共享、视频会议、其他虚拟协作工具等技术可以帮助人员实现远程协作

在不同地点工作的团队需要虚拟的工作空间。另外，要考虑让团队成员定期聚集一堂，以便建立信任，学习怎样开展合作。

分散式团队管理沟通的一些技术包括鱼缸窗口和远程结对

通过在团队分布的各个地点之间建立长期视频会议链接，创建一个鱼缸窗口。每天工作开始时，人们打开链接，工作结束时，关闭连接。通过这种方式，人员可以自然地看到彼此并进行互动，减少了身处不同地点所固有的协作滞后问题
通过使用虚拟会议工具来共享屏幕，包括语音和视频链接，建立远程结对。只要考虑了时区差异因素，这种方法几乎和面对面的结对一样有效

要点：

来自不同职能部门、拥有不同技能的人员共同组成团队。培养管理者和领导的敏捷思维模式，在敏捷开发早期就让他们参与其中

4.3.7 客服组织孤岛

组建敏捷团队的最好开端是构建一个拥有基本信任和安全的工作环境，以此确保所有团队成员都有平等的话语权，他们的意见都能被听到并的到考虑。这一点再加上构建敏捷思维模式，都是潜在的成功因素，在此基础上，所有其他挑战和风险都能够化解

孤岛组织往往给跨职能敏捷团队的组建带来重重障碍。需要构建跨职能团队的团队成员通常需要向不同的管理人员报告，管理人员会采用不同的标准衡量他们的绩效。管理人员需要关注的不是资源利用效率，而是过程效率（和基于团队的指标）

为克服组织孤岛问题，就要与团队成员的不同管理者合作，让他们为跨职能团队安排必要的专职人员。这样不仅能建立团队协调，而且能让组织看到怎样用人才能优化正在进行中的项目和产品

有关团队的更多信息，请参见附录X2"影响裁剪的属性"

要点：

作为敏捷项目领导，首先要把重点放在如何组建跨职能团队，让所有团队成员100%投入团队工作。即使这只是意味着关键团队成员（如开发人员和测试人员）每天一起工作和交流，但也是迈向正确敏捷方向的一步

5 实施敏捷：在敏捷环境中交付

5.1 项目章程和团队章程

每个项目都需要一个项目章程，这样项目团队就能了解项目之所以重要的原因、团队的前进方向、项目的目标。

不过，对于团队而言，仅有项目章程还不够。敏捷团队需要有团队规范以及对一起工作方式的理解。这种情况下，团队可能需要一个团队章程

制定章程的过程能帮助团队学习如何一起工作，怎样围绕项目协作

对于敏捷项目而言，团队至少需要项目愿景和目标，以及一组清晰的工作协议。敏捷项目章程要回答一下问题：

我们为什么要做这个项目？这是项目愿景
谁会从中受益？如何受益？这可能是项目愿景和/或项目目标的一部分
对此项目而言，达到哪些条件才意味着项目完成？这些是项目的发布标准
我们将怎样合作？这说明预期的工作流

仆人式领导可以促进章程的制定过程。团队可以通过一起工作实现协作，而制定项目章程是一种很好的开始工作的方式。此外，团队成员可能希望通过协作了解他们将如何一起工作

只要团队知道如何一起工作，制定章程就不需要一个正式的过程，有些团队可以从团队制定章程的过程中受益。下面是对团队成员制定章程的一些建议，可以将其作为制定团队社会契约的基础

团队价值观，例如可持续的开发速度和核心工作时间
工作协议，例如“就绪”如何定义，这是团队可以接受工作的前提；“完成”如何定义，这样团队才能一致地判断完整性；考虑时间盒；使用工作过程限制
基本规则，例如有关一个人在会议上发言的规定
团队规范，例如团队如何对待会议时间

仆人式领导可以与团队一起决定处理其他行为

请记住，团队的社会契约，即团队章程，将规定团队成员之间彼此互动的方式。团队章程的目标是创建一个敏捷的环境，在这个环境中，团队成员可以发挥他们作为团队的最大能力

5.2 常见敏捷实践

5.2.1 ～ 5.2.8 节描述了一些最常见的敏捷项目实践

5.2.1 回顾

回顾是最重要的一个实践，原因是回顾让团队学习、改进、调整其过程

回归可以帮助团队从之前的产品开发工作及其过程中学习。《敏捷宣言》背后的原则之一是：团队要定期反省如何能够做到更加有效，并相应地调整团队行为。

许多团队使用迭代，尤其是为期两周的迭代，因为迭代在最后会提示进行演示和回顾。不过，团队回顾并不需要迭代。团队成员可以决定在这些关键时刻进行回顾：

当团队完成一个发布或者加入一些功能时。这不一定是一个巨大的增量。它可以是任何发布，无论它有多小
自上次回顾以来，又过了几周时间
当团队出现问题时，以及团队协作完成工作不顺畅时候
当团队达到任何里程碑时

团队可以通过分配足够的时间学习受益，无论无论是在项目中间回顾，还是在项目结束时回顾。团队需要了解他们的工作产品和工作过程。例如，有些团队在完成工作时遇到困难。团队可以计划用充足的时间组织回顾，以此收集数据、处理数据、再决定之后要尝试的实验做法

首要的是，回顾并不是责备；回顾是让团队从以前的工作中学习并做出小的改进

回顾针对 定性的（人的感觉）和定量的（衡量指标）数据，然后利用这些数据找到根源，设计对策，并制订行动计划。项目团队可以采取许多行动事项来消除障碍

考虑限制行动事项的数量，使团队在即将进行的迭代或工作期间有能力改进。尝试一次改进太多的事情却没有完成其中任何一件，比计划完成较少的事情并成功完成要糟糕得多。然后，在时间允许的情况下，团队可以进行列表中的下一个改进。团队选择改进时，要决定如何衡量结果。然后，在下一段时间内要衡量结果，以验证每个改进成功与否

来自团队的一位促进者引导团队通过一个活动对所有改进事项的重要性进行排序。完成改进事项的排序后，团队下一次迭代选择合适的数量（或者在流程基础上增加工作）

5.2.2 待办事项列表编制

待办事项列表，是所有工作的有序列表，它以故事形式呈现给团队。工作开始之前，不需要为整个项目创建所有的故事，只需要了解第一个发布的主要内容正确即可，然后就可以为下一个迭代开发足够的项目

产品负责人（或者 产品负责人价值团队，包括产品经理和产品领域的相关产品负责人）可能会制作一个产品路线图，以显示预期的可交付成果序列。产品负责人根据团队的实际成果重新规划路线图（关于路线图的示例请参见附录X3“敏捷适用性筛选工具”）

5.2.3 待办事项列表的细化

在基于迭代的敏捷中，产品负责人往往在迭代中期的一次或多次会议中与团队合作（为了获得反馈，以便做出准确的交付成果），为即将进行的迭代准备一些故事。这些会议的目的是细化足够的故事，让团队了解故事内容，以及故事之间的相互关系

至于细化过程应该有多长时间，还没有达成共识。有一个连续区间：

基于流程的敏捷的即时细化。团队将下一张卡片从待办事项列表中拿出来讨论
许多基于迭代的敏捷团队在两周的迭代中用1小时的时间盒讨论。（团队选择一个迭代持续时间，为他们提供足够频繁的反馈）
基于迭代的敏捷团队的多次细化讨论。团队可以在陌生的产品、产品领域或问题领域使用这一技巧

细化会议上，产品负责人可以向团队介绍故事的创意，让团队了解故事中潜在的挑战或问题。如果产品负责人不确定依赖关系，还可以请求团队对相应功能进行刺探，以了解风险

产品负责人有很多方法处理待办事项列表的细化准备与会议，其中包括：

鼓励团队在开发人员、测试人员、业务分析人员和产品负责人三方面开展合作，一起讨论和撰写故事
把整个故事的概念呈现给团队。团队进行讨论，并根据需要将其细化为许多故事
与团队一起寻找各种方法探索和撰写故事，确保所有的故事都足够小，以便团队能源源不断地交付完成的工作。考虑每天至少完成一个故事

团队通常有一个目标，就是每周用不超过1小时的时间来为下一批工作细化故事。团队希望把时间尽可能花在工作上，而不是计划上。如果团队需要每周花1小时以上的时间来细化故事，那么，产品负责人可能会过度准备，或者团队可能缺乏评估和细化工作所需的一些关键技能

5.2.4 每日站会

团队成员利用每日站会对彼此做出小的承诺，发现问题，并确保团队工作顺利进行

为每日站会规定时间盒，不超过15分钟。团队以某种方式“过一下”看板或任务板，而团队中的任何人都可以主持站会

在基于迭代的敏捷中，每个人都轮流回答下列问题：

（基于迭代的敏捷，每日站会关注反馈）

上次站会以来我都完成了什么
从现在到下一次站会，我计划完成什么
我的障碍（或风险或问题）是什么

从这样的问题得出的答案能够让团队自我组织，并让团队成员为完成之前和整个迭代中承诺完成的工作承担彼此的责任

基于流程的敏捷有一种不同的方法，可以将注意力集中在团队的产出上。团队从右到左（越往右越接近最终成果）对看板进行评估。每日站会的问题包括：

（基于增量的敏捷，每日站会关注可交付成果和开发速度）

我们还需做些什么来推进这一工作？
有人在做看板上所没有的事情吗？
作为一个团队，我们需要完成什么？
工作流程是否存在瓶颈和障碍？

站会常见的一个反模式是，站会变成状态报告会议。传统上，在预测环境中工作的团队可能倾向于采用这种反模式（状态报告会议），因为他们习惯于报告状态。

另一个典型的反模式是，当问题变得明显时，团队才开始解决问题。站会是为了发现存在的问题，而不是解决它们。将问题条件到停车场区，然后创建另一个会议，它可以在站会之后立即召开并在会上解决问题

团队可以举办自己的站会。只要提现了团队工作需要的密切合作，进行顺利，站会变回非常有用。要针对团队何时需要站会、站会是否有效等问题有意识地做出决定

要点：

要鼓励团队成员主持会议而不是由项目经理或领导主持，以确保每日站会不会变成状态报告会议，而是作为团队进行自我管理和相互承诺的会议

5.2.5 展示/评审

当团队以用户故事的形式完成待定功能时，团队会定期展示工作产品。看过展示后，产品负责人接受或拒绝故事

在基于迭代的敏姐中，团队在迭代结束时展示所有已经完成的工作项。

在基于流程的敏捷中（基于增量），团队在需要时展示完成的工作，通常是当完成的功能累积到足以构成一个连贯组合时。

团队，包括产品负责人在内，都需要反馈来决定何时需要产品反馈

一般的指导方针是，每两周至少展示一次团队的工作产品。这种频率对于大多数团队来说是足够的，这样，团队成员就可以得到反馈，防止他们朝着错误的方向前进。这种频繁也足够频繁，让团队可以保持产品开发足够清晰，按照自己希望或需要的频率构建一个完整的产品

使项目敏捷的一个基本要素是频繁地交付产品。一个没有展示或发布的团队，其学习的速度不会快，，并且很可能并未采用敏捷技术。团队可能需要额外的引导来保证频繁的交付

5.2.6 规划基于迭代的敏捷

不同团队的能力各不相同。不同产品负责人的典型故事大小也各不相同。团队应考虑自身故事大小，避免提交更多的故事，而超出团队在一个迭代中工作的能力

产品负责人了解，当人员不可用时（例如，公共假期、度假期间、阻止人员参加下一组工作的任何事情），团队能力降低。团队将无法完成与前一期相同的工作量。在能力降低的情况下，团队只会计划相应能力能够完成的工作

团队估算能够完成的工作，这也是一种能力的衡量（示例参见4.10节）。团队不能100%确定自己能交付什么，因为他们无法知道意外情况。当产品负责人拆分故事使其变小时，团队看到的是产品的完成进度，团队就会知道他们将来能够做什么

敏捷团队在一个工作块中不会只计划一次。相反，敏捷团队会开始计划一点，交付、学习，然后在一个持续的循环中重新规划更多的东西。

要点：

将团队的注意力吸引到反模式，并帮助团队发现如何改进站会

5.2.7 帮助团队交付价值的执行实践

如果团队不重视质量，很快就会无法快速发布任何东西（一直在修bug、或者产品不受市场喜欢被迫停止）

下面的技术实践中，很多都来自于极限编程，他们可以帮助团队以最快的速度交付：

【持续集成】
- 无论产品如何，都要频繁地将工作集成到整体中，然后再进行重新测试，以确定整个产品仍然按照预期工作
【在不同层面测试】
- 对端到端信息，使用系统级测试
- 对构建块，使用单元测试
- 在两者之间，了解是否需要进行集成测试，以及在何处进行测试
- 团队发现冒烟测试有助于测试工作产品是否良好
- 团队发现，决定何时以及对哪些产品运行回归测试，可以帮助他们在维护产品质量的同时，良好地构建性能
- 敏捷团队非常偏爱自动化测试，因此他们借此构建和保持交付的势头
【验收测试驱动开发 ATDD （Acceptance Test Driven Development）】
- 在ATDD中，整个团队聚集一堂讨论工作产品的验收标准。然后，团队创建测试，这让团队能够编写足够的代码，进行自动化测试，满足标准要求。
- 对于非软件项目，要考虑怎样在团队完成大量价值时对工作进行测试
【测试驱动开发TDD（Test Driven Development）、行为驱动开发BDD（Behavior-Driven Development）】
- 在编写/创建产品之前编写自动化测试，实际上可以帮助人员设计产品，防范产品错误。
- 对于非软件项目，要考虑如何通过“测试驱动”团队的设计。
- 硬件和机械类项目，经常使用模拟进行设计的中间测试
【刺探（时间盒研究或实验）】
- 刺探对学习很有用，可以在诸如评估、验收标准定义、通过产品了解用户行为的流程中使用
- 在团队需要学习一些关键技术或功能要素时，刺探会很有帮助

5.2.8 迭代和增量如何帮助交付工作产品

迭代可以帮助团队为交付和多种反馈创建一个节奏。

团队会为交付和反馈创建增量

交付的第一部分是一次演示。团队会收到关于产品的外观和运行方式的反馈

团队成员回顾如何检查和调整有关过程以取得成功

演示或评审，是敏捷项目流程的必要组成部分。为团队的交付节奏安排适当的演示

5.3 解决敏捷项目的挑战

出于解决具有高变化率、不确定性、复杂性、的项目相关问题的需要，敏捷方法应运而生。由于这些原因，敏捷方法包含了各种各样的工具和技术，用于处理预测法中出现的问题。

要点：

团队应该经常为反馈进行演示，并展示进度。鼓励PMO（项目管理办公室）和其他感兴趣的人观看演示，以便决定项目组合的人能够看到实际的进展。

敏捷的痛点和解决痛点的可能性
痛点	解决痛点的可能性
团队目标或任务，不明确	敏捷章程中关于目标的部分：愿景、使命、使命测试
团队工作协议，不明确	敏捷章程中关于一致性的部分：价值观、原则、工作协议
团队环境，不明确	敏捷章程中关于环境的部分：边界、承诺资产、前瞻性分析
需求，不明确	帮助发起人和相关方制定产品愿景考虑使用实例化需求、用户故事地图、影响地图来构建产品路线图让团队和产品负责人一起来明确需求的期望和价值逐步将路线图分解为具有更少具体需求的待办事项列表
用户体验，不佳	开大团队的用户体验设计实践应在早期就让用户经常参与
估算，不准确	通过分解故事来让故事变小让整个团队使用相对估算进行估算考虑通过敏捷建模或刺探来理解故事
工作分配、工作进展，不明确	帮助团队认识到自我管理工作考虑用看板面板查看工作流程考虑利用每日站会，根据看板面板查看工作进展
团队面临障碍	仆人式领导能帮助消除这些障碍如果团队不知道他们都有哪些可选方案，就要考虑聘请教练有时，团队或仆人式领导无法消除障碍，团队就需要上报故事
由于产品待办事项列表不够完善，导致工作延误 / 超时	产品负责人和团队一起研讨故事为故事创建一个准备就绪的定义考虑分拆故事以使用更小的故事
缺陷	考虑对特定环境有效的技术实践它们可能是：结对工作、产品集体负责制、普适测试（测试驱动方法、自动化测试方法）、稳健的完成的定义
工作未完成	团队确定故事完成的定义包括验收标准在内为项目补充发布标准
技术债务（代码质量降级）	重构、敏捷建模、普适测试、自动化代码质量分析、完成的定义
产品复杂性过高	无论是软件项目还是非软件项目都要常常鼓励团队思考：最简单的有效方法是什么？并应用“简洁，尽最大可能减少不必要的工作，这是一门艺术”的敏捷原则这样做将有助于降低复杂性
团队合作过程进展缓慢或没有改善	在每次回顾中，选择的改进项目不要超过三个让仆人式领导帮助团队学习怎样整合这些待改进项
前期工作过多导致返工	不要做过多的前期工作，而要考虑让团队通过刺探来学习另外，在项目开始时衡量在制品（WIP），看看哪些部分团队并不需要设计，只需要交付价值缩短迭代，并创建一个稳健的完成的定义
错误的开始，前功尽弃	让产品负责人成为团队不可分割的一部分
产品待办事项列表杂乱无序	按价值排序，并考虑延迟成本按持续时间（CD3）和其他价值模型划分
仓促 / 等待，不均匀的工作流程	计划要对应团队的能力，而不是超出能力所及要求人员停止多任务，为一个团队专注工作请团队利用结对、群集、群体开发、等等方法，平衡整个团队的能力
相关方要求无法满足	仆人式领导与这个相关方（可能是产品负责人）一起工作
意想不到或不可预见的延误	让团队更频繁地检查使用看板面板检查工作流和在制品（WIP）限制了解需求对团队或产品的影响在障碍板上跟踪障碍和障碍消除情况
孤立的团队，而不是跨职能团队	让项目人员作为跨职能团队自我组织使用仆人式领导技巧帮助管理人员理解为什么敏捷需要跨职能团队

5.4 敏捷项目的衡量指标

过渡到敏捷，意味着要是用不同的衡量指标

使用敏捷，意味着要对审视团队和管理层都很重要的新指标

这些衡量指标很重要，因为它们关注的是客户价值

状态报告的一个问题是，团队预测完成或使用交通灯来描述项目的能力。例如，项目领导将项目描述为“90%完成”。此时，团队正试图将一个个片段集成到一个产品中。团队发现，有缺少的需求或者意外的出现，或是产品没有按照他们的想法集成

项目只是完成了一半，而交通灯状态报告并未反映项目真实状态。项目团队往往认识到，他们还需要同样长的时间才能完成项目的剩余部分。太多的项目存在这种情况：由于发现了问题，团队才认识到，自己最多只完成了10%的工作

预测型衡量指标的问题在于，它们往往并不反映真实的情况。往往直到发布日期前1个月，项目状态绿灯一直是亮的；这种项目有时被称为“西瓜项目（外面绿，里面红）”。项目状态灯，经常会变成红色，似乎没有任何警告，因为直到发布日期前1个月，才会得到关于项目的经验数据

敏捷项目的衡量指标包含有意义的信息，这些信息提供了历史记录，因为敏捷项目要定期交付价值（完成的工作）。项目团队可以利用这些数据改进预测和决策

替代衡量指标（如完成百分比）不如经验指标（如完成的工作）更有用。有关价值管理的更多信息，请参见4.10节。敏捷帮助团队发现问题和难题，以便团队能够诊断和解决问题

除了定量指标之外，团队还可以考虑收集定性衡量指标。其中一些定性衡量指标侧重于团队选择的实践，评估团队使用这些实践的情况，例如，对交付功能的业务满意度、团队的士气、团队希望跟踪的任何东西等都是定性衡量指标

5.4.1 敏捷团队的衡量结果

敏捷倾向于使用基于经验和价值的衡量指标，而不是预测型衡量指标。敏捷衡量团队所交付的成果，而不是团队预测将交付的成果

对于一个习惯于掌握项目基准、估算的挣值、投资回报率（ROI）的团队，可能会对实施一个项目而不是管理一个基准感到茫然。敏捷是基于对客户有可见价值的工作产品

基准通常是尝试预测的产物。在敏捷中，团队的估算最多限于未来几周时间（即：只估算下一个迭代的工作）。在敏捷中，如果团队工作的可变性不高，如果团队成员没有从事多任务，则团队的能力就会变得稳定。这样才能对未来几周做出更好的预测

完成迭代或流程中的工作后，团队就可以进行重新规划。敏捷并不能创造出更多的工作能力。然而，有证据表明，工作量越少，人员就越有可能交付

与其他知识型工作一样，软件产品开发关乎在交付价值的同时进行学习。在项目的设计部分，硬件开发和机械开发是相似的。学习的过程是通过实验来实现的，项目设计能交付微小的价值增量，并获得对目前已完成工作的反馈。其他许多产品的开发项目也包括学习

项目发起人，通常想知道项目什么时候能够完成。一旦团队建立了稳定的速度（每个迭代的故事或故事点的平均数量）或平均周期时间，团队就能够预测项目将花费多长时间

举例来说，如果团队平均每个迭代有50个故事点，而团队估算还剩下大约500个点，于是，团队估算，还剩下大约10个迭代。随着产品负责人对剩余的故事进行细化，团队对估算进行细化，项目估算虽然可能有升有降，但团队却能提供一个估算。

如果团队平均完成每个故事的周期为3天，还有30个故事要完成，那么团队将需要90个剩余工作日，大约4-5个月

用飓风图反映估算的可变性，也可使用发起人能够理解的其他一些可变性衡量方法

由于学习是项目的重要组成部分，因而，团队需要在平衡不确定性的同时为客户提供价值。团队要规划项目要完成的下一个小部分。

团队报告经验数据，并重新规划其他小的的增量，以此管理项目的不确定性。

基于迭代的敏捷团队的衡量标准

某些基于迭代的项目使用燃尽图查看项目随时间的进展情况。

图5-1，显示了一个燃尽图的例子，其中，团队计划交付37个故事点。故事点怼需求或故事的相关工作、风险、复杂性进行评估。

许多敏捷团队使用故事点估算工作量。

燃尽图中的虚线表示计划。

图5-1中，团队可以看到，在第3天他们面临交付的风险

某些项目团队更喜欢用燃起图（显示已完成的工作）。如图5-2所示的燃起图中的数据与图5-1相同

图5-1和图5-2都是基于相同的数据，但分别以两种不同的方式显示。团队可以选择如何查看他们的数据

看到在迭代中尚未完成的工作时，团队可能会变得沮丧，并且可能因为急于完成工作而不满足验收标准。不过，团队可能有很多理由不按预期完成工作。燃尽图显示了团队成员的多任务处理、过于庞大的故事或团队成员缺勤的效果

特别是对新建的敏捷团队，燃起图将显示迭代过程中范围内的变化。利用燃起图，团队能查看他们已经完成的工作，这将有助于团队进行下一项工作

无论使用燃尽图还是燃起图，团队都能看到在迭代过程中完成的的工作。在迭代结束时，他们可能会根据自己在这个迭代中完成工作的能力（多少故事或故事点）来建立他们下一个迭代的能力衡量指标。这样，产品负责人与团队一起重新规划，团队就更有可能在下一个迭代中成功交付

速度，即本次迭代中实际完成功能的故事点大小的总和，让团队得以通过观察历史表现来更准确地规划下阶段的能力

要点：

团队可能会发现，可能需要四到八次迭代才能达到稳定的速度。团队需要从每个迭代中获得反馈，了解他们的工作量情况以及该如何改进

基于流程的敏捷团队的衡量指标：

基于流程（增量：流程最后一环是交付）的敏捷团队使用不同的衡量指标：交付周期（交付一个工作项目花费的总时间，从项目添加到看板直至项目完成）、周期时间（处理一个工作项目所需的时间）、响应时间（一个工作项目等待工作开始的时间）。团队通过衡量周期时间发现瓶颈和延迟问题，问题不仅限于团队内部

看板面板的好处：任务直接在面板上显示，可以清晰的看出瓶颈和问题。因为增量式敏捷开发，是多次交付最小可行产品，所以需要时刻关注任务的各种情况和状态，看板面板更加适合

燃尽图、燃起图：因为没有任务显示，所以只能看出来已完成任务的多少。由于迭代型敏捷开发，只交付一次，所以只需要关注任务剩余量（距离全部完成的剩余时间）。燃起图、燃尽图，信息比较少的图表，更加适合

看板面板示例如图5-3所示

就绪：此列有限制，可以随时将一些内容换成其他内容

周期时间：从开始任务到完成任务的时间

交付给客户：交付周期（从写在看板上直至交付的时间），由于就绪一列中各项的顺序可以变更，因而这是不可预测的

交付周期有助于理解从第一次查看特定功能到向客户发布该功能所需的周期时间。在制品（WIP）限制位于各列顶部（此处在框中显示），让团队了解如何从看板上提取工作。达到WIP限制后，团队就不能将工作从左边提取到下一列。此时，团队就要从最右边的列中提取工作，并提出问题：“作为一个团队，我们应该怎样做才能将这项工作移到下一列中？”

每个功能都是独一无二的，所以每个功能的生命周期时间也是独一无二的。不过，产品负责人可能会注意到，较小的功能周期时间也较短。产品负责人希望看到产出，因此产品负责人创建较小的功能，或者与团队合作创建

燃起图、燃尽图（能力衡量指标）和交付周期、周期时间（可预测的衡量指标）对于实时测量非常有用。它们可帮助团队了解他们共有多少工作，以及团队是否能按时完成工作

故事点衡量与已完成的故事（燃起图；故事点的衡量）或功能的衡量（增量-看板）有所不同。有些团队试图在没有完成实际功能或故事的情况下衡量故事点。团队仅衡量故事点时，衡量的是能力，而不是已完成的工作，这违背了“可用的软件（或者，如果不是软件，则是其他的产品）是衡量进度的主要指标”的原则

每个团队都有自己的能力。在使用故事点（燃起图、燃尽图）时，团队要认识到：在给定时间内能够完成的故事点数量对一个团队而言是唯一的（每个人的完成时间不一样，所以这里说“唯一”）

要点：

当团队依赖于外部人员或团队时，衡量周期时间可了解团队完成工作所需的时间。团队完成工作之后，衡量交付时间可了解外部依赖关系。团队还可以测量反应时间（响应时间），从准备就绪到第一列的时间，了解平均需要多长时间才能对新请求做出响应

根据自身的指标单位进行衡量，团队就能更好地评估和估算自己的工作，并最终交付。

相对估算的缺点是，无法比较各个团队或者在团队之间增加速度（因为每个团队成员的能力是不一样的，所以相对估算时与其他成员的指标比较是无意义的）（相对估算，比较适合与自身的指标进行比较）

团队可以在一个功能燃起图 / 燃尽图和一个产品待办事项列表中衡量已完成的工作。这些图表提供了随时间变化的完成趋势。如图5-4所示

功能燃起图 / 燃尽图可显示项目期间需求的发展。

【完成的功能数量线】显示团队以正常速度完成功能。

【功能总数】显示了项目的总功能随时间的变化。

【剩余的功能数量线】显示功能完成速度的变化

每次在项目中添加功能时，燃尽线都会有改变

在敏捷中的挣值，是基于已完成的功能，如图5-5所示。产品待办事项列表燃起图显示已完成的工作与区间里程碑或迭代中的预期工作总量的比较

一个团队一次只能完成一个故事。为了完成一个包含多个故事的大功能，团队会有待完成的剩余故事，并且除非拥有更多的时间，否则可能无法完成整个功能。团队可以用一个产品待办事项列表燃起图来显示已完成的价值，如图5-5所示

如果一个团队需要衡量挣值，可以考虑使用燃起图，以图5-6为例：请注意，左边y轴代表了故事点的范围，右边y轴代表项目的支出

传统的 挣值管理（EVM） 衡量指标，如 进度绩效指标（SPI） 和 成本绩效指标（CPI）可以很容易地转换为敏捷术语。

例如，如果团队计划在一次迭代中完成30个故事点，但是只完成了25个，那么SPI（进度绩效指标）是25/30 或者 0.83（该团队的工作速度只有计划的83%）。同样，CPI是迄今为止的劳动价值（已完成的功能值）除以实际的成本，如图5-6所示，$2.2M / $2.8M = 0.79，这就意味着，与计划相比，仅能得到79美分的结果（当然，这假定了预测仍然正确）

图5-7中所示的累积流图显示了看板上进行中的工作。如果一个团队有许多等待测试的故事，测试团队将会扩大。累计工作可一目了然

团队在处理累积工作方面有困难：团队有进行中的工作，而不是已完成的工作。如果团队有大量进行中的工作，就会延迟整体功能的交付。团队的交付时间越长，在相同时间内有更多功能，团队的压力就越大

6 关于项目敏捷性的组织考虑因素

如果组织能够做出相应调整，则可以提高项目敏捷性的效率和适应性

每个项目都存在于组织环境下。文化、结构、政策可能会影响到所有项目的方向和成果。这些动态变化可能会对项目领导提出挑战

项目领导可能无法根据自己的意愿来改变组织动态文化，但可以有技巧地引导这些动态变化

本章探讨了组织以及（在某些情况下）项目环境影响项目的方式。领导可以通过探讨变革方案来提高项目成功率

6.1 组织变革管理

组织变革管理一节，涵盖了会影响敏捷应用情况的技能和技术

PMI出版物《组织变革管理实践指南》介绍了成功引入有意义变革的全面整体性方法。该指南提供的建议包括：

说明变革动态变化的模型
实现变革的框架
项目、项目集、项目组合层面的变革管理实践的应用

6.1.1、6.1.2节探讨了特定敏捷环境中变革管理的考虑事项

图6-1显示了“敏捷方法、变革管理”这两个主题之间的关系

6.1.1 变革管理驱动因素

所有项目都涉及到变革。但是，有两种主要因素会进一步激励敏捷环境中变革管理实践的应用：

【与加快交付相关的变革】敏捷方法强调频繁并尽早交付项目输出。但是，接收组织可能尚未做好加速纳入这些输出的充分准备。加速交付将会考验组织适应该交付的能力。成功发现和交付项目功能是不够的。如果组织抗拒项目输出，则会延迟目标投资回报。客户接受并支持项目输出在敏捷环境中日益盛行
【与敏捷方法相关的变革】组织在刚开始采用敏捷方法时也会经历更高程度的变革。高级别协作可能需要团队、部门、供应商之间更频繁地交流。将工作分解到迭代原型时会涉及到不利的返工。领导应考虑利用变革管理技术来解决过渡到敏捷方法时所遇到的阻碍

6.1.2 变革就绪情况

组织在开始采用敏捷方法时应了解这些方法与其当前方法之间的相对兼容性。某些组织的特征可能更容易支持跨部门协作、持续学习、内部过程演变等敏捷原则。这些变革友好型特征的示例包括：

1.管理层的变革意愿（管理层支持，才容易落实变革）
2.组织在员工认知、审核、评估方式上做出改变的意愿（组织自身支持变革，也要组织员工积极参与到变革中）
3.集中或分散项目、项目集、项目组合管理职能（集中或分散，主要目的是为了让敏捷尽快得到适应）
4.专注于短期预算和指标，而不是长期目标（因为敏捷的原则是：频繁地尽早交付最小可行性产品）
5.人才管理成熟度和能力

相反，还有一些机构特征可能会成为实现组织敏捷性相关变革的障碍。这些特征示例包括：

1.工作被分解为部门孤岛，从而创造出阻碍加快交付的依赖关系，而不是构建在能力中心指导下的跨职能团队（能力中心指导下的跨职能团队：说明是团队的核心，说明产出被重视，说明跨职能的互动比较多）
2.采购策略基于短期定价策略，而不是长期能力（敏捷价值观和原则是：可用的软件）
3.奖励领导的依据是本地效率，而不是端到端项目交付或整体优化情况（就组织而言）
4.员工属于特定领域人才，实现技能多元化的工具或激励有限，不重视培养 T型专家人才
5.分散化项目组合，使员工同时分配到过多的项目，而无法专注于单个项目

组织审查和修改这些实践的意愿程度将决定采用敏捷方法的速度和效率。但是，为了解决这些敏捷组织障碍，项目领导可以尝试多种方法来加速文化兼容性：

1.积极明确的管理层支持
2.变革管理实践，包括沟通和引导
3.逐个项目应用敏捷实践
4.向团队增量地引入敏捷实践
5.通过采取适用的敏捷技术和实践示范引导

6.2 组织文化

组织文化，就是组织的DNA -- 组织的核心标识

文化始终影响敏捷方法的使用

组织文化一直在连续运转，从高预测型计划到一切皆为实验的精益创业阶段，均有体现。

尽管敏捷方法与精益创业文化相当吻合，高预测型组织可以鼓励实证的衡量指标、小型试验和不断学习以便向敏捷方向转变

“文化能把战略当早餐吃” Culture eats strategy for breakfast.【彼得·德鲁克Peter Drucker】

这句名言强调了人的承诺和热情对于一份事业的重要性。无论您在团队中实施何种策略或计划，其成功与否将会受到实施该计划的人员的控制。如果推动策略的人员对变革没有热情，甚至漠视工作和组织，则您可能没有机会实施变革

吃下去的战略是什么，文化就容易是什么。

6.2.1 创建安全环境

组织文化难以改变，但组织中最重要的文化规范 -- 愿意尝试任何新方法或技术 -- 将有利于构建安全的工作环境

只有在安全、诚实、透明的环境中，团队成员和领导才可以真正反思其成功，确保项目持续进步，或者应用从失败项目中所吸取到的教训，不再重蹈覆辙

6.2.2 评估文化

每个项目都会遇到相关方意愿相左的棘手情况。

团队如何在不影响质量的情况下取得快速进展？

团队如何在保留灵活性的同时确保时效性？

更重要的是，团队如何满足客户需求？

项目领导可能感觉其职责就是满足各个相关方的期望；但是在面对选择时，通常需要根据组织业务环境的文化和要求来确定优先级。例如，移动电信项目偏重于速度，而政府项目可能偏重于大众化和稳定性

要引导这些动态变化，项目领导应花费时间去评估组织通常所关注的重点。图6-2显示了有关如何评估的示例。在例子中，项目领导发起了与相关方、团队成员、高层管理的对话以讨论组织优先级。这些优先级根据 滑动标尺 在这两个极端之间的位置来进行记录，然后再利用该结果去找到最适合这些优先级的敏捷技术

有一些模型，可用于评估这些动态变化；但是，采取何种模型或方法并不重要，关键是让项目领导了解其环境的驱动因素。了解某组织需要满足的组织与行业需求后，才能选择合适的对话、权衡，尤其是技术

6.3 采购和合同

如本实践指南中前面所述，《敏捷宣言》认为“客户协作高于合同协商”。

许多项目失败，源于客户供应商关系破裂。

如果合同相关方怀有非赢即输的想法，通常会给项目带来更多的风险。（心态要好，要积极拥抱变化，积极复盘成功和失败，思考原因，并制定可借鉴和需优化的方向，并严格落实执行。共担风险+共享奖励，形成迭代精进）

协作方法提倡 共担项目风险和共享项目奖励 的关系（同甘共苦），实现所有方共赢。设计这种动态特性的合同签署技术包括：

1.【多层结构】除了在单层文档中正式说明整个合同关系，项目方可以通过在不同文档中说明不同方面来提高灵活性。通常固定项目（如担保、仲裁）可以锁定在主协议中。同时，所有方将可能会变更的其他项目（如服务价格、产品说明）列在服务明细表中。合同主要服务协议中注明这些服务参考。（这样做的目的，也可以帮助动态修改时方便）最后，范围、进度计划、预算等更多动态变化项目可以列在轻量级说明书中。通过将合同中的更多变化因素隔离到单独的文档中，将会简化修改工作 并 提高灵活性
2.【强调价值交付】许多供应商关系是由专注于中间人为因素的固定里程碑或 “阶段关口” 控制的，而不是由增量业务价值的完全可交付成果 控制的。通常，这些控制会限制利用反馈来改进产品，与之相反的是，里程碑和支付项目可以根据价值驱动可交付成果来构建，以增强项目敏捷性
3.【总价增量】项目可以将范围分解为总价微型可交付成果（如用户故事），而不是将整个项目范围和预算锁定在单个协议中。对于客户而言，这可以更好地控制资金流向。对于供应商而言，这可以限制对单个功能或可交付成果的过多承诺所带来的财务风险。
4.【固定时间和材料】客户在采用传统的时间和材料方法时会产生不必要的风险。一种替代方法是将整体预算限制为固定数量。这就允许客户在最初未计划的项目中纳入新的观点和创新。（固定预算，倒逼选择最有价值的内容进行开发）。如果客户需要纳入新的观点，则必须管理给定能力，用新的工作来替代原有工作。应密切监控工作，防止所分配的时间超过其限制。此外，在认为有用的情况下，还可以在最大预算中规划额外应急时间
5.【累进的时间和材料】另一种替代方法是共担财务风险法。在敏捷方法中，质量标准是已完成工作的一部分。因此，如果在合同期限之前交付，则可对供应商的高效率进行奖励。相反，如果供应商延迟交付，则将扣除一定费用
6.【提前取消方案】如果敏捷供应商在仅完成一半范围时便可交付足够的价值，且客户不再需要另外一半范围，则不必支付这部分费用。但合同中可以规定客户应为项目剩余部分支付一定的取消费用。因为不再需要这些服务，客户可以限制预算敞口，而供应商也可获得可观的的收入。（刺探开发，甲方先付全款，如果供应商交付的部分成果，可以满足全部价值，则后面的开发就不需要了，供应商支付甲方合同内约定的款项）
7.【动态范围方案】对于具有固定预算的合同，供应商可为客户提供在项目特定点改变项目范围的方案。客户可调整功能以适应该能力。这样客户便可利用创新机会，同时限制供应商的过度承诺风险
8.【团队扩充】大多数协作合同方法是将供应商服务直接嵌入客户组织中。通过资助团队而不是特定范围，可以保留客户自行确定需要完成工作这方面策略的权力。（比如：人力外包）
9.【支持全方位供应商】为了分化风险，客户可能需要采取多供应商策略。但是，这样签署合同的结果是，每家供应商只能负责一项工作，这就会产生许多依赖关系，阻碍可行服务或产品的交付。（关系越多，越复杂）相反，要强调提供全面价值的合约（这与已完成独立功能集中的观点相符）

可以创建敏捷合同。敏捷是在协作和信任的共同基础上建立的。

如果有供应商能够尽早频繁地交付价值，则有助于实现这一点。
如果客户能够提供及时反馈，则有助于实现这一点

要点：

文化 VS 结构

有些人坚持在开始各种文化转型前，构建新的组织结构。

还有些人持相反意见，认为：新型组织结构只是表面的调整，只有 集体文化 朝着有意义的方向转变才是根本。

实际上，任何一方都孤掌难鸣。

如果要实现敏捷，项目领导应同时考虑其组织中这两个方面的当前和未来状态

6.4 商业实践

在需求生产时，组织创建新能力的意愿和能力 即组织敏捷性的标志（有创新意愿，还要有实现意愿的能力。动起来）。对于关注敏捷及敏捷所提供结果的组织而言，这些不必是颠覆性的变革，破坏性较小。透明和开放协作 至关重要

在跨职能团队交付价值时，团队和个人可能会遇到组织多种支持职能方面的问题

如果团队定期交付价值，财务部门可能有机会以不同的方式获得产品收益。如果团队与其他组织签署了合同，采购部门可能需要变更这些合同，以帮助其他组织频繁地交付价值并与团队保持同步（即：不需要等合同上的日期，压着已交付的价值。可以通过修改合同，让其他组织可以尽早的参与）

团队开始以团结协作的方式展开工作后，将会对内部管理策略提出挑战。人力资源可能注意到个人激励不足，而经理可能会在自组织员工的绩效评估方面绞尽脑汁。在各种情况下都有机会评审现有实践对敏捷工作方式的支持程度（集思广益）。

当组织发展到更高敏捷阶段时，其他业务部门将有必要更改其交互方式并履行自己的职责。现在应拥护对组织其他领域有益的变更，以此来提高整个组织的效率

6.5 多团队协作和依赖关系（扩展）

多个项目之间会产生依赖关系，即使不在给定项目集中进行管理。因此有必要了解敏捷工作在现有项目集和项目组合管理环境下的工作方式

6.5.1 框架

大多数流行敏捷方法（如 Scrum、XP极限编程）的指导：关注于单个小型且通常是集中办公的跨职能团队活动。这对于需要单个团队的工作非常有用，但对于需要在一个项目集或项目组合中进行多个敏捷团队协作的举措，却显得捉襟见肘

目前已出现许多框架（如大规模敏捷框架、大规模敏捷开发和规范敏捷）和方法（例如 Scrum of Scrums）来应对这种情况。有关这些框架和方法的更多详细信息，请参见附录A3

6.5.2 考虑事项

有多种扩展工作的方式。团队可能需要将多个敏捷项目工作扩展到单个敏捷项目集中。或者，组织可以设计出支持整个项目组合中不同敏捷方法的结构

例如，可以从小项目着手，然后尽快了解组织环境中比较适合的方式。即使一切还未完全转换到敏捷方法，团队仍可获得成功

无论采用哪种方法，关键成功因素是健康的敏捷团队。如果单个团队采取敏捷方法无法获得成功，则勿尝试将其扩展到更大范围；而要先行解决阻止团队敏捷工作的组织障碍

大规模敏捷项目的目标是协调不同团队的工作以便为客户提供价值。这有多种实现方式。团队可以采用正式的框架或应用敏捷思维调整现有项目集管理实践

6.6 敏捷和项目管理办公室（PMO）

设立 PMO（项目管理办公室 product manager office）的目的是引导组织实现商业价值。可以通过帮助实现项目目标来做到这一点。PMO有时还会提供团队教育（或安排培训）、项目支持。PMO 项目管理办公室还会针对给定项目或项目集提供相关商业价值方面的管理建议

由于敏捷会带来文化变更，随着时间的推移，组织可能也需要变更，包括 PMO。例如，经历会决定资助的项目及其时间，团队会决定培训或建议需求

6.6.1 敏捷PMO 为价值驱动型

所有项目都应在合适的时间为合适的受众提供合适的价值

PMO 项目管理办公室的目标是帮助促进这个目标的实现。

基于敏捷的PMO项目管理办公室方法以客户协作思维为基础，并存在于所有PMO项目集中。

在许多情况下，这意味着PMO的运营方式类似于咨询企业（帮助敏捷团队实现商业价值：想办法、出主意），需要根据给定项目的特定需求来定制其工作。有些项目可能需要工具和模版，还有些项目可能会从管理层引导中获益。PMO项目管理办公室应努力按需交付并紧跟客户需求，确保了解并适应他们的需求。这种内部创业方法专注于能为所支持的项目提供最大价值的PMO活动

6.6.2 敏捷PMO 为面向创新型

为了在基于价值的章程下加速发展，PMO项目管理办公室可能需要强制执行某些解决方案或方法，例如，保持所有人行动的一致性以快速获得成功。但需要确保员工的参与意愿才能提高效率。只邀请感兴趣的人员参与PMO服务即可实现这一点。PMO实践的参与度越高，便更容易提高这些实践的“粘合力”。如果PMO为其客户提供了价值，则客户很可能会要求这种服务并采用其实践

6.6.3 敏捷PMO 为多学科型

为了支持特定项目需求，PMO 项目管理办公室还需要熟悉项目管理本身以外的其他一些能力，因为不同的项目要求不同的能力。例如，一个项目可能需要组织设计来解决人员配备挑战，而另一个项目可能需要组织变革管理技术来确保相关方参与或获得独特的业务模型以支持客户目标

某些组织已将其PMO转换为卓越敏捷中心 以提供以下服务：

1.【制定和实施标准】提供用户故事、测试案例、累积流图等模板，提供敏捷工具并培训支持小组了解迭代开发概念
2.【通过培训和指导发展人才】协调敏捷培训课程、教练、导师，以帮助员工过渡到敏捷思维模式并升级其技能。鼓励和支持员工参与本地敏捷活动
3.【多项目管理】通过不同项目交流协调敏捷团队。考虑分享进度、问题、回顾性发现和改进实验等内容。借助适当的框架，帮助管理项目层的主要客户发布和项目组合层的投资问题
4.【促进组织学习】收集项目进度信息并获取、存储、记录回顾性发现成果
5.【管理相关方】提供产品负责人培训，指导验收测试以及评估方法，并提供系统反馈。宣扬主题专家（SME）对项目的重要性
6.【招聘、筛选、评估项目领导】制定敏捷实践者访谈指南
7.【执行专业化项目任务】培训和提升回顾的促进者，与敏捷项目问题解决者订立协议，并提供导师和教练

6.7 组织结构

组织结构会严重影响其转向新信息或转变市场需求的能力。下面列出了主要特征：

1.【地理】地理分散的项目组织，可能会在各种项目中发现阻碍工作进展的一些挑战。项目领导和区域经理可能持有不同或相反的目标。此外，文化差异、语言障碍、低可视化，可能会降低工作效率。幸运的是，采用敏捷方法可以鼓励更好的协作并提高信心。在这些环境下，项目领导应鼓励团队和管理层对话，定制该环境所需的技术并管理对工作的期望
2.【职能结构】有些组织按照高度项目型、矩阵型、高度职能型的方式构建。具有高度职能结构的项目可能会在组织内部协作方面遇到很大阻力
3.【项目可交付成果的大小】缩小项目可交付成果将会激励部门之间更频繁的交流，由此带来更频繁的交互以及组织内部更快速的价值流动
4.【项目人员分配】另一种方法是在各个部门中抽出一个人，将其临时完全分配到最高优先级项目
5.【重采购型组织】有些组织选择主要供应商实施项目。尽管项目目标可能非常明确，供应商也有责任监管自己的财务状况。但是，供应商完成其义务并退出合约后，相关项目知识也将随之带走。这就会限制持续灵活性和速度所需的内部能力。如果在供应商还参与时采用敏捷技术（例如回顾和跟踪可能改进的领域）（保持长期记录），则可帮助缓解产品知识缺失的情况

6.8 组织演变

应对单个挑战领域或实施新的混合或敏捷方法时，建议以累积方式承接工作。常用实践是将变更过程视为一个敏捷项目，团队可以根据自己的价值观或其他考虑事项引入自己的变更待办事项列表，并确定其优先级。每个变更可以被视为一个实验，将进行短时间测试以确定每个变更的适应性以及进一步细化/考虑需求

使用看板面板跟踪进度，显示已作为 “已完成”使用的新方法、被视为“进行中”的方法，以及在等待被引入“待办事项”的方法。请参见图6-3 以了解具有待办事项列表排序的初始面板。图6-4 显示了面板工作进度的示例

通过使用这些工具，来组织和管理变更实施，将可提供 进度的可视化并对正在实施的方法进行建模。

以 透明和吸引人 的方式部署变更，将可以提高成功可能性

7 行动呼吁

自2001年，首次发布《敏捷宣言》之后，敏捷及其项目管理方法的采用率已有大幅提高。敏捷思维模式的理念和实践不再局限于特定规模的组织或一些仅专注于信息技术的组织。该思维模式应用广泛，并已在许多环境中获得了成功

如今，“敏捷”呼声，前所未有地高涨起来。由于业内对敏捷的最佳途径还存在争议，围绕该主题的讨论仍甚嚣尘上，并且不断涌现出更多的创新。有一个真理永恒不变，那就是：检查、适应、透明度，是成功交付价值的关键因素。

该实践指南可能无法提供您所期待的一切信息。我们的核心团队意识到您可能对我们选择呈现并热衷的一些元素或方法持有不同意见。我们希望您能继续积极参与这方面的对话，并改进该实践指南的下一次迭代。您需要进行学习、实验、获取反馈、再实验的过程，然后帮助我们回顾，提供指南的相关反馈并参与制定该实践指南的未来版本。无论怎样，没有适应的检查的只是浪费精力。（有了归属感，才会坚定的走下去，才有希望越来越精彩、越来越好）

最后，我们期待您能参与更广泛的项目管理和敏捷社区，推动这些主题的对话。通过会议结识PMI和敏捷联盟的代表并参与讨论。使用社交媒体发表您的观点和意见

您可以在名称为“敏捷实践”的博客中提供有关实践指南内容的反馈并参与对话，网址 https://www.projectmanagement.com/blogs/347350/Agile-in-Practicehttps://www.projectmanagement.com/blogs/347350/Agile-in-Practice