分布式 Scrum
David Starr 是 Scrum.org 的首席软件技师，致力于提高软件开发的专业性。 他还成立了在线技术社区 ElegantCode.com。
2012 年 7 月
分布式团队经常要想方设法获得一致、及时和有效的通信。 了解 Scrum 如何提供一个可供不同类型的分布式团队进行提高和获得成功的容器。
Scrum 框架只字未提分布式开发团队。 Scrum 不要求 Scrum 团队的所有成员或者甚至是开发团队的成员在同一个房间、同一栋大厦或同一个时区进行工作。 Scrum 团队确实强烈地曝光了对提高生产力的障碍，当通信成为障碍时，Scrum 会使这个问题变得非常明显。
当团队成员不在同一物理空间中一起工作时，团队内的通信必然更复杂，团队创建的软件也是如此。 1968 年，Melvin Conway 写道：
设计系统的组织只能做出复制这些组织的通信结构的设计。
Conway 定律已经证明不仅仅是一句箴言，而且是软件开发团队内可测量的动力。 一项研究通过测量团队分布可对系统结构造成的影响证实了 Conway 定律的效果。 当团队成员分布在各处时，软件开发人员为了互相隔离，往往会在代码中创建更抽象的层[1]。
概述
通过代码看团队
Stella 是 Scrum 团队的一名开发人员，始终如一地交付他们为每次冲刺 (Sprint) 预测的工作。 她的团队以创建高质量软件出名，即使其他人在阅读其代码时发现有点儿难以理解。
她在家工作，与团队其他成员并不在一个时区。 他们使用电子邮件、一个昂贵的要求管理系统和视频会议（偶尔使用）来在每个冲刺 (Sprint) 过程讨论工作。 他们按照与每个人的时间表相适应的日常 Scrum 的规定使用 Scrum。 她通过电话出席计划会议和日常 Scrum，在与团队其他成员交谈时无法看到对方的面部表情。 此外，她也无法到每次日常 Scrum 前后发生的对话。
出于好心，Stella 在她的代码中创建了一个抽象层，以便能够更加轻松地隔离和测试她的工作。 这个新的抽象将她的实现与她已向团队其他成员声明并且公开的接口隔离开来。 她声称，这种类型的可插接系统可产生干净的解耦系统体系结构。她提醒自己“使用接口作为实现边界完全是优秀的面向对象的设计”。 她的新的插件模型让她可以只处理自己的代码部分，不会影响在其他区域工作的队友。
正如 Conway 定律所言，代码现在反映了她与她团队的通信：松散耦合。 她的设计代替了她可能需要与团队进行的对话，并且系统开始变得不必要的复杂。 这种不必要的复杂是一面镜子，反映了她与她的开发团队其他成员的关系。 这些决策最终将耗费她公司的资金，因为要控制更多代码行、要了解之后的开发人员更多级别的间接行动、并且要进行更多的测试来证明抽象的功能运行正常。
Stella 并未做错什么。 实际上，她成功利用了优秀的面向对象的设计做法来隔离系统中的问题区域。 不幸的是，她隔离的问题是她自己的通信难题，而解决方案允许次数更少的通信。 让人难过的是，她在解决问题时更改的系统是软件。 一种更有效地解决此问题的方式可能一直都是简化她与开发团队的通信。
当团队成员没有坐在一起时，他们往往会用更强硬并且更正式的对话代替轻松的口头交流。 他们不是对小的战术性决定进行快速、高效的讨论，而是将相关主题一一列出来，然后等待以后讨论。 而这些讨论往往没有了下文。 人与人的通信减少意味着会将通信往下推到其他东西上，如规范、工作单甚至代码。 ISomeInterfaces 的存在揭示了创建它们的团队的功能障碍。
团队分发的意外复杂性
在 Scrum 团队之外做出的决策很有可能增加复杂度。 软件开发团队的构成或任务很少有简单的时候，Scrum 提供了一个边界，Scrum 团队可以在此边界内机动和工作以降低复杂度。 尽管如此，实际编写代码和交付软件的复杂度有时还远远比不上组织文化和流程为开发团队带来的复杂度。
相应地，由居住在不同时区的成员构成一个 Scrum 团队的决策很少是由执行工作的人做出的。 创建分布式 Scrum 团队的决策可能来自领导者，这些领导者可能正在组建一个技术精湛的专家团队，或者（更有可能）尝试用更少的钱雇佣场外承包商来开发软件，从而降低生产成本。 虽然这些模式可能会减少软件开发的初始成本，但它们通常没有考虑到日常维护的成本以及为了解决开发团队的通信难题所增加的复杂度的成本。
不管分布式团队创建的方式或原因如何，它们都是一种客观存在，并且无任何消失的迹象。 即使在分布式团队环境下，Scrum 也保留了一个卓越的框架来管理软件产品交付的计划和执行。 团队成员必须花费更多精力来改进现有通信渠道并防范次优化，如上面的示例中描述的情况。
分布式现实
分布式团队可以让公司有机会来雇佣完成工作的合适人选，而不管这些人居住在哪里，也可以让一些人有机会居住在自己选择的地方而不用居住在公司总部所在地。 尽管反对分布式团队很容易，但外包、内包、近包和乡村外包的经济性仍然吸引了许多组织。
Scrum.org 上发布的 Scrum 指南对 Scrum 进行了整理，包含了一组应用 Scrum 框架的规则。 虽然 Scrum 指南未提及分布式团队的问题，并且未提供任何特别针对分布式团队的指导，但 Scrum 将会使成员无法彼此交谈且没有电子设备来消除隔阂的团队中存在的通信延迟和消耗情况变得非常明显。
信任是关键
人类相互之间所说的大部分内容都是通过身体语言传达的。 在设计讨论期间通过观察某人收集的信息与书写在白板上的信息一样宝贵。 因此，消除分布式工作人员之间的隔阂的重点大多集中在克服身体语言障碍上。
Steve McConnell 写道，“信任的半衰期大约是 6 周”。[2] 这表明每天一起工作和协作的开发人员将逐步发展到相互信任的级别。 信任度在任何关系中都不相同，但信任的潜力在队友相互之间经常见面并且一起工作时是最高的。
如果队友平常不见面并且相互之间有约 6 周时间未在一起密切合作，则关系中的信任度将只有之前的一半。 余下的信任短尾将随着更多的时间消逝而快速消失殆尽。
并不是相关人员没有主动相互关心或尊重，而是信任和团队效率消失了。 没有信任的话，协作将减少，队友之间的界线将增加。 这些界线通常会反映在代码中。
摄像头、电话会议、即时消息、视频聊天、屏幕共享和其他协作工具帮助消除队友之间的隔阂，对于追求高生产力的分布式团队来说，与此类似的工具如空气一样无所不在。 频繁的视频通信可在重建信任方面走得更远。
无论使用什么工具，分布式团队均可通过利用高保真通信的机会来提高其效力。 简言之，实时语音优于即时通信，即时通信又优于电子邮件，等等。 此外，减少交互之间的时间会更好。
分离程度
团队成员会发现自己与他人在很多方面不同，并且团队分布有常见的重复执行模式。 与在其他环境（如软件设计）中发现的模式一样，团队分布的模式可能会有意或无意地出现。 无意模式会作为对现有压力的无意识反应出现，而有意模式是为了控制复杂度而有意实施的。
此处介绍的分布式 Scrum 模式可能是规定的或无意识的。 它们可能由在 Scrum 团队外部做出的决策激发，或者它们可能来自 Scrum 团队围绕特定问题的自行组织。 无论它们出现的原因如何，下列分布模式在自然环境下都很常见。
远程开发团队 一起工作，但在物理空间上与公司的其他部门分离。
在远程团队成员 模式中，团队每个成员在与他/她所属团队的其他成员不同的位置工作。
在分布式团队 中，各个团队成员发现他们一起围绕同一目标工作，但每个人来自不同的地方。
远程开发团队
一些开发团队发现自己的地理位置与其更大的父级组织的不同，甚至与其产品负责人的地理位置不同。 这在一家公司收购另一家公司或在两家公司合并时很常见。 如果开发团队必须远程工作，Scrum 是管理该团队与上级组织的工作和通信的理想途径。 如今许多团队都成功运用了此方式。
虽然情况不同，但远程开发团队通常会感到权利被剥夺、遭到轻视以及与主组织隔绝。 远程团队的成员会觉得被父级公司忽略和疏远，父级公司可能（一般是无意识的）认为该团队不如位于公司总部的其他团队重要。
这些远程开发团队反复找原因、借口和机会不将其工作与其他团队的工作进行整合。 这很容易造成推脱解释为什么此冲刺 (Sprint) 的整合不重要、不必要或不可能。 这种不满情绪会日益造成开发团队认为与主要组织整合代码的请求“不合理”、“脱离我们的实际”、“不必要”或“与我们的需求无关”。
所有这些感觉是真是假都没有关系。 远程开发团队需要感觉得到倾听和理解，同时了解其在主要组织中的自身价值。 在远程岗位工作时，很容易忘记一个人是比自己更重要的事物的一部分。
与开发团队不在同一个位置工作的 Scrum 主管是失败的原因之一。 Scrum 主管无法远距离有效地履行指导、推进有效的 Scrum 活动和管理 Scrum 的职责。 开发团队与 Scrum 主管之间的距离阻碍了通信并且为 Scrum 团队带来了巨大的风险。 熟悉为信任所必需，互相高度信任是 Scrum 成功的基础。
Scrum 主管与其开发团队在同一个位置工作。
为了让开发团队很好地服务于其产品负责人，还需要畅通无阻和明确的通信。 在每个冲刺 (Sprint) 的整个过程中，开发团队必须可与产品负责人取得联系，这样才能解答问题并提供对正在进行的工作的反馈。 虽然此种常见互动在远程情况下也能进行，但必须建立保持此通信的可靠方式。
缺位的产品负责人是 Scrum 团队可能遇到的最具破坏性的力量之一。 被忽视的开发团队将被迫做出与功能和优先级有关的决策。 这个群体一般不太可能做出与功能相关的合理选择，因为他们通常不如产品负责人了解客户的需求。
产品负责人在冲刺 (Sprint) 过程中为开发团队提供关注和反馈。
遗憾的是，缺位或很少有空的产品负责人是 Scrum 团队中的常见功能障碍因素，甚至在协作环境中也是如此。 若要 Scrum 实现到其潜力，Scrum 团队必须作为一个有凝聚力、相互信任和协作的单元工作，并且需要专门的产品负责人定期关注。
远程团队成员
一些开发人员与在一个共享位置自我搭配和工作的队友分隔开来。 典型的示例是在家中的办公室尽职尽责地与团队合作的在家工作的开发人员。 虽然这种安排的原因各不相同，但越来越常见。
Alistair Cockburn 创造了渗透式通信[3] 这个词来标识团队聊天室内的固有通信的类型。
渗透式通信意味着信息将流入团队成员的收听后台，以便他们像渗透一样挑选相关信息。这一般是通过将他们安排在同一个聊天室来完成的。然后，当一个人提出问题时，聊天室内的其他人可收听或不理会，参与讨论或继续自己的工作。
渗透式通信并不限于软件开发团队。 大型报纸或媒体媒介的新闻聊天室的访客通常会在发现这种通信方式正在日益增多。 甚至全球警察部门的侦探队的人也会在调查犯罪事件时使用团队聊天室来增加共同了解。
渗透式通信的减少意味着团队内态势感知的减少。 如果软件开发人员在进行更改时未意识到他的队友对软件的更改，团队内将出现凝聚力和共享环境的缺失。 不停地专心工作的远程团队成员将不会收听团队聊天室广播中的重要信息。 这会让她无法参与某一天内涌现的有关设计和其他决策的临时讨论。
在各个版本之间用更少的时间更快地交付软件的趋势要求开发团队内有更高的态势感知。 对于未出现在团队聊天室内的远程团队成员，态势感知几乎丧失。
远程出现解决方案对于解决此问题变得更加常见。 简单的远程出现解决方案可能是使用便宜的便携式计算机、摄像头和音箱构建的。 在团队聊天室内放置此系统可为整日打开此渠道的远程开发人员提供开放的通信渠道。
视频和电话会议帮助消除身体语言障碍。
远程开发人员努力地实际成为团队的一员的迹象包括：
使用电子邮件或即时消息等打字通信来讨论复杂的问题。
在代码中定义固定的接口作为协定而不是与其他开发人员定期讨论。
想在版本控制中具有专用或个人的代码分支。
当消除远程开发人员与团队其他成员之间的隔阂时，定期访问非常有帮助。 视频呼叫胜于电话呼叫。 电话呼叫胜于打字，依赖电子邮件是待势而发的灾难。
分布式团队
在真正的分布式 Scrum 团队中，每个人一起协作来实现相同的冲刺 (Sprint) 目标，并且每个团队成员在不同的位置工作。 典型的示例是参与者居住在全球不同位置的开放源项目。 虽然通信问题很明显，但此模式具有可论证的正确性。 此类团队中的通信必然具有难度，但这随着技术不断减少身体语言障碍而变得越来越常见。
当团队成员位于不同位置时，屏幕共享软件对开展与设计和代码有关的有效对话很关键。 就代码而言，除非对话双方看到的内容相同，否则讨论将会包含太多的假设。 幸运的是，屏幕共享软件已经可用并且非常有效。 不在同一房间的团队成员应会发现自己每天会与队友共享多次屏幕。
屏幕共享可能是一个非常有效的配对和协作工具。
找理由一起检查代码、积压工作 (backlog) 项或其他项目是在分布式团队中保持高度态势感知的好方法。 另一种有效方法是为作为冲刺 (Sprint) 一部分交付的任何项添加简单验证规则。 这个分为两部分的规则是：
每一项必须在集成环境下进行验证才能视为完成。执行验证的人不能是完成工作的人。
采用此简单规则的开发团队会发现提高了整个团队对所完成的工作的共同了解。
作者注我曾经与一个开发团队合作过，这个团队的成员在同一栋大厦的不同办公室中工作。公司能为所有员工提供个人的办公室感到很自豪。开发团队最终决定创建一个虚拟的团队聊天室，每个团队成员可使用摄像头、麦克风和音箱出现在此聊天室内。虚拟团队聊天室一直处于开放状态，团队成员在处理共享的产品时将进入此聊天室。一段时间之后，团队开始称赞此虚拟聊天室。他们开始使用屏幕共享软件相互查看屏幕而不用沿着过道走到别人的房间，因为他们发现前者更快。团队开始全天都使用此虚拟团队聊天室，即使他们坐在只有一墙之隔的办公室内。最终，其中一个团队成员尝试一些天不去办公室，就在家办公。在冲刺 (Sprint) 回顾过程中，开发团队一致认为，有了这个虚拟聊天室，队友是在相邻的办公室还是在家已经没有多大关系。此虚拟团队聊天室已经证明比独立的办公室更宝贵。
工具和做法
许多麻烦都是敏捷团队使用技术含量低和高保真工具管理其工作造成的。 当在此基础上增添地理分布或多个开发团队的复杂性时，模拟索引卡和标记以及基于软件的解决方案只能够不进行扩展。 这导致专为 Scrum 或“敏捷”团队设计的工作管理工具供大于求，同时许多工具供应商基本都在宣传“我们的工具将使您变得敏捷”。
将工具与做法混为一谈
当然，没有工具可以让团队“变得敏捷”。 真正的敏捷来自制作和交付软件的人的文化、态度和行为。 因此，敏捷宣言[4] 表达了“个体和交互优于过程和工具”的价值观。
敏捷社区中的一种普遍的说法是“人优于过程，过程优于工具”。
实用主义者常说“工具设定规则”。
这两句箴言谈论的都是人与用于通信、协作和管理工作的软件之间的关系。 工作跟踪工具旨在降低通信和理解的复杂性，也可能适得其反。 例如，人们经常陷入到不必要地报告缺陷而不是修复缺陷的巢臼之中。
作者注对于考虑工具、过程和做法之间的平衡的人而言，Kent Beck 的白皮书敏捷工具是一个不错的资源。直到今天，这篇文章的见解仍如 Beck 先生 2008 年写作时一样深刻。
当工作或功能跟踪系统中的数据不是最新时，Scrum 主管和开发团队成员倾向于抱怨“工具过时了”。 这忽视了您凭直觉了解的内容：
目标是让团队而不是工具了解最新信息。有时工具能帮助实现这一点。
Scrum 专门用于提高 Scrum 团队中的态势感知。 Scrum 未提及需求、会议记录保留、工作细分、评估单位或时间跟踪的格式。 团队可能发现这些内容有用，并且它们可以在 Scrum 的上下文中工作。 但使用这些附加做法的团队是在 Scrum 之外这样做的，而不是因为 Scrum 而这样做的。
通过工具来支持做法
为 Scrum 团队选择使用的任何工具希望能够支持在工具之前选择的做法。 也就是说，健全的 Scrum 团队应有意改进。 这样做意味着选择要尝试的新做法或技术，因为团队希望在某些领域进行改进。 使用工具来支持新的做法可在尝试基本原则之后进行。 简而言之：
首先选择优秀的人。作为一个自我管理的团队，他们选择自己的做法，最后选择工具来支持所选的做法。人重于过程，过程重于工具。
（有关 Microsoft Visual Studio 2012 中提供的支持您的做法的工具的详细信息，请参见协作（进一步探讨） [重定向]、协作 [重定向]和 Visual Studio Online 上“欢迎使用”门户的了解部分。）
团队成员协作的方式对其创建的软件具有不可否认和明显的影响。 当通信轻松而有效时，生成的软件设计将体现这一点。 相反，当团队与内部通信或与为之服务的对象的通信困难时，团队生成的软件将会反映出团队遇到的阻碍。
Scrum 的定期检测和适应周期将可以更多地帮助处于分布状态的团队。 Scrum 中规定的事件会强制进行通信，但不一定影响通信的方式。
配备团队办公室仍然是让团队协作创建复杂软件的技术要求最低、保真度最高和最有效的方式。 但远程团队会一直存在。 无论是受个人状况、经济效益还是缺少远见的激励，越来越多的 Scrum 团队发现自己在团队成员不在同一物理空间的环境中工作。
越过物理边界参与团队的通信将带来更高的质量、更少的困惑、更快的生产率和更快乐的个体等回报。 在对团队中的工具和做法经过慎重考虑之后，分布式团队可以很好地运转， 甚至可以运转得非常好。
参考资料