ALM ガイダンス

Visual Studio ALM Rangers - 仮想チームから得られるヒント

Willy Peter Peter

Brian Blackman

 

Visual Studio ALM Rangers は、スキル、動機、取り組み、所属プロジェクト、制限事項が異なる、世界各国からのメンバーが結集したチームを組織、管理することについて貴重な教訓を得ています。ここでは、当チームの経験を読者の皆さんと分かち合い、理想的とは言いがたい分散環境および仮想環境においてチーム作業を行っている方へのガイダンスを提供します。

前回も触れましたが、Rangers は、不足している機能に対処し、導入を妨げるものを取り除き、実世界での経験に基づいたベスト プラクティスとガイダンスを提供しながら、Visual Studio 製品グループ、Microsoft サービス、および Microsoft Most Valuable Professional (MVP) コミュニティの間の連携を推し進める専門家グループです。

今回はまず、Ruck という Rangers 独自のプロジェクト管理プロセスを定義します。次に、仮想チームの課題をまとめます。その後、アプリケーション ライフサイクル管理 (ALM) ソリューションとして Ruck と Visual Studio Team Foundation Server (TFS) を使用して行った Rangers プロジェクトの観察結果をお見せします。最後に、Rangers とその他の同様の環境にある仮想チームにとっての推奨事項を紹介します。

Ruck とは

Rangers は、業務とソリューション製品の質を高めるため、自社製品の Visual Studio TFS を ALM ソリューションとして使っています。潜在的な投資効果が高い主要領域は、プロセス モデルと、関連する要求管理プロセスです。ここでの主な目的は、Rangers によるイニシアティブの大きな特徴を見つけ出しそれに対処する、反復可能で体系的な方法を作成することです。プロセスの定義と進化は、飛行中に飛行機のエンジンを修理するような難しい作業であることが証明されていますが、プロセスのバリエーションをうまく活用しているプロジェクト チームもあるので、これは強固な柱と見なすことができます。読者を方法論の点で戸惑わせたり、プロセスの熱狂的支持者を困らせたりしないように、Rangers 独自のプロセスを "Ruck" と暫定的に呼んでいます。Ruck とは、ラグビー用語で "緩いスクラム" を意味します。

Rangers チームの仮想環境での課題

Rangers がしばしば直面する課題は、「1 人 1 人が自分の仕事や家庭と、Rangers の世界や活動とのバランスをどうやって取るか」ということです。Rangers の作業はこの 3 つの中で優先順位が最下位になることが多く、深夜に行われることもよくあります。Rangers のエコシステムは独特で、そのソリューションは準備ができ次第リリースようなものではありません。テクノロジのマイルストーンとソリューションへの要求によって暗黙のうちに期日が設定されます。1 日の時間を延ばす魔法はまだ見つかっていないため、Rangers 個人のテクノロジに対する情熱と、Rangers の作業に余裕を生み出せる可能性のあるコミュニティが頼りです。その結果、膨大な量のコンテキストの切り替えを吸収して、短く、場当たり的で、ランダムな力の発揮によって高品質の製品を提供することができるすばらしい IT プロフェッショナルが誕生しますが、それだけではなく、スクラムに反するプロセスも生まれます。

まだ少数の Rangers しか含まれていない Rangers リスト (bit.ly/9LKgZb、英語) で、チーム メンバーのさまざまな所在地を見ると、Rangers (つまり、我々のチーム) は地球全体に広がっていることがわかります。チームは、さまざまな文化の人々と作業をしているため、文化ごとに異なる標準や習慣について推測することも、その環境を軽視することもできません。したがって、文化的な違いに対応するため、状況に応じたリーダーシップやプロセスを取り入れました。詳細については、Kenneth H. Blanchard、Patricia Zigarmi および Drea Zigarmi 著『1 分間リーダーシップ - 能力とヤル気に即した 4 つの実践指導法』(ダイヤモンド社、1985 年) を参照してください。

