トップスポーツチームの監督に教わる秘訣
この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。
作者 Vikas Hazrati, 翻訳者 沼田 暁子 投稿日 2008年6月10日 午後12時27分
中断は、その名が示すようにアジャイルチームの速度を落とす役割を果たす。こうした中断のうち、あるものは必要なものであり、またあるものはそうではない。重要なことは、作業の流れにダメージを与えるような中断を識別し、最小限に抑えることである。
エクストリーム・プログラミングのグループ(source)の興味深いディスカッションの中で(source)、Alistair Cockburn氏は(source)チームの流れを妨げる主な中断について共有している。
(1) 打ち合わせが多すぎること(プログラマは作業を止めて、さらにもう一つの打ち合わせに出席しなければならない)
(2) 同時に行われているプロジェクトが多すぎること(プログラマはAプロジェクトの作業を止めて、Bプロジェクトの作業に移らなければならない)
これらはどちらもリアルタイムに発生し、活力を吸い取ってしまうことがあります。そして一般的に、プロジェクトや打ち合わせ、一日の流れを調整してそれらを減らし、プログラマがもっと連続してプログラミングの時間を持てるようにする方法があります。
Alistair 氏は、電話応対や打ち合わせへの出席、人を追いかけたり顧客と話したりといったことをする人がチームに必要なことがある、とつけ加えている。これにより、その人物がチームに生産性をもたらす時間は予定されていたよりも少なくなる。Alistair氏によると、この人物に期待される生産性は、彼がこのプロジェクトのために使える時間に制限されなければならない。
Alistair氏はこのシナリオについて、プロジェクト管理パターンの中で「Sacrifice one person(source)」(一人を犠牲にする)と言う名前で記述している。このパターンの中でAlistair氏は、プロジェクトは望んでいた速度では進まないことがよくあるかもしれないが、それはチームのメンバ全員の時間をとる重要な中断があるからだと述べている。その中断は重要な二次的なタスクであるために除くことができないが、しかし、それによってチームの関心が最も重要なタスクからそれてしまうのである。
Alistair氏によれば、この問題の解決策は、その中断に対応する専用の人を一人任命することである。この一人の人は犠牲になったと感じるだろうが、チームの残りのメンバは最も重要なタスクの作業をすることで、はかどるのである。
似たような路線でGojko Adzic氏は、彼がプロジェクトでアーキテクトとして働いていた時、ほとんどの時間をソフトウェアの潤滑油としての作業に費やしていたという話を付け加えた(source)。潤滑油になるということには、新しく来た人の質問に答えたり、様々なスレッドを調整したり、顧客と話したり、あらゆる打ち合わせに出席したり、といったタスクが含まれていた。Gojko氏は、彼がプログラミングに関係するタスクで生産性をあげようとしたら、チームの他の多くのメンバが潤滑油の役割を果たさなければならなくなり、これによってチームの速度が引き下げられたことをつけ加えている。彼が二次的な作業は全て自分が引き受け、チームの他のメンバ全員を最も重要なタスクに集中させるようにすることを決めたのはこの時である。Gojko氏によると、
私は、それでもまだ、物事の進展に触れていられるようにコードを切り出そうとしていました。しかし、計画の点から見ると、私の参加はまったく当てにされませんでした-私の時間は単純に無いものとみなされたのです。4ヶ月たって振り返ってみると、プロジェクトの進捗とチームの生産性について言えば、あの問題を解決する優れた方法だったのだと思います。
Alistair 氏が挙げた2つめの主な中断を受けて、人を断片的にプロジェクトに配置するのは上手くいかないということで、メーリンググループのメンバはの意見は一致した。Gojko氏は複数のプロジェクトで働くメンバがチームにいることによる、考え方の問題をまとめている。
問題は、あなたの下に断片的に関わる人が4人か5人を配置されると、利害関係者達はあなたにはチームがあると考えますが、実際には、あなたの下にいるのは実質的には専任の人一人なのです。
さらに、同時に進んでいるプロジェクトで働いている人たちのサポートについて、複数のプロジェクトで働くメンバがチームにいると、調整したりコミュニケーションをとるのにかなりのオーバーヘッドがあると、Gojko氏は述べている。彼は非常に興味深い例を挙げて自分の言い分を証明している。
20%の労力を使える人が10人がいる場合、理論上は専任の人の2人分の成果があがるはずです。しかし、断片的に関わる10人を調整するのと2人を調整するのとでは、労力は同じではありません。少なくとも、10人の専任の従業員を調整するのと同じ労力が必要です。私がこう考えるのは、断片的に関わる人たちは、他の仕事のために、スタンドアップ・ミーティングやキャッチアップ・ミーティングに欠席することがよくあり、そして10人の専任の人のように、いつも一緒にいることがないからです。現実の人が2人であれば、実質的には調整は必要なく、コミュニケーションのオーバーヘッドも発生しないでしょう。
このグループのメンバは、主な中断に関連するリスクを軽減するためには、二次的なタスクに対応するために犠牲となる人を配置し、同時に複数のプロジェクトに同じ人を配置するのを避けるとよい、ということを確信していた。
原文はこちらです:http://www.infoq.com/news/2008/05/handling-interruptions
ITマネージャ必聴!IT活用セミナー 勝ち残りの法則~管理・統合化スペシャル~
12/16 ~野村総合研究所が提案~ 「不況を乗り切る!効果的なIT投資を考えるセミナー」
12/5 CSQ会員限定技術情報交換会にてJCP議長が標準化について語る
この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。
Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。
マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。
Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。サブミッションが選択された人、そうでない人も含めて、個々の目的意識の確認、膨大なプログラムから聞きたいセッションの選択、旅行の準備、プレゼンテーションの準備の期間を終えて、無事当日を迎えました。
筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。
エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。
この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。
No comments
返信