什么是敏捷项目管理？

敏捷项目管理是运用敏捷原则（灵活性、协作性、迭代开发、客户反馈优先及持续改进）管理多个关联项目的实践方式。

敏捷是一种哲学，它包含一套原则，而不是一种特定的方法。不过，有一些成熟的敏捷方法通常是敏捷项目管理的一部分，包括 Scrum、极限编程 (XP) 和看板。敏捷项目管理最初是由软件行业设计的，旨在更快地向客户提供更大的价值，但现在它的应用范围已经远远超出了该行业。

敏捷项目管理通常包括几个相关的项目。单个项目可以用敏捷框架进行管理，但敏捷项目管理会在整个生命周期内将一组项目整合为一个有凝聚力的整体。提升一个级别，一组程序和基础项目可能会在更广泛的投资组合管理战略下进行组织。

敏捷项目管理专注于特定项目，以及与该项目相关的目标、时间表、资源和团队的管理。敏捷项目管理负责监督一组相关项目，以及将这些项目整合到更广泛的组织目标下的战略。这两个学科共有许多相同的功能，但范围有所不同，敏捷项目经理在项目战略、风险、利益相关者沟通等方面发挥着更广泛的作用。

一种快速、极简的思考方式是：项目管理更关心单个项目执行的战术性和及时性。而项目管理采用更具战略性的方法来协调项目范围内各个项目的全面成功。

项目管理作为一门学科于 20 世纪 50 年代在美国开始形成。到了 20 世纪 90 年代，一组被称为“瀑布”的方法正式确定下来，即必须完成项目的每个阶段后，整个团队才能进入到下一个阶段。但随着软件活力和复杂性的增加，传统的项目管理和瀑布方法被证明是繁琐的，并且对于快速移动和频繁变化的项目来说并不理想。

2001 年，一群软件开发人员为敏捷项目管理制定了敏捷宣言，其中包括四个关键价值观和 12 条原则。关键价值观包括：

• 个人和交互超越流程和工具
  
  
• 可工作的软件胜过详尽的文档
  
  
• 客户协作 优先于合同谈判
  
  
• 响应变化而非遵循计划

优先价值观并不要求完全舍弃非优先事项。例如，敏捷理念不排斥制定计划，但更强调对必然变化的响应与准备。

这些敏捷原则在软件开发过程中日益流行，但其理念远远超出了敏捷软件开发的范畴。敏捷原则现已应用于从时尚到生物技术再到政府的许多不同行业。

敏捷方法与瀑布式等先前方法的不同之处在于，敏捷方法从一开始就被设计为迭代、合作和灵活的方法。在敏捷项目管理系统中，项目会快速创建，并根据团队或客户的响应定期进行审查、讨论和更改。一开始就假定计划和方法必须改变，而且不能一味地遵守最初的规划。每个团队成员都有权畅所欲言，而不需要像其他方法那样严格的等级制度。

由于敏捷项目管理是理念而非具体方法论，其实践细节在不同组织或项目间差异显著。但敏捷项目管理通常包含一些共性特征。

敏捷项目管理包括多个单独的项目；整个项目和每个单独的项目都可以在敏捷框架内组织。敏捷项目管理结合了一组项目的整体、全局视图。通常包括单个项目管理中没有的要素，例如预算编制、整体战略和长期分析。

快速响应变化是敏捷理念的核心原则。因此，敏捷项目管理将变革视为调整方针和进行持续改进，从而为客户创造价值的机会。将项目分成较小的增量以便完成，可以使组织更加灵活并更快地进行调整

敏捷项目管理的一个关键方面在于迭代方法。该计划中的各个项目都会经历多个版本，产品开发团队每次都会讨论并改进结果。持续交付工作输出至关重要，无论是整个项目还是单个方面。同样重要的是，要根据客户反馈、KPI 和不断变化的要求，在每次迭代中完善产品。

敏捷的优先级优先考虑面对面的对话，而不是冗长的电子邮件或其他基于文本的通信。由于时间限制或错过电子邮件，电子邮件会话串可能需要花费数小时、数天甚至数周，而面对面的交流可以在数分钟内完成同样的任务。

作为项目的总体视角，敏捷项目管理需要始终关注效率，并去除不必要或繁琐的元素。文档是达到目的的一种手段，而不是目的本身，并且应该只包含必要的内容。

诚实和开放是敏捷计划成功的关键。对话应该让所有团队成员都能畅所欲言。在这种管理方法中，每个人的声音都是有效的，都能被听到。

与此同时，在过滤不可行创意时需要确保提议者未来仍愿意建言献策。项目回顾会（收集反馈的结项评估）的成功同样依赖团队透明度。