図 1 に見られる広範囲に及ぶ時間帯が原因で、チーム メンバーの中には、進捗会議または設計会議のために、深夜や尋常ではない時間まで起きていることを余儀なくされる人もいます。これは、愉快でもなければ生産的でもありません。

図 1 典型的な Rangers の会議は時間帯をまたがる

製品グループ、サービス、パートナー、MVP、コミュニティなどの多様なエコシステムからの Rangers が連帯することにより、すべてが Rangers のエコシステムと認識プログラムによって内包される必要があるさまざまな動機や取り組みが取り込まれます。

透明性を最大限にしたり、だれもがすべてのものにアクセスできるようにしたりすることを目指してはいますが、機密保護契約、ライセンス、インフラストラクチャの制約が原因となり、例外も生まれます。

頻繁なコンテキストの切り替え (およびプロジェクトや機能領域の開始と停止) は、チームの士気を低下する原因となるため、最も困難な問題です。この結果として、興味深くはあるものの、状態や進捗を把握するために効率良く使用するにはふさわしくないスプリント バーンダウン チャートが生まれます (図 2 参照)。図 2 の 1 つ目のグラフは、タスク作業項目の増加を表しています。タスク作業項目は、個人またはチームが、当初思っていたよりも製品バックログ項目の実装が大変であることに気付くたびに増しています。2 つ目のグラフは、顧客の要求によってプロジェクトの作業が停止したことを示しています。図 3 の速度グラフは、コンテキストの切り替えおよび機能領域の開始と停止がもたらす影響について先ほど言及したことを実証しています。

図 2 課題を反映しているスプリント バーンダウン チャート (画像をクリックすると拡大表示されます)

図 3 プロジェクトの速度

また、Rangers プログラムの自発的な性質により、説明責任は大きく変化するため、納品についての取り組みを強制する選択肢がほとんどありません。さいわい、ほとんどの Rangers は、自身に説明責任があると考えているため、Rangers チームの大半はいつも期日どおりに納品します。

最近のプロジェクトの分析と学習

既に説明したように、チームが 1 か所にまとまっていない場合、チームの所在地がさまざまな場合、また Rangers のメンバーとなる情熱を超えるほどの個人の取り組みがない場合は、いくつかの課題が生じます。これには、地域ごとにチームをまとめることで対処を試みましたが、現在地に関係なく開発者に関心のある領域を選択してもらうというチームの主義に反するため、うまくいかないことがほとんどでした。したがって、特定のプロジェクトに対して適切に機能するベスト プラクティスを判断するために、他に頼らず、経験を生かす必要がありました。

チームの仮想エコシステムの性質から、スクラムなどのプロセスのあらかじめ決められた膨大な規則を破ることが必要になるため、Kanban (カンバン) のように、プロセスを自分たちのニーズに合わせて調整しました。Kanban については、David J. Anderson 著『Kanban: Successful Evolutionary Change for Your Technology Business』(Blue Hole Press、2010、英語) を参照してください。さまざまな方法を使い、各プロジェクト固有の属性に基づいて、状況に応じたリーダーシップをプロジェクトに適用します。たとえば、すべてのメンバーには本業があるため、会議の開催は週単位にします。毎日開く会議 ("日常会議") は、束縛が強く、回数が多すぎます。さらに、Rangers の会議は、同時に参加できるメンバーの数が非常に少ないため、毎日行われるスクラム会議のようにはいきません。複数の時間帯に対処するために、1 日に 2 つの会議を開かなくてはならなくなります。

Rangers プロジェクトの複雑さによって、透明性、頻繁なコミュニケーション、チェックポイント、および会議が必要になります。だれでも家族や本業などのための時間が別に必要なので、チームを過剰に束縛することは避ける必要があります。学習して適応するごとに、独自のプロジェクト パターンを確立してそれらを適合させ、より良い影響を及ぼしていきます。以下にそのパターンの例を挙げます。

• チーム メンバーは興味のあるタスクに登録する
• 適切なタイミングで重要なチェックポイントやマイルストーンをメールで通知し、さらに作業の進捗も目に見えるようにする
• 毎週会議を開く

