查看原文
其他

DevOps 时代组织结构设计的秘密

董越 DevOps时代 2024-03-22

作者简介
董越,DevOps 资深专家,前阿里巴巴集团研发效能事业部架构师。

关键思路

组织结构设计的核心秘密是减少协作,或者说,自主性:尽可能让一个人或者一个团队能够把一件事负责到底。说到开发软件,那就是从idea一直到上线。

为什么呢?因为人和人之间合作是很累的。沟通需要不少时间,以理解上下文、进入状态。协调也需要不少时间,各有优先级,各种争抢各种排队各种等待。若是赶上年假啦撞车啦新冠啦,那更麻烦。所以说,尽量一件事能够从头到尾独立完成。

各职能之间的协作

拿这个思路来看一下,软件研发过程中,不同职能间怎么协作。最好是,从提出需求到发布上线都由一个人搞定,如果这不太容易的话那就一个团队搞定,所谓全流程团队(或者全功能团队、跨职能团队、stream-aligned team等等)。

敏捷运动兴起的时候,重点强调了需求、开发、测试最好由一个团队负责,而 DevOps 运动进而扩展到部署运维以及安全(DevSecOps)等等。

要想让一个团队都搞定,那就得这个团队很强。这很难啊。那还有另外一招,就是让事情变得容易做,用不着那么专业的人做。所以要搞各种工具,搞各种自动化,让工具足够好用,以至于一个人或者一个团队自己就可以搞定集成发布过程,搞定应用的运维、监控等等的各种操作。

那么那些职能团队干什么去呢?去搞开发工具等基础设施的选型引入开发运维支持推广啊。去琢磨最佳实践并且指导大家用起来啊。比如各种工具团队。比如各种教练导师传教士啊布道师什么的。
总之,由他们提供特定领域的专业服务,让群众们用起来,而不是让专业的人跑到日常开发交付流程(或者换个时髦的词叫价值流)的流程节点上去,干点儿重复琐碎的活儿或者打个勾。

当然,以上是一般原则。确实有的时候,有些事情就是比较专业,比如需要解决一个有挑战的算法问题。这个时候从别的团队请专家大拿过来支援一下也是合理的。

开发不同功能时的团队划分

应该按组件建团队,还是按特性建团队?这根本就不是个二选一的问题。首先,团队应该是长期负责系统的某部分,比如某个子系统或者某个组件。这意味着对所负责的部分越来越了解,并且有主人翁责任感,并且在有后续需求或者发现缺陷时能迅速反应。

基于这样的组织结构,当有一个具体的特性要开发的时候,把它分配给一个人去弄,一个人不成就找几个人组成一个临时的特性团队去弄,要是特性跨多个组件那就尽量从各相应组件团队里抽调人手。等过一阵儿把特性弄好了,临时团队也就解散了,人就都归队了。

再说说团队之间的划分。其实原理还是前面说的,最好是开发任务来的时候,经常一个团队就能独自搞定。尽量减少团队间配合,特别是你来我往的紧密配合。所以,理想情况是,系统本身架构很好,划分得很好,然后系统各部分分别由对应团队负责。于是这些团队就像系统架构一样,高内聚、低耦合、系统分层、充分复用。
这里要小心康威定律。康威定律说的是,你把组织结构搞成什么样子,那么开发的软件系统就会长成什么样子。所以,为了让软件系统有个好的架构,就需要对组织结构深思熟虑,让它符合我们脑海中想要的经过深思熟虑的系统架构。
最后谈一下团队规模。对,两个披萨原则这类。万一你不知道这个词的话就到网上查一下。
社区第一场大规模线上技术峰会火热报名中,欢迎来撩~

DELL EMC 中国研发集团资深架构师茹炳晟老师将带来 DevOps 体系下测试中台建设与探索,扫描图片二维码,立即报名~

近期好文:

阿里工程师:Code Review 是一场苦涩但有意思的修行

2020 年 10 种最佳持续集成工具,总有一款适合你

CI/CD 管道:揭开复杂性的神秘面纱

“DevOps时代”公众号诚邀广大技术人员投稿,
投稿邮箱:jiachen@greatops.net,或添加联系人微信:greatops1118.

点击阅读原文,立即报名 2020 DevOps 线上峰会,联系上方图片中小伙伴,可以领取5折优惠券,名额有限先到先得~

你点的每个赞,我都认真当成了喜欢
继续滑动看下一个
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存