敏捷实践指南

申明

  本文章属于原创，参考了《敏捷实践指南》，侵删。

1. 引论

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

2. 敏捷概述

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

  项目工作包括可确定的工作与高度不确定的工作。可确定的工作项目具有明确的流程，它们在以往 类似的项目中被证明是行之有效的。在完成设计后制造汽车、电器或建造住宅，这些都是可确定的工 作的例子，其所涉及的生产领域和过程通常都很好理解，并且执行的不确定性和风险通常较低。
  新的设计、解决问题和之前未做过的工作都是探索性的。它要求主题专家携手合作，解决问题， 并创建解决方案。遭遇高度不确定的工作的人员包括软件系统工程师、产品设计师、医生、教师、 律师和许多解决问题的工程师等。随着可确定的工作日益实现自动化，项目团队也越来越多地从事 高度不确定的工作，从事这些工作就需要使用本实践指南所述的有关技术。
  高度不确定的项目变化速度快，复杂性和风险也高。这些特点可能会给传统预测法带来问题， 传统预测法旨在预先确定大部分需求，并通过变更请求过程控制变更。而敏捷方法的出现是为了 在短时间内探讨可行性，根据评估和反馈快速调整。

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

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

2.3 精益与看板方法

  看待精益、敏捷与看板方法三者之间关系的一种思路是，将敏捷和看板方法视为精益思想的衍生物。换言之，精益思想是一个超集，与敏捷和看板方法拥有共性。
  这种共性非常相似，重点在于交付价值、尊重人、减少浪费、透明化、适应变更以及持续改善等 方面。项目团队有时会发现将各种方法结合起来使用更为有用，只要是对组织或团队有效的方法， 无论来源如何，都应该采纳。无论使用什么方法，目标都是为了实现最佳结果。
  看板方法受到最初的精益制造体系的启发，专门用于知识型工作。它在 2000 年代中期出现，是当 时非常盛行的敏捷方法的一种替代方法。
  看板方法不如某些敏捷方法规范，破坏性也较小，原因在于它是原始的“原地出发”方法。在有 必要或适当的情况下，项目团队可以相对轻松地应用看板方法，并向其他敏捷方法发展。关于看板 方法的更多信息，请参见“附录 A3 敏捷和精益框架概述”。

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

  有些项目在项目需求、以及如何使用现有知识和技术满足这些需求方面，具有很大的不确定性。
这些不确定因素可能导致大量变更和项目复杂性的提高。上述特点如图 2-5 所示。
  随着项目不确定性的增加，返工的风险和使用不同方法的需求也会增加。为了减轻这些风险的
影响，团队选择的生命周期要能够通过较少的工作增量解决项目的大量不确定性问题。
  团队可以利用较少的工作增量验证自身的工作，并且可以对接下来的工作做出相应变更。与静态 书面规范相比，当团队交付小的增量时，他们能够更快更准确地理解真正的客户需求。

  团队可以用明确稳定的管理要求规划并管理项目，轻松解决各种技术挑战。但是，随着项目不确
定性的增加，变更、做无用功和返工的可能性也会随之增加，而这不仅代价高昂，而且耗费时间。
  有些团队让项目生命周期发生演变，以便使用迭代和增量方法。许多团队发现，在探讨迭代需 求、更频繁地交付增量时，团队会更容易适应变更。由于团队获得反馈，这些迭代和增量方法减 少了浪费和返工。这些方法应用了:

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

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

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

  通过构建一个小的增量，然后对其进行测试和评估，团队可以在短时间内以低成本探索不确定性， 降低风险，最大程度地实现商业价值的交付。这种不确定性可能集中于适用性和需求(正在构建的产 品是否正确?);技术可行性和性能(产品是否可以采用这种方法构建?);或过程和人员(这是否 为团队工作的一种有效方式?)。以上三个特点(产品规格、生产能力和过程适用性)通常都具有高 度不确定性因素。
  不过，迭代和增量管理方法也有其应用局限性。当技术和需求的不确定性都很高时(图 2-5 右上部 分),项目就会极端复杂，陷入无序状态。为了使项目尽可能可靠，需要遏制其中一个不确定性变量。

3. 生命周期选择

  项目有多种形式，也有多种实施方式。项目团队需要认识到 相关特征和方案，以选择最可能使项目成功的方法。
  本实践指南涉及四种生命周期，分别定义如下:

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

3.1 项目生命周期的特征

  需要注意的是，所有的项目都具有这些特征，没有一个项目能够完全不考虑需求、交付、变更和 目标这些因素。项目的固有特征决定了其适合采用哪种生命周期。
  另一种理解不同项目生命周期的方法是，使用一个连续区间，从一端的预测型周期到另一端的敏 捷型周期，连续区间中间还有更多的迭代型周期或增量型周期。
  第六版《PMBOK® 指南》附件 X3 图 X3-1 将连续区间显示为一条直线。该图强调了从线的一端到 另一端，项目特征的变化情况。另一种形象化的方法是，用一个二维正方形表示这个连续区间， 如图 3-1 所示。

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

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