前述の課題は、プロジェクトのリズムが変わるたびに悪化します。これは、Rangers のエコシステムに限ったことではありません。プロジェクトの開始時にはよくあることです。新しいチームの全メンバーが最終的に同調して正常なリズムで作業を実行するようになるまでには、いくつかの手順や誤りが必要です。

筆者はマイクロソフト以外の大きなオープン ソース コミュニティに直接かかわったことがないため、ここに書くことは、別の出版物やブログ記事から推測したことに基づいています。オープン ソース プロジェクトとは異なり、Rangers プロジェクトには、定められた出荷日という考え方があります。一般に、ほとんどのオープン ソース プロジェクトは、どれだけ長くかかっても、完了してから、またはリリースに値するようになってから出荷されますが、Rangers プロジェクトでは多くのメンバーが自分たちの成果物に強く依存します。開発サイクルが長くなると、Visual Studio の新しいバージョンがリリースされてしまい、最新の状態で作業を進められなくなります。定められた出荷スケジュールがあることで、プロジェクトの運用は反スクラムと考えられます。ただし、これが期日が設定されたスプリントと異なるとは考えません。チームは、プロジェクト全体の期日を設定するためです。

Rangers プロジェクトでは、MSF for Agile Software Development v5.0 または Microsoft Visual Studio Scrum 1.0 のいずれかのプロセス テンプレートを使用します。後者の方が軽量のためはるかに人気があります。プロジェクトには、いくつか事前の計画と設計が必要です。プロセス手法の中には、これを pregame (実施前) と呼ぶものもあります。この pregame が機能するように Sprint 0 を使用して開始し、計画と設計の期日を設定します。これにより、開発の開始日と目的が認識されます。Sprint 0 では、チームで必要なトレーニングを実行し、環境、計画、調査をセットアップして、エピックの優先順位を決定し、Ruck プロセスを確認します (Ruck プロセスの詳細については後ほど解説します)。Visual Studio Lab Management などの製品について検討するときは、環境のセットアップがきわめて重要です。

Ruck プロセスには、スクラムのように、頻繁なチェックポイントが必要です。先ほど説明したように、毎日行われる会議は Ruck チームには負担が大きすぎます。したがって、日常会議の代わりに、Microsoft Lync を使って、週ごと、または時間帯ごとに会議を開きます。これらの会議は、出席者が現在の作業、次の作業、障害があるかどうかについてたずねられる、従来の方法で行われます。さらに、この機会を使用して、重要なメッセージを伝えたり、プロジェクトまたはスプリントのビジョンを繰り返したりします。チームには、実際に目で見えるように説明することに最も効果があるという教訓があります。Ruck マスターまたは開発リードは、デスクトップをメンバーと共有し、スプリント バーンダウン チャートを示して、現在のチーム メンバーが対処する必要のある作業項目の一覧を見せます。実際に見せることが鍵です。

図 3 を見てもわかるように、Rangers プロジェクトは、一貫した速度を保つのが困難であることがほとんどです。これは、チームのキャパシティが常に流動的であるという、チームが持つ反スクラムの性質によるものです。すぐにプロジェクトを外れるチーム メンバーが出る可能性があるため、仕事を完了させるために創造力を使って管理したり、新しいメンバーを勧誘したりする必要性が生まれます。これは Rangers プロジェクトにはよくある状況なので、Rangers プロジェクトに携わっているときに深くかかわることの重要性を強調するために、Rangers マニフェストを制定しました。

プロジェクトとチームは、規模が小さいほど、正常に実行したり、リズムを適切にしたり、チーム メンバーが密接に取り組んだりすることが可能になることがわかっています。また、メンバーは、大きなチームよりも小さなチームの方が抜けにくいと感じます。図 4 は、作業項目を適切なリズムで完了していて、かつ図 2 よりも理想的な傾向を示しているスプリント バーンダウン チャートです。

図 4 適切なリズムから適切なバーンダウン チャートが生まれる

