什么是敏捷方法论？

在回答"什么是敏捷方法论？"这个问题时，我将努力澄清一些往往会造成障碍的语言挑战。例如，Agile（大写A）和agile（小写a）之间有什么区别吗？  我们所说的方法、框架或方法论是什么意思，这重要吗？

对于上述问题的看法各不相同，所以我将使用敏捷性这个概念来帮助回答，因为这个词超越了所有这些争议，不会引起争议。

敏捷性被定义为快速轻松地思考和行动的能力。在规划和执行工作的背景下，敏捷性包含了持续变化的概念。在存在一定程度的波动性、不确定性、复杂性或模糊性的环境中，刚性的详细计划难以制定和执行，此时敏捷性尤其有价值。

有些人将"敏捷"视为定义一种工作方式，而有些人则将其视为描述一种思维或行为方式。有些人甚至试图通过"Agile"与"agile"的大小写来区分这两者。仅这一点就能引发数小时有时颇为有趣、但更多时候令人沮丧的辩论，争论哪一个更重要或更有价值——是"做敏捷"还是"成为敏捷"？

就我个人而言，我更愿意专注于共同点——认识到思考和行动是紧密相连的。事实上，根据前面对敏捷性的定义，特别是与响应性相关的方面，在没有思考的情况下"做敏捷"甚至应该是不可能的。同样，如果没有后续行动，思维上的敏捷性就没有实际价值，除了或许通过观察学习。因此，任何真正敏捷的工作方式都需要结合人的视角和流程视角，才能做到有效。

在分享我对此的看法之前，最好先说明一下，方法、框架和途径这些词通常与方法论互换使用。

框架最常用于品牌化语境中，例如，Scrum、AgilePM 和 SAFe 都将自己描述为框架。其他术语更多用于谈论敏捷性的一般概念时。

最好的敏捷框架描述了价值观、原则、流程、实践、角色、职责以及支持性工作产品或工件的具体组合。价值观、原则、角色和职责涉及敏捷的人文方面，而流程、实践和工作产品则为交付提供结构和机制。

一些最受欢迎的敏捷框架包括：

Scrum 是一个主要用于产品开发的敏捷框架。它起源于软件开发领域，至今仍主要在该领域使用。与常见的理解相反，它并不是一种项目管理方法论，因为它不涉及项目管理的任何方面。它专注于产品交付，这正是它真正擅长的领域。

Scrum 包含一套5个价值观（承诺、专注、开放、尊重和勇气），强调敏捷开发中的人文方面。这些价值观描述了一套理想的行为准则，Scrum 团队中的每个人都应该努力践行并相互支持。Scrum 还在框架内定义了三个角色：

• 一位产品负责人，负责识别和排列工作优先级，以尽早并持续地交付最优价值；
• 多位开发人员，他们自组织地交付产品的有价值增量；以及
• 一位 Scrum Master，帮助整个团队从 Scrum 所描述的敏捷工作方式中获得最大收益。

产品交付是通过一个简单重复的开发周期来协调的，这个周期被称为Sprint。Sprint通常很短——持续时间为一个月或更少。每个周期都以活动（简短、集中的会议）开始，以达成一致并规划工作。它以活动结束，用来回顾已交付的内容，并探索如何改进产品和工作方式。每天都有一个15分钟的每日Scrum会议，供开发人员使用，以保持对交付其已商定的Sprint目标的专注，并相应地调整其计划的细节。

Scrum强调在其过程控制中的经验主义——这是真正敏捷方法论的另一个关键人文基础。随着开发的进行，团队应该利用Scrum活动和工件所提供的透明度。基于对这些的检视，他们应该持续调整正在做的事情，以优化价值交付。透明度、检视和适应是经验过程控制的三大支柱。

有些人认为看板是一种精益开发方法，而不是敏捷方法。虽然这种观点在技术上可能有其道理，但对于大多数目的来说，这并不重要。与Scrum一样，看板描述了一种专注于尽早且频繁地交付价值的工作方式，鼓励团队成员之间的协作，并授权他们管理工作的细节。

Scrum和看板之间的一个关键区别是，看板流程是工作的持续流动，而不是重复的周期。团队成员一旦完成前一项工作，就会从待办事项中取出一个工作项。与偏好团队成员具备跨职能能力（多技能）的Scrum不同，在看板中，从一个人到另一个人的工作移交更为常见。在制品数量（WiP）被有意限制，当达到WiP限制时，这鼓励团队成员协作解决问题。

看板的人类行为方面由六个核心实践指导：可视化工作；限制在制品；管理流动；明确政策；实施反馈循环；协作改进；以及实验性演进。

与Scrum一样，维护一个有序的待办事项列表来指导和塑造开发人员的工作。与Scrum不同，规划、评审和回顾并不与开发周期绑定。然而，这些在看板中确实存在类似物，通常按照预先约定的节奏组织，包括每日站会。下表描述了Scrum事件及其看板对应物。