3.1.1 预测型生命周期的特征

  预测型生命周期预计会从高确定性的明确的需求、稳定 的团队和低风险中获益。因此，项目活动通常以顺序方式执 行，如图 3-2 所示。
  为了实现这种方法，团队需要详细的计划，了解要交付什么以及怎样交付。当其他潜在变更受到限制时，这些项目就会成 功(例如:需求变更;项目团队成员修改团队交付的成果)。 团队领导的目标是尽可能减少预测型项目的变更。
  团队在项目开始时创建详细的需求和计划时，他们可以阐明各种制约因素。然后，团队可以利用这些制约因素管理风险和成本。进而，团队在实施详细计划时，他们会监督并控制可能 影响范围、进度计划或预算的变更。
  预测型项目强调根据部门划分的、有效的、顺序的工作，并 且通常不会在项目结束前交付商业价值。如果遇到变更或需求 分歧，或者技术解决方案变得不再简单明了，预测型项目就将 产生意想不到的成本。
计划始终贯穿其中
  要记住的关键一点是，每种生命周期都有计划要素。生命 周期的不同之处并非在于计划是否完成，而在于完成了多少计划以及何时完成。
  在连续区间的预测一端，是计划驱动着工作。有多少计 划，就有多少提前执行的可能性。尽可能详细地定义需求。 团队估算何时能够交付可交付成果，并全面开展采购工作。
  在迭代方法中，也计划了原 型和验证，但是输出的目的是修改一开始所创建的计划。对未完成的工作的早期评审将有助于未来的项目工作。
  与此同时，增量方法计划交付整个项目后续部分。 团队可以提前计划可交付成 果的若干次连续交付，或者一次只计划交付一个。可交付成果为未来的项目工作提供了相关信息。
  敏捷项目也有计划。主要区别在于，通过对频繁交付的可交付成果的评审，团队将能获得更多的信息，从而在此基础上进行计划和重新计划。无论采用哪种项目生命周期，项目都需要计划。

3.1.2 迭代型生命周期的特征

  迭代型生命周期通过连续的原型或概念验证来改进产品或成果。每一个新的原型都能带来新的 相关方新的反馈和团队见解。然后，团队在下一周期重复一个或多个项目活动，在其中纳入新的信息。团队可能会在长达数周时间的一个特定迭代中使用时间盒，集中各种见解，然后根据这些见解 对活动进行返工。这样，迭代有利于识别和减少项目的不确定性。
  当项目复杂性高、变更频繁或当项目范围受到相关方对所需最终产品的不同观点的支配时，采用 迭代型生命周期会有优势。迭代型生命周期可能需要更长的时间，因为它是为学习而优化，而不是为交付速度而优化。
  图 3-3 显示迭代型项目生命周期的一个产品交付的某些要素。

3.1.3 增量型生命周期的特征

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

3.1.4 敏捷生命周期的特征

  在敏捷环境中，团队预料需求会发生变更。迭代和增量方法能够提供反馈，以便改善项目下一部 分的计划。不过，在敏捷项目中，增量交付会发现隐藏或误解的需求。图 3-5 显示了实现增量交付的 两种可能的方法，这样将便于项目与客户需求保持一致，并根据需要进行调整。

  在基于迭代的敏捷中，团队以迭代(相等持续时间的时间盒)形式交付完整的功能。团队集中 于最重要的功能，作为一个团队合作完成其工作。然后，团队再集中于下一项最重要的功能，并合作完成其工作。团队可决定一次进行若干功能的开发工作，但团队不会同时完成所有的迭代工 作(即团队不会在完成全部分析等工作后再解决所有需求)。
  对于建立在流程基础上的敏捷方法，团队将根据自身能力，从待办事项列表中提取若干功能开始 工作，而不是按照基于迭代的进度计划开始工作。团队定义任务板各列的工作流，并管理各列的进 行中的工作。完成不同功能所花费的时间可能有所不同。团队让进行中的工作的规模尽量小，以便 尽早发现问题，并在需要变更时减少返工。无需利用迭代定义计划和审核点，而由团队和业务相关 方决定规划、产品评审与回顾的最适当的进度计划。
  敏捷生命周期是符合《敏捷宣言》原则的周期。特别是，客户满意度将随着有价值产品的早期交 付和持续交付不断提升。此外，功能性的、提供价值的增量可交付成果，是衡量进展的主要尺度。 为了适应更频繁的变更，和更频繁地交付项目价值，敏捷生命周期结合了迭代和增量方法。

3.1.5 敏捷适用性筛选器

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

