培训
认证
Microsoft Certified: DevOps Engineer Expert - Certifications
此认证测试你是否能够完成以下技术任务:设计和实现流程和通信;设计和实现源代码管理策略;设计和实现生成和发布管道;制定安全性和合规性计划;实施检测策略。
敏捷是一个描述软件开发方法的术语,它强调增量交付、团队协作、持续规划和持续学习。 敏捷这个术语是 2001 年在敏捷宣言中提出的。 该宣言致力于确立一些指导原则,以便更好地指导实现软件开发。 作为其核心,该宣言声明了四个价值表述,从而作为敏捷运动的基础。 如文中所述,该宣言指出:
我们应重视:
宣言并未暗指这些表述右侧的项目就不重要或不需要。 相反,左侧的项目更有价值。
必须了解敏捷不是一种事务。 你无法执行敏捷。 相反,敏捷是推动软件开发方法的一种思维模式。 由于没有适用于所有情况的单一方法,因此敏捷一词表示与声明中的价值表述相一致的各种方法和做法。
通常被称为框架的敏捷方法是 DevOps 生命周期阶段的各种综合方法,这些阶段包括规划、开发、交付和运营。 它们为完成工作提供了附带明确指导和原则的方法。
Scrum 是最常见的敏捷框架,也是大多数人最初使用的框架。 另一方面,敏捷做法是在软件开发生命周期的各个阶段采用的技术。
这些做法(例如所有敏捷做法)都附带敏捷标签,因为它们符合“敏捷宣言”中的原则。
随着敏捷的普及,很多陈规和误解对其有效性产生了负面阴影。 我们很容易听到“是的,我们正在实施敏捷”,但却没有任何问责。 请记住这一点,请考虑一些敏捷无法完成的事情。
“计划毫无价值,但规划却是一切。”— Dwight D. Eisenhower
那么,为什么有人会考虑使用敏捷方法? 很明显,过去 10-15 年间,围绕构建软件的参与规则已发生根本性变化。 很多活动看似相似,但我们应用它们的场景和环境却明显不同。
Forrester 的 Diego Lo Guidice 在他的博文《转换应用程序交付》(2020 年 10 月)中说得最为精彩。
“一切都发生了巨大变化。 可持续性意味着,除了绿色和清洁,我们今天建造的东西必须能轻松、迅速地改变明天。 战略计划是短期之举,规划和变革才能连续。”— Diego Lo Guidice,Forrester
这些规则已经改变,全球各地的组织现在都在相应地调整其软件开发方法。 敏捷方法和做法无法承诺解决每个问题。 但它们确实承诺建立起一个文化和环境,其中的解决方案会通过协作、持续规划和学习以及渴望更频繁地交付高质量软件等方式来产生。
决定将敏捷路径迁移到软件开发可能会带来一些有趣的机会来增强 DevOps 流程。 其中关键的一系列注意事项侧重于敏捷开发如何与组织的当前方法进行比较和对比。
培训
认证
Microsoft Certified: DevOps Engineer Expert - Certifications
此认证测试你是否能够完成以下技术任务:设计和实现流程和通信;设计和实现源代码管理策略;设计和实现生成和发布管道;制定安全性和合规性计划;实施检测策略。