请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 26|回复: 0

敏捷团队为什么要跨领域

[复制链接]
发表于 2022-1-9 17:07:55 | 显示全部楼层 |阅读模式
梅尔·康威(MelConway)提出了著名的康威定律:“任何组织在设计系统时,其设计的系统架构是该组织沟通结构的写照。简单来说,产品必然是其组织沟通结构的缩影。”

) J# S4 Z8 _% m4 \# \2 A
你想要什么样的系统,就应该搭建什么样的团队。如果你的团队分成前端团队、DBA团队、中间件团队这种筒仓式的职能部门,将会产生筒仓式的软件架构(如图6-2所示)。

8 D7 H2 I% R/ ]% R1 \
粘贴上传202201091707167243..png
! p1 ]& G4 Y8 v0 s- X( d  B7 \
图6-2康威定律
8 q& {+ `9 M5 ?: i0 d0 Z- \. ]
这时候,组织若要交付一个潜在的可交付产品增量(PotentialShippableIncrement),就需要跨越DBA团队、中间件团队、UI团队。团队与团队之间的交接和等待,就像一场接力赛,这样的速度无法满足互联网时代激烈的竞争要求。
% e4 {) o, J) r# _6 e; n/ x& d
此外,当组织要改变一个产品特性的时候,可能会牵动每个层次的整体架构的变动。

7 d% w* E( `4 k9 b' q% N. c, R
诺基亚手机在实施敏捷转型之初,其终端功能机的研发部门的组织架构保留了原有的组件式团队。对于手机里的相机功能,需要有相机UI、相机Middleware、相机驱动程序三个Scrum团队来完成。每个Scrum团队貌似都做得很好,每个Sprint中自己开发的部分也都能顺利完成,但总是出现UI在等中间件、中间件在等驱动程序的情况。每个团队在Sprint结束时完不成的产品特性都需要对外依赖,而对外依赖的部分不受自己控制和影响,所以每个团队都把能搞定的先搞定,搞不定的都只能等着。结果,每个Sprint都有完不成的产品特性。实际上,整个相机研发过程中的每个Sprint都没有一个完整的可交付的产品增量。

% I! B8 `& ^; ~. X) u& Z
此外,被依赖的组件即使交付给需要的团队,也经常发生不可用的情况。比如,中间件团队足足等待驱动团队两个Sprint的时间交付了一个组件,可是当中间件团队拿来与自己的组件联调后,发现很多不适配的问题,不得不打回驱动团队修改;而驱动团队有自己的优先级和Sprint计划,只能把修改任务排在后面。于是,中间件团队不得已又等了一个Sprint才拿到修改后的组件。每一次返工都将彼此的等待时间扩大了一倍。中间件团队拿到修改好的组件后,又花了一个Sprint的时间进行联调、发布。这样,为交付一个产品特性,经过几个团队之间的辗转反复,至少需要四个Sprint的时间。如果有的特性需要贯穿UI、中间件、底层驱动三个团队协同交付,所需的周期更长,返工更多。

: j" y( W1 e) n9 j+ i9 m  X
在这样的按职能分工的组织里工作,每个团队只能把自己的那部分工作做到最好,控制不了的只能搁置一旁。而那些被搁置的工作,却是能够连接、集成整个系统的关键部分,从而造成整个产品交付效率低下。因此,组织必须基于产品特性组建跨领域团队才能实现高效交付。

1 ?5 l" l) l- n) I8 `1 Y1 u




上一篇:敏捷团队为什么要跨工种
下一篇:敏捷开发团队的规模
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和中级专家认证、v3专家升级、DevOps专家认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-1-20 18:32 , Processed in 0.101558 second(s), 29 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表