3.2 混合敏捷方法

  敏捷团队很少将其实践局限于一种敏捷方法。每个项目 背景都有其各自的独特性，比如团队成员技能和背景的不同 组合;开发中的产品的各个组成部分;以及工作环境中的年 龄、规模、关键性、复杂性和监管制约因素等。
  敏捷框架并不是针对团队定制的。为了定期交付价值，团队 可能需要对实践进行裁剪。通常，团队都会实践各自特殊的敏 捷组合，即便他们使用一个特定的框架作为起点也不例外。
协调方法
  裁剪敏捷框架的一个例子 是，一个广泛使用的常见协调 方法涉及到协调使用 Scrum 框 架、看板方法和极限编程 (XP) 方法的要素。Scrum 为产品待办 事项列表、产品负责人、Scrum 主管以及跨职能开发团队的使 用提供指导，包括冲刺计划、 每日例会、冲刺评审和冲刺回 顾会议。看板面板帮助团队进 一步提高效率，方法是将工作 流可视化、使障碍更容易被察 觉，以及通过调整在制品限制 来实现流程管理。此外，受极 限编程启发的工程实践，如使 用故事卡、持续集成、重构、 自动化测试和测试驱动开发， 将进一步提高敏捷团队的效 力。总之，与孤立采用各种实 践相比，协调这些不同来源的 实践将产生更好的协同成果。

3.3 影响裁剪的项目因素

  有时，为了更好地配合，根据项目属性对方法进行裁剪。表 3-2 列出一些要考虑的项目因素和裁剪方案。

4. 实施敏捷:创建敏捷环境

4.1 从敏捷思维模式开始

使用敏捷方法管理项目，要求项目团队采用敏捷思维模式。以下问题的答案将有助于制定实施策略:

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

4.2 仆人式领导为团队赋权

  敏捷方法强调，仆人式领导是一种为团队赋权的方法。仆人式领导是通过对团队服务来领导团队的实践，它注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。
  仆人式领导的作用是促进团队发现和定义敏捷。仆人式领导实践并传播敏捷。仆人式领导按照以 下顺序从事项目工作:

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

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

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

  仆人式领导并不是敏捷所独有的。但经过实践，仆人式领导通常能了解到仆人式领导是怎样融入敏捷思维模式和价值观的。
  领导在发展自身仆人式领导力或促进技巧后，他们就更愿意成为敏捷践行者。因此，仆人式领导可以帮助他们的团队通过合作更快地交付价值。
  成功的敏捷团队信奉成长思维模式，团队成员自己能够学到新技能。如果团队和仆人式领导都相信自己能够学习，那么所有人的能力都能得到提高。

4.2.1 仆人式领导的职责

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

4.2.1.1 仆人式领导的促进作用

  项目经理成为仆人式领导时，工作重点就会从“管理协调”转向“促进合作”。促进者将帮助每个人各尽所能地思考和工作。促进者鼓励团队参与、理解，并对团队输出共同承担责任。促进者帮 助团队创建可接受的解决方案。
  仆人式领导促进团队内部和团队之间的合作与对话。例如，仆人式领导在团队内部和团队之间帮助发现瓶颈问题，并进行相应沟通。然后，团队将解决这些瓶颈问题。
  此外，促进者还鼓励大家通过交互式会议、非正式对话和知识共享展开协作。仆人式领导要通过成为公正的搭桥者和教练来做到这一点，而不是代替他责任人做出决策。

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

  《敏捷宣言》的第一个价值观关乎个人与过程和工具的交互。对仆人式领导而言，更好的职责是 认真审视那些阻碍团队敏捷或组织敏捷的过程，并努力使其合理化。例如，如果一个部门需要大量 文档，仆人式领导的角色就能发挥作用，他们可以与部门合作审查所需的文档，就敏捷交付如何满 足这些需求达成共识提供协助，并对所需的文档数量进行评估，从而使团队能够将时间更多地用于 提供有价值的产品，而不是创建详尽的文档。
  仆人式领导还应该关注其他冗长的过程，这些过程往往造成瓶颈问题，阻碍团队或组织的敏捷性。 可能需要处理的过程或部门的例子包括，财务部门、变更控制委员会或审计部门。仆人式领导可以与 他人携手合作，共同质疑和审核他们的过程，为敏捷团队和领导提供支持。例如，对团队而言，每两 周交付一个工作产品仅仅是为了让产品进入队列或过程，而冗长的发布过程却可能需要 6 周或更长时 间，这样做有什么好处呢?太多的组织都有这些“瓶颈”过程，正是它们阻碍了团队快速交付有价值 的产品或服务。仆人式领导有能力改变或消除这些组织障碍，为交付团队提供支持。

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

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

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

  第六版《PMBOK® 指南》将项目经理定义为“由执行组织委派，领导团队实现项目目标的个人”。
  许多项目经理已经习惯于作为项目的协调中心，负责跟踪团队的状态，并向组织中的其他成员反映。 当项目被分解为孤立的功能时，这种方法没有问题。
  然而，对于高不确定性项目，项目的复杂性是一个人所无法管理的。而跨职能团队既能协调自身 的工作，还能与业务代表(产品负责人)开展合作。
  从事敏捷项目工作时，项目经理的角色就会从团队的中心转变成为团队和管理人员提供服务。在敏捷环境中，项目经理充当仆人式领导，其工作重点转变为引导需要帮助的人，促进团队的合作，保持与相关方的需要一致。作为仆人式领导，项目经理要鼓励将责任分配给团队成员，分配给那些 掌握完成任务所需知识的人。

