敏捷和devops区别

通往DevOps的持续创新之旅就是如此-连续-意味着您不可能到达目的地。

如下图所示，整个旅程的步骤是： 评估组织与行业内其他组织并进行比较，确保人们参与到转型中，引入能够使团队取悦利益相关者，不断创造价值的工程流程和产品。 ，并将解决方案从数百个用户扩展到数百万个用户。 从概念上讲，任何组织的转型都应该相同。

^{DevOps转型之旅}

但是，在拥有少量工程师的公司中，DevOps转型与拥有数百或数千名工程师的公司完全不同。

本能地，对于小型组织而言，DevOps之旅应该最容易，因为它们通常充满激情和对变革的渴望。 但是，小型组织倾向于在资源，基础架构和预算方面受到更大的限制，而大型组织则倾向于拥有更多影响转型的政策，治理和政治。

那么，大小有什么关系呢？ 这是社区成员在民意测验中关于规模如何影响转换难易度的看法。

^{根据组织规模接受DevOps的能力}

小型和新兴组织

在小型组织中，管理和工程职责范围趋于模糊，这自然会创建一个精益的环境。 同样，由于资源稀缺，工程通常会戴上多个技术和操作帽，从而有机地建立了负责其解决方案的跨职能团队。 此外，小型和新兴组织中通常对新产品和新Craft.io充满热情和胃口，这使得他们成为向DevOps思维方式转变的理想人选。 此外，DevOps转型已成为与大型竞争对手竞争的必要条件。

由于小型组织的管理和工程精益管理，重要的是要确保有一个清晰的愿景，授权和负责工程，尊重自主权以及积极进行反馈和快速故障处理。 当现场事件影响用户体验时，还需要有一个清晰的“凌晨2点呼叫”流程-在许多情况下，即使是小型组织的CEO也必须在备用名单上。 不愿承担跨职能职责的工程师对这些组织构成风险。 工程师必须具有正确的态度，有些工程师可能需要寻找另一个住所（无论在组织内部还是在组织内部）。 有关DevOps团队的更多信息，请参阅“ 具有DevOps心态的团队的蓝图 ”。

^{按规模划分的组织中的DevOps模式}

考虑DevOps即服务和完全嵌入式模型Matthew Skelton在“ 什么团队结构适合DevOps蓬勃发展？ ”中讨论，前一种模型非常适合小型组织，而后者则是可行的，因为Microsoft的兼职ALM | DevOps Ranger社区演示。

中型组织

中型组织不断增长的资源和预算通常会创造一种环境，政治，政策和技术治理会抬头。 您可能会找到一支专注的IT运营团队，一个或几个工程团队，以及开发和运营之间的可怕鸿沟。 这些都是孤立的环境，开发人员可以在其中构建解决方案，而IT运营人员则支持基础架构和解决方案。

中型组织必须专注于打破孤岛，创建通用语言以及建立将业务，开发和运营领导与工程结合在一起的技术治理。 谈论宣言（而不是治理）将减少工程的焦虑和阻力。

^{按规模划分的组织中的DevOps反模式}

考虑一下上面链接在“团队结构”一文中描述的临时DevOps团队 。 将开发人员和操作人员紧密联系在一起是一个不错的临时策略。

大型且成熟的组织

我们很少有人拥有像亚马逊，Facebook，谷歌或微软这样的大型组织的豪华资源和预算。 大型组织具有多样性，经验和能力，可以将其运营和开发团队分为许多小型的，专注的团队。 例如，Microsoft有几个以产品为中心的部门，例如Windows，Office和Azure DevOps，每个部门都使用一个通用的工程系统分解为许多小团队。 在统一的企业级愿景和转型策略的支持下，团队自然接受敏捷和DevOps实践。

考虑建立一个卓越社区或卓越中心来创建特殊的兴趣小组。 以这种方式利用熟练的知识工作者的思想领导力可以启用并为组织提供最佳实践。 这些团队还支持DevOps即服务模式的概念，以帮助将组织提升到更高的知名度和成熟度水平，共享知识，减少浪费并进行创新。 确保您有业务，开发和运营方面的代表！ 尽管所有类型的组织都将从DevOps即服务中受益，但预算和人员资源需求使其仅适用于中型和大型组织。

一些大型组织感觉像是中型组织，具有孤立的领导，业务，运营和开发团队，只是规模更大，更孤立。 他们面临的挑战包括：鼓励整个组织考虑并接受DevOps的实践；将组织业务的口语翻译成一种通用语言；引入不熟悉的概念，例如Scrum，看板，冲刺节奏，短交付周期，快速而轻量级的反馈循环以及持续的实验。在生产中。 虽然许多组织看到将开发和运营紧密结合的价值，但您会遇到瀑布团队的阻力，这些团队习惯于严格的顺序，详细且可预测的范围以及以里程碑为重点的项目。 您可能还会遇到领导层无意间干扰工程团队的情况，从而模糊了将WHAT和WHY（由领导层拥有）与HOW和WHEN（由工程部门拥有）区分开的自治线。

Skelton在他的博客中讨论的完全嵌入式或平滑协作模型在自然拥护DevOps的大型组织中被证明是成功的。 对于其他人， DevOps即服务和临时DevOps团队模型非常适合将异类团队紧密联系在一起。

正确的策略

^{DNA：文化，领导力，流程和团队}

每个组织都是不同的，并且评估正确的策略是多种特征的组合，而与规模无关。

^{DevOps中的人员，流程，产品挑战}

对组织的人员 ， 流程和产品进行评估，以揭示其文化，领导才能，团队和对变革的渴望，这一点很重要。 更重要的是，评估将突出自然变化的领域以及您需要深思熟虑培养的领域。

核心是人和他们的文化，而不是组织的规模，使组织与其他组织之间形成差异。

有关 更多信息，请浏览Microsoft Azure的DevOps资源中心，获取有关转换和采用DevOps的视频和文章的集合，包括经验教训。

接下来要读什么

翻译自: https://opensource.com/article/19/1/devops-small-medium-large-organizations

敏捷和devops区别