通过

什么是敏捷？

  • 项目

Diagram that shows various aspects of Agile feeding into each other, such as collaboration, development, and automated version control and deployment.

敏捷是一个描述软件开发方法的术语，它强调增量交付、团队协作、持续规划和持续学习。 敏捷这个术语是 2001 年在敏捷宣言中提出的。 该宣言致力于确立一些指导原则，以便更好地指导实现软件开发。 作为其核心，该宣言声明了四个价值表述，从而作为敏捷运动的基础。 如文中所述，该宣言指出：

我们应重视：

  • 个体和交互胜过流程和工具。
  • 有效用的软件胜过全面的文档。
  • 客户协作胜过合同协商。
  • 响应变化胜过遵循计划。

宣言并未暗指这些表述右侧的项目就不重要或不需要。 相反，左侧的项目更有价值。

敏捷方法和做法

必须了解敏捷不是一种事务。 你无法执行敏捷。 相反，敏捷是推动软件开发方法的一种思维模式。 由于没有适用于所有情况的单一方法，因此敏捷一词表示与声明中的价值表述相一致的各种方法和做法。

通常被称为框架的敏捷方法是 DevOps 生命周期阶段的各种综合方法，这些阶段包括规划、开发、交付和运营。 它们为完成工作提供了附带明确指导和原则的方法。

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

  • 规划扑克是一种协作估计做法，它旨在鼓励团队成员分享他们对已完成工作的理解。 许多人发现此流程非常有趣，而事实也证明，它有助于培养团队合作和更好的估计。
  • 持续集成 (CI) 是一种常见的敏捷工程实践，它涉及频繁将代码更改集成到主分支中。 自动化构建会验证更改。 因此，集成债务会减少，同时还会形成一个可持续交付的主分支。

这些做法（例如所有敏捷做法）都附带敏捷标签，因为它们符合“敏捷宣言”中的原则。

敏捷无法完成什么？

随着敏捷的普及，很多陈规和误解对其有效性产生了负面阴影。 我们很容易听到“是的，我们正在实施敏捷”，但却没有任何问责。 请记住这一点，请考虑一些敏捷无法完成的事情。

  • 敏捷不是牛仔编码。 敏捷不应与“我们会在途中弄清楚”这一软件开发方法相混淆。 这样的想法与事实相去甚远。 敏捷要求对每个冲刺中提供给客户的已实现的价值和明确的价值进行定义。 虽然敏捷重视个人和团队的自主性，但它更强调保持一致的自主性，从而确保更高的自主性能带来更高的价值。
  • 敏捷并非缺乏严格和规划。 相反，敏捷方法和做法通常十分强调规划中的纪律。 关键是在整个项目中持续规划，而不仅仅是提前规划。 持续规划可确保团队能从他们执行的工作中吸取教训。 通过此方法，他们可最大限度地利用规划的投资回报 (RoI)。

“计划毫无价值，但规划却是一切。”— Dwight D. Eisenhower

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

为什么采用敏捷？

那么，为什么有人会考虑使用敏捷方法？ 很明显，过去 10-15 年间，围绕构建软件的参与规则已发生根本性变化。 很多活动看似相似，但我们应用它们的场景和环境却明显不同。

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

Forrester 的 Diego Lo Guidice 在他的博文《转换应用程序交付》（2020 年 10 月）中说得最为精彩。

“一切都发生了巨大变化。 可持续性意味着，除了绿色和清洁，我们今天建造的东西必须能轻松、迅速地改变明天。 战略计划是短期之举，规划和变革才能连续。”— Diego Lo Guidice，Forrester

这些规则已经改变，全球各地的组织现在都在相应地调整其软件开发方法。 敏捷方法和做法无法承诺解决每个问题。 但它们确实承诺建立起一个文化和环境，其中的解决方案会通过协作、持续规划和学习以及渴望更频繁地交付高质量软件等方式来产生。

后续步骤

决定将敏捷路径迁移到软件开发可能会带来一些有趣的机会来增强 DevOps 流程。 其中关键的一系列注意事项侧重于敏捷开发如何与组织的当前方法进行比较和对比。