写点什么

远距离 Swarming

  • 2012-06-07
  • 本文字数:3258 字

    阅读完需:约 11 分钟

我们知道配备齐全的团队如何围绕某个功能进行 swarm 。但是如果你是分布在不同地方的敏捷团队成员之一,又该如何呢?这就取决于成员分布的方式以及所跨时区有多少。

团队如何分布?

太多跨区域分布式团队都是按功能划分的。比如说,所有或部分开发人员会分布在一些地区,所有或部分测试人员会在其他一些地区。产品所有者 / 用户在另一个不同的地方,如果团队配有业务分析人员,这些人通常又会在另一个不同的地方。

这种情况很容易用一个故事来描述。我曾经遇到过一位项目负责人叫 Stefan,他在我的工作室任职。他本人在德国,当时就很担心其中一个项目。那个项目有两位开发人员在英国,一位在法国,还有两位在德国,另外有两位测试人员在印度的班加罗尔。产品所有人在德国,而且该用户还想要管理另外两个团队积压的工作。

这种情况真是杂乱无章。但是这个故事正是我时时听闻的区域式分布团队的典型代表。而且,因为团队不是围绕特征来进行 swarm,产品所有者认为他有足够的时间在各个团队之间进行多任务管理。

集中工作

Stephan 提出的第一项建议是让开发人员减少在制品(WIP),并且大家集中关注在同一件事情上。而之前他们每个人都有各自的事。现在,他们都在讨论的是“我们如何一起开始这个事情?”

结对进行实验

他们不会同一时间一起开始。首先是在英国的两位开发人员一起开始。他们想,既然是在同一时区,那么他们应该一起开始。这么做也是比较合理的,因为不存在时差的问题。

两位身在英国的开发人员其实并不是在同一地点一起工作,所以他们同分布在其他地区的人面临同样的问题。他们试着通过架构来组合 Google 文档、共享屏幕、做结对、进行工作。他们必须实践多种场景。然后发现原先设置的“故事”都太大了。将“故事”范围调整小一些之后,swarm 会变得简单许多。

再加入一位开发人员

当英国的两位开发人员开始实践某一“故事”之后,他们打算再让另一名开发人员加入进来。在接下来的故事中,他们召集了德国开发人员中的一人。三个人所在区域存在一个小时的时差,上下班和午餐时间也是如此。

不过他们还是努力一起交付了这个“故事”,并决定再加入一名测试人员。但他们还是对时差的问题有点担心。

加入测试人员

两位英国开发人员分别位于曼彻斯特和伦敦,还有一位开发人员在德国慕尼黑,现在又有一位测试人员在印度班加罗尔,这个项目小组分布在跨 4 个半小时的时区内。更糟的是他们一天能一起工作的时间最多只有 5 个小时,前提还是测试人员要加会儿班,开发人员要晚点儿吃午饭。而且这样做也只能偶尔为之,不可能一直这样。

所以,他们决定按照各自的时间工作,而不是 5 个小时大家一起工作。

按各自时间工作

现在我们明白了按各自时间工作的价值——这也是敏捷的大致含义所在。不过我们没必要按照一周或两周这样划分时间段。我们还可以划分更小的时间段。

该团队决定利用分时间段的方法集中精力做 swarm,这样他们就可以尽各自所能利用的时间来一起解决问题。

在第一个 90 分钟内,开发人员和测试人员一起工作,分享屏幕、远距离结对,一切你所能想象的一般团队的工作场景都在这支团队中得以实现。

第一时段之外的安排就由每个人自行决定了。

大家能午餐同步吗?或者他们牺牲下午的剩余时间来吃午餐?团队成员需要自己决定找出解决问题的办法。该团队尝试了多种方法,主要还是取决于其他事情的进展程度。

手动测试减慢了团队的速度

当团队刚开始 swarming 的时候,测试人员只能进行手动测试。这就意味着团队每次都有一步滞后,即测试人员总是晚一步了解目前的状况。当测试人员与开发人员一起工作时,测试人员能够理解功能是什么,但还是不能开发出自动测试。

