パターン40:割り込みは閉塞状況を解除する

          

 

問題:

プロセスにおける事象や作業は、むずかしすぎて開発活動を時系列的にならべることができない。

コンテキスト:

生産性が高い設計/実装プロセスあるいは遅延が少ないサービスプロセスにおいて。スケジューリングの問題が、小さな範囲に限定されるとき(すなわち、部門全体ではなく、個々人の協力作業におけるスケジューリング)。

影響する事柄:

完璧なスケジューリングの洞察は不可能である。

もし、あるプログラマが自分のコードを使って結合したりテストしたりする前に、他の人のコードの多くができているのなら、最も長い開発期間をあたえられているそのプログラマは得するであろう。また、そうでなければ、そのプログラマの開発期間は短くすることはできない(コード所有者のパターン参照)。

解決策:

もし、あるクリティカルなリソースのためにある仕事が停滞しそうな時は、そのリソースを与えようとしている仕事に割り込みなさい。そうすれば、あなたは停滞から解法されるでしょう。もしオーバーヘッドが十分小さいのなら、スループットには影響しない。常に局所的な遅延を改善する。

結果として生じるコンテキスト:

そのプロセスは、より強い関わり合いを持つという代償を払うことによって、再び高いスループットを得るに違いない。関わり合いは、すでに仕事は内向きに流れる責任を移動バッファローの山関わり合いは遅延を少なくするのパターンを使って促進されていたかもしれない。

論理的根拠:

影響する事柄を参照してください。その意図は、このパターンは、同一のプロジェクトで共同作業を行っている開発者に最も頻繁に適用できるということである。これは、AT&Tの生産性の高いプロセスから経験的に支持されている。強力なソフトウエアエンジニアリング(実際に動いている)原理も存在する。

割り込みに優先順位を付けて、全体的な組織の生産性を最適化するようなものから処理するのがいいいだろう。すなわち、1つのきしんでいる輪を進むようにするよりも、停滞している4人の仕事を進めるようにした方がよい。意志決定プロセスは迅速でなければならない。それは、多くの場合分散されていなければならない。調停が必要な時には、パトロンのパターンを適用しなさい。パトロンとマネージャーは、停滞していた進捗の原因究明のために、そのチームがプロジェクトを監査することを促進させることができる。しかしながら、パトロンとマネージャーは、停滞を解消するためには、常に開発者(あるいは直接的に影響を受ける役割)の意見にしたがうべきである。

このパターンからの推定であるMoranzanoの注意「1人の人にクリティカルな作業をあまりにも多く割り付けてはならない。」は、もう1つのパターンである。