機能を簡潔に説明するためには、エピックを使用します。これは、顧客がオンサイトにはいないため、リアルタイムに詳細を提示することができないので、機能についてより包括的な話をするという、アジャイル コミュニティによるエピックの用途にかなり近いものです。エピックは、だれかがソリューションをインストールする理由やガイダンスをダウンロードする理由について説明するものと見なすことができます。このエピックは、機能のビジョンについてのガイドを提供して、作業を作り上げる場所である、関連するユーザー ストーリーの作成を促進します。初期設定済みの TFS プロセス テンプレートには、作業項目の種類にエピックがないうえ、テンプレートのカスタマイズを避けなくてはならない制約があるため、ユーザー ストーリーのタイトルの冒頭に "Epic" と付け (図 5 参照)、この作業項目に 0 という優先順位を付けて、レポートやレポート フィルターで簡単に特定できるようにします。

図 5 ユーザー ストーリー作業項目のタイトルの冒頭に Epic を使用 (画像をクリックすると拡大表示されます)

Rangers プロジェクトには、開発者、テスター、Ruck マスター、開発リード、製品責任者、エピック リード、レビューアーなど、大まかに定義された複数の役割があります。多くの場合、チーム メンバーは複数の役割を担います。1 人のメンバーが、ある機能の開発者になったり、別の機能のテスターになったり、別のプロジェクトのレビューアーになったりします。3 人の主要 Rangers は、通常、すべてのプロジェクトで固定された役割を担います。Bijan Javidi がマネージャー、Willy-Peter Schaub が開発リード、Brian Blackman が Ruck マスターおよびコーチです。

頻繁なチェックポイントと完全な透明性が必要なため、コミュニケーションが、プロセスとエコシステムにおけるきわめて重要な部分になります。コミュニケーションが適切に行われれば、地理的に分散したチームの間で支えとなり、互いに注意し合える、協力的なネットワークが構築されます。チームへの帰属意識を高めるためには、常に仮想的な対面式のキックオフ ミーティングを行い、ミーティングにおいては、共通の目標、目的、動機、ビジョン、メリット、スコープ、および制限を定義します。最も重要なのは、このキックオフ ミーティングの間に、チームがインフラストラクチャとコミュニケーションのガイドラインに合意することです。

この後に解説する Ruck-of-Ruck (ruck の中の ruck) 会議では、毎週開催する会議に全員が出席する必要性を最小限に押さえ、状態と障害を明白にし、場当たり的で、自発的な、あらかじめ定義されたコミュニケーションを使用します。会議においては、TFS の作業項目追跡 (WIT) と、エピックの割り当て (図 6 参照) を使用して、進捗、バックログ、機能、受け入れ基準、バグ、障害などの情報を得て、公表します。日常会議の議事録は wiki に記録し、ドキュメント内の設計情報は共通のポータルに格納します。議事録をソース管理に格納する場合もあり、これは (その他すべてのインフラストラクチャ コンポーネントのように) 世界中のどこからでもアクセス可能です。

図 6 Rangers エピック、製品バックログ項目、タスクの構造の Team Foundation Server の成果物への割り当て

コミュニケーションと連携の主な手段は共有ポータルですが、最も重要なものとして電子メールがあります。配布リストと統制語を使用すれば、電子メールは現在のプロジェクトのスコープ外の Rangers を含めてすべてのメンバーと共有されます。これにより、関係者全員がすべての情報を確実に受け取ることができ、透明性が促進されます。また、電子メールのルールを使用すれば、特定の情報に関心のあるメンバーがその情報についてのメールを受け取れるようになります。

文化と作業状況による影響を把握して対処する

コミュニケーションと管理のスタイルは、国によってさまざまです。堅苦しく、他人行儀なコミュニケーションを好み、明確に定義された管理者の役割や期待を求める文化もあれば、堅苦しくなく、面と向かった、しばしば協力的な管理を行い、"抱擁" が尊敬の印になる文化もあります。潜在的な問題を明確に定義して、仲が悪くまとまりのないチームの原因となる誤解をなくすために、この多様性を認識する必要があります。他の多くの ALM および仮想チーム メンバーと同様に、透明性は、文化の問題に積極的かつ継続的に対処するために重要です。