通过 swarming,开发人员能够为测试人员构建代码使部分测试得以自动化。这虽说不是完美的解决方案,但又有哪种是呢。

随着不断的沟通,测试人员对自动化的担心越来越少,并开始对团队做出越来越有效的贡献。

加入看板使进度更直观

由于该团队成员分散在太多不同的时区中,且时间重叠很少,于是成员们使用了看板管理来观察所有“ kanban board ”的进度。这样的话,每位成员就可以根据情况选择早来或晚走。

像这样团队成员分布在不同区域的,大家对调班都习以为常。不需要每个人每天都调班,只要你发现你可以在某一天或两天调整个一两小时就能对团队起到帮助,你可能就会这么做。看板管理可以帮助大家判断这么做是否有必要。

该团队很快发现他们一起 swarm 的频率越来越高,他们需要各自调整时间以便一起 swarm。由于彼此相隔太远,如果想要加上测试人员一起的话,swarm 变得没那么容易。

“我们需要更多的故事”

Swarm 的成效之一就是团队能更快地完成工作。因为他们的在制品更少,所以故事就完成得更快。现在压力转移到了产品所有者身上,他们已经为其提供了编写完好而简练的故事。产品所有者很讶异甚至还没心理准备团队能够如此又快又好地完成任务。

起初,产品所有者想要自己搞定所有的故事。后来,他意识到项目太多了,根本忙不过来。于是他寻求帮助,将工作移交给另外一个产品所有者的两支队伍,并将注意力集中在这支团队上。

你拥有更多选择

相比这支团队的选择,其实还可以有更多的选择。如果你打算实验一下,或许可以选择另一种方法。这支团队选择的方法是:

  1. 先从最近的人那里起头。
  2. 加入下一个人进来。
  3. 使用时间分段来克服时差问题。

其他方法可以是:

  1. 先从各个架构层某个人开始再加上一名测试人员
  2. 使用时间分段来克服时差问题。

还有一种方法是:

  1. 使用看板管理来观察进度。
  2. 不要试图进行实时 swarm,而是只要有谁有空就出来解决问题。

我个人不倾向于第三种方法,因为那样会导致多任务操作。

当你们分散太开而不能一起 swarm 时怎么办

有时候,作为跨职能的团队,你们会因为各自分散在不同区域而无法一起 swarm。我有位同事叫 Tim, 我就经常在他的项目中发现这样的情况。Tim 团队的开发人员分布在美国的好几个地方:Cambridge、 MA、 Denver、还有 San Jose。所有测试人员都在印度的 Pune。由于时差问题,他们没法儿选择合适的时间一起开会,但是这并不妨碍他们选择正常时间之外的时段一起工作。

在 Tim 的项目中,开发人员可以在差不多的时间里一起 swarm。然后,完成他们的部分之后加入测试,再将代码交接给在印度 Pune 的测试人员。

这并不是理想状态。但是,他们使用了看板管理来跟踪进度并提出相关问题。所以,如果 Pune 的测试人员有任何问题,他们就会在看板上创建卡片,这样开发人员就能看到并做相应回复。

可视化管理益处多

跨越不同时空进行 swarm 并非易事。如果可以用工具来看到对方的工作区域就太好了。然而,更有帮助的是能够看到工作进度。

Swarming 帮助团队减少在制品,这使得整个团队能更好更快地完成工作。它可以帮助你理清方向。它有助于团队成员之间的关系得以促进。

当然,有时候不管怎样,这项工作就是没法儿完成。那么索性就放弃吧。但是,但凡你有机会,就请尝试一下看看会有什么结果。一定要告诉你尝试的结果,好吗?

关于作者

Johanna Rothman 与很多公司有合作,帮助他们改进产品开发管理——最大化管理人员和技术人员的效率,并提高产品质量。Johanna 是 2009 敏捷大会的主席。她还撰写了以下多本著作:

- Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
- The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
_- Behind Closed Doors: Secrets of Great Management_
_- Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People_

她还为 Stickyminds.com 撰写专栏,并为 Gantthead.com 撰写“极限项目管理”,并在其主页 jrothman.com 上写有两篇博客。最近她开始在 www.createadaptablelife.com 撰写博文。她还是 Amplifying Your Effectiveness 会议的主持人。

查看英文原文: Swarming Across Distance


感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2012-06-07 00:001599
用户头像

发布了 52 篇内容, 共 17.1 次阅读, 收获喜欢 3 次。

关注

评论

发布
暂无评论
发现更多内容

参与 TDesign 收获了什么?听听社区贡献者怎么说

TDesign

设计 产品经理 设计师

开源一夏 | 23张图,4500字从入门到精通解释Redis

wljslmz

redis 开源 8月月更

Beetle编译/部署自动化

转转技术团队

CI/CD

高项-第一章 信息化和信息系统(1)

索隆

项目管理 软考 笔记分享

【真送礼物】1 分钟 Serverless 极速部署盲盒平台,自己部署自己抽!

阿里巴巴中间件

阿里云 Serverless 云原生

前端食堂技术周刊第 49 期:Deno即将迎来重大变革、Blitz 2.0 Beta、Chrome删除HTTP/2服务端推送

童欧巴

JavaScript typescript deno

你就是函数响应式编程(FRP)啊?!【附 RxJS 实战】

掘金安东尼

前端 函数式编程 8月月更

【杂谈】网络协议(一)

自然

网络 8月月更

多模态算法在视频理解中的应用

之家技术

人工智能 算法 视频 多模态

开源一夏 | Foundation对于模态框以及Subsystems的深入运用的理解心得

恒山其若陋兮

开源 8月月更

实力上榜|海泰方圆跻身2022企业网络安全服务Top15

电子信息发烧客

[教你做小游戏] H5小游戏技术选型分析,低代码?小游戏框架?canvas或SVG?还能用React?

HullQin

CSS JavaScript html 前端 8月月更

多核驱动时代的降维打击 英特尔异构混合架构破局之路

科技之家

华为云CDN&云视频通信专场:828低价购,CDN0.05元/GB起,短信0.006元/条起

sofiya

无影云电脑

六月的雨在InfoQ

无影云电脑 云电脑 8月月更

TDesign 设计资源大更新,产品经理和设计师都可以省心啦~

TDesign

设计 设计师

开源一夏 | 一个裸机工程转FreeRTOS的实例

矜辰所致

开源 stm32 STM32CubeMX 8月月更 FreeRTOS

圆壹智慧创始人兼CEO 潘麓蓉:AI制药工业落地的痛点与前进方向

阿里云弹性计算

HPC 高性能计算 AI制药

已有小程序应用转App的一种技术

Speedoooo

小程序 小程序容器 小程序转app

付费会员之我见-02(44/100)

hackstoic

商业模式 付费会员

直播预告 | 流程挖掘如何助力头部制造业实现千万级增长?

望繁信科技

“九章云极DataCanvas AI平台赋能厦门航空”荣获AI平台应用标杆案例

九章云极DataCanvas

人工智能

全链路灰度新功能:MSE 上线配置标签推送

阿里巴巴中间件

阿里云 微服务 云原生

什么数据库这么猛?5.6 版本刚开源一个半月,8.0 版本竟然就要启动了?| StoneDB 社区答疑第二期

StoneDB

MySQL 数据库 开源 StoneDB 8月月更

【杂谈】网络协议(二)

自然

网络层 8月月更

在 WSL2 上部署 PyTorch

DisonTangor

WSL2 Windows 10 PyTorch

灵魂拷问:你精神内耗了吗?由TA来治愈吧

白洞计划

诚邀|8月31日,【因果学习和决策优化挑战赛TOP10队伍作品秀】邀您共享因果学习智慧盛宴

九章云极DataCanvas

人工智能

九章云极DataCanvas YLearn因果学习开源项目荣获“可信AI实践优秀案例”奖

九章云极DataCanvas

分布式系统接口用例自动回归实践

转转技术团队

接口测试

828选华为云,实惠更实用——为什么选择华为云CDN的企业多?

sofiya

  • 扫码加入 InfoQ 开发者交流群
远距离Swarming_文化 & 方法_Johanna Rothman_InfoQ精选文章