4.3 团队构成

  《敏捷宣言》的价值观和原则的一个核心宗旨是强调个人和交互的重要性。敏捷优化了价值流，强调了向客户快速交付功能，而不是怎样“用”人。
团队在考虑如何优化价值流时，以下好处是显而易见的:

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

4.3.1 敏捷团队

  敏捷团队注重快速开发产品，以便能获得反馈。在实践中，最有效的敏捷团队往往由三到九个成 员组成。理想情况下，敏捷团队应该集中在一个团队工作场所工作。团队成员 100% 为专职成员。敏 捷鼓励自我管理团队，由团队成员决定谁执行下一阶段定义的范围内的工作。敏捷团队与仆人式领 导一起茁壮成长。领导支持团队的工作方法。
  跨职能敏捷团队频繁创造功能性产品增量。这是因为团队集体对工作负责并共同拥有完成工作所 需的所有必要技能。
  无论整体的敏捷方法是什么，团队越是限制其在制品，团队成员就越有可能通过合作来加快整 个团队的工作。在成功的敏捷团队中，团队成员在工作中以各种方式开展合作(如结对、群集、 群体开发)，因而，他们会协同工作，而不会落入迷你瀑布的陷阱中。团队在给定时间解决所有 的需求，然后试图完成所有的设计，继而又去完成所有的构建，就会发生迷你瀑布的情况。使用 这个场景，在构建中或构建后测试中的某一时刻，团队可能会意识到，原先的假设已经不再有 效。这种情况下，团队解决所有的需求根本是在浪费时间。相反，当团队成员合作打造全部功能 中的少量功能时，随着工作的推进和交付少量已完成的功能，他们也在不断学习。
  敏捷项目得益于项目团队结构，这种结构能改善团队内部和团队之间的合作。图 4-1 展示了团队成 员如何通过合作提高工作效率、促进创造性地解决问题。

4.3.2 敏捷的角色

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

• 跨职能团队成员;
• 产品负责人;
• 团队促进者。
  表 4-2 描述了这些团队角色。
  

4.3.3 通才型专家

  敏捷团队是跨职能的，但其人员往往不会一开始就做到这 样。不过，许多成功的敏捷团队都由通才型专家组成，他们也 称为 T 型人才。
  这意味着这些团队成员在具备一项擅长的专业化技能的同 时，还拥有多种技能的工作经验，而不是单一的专业化。由于 密切协作和自我组织，敏捷团队成员才能够敏捷开发并迅速完 成工作，而这就需要使互相帮助成为常态。敏捷团队成员都要 致力于培养这样的特质。
  一个人的能力大小无关紧要。如果给团队其他成员带来瓶颈 问题，集中于某一个人的能力甚至是有害的。团队的目的是优 化已完成的工作，并获得反馈。
  如果客户希望获得好的结果，如快速交付功能并且质量优 良，那么团队就不能仅仅为了尽可能有效利用资源而构建专门 的角色。团队的目标是提高过程效率，优化整个团队的产能。 团队规模小会促进团队的合作。产品负责人的工作是确保团队 从事最高价值的工作。

4.3.4 团队结构

  许多行业的团队都会采用敏捷原则和实践。他们将人员组织到跨职能团队中，迭代开发工作产品。
  有些组织已经能够建立集中办公的跨职能团队;还有组织有不同的情况。有些组织并不是所有团 队成员都为集中办公，而是拥有分布式或分散式团队。分布式团队可以在不同地点拥有多个跨职能 团队。分散式团队可能会让各团队成员分别在不同的地点工作，或在办公室，或在家里。鉴于通信 成本的增加，这些安排并非理想，但它们仍然是可行的。

4.3.5 专职小组成员

  如果团队成员并非 100% 为团队专职工作，会有什么情况发生?遗憾的是，这种情况虽然并不理想，但有时却无法避免。
  让一个人在团队中只投入 25% 或 50% 的能力，这带来的关键问题是，他们会进行多任务处理和任 务切换。多任务处理会降低团队工作的产出，并影响团队预测交付能力的一致性。
  任务切换时，人员工作效率的损失在 20% 到 40% 之间。随着任务数量的增加，效率损失会呈指 数级增长。
  当一个人在两个项目之间进行多任务切换时，他投入到每个项目上的精力并非各占 50%。相反， 由于存在任务切换成本，他在每个项目上的投入降低到 20% 到 40%之间。
  人们在一心多用的时候更容易犯错误。任务切换消耗工作记忆，人们在多任务处理时不太可能记 住相应工作的背景。
  当团队中所有的人都被分配到一个项目时，他们能够作为一个团队持续协作，从而使每个人的 工作更加有效。

