DevOps 时代组织结构设计的秘密
作者简介
董越，DevOps 资深专家，前阿里巴巴集团研发效能事业部架构师。
关键思路
组织结构设计的核心秘密是减少协作，或者说，自主性：尽可能让一个人或者一个团队能够把一件事负责到底。说到开发软件，那就是从idea一直到上线。
为什么呢？因为人和人之间合作是很累的。沟通需要不少时间，以理解上下文、进入状态。协调也需要不少时间，各有优先级，各种争抢各种排队各种等待。若是赶上年假啦撞车啦新冠啦，那更麻烦。所以说，尽量一件事能够从头到尾独立完成。
各职能之间的协作
拿这个思路来看一下，软件研发过程中，不同职能间怎么协作。最好是，从提出需求到发布上线都由一个人搞定，如果这不太容易的话那就一个团队搞定，所谓全流程团队（或者全功能团队、跨职能团队、stream-aligned team等等）。
敏捷运动兴起的时候，重点强调了需求、开发、测试最好由一个团队负责，而 DevOps 运动进而扩展到部署运维以及安全（DevSecOps）等等。
要想让一个团队都搞定，那就得这个团队很强。这很难啊。那还有另外一招，就是让事情变得容易做，用不着那么专业的人做。所以要搞各种工具，搞各种自动化，让工具足够好用，以至于一个人或者一个团队自己就可以搞定集成发布过程，搞定应用的运维、监控等等的各种操作。
那么那些职能团队干什么去呢？去搞开发工具等基础设施的选型引入开发运维支持推广啊。去琢磨最佳实践并且指导大家用起来啊。比如各种工具团队。比如各种教练导师传教士啊布道师什么的。
总之，由他们提供特定领域的专业服务，让群众们用起来，而不是让专业的人跑到日常开发交付流程（或者换个时髦的词叫价值流）的流程节点上去，干点儿重复琐碎的活儿或者打个勾。
当然，以上是一般原则。确实有的时候，有些事情就是比较专业，比如需要解决一个有挑战的算法问题。这个时候从别的团队请专家大拿过来支援一下也是合理的。
开发不同功能时的团队划分
应该按组件建团队，还是按特性建团队？这根本就不是个二选一的问题。首先，团队应该是长期负责系统的某部分，比如某个子系统或者某个组件。这意味着对所负责的部分越来越了解，并且有主人翁责任感，并且在有后续需求或者发现缺陷时能迅速反应。
基于这样的组织结构，当有一个具体的特性要开发的时候，把它分配给一个人去弄，一个人不成就找几个人组成一个临时的特性团队去弄，要是特性跨多个组件那就尽量从各相应组件团队里抽调人手 。等过一阵儿把特性弄好了，临时团队也就解散了，人就都归队了。
再说说团队之间的划分。其实原理还是前面说的，最好是开发任务来的时候，经常一个团队就能独自搞定。尽量减少团队间配合，特别是你来我往的紧密配合。所以，理想情况是，系统本身架构很好，划分得很好，然后系统各部分分别由对应团队负责。于是这些团队就像系统架构一样，高内聚、低耦合、系统分层、充分复用。
来源：乔梁老师2017演讲
这里要小心康威定律。康威定律说的是，你把组织结构搞成什么样子，那么开发的软件系统就会长成什么样子。所以，为了让软件系统有个好的架构，就需要对组织结构深思熟虑，让它符合我们脑海中想要的经过深思熟虑的系统架构。
最后谈一下团队规模。对，两个披萨原则这类。万一你不知道这个词的话就到网上查一下。
社区第一场大规模线上技术峰会火热报名中，欢迎来撩~
京东高级总监，《技术运营标准》核心编写专家 徐奇琛
分享京东：面向互联网时代的质量体系建设与能力构建
扫描图片二维码，立即报名 ▲
近期好文：
基于 Prometheus 构建高大上的 MySQL 监控平台
灵魂一问：假如把支付宝存储服务器炸了，里面的钱还在么？
“互联网之父”确诊新冠肺炎；某酒店520万开房信息被泄露！| 一周资讯
“高效运维”公众号诚邀广大技术人员投稿，
投稿邮箱：jiachen@greatops.net，或添加联系人微信：greatops1118.
点击 阅读原文 ，立即报名 2020 DevOps 线上峰会，联系上方图片中小伙伴，可以领取5折优惠券，名额有限先到先得~
你点的每个赞，我都认真当成了喜欢
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
