グローバルチームのスクラムとスクラムマスター
私は、1人の開発者を技術リーダー（私）として使用するモデルで、オフショアチームを調整するオンショアコーディネーター/開発者と一緒に働いています。オフショアチームにはオフショアコーディネーターがいます。 。奇妙に聞こえますが、基本的には機能します。
残りの開発者はオフショアです。私はたまたま、追加のオンショア開発者がいるプロジェクトに参加しています。
私の質問は、ここでアジャイル手法を大まかに使用できると思いますか（私たちはウォーターフォール会社ですが、スクラム、スプリント、プランニングポーカーなどを行うことができます）？また、スクラムマスターの恩恵を受けることができると思いますか？追加のオンショア開発者がいなかった場合はどうなりますか（基本的に、私は2人のオンショア開発者の1人になり、どちらもプロジェクトにフルタイムで参加しない可能性があります）。私が行っているコーディングをあきらめて、スクラムマスターと技術リーダーになるのはどうですか？今の私の義務については、以下の私のコメントを参照してください。
多くのスクラムプラクティスが役立ちます。それらのいくつかは、プロジェクトのウォーターフォールの性質を考えると、別の方法で対処する必要がある問題を示します。ウォーターフォールでも役立つと思うものは次のとおりです。
- 毎日のスタンドアップ（電話またはビデオ会議で行うことができます）
- 回顧展（電話、ビデオ会議、または電子メールによる）
- 増分および反復配信
見積もりと速度に関しては、スクラムは変更のコストがかなり一定であることに依存しているという点で少し奇妙ですが（以下を参照）、実際にはそれを行うためのプラクティスを規定していません。推定と速度の測定の使用を開始したい場合は、XPプラクティス。TDD、ペアプログラミング（または配布されている場合はコードレビューを使用）など）も確認します。 、協調的なコード所有権、リファクタリング、継続的インテグレーションも、特にチームの分散を考えると、ソフトウェアの品質を向上させます。
ただし、見積もりと速度の目的は、効果的で適応性のあるリリース計画を可能にすることです（チームのコミットメントを促進することもできます）。アイデアは、リリースレベルのバーンアップまたはバーンダウンによって、期限を設定するかどうかが示されるということです。スクラムでは、範囲を縮小するか、期限を延長することで、期限を逃すという発見に対応します。ウォーターフォールでは、そのオプションがない場合があります。少なくともそれはあなたにもっと多くの情報を与え、あなたが最後にクランチするのではなく、おそらくより長い期間にわたってより効果的に働くことを可能にし、そして確かにあなたがそのリスクについて話し合うのを助けます。
あなたにとっての本当の危険は、製品を段階的に提供して展示することによって、ビジネスが彼らの考えを変える可能性が増加であるということです。これは、ウォーターフォールの予算や大幅な変更管理ではうまく機能しません。チームが分散していると、コミュニケーションや変化への適応が難しくなります。別の方法は、チーム内でのみ増分を紹介し、ビジネスが望まない可能性のあるソフトウェアを提供することですが、それがウォーターフォールの考え方です。間違っているという発見に反応するのではなく、最初から正しくすることに重点が置かれています。その政治に対処できるのであれば、どのような形のアジャイルも良い動きです（スクラムの実践者は、チームが同じ場所に配置されていなければ、スクラムではないと言うことがよくあります）。
経験豊富なスクラムマスターまたはコーチが役立つかもしれません。彼らは、反復配信のメリットを売り込み、関連する政治を通じて話し合うことに慣れています。
スクラムが一般的に推奨されないシナリオの1つは、分散チームです。チームメンバーが同じワークスペースになく、同じtimezoneである場合、正しいスクラムプロセスを作成することは非常に困難です。スクラムは、チームメンバー間だけでなく、チームメンバーと製品所有者の間のコミュニケーションにも関わっています。あなたの製品の所有者はあなたのサイトにいますか、それともオフショアサイトにいますか？いずれの場合も、1つのサイトが製品の所有者と効果的に通信できません。スクラムマスターでも同じことが起こります。スクラムマスターが異なるタイムゾーンで作業している場合、どのようにして障害をできるだけ早く解決できますか？
プロセス記述のもう1つの問題は、実際には技術リーダーの立場です。スクラムチームは、権限を与えられ、クロスファンクショナルな人々の自己組織化されたグループです（権限を与える人々は主要なアジャイル信条の1つです）。それは彼らがあなたにいくつかのアドバイスを求めることができないという意味ではありませんが、同時に彼らはそうする必要はなく、彼らは彼らのやり方でそれをすることができます。
多くの企業はあなたが説明したことを正確に行っており、彼らはスクラムと呼ばれるものを使用しています-私はそのような企業の1つで働いていました。オフショア開発はコストを削減するための特効薬であるという世界的なおとぎ話がありますが、私の経験では、オンショア開発者とオフショア開発者を同じチームにまとめるべきではありません。 2つの別々のチームを作成するか、開発全体を1つのサイトに移動します。
分散型チームを使用すると、電話やビデオ会議に追加のコストがかかるだけでなく、出張にも高いコストがかかります。たとえば、新しいプロジェクトを開始する場合は、サイト全体（オフショアまたはオンショア）を1つまたは2つのスプリントで単一の場所に移動して、人々が互いに出会い、基本的な関係を築くようにする必要があります。個人的にお互いを知ることは、士気にとって常に良いことです。
私はこれを私の最後のチームであるMicrosoftのパターンと実践で数年間行っていました。分散型アジャイル（スクラム/ XP）の実行で学んだことに関するホワイトペーパーは次のとおりです。
http://www.ademiller.com/blogs/tech/2009/08/distributed-agile-development-at-Microsoft-updated/
これは、同じトピックに関する他の人の作品への講演といくつかのリンクです。
http://www.ademiller.com/blogs/tech/2010/11/distributed-agile-development-at-oredev/
あなたが見ているものはかなり典型的なようです。技術リーダーはオンショアであり、コードのレビュー、オンショアの利害関係者とのやり取りなどに多くの時間を費やしています。
あなたの会社はウォーターフォールアプローチを使用しているので、あなたは確かにそうすることができ、そうしない理由はありません。
まず、スクラムミーティング、毎日のスタンドアップ、またはあなたがそれらと呼びたいものは何でも良いです、ただの形式に固執してください
- 前回のスクラム以来、私は達成しました
- 次のスクラムまでに達成します
- 私が達成したことに影響を与えた予期しない障害
- 現在と次のスクラムの間に予想される障害。
次に、スプリントのアイデアがあります。オフショアチームの最大の問題の1つは、彼らが生産しているものを把握し続けることです。 「仕様です。完成品で3か月後に会いましょう」と言うのではなく、スプリントを使用して作業を管理可能なセクションに分割します。
最後に、利害関係者の関与とフィードバック。これはスプリントに結びついており、基本的には、これまでの作業を支払いをしている人々と検証し、進歩があることを示すチャンスです。問題がある場合は、すぐにつぼみに挟むことができます。
私の質問は、ここでアジャイル手法を大まかに使用できると思いますか（私たちはウォーターフォール会社ですが、スクラム、スプリント、プランニングポーカーなどを行うことができます）？また、スクラムマスターの恩恵を受けることができると思いますか？追加のオンショア開発者がいなかった場合はどうなりますか（基本的に、私は2人のオンショア開発者の1人になり、どちらもプロジェクトにフルタイムで参加しない可能性があります）。
いいえ。アジャイル開発の主なポイントは、事前に計画や設計を行うのではなく、緊密なコミュニケーションループです。
あなたの場合、チームの他のメンバーとのコミュニケーションが困難になります。
「ウォーターフォール」タイプの組織と両側に2人のコーディネーターがいることを考慮すると、多かれ少なかれ作業プロセスがすでに確立されていると思います。ある種の事前の設計、ある種の計画があります。スクラムで良くなります。
もちろん、毎日の会議のようなものは役に立つかもしれませんが、それは「スクラム」ではなく、単なる常識です。