InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

“请勿打扰”团队成员

作者 Vikas Hazrati 译者 石永超 发布于 2010年3月11日

领域
过程 & 实践
主题
敏捷 ,
敏捷技术
标签
生产力

即便不是经常如此,许多开发人员也喜欢在一段时间内不受干扰地工作。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天是协作的。随着时间的推移和团队的成熟,最终他们会不需要使用静锥区。

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

查看英文原文:The "Do Not Disturb" Team Member

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

译者 石永超 是Irdeto BSS软件工程师,CSM,敏捷爱好者,《User Stories Applied中文版》译者之一。

发表人 李 冬 发表于
Re: 过犹不及 发表人 黄 雯 发表于
? 发表人 张 鹏 发表于
每天2个小时的不被打扰时间,并不会破坏敏捷吧? 发表人 Jun Ran 发表于
  1. 返回顶部

    发表人 李 冬

    不喜欢被打扰的人不应该在做Scrum Master,就是这样。Scrum Master是要为团队服务的。他们必须一整天都能够服务团队。那是他们的工作。如果他们有比这更重要的事情,那么他们就不是真正的Scrum Master。因此,让他们做随便什么资深的角色去吧,并且找真正想服务团队的人当Scrum Master。
    同意這一點,不願意應付狼群的牧羊犬是保護不了羊群的。

  2. 返回顶部

    Re: 过犹不及

    发表人 黄 雯

    不是说不应该被打扰 而是说应该有少量独立处理时间 而且是固定的

  3. 返回顶部

    ?

    发表人 张 鹏

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

    这不就解决了....

  4. 返回顶部

    每天2个小时的不被打扰时间,并不会破坏敏捷吧?

    发表人 Jun Ran

    一天8个小时工作时间,其中抽出2个小时独立工作,还剩下6个小时可以用于跟团队一起完成需要互相协作的事情,我觉得并不会有什么问题。

    事实上一个团队也不可能一天8个小时都在互相沟通或者交互。

深度内容

大规模视频网站的计费与流量管理

本次分享将会就大规模视频网站的计费与流量管理这个话题,从操作层面细细进行讲解和分析,为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”,让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011

专访Jeffrey Richter:Windows 8是微软的重中之重

Jeffrey Richter以其多本Windows核心技术的经典著作而闻名,同时,他深入掌握微软的.NET等一系列核心技术,2012年1月,Jeffrey Richter在北京接受了InfoQ中文站的专访,谈到Windows 8和WinRT编程,并就异步编程、Windows编程中的可扩展性、性能和安全性方面给出自己的建议。

应用云平台的可用性——从新浪SAE看云平台设计

云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。

JVM定制改进 @ 淘宝

淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011

"伤得起"的云计算应用——对云端应用之架构的思考

2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。

让交付的速度跟上思考的速度

12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011

架构之路——穿行在产品和业务之间

篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011

特性注入:成功三部曲

本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。