扫码阅读
手机扫码阅读

聊聊多地点团队的敏捷研发

78 2024-01-31

这是鼎叔的第四十二篇原创文章。
行业大牛和刚毕业的小白,都可以进来聊聊。

随着全球化和信息技术的发展,以及疫情的助推,多地点“分布式研发”成为新常态,给项目管理者带来很大的新挑战。即使团队分布在多个不同的地点,各种经典敏捷实践活动都是适用的。

本文参考了Craig Larman和Bas Vodde的观点,他们是《精益和敏捷开发大型应用实战》的作者。

Erran Carmel在《全球软件团队》中指出了多地点开发团队遇到的五种离心力,它们破坏了团队和角色的协作,并削弱了绩效:地理位置的分散,团队性的丧失,沟通丰富性的丧失,协调的分崩离析和文化的差异

围绕这些离心力的思考,我们(敏捷教练)可以进行如下改良实践,总结出成功的解决方法。

1 减少研发站点数量。敏捷教练和利益相关方(管理层)进行充分沟通,使他们意识到研发站点的爆发增长带来的负面影响,并且可能导致项目失败。

注意:即使团队坐在一栋楼的不同楼层,他们也可能是“分布式研发团队”,因为平常都是线上联系,没有互相走动。

多地点研发对于项目交付效率肯定是有影响的,离心力很强大,据行业调查,多地点开发的开发耗时是同地开发的两倍。所以,任何公司,如果能把团队布置到一个地点,这都是优先选择。

对于大型分布式开发团队,每个站点的团队最好都是数个完整的特性团队,因此是“分而不散”,单个特性团队并不会跨地域工作。每个站点中的特性团队,都是卓越人员组成的小型团队在工作,而并非由平庸人才组成的大型团体。

2 针对产品而非站点来创造迭代。多地点研发团队创造一份潜在可交付的产品增量作为共同的挑战,不能每个站点设置一个独立的迭代。

要做到这点,当然需要持续集成的基础设施,共享大规模测试自动化和同一个代码库。

3 避免以组件或职能来组织站点。比如,把测试组集中放在站点A,把架构组放在站点B,这种组织形式因为沟通阻碍会把协作依赖变得错综复杂。一个特性的完成会牵扯到远在天边的组件团队的联调和延迟。如果每个特性团队自给自足,不需要太多和其他团队的协调来完成特性,多地点开发就变得非常简单了。

4 如果团队不得不分散,那不同情况下的分散的负面影响是不一样的。语言、文化和时区是否相同,过去是否在同一地点工作,是否互相信任,是否经常视频等,都会导致负面影响的程度不同。

当一个新站点被加入到现有产品团队时,对产品的知识和能力会存在问题。这是应该尽量用同步工具沟通,来鼓励团队性,如视频会话,IM,共享桌面编程等。这种方式下,分散式团队最好有大部分重叠的工作时间,时区差距不大。最好试着把所有分散团队的成员组织在同一个站点工作几个迭代,建立真正的信任关系。

5 逐步向同地点Scrum特性团队模式转变。把团队结构的改变集中在最高优先级的待办条目上,这样改变的投入产出效率最高。

一个新的特性团队就从原有团队中建立起来,它通过实践验收测试驱动开发,以及自动化特性测试,就不再依赖远程的测试团队,仅仅是通过视频会议获得远程专家的评审意见。远程测试团队更多地关注于在持续集成系统中编写全面自动化测试。

新特性团队通过和其他站点的组件专家进行分布式结对编程,代码审查,学习如何在不熟悉的组件上工作。

新特性团队要和某需求区域的产品负责人在同一地方工作,一起参加scrum活动。注意:需求区域是从客户角度对产品主要特性集的认知,它和产品组的工作地点和组织架构没有必然关系,所以不用刻意围绕产品负责人的地点来安排研发团队站点(能在一起当然更好)。

总之,尽可能在现有站点学习需要的新知识,而不是增加新的站点。相关的外地专家可以飞过来指导,审查,结对编程或者远程视频研讨。

6 多地点团队的协调诀窍

多地点开发团队的成熟阶段,应该是各站点从根本上平等合作,参与对产品愿景和架构的驾驭,积极性和互动质量充分提高。

多地点开发团队共享同一个代码库,跨地域持续集成所有代码,采用编译构建耗时更短的工具。

百闻不如一见,视觉对于建立关系和丰富沟通时非常重要的。

进行大型团队视频研讨会议时,采取发散-聚合循环的议程,让各个站点单独进行讨论活动,再让所有站点现身说法,通过视频展示成果。

多地音视频会议时,建议每次都说出自己的名字。一旦听不清对方,就立即告知。不要长时间讲话,定时询问对方是否听到并理解。积极倾听对方的发言并尝试理解观点。当会议室开始一个本地讨论时,要向其他站点人员进行现场解释。

多地团队故事点估算时,主持人可以利用在线WIKI或共享表格,整理对方输入的回答,而且所有站点可以实时访问,还可以同时进行投票。还可以准备实体计划扑克(大卡片),写上粗大的字体,通过摄像头可以看清楚。

异花授粉:即安排负责人访问其他站点,参与scrum,花上很长时间和当地团队紧密工作在一起。注意访问者不能成为两个站点的中间人,而是牵线搭桥,帮助当地人员建立和其他站点人员的直接关系。有些站点对于到访的关键访问者会公开欢迎介绍,以便周知来者的背景以及来访目的。

建立多地点的实践社区(CoP)。在多地点CoP的环境中,异步沟通工具更为重要,比如WIKI,博客,网站推送等。一个受到正式承认的CoP组织以及一些积极的社区协调员会特别有帮助。一个大型项目的共享平台WIKI,建议安排管理员,让无组织无纪律的WIKI保持半结构化,修剪杂乱内容。

对于Scrum的回顾会议,除了最低层次的单团队回顾,以及完全的多地点产品级回顾,在两者之间还有中间层级的联合回顾是值得尝试的。比如:所归属的需求区域级别的回顾,或站点级别的回顾(聚焦关注工作环境,物质和文化)。

7 注意多地点交流的文化和规范。通过共享的词汇和概念来创造基本的共通文化。对于不同国家的团队,理解不同文化下的管理者权力和个人主义的差异。

8 工具

推荐可多地点会话的音频视频工具,并可录制回放。推荐使用手写屏电脑,方便把手绘草图保存为共享文档。不建议购买专门在视频室使用的昂贵系统,而是用简单的视频软件和投影机等解决方案。

不推荐使用商业“敏捷”工具,因为工具越花哨,越专业,就让人把关注点吸引到工具上,而不是人们之间的互动上了。敏捷教练鼓励在研讨会上使用简单而有形(实物)的协作工具。对于协作软件工具,要挑选极其简单的免费工具,这也是建立跨站点通用工具的便利方法。

商业工具可能会拖慢多地开发,比如为新人和新站点花费时间申请使用许可。而工具需要接入公司网络以获取访问许可,这也会影响本地化离网开发。公司预算限制也会延误商业工具购买。

多地点开发的挑战不在于工具,而在于人员和观点。

       
原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484096&idx=1&sn=3fd6d56ad3ed7e70b5c0f616681fcacb&chksm=c24fb7a2f5383eb4237c85e439b65a2e6c99eea88f7fca16af4c36293d6989b5019a9c88e600#rd

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。

81 篇文章
浏览 5383
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线