敏捷项目管理作为一种理念，不需要使用任何特定的框架。但是许多项目管理框架，包括 Scrum 和看板，已经与敏捷理念密切相关。以下是一些最受欢迎的框架。

Scrum 是一个协作团队项目工作的框架。这个名字虽然看起来很像首字母缩略词，但实际上来自橄榄球运动：在争球 (Scrum) 时，球员们手臂架在一起，共同向对手发起冲击。这是一种不用马匹的骑兵冲锋。

在敏捷中，Scrum 团队包括三个角色：

• 项目经理：他是 Scrum 团队与利益相关者之间的联络人，利益相关者可能是用户、客户或母公司。项目经理负责向 Scrum 团队传达外部因素，如预算、人员配备和反馈，同时向利益相关者传达团队的进度。
  
  
• Scrum Master：Scrum Master 与其说是传统意义上的“老板”，不如说是 Scrum 方法的老师、指挥者，负责促进指导、沟通和解决问题。Scrum Master 通常不负责招聘和解雇。
  
  
• 开发人员或团队成员：在某些情况下，这个术语可能会有所不同，例如，当 Scrum 团队属于软件以外的行业时。无论此角色是称为开发人员、团队成员还是职员，此角色都没有层次结构。理想情况下，团队的规模在 3 到 9 人之间；较大的小组 Scrum Master 往往难以指导。这也可以包括自组织团队，其中个人可以准确决定团队需要谁和什么才能成功，而无需管理层进行过多的规划。

Scrum 有一些特定的概念将其与其他基于团队的组织模型区分开来。产品待办事项是团队在 Scrum 期间可能需要的所有任务、想法、需求、可交付成果和资源的存储库。它可以（也确实应该）由团队不断更新和监控，以帮助确保其效率和完整性。

在 Scrum 中，工作分为多个冲刺，通常持续 1 到 4 周。在冲刺阶段，团队成员努力实现一个具体的、可交付的目标。该目标可能是一个工作模型、实体模型、原型，甚至只是成品或解决方案的一个功能或元素。

在冲刺期间，团队成员每天开会一次，参加“每日 Scrum”或“站立会议”。根据 Scrum 的原则，这些会议的级别非常高。每日 Scrum 时长不超过 15 分钟，团队成员简要宣布他们的进度以及任何干扰他们工作的阻碍因素，并尽可能地精简。有时，某些团队成员可能会把信息拆分到每日 Scrum 后的会议中，以进一步讨论每日 Scrum 中宣布的内容。

在冲刺结束时，整个团队，团队成员、Scrum Master 和项目经理，将聚在一起审查和讨论已完成的工作。项目经理可以传达来自利益相关者（例如用户或更大的组织）的任何变化，经过讨论后，团队可以将这些变化纳入下一个冲刺。

看板是一个用于管理和跟踪项目的可视化系统。看板以直观的方式展示团队在项目上的进展，其中各个子任务被归为几个类别之一。这些类别通常包括：

• 待办事项：尚未转至另一类别的所有任务；在项目开始时所有任务都将归入待办事项
  
  
• 执行中：正在进行的任务
  
  
• 审核中：已完成初始阶段且正在接受他人评审的任务
  
  
• 已完成：已完成的任务。

“看板”一词源自日语“看（kan）”与“板（ban）”的组合，意为类似广告牌或留言板。看板可以采用实体或数字形式。在实体形式中，独立任务通常以实体便利贴呈现，完成时在不同栏目间移动。

还有许多数字版看板，对于部分或所有成员都是远程工作者的项目团队尤其有用。

极限编程或 XP 是一种敏捷方法，最初是为软件工程师设计的，旨在提高软件质量、响应度和速度。其基本概念是敏捷的一种形式，依赖于多个更短的可测试创建时间线。

在 XP 中，整个项目中的每个独立元素都经过反复测试，有时甚至是旨在破坏项目的大量测试。然后，通常每周一起测试这些各个方面，以帮助确保最大的兼容性。

在沟通方面，XP 极其依赖简单性。文档旨在尽可能简洁，以便其他团队成员能够理解，使用简单的语言、概念和比喻。这种简洁性还延伸到任务的实际设计中；XP 项目在设计时往往不考虑后续的额外功能，将其视为与项目发布无关的内容。这有时被称为“YAGNI”，或“You Aren't Gonna Need It（你用不到它）”。

XP 并不适合每个项目；重要的是，XP 只适用于不需要可扩展性或大量返工的项目。

SAFe 是一套基于精益敏捷开发方法、DevOps 开发运维和系统思维的原则和实践。Scaled Agile Framework（SAFe）的设计（顾名思义）是为了在大型组织中扩展敏捷框架，以协调多个项目，帮助确保跨职能和互操作性。这主要是通过包含规划增量 (PI) 路线图的结构完成的。

