想知道如何解决“切换上下文”问题么?进入“等待打扰”状态吧

  • Vikas Hazrati
  • 郑柯

2009 年 9 月 16 日

话题:敏捷文化 & 方法

在相对短的时间内,把注意力从一个任务切换到另一个任务,这就是“切换上下文”的定义。人们普遍认为:这么做对于团队成员和他正在其中工作的项目都是有害的。大家也觉得“切换上下文”与“多任务工作方式”很类似,InfoQ 最近一篇新闻也提到斯坦福大学的一篇研究报告,展示出了相关的负面影响。David Starr 认为“切换上下文”可与“Muda(浪费)”相比拟。他提出:

“切换上下文”正是 Muda 的本质,Muda 是一个日本词汇,指那些发生浪费的活动,而且这些活动没有增加任何价值,对工作效率毫无贡献。学着积极应对“切换上下文”能够降低你的浪费,还能让你变得效率更好。事实如此。

应对“切换上下文”的威胁,有多种方式。首要规则就是:“不要切换上下文”。不过,Charles Miller 指出,要想完全摆脱“切换上下文”只能是一厢情愿。一个项目中,有很多因素会转移人的注意力,必须要采取某种方式处理它们。他提到了Atlassian 使用的下列技巧:

  1. 异步沟通——Atlassian 为员工们运行了一个Jabber 服务器,所有的开发人员都会登录上去发送即时消息。其长处在于:因为其本质是异步的,所以可以很容易暂时无视,等到时间合适再去回应别人的消息。博客和内部 Wiki 也是不错的工具,可以在不必实时干扰他人的情况下,了解他们的想法
  2. “等待打扰”——他们采取的另一个有趣的想法,是指定某一个开发者的状态为“等待打扰”。这个开发人员在整个 sprint 中都可以被人打搅。他专门负责管理并响应所有的打搅因素和“切换上下文”场景,以避免整个团队被打扰。
指定唯一的一个开发人员为“等待打扰”状态,让他用两周的时间来扮演磁铁,吸引所有的问题、请求和干扰因素,这样整个团队就可以免于打搅了。

Charles 强调指出:别指望处于“等待打扰”的人在 sprint 中完成大量工作,考虑到“切换上下文”带来的问题,这可不奇怪。他提到:

当然,这种方式有其不好之处,就是处于“等待打扰”的人在两周内完成的工作量不会很多,不管他们承诺说要完成多少功能。从另一方面看来,因为人们不指望“等待打扰”者完成多少工作(他自己可能也不抱多大期望),这个开发人员也就不怎么懊恼了,而且对于团队整体来说,安排日程和估算也能达到更大的准确性。

因此,将来敏捷团队如果需要对付多次上下文切换或是多种干扰因素,指定一名专职的团队成员应对 sprint 中的干扰,这也许是个好主意。

查看英文原文:Need an Answer to Context Switching? Get Disturbed

敏捷文化 & 方法