译自 Agile Reinvented: A Look Into the Future，作者 Dave Ross。
敏捷方法论在 20 多年前彻底改变了软件开发，并随着技术进步和业务实践的变化不断发展。事实上，敏捷目前正经历着一段收缩和不确定时期, 一些人质疑其相关性，而另一些人则找到方法根据自身需求重塑敏捷。
我看到软件团队从“大 A”敏捷（严格遵循重复的框架和实践）演变为“我们这里不叫它敏捷”。作为一名 Scrum Master，我加入了一个高度技术化的团队，他们声称自己讨厌敏捷，但实际上一直在做"敏捷式"的事情——比如灵活的迭代开发，作为一个小而强大的团队，他们快速调整以交付有价值的定期发布——所有这些都没有经过 Scrum 的传统流程。他们实践了敏捷的本质，没有所有花哨的东西——并且有证据证明它有效。
尽管如此，在这样的演变中，敏捷所基于的原始原则——包括灵活性和以人为本——仍然指导着团队追求构建下一个重大事物。
敏捷诞生于 2001 年，挑战了传统的软件开发理念。作为瀑布模型的替代方案，它引发了工作方法、客户互动、技术流程和产品交付方面的改进浪潮。
从那时起，技术领域发生了巨大变化，许多人现在开始质疑敏捷的作用。一些开发人员，尤其是年轻的开发人员，将敏捷视为过时且不灵活。
但是，敏捷的核心不是一组僵化的规则，也不是一个万能的框架。它是一种方法和一种理念，赋予团队拥抱变化、协同工作并持续交付价值的能力。
近几十年来，这些价值观已成为软件团队工作方式的基础元素，以至于人们可能甚至没有意识到自己在使用敏捷的某些方面。他们可能称自己为“以产品为中心的组织”，但他们在拥抱迭代开发、客户协作和持续改进的过程中，实际上是在拥抱敏捷的核心价值观。
如今，敏捷通常不是作为固定框架，而是作为一种可塑的方法，团队可以根据自己的独特需求进行调整。这导致了许多敏捷方法论的出现，旨在解决特定环境和需求。
事实上，一些团队和组织实践“自助餐式敏捷”，或者根据自己的需求结合来自各种敏捷方法论的元素或仪式。ScrumBan 是一种越来越流行的方法，它将 Scrum 的结构化稳定性与 Kanban 的以客户为中心和透明度相结合——两者最好的元素。另一个例子是采用 Spotify 模型的元素，例如 Squads 和 Guilds，并将它们与 ShapeUp 框架的六周开发周期相结合。
这些混合方法使团队能够享受敏捷带来的好处——更高的敏捷性、改进的协作和更好的软件质量——而不会受到单一僵化框架的限制。
不可否认，敏捷正处于一个关键的转折点，尤其是考虑到人工智能的出现。虽然没有人知道人工智能将如何长期影响敏捷，但它已经开始影响敏捷团队的结构以及成员如何开展工作，包括使用人工智能工具编写代码或编写用户故事和待办事项。
为了保持相关性和影响力，敏捷必须对不断变化的劳动力需求做出反应。尤其是年轻的开发人员，他们寻求更大的创造空间。敏捷团队组建的新方法——包括团队和组织拓扑结构或 FaST，它依赖于动态重组团队的元素而不是固定的团队结构来处理复杂的工作——正在出现，为创新创造空间。
由于敏捷建立在以人为本和适应变化的价值观之上，因此它可以而且应该继续赋予团队在组织内推动创新的能力。这是现代敏捷的核心：不是盲目地遵循一组规则，而是拥抱和适应其原则，以适应团队的独特情况。
随着敏捷的不断发展，我们可以预期它将在更多样化和创新的方式中得到应用。例如，它已经与 DevSecOps 和精益等其他方法论相交，形成了更全面的框架。它的范围将扩展到软件开发之外，并改变新的领域和行业。 敏捷的未来一片光明。它将以定制、集成和适应性为特征。拥抱这种思维方式的团队将有能力在快速变化的工作世界中取得成功。