什么是敏捷项目管理？

敏捷项目管理是针对单个项目（通常是产品或软件开发项目）的方法，它依赖协作、迭代开发、灵活性、适应性和持续改进等敏捷原则。项目目标（时间表、资源、目标、团队）的管理以敏捷理念为核心，可兼容 Scrum、看板和精益等多种框架。

敏捷项目管理可组合成项目群并沿用敏捷原则进行管理；多个项目群则可进一步组合成项目组合，形成嵌套式结构。

敏捷方法诞生于 2001 年，当时一群软件工程师共同发布了《敏捷宣言》。《敏捷宣言》包括四大关键价值观和 12 项原则。关键价值观包括：

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

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

顾名思义，敏捷项目管理专为应对需求频繁变动的环境而设计。项目开始前无需精心规划每个步骤，而是快速创建任务，并根据团队或客户反馈定期进行审查、讨论和更改。

一开始就假定计划和方法必须改变，而且不能一味地遵守最初的规划。每个团队成员都有权畅所欲言，而不需要像其他方法那样严格的等级制度。

敏捷和瀑布是两种最热门的项目管理理念，二者所代表的方法截然不同。

瀑布于 1970 年首次深入阐述 (PDF)，是一种顺序式的高度结构化方法论。在瀑布中，具体步骤在项目开始前就已枚举，每个步骤都需要在进行下一步前完成。有趣的是，计算机科学家 Winston Royce 在 1970 年发表的论文中其实对瀑布提出了批判。（更有趣的是：Royce 的儿子 Walker Royce 是 IBM 首席软件经济学家，并且撰写了多本有关项目管理的书籍）

敏捷则采取不同的策略：它重视迭代、可变且具备适应性的进展。它理解并接受项目的完整生命周期无法在初始阶段完全预知，并通过审核与冲刺等实施工具来适应这一现实。

敏捷项目管理更像是一种涵盖广泛原则的哲学，而非特定的方法论。但是，大多数敏捷项目都涉及几项关键功能。

敏捷的核心要素之一，在于其对迭代的依赖。这与《敏捷宣言》中四大关键价值观中“构建可用软件”的原则密切相关。在敏捷中，工作可划分成更小且更易于管理的任务，这些任务可以快速完成并频繁审核。各项任务会根据利益相关方审核会议的反馈进行动态调整，有时甚至会做出重大变更。

审核是敏捷的重要组成部分，通过迭代来提供定期反馈以持续改进。具体形式因所用框架而异，但定期、频繁的审核会议是所有敏捷实践的共同特征。在审核会议中，组织会鼓励所有参会者畅所欲言，这与瀑布等层次结构更强的模式形成鲜明对比，瀑布模式的决策是自上而下“流动”的。

敏捷支持跨学科协作，重视具备多种技能的团队成员——他们可以与整个组织的利益相关者进行广泛协作。在敏捷中，开发人员不会在产品开发过程中“闭门造车”，对团队的所有其他成员视而不见。相反，定期审核涉及各类利益相关者。

例如，让我们将敏捷原则应用于某个新的锻炼应用程序。创建该应用程序的开发人员还需要与设计师、健身专家、营销人员、销售人员和项目经理频繁协作。通过吸纳所有必要的利益相关者，这些开发人员就能在努力实现高质量成果的过程中融入关键反馈。

旧版或更传统的项目管理系统（如瀑布）则遵循严格的层次结构，确保每个人都专注于执行任务。项目经理负责分配任务，专业人员则负责完成各自的任务，每个人都各司其职。

这种方法会形成“孤岛”，削弱团队成员的自主性，导致其因认为自己“人微言轻”而放弃提出建设性反馈意见。

在敏捷模式下，团队通常规模较小、具备自组织能力，并依托跨职能协作。每位团队成员都能感受到更强的项目归属感，并根据需要随时补位。

敏捷项目管理框架可提供符合敏捷原则的结构。并非每个框架都适用于所有项目，因此选择最合适的框架至关重要。

作为最广为人知的敏捷概念之一，Scrum 源自橄榄球运动——全体队员在短暂而激烈的对抗赛事中同步推进。在敏捷的背景下，Scrum 依赖固定时长的迭代冲刺（通常为一至四个星期），但团队合作的概念仍然存在。

这些冲刺以协同规划为出发点，确定在即将到来的冲刺中要处理哪些产品待办事项任务和交付成果。这一冲刺规划可由 Scrum Master 或产品负责人引导——他们更像是导师而非领导者，其职责是确保Scrum 团队持续遵循敏捷实践。然后，团队会召开简短的每日例会（持续时间不超过 15 分钟），以确定任何障碍或干扰因素。这些日常站会对于发现任何潜在问题至关重要，但必须尽可能简明扼要。

在每次冲刺结束后的冲刺回顾中，团队会与开发团队外部的利益相关者共同审核其完成的工作，以确定任何潜在问题或亟需改进之处。

看板是工作流的可视化呈现，其传统形式为分类便利贴组成实体看板。（当然也有众多数字版本供无需纸质工具的用户选择）

看板通常包括三栏：

待办事项：尚未开始的任务。

进行中：个人或子团队目前正在开展的工作。