这些路线图中的任务以各种方式被引用，以帮助从鸟瞰图中识别它们。标识包括“推动因素”（其他任务的依赖关系）、“史诗”（针对特定业务需求设计的更大型计划）和“故事”（从用户或业务角度来看所需的功能）。

规范敏捷本质是一套原则、承诺与指导方针，而非完整方法论。属于轻量级、极简且混合型管理方式，为团队成员保留充分自主空间。

一些敏捷框架，例如 Scrum 和 SAFe，包含规范的方法和步骤。这种特殊性对于某些项目来说可能很棒，但 DA 旨在为团队成员提供更多自由度和灵活性。基本概念允许个人挑选最适合他们特定工作流的概念和框架。Scrum 可能适用于某些人，但不适用于其他人，尤其是在更大的项目观中。DA 将大量权力赋予个人，这使得它最适合团队成员知识渊博、独立且熟悉基本敏捷概念的项目。

大规模 Scrum（通常称为 LeSS）是 Scrum 的一个版本，是专为 Scrum 规模更大的团队或团队群体而设计的，而不是专为处理 Scrum 而构建。虽然 LeSS 仍然涉及冲刺、每日 Scrum 会议和审查，但它有一些额外的指导方针，以确保大型团队通过扩展敏捷来实现他们的目标，而不会失去敏捷的灵魂。

在 LeSS 中，所有团队都致力于一个共同的冲刺，而不是像敏捷项目管理那样，由各个团队计划单独的冲刺。还有一个共享的待办事项列表，包含整个计划所需的所有任务。冲刺的规划涉及两种类型的会议：所有团队的总体规划会议，然后是各个团队的单独冲刺规划会议。

Nexus 是一个类似于 Scrum 的框架，但有一些增删和修改。主要区别在于增加了 Nexus 集成团队，这是一组单独的团队成员，充当教练。NIT 通常包括来自 Scrum 团队的成员，负责消除障碍、提供帮助并通过敏捷流程指导团队。NIT 有自己的会议，与日常 Scrum 分开。

尽管 Scrum 在敏捷项目管理中针对具体项目表现卓越，但谈及敏捷项目群管理时实质是多团队协作场景。这就是 Scrum@Scale 框架的应用场景。

在 Scrum@Scale 中，所有敏捷团队成员都被视为可互换 Scrum 团队的一部分，从而实现跨学科协作。为了帮助实时应对大型项目带来的挑战，其中增加了一些新的团队成员。首席产品负责人 (CPO) 为所有 Scrum 创建单一待办事项列表，并与各个产品负责人进行协调。类似的角色是 Scrum of Scrums Master，负责协调 Scrum Master 之间的工作。

精益是一种致力于减少低效环节、持续提升交付成果质量的方法论。它常被归入敏捷体系范畴。但是，敏捷属于指导性哲学理念，而精益则是一套具备具体工具和实施路径的方法体系。精益的核心在于最大限度消除效率损耗与资源浪费，而敏捷更强调迭代开发、反馈响应与灵活适应能力。

精益有五项主要原则：

• 确定价值：从本质上讲，弄清楚目标到底是什么，并消除任何不增加价值的东西。
  
  
• 映射价值流：使用看板等管理工具来可视化产品路线图。本质上，从头到尾对项目计划进行可视化。
  
  
• 创建工作流程：构建具有具体步骤的生产流程，寻找任何可以想象到的障碍。目标是构建尽可能流畅的工作流。
  
  
• 建立拉动系统：拉动式系统只根据客户需求创建新任务，而且只在团队成员准备好完成更多工作时才创建新任务。这通常是通过任务队列来实现的。
  
  
• 持续改进：通过多种技术手段持续创造价值并改进产品。这些技术可能包括精益六西格玛与改善等方法论及哲学理念，或 Scrum 等倡导持续测试并构建良性反馈循环的结构化框架。

敏捷项目管理及其相关方法提供了许多改进项目交付的途径。

• 精准聚焦：敏捷团队借助高频次迭代，能够精确锁定客户核心需求，避免对项目全局进行无针对性的盲目优化。
  
  
• 效率：敏捷项目管理包括旨在减少浪费、文档和官僚主义的原则。
  
  
• 多功能性：根据客户反馈快速周转，灵活性是敏捷项目管理的基本要素。敏捷团队在项目开始之前就知道，在过程中会发生变化。
  
  
• 团队士气：敏捷项目管理鼓励公开、透明，让团队成员畅所欲言。等级制度并不重要，重要的是诚实和尽心尽力的团队合作。