SAFe——规模化敏捷框架——有些不同，因为正如其名称所示，它解决的是更宏观的问题。它专门设计用于在大型企业中规模化敏捷实践。

虽然Scrum和Kanban非常适合单个团队，但SAFe提供了一个结构来协调多个敏捷团队，通常跨部门和价值流，交付复杂的产品和解决方案。

SAFe基于基础的敏捷和精益原则——借鉴了Scrum、Kanban和精益产品开发等框架——并将它们整合到结构化的层次体系中。它不仅解决团队级别的交付问题，还涉及战略一致性、治理、预算和跨团队协作。

SAFe中的关键角色包括：

• 敏捷团队（遵循Scrum或Kanban），
• 产品负责人和Scrum Master（在团队层面），
• 发布火车工程师（RTE）——敏捷发布火车（ART）的敏捷风格领导者，
• 产品管理和系统架构师/工程师——跨团队协调优先级和架构，
• 精益组合管理——将投资与战略保持一致。

工作在项目增量（PI）中进行规划和交付——通常为8-12周——并围绕基于节奏的定期活动进行结构化：

• PI规划——大规模的面对面规划会议，使所有团队在目标和依赖关系上保持一致，
• 系统演示——展示跨团队的集成进展，
• 检视与适应——用于持续改进的结构化回顾。

SAFe鼓励精益敏捷领导、持续学习文化和以客户为中心的思维。虽然比Scrum或Kanban更具规范性，但SAFe为规模化提供了支架，使组织能够在管理企业级复杂性和一致性的同时保持敏捷性。

AgilePM还有一个不同之处，即它专注于项目而非产品环境，处理项目管理的所有经典方面，但采用根本上敏捷的方式。它平衡了敏捷性的所有好处与传统项目管理学科的严谨性。

它特别适合政府、金融服务或其他受监管行业等组织，这些组织需要利益相关者保证、明确的角色和职责以及受控的交付环境。

AgilePM包含了扩展到多个自组织团队的要素，并专注于价值交付。然而，与大多数敏捷方法不同的是，它关注成果而非产出，涵盖了实现价值所需的所有工作，而不仅仅是交付应该有价值的东西。

像任何优秀的敏捷框架一样，它包含人员和流程要素，所有这些都在下面的图表中进行了识别。

在总结了一些最重要的敏捷框架之后，现在是时候回到"方法论"这个术语了。

对许多人来说，方法论只是框架的另一种说法，但我更愿意深入探讨这个词可能传达的额外价值。许多资料将方法论定义为"方法的研究、分析或应用"。因此，在这种语境下，敏捷方法论可能与框架有些许不同的解读，它包括对特定框架为什么有效以及为什么能起作用的真正理解。

最近，一些组织似乎对"敏捷"感到失望，往往放弃了未能兑现承诺的重大投资。这是为什么呢？是因为敏捷框架不起作用吗？是因为承诺过多吗？还是因为对方法论缺乏关注？

自1990年代中期敏捷兴起以来，我一直参与其中，实施、调整甚至创造敏捷框架。经历过，有时还领导过通过敏捷性提高绩效的各种举措——有好的、坏的和糟糕的，我认为最后一种可能最接近真相。

正如我之前提到的，任何敏捷框架的人员和流程两个维度都需要考虑。流程部分很简单……从优先级排序的工作待办列表中进行短期冲刺，在开发过程中频繁进行产品评审，每天举行15分钟的团队"站会"等等。

人员部分则要复杂得多。如果要实现任何框架的潜力，就需要真正理解敏捷工作方式的个人和人际关系层面。这些包括：

所有敏捷方法都强调团队层面的自我组织（或自我管理）。其背后的假设是，最接近工作的人应该最有资格决定完成工作的最佳方式。再加上需要快速响应工作环境中相对较小的变化，自我组织就成为敏捷工作方式的核心要素。  这包含两个维度：赋权和责任感。

赋权涉及团队和团队内个人拥有的自主权和自决权程度。它需要在围绕做什么、何时做以及如何做来实现既定目标的权威与有效完成这些工作的能力之间取得平衡。 

这与责任感形成平衡。以这种方式被赋权并对其工作承担责任的个人和团队，相比那些工作受他人控制的人，表现出更好的绩效和生产力，以及更高的工作满意度。

因此，一个优秀的敏捷领导者（传统上是经理）将努力确保其团队获得最佳的赋权。

人类区别于大多数其他动物物种的特征之一，是我们能够通过协作来解决问题。协作得益于我们在沟通方面的高级技能——主要是我们通过语言分享想法和观念的能力。所有敏捷方法的核心都是协作工作，并依赖于透明度，这种透明度由关于所承担工作各个方面的清晰、开放、诚实的沟通来支撑。这是敏捷团队内部的基本要求，也应该成为对外沟通的默认方式。

这就是方法论真正发挥作用的地方……敏捷转型举措失败的主要原因之一，源于缺乏智能、务实的应用。这又回到了敏捷性极其重要的人文基础。如果你把Scrum、AgilePM或任何其他敏捷框架纯粹当作一套要遵循的流程，你不太可能从中获得多少价值。