時間帯の違いと文化の違いは、しばしば密接に関係しています。1 日中働くことをいとわなかったり、さらに重要なことに、チーム会議に出席するために深夜のとんでもない時間に起きていてもかまわなかったりする文化もあれば、家族と過ごす時間をプロジェクトに費やすのを非常に嫌がる文化もあります。チーム メンバーが快適に感じ、連携が可能な環境を作るためには、チーム全員が電話会議やオンライン会議に参加するのに適したメカニズムや時間を見つけることが重要です。Rangers のコミュニケーションと連携の大半は、電子メールを通じて行われますが、電子メールよりも重要なのが、TFS チーム プロジェクトおよび関連するポータルです。また、連携を促進したり、状態を共有したり、チームの独自性を継続的に発展させたりすることができる、チームの定期的な日常会議の予定を立てるのにも細心の注意を払います。時間帯を越えた複数の日常会議の予定を立てるとき、チーム メンバーは自身の時間帯の制約を受けません。自身の時間帯と仕事に見合う複数の会議に参加することができます。Ruck-of-Ruck の日常会議は、連携と、特に WIT インフラストラクチャを使用して、状態を上向きに集約します (図 7 参照)。完了後、1 つに統合されたチームの状態は、チームが選んだコミュニケーション メカニズムを使用して、チーム全体と関係者が特に意識しなくても共有できます。

図 7 Ruck-of-Ruck の日常会議

図 8 は、1 つの時間帯で稼働していて、機能領域ごとに分かれており、1 人の情熱的な機能リードが各領域専門のチーム メンバーと作業する、理想的な仮想チームを示しています。

図 8 理想的な仮想チーム

実のところ、通常の Rangers チームは、世界中の多くの時間帯にチームが分散している図 9 のようになります。チーム リードは、さまざまな時間帯における臨時のリソースと作業し、プロジェクト内のいくつかの機能領域に重点を置くことが多くなります。

図 9 典型的な仮想チーム

全員がすべての情報にアクセスできるようにして、完全な透明性を確保し、実用的で支配関係のないチーム環境を発展させ、最先端の ALM テクノロジを活用することで、効率的かつ情熱的なプロジェクト チームを作り上げることができています。図 10 のように、すべての Rangers が、作業項目、ソース管理、プロジェクト ポータルおよび全体的な Rangers ポータルを含む 1 つのRangers ポータルからすべてのプロジェクトにアクセスできます。Rangers は、電子メールの分類に統制語を使用するため、簡単にフィルターをかけたりルールを使用したりすることが可能です。

図 10 典型的な Rangers のインフラストラクチャ

作業状況の多様性はおそらく、仮想チームの最も困難な部分です。Rangers は、臨時のチーム メンバーであり、それが原因で通常の営業時間中につながらなくないことが多いだけでなく、ほとんどの場合セキュリティが確保された環境で作業しているため、パブリック ドメインと Rangers ALM インフラストラクチャへのアクセスが制限されます。さらに、9,600 bps の回線や 56KB のモデムがいまだに標準のインフラストラクチャである、とても理想的とは言えない環境で作業している Rangers もいます。その結果、高速ネットワークと広帯域幅を使用する環境とサービスを使用する能力が制限されます。

私たちは、TFS (特に Web Access コンポーネント) で作業し、連携のために電子メールを使用することで、Rangers の大半に適した、効率的で信頼性のある ALM インフラストラクチャを作成することができました。

動機と取り組みを理解して対処する

IT プロフェッショナルが、自分の時間を犠牲にしてまで別の Rangers と連携して、しばしば孤立して作業しながら経験、知識、情報を Rangers ソリューションとガイダンスに集約するための原動力はなんでしょう。1 人 1 人に異なる動機やその結果としての取り組みがあり、チーム内で各リソースが効率的に利用できるようにそれらを特定および理解する必要があります。

