分散スクラム
David Starr は、Scrum.org のチーフ ソフトウェア クラフトマンであり、ソフトウェア開発という専門職の能力を向上させることに注力しています。 彼は、オンライン テクニカル コミュニティである ElegantCode.com の設立者でもあります。
2012 年 7 月
チームが分散されていると、タイムリーで有効な一貫したコミュニケーションを行うことが難しくなる場合があります。 スクラムの枠組みで提供されるコンテナーを使用して、さまざまな種類の分散チームを改善し成功に導く方法を理解します。
スクラム フレームワークは、分散開発チームに関して何も言及していません。 スクラム チームのすべてのメンバー、または開発チームのすべてのメンバーが、同じ部屋、同じビル、同じ都市、または同じタイム ゾーンで作業することはスクラムの前提になっていません。 スクラム チームは、生産性向上の妨げとなる事項が存在する場合はその事項を積極的に明示し、コミュニケーションが妨げとなる場合は、スクラムはそのことを非常に明確に示します。
チーム メンバーが物理的に近接していない場所で作業している場合は、チーム内のコミュニケーションは確実により複雑になり、チームが作成するソフトウェアにも同じことが当てはまります。 1968 年に、Melvin Conway (メルビン コンウェイ) 氏は次のように説明しました。
システムを設計する組織には、その組織のコミュニケーション構造を反映した設計を作り出すという制約が課されます。
Conway の法則は、ただの格言ではなく、より実証的な説明です。ソフトウェア開発チーム内では、測定可能な動的要因になる可能性もあります。 ある研究では、チーム分散という事実がシステム アーキテクチャに及ぼす影響を測定して、Conway の法則が実際に影響力を持つことが実証されました。 チーム メンバーが分散している場合は、ソフトウェア開発者が互いを分離しようとして、コード内でより多くの抽象化レイヤーを作成する傾向に陥りがち[1]です。
概要
コード内に見られるチームの距離
Stella は、各スプリントに関する予測を継続的に納入するスクラム チームに所属する開発者です。 この女性が所属するチームには、高品質のソフトウェアを開発するが、他の開発者がコードを読む場合は少々理解しにくい、という評判があります。
この女性は自宅で働いていますが、チームの他のメンバーとは異なるタイム ゾーンで作業を進めています。 メンバー相互は、電子メールと高価な要件管理システムを使用し、時にはビデオ会議で、各スプリントに関する全体的な作業について話し合うことがあります。 メンバーは、全員の進捗予定を設定した日次スクラムのスケジュールによって事前に定義された方法でスクラムを使用しています。 Stella は、計画に関する会議や日次スクラムに参加するときに、他のメンバーの顔が見えない電話会議を使用します。 また Stella は、日次スクラムの開催前および開催後に他のメンバー相互の間で交わされる会話を聞くこともありません。
Stella は善意から、自分のコード内に抽象化レイヤーを作成し、自分の作業成果を簡単に分離およびテストできるようにしました。 この新しい抽象化により、Stella の実装は Stella が宣言したインターフェイスから分離され、チームの他のメンバーからも利用できるようになりました。 この種のプラグ可能なシステムは、明確に分離されたシステム アーキテクチャをもたらすと Stella は主張します。"インターフェイスを実装の境界として使用する手法は、オブジェクト指向設計として適切な手段になる" という考え方を Stella は意識しています。 この新しいプラグイン モデルにより、Stella はコードのうち自分の開発したセクション内でのみ作業することができ、他の領域で作業している他のメンバーに干渉することはありません。
Conway の法則が予見したとおり、Stella とチームの他のメンバーとのコミュニケーション状況、つまり、あまり密接ではない連絡状況 (疎結合) がコードに反映されるようになりました。 仮に全員が同じ場所で作業していた場合はメンバー相互で会話を交わすだけで済んだものが、Stella の設計はその会話を置き換えるものとなり、その結果、システムは必要以上に複雑になります。 この必要以上の複雑さは、開発チーム内での Stella と他のメンバーとの関係を映し出す鏡像です。 これらの決定は最終的に、会社の経費増加につながります。会社が所有するコード行が多くなり、将来の開発者が理解する必要のある間接的な作業、つまり遠回りとなる処理のレベルが増え、抽象化機能が正常に動作していることを実証するために追加のテストを実施する必要が生じるからです。
Stella は間違ったことをしたわけではありません。 実際、Stella はシステム内の問題領域を分離する、オブジェクト指向設計の適切な手法を活用することに成功しました。 残念ながら、Stella が分離した問題とは、自分が抱えているコミュニケーションの制約であり、このソリューションにより、コミュニケーションがさらに減少しても対応できるという事態を招いてしまいました。 悪いことに、この問題に対処するために Stella が変更を加えたシステムは、コミュニケーションではなくソフトウェアでした。 この問題に対処する効果的な方法として考えられるのは、開発チームの他のメンバーとのコミュニケーションを容易にすることでした。
チーム メンバー全員が同じ場所に集結していない場合は、口頭での気軽な会話の代わりに、少々堅苦しい、公式な意見交換を採用する傾向があります。 小規模な方針に関する決定を下すために、効率的な会話をその場で実施する代わりに、議題をいくつかまとめておき、後で会議を開催するときまで待つことになります。 多くの場合、後回しにした議題を解決する機会は決して訪れません。 対人のコミュニケーションが減少すると、意見交換は仕様書、作業チケット (各作業をチケットという形で管理し、各開発者に割り当てる)、さらにコードへの記述など他の形に姿を変える結果になります。 ISomeInterfaces は、コード開発に従事しているチームの機能不全に対処する目的で用意されたものです。
チーム分散に伴う予定外の複雑さ
スクラム チームの外部で意思決定を下すと、多くの場合は、複雑さが増加する結果になります。 ソフトウェア開発チームの構造や役割分担が最初から簡潔であることはめったにありません。一方、スクラムを使用すると、境界が設置され、スクラム チームはその中で物事を進め、複雑さを軽減することができます。 この事実にかかわりなく、実際のコード開発とソフトウェア納入に関係する複雑さはある程度限定されています。それに比べると、組織の文化やプロセスが原因で、開発チームの手法に関係する複雑さが大幅に増加する可能性があります。
したがって、異なるタイム ゾーンに住むメンバーでスクラム チームを構成するという決定が、実際に作業をするメンバー自身の手で下されることはめったにありません。 分散スクラム チームを作成するという決定を下すのは、多くの場合、専門分野を持つ高度に熟練したチームを編成しようとしているリーダーか、またはより可能性が高いのは、開発コストを削減する目的でオフサイトの請負業者を複数組み合わせ、低コストでソフトウェアを開発しようとする意思決定者です。 これらのモデルを使用する場合は、ソフトウェア開発の初期コストを削減できる可能性がありますが、通常、継続的なメンテナンスと、開発チームのコミュニケーションの苦慮に対応する目的で複雑さが増加するというコストを考慮に入れていません。
分散チームを編成する方法や理由にかかわりなく、分散チームが編成されることは現実であり、このような編成が消滅する兆候はありません。 分散チームの置かれた状況がどのようなものであっても、スクラムは引き続き、ソフトウェア製品の納入に関する計画と業務遂行を管理するための優れたフレームワークとして機能します。 チーム メンバーは、既存のコミュニケーション手法を改善し、上記の例のような望ましくない部分最適化を防止するという簡潔な対策を忠実に実行する必要があります。
分散の現実
分散チームは、居住地域にかかわりなく業務に適した人を雇用し、会社が拠点を置く地域とは異なる場所を選択する人を雇い入れるという機会をもたらします。 分散チームに反対する意見を表明することは簡単ですが、アウトソーシング (外部委託)、インソーシング (内部委託)、ニアソーシング (近隣諸国への委託)、ルーラルソーシング (国内地方部への委託) という、経済的な要因に基づく分散は多くの組織にとって引き続き必須です。
Scrum.org によって発行されている『Scrum Guide』は、スクラムを体系的に定義し、スクラム フレームワークを適用するための一連のルールを掲載しています。 『Scrum Guide』は分散チームに伴う問題について何も言及せず、それらの問題に対するガイダンスを提供していませんが、スクラム内のコミュニケーションに時間差や非効率性が生じ、地理的および時間的距離を埋めるためにメンバーが電子デバイスを必要とする結果になることは非常に明白です。
信頼性の問題
人間相互のコミュニケーションの多くは、小さな動作も含めたボディー ランゲージによって達成されます。 設計に関する話し合いの際に、他のメンバーの身振りを観察する形で収集された情報は、ホワイトボードに記載された情報と同等の重要度で認識されることがあります。 この理由により、分散チームを形成するメンバーの間にある距離を埋めるために、ボディー ランゲージが活用できないという障壁を克服することに注意する必要があります。
Steve McConnell (スティーブ マコーネル) 氏は次のように説明しました。「信頼の半減期は約 6 週間です。」[2] この説明は、毎日顔を合わせ、協調して働く開発者が、相互の信頼を毎日高めてゆく事実を認識しています。 どのような関係でも信頼の程度は変化しますが、チームメートが頻繁に顔を合わせ、協調して働く場合は、信頼の上限が最も高くなります。
チームメートが毎日顔を合わせることがなくなり、すぐ近くで働くことがなくなった状態がおよそ 6 週間経過すると、その関係における信頼レベルが以前のおよそ半分になります。 さらに時間が経過するにつれて、残っている信頼も急速に低下してゆきます。
これは、関係している開発者が相互に好意的な尊敬または敬意を抱いていない、という意味ではなく、信頼およびチームの影響が失われてゆくことを意味します。 信頼が欠けている場合は、協調の効果は低下し、チームメート間の境界が大きくなります。 このような境界は、多くの場合、コードに反映されます。
カメラ、TV 会議、インスタント メッセンジャー、ビデオ チャット、画面共有、他のコラボレーション ツールは、チームメート間のギャップを埋めるのに役立ちます。また、分散チームの生産性を高めるには、これらのツールがあたかも空気のようにありふれていて、気軽に使用できることが必要です。 ビデオを使用したリアルタイムのコミュニケーションを頻繁に実施すると、時間はかかりますが、信頼を徐々に蓄積して再構築する方法として利用できる可能性があります。
どのツールを使用する場合でも、信頼性の高いコミュニケーションを交わす機会を活用すると、分散チームは影響力を高めることができます。 要約すると、音声を直接聞くことができるコミュニケーション手段はインスタント メッセンジャーより望ましく、インスタント メッセンジャーは電子メールより望ましいと言えます。 相互のやり取りの間隔が短い方が、より良い手段になります。
分離度
互いに分離されたチーム メンバーが相手を見つける方法は多数存在し、チームの分散にも、一般的に採用される複数のパターンがあります。 他の環境 (ソフトウェア設計など) で見受けられるパターンのように、チーム分散のパターンが意図的または偶発的に設定されることがあります。 偶発的なパターンが発生するのは、既存の圧力に対してあまり強く意識せずに対応する場合であり、意図的なパターンが発生するのは、複雑さを管理するために熟考した上で実施する場合です。
ここで説明する分散スクラムのパターンは、事前に定義したもの、または意図していないものを指します。 このような分散スクラムは、スクラム チームの外部で行われる意思決定、または特定の問題に対処するためにスクラム チームが内部で下した決定に起因する可能性があります。 どのような理由で分散チームが編成されたかにかかわりなく、自然に採用される次の分散パターンが一般的です。
リモート開発チームは連携して働きますが、会社の他の部門からは物理的に分離しています。
リモート チーム メンバーのパターンでは、チーム内の 1 人のメンバーが、自分の所属するチームの他のメンバーとは異なる場所で働きます。
分散チームの個々のチーム メンバーは、同じ目標に向かって協調して働きますが、各自は異なる場所にいます。
リモート開発チーム
一部の開発チームは、大規模な上位組織とは地理的に離れた場所で働きます。より望ましくない状況では、製品所有者と地理的に離れた場所で働きます。 このパターンは、1 つの会社が他の会社を買収した場合や、2 つの会社が合併した場合に一般的に見受けられます。 開発チームをリモートの拠点に置く必要がある場合は、そのチームを管理し、組織全般とのコミュニケーションを確保する方法として、スクラムを使用するのが最善です。 多くのチームは、現在この方式で成功を収めています。
状況はさまざまに異なりますが、リモート開発チームは多くの場合、組織の本体から与えられている権限が少なく、過小評価され、切り離されていると感じています。 リモート チーム メンバーは、親会社から無視され、よそ者扱いされていると感じる可能性があり、(多くの場合は無意識のうちに) 本社に位置する部門より重要性が低いと考える傾向があります。
このようなリモート開発チームは頻繁に、正当化の理由と言い訳を繰り返し、自分たちの作業成果を他のチームと統合する機会を回避しようとします。 このスプリントの統合が重要ではない、必要ではない、または実現できないという意見を表明する可能性が高くなってきます。 不満が蓄積される結果、コードを組織全体のコードと統合することを求める要求に対して、開発チームは "不合理"、"現実的ではない"、"不必要"、"当チームのニーズが考慮されていない" などの見解を示すようになります。
これらの意見が妥当かどうかは、重要なことではありません。 リモート開発チームが必要としているのは、自分たちの意見に注意が払われ理解されているという感触を得ること、および上位組織で自分たちがどのように価値判断されているかを把握することです。 リモートの拠点でサービスを提供している場合は、チームや開発者個人がより大きな組織の一部であるという事実を忘れがちです。
スクラム マスターが開発チームとは異なる場所で働いている場合は、そのような障害をもたらす要因になります。 距離を隔てた場所にいるスクラム マスターは、指導、スクラム イベントの効果的な手配、スクラム自体への対応などを十分効果的に実施することができません。 開発チームとスクラム マスターの間に地理的な距離がある場合は、コミュニケーションが妨げられ、スクラム チームに過度に大きなリスクがもたらされます。 信頼を築くには親密な関係が必要であり、スクラムを成功させるには互いへの強い信頼が基盤にあることが求められます。
スクラム マスターが開発チームと同じ場所で働く場合。
開発チームが製品所有者に対してサービスを提供するうえで、コミュニケーションが妨げられず、明確な意思の疎通を実施できることも求められます。 各スプリントで、開発チームが製品所有者に連絡を取ることができ、質問に対する回答を受け、進行中の作業に対するフィードバックを得られることが必要です。 リモートの状況でもこのような頻繁なやり取りは可能ですが、このコミュニケーションを維持できる信頼性の高い方法を確立する必要があります。
製品所有者が常に不在、という事態は、スクラム チームが遭遇する可能性のある非常に有害な状況の 1 つです。 対応を受けることのできない開発チームは、機能や優先順位に関する決定を自ら下す必要があります。 このグループは、製品所有者に比べると、通常は顧客のニーズに関する情報をあまり多く得ていないため、適切な決定を下せる可能性が高くありません。
製品所有者が、スプリントを通じて開発チームに注意を払い、フィードバックを提供する場合。
残念なことに、製品所有者とチームが同じ場所にいる環境であっても、不在がち、またはほとんど連絡の取れない製品所有者は、スクラム チームの機能障害を引き起こす一般的な原因になっています。 スクラムの潜在能力を実現するには、スクラム チームがまとまりと信頼関係のある協調性の高いユニットとして機能する必要があり、そのために専任の製品所有者が定期的に注意を払うことが求められます。
リモート チーム メンバー
複数の開発者が共通の場所で協調して働いている状況で、一部の開発者はそれらのチームメートから分離された状態にあります。 従来からある例は、自宅で仕事をすることを前提として、チームと共に働く在宅勤務の開発者です。 この状況では理由は異なりますが、結果は非常に似通っています。
Alistair Cockburn (アリスター コーバーン) 氏は、浸透性のコミュニケーション[3] という用語を使用して、チーム ルーム内に固有のコミュニケーションの種類を識別しています。
浸透性のコミュニケーションという用語は、チームの他のメンバーが背後で話しているのを聞いているうちに、あたかも浸透が発生したかのように関連情報を受け取ることを意味します。通常、この現象が発生するのは、同じ室内で働いている場合です。その場合、1 人が質問をすると、室内にいる他の開発者はその質問に反応して話し合いに加わるか、何も反応せず自分の仕事を続けるかのどちらかになります。
浸透性のコミュニケーションは、ソフトウェア開発チームに限定されていません。 大手新聞社や放送局のニュース編集室を訪問すると、まさにこのような受け答えが頻繁かつ動的に行われていることがわかります。 世界各国の警察でも刑事部門が詰め所を使用して、犯罪の捜査を行うときに集合的な知識を増やそうとします。
逆に、浸透的なコミュニケーションが失われると、チーム内で状況対応能力が失われます。 あるソフトウェア開発者がソフトウェアに変更を加えるときに、他のソフトウェア開発者がその変更に気付かない場合は、チーム内のまとまりとコンテキスト共有の水準が低下します。 他の開発者の行動による中断が発生せず、自分の仕事に集中しているリモート チーム メンバーは、チーム ルームで見聞きされている重要な情報を耳にすることがありません。 リモート チーム メンバーは、設計や他の決定事項に関して一日中流動的に発生しているその場の話し合いから隔絶されています。
あるリリースから次のリリースまで、あまり期間を開けずにソフトウェアをより迅速に納入する傾向により、開発チーム内で状況対応能力をさらに高めることが求められています。 一方、チーム ルーム内にいないリモート チーム メンバーにとっては、単純に状況対応能力が失われていることになります。
この問題に対処するために、テレプレゼンス ソリューションがますます一般的になっています。 単純なテレプレゼンス ソリューションは、安価なノート PC、カメラ、スピーカーを使用して構築することができます。 チーム ルームにこのシステムを配置すると、リモート開発者が単純にチャネルを一日中開いておくだけで、コミュニケーション チャネルを開く機会が提供されます。
ビデオ会議、または TV 会議と呼ばれる手段は、ボディー ランゲージの障壁に対処するのに役立ちます。
チームの一員として活動するためにリモート開発者が苦慮している兆候として、次の行動を挙げることができます。
複雑な問題について相談するために、電子メールやインスタント メッセンジャーのような文字を主体とするコミュニケーションを使用します。
他の開発者との定期的な話し合いの代わりに、コード内のコントラクトを固定的なインターフェイスとして定義します。
バージョン管理の一環として、プライベートまたは個人用のコード分岐を設けることを希望します。
リモート開発者とチーム全体の間にあるギャップを埋めるために、定期的に交流を持つ方法は非常に有効です。 ビデオ会議は、電話の話し合いより推奨されます。 電話による話し合いは文字入力より優れており、電子メールのみに依存するのは、やがて問題が発生するのを待っているようなものです。
分散チーム
本当の意味で適切に編成された分散スクラム チームの個人は、各チーム メンバーが異なる場所で働いているにもかかわらず、共通のスプリントの目標を達成するために協調して作業を推進します。 代表的な例は、世界中のさまざまな場所に住む共同作成者が参加しているオープン ソース プロジェクトです。 コミュニケーションの問題は重要ですが、このモデルは有効性を実証してきました。 このようなチームは必然的にコミュニケーションの課題に取り組むことになりますが、テクノロジがボディー ランゲージの障壁を継続的に緩和しているため、適切な対策が一般的に採用されるようになっています。
チーム メンバーが別の場所にいる場合は、設計やコードに関して効果的に話し合うために、画面共有ソフトウェアが重要な役割を果たします。 コードに関して、会話に参加している両者が同じ表示を目にしていない場合は、話し合いに含まれる前提があまりにも多くなります。 さいわい、画面共有ソフトウェアは容易に利用でき、非常に効果的です。 チーム メンバーが同じ室内にいない場合は、1 日に数回チームメイトと画面を共有して、相手が何をしているかを確認することをお勧めします。
画面共有は、ペア形成とコラボレーションに関する非常に有効なツールになる可能性があります。
コード、バックログ項目、他の制作物を検討し、改善点や問題の原因を協調して探すことは、分散チーム内で状況対応能力を高めるための優れた手段です。 もう 1 つの効果的な手法は、スプリントの一部として納入されるあらゆる項目に対して簡潔な検証規則を追加することです。 2 つの部分で形成される規則は次のとおりです。
各項目の作業が完了したと見なされるには、統合環境で検証する必要があります。作業を行ったのと異なる開発者が、この検証を実施する必要があります。
この簡潔な規則を採用している開発チームは、チーム全体でどのような作業が実施されているかに関して、より包括的な集合的知識を獲得しています。
筆者による注釈筆者は開発チームの一員として働いています。このチームのメンバーは同じビル内にいますが、部屋は別です。会社がすべての従業員の自尊心を高める目的で、各従業員に専用の部屋を割り当てているからです。開発チームは最終的に、各チーム メンバーがカメラとマイクとスピーカーを使用して互いを表示できる仮想チーム ルームを作成するという合意に達しました。仮想チーム ルームは常に開放された状態にとどまり、チーム メンバーは共有している製品の作業を進めるときは常にこのルームに立ち寄ります。短期間のうちに、チームはこの仮想ルームの価値を認めるようになりました。チーム メンバーは、ミーティング ルームまで降りる代わりに、より迅速にアクセスできる画面共有ソフトウェアを使用して他の開発者の画面を表示するようになりました。やがてチームは、厚さ数インチの壁で区切られた部屋にいるにもかかわらず、仮想チーム ルームを一日中使用するようになりました。とうとう、1 人のチーム メンバーは数日間にわたって自分の部屋にもやって来ずに、自宅で仕事をするようになりました。開発チームがスプリントを振り返った際に、仮想チーム ルームを活用すると、開発者がミーティング ルームまでドアを数枚隔てた部屋にいるか、自宅にいるかは関係なくなるという結論に合意しました。仮想チーム ルームは、個別の部屋より価値が高いことを自ら実証しました。
ツールと手法
アジャイル チームは作業を管理するために、高度なテクノロジを必要とせず、信頼性の高いツールを使用して、さまざまな取り組みを進めています。 地理的な分散または複数の開発チームに伴う複雑さが加わる状況では、アナログ式のインデックス カードやマーカーを使用する方法は、ソフトウェアベースのソリューションほどのスケーラビリティを達成できません。 この結果、スクラム チームやアジャイル チーム向けに非常に多様な作業管理ツールが設計されており、多くのツール ベンダーは "当社のツールを使用すると開発チームがますますアジャイルになります" と宣伝しています。
混乱をもたらすツールと手順
もちろん、どのツールを使用しても、それだけでチームが "アジャイルになる" ことはありません。 純粋なアジリティの要因になるのは、ソフトウェアの開発と納入を行う人材の文化、態度、行動です。 このことが原因で、アジャイル宣言[4] では、"プロセスやツールを上回る個人とその相互作用" に価値を認める方針が表明されています。
アジャイル コミュニティの格言は、"人材はプロセスに勝り、プロセスはツールに勝る" です。
現実主義者の格言は、"ツールを使用すると規則が制定される" です。
これらの格言は両方とも、コミュニケーション、コラボレーション、作業の管理の目的でソフトウェアを使用する人材相互の関係が重要であることを物語っています。 作業追跡ツールはコミュニケーションと相互理解の複雑さを軽減することを意図していますが、正反対の結果が生じる可能性もあります。 開発者が、不具合を修正する代わりに、その不具合を対象とする不必要なレポートを作成するというよくある落とし穴に陥るのは珍しいことではありません。次のような例があります。
筆者による注釈 ツール、プロセス、手順の間のバランスを考慮する際に役立つリソースは、Kent Beck (ケント ベック) 氏によるホワイト ペーパー Tools for Agility (アジリティを意図したツール) です。このペーパーは、ベック氏が 2008 年に作成したものですが、現在もなお洞察に富むものです。
作業追跡システムや機能追跡システムに格納されているデータが最新版ではない状況で、スクラム マスターと開発チーム メンバーがデータに注目せず "このツールは時代遅れだ" と嘆く傾向があります。 この傾向は、開発者が直感的に理解している事実を無視しています。
目標は、ツールを最新版にすることではなく、チームが最新の状態を維持することです。時には、この点でツールが役立つこともあります。
スクラムは特に、スクラム チームの状況対応能力を向上させる目的で設計されたものです。 スクラムは、要件の形式、議事録の保存、作業の分割、見積もりに使用する単位、時間の追跡について何も言及していません。 状況によっては、チームはこれらの事項が役に立つと考えて、スクラムの枠内でこれらの事項を意識して作業を進めることもできます。 ただし、チームはこれら追加の手順を目的とするのではなく、スクラムに加えてこれらの手順を使用することになります。
ツールを使用した支援用の手順
スクラム チームがどのようなツールを使用する場合も、ツールを先に選択するのではなく、特定の手順を選択し、その手順を支援するツールを選択することが望まれます。 つまり、健全なスクラム チームは意図的に向上を遂げます。 チームは特定の分野での向上を意図しているので、この目的を果たすために新しい手順や手法を選択して試行する必要があります。 ツールを使用して新しい手順を支援するのは、基礎となる手順を試行して成果が得られた後です。 要約すると、次のようになります。
最初に、総合的に優れている人材を選択します。自己編成に対応できるチームは、独自の手順を選択し、最終的に、選択した手順を支援するツールを選択します。人材をプロセスより重視し、プロセスをツールより重視します。
(Microsoft Visual Studio 2012 で使用できる、手順を支援するツールの詳細については、「共同作業 (より専門的な情報) [リダイレクト]」、「共同作業 [リダイレクト]」、および Visual Studio Online の「はじめに」ポータルにある詳細はこちら」セクションを参照してください)。
チーム メンバーがどのように協調したかに応じて、チームが作成したソフトウェアは紛れもなく明白な影響を受けます。 コミュニケーションが容易で効果的に実施された場合は、作成されたソフトウェアの設計にもそのことが反映されます。 逆に、チームが内部のコミュニケーションやサービス提供者とのコミュニケーションに苦慮した場合は、そのチームが作成したソフトウェアにも、チームが直面した障壁が反映されます。
スクラムによって実施される定期的な検査と適合のサイクルは、長期的には分散という状況でチームを助けることになります。 スクラム内で事前に定義されたイベントは、コミュニケーションを促しますが、必ずしもコミュニケーションの形態に影響を及ぼすとは限りません。
同じ場所にあるチーム ルームを使用すると、高度なテクノロジなしで非常に高い信頼性を確保し、非常に効果的な方法でチームが協調して、複雑なソフトウェアを作成することができます。 ただし、リモート チームも現実に存在しています。 個人的に意欲の湧く状況に取り組んでいるか、経済的な利点があるか、先見の明が欠落していた不本意な状況であるか、どのような理由であっても、ますます多くのスクラム チームが、チーム メンバー全員が物理的に集結していない状態で作業をするようになっています。
物理的な境界を越えてチームのコミュニケーションを推進すると、高い品質、混乱の回避、高いスループット、各個人の満足度の向上というメリットが得られます。 チーム内で使用するツールと手順について十分考慮すると、分散チームも適切に機能する可能性があります。 非常に良好に機能する可能性さえあります。
参考文献
Herbsleb, 1999 Architectures, coordination, and distance: Conway's law and beyond. (アーキテクチャ、調整、および距離: コンウェイの法則とその克服) IEEE Software, 7
McConnell, S. (2009). Travel Restrictions and Offshore Development. (移動の制約とオフショア開発)
Cockburn, A. (2008). Osmotic Communication. (浸透性のコミュニケーション)
various. Agile Manifesto. (アジャイル宣言)