4.3.6 团队工作场所

  团队需要一个工作场所，他们可以一起工作，了解他们作为团队的状态，并进行协作。有些敏捷 团队的所有成员都集中在一个房间里工作。有些团队拥有一个团队工作场所用于开例会以及张贴各 种图表，但团队成员分别在各自的小隔间或办公室里独立工作。
  随着各公司迈向开放、协作的工作环境，组织也必须为需要不间断时间来思考和工作的员工创 造安静的空间。因此，各公司纷纷设计各自的办公室，以平衡公共和社交区域(有时被称为“公共 区”)与个人工作不被打扰的安静区域或私人区域。
  拥有在不同地点工作的成员时，团队会决定他们各自的工作场所有多少是虚拟的，多少是实际的。 诸如文档共享、视频会议和其他虚拟协作工具等技术可以帮助人员实现远程协作。
  在不同地点工作的团队成员需要虚拟的工作空间。另外，要考虑让团队成员定期聚集一堂，以便 建立信任，学习怎样开展合作。
  分散式团队管理沟通的一些技术包括鱼缸窗口和远程结对:

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

4.3.7 克服组织孤岛

  组建敏捷团队的最好开端是构建一个拥有基本信任和安全的工作环境，以此确保所有团队成员都 有平等的话语权，他们的意见都能被听到并得到考虑。这一点再加上构建敏捷思维模式，都是潜在 的成功因素，在此基础上，所有其他挑战和风险都能够化解。
  孤岛组织往往给跨职能敏捷团队的组建带来重重障碍。需要构建跨职能团队的团队成员通常需要 向不同的管理人员报告，管理人员会采用不同的标准衡量他们的绩效。管理人员需要关注的不是资 源利用效率，而是过程效率(和基于团队的指标)。
  为克服组织孤岛问题，就要与团队成员的不同管理者合作，让他们为跨职能团队安排必要的专职 人员。这样不仅能建立团队协同，而且能让组织看到怎样用人才能优化正在进行中的项目和产品。

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 分钟。团队以某种方式“过一下”看板或任务板，而团队中的 任何人都可以主持站会。
  在基于迭代的敏捷中，每个人都轮流回答下列问题:

• 上次站会以来我都完成了什么?
• 从现在到下一次站会，我计划完成什么?
• 我的障碍(或风险或问题)是什么?
    从这样的问题得出的答案能够让团队自我组织，并让团队成员为完成之前和整个迭代中承诺完成 的工作承担彼此的责任。
    基于流程的敏捷有一种不同的方法，可以将注意力集中在团队的产出上。团队从右到左对看板进行评估。问题包括:
• 我们还需要做些什么来推进这一工作?
• 有人在做看板上所没有的事情吗? uu作为一个团队，我们需要完成什么?
• 工作流程是否存在瓶颈或阻碍?
    站会中常见的一个反模式是，站会变成了状态报告会议。传统上在预测环境中工作的团队可能倾 向于采用这种反模式，因为他们习惯于报告状态。
    另一个典型的反模式是，当问题变得明显时，团队才开始解决问题。站会是为了发现存在问题， 而不是解决它们。将问题添加到停车场区，然后创建另一次会议，它可以在站会之后立即召开， 并在会上解决问题。
    团队可以举办自己的站会。只要体现了团队工作需要的密切合作，进行顺利，站会便会非常有用。 要针对团队何时需要站会、站会是否有效等问题有意识地做出决定。

5.2.5 展示/评审

  当团队以用户故事的形式完成特定功能时，团队会定期展示工作产品。看过展示后，产品负责人接受或拒绝故事。
  在基于迭代的敏捷中，团队在迭代结束时展示所有已完成的工作项。在基于流程的敏捷中，团队 在需要时展示完成的工作，通常是当完成的功能累积到足以构成一个连贯组合时。团队，包括产品 负责人在内，都需要反馈来决定何时需要产品反馈。
  一般的指导方针是，每两周至少展示一次团队的工作产品。这种频率对于大多数团队来说是足够 的，这样，团队成员就可以得到反馈，防止他们朝着错误的方向前进。这种频率也足够频繁，让团 队可以保持产品开发足够清晰，按照自己希望或需要的频率构建一个完整的产品。
  使项目敏捷的一个基本要素是频繁地交付工作产品。一个没有展示或发布的团队，其学习的速度 不会快，并且很可能并未采用敏捷技术。团队可能需要额外的引导来保证频繁的交付。

