什么是敏捷?

显示敏捷相互馈送的各个方面的关系图,例如协作、开发和自动化版本控制和部署。

敏捷是一个术语,描述软件开发方法,强调增量交付、团队协作、持续规划和持续学习。 敏捷术语于 2001 年在敏捷宣言中创造。 宣言旨在制定原则,指导更好的软件开发方法。 宣言的核心是声明四个值语句,这些语句表示敏捷运动的基础。 如书面所述,宣言指出:

我们来重视:

  • 个人和对流程和工具的交互。
  • 有效用的软件胜过全面的文档。
  • 客户协作胜过合同协商。
  • 响应对遵循计划进行更改。

宣言并不意味着这些语句右侧的项并不重要或不需要。 相反,左侧的项目更重视。

敏捷方法和做法

请务必了解敏捷不是 一回事。 你不 做敏捷。 相反,敏捷是推动软件开发方法的思维模式。 由于没有适用于所有情况的单个方法, 因此敏捷 术语表示与清单中的值语句一致的各种方法和做法。

敏捷方法(通常称为框架)是 DevOps 生命周期阶段的综合方法:规划、开发、交付和操作。 他们规定一种方法来完成工作,并明确指导和原则。

Scrum 是最常见的敏捷框架,也是大多数人从头开始的框架。 另一方面,敏捷做法是在软件开发生命周期的各个阶段应用的技术。

  • 规划扑克 是一种协作估计实践,旨在鼓励团队成员分享他们对 完成哪些操作 的理解。 许多人发现这个过程很有趣,它被证明是帮助培养团队合作和更好的估计。
  • 持续集成 (CI) 是一种常见的敏捷工程实践,涉及经常将代码更改集成到主分支中。 自动生成会验证更改。 因此,一体化债务的减少和不断交付的主分支。

这些做法(如所有敏捷做法)都带有 敏捷 标签,因为它们与敏捷宣言中的原则一致。

敏捷不是什么

随着敏捷的普及,许多刻板印象和误解对其有效性产生了负面阴影。 很容易说“是的,我们正在做敏捷”,没有任何责任。 请记住这一点,请考虑一些敏捷不是的事情。

  • 敏捷不是 牛仔编码。 敏捷不应与软件开发的“我们会在进行时弄清楚”的方法混淆。 这样的想法不能从真相中进一步。 敏捷要求定义 完成 和显式值,这些值在每个冲刺中交付给客户。 虽然敏捷价值观是个人和团队的自主性,但它强调保持一致的自治性,以确保提高自主性会产生更高的价值。
  • 敏捷并非没有严格和规划。 相反,敏捷方法和做法通常强调规划中的纪律。 关键是在整个项目中持续规划,而不仅仅是提前规划。 持续规划可确保团队能够从执行的工作中吸取教训。 通过这种方法,他们最大限度地提高了规划 (ROI) 投资回报。

“计划是毫无价值,但规划是一切。”德怀特·艾森豪威尔

  • 敏捷并不是缺乏路线图的借口。 这种误解可能对整个敏捷运动造成最大的伤害。 遵循敏捷方法的组织和团队绝对知道他们要去哪里,以及他们想要实现的结果。 将更改识别为过程的一部分不同于每周、冲刺或月份以新方向透视。
  • 敏捷不是没有规范的开发。 在任何项目中,都需要使团队与 工作原因工作方式 保持一致。 规范的敏捷方法包括确保规范 大小正确,并适当反映团队的排序和交付方式。
  • 敏捷无法容纳计划外的工作和其他中断。 请务必按计划完成冲刺。 但是,仅仅因为一个问题出现,侧轨开发并不意味着冲刺必须失败。 Teams 可以通过提前为问题和意外问题指定资源来规划中断。 然后,他们可以解决这些问题,但可以继续跟踪开发。
  • 敏捷不适用于大型组织。 常见的抱怨是,在大型团队中,协作是敏捷方法的关键组成部分。 另一种抓地力是,敏捷的可缩放方法引入了破坏灵活性的结构和方法。 尽管存在这些误解,但可以成功缩放敏捷原则。 有关克服这些困难的信息,请参阅 将敏捷缩放到大型团队
  • 敏捷性效率低下。 为了适应客户不断变化的需求,开发人员将每次迭代投入时间来演示工作产品并收集反馈。 的确,这些努力减少了他们花在开发上的时间。 但尽早合并客户请求可以节省大量时间。 当功能与客户的愿景保持一致时,开发人员可避免在行内进行重大改革。
  • 敏捷不适合当今的应用程序,通常以数据流为中心的应用程序。 此类项目通常涉及比用户界面更多的数据建模和提取转换加载 (ETL) 工作负荷。 这一事实使得很难以一致、严格的计划展示可用的软件。 但是,通过调整目标,开发人员仍然可以使用敏捷方法。 开发人员可以专注于运行数据试验,而不是完成每次迭代的任务。 他们可以更好地了解数据,而不是每隔几周提供一个工作产品。

为什么是敏捷?

那么,为什么有人会考虑敏捷方法? 很明显,过去10-15年,围绕构建软件的参与规则已经从根本上改变了。 许多活动看起来相似,但我们应用它们的景观和环境明显不同。

  • 比较今天购买软件与 2000 年代初的情况。 人们多久开车去商店购买商业软件?
  • 考虑如何从客户那里收集有关产品的反馈。 团队如何了解人们在社交媒体之前对软件的看法?
  • 考虑团队需要更新和改进其交付的软件的频率。 与现代竞争的年度更新不再可行。

Forrester 的迭戈·洛·吉迪斯在他的博客《 转换应用程序交付 》 (2020年10月) 说得最好。

“一切都发生了巨大的变化。 除了绿色和清洁,可持续性意味着我们今天建设的东西必须轻松快速地改变明天。 战略目标是短期的,规划和变革是连续的。“ — 迭戈·洛·吉迪斯,Forrester

这些规则已经改变,世界各地的组织现在相应地适应软件开发的方法。 敏捷方法和做法不承诺解决每个问题。 但他们确实承诺建立一个文化和环境,解决方案通过协作出现,不断规划和学习,以及更频繁地交付高质量的软件的愿望。

后续步骤

决定将敏捷路线带到软件开发可以引入一些有趣的机会来增强 DevOps 流程。 一个关键的注意事项集侧重于 敏捷开发 如何与组织的当前方法进行比较和对比。