仮想チームで作業するときは、テクノロジに情熱を燃やしていて、"目的を達成する" という意気込みがあり、やる気があって、考え方が柔軟で、非常に自分に厳しいすべてのチーム メンバーを特定することが重要であることを学びました。チームの独自性、テクノロジ、またはプロセスがないことにより、膨大な量の指示が必要な人々が (特にチーム リードの役割も果たさなくてはならないとき) 仮想チームで効果的に作業をすることができます。

Ruck プロセスと TFS ALM ソリューションを使用してエピックを定義すれば、製品バックログとタスクが (特にチーム メンバーがタスクを割り当てられるのではなくタスクを進んでやるよう求められるとき) 非常に有益であることが証明されます。さらに、進捗 (またはその欠如) を継続的に追跡できる能力によって、課題と障害を早い時点で特定することができます。残念ながらまだ克服していない課題は、継続的な通知がなくても、メンバー全員が適切なタイミングで作業項目を定期的に更新するという、人的な問題です。

図 11 のように、チームの目的、ビジョン、製品バックログ、プロジェクトの状態を定義し、それらをチームおよび関係者と共有するために、定期的に行うチーム会議を結合し、進行中の連携戦略とテクノロジを使用します。これにより、分離され、仮想的で、孤立したエコシステムで作業していても、全員からやる気と取り組みを継続的に引き出せるようになります。

図 11 連携と ALM のためのテクノロジの使用

驚くべきことに、分離の問題は、その存在およびチームの目的にもたらす潜在的な影響が明白になるときに、チームの課題となります。TFS と Ruck プロセスを使用することで、状態と課題を "全員に見え続ける" ようにすることが可能になりました。この結果、ほとんどの場合、次回の毎週の会議でそれらをレポートすることになる前に、チームが問題を特定して解決できるようになりました。

最も推奨する事柄

仮想チームの環境、各チーム メンバーの連携と効率、および製品の品質を高めることができる、多くの推奨事項、スキル、実践がありますが、ここでの推奨事項は次の 7 つです。

1. チームの独自性とビジョンを明確に定義して発展させる。
2. Ruck プロセスなどのプロセスを明確に定義する。
3. コミュニケーションのガイドラインとプロトコルを明確に定義する。
4. マイルストーンを明確に定義して、状態を共有し、成果物を賞賛する。
5. TFS や関連するテクノロジなど、チームが効果的に連携できる ALM インフラストラクチャを実装する。
6. 物事の視覚化と完全な透明性の実現を、一定のリズムで行う。
7. チームを賢明に選択し、メンバーに自発的に動いてもらったり、情熱的で "目的を達成する" 意気込みのある個人を奨励したりする。

今後の記事では、Rangers が分散型の仮想チーム環境で VM Factory と Visual Studio テスト ツールを使用して、帯域外のソリューションの一貫性を促進し全体的な質を高める方法について解説します。

Brian Blackman は、エンジニアリングと市場における独立系ソフトウェア ベンダーに影響を与えることに特化している、Microsoft Services Partner ISV チームの主任コンサルタントです。彼は MBA を取得していて、CSM、MCSD (C++)、MCTS、および Visual Studio ALM Core Ranger です。コードを記述したり、ワークショップを作成および提供したり、さまざまな研究領域や ALM 関連のすべてについてコンサルティングを行っています。

WillyPeter Schaub は、Microsoft Canada Development Center で、Visual Studio ALM Rangers のシニア プログラム マネージャーを務めています。80 年代中ごろから、ソフトウェア エンジニアリングにおける簡潔さと保守性を追求し続けています。彼のブログは blogs.msdn.com/b/willy-peter_schaub (英語) で公開されており、Twitter (twitter.com/wpschaub、英語) でフォローすることができます。

この記事のレビューに協力してくれた技術スタッフの Ben Amodio、Mike Fourie、Bill Heys、Bijan Javidi、および Patricia Wagner に心より感謝いたします。