组织尝试避免的一些陷阱：
无法跨多个开发团队一致地报告进度，例如，如果一个团队报告他们的进度就两周内完成的大小相等的故事而言；而另一个团队报告的故事点是在三个星期的冲刺中完成的。
实践的不一致应用意味着团队成员在不学习新的工作方式的情况下就无法轻易地在同一组织内的团队之间移动。
开发中的不匹配
在拥有大量开发团队（可能在多个单独的业务部门中）的组织中，可以采用一致的方式来实现一致的方式是什么？ />
#1 楼
大型企业通常会采用为支持大型企业而构建的交付框架或运营模型。从敏捷/ DevOps的角度来看，这是我的专长领域，它涉及三个感兴趣的框架：可伸缩的敏捷框架（SAFe®）将DevOps定义为通过成功运营DevOps来交付业务价值。环境中的软件。这是通过早期关注“投入生产”的行为来实现的，并部分地通过整合敏捷团队中的运营职能人员来实现。纪律严明的敏捷2.X，也称为DAD，定义了将DevOps称为“ DevOps是围绕IT解决方案开发和IT运营的活动的简化。”这是通过在企业内部的开发和运营职能之间建立反馈循环来实现的。 DAD继续将纪律化的DevOps描述为以下角色之间的交集：企业体系结构，IT运营，业务运营，发布管理，数据管理和开发。
大型Scrum并没有专门提及DevOps，发布工程或平台。工程;但是，它确实描述了在一个快速发展的组织中扩展Scrum的方法，在这些团队中集成DevOps专业知识既合乎逻辑又广为人知。
据我所知，还没有有关每个框架在企业中采用情况的统计数据，以及除敏捷实践之外是否采用了DevOps实践，但是从经验来看，许多组织似乎倾向于使用规模化敏捷框架。
Kristof Horvath讨论了该应用程序他的文章：在大型企业中扩展敏捷性：LeSS，DAD或SAFe®？中的DevOps在这些企业级敏捷框架中的研究。
值得注意的是，在企业中并不需要采用“企业级”框架，最终，敏捷，DevOps和Lean都将针对您的组织而不是最受欢迎的组织采用正确的实践。
#2 楼
您提出的所有问题似乎都不是我的DevOps特有的。组织尝试避免的一些陷阱：
无法跨多个开发一致地报告进度例如，如果一个团队根据两个星期内完成的同等大小的故事数报告了他们的进度；而另一个团队报告的故事点是在三周的冲刺中完成的。
这是一个问题，任何拥有多个开发团队或具有相同功能的多个团队的公司都会面对。最简单的答案是将他们全部转移到一个共享的周期。
实践的不一致应用意味着团队成员在不学习新的工作方式的情况下就无法轻易地在同一组织内的团队之间移动。同样，不是DevOps特有的问题。与开发人员团队一样，您需要提高对其他团队的可见性，并引入标准以使人们保持同步。
多个团队之间的开发节奏不匹配，因此难以协调依赖版本。
再一次，这不是特定于DevOps的问题，而是经典的业务问题，远比电子计算机早。减少依赖关系，并清楚它们发生的时间以及延误的影响，并让所有受影响的方面都了解进度更改。
#3 楼
无法在多个开发团队中一致地报告进度，例如，如果一个团队根据两个星期内完成的同等大小的故事数量报告其进度；而另一个团队报告的故事点是在三个星期的冲刺中完成的。
实践的不一致应用意味着团队成员在不学习新的工作方式的情况下就无法轻易地在同一组织内的团队之间移动。
想象一下一家快餐连锁餐厅。每家餐厅可能会根据其特定位置的架构对事物进行一些重新组织，以最适合其需求。但是，一般成分和成分以及要交付的预期SLA将相同。员工应该可以轻松地在任何位置之间进行转移，而只需稍作重新定位。
每个“位置”所面临的挑战意味着您可能需要定期重新审视整体策略，而您应该“尝试一下” ，并定期将这些更改回滚到整个流程中。过程也就像软件交付一样。
多个团队之间的开发节奏不匹配，使得协调依赖版本变得困难。
再次，需要团队之间的权威控制和协议...
Etsy有一个著名的“模式变更周四”示例，在该示例中，他们可以根据需要频繁部署非违约变更，但是任何需要在系统之间进行协调更改的事情都会在每周的特定日期发生。
评论
当然！开火。@ Pierre.Vriens感谢您的反馈，还好吗？如果您认为自己所经历或提出的建议支持DevOps文化，我鼓励您发布问题的答案。
SAFe和DAD对实现方式和实现方式非常明确，LeSS本质上并不明确，实际上它只是扩展Scrum的一种方式。我可能可以将问题调整为“什么”而不是“如何”。
由您决定（最适合您）。在最终发表我的想法之前，我会稍等一下。这应该为您的问题和答案留出一些空间/灵活性。因为一旦出现另一个答案，您就不能再以使任何现有答案无效的方式更改您的问题（根据SE网站的规则，即“ I”没有发明...）。 PS：很抱歉因为如此艰难的QA阅读器（有建设性的评论，还记得吗？）。
很遗憾，我不能分享我的部门组织变更演示文稿：/我可以尝试对其进行总结，但是我不确定我能不能说什么。