敏捷是一个术语，描述软件开发方法，强调增量交付、团队协作、持续规划和持续学习。 敏捷术语是在 2001 年《敏捷宣言》中创造的。 宣言着手制定原则，指导更好的软件开发方法。 宣言的核心是声明四个值语句，这些语句表示敏捷运动的基础。 如文所述，宣言指出：
我们来重视：
- 个人和交互胜过流程和工具。
- 工作的软件比完备的文档更重要。
- 优先客户协作而非合同谈判。
- 更重视对变化的响应而非遵循计划。
宣言并不意味着这些语句右侧的项不重要或不需要。 相反，左侧的项更重视。
敏捷方法和做法
必须了解敏捷不是 一回事。 你不会 执行敏捷作。 相反，敏捷是推动软件开发方法的思维模式。 由于没有适用于所有情况的单个方法， 因此敏捷 术语表示与清单中的值语句一致的各种方法和做法。
通常称为框架的敏捷方法是 DevOps 生命周期阶段的综合方法：规划、开发、交付和运营。 他们规定一种方法来完成工作，并明确指导和原则。
Scrum 是最常见的敏捷框架，也是大多数人从头开始的框架。 另一方面，敏捷做法是在软件开发生命周期的各个阶段应用的技术。
- 规划扑克 是一种协作估计做法，旨在鼓励团队成员分享他们对 已完成 作的理解。 许多人发现这个过程很有趣，事实证明，它有助于培养团队合作和更好的估计。
- 持续集成 （CI）是一种常见的敏捷工程实践，涉及经常将代码更改集成到主分支中。 自动化生成会验证更改。 因此，一体化债务的减少和不断可交付的主分支。
这些做法（如所有敏捷做法）都带有 敏捷 标签，因为它们符合敏捷宣言中的原则。
什么是敏捷
随着敏捷的普及，许多陈规定型观念和误解对其有效性产生了负面阴影。 很容易说“是的，我们正在做敏捷”，没有任何责任。 请记住这一点，请考虑一些敏捷不是的事情。
- 敏捷不是 牛仔编码。 敏捷不应与“我们会在进行软件开发时弄清楚”方法混淆。 这种想法不能离真相更远。 敏捷要求对每个冲刺中提供给客户的已完成值和显式值 的定义 。 虽然敏捷价值观是个人和团队的自主性，但它强调保持一致的自主性，以确保提高自主性产生更高的价值。
- 敏捷并非没有严格和规划。 相反，敏捷方法和做法通常强调规划中的纪律。 关键是在整个项目中持续规划，而不仅仅是提前规划。 持续规划可确保团队能够从他们执行的工作中吸取教训。 通过这种方法，他们最大限度地利用规划的投资回报（ROI）。
“计划毫无价值，但规划是一切。” — 德怀特·艾森豪威尔
- 敏捷并不是缺乏路线图的借口。 这种误解可能对敏捷运动整体造成最大的伤害。 遵循敏捷方法的组织和团队绝对知道他们要去哪里，以及他们希望实现的结果。 将更改识别为过程的一部分不同于每周、冲刺或月份以新方向透视。
- 敏捷不是没有规范的开发。 任何项目中都需要使团队保持一致 ，了解工作发生的原因 和 方式 。 规范的敏捷方法包括确保规范 大小正确，并适当反映团队对工作进行排序和交付的方式。
- 敏捷无法容纳计划外的工作和其他中断。 请务必按计划完成冲刺。 但是，仅仅因为出现一个问题，侧跟踪开发并不意味着冲刺必须失败。 Teams 可以通过提前为问题和意外问题指定资源来规划中断。 然后，他们可以解决这些问题，但可以继续跟踪开发。
- 敏捷不适用于大型组织。 常见的抱怨是，协作是敏捷方法的关键组成部分，在大型团队中是困难的。 另一种抓地力是，敏捷的可缩放方法引入了破坏灵活性的结构和方法。 尽管存在这些误解，但可以成功缩放敏捷原则。 有关克服这些困难的信息，请参阅 将敏捷缩放到大型团队。
- 敏捷性效率低下。 为了适应客户不断变化的需求，开发人员每次迭代都会投入时间来演示工作产品并收集反馈。 的确，这些工作减少了他们在开发上花费的时间。 但尽早合并客户请求可以节省大量时间。 当功能与客户的愿景保持一致时，开发人员避免在行内进行重大改革。
- 敏捷不适合当今的应用程序，通常以数据流为中心。 此类项目通常涉及比用户界面更多的数据建模和提取转换-加载（ETL）工作负载。 这一事实使得很难以一致、严格的计划展示可用的软件。 但是，通过调整目标，开发人员仍然可以使用敏捷方法。 开发人员可以专注于运行数据试验，而不是完成每次迭代的任务。 他们不必每隔几周提供一个工作产品，而是为了更好地了解数据。
为什么是敏捷？
那么，为什么有人会考虑敏捷方法？ 很明显，过去10-15年，围绕构建软件的参与规则已经从根本上改变了。 许多活动看起来相似，但我们应用它们的环境和环境明显不同。
- 将今天购买软件与 2000 年代初的类似情况进行比较。 人们多久开车去商店购买商业软件？
- 考虑如何从客户那里收集有关产品的反馈。 团队如何了解人们在社交媒体前对软件的看法？
- 考虑团队想要更新和改进其交付的软件的频率。 每年的更新在现代竞争中不再可行。
Forrester 的迭戈·洛·吉迪斯在他的博客《 转换应用程序交付 》（2020年10月）中说得最好。
“一切都发生了巨大的变化。 可持续性，除了绿色和清洁，意味着我们今天建造的东西必须轻松和迅速地改变明天。 战略计划是短期的，规划和变革是连续的。
这些规则已经改变，世界各地的组织现在相应地适应软件开发的方法。 敏捷方法和做法不承诺解决每个问题。 但他们确实承诺建立一个文化和环境，其中解决方案通过协作出现，持续规划和学习，并渴望更频繁地交付高质量的软件。
后续步骤
决定将敏捷路由迁移到软件开发可能会引入一些有趣的机会来增强 DevOps 流程。 一个关键的注意事项集侧重于 敏捷开发 如何与组织的当前方法进行比较和对比。