《DevOps实践指南》笔记：第7章

《DevOps实践指南》笔记：第7章

第7章 参考康威定律设计组织结构

康威定律

团队的组织方式会影响工作方式，即组织结构决定了工作方式和工作成果。系统设计受限于组织自身的沟通结构。组织的规模越大，灵活性就越差，这种现象也就越明显。软件的架构和软件团队的结构是一致的，说白了就是‘如果让4个团队开发同一个编译器，那么编译器最后会有4个执行阶段’。软件开发团队的结构对软件产品的架构和成果有着巨大的影响。

组织原型

在决策科学领域，主要有3种组织结构类型：职能型、矩阵型和市场型。 

❏ 职能型组织结构注重提高专业技能、优化分工或降低成本。

❏ 矩阵型组织结构试图结合职能型和市场型。

❏ 市场型组织结构注重快速响应客户需求。

过度职能导向的危害（“成本优化”） 

传统的IT运维组织往往采用职能型结构，根据专业领域组织团队。这种方式显然会延长交付周期，特别是在像大规模部署这样复杂的活动中，不得不向多个团队发出一堆工单并且对工作的交接情况进行协调，这导致每一个步骤都面临长时间等待。执行工作的人通常都不太理解自己的工作与价值流目标有什么关系，这样就无法让员工发挥创造性和主动性。

组建以市场为导向的团队（“速度优化”） 

以市场为导向的团队不但要负责特性开发，而且在整个应用生命周期中还要负责测试、安全、部署和生产环境的运维。这些跨职能团队可以独立运作——能够设计和开展用户实验，构建和交付新特性，在生产环境中部署并运行服务，不依赖于其他团队就能修复任何缺陷，从而加快行动的步伐。

使职能导向有效 

职能导向也可以成就高效运转的组织。组建跨职能和以市场为导向的团队是实现快速流动和可靠性的一种方式，但并不是唯一的方式。

 左侧为职能导向：所有工作流经集中式IT运维团队；右侧为市场导向：所有产品团队能以自助的方式向生产环境部署松耦合的组件。

丰田成功的根本原因不在于其组织结构，而在于它的发展能力和员工的工作习惯。实际上，令许多人感到惊讶的是，丰田大体上是由传统的职能部门构成的。

 将测试、运维和信息安全融入日常工作

在高效能组织中，人们有着共同的目标。保证质量、可用性和安全性不是某个部门的职责，而是所有人日常工作的一部分。

使团队成员都成为通才 

职能型运维组织的各个部门都拥有各自的专业人员，比如网络管理员、存储管理员等。当这些部门过于专业化时，就会产生筒仓。一种对策是让每一位团队成员都成为通才。

 多技能交叉培训非常有利于员工的职业发展，也能让所有员工的工作变得更有意思。如果仅仅看重员工现有的技能或成绩，而不考虑他们获取新技能的能力，就会陷入“固定型思维模式”。鼓励员工学习，帮助员工克服学习焦虑和获得相关技能，并让他们明确地规划职业生涯，等等。这样做有助于培养员工的成长型思维模式。

投资于服务和产品，而非项目 

实现高绩效的另一种方法是组建稳定的服务团队，持续提供资金，让他们执行自己的战略和计划。这些团队应该有工程师专门负责兑现对内部或外部客户的具体承诺，如特性、故事和任务等。

根据康威定律设定团队边界 

随着组织的发展，保持人员和团队之间的有效沟通和协作成为最大的一个挑战。软件的架构应该保证小团队能够独立运作，彼此充分解耦，从而避免过多不必要的沟通和协调。

创建松耦合架构，提高生产力和安全性