5.2.6 规划基于迭代的敏捷

  不同团队的能力各不相同。不同产品负责人的典型故事大小也各不相同。团队应考虑自身故事大小，避免提交更多的故事，而超出团队在一个迭代中所能完成工作的能力。
  产品负责人了解，当人员不可用时(例如，公共假期，度假期间，或阻止人员参加下一组工作的 任何事情)，团队能力降低。团队将无法完成与前一时期相同的工作量。在能力降低的情况下，团 队只会计划相应能力能够完成的工作。
  团队估算能够完成的工作，这也是一种能力的衡量(示例参见 4.10 节)。团队不能 100% 确定自己 能交付什么，因为他们无法知道意外情况。当产品负责人拆分故事使其变小时，团队看到的是产品 的完成进度，团队就会知道他们将来能够做什么。
  敏捷团队在一个工作块中不会只计划一次。相反，敏捷团队会开始计划一点，交付、学习，然后 在一个持续的循环中重新规划更多的东西。

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

  如果团队不重视质量，很快就会无法快速发布任何东西。 下面的技术实践中，很多都来自于极限编程，它们可以帮助团队以最快的速度交付:

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

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

  迭代可以帮助团队为交付和多种反馈创建一个节奏。团队会为交付和反馈创建增量。交付的第一 部分是一次演示。团队会收到关于产品的外观和运行方式的反馈。团队成员回顾如何检查和调整有关过程以取得成功。
  演示或评审是敏捷项目流程的必要组成部分。为团队的交付节奏安排适当的演示。

5.3 解决敏捷项目的挑战

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

5.4 敏捷项目的衡量指标

  过渡到敏捷意味着要使用不同的衡量指标。使用敏捷意味着要审视对团队和管理层都很重要的新指标。这些衡量指标很重要，因为它们关注的是客户价值。
  状态报告的一个问题是，团队预测完成或使用交通灯状态来描述项目的能力。例如，项目领导将 项目描述为“90% 完成”。此时，团队正试图将一个个片段集成到一个产品中。团队发现，有缺少的 需求或者意外出现，或是产品没有按照他们的想法集成。
  项目只是完成了一半，而交通灯状态报告并未反映项目真实的状态。项目团队往往认识到，他们 还需要同样长的时间才能完成项目的剩余部分。太多的项目存在这种情况:由于发现了问题，团队 才认识到，自己最多只完成了 10% 的工作。
  预测型衡量指标的问题在于，它们往往并不反映真实的情况。往往直到发布日期前 1 个月，项目 状态绿灯一直是亮的;这种项目有时被称为西瓜项目(外面绿，里面红)。项目状态灯经常会变成 红色，似乎没有任何警告，因为直到发布日期前 1 个月，才会得到关于项目的经验数据。
  敏捷项目的衡量指标包含有意义的信息，这些信息提供了历史记录，因为敏捷项目要定期交付 价值(完成的工作)。项目团队可以利用这些数据改进预测和决策。
  替代衡量指标(如完成百分比)不如经验指标(如已完成功能)更有用。有关价值管理的更多 信息，请参见 4.10 节。敏捷帮助团队发现问题和难题，以便团队能够诊断和解决问题。
  除了定量指标之外，团队还可以考虑收集定性衡量指标。其中一些定性衡量指标侧重于团队选择 的实践，评估团队使用这些实践的情况，例如，对交付功能的业务满意度、团队的士气;团队希望 跟踪的任何东西等都是定性衡量指标。

5.4.1 敏捷团队的衡量结果

  敏捷倾向于使用基于经验和价值的衡量指标，而不是预测型 衡量指标。敏捷衡量团队所交付的成果，而不是团队预测将交 付的成果。
  对于一个习惯于掌握项目基准、估算的挣值和投资回报率 (ROI) 的团队，可能会对实施一个项目而不是管理一个基准感 到茫然。敏捷是基于对客户有可见价值的工作产品。
  基准通常是尝试预测的产物。在敏捷中，团队的估算最 多限于未来几周时间。在敏捷中，如果团队工作的可变性不 高，如果团队成员没有从事多任务，则团队的能力就会变得 稳定。这样才能对未来几周做出更好的预测。
  完成迭代或流程中的工作后，团队就可以进行重新规划。敏 捷并不能创造出更多的工作能力。然而，有证据表明，工作量 越少，人员就越有可能交付。
  与其他知识型工作一样，软件产品开发关乎在交付价值的同时 进行学习。在项目的设计部分，硬件开发和机械开发是相似的。 学习的过程是通过实验，交付微小的价值增量，并获得对目前已 完成工作的反馈。其他许多产品的开发项目也包括学习。
  项目发起人通常想知道项目 什么时候能够完成。一旦团队 建立了稳定的速度(每个迭代 的故事或故事点的平均数量) 或平均周期时间，团队就能够 预测项目将花费多长时间。
  举例来说，如果团队平均每 个迭代有 50 个故事点，而团队 估算还剩下大约 500 个点，于 是，团队估算，还剩下大约 10 个迭代。随着产品负责人对剩 余的故事进行细化，团队对估 算进行细化，项目估算虽然可 能有升有降，但团队却能提供 一个估算。
  如果团队平均完成每个故事 的周期为三天，还有 30 个故事 要完成，那么团队将需要 90 个 剩余工作日，大约 4 到 5 个月。
  用飓风图反映估算的可变性，也可使用发起人能够理解 的其他一些可变性衡量方法。
  由于学习是项目的重要组成部分，因而，团队需要在平衡不确定性的同时为客户提供价值。团队 要规划项目要完成的下一个小部分。团队报告经验数据，并重新规划其他小的增量，以此管理项目 的不确定性。
  某些基于迭代的项目使用燃尽图查看项目随时间的进展情况。图 5-1 显示了一个燃尽图的例子， 其中，团队计划交付 37 个故事点。故事点对需求或故事的相关工作、风险和复杂性进行评估。许多 敏捷团队使用故事点估算工作量。燃尽图中的虚线表示计划。图 5-1 中，团队可以看到，在第 3 天他们面临交付的风险。

