什么是敏捷方法？

敏捷方法是一种软件开发方法，旨在通过快速迭代持续交付可以工作的软件项目。 

不过，"敏捷方法"一词容易让人误以为它是一种非此即彼的软件开发的方法。敏捷方法并不是一套对在软件开发中要采取哪些行动的规定。相反，它是对协作和工作流程的一种思考，也是一套指导我们在生产内容和生产方式方面如何取舍和工作的价值观。

实际上，敏捷软件开发方法的目标就是快速交付小的可以工作的软件，从而提高客户满意度。它们借助自适应方法和团队合作，从而专注于业务的持续改进。通常，敏捷软件开发的主体是由软件开发人员和业务代表组成的小型自组织团队，他们会在软件开发的生命周期内定期会面。敏捷方法支持轻量级的软件文档编制方法，并且在生命周期的任何阶段都会接受而不是抵制变更。

我们今天所谈论的敏捷开发，其历史可追溯到 2001 年。为了一改瀑布式项目管理方法（将一个软件项目划分为一系列线性流程），一群软件开发人员签署了一份"敏捷软件开发宣言"（Manifesto for Agile Software Development）。在这份文档中，程序员们提出了一种新的软件开发方法，并列出了他们认为更具价值的 4 个关键特性。正如他们所说，敏捷软件开发团队应重视：

• 个体和互动，胜过流程和工具
• 可以工作的软件，胜过面面俱到的文档
• 客户协作，胜过合同谈判
• 响应变化，胜过遵循计划

这些创作者们指出，以上所有的事项都有价值。但他们认为，相对于右侧的事项，如果能更加重视左侧的事项（以粗体显示），就能更有利于产品开发。敏捷宣言并不是规定一套操作实践；它的目的是为软件开发思路的创新提供指导。

实际上，敏捷宣言有许多实际成果。例如，相比以前从一个阶段到下一个阶段依次开发软件的方式（瀑布式方法正是藉此来确保产品质量的），敏捷方法可通过并发和持续流程来加快开发和测试工作。换句话说，瀑布式开发中，只有在完成整个阶段之后才能进入下一个阶段，而敏捷开发则支持多个序列同时进行。 

人们提出敏捷开发方法，是为了解决瀑布式开发的局限性。瀑布式开发源自亨利·福特于 1913 年创造的流水线生产方式，这种规模化的生产理念后来也应用到了软件开发。自 2001 年提出以来，敏捷开发在软件行业和项目管理中得到了蓬勃发展，它有着许多的变化形式。

随着 IT 行业的发展，许多软件开发人员意识到，瀑布式生产周期和协作方法不能实现预期结果。到了 1990 年代初，这个问题变得日益突出。当时，企业的业务需求与可工作应用的交付之间存在数年的脱节，这已成了业内的常态。在这期间，业务需求和市场有时会发生天翻地覆的变化，从而导致大量软件项目尚未交付便被取消。这种时间和资源的双重浪费促使许多软件开发人员开始寻求替代方案。

为了不被浪潮淹没，企业纷纷开采用数字化转型策略来跟上业务发展的步伐。正在此时，敏捷软件开发频频发挥作用。

敏捷方法为了当今许多数字化工作流程奠定了基础。随着人们对敏捷软件开发的需求不断增长，云计算及其灵活、可扩展的 IT 基础架构也得到了同步发展。云原生开发蕴含着类似敏捷开发的软件理念，即对一系列互联的服务进行扩展以满足业务需求。

DevOps 的理念打破了软件开发和运维之间的旧壁垒。SRE 是 DevOps 的实施，它使用软件作为工具，来管理系统并实现运维任务自动化。CI/CD 方法则是认同软件会持续变化这一事实，并提供相关的开发工具来加快部署新代码的速度。

到目前为止，您可能已经注意到："敏捷方法"的概念本身就是一种敏捷思想，意在响应客户（即软件开发人员）随时变化的需求。在我们简要介绍各种敏捷框架时，请记住这一点。这些敏捷框架有着不同的名称，而且在不同的实现方案之间往往也不同。

软件开发的敏捷框架——如 Scrum、看板或极限编程（XP）——构成了常见软件开发流程——如 DevOps 和持续集成/持续部署（CI/CD）——的基础。

Scrum 可能是当今使用最广泛的敏捷框架，但它并不是敏捷开发的全部。而且，老实说，也并非所有的 Scrum 都是敏捷的。Scrum 框架可用于管理专为 5 - 9 人的跨职能小型团队而设计的工作，团队的工作将被分解为若干可在统一的时间内完成的行动，称为"冲刺"。Scrum 团队由团队成员、Scrum 管理员和产品所有者组成。通常，当大型项目可以分解为若干 2 - 4 周的冲刺时，即可采用 Scrum。Scrum 非常看重反馈循环，并通过"回顾"的方式建立这一循环。Scrum 的非正式座右铭就是"检查和适应"。

其他敏捷框架（尤其是看板）的历史比敏捷宣言还早。但是，这些框架之所以归于敏捷，是因为它们倡导与敏捷宣言相同的价值观。有太多的敏捷框架和方法可以扩展敏捷性，无法在此一一列举。