MSの経験から生まれた分散アジャイルですべきこととすべきではないこと

作者 Chris Sims , 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2008年11月11日

セクション

プロセス/プラクティス,

設計/アーキテクチャ

トピック

コラボレーション ,

分散チーム ,

チームワーク ,

ケーススタディ ,

Microsoft ,

Antipatterns ,

Patterns ,

Agile

共有 |

Microsoftのpatterns & practicesグループ(リンク)の開発マネージャ、Ade Miller氏(リンク)が分散アジャイル開発の記事を発表した(リンク)。この記事で、分散アジャイル開発をしようする際の課題を明らかにしている。さらに、主としてMicrosoftのpatterns & practicesグループ内のチームの経験に基づき、これらの課題に取り組むための提案を行う。

Microsoftのpatterns & practicesグループは、過去5年間、アジャイルの分散開発アプローチに従ってきました。この期間中、グループ内のチームは、分散アジャイル開発の課題に最大限取り組むために、広範囲にわたり異なるアプローチを試してきました。この記事は、地理的に分散したアジャイルチームが直面した課題を示し、それらの出来事に取り組み、分散チームの構築に成功したことを証明するいくつかのプラクティスを詳しく述べています。

この記事は、警告で始まり、警告で終わっている。その警告とは、分散チームが同じ場所にいるチームよりも非効率で機能しなくなりそうだというものである。そのため、可能ならいつでも分散するよりも同じ場所を選ぶことを薦めている。それからさらに、分散チームができる限り効率的になるように、patterns & practicesグループが注目している分野を特定する。この記事には、彼らの経験に基づき、すべきこととすべきではないことのリストが含まれる。

チームで利用可能なコミュニケーションの情報量が最大限になるようにしなさい。チームのために、会議電話、ウェブカメラ、ハンドフリーヘッドセットなどのコミュニケーションツールを提供し、既存のプラクティスを分散場所に適応するように支援しなさい。

新しいプロジェクト毎に、頻繁にチームを再編成してはいけません。チームビルディングには時間がかかり、分散チームビルディングにはさらに長い時間がかかります。チームをかき回すのを最小限にすることでチームビルディングへの投資を最大限にしなさい。

特にプロジェクトの極めて重要な時点で、分散場所を訪れる計画を立てなさい。最初のいくつかのイテレーション、プロジェクト期間中、定期的に、そして最終リリースの直前に皆を団結させます。

システムコンポーネントで作業を分散しないで、ユーザストーリーに注目しなさい。例えば、オフショアテストチームのように、機能で分散チームを組織化することを避けなさい。

チームルームの中だけで機能するものを増やしたり、置き換えたりするツールを提供しなさい。例えば、ホワイトボードの付箋紙に代わる作業項目のトラッキングシステムのようなものです。

チームミーティングでリモートのチームメンバを忘れないようにしなさい。仲間とペアになり、少なくとも時々電話会議にすべてのメンバを呼び、皆が同じ足場にいるようにするのです。

地理的な分散の課題を扱うよりよい方法を見つけながら、チームのプラクティスを発展させなさい。たびたびふりかえりを行うことは、チームに改善方法を考えさせるキーポイントになります。

たびたび行うチームのふりかえりに皆が参加することを忘れないようにしなさい。ふりかえりでは、チームで何がでうまくいって、何がうまくいっていないか確認します。

コーチングに注目しなさい。なぜアジャイルプラクティスを分散開発環境に適応する必要があるのか、皆が理解するようにしなさい。

あなたは分散アジャイルチームに取り組んでいるだろうか?コメントを書いて、あなたが直面している課題と、それに取り組んでいる方法をいくつか共有しよう。

原文はこちらです：http://www.infoq.com/news/2008/11/Distributed-Agile-Paper