敏捷过程

添码座原创大约 7 分钟

什么是敏捷过程

现实世界唯一不变的就是一直在变，软件开发也是如此，新的语言，新的方法，新的思想不断出现。

除了 按“步”就班 的瀑布模型和 唯“例”是图 的RUP这两大重量级过程以外，一些小型化、轻量级的软件过程也迅速发展起来。

因为，除了那些大型的、关乎国计民生的重量级软件项目，更多的是一些面向中小型企业乃至个人的应用。例如，某个零售店的收费系统、某家公司的考勤系统、某个图书馆的借阅系统和某所大学的教务系统等。这些应用系统的需求和那些大系统相比完全不在一个数量级上，有的甚至连正式的需求文档都没有。

尤其是在互联网应用开始兴起，逐渐成为软件开发的主流应用之后，这种情况就更加普遍。相对于那些文档、报告和各种交付件来说，客户、老板和工程师们都更倾向于立马得到看得见摸得着的可运行系统——效率高于一切。

在这种背景下，2001年，17位国际软件开发专家聚集在美国犹他州，讨论了他们对于软件开发的各种想法和实践经验，并据此达成了价值观和原则的共识，之后共同发布了世界上第一份敏捷软件开发宣言和相应的十二条敏捷开发原则。

敏捷宣言和价值观都充分说明，它重视变化，重视迭代，重视团队协作和沟通反馈，强调快速变化和持续改进，它的核心理念包括下面几个方面。

迭代开发，敏捷过程将软件开发过程分为多个短周期，称之为迭代周期。每个迭代周期通常持续1到4周。在每个迭代周期结束时，开发团队将会交付一个可用的、经过测试的且可发布的软件版本，这有助于快速验证需求、减少风险，并使客户能够及时体验并提出反馈。
快速反馈，鼓励与客户和用户保持紧密沟通，及时获取反馈。这样一来，团队就可以及时调整开发方向，避免无用功，确保软件符合客户需求。
持续改进，通过定期的回顾会议和迭代总结，让工程师们可以发现问题、找到改进的方法和提高软件质量，并在下一个迭代中应用这些改进。
团队协作，鼓励团队内部、团队与客户之间相互理解支持，以实现项目的成功。
自组织和管理，团队成员应该具有一定的自主权和决策权，避免因外部管理问题而影响开发效率。

Agile和Scrum

需要注意和说明的是，敏捷（Agile）是一种思维方式或开发理念，而Scrum则只是一种实现敏捷的具体方法（实现敏捷的方式并非只有Scrum一种）。

Agile和Scrum之间的关系类似于微服务和Spring Cloud之间的关系。只是因为Scrum应用较为广泛，所以在大多数场合下，Agile和Scrum这两者之间互相替代也没什么问题。

因此，Scrum无疑是敏捷过程里最成功的那一个。

Scrum的概念最早来源于精益生产，它将产品开发比作橄榄球比赛中球队的集体争球，强调团队需要在短时间内合作才能完成任务。这种灵活的、迭代的方法后来被引入了软件开发领域，由此形成了现在人们所熟知的Scrum方法。

Scrum的基本原则是将整个开发过程划分为若干短小的迭代周期，这被称为冲刺（Sprint），它通常为2到4周。
在每个冲刺开始之前，Scrum教练（Scrum Master）会制定一个冲刺计划（Sprint Planning），明确冲刺目标和计划如何实现，而产品负责人（Product Owner）则会事先将已确认的需求分解成一份产品待办清单（Product Backlog）。
Scrum教练和产品负责人是两个不同的角色，这两个角色可以是同一个人，也可以不是。
在冲刺期间，开发人员（Developers）会完成一批由产品负责人根据价值排序原则从产品待办清单中列出的用户故事（User Story）清单，这个清单也叫冲刺清单（Sprint Backlog）。
每个冲刺都以一个可交付的、经过测试的软件产品增量（Product Increment）版本作为结束。
开发人员每天进行短暂的站立会议（Daily Stand-up），以便及时沟通、解决卡点问题和互相通报进度，会议时间一般不超过15分钟。
Scrum强调团队的自组织管理和持续改进能力，同时也通过定期的评审会议（Sprint Review）和回顾会议（Sprint Retrospective）来总结经验教训，不断改进工作方式。

在我个人关于敏捷的实践过程中，见到过很多工程师、客户，包括老板都对敏捷存在不少误解，其中最大一个误解就是：先进的新东西永远是好的，而且那么多大厂都成功实践了，我们也要用。

其他敏捷实践

除了Scrum外，敏捷软件开发的方法论中还包括另外极限编程和敏捷看板。

极限编程（eXtreme Programming，XP）在软件开发中较为知名，因为它最大的特色之一就是结对编程：两名工程师在同一台计算机上完成同一个功能，解决同一个问题。除了此之外，诸如测试驱动开发（Testing Driven Development，TDD）、短交付周期、持续集成等手段，都是XP的基本配置了。