某些项目团队更喜欢用燃起图。如图 5-2 所示的燃起图中的数据与图 5-1 相同。

  燃起图显示已完成的工作。图 5-1 和图 5-2 都是基于相同的数据，但分别以两种不同的方式显示。团队可以选择如何查看他们的数据。
  看到在迭代中尚未完成的工作时，团队可能会变得沮丧，并且可能因为急于完成工作，而不满足 验收标准。不过，团队可能有很多理由不按预期完成工作。燃尽图显示了团队成员的多任务处理、 过于庞大的故事或团队成员缺勤的效果。
  特别是对新建的敏捷团队，燃起图将显示迭代过程中范围内的变化。利用燃起图，团队能查看他 们已经完成的工作，这将有助于团队进行下一项工作。
  无论使用燃尽图还是燃起图，团队都能看到在迭代过程中完成的工作。在迭代结束时，他们可能 会根据自己在这个迭代中完成工作的能力(多少故事或故事点)来建立他们下一个迭代的能力衡量 指标。这样，产品负责人与团队一起重新规划，团队就更有可能在下一次迭代中成功交付。
  速度，也即本次迭代中实际完成功能的故事点大小的总和，让团队得以通过观察历史表现来更准 确地规划下阶段的能力。
  基于流程的敏捷团队使用不同的衡量指标:交付周期(交付一个工作项目花费的总时间，从项目 添加到看板直至项目完成)、周期时间(处理一个工作项目所需的时间)和响应时间(一个工作项 目等待工作开始的时间)。团队通过衡量周期时间发现瓶颈和延迟问题，问题不仅限于团队内部。

  交付周期有助于理解从第一次查看特定功能到向客户发布该功能所需的周期时间。在制品(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 出版物《组织变革管理实践指南》[2] 介绍了成功引入有 意义变革的全面整体性方法。该指南提供的建议包括:

• 说明变革动态变化的模型;
• 实现变革的框架;
• 项目、项目集和项目组合层面的变革管理实践的应用。
  6.1.1 和 6.1.2 节探讨了特定敏捷环境中变革管理的考虑事项。 图 6-1 显示了这两个主题之间的关系。
  

6.1.1 变革管理驱动因素

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

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

6.1.2 变革就绪情况

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

• 管理层的变革意愿;
• 组织在员工认知、审核和评估方式上做出改变的意愿;
• 集中或分散项目、项目集和项目组合管理职能;
• 专注于短期预算和指标而不是长期目标;
• 人才管理成熟度和能力。

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

• 工作被分解为部门孤岛，从而创造出阻碍加速交付的依赖关系，而不是构建在能力中心指导下 的跨职能团队。
• 采购策略基于短期定价策略，而不是长期能力。
• 奖励领导的依据是本地效率而不是端到端项目交付流或整体优化情况(就组织而言)。
• 员工属于特定领域人才，实现技能多元化的工具或激励有限，不重视培养T型专家人才。
• 分散化项目组合使员工同时分配到过多的项目，而无法专注于单个项目。
    组织审查和修改这些实践的意愿程度将决定采用敏捷方法的速度和效率。但是，为了解决这些敏捷组织障碍，项目领导可以尝试多种方法来加速文化兼容性:
• 积极明确的管理层支持;
• 变革管理实践，包括沟通和引导;
• 逐个项目应用敏捷实践；
• 向团队增量地引入敏捷实践;
• 通过采取适用的敏捷技术和实践示范引导。

6.2 组织文化

  组织文化就是组织的 DNA – 组织的核心标识。文化始终影响 敏捷方法的使用。组织文化一直在连续运转，从高预测型计划 到一切皆为实验的精益创业阶段均有体现。尽管敏捷方法与 精益创业文化相当吻合，高预测型组织可以鼓励实证的衡量指 标、小型实验和不断学习以便向敏捷方向转变。

6.2.1 创建安全环境

  组织文化难以改变，但组织中最重要的文化规范—愿意尝试任何新方法或技术—将有利于构建安全的工作环境。
  只有在安全、诚实和透明的环境中，团队成员和领导才可以 真正反思其成功，确保项目持续进步，或者应用从失败项目中 所吸取的教训，不再重蹈覆辙。

6.2.2 评估文化

  每个项目都会遇到相关方意愿相左的棘手情况。团队如何在 不影响质量的情况下取得快速进展?团队如何在保留灵活性的 同时确保时效性?更重要的是，团队如何满足客户需求?
  项目领导可能感觉其职责就是满足各个相关方的期望;但是 在面对选择时，通常需要根据组织业务环境的文化和要求来确定优先级。例如，移动电信项目偏重于速度，而政府项目可能偏重于大众化和稳定性。
  要引导这些动态变化，项目领导应花费时间去评估组织通常所关注的重点。图 6-2 显示了有关如何 评估的示例。在这个例子中，项目领导发起了与相关方、团队成员和高层管理者的对话以讨论组织优先级。这些优先级根据滑动标尺在这两个极端之间的位置来进行记录，然后再利用该结果去找到最适合这些优先级的敏捷技术。

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

6.3 采购和合同

  如本实践指南中前面所述，《敏捷宣言》认为“客户协作高于合同协商”。许多项目失败源于客户供应商关系破裂。如果合同相关方怀有非赢即输的想法，通常会给项目带来更多的风险。协 作方法提倡共担项目风险和共享项目奖励的关系，实现所有方共赢。设计这种动态特性的合同签 署技术包括:

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

6.4 商业实践

  在需求产生时，组织创建新能力的意愿和能力即是组织敏捷性的标志。对于关注敏捷及其所提供结果的组织而言，这些不必是颠覆性的变革，破坏性较小。透明和开放协作至关重要。
  在跨职能团队交付价值时，团队和个人可能会遇到组织多种支持职能方面的问题。
  如果团队定期交付价值，财务部门可能有机会以不同的方式获得产品收益。如果团队与其他组织签署了合同，采购部门可能需要变更这些合同，以帮助其他组织频繁交付价值并与团队保持同步。
  团队开始以团结协作的方式展开工作后，将会对内部管理策略提出挑战。人力资源可能注意到个人激励不足，而经理可能会在自组织员工的绩效评估方面绞尽脑汁。在各种情况下都有机会评审现 有实践对敏捷工作方式的支持程度。
  当组织发展到更高敏捷性时，其他业务部门将有必要更改其交互方式并履行自己的职责。现在应拥护对组织其他领域有益的变更，以此来提高整个组织的效率。

6.5 多团队协作和依赖关系(扩展)

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

6.5.1 框架

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

6.5.2 考虑事项

  有多种扩展工作的方式。团队可能需要将多个敏捷项目工作扩展到单个敏捷项目集中。或者，组织可以设计出支持整个项目组合中不同敏捷方法的结构。
  例如，可以从小项目着手，然后尽快了解组织环境中比较适合的方式。即使一切还未完全转换到敏捷方法，团队仍可获得成功。
  无论采用哪种方法，关键成功因素是健康的敏捷团队。如果单个团队采取敏捷方法无法获得成功， 则勿尝试将其扩展到更大范围;而是要先行解决阻止团队敏捷工作的组织障碍。
  大规模敏捷项目的目标是协调不同团队的工作以便为客户提供价值。这有多种实现方式。团队可 以采用正式的框架或应用敏捷思维调整现有项目集管理实践。

6.6 敏捷和项目管理办公室 (PMO)

  设立 PMO 的目的是引导组织实现商业价值。可以通过帮助实现项目目标来做到这一点。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 转换为卓越敏捷中心以提供以下服务:

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

6.7 组织结构

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

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

6.8 组织演变

  应对单个挑战领域或实施新的混合或敏捷方法时，建议以累积方式承接工作。常用实践是将变更过程视为一个敏捷项目，团队可以根据自己的价值观或其他考虑事项引入自己的变更待办事项列表 并确定其优先级。每个变更可以被视为一个实验，将进行短时间测试以确定每个变更的适应性以及 进一步细化/考虑需求。
  使用看板面板跟踪进度，显示已作为“已完成”使用的新方法、被视为“进行中”的方法、以及仍 在等待被引入“待办事项”的方法。请参见图 6-3 以了解具有待办事项列表排序的初始面板。图 6-4 显示了面板工作进度的示例。


  通过使用这些工具来组织和管理变更实施，将可提供进度的可视化并对正在实施的方法进行建模。以透明和吸引人的方式部署变更，将可以提高成功可能性。

7. 专栏知识链接

项目管理综述
项目整合管理
项目范围管理
项目进度管理
项目成本管理
项目质量管理
项目资源管理
项目沟通管理
项目风险管理
项目采购管理
项目相关方管理
敏捷实践指南