“请勿打扰”团队成员

即便不是经常如此，许多开发人员也喜欢在一段时间内不受干扰地工作。XP 推荐一种称之为“洞穴和公共区域（Caves and Commons）”的房间布局。公共区域用于最大限度地进行渗透性交流。洞穴用于协助隔离个人活动，比如撰写个人电子邮件、电话或快速探索式开发（Spike）等活动。但是，有些团队成员或某个特定的团队成员可能会想要过分地进行这种隔离。

Jacob 在 Scrum 开发组上提到过一种情况：在回顾会议上，一位团队成员希望在 Sprint 中使用“请勿打扰”时间段，并就此制定标准。开发人员声称：由于他被过于频繁地打断，导致他的生产率不太理想。他建议每天有 2 小时封闭的时间。在这段时间内，他不会跟团队交谈。根据 Jacob 的说法，他们的团队发现这种做法是反敏捷的，而且不利于交流。那位团队成员既是公司的合伙人，也是一名高级工程师和 Scrum Master。

Alan Dayley 认为：干扰要视类型而定。Alan 说：

现在，如果那些干扰直接与他当前正在从事的工作有关呢？那么，这种干扰应该是受欢迎的。而且，如果有两个或多个人，甚至整个团队都在做相同的事情呢？那么这种干扰就不是干扰，他们是在完成工作。

Kurt Haeusler支持那个开发人员，他提到有些开发人员需要独立的环境，而这可能并没有什么错误。他认为：问题的根源可能有其他原因，包括：

如果他真的每 15 分钟就会被打扰，即使团队其他成员知道这妨碍了他的工作，那么这似乎表明，其他人员缺乏相关信息，而他拥有这些信息。

Kurt 还提到：从积极的一面来看，团队能在回顾会议上讨论这样的事情，是非常正面的团队文化。

类似地，Elisabeth Hendrickson 提出这种情况对教练来说可能是一个巨大的挑战。Elisabeth 认为，导致这种情况可能有多种根源，目前的表现症状是没有任何进展、一事无成、英雄综合症、缺乏敏捷工程实践、信息不透明或合作不够深入，或者更有甚者缺乏团队思考意识，乃至围绕组织鼓励性措施的大问题等等。有必要更加深入地研究与分析。

Roy Morien 也说道，比起“请勿打扰”，这更像是开发人员试图扮演多个角色引起的问题。

然而，Johanna Rothman强烈认为这位开发人员不应该被放到团队中。Johanna 说：

让那个人离开团队。反正他等于不在团队里。让他去做他想做的东西，但不是那个项目。团队的速率是关于“团队”的，而不是个人的速率。如果其他人需要讨论，他就得和他们讨论，而不是单独工作。我不理解一个人怎么可能在公司里同时作为合格的资深工程师，Scrum Master 以及合伙人。他等于是在给自己做决定。

Adam Sroka 也有类似的观点，他提到：

不喜欢被打扰的人不应该在做 Scrum Master，就是这样。Scrum Master 是要为团队服务的。他们必须一整天都能够服务团队。那是他们的工作。如果他们有比这更重要的事情，那么他们就不是真正的 Scrum Master。因此，让他们做随便什么资深的角色去吧，并且找真正想服务团队的人当 Scrum Master。

Siddharta Govindaraj，做了有趣的观察，他认为这种情况是组织从传统工作方法转向敏捷工作方法时走向成熟的表现。他说：

理想情况下，你希望所有人始终是合作的。但有些时候，当你转变一个环境时，你要平衡一些事情来支持它。静锥区（cone of silence）【译者注】有趣的地方是它违背了许多基本的敏捷原则。但它在特定情况下是实用的。

Siddharta 提到：在他们的项目中，他们每周有 1 天使用静锥区策略。那天他们独自工作，而其余 4 天是协作的。随着时间的推移和团队的成熟，最终他们会不需要使用静锥区。

因此，没有多少成员对“请勿打扰”的概念充满热情。然而，有些人相信有必要在协作和孤立之间做一个好的平衡。什么适合你们的团队？在这种情况下你们会怎么做？

查看英文原文： http://www.infoq.com/news/2010/03/isolated-work-vs-collaboration “The “Do Not Disturb” Team Member”">The “Do Not Disturb” Team Member

【译者注】：Cone of Silence 是 Alistair Cockburn 提出的一种策略，静锥区原是航海、电信术语，用于表示电波不能达到的地方。这里代表隔离、封闭、不受干扰的区域。