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

在相对短的时间内，把注意力从一个任务切换到另一个任务，这就是“切换上下文”的定义。人们普遍认为：这么做对于团队成员和他正在其中工作的项目都是有害的。大家也觉得“切换上下文”与“多任务工作方式”很类似， 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