已完成：已完成的单项任务。

但这并非一成不变。根据项目情况，可能需要添加其他栏目，例如“测试”、“合规性”或“构思”。

每个栏目均包含单项任务，并以纸质或数字便利贴形式呈现。在我们的锻炼应用程序示例中，这些注释可能包括“创建‘锻炼项目收藏’列表”、“添加示范视频”和“使用秒表功能”。每项任务完成后，其对应的便利贴将以物理（或数字）形式从一栏移至下一栏，直到所有任务完成。

虽然精益并非严格意义上的敏捷框架，但它是一种可以应用于敏捷项目的相关方法论。精益起源于制造业，专注于减少浪费、文档编制、过度生产和碎片化。当二者结合时，这一模式有时又被称为“精益敏捷”。精益敏捷优先确定价值，有时会通过“价值流”映射这一可视化呈现来识别瓶颈或低效问题。

规模化敏捷框架 (SAFe) 是一套组织与工作流原则、实践及能力体系的知识库，旨在助力企业实现大规模敏捷转型。在 SAFe 中，敏捷团队利用 scrum 或其他方法开展常规工作。多个团队共同组成“敏捷发布列车”(ART)，以跨职能方式协作，从而定期交付增量解决方案。ART 每隔两周举办一次演示会议，提出相关意见和建议并在后续冲刺阶段实施。SAFe 整合了多种敏捷方法论和实践，并添加部分额外功能，旨在确保大型组织步入正轨。

敏捷项目管理正日益普及，尤其是在软件和技术领域。如今，许多组织都认识到了明智抉择的价值：2025 年的一项研究 (PDF) 发现，对于流程简单、复杂度低且结果可预见的项目，瀑布实践仍然是理想选择。该研究还发现，敏捷项目管理对于复杂或频繁变动的项目来说可能更为有效。其他分析师则倾向于采用混合方案。Antonio Nieto-Rodriguez 在《哈佛商业评论》中写道，“组织可借助混合方案实现最佳平衡，从而灵活适应无法预见的挑战，始终聚焦其最终目标”。

敏捷项目管理注重最简化可实施产品 (MVP)。无论是使用精益、SAFe 还是其他方法论，敏捷流程都非常重视在冲刺阶段结束时交付功能演示。在软件方面，这种做法能更快地向消费者发布产品，并随项目的进展持续更新。

敏捷思维从初始阶段就假定，一个项目不仅可能会发生变化，而且一定会变化。适应性是敏捷方法的核心特征，通过独立划分任务和项目以及定期举办审核会议来实现。在每次审核中，组织会鼓励团队和利益相关者提出任何反馈——无论是内部反馈还是来自客户的反馈，团队则会在后续冲刺中整合这些反馈。客户满意度才是最终目标，而非机械遵循计划。

成功案例表明，敏捷实践可以提高效率和生产力。在亚利桑那州立大学 (ASU)，IT 部门大力推行敏捷实践，并借助模板和协作来规范项目规划。ASU 专门应用各种工具，整合减少浪费和重复的精益原则。他们的方法成功构建了可扩展、可复用的新系统，目前全校其他团队已开始采纳这些新技术。

敏捷推崇在更广泛利益相关方之间建立开放、高效且赋权的沟通机制。这一跨职能特性支持组织各部门代表参与 Scrum 后的讨论环节。通过这种方式，敏捷能够打破大型组织中可能引发问题的孤岛。

敏捷团队的分散性强调多样化的技能和灵活性，允许团队成员以最合适的方式运用其技能。这些团队同样采用自组织模式，有权根据自身专业能力自主安排冲刺计划，而非执行自上而下分派的方案。

虽然敏捷项目管理具备多重优势，但也存在潜在的缺陷。在某些情况下，敏捷实践的成效可能并不理想，或者可能需要进行调整以满足组织的需求。

在项目生命周期内，组织依赖迭代方法、持续改进和频繁发布，因此很难预测项目何时能“完成”，或需要投入多少成本。瀑布等系统中的严格路线图采用简单的达标/未达标评判标准：产品必须在截止日期前完成，否则即视为未达标。在敏捷实践中，项目始终处于持续进行和优化的状态。

虽然不可预测性是一项挑战，但敏捷方法往往更适合应对现实困境，而非强行扭转本质上陷入混乱局面的项目周期。从某种意义上说，敏捷方法可能仅仅与“混乱”相关，因为它们是应对这一局面最有效的方法。

随着组织内部更多意见的输入，加上敏捷冲刺固有的适应性，项目很容易陷入范围蔓延的困境。团队可能会不断追加功能，着力解决次要问题，导致项目缓慢推进，但必然演变为与团队初衷相异且规模超出预期的产物。

为了解决这个问题，必须定期处理范围蔓延。任何新功能都必须经过评估，判断其属于核心需求还是冗余设计。

敏捷项目管理方法论是跨职能、自主和自我激励式团队成员的理想选择。各个团队都采用自组织模式，团队成员则会按要求履行各种职责。这种敏捷性需要特定、灵活的思维方式，并非所有团队成员都能在此情境下发挥最佳表现。有效的团队负责人可以帮助团队掌握如何在敏捷环境中做出调整并持续前进。