任何敏捷框架的完全成功都需要经验主义。也就是说，它需要持续的透明度以及不断的检视和适应：

• 对所遵循的方法和朝着预期目标取得的进展的透明度都是至关重要的。这是必要的，以便允许……
• 对这两者进行检视。具体来说，分析参与的每个人是否理解工作方式并正确应用所选择的框架，以及产出和结果是否符合预期。这对于实现有效的……是必要的
• 适应。这可能也涉及到人员或流程的适应。
  • 刚接触敏捷工作方式的人可能会发现它与他们以前的工作方式截然不同。团队成员和团队外部的利益相关者都可能需要调整他们的工作方式。
  • 框架中的默认流程和实践可能需要进行调整以获得最佳结果。任何能让团队在实现业务最终目标方面更加高效有效的调整都应该被考虑。在敏捷性方面，在这方面不应该害怕实验。

AgilePM是第一个，也可以说是敏捷项目管理的最佳框架。它将敏捷项目管理描述为一种灵活且迭代的项目管理方法。它旨在应对现代动态环境的挑战。AgilePM专注于早期且持续地交付业务价值，同时在整个项目生命周期中拥抱变化和不确定性。与依赖详细前期规划并假设环境稳定的传统方法不同，AgilePM旨在在易变性、不确定性、复杂性和模糊性(VUCA)的条件下蓬勃发展。

在敏捷项目中，人员、协作和可工作的解决方案比僵化的流程和文档更受重视。AgilePM将敏捷宣言的价值观——所有真正的敏捷方法都遵循这些价值观——整合到更广泛的项目环境中，从软件开发扩展到适用于各种业务项目。

AgilePM强调业务解决方案的迭代开发、工作的时间盒以及频繁的利益相关者参与，以确保解决方案根据现实世界的反馈而不是早期定义的固定需求进行演进。但AgilePM的作用不止于此。它不仅限于监督产品开发，还包括通过协调资源、管理风险和维护治理来确保价值实现。该框架支持及时规划和决策制定，鼓励灵活性和适应性，同时仍然提供强有力的控制和问责机制。

总的来说，以AgilePM为代表的敏捷项目管理是一种既有纪律性又具适应性的项目方法，它在敏捷性和治理之间取得平衡。它对于预期会发生变化且以客户价值为核心关注点的项目特别有效。它通过允许组织在不损害质量或战略方向的前提下快速且负责任地响应不断变化的需求，帮助实现业务敏捷性。

业务敏捷性是组织快速适应市场和环境变化的能力，以高效且具有成本效益的方式进行。它强调响应性、创新性和以客户为中心，使组织能够在不确定性和变化中蓬勃发展。

从历史角度来看，这一概念源于阿尔文·托夫勒和彼得·德鲁克等思想家，他们强调了在快速变化面前适应性和创新的必要性。"业务敏捷性"一词在2000年代初期获得了重要地位，受到敏捷软件开发运动的影响，此后已发展为涵盖更广泛的组织实践。

业务敏捷性的关键方面包括：

• 客户焦点： 敏捷组织优先考虑高效地为客户提供价值，利用持续反馈来增强客户体验。
• 灵活性和适应性： 这类组织能够迅速调整流程和结构，以应对细微变化和重大变革，依靠被赋权的员工做出明智的决策。
• 运营效率： 通过简化流程和减少浪费，敏捷企业实现效率，通常通过赋权团队掌控其工作流程来实现。

业务敏捷性并非一刀切的方法；它在不同组织之间以及同一组织的不同领域内都有所不同。这是一个持续的旅程，需要一种支持持续学习和适应的文化。实施像Scrum这样的敏捷框架可以是一个起点，但真正的敏捷性涉及整个组织的思维方式转变。

最终，业务敏捷性通过使组织能够迅速响应市场需求、持续创新并为客户提供持续价值，从而提供竞争优势。

许多人交替使用敏捷方法论、敏捷方法和敏捷框架这些术语。这没有问题——这就是世界的现状。话虽如此，我认为方法论意味着对方法和框架为什么以及如何运作进行更深入的探讨。

许多人通过相对"不假思索地"实施诸如Scrum或AgilePM等"开箱即用"的敏捷框架，能够在绩效上取得适度的改善。对许多人来说，这样的回报就足够了，但对于那些被彻底改善的梦想所打动的人来说，"活出敏捷"而不是"实行敏捷"是至关重要的下一步。

这可以通过利用所有最佳框架的经验基础来实现——通过充分利用透明度，以及通过检查和实验性适应进行学习，这些都是敏捷工作方式的基础。

虽然显著的改善可以相对快速地实现，但拥抱敏捷性并不总是容易的，因为它通常需要交付团队内部和周围的行为改变。优化敏捷性是一个永无止境的旅程，值得注意的是，在工作方式的人文方面而非流程方面进行适应，可能会带来最丰富的回报。