远距离 Swarming

我们知道配备齐全的团队如何围绕某个功能进行 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 ）关注我们，并与我们的编辑和其他读者朋友交流。