DevOps基础-2.4-把事情抛出流程墙（管理艺术）

   虽然我多年来一直是一名工程师，但我作为经理的时间也占职业生涯一半以上，我想把这个视角带到这个教程中。作为领导者，在迁移到DevOps期间应该考虑如何改变。如果只需重命名现有团队DevOps或创建一个名为DevOps的新团队，就无法实现这些目标。如果这就是你所做的一切，那么当没有任何效果改善时不要感到惊讶。你需要真正的改变，变革总是很艰难。帮助你的团队完成过渡到DevOps是你成功的关键。

      首先，我们来谈谈组织问题。 DevOps强烈主张在自治团队的环境中消除孤岛和茁壮成长。通过将合适的人员放在团队中合适位置，专注于手头的业务问题并设置自助服务工具以允许他们开发测试，部署和运营他们自己的服务，你的团队工作保持非常高的速度。这是工作中的基本排队理论。当James和我在National Instruments开始我们的第一个集成的DevOps团队时，我们的团队能够在其他工程团队平均将一种产品推向市场的同时向市场提供三种产品（效率三倍）。查看from concept to cash的概念。您的概念需要经过多少次发版才能获得现金？

        你不必重组您的团队来实施DevOps，但你可能最终会在某个时候执行此操作，其中一些原因是人们在DevOps下更改原有工作类型和方式。有些人认为DevOps对他们的工作构成了威胁，除非这项工作太依赖他们的手工方式，否则这威胁不是真的。对于优秀的操作工程师和优秀的QA工程师以及每个人都有很多需求，但是那些花费时间做手动配置服务器或者手动测试的人的需求相对要少很多。
        开发人员在检查代码后，必须对失败的构建或部署负责。他们必须愿意随时随地支持他们的生产应用程序。运维和质量保证工程师必须改变他们的方法来提供自助服务平台和指导，而不是为其他人做工作。并且改变你的工作方式很难，这对我们来说很难。当我开始使用DevOps时，我已经做了十多年的传统IT工作，这真的很有挑战性。
        我投资了金钱和时间在DevOps工作方式和工具上面，我知道如何使用DevOps。所以，你和你周围的其他人需要学习，理解和鼓励才能做出这种改变。现在，让我们转向谈论流程问题。当然，这些与组织问题相互关联。实际上，有一个很好理解的概念叫做Conway定律，它说明你的系统基本上与你的通信边界保持一致。
         组织边界是一种沟通边界，但流程边界是另一种。一般而言，敏捷流程可以促进向DevOps的转变。事实上，它们往往是必然联系在一起的。作为一名发布经理，我被邀请一家商店来帮助他们，因为他们已经迁移到Agile开发模式，然后他们意识到他们仍然处于瓶颈状态，因为他们无法快速安全地发布版本。只有两种方法（组织和流程两方面）的结合才能实现他们想要的效果。

        2016年的DevOps报告发现，精益管理方法与组织绩效密切相关。他们还发现，与Ron Westrum组织文化类型学中定义的生成组织文化相一致的组织是组织和IT绩效的最佳预测指标之一。我喜欢实现我称之为最小可行流程，然后让团队在调整我们的流程方面有很大的发言权。

        您不添加流程，除非每个人都认为更多流程确实是解决方案，并且您要留意可以删除的流程。过程通常像训练轮，随着组织的成熟，它们成为残余，其中一些需要丢弃。你的过程墙越高，康威定律就越多。你可以给予工作的人更多的信任和自由定夺权，你将获得更好的结果。支持他们完成任何角色转换，并指导他们使用一些你将在领导转型时使用的相同的大图思维技能。最后，我看到的管理最佳实践与DevOps实施很好地重组为独立的跨职能团队，理解人们对变革的障碍，帮助他们克服障碍，并使用精益敏捷流程来保持您的努力在专注于价值创造上面。