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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 117|回复: 0

敏捷团队为什么要跨领域

[复制链接]
发表于 2022-1-9 17:07:55 | 显示全部楼层 |阅读模式
梅尔·康威(MelConway)提出了著名的康威定律:“任何组织在设计系统时,其设计的系统架构是该组织沟通结构的写照。简单来说,产品必然是其组织沟通结构的缩影。”
/ z4 `$ S- J& g# S1 Y
你想要什么样的系统,就应该搭建什么样的团队。如果你的团队分成前端团队、DBA团队、中间件团队这种筒仓式的职能部门,将会产生筒仓式的软件架构(如图6-2所示)。

  u- {( u4 K( _6 i
粘贴上传202201091707167243..png
  B9 m/ i( ?' K2 t
图6-2康威定律
0 `& t/ `8 Q1 j" h5 A
这时候,组织若要交付一个潜在的可交付产品增量(PotentialShippableIncrement),就需要跨越DBA团队、中间件团队、UI团队。团队与团队之间的交接和等待,就像一场接力赛,这样的速度无法满足互联网时代激烈的竞争要求。

/ W$ z# l. a8 D& E2 p( g; U
此外,当组织要改变一个产品特性的时候,可能会牵动每个层次的整体架构的变动。
8 X% n, q- {2 r/ b3 A
诺基亚手机在实施敏捷转型之初,其终端功能机的研发部门的组织架构保留了原有的组件式团队。对于手机里的相机功能,需要有相机UI、相机Middleware、相机驱动程序三个Scrum团队来完成。每个Scrum团队貌似都做得很好,每个Sprint中自己开发的部分也都能顺利完成,但总是出现UI在等中间件、中间件在等驱动程序的情况。每个团队在Sprint结束时完不成的产品特性都需要对外依赖,而对外依赖的部分不受自己控制和影响,所以每个团队都把能搞定的先搞定,搞不定的都只能等着。结果,每个Sprint都有完不成的产品特性。实际上,整个相机研发过程中的每个Sprint都没有一个完整的可交付的产品增量。
- v" h  R" b9 e+ I/ D4 ^; Z! S
此外,被依赖的组件即使交付给需要的团队,也经常发生不可用的情况。比如,中间件团队足足等待驱动团队两个Sprint的时间交付了一个组件,可是当中间件团队拿来与自己的组件联调后,发现很多不适配的问题,不得不打回驱动团队修改;而驱动团队有自己的优先级和Sprint计划,只能把修改任务排在后面。于是,中间件团队不得已又等了一个Sprint才拿到修改后的组件。每一次返工都将彼此的等待时间扩大了一倍。中间件团队拿到修改好的组件后,又花了一个Sprint的时间进行联调、发布。这样,为交付一个产品特性,经过几个团队之间的辗转反复,至少需要四个Sprint的时间。如果有的特性需要贯穿UI、中间件、底层驱动三个团队协同交付,所需的周期更长,返工更多。
% o& m' ^0 n6 T" b( ?0 q: F
在这样的按职能分工的组织里工作,每个团队只能把自己的那部分工作做到最好,控制不了的只能搁置一旁。而那些被搁置的工作,却是能够连接、集成整个系统的关键部分,从而造成整个产品交付效率低下。因此,组织必须基于产品特性组建跨领域团队才能实现高效交付。
. Q& t4 F5 z; _4 [! G




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

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名

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

GMT+8, 2022-7-5 14:01 , Processed in 0.100009 second(s), 32 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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