中断は、その名が示すようにアジャイルチームの速度を落とす役割を果たす。こうした中断のうち、あるものは必要なものであり、またあるものはそうではない。重要なことは、作業の流れにダメージを与えるような中断を識別し、最小限に抑えることである。
エクストリーム・プログラミングのグループ(source)の興味深いディスカッションの中で(source)、Alistair Cockburn氏は(source)チームの流れを妨げる主な中断について共有している。
(1) 打ち合わせが多すぎること（プログラマは作業を止めて、さらにもう一つの打ち合わせに出席しなければならない）
(2) 同時に行われているプロジェクトが多すぎること（プログラマはＡプロジェクトの作業を止めて、Ｂプロジェクトの作業に移らなければならない）
これらはどちらもリアルタイムに発生し、活力を吸い取ってしまうことがあります。そして一般的に、プロジェクトや打ち合わせ、一日の流れを調整してそれらを減らし、プログラマがもっと連続してプログラミングの時間を持てるようにする方法があります。
Alistair 氏は、電話応対や打ち合わせへの出席、人を追いかけたり顧客と話したりといったことをする人がチームに必要なことがある、とつけ加えている。これにより、その人物がチームに生産性をもたらす時間は予定されていたよりも少なくなる。Alistair氏によると、この人物に期待される生産性は、彼がこのプロジェクトのために使える時間に制限されなければならない。
Alistair氏はこのシナリオについて、プロジェクト管理パターンの中で「Sacrifice one person(source)」（一人を犠牲にする）と言う名前で記述している。このパターンの中でAlistair氏は、プロジェクトは望んでいた速度では進まないことがよくあるかもしれないが、それはチームのメンバ全員の時間をとる重要な中断があるからだと述べている。その中断は重要な二次的なタスクであるために除くことができないが、しかし、それによってチームの関心が最も重要なタスクからそれてしまうのである。
Alistair氏によれば、この問題の解決策は、その中断に対応する専用の人を一人任命することである。この一人の人は犠牲になったと感じるだろうが、チームの残りのメンバは最も重要なタスクの作業をすることで、はかどるのである。
似たような路線でGojko Adzic氏は、彼がプロジェクトでアーキテクトとして働いていた時、ほとんどの時間をソフトウェアの潤滑油としての作業に費やしていたという話を付け加えた(source)。潤滑油になるということには、新しく来た人の質問に答えたり、様々なスレッドを調整したり、顧客と話したり、あらゆる打ち合わせに出席したり、といったタスクが含まれていた。Gojko氏は、彼がプログラミングに関係するタスクで生産性をあげようとしたら、チームの他の多くのメンバが潤滑油の役割を果たさなければならなくなり、これによってチームの速度が引き下げられたことをつけ加えている。彼が二次的な作業は全て自分が引き受け、チームの他のメンバ全員を最も重要なタスクに集中させるようにすることを決めたのはこの時である。Gojko氏によると、
私は、それでもまだ、物事の進展に触れていられるようにコードを切り出そうとしていました。しかし、計画の点から見ると、私の参加はまったく当てにされませんでした－私の時間は単純に無いものとみなされたのです。４ヶ月たって振り返ってみると、プロジェクトの進捗とチームの生産性について言えば、あの問題を解決する優れた方法だったのだと思います。
Alistair 氏が挙げた２つめの主な中断を受けて、人を断片的にプロジェクトに配置するのは上手くいかないということで、メーリンググループのメンバはの意見は一致した。Gojko氏は複数のプロジェクトで働くメンバがチームにいることによる、考え方の問題をまとめている。
問題は、あなたの下に断片的に関わる人が４人か５人を配置されると、利害関係者達はあなたにはチームがあると考えますが、実際には、あなたの下にいるのは実質的には専任の人一人なのです。
さらに、同時に進んでいるプロジェクトで働いている人たちのサポートについて、複数のプロジェクトで働くメンバがチームにいると、調整したりコミュニケーションをとるのにかなりのオーバーヘッドがあると、Gojko氏は述べている。彼は非常に興味深い例を挙げて自分の言い分を証明している。
２０％の労力を使える人が１０人がいる場合、理論上は専任の人の２人分の成果があがるはずです。しかし、断片的に関わる１０人を調整するのと２人を調整するのとでは、労力は同じではありません。少なくとも、１０人の専任の従業員を調整するのと同じ労力が必要です。私がこう考えるのは、断片的に関わる人たちは、他の仕事のために、スタンドアップ・ミーティングやキャッチアップ・ミーティングに欠席することがよくあり、そして１０人の専任の人のように、いつも一緒にいることがないからです。現実の人が２人であれば、実質的には調整は必要なく、コミュニケーションのオーバーヘッドも発生しないでしょう。
このグループのメンバは、主な中断に関連するリスクを軽減するためには、二次的なタスクに対応するために犠牲となる人を配置し、同時に複数のプロジェクトに同じ人を配置するのを避けるとよい、ということを確信していた。
原文はこちらです：http://www.infoq.com/news/2008/05/handling-interruptions