VSTS 2010

Visual Studio Team System 2010 のアジャイル計画ツール

Ajoy Krishnamoorthy

この記事は、Visual Studio Team System (VSTS) 2010 のプレリリース バージョンに基づいています。ここに記載されているすべての情報は、変更される場合があります。

目次

長期的な計画
リリース計画およびイテレーション計画
VSTS 2010 Excel ブック
製品バックログのブック
能力計画
イテレーション バックログのブック
レポート

"アジャイルな計画" という用語は矛盾しているでしょうか。そのように考えておられないことを祈りますが、最近ロサンゼルスで開催されたフォーカス グループで出席者の 1 人が言うには、彼女の組織でアジャイルな手法からより従来的な手法を導入するようになったということです。詳しく話を聞くと、彼女のチームでは、マネージャからの口頭での要求に基づいてコードを修正し、それを直ちに実稼動環境に展開することはもはやできないようです。そこでは従来的な手続きに従わなくてはなりません。彼女にとって、これはアジャイルから遠ざかることを意味していました。

しかし、アジャイル開発に関する彼女の理解は間違っています。筆者は、彼女の組織が従来のプロセスへの変更を制定したことを喜ばしく思います。アジャイルは速度を過信するあまり盲目的に飛び回ったりやみくもに走ったりすることではありません。むしろ、計画に対する秩序あるアプローチであり、経験に基づくデータが考慮されます。

Visual Studio Team System (VSTS) 2010 では、アジャイルなチームが計画を立案するうえで役立つ新機能が導入されています。この記事では、アジャイルなチームがリリースおよびイテレーションを計画、管理するのに役立つ新しい製品バックログおよびイテレーション バックログのブックと、新しいレポートのセットについて紹介します。

長期的な計画

正確な長期的計画がないという懸念はよくあることで、これが導入に対する主な妨げとなっています。2008 年の State of Agile Development Survey (アジャイル開発の状況調査) では、高度な計画が不足していることが、回答者の組織でアジャイルな手法を導入する際の最大の懸念となっていました。多くの組織で、長期的で正確な計画が不足していることが、まったく計画性がないこととイコールに捉えられている気がします。アジャイルなチームは、ウォーターフォール スタイルの計画でのコース修正を含む、複数のレベルで計画を立案することを選択します。

Steve McConnell は、彼のソフトウェアの見積もりにおける不確実性の円錐形を明らかにしていますが、プロジェクト初期の見積もりは、上流へ行くほどエラー率が増し不正確さが 400% にも上る場合があると提唱しています。"プロジェクト初期には、ソフトウェアが持つ性質の具体的な詳細が決定されますが、具体的な要件の詳細、ソリューションの詳細、プロジェクト計画、人員、およびその他のプロジェクトの変数は未確定です。これらの要素が変化すると、プロジェクトの見積もりが変化します。"

当然ながら、これらのことによって経営管理の戦略が "プロジェクトがいつ終わるかわからないし、どのような仕上がりになるかわからない" となるわけではありません。そうではなく、チームがリリースの計画を進める方法と、リリースで完了される作業のスコープが変化することを意味しています。

図 1 製品バックログとイテレーション バックログ

リリース計画およびイテレーション計画

アジャイルなチームにとって、計画は、リリース計画およびイテレーション計画という 2 つの異なるレベルで行われます。リリース計画は上位レベルの計画作業であり、アジャイルなチームは機能またはユーザー ストーリーの大まかなセットをレビューできます。バックログ項目はランク付けされ、見積もられ、イテレーションのセットに割り当てられます。この段階では、見積もりは T シャツのサイズのような単位 (大、中、小) で行われます。この時点での目的は、バックログの各項目のコストの概略値を出すことであり、正確な見積もりを出すことではありません。また、これによって顧客は概略の規模を念頭において要件をランク付けすることができます。

スクラムでは、このユーザー ストーリーのセットは製品バックログと呼ばれるリストに保持されます (図 1 を参照)。各イテレーションで行われる作業のスコープは、チームの速度に大きく依存します。リリースを定義する内容は、顧客によって確定された信用できる要件のセットをいつ入手できるかに大きく依存します。たとえば、最初の機能セットを取得するのにイテレーションが 4 回行われるとすると、最初のリリースは 4 回目のイテレーション後にスケジュールが設定されます。

イテレーション計画はより詳細な計画作業であり、それぞれのイテレーションが開始する前に行われます。製品バックログの上位のユーザー ストーリーはレビューされ、必要に応じてより小さいユーザー ストーリーに分類されます。この時点で、チームではユーザー ストーリーをより小さいストーリーに分類し、ユーザー ストーリーを完了するのに必要なタスクを定義する準備が整います。これらのユーザー ストーリーおよび関連付けられたタスクは時間数で見積もられます。この時点で、チームはイテレーションのスコープを認識できます。

Microsoft Office Excel は、インデックス カードや付箋と共に、アジャイルなチームのツールボックスに頻繁に見られるツールです。VSTS 2010 では、アジャイルなチームが製品バックログとイテレーション バックログを管理するのに役立つ 2 つの新しい Excel ブックが導入されました。ここで、ブックを紹介する前に、VSTS 2010 に付属する新しいアジャイル プロセス テンプレートについて簡単に紹介します。

VSTS のプロセス テンプレートには、作業項目の種類、クエリ、レポート、およびテキストによるガイドが含まれています。ここで重要なエンティティは作業項目です。作業項目には、ユーザー ストーリー、タスク、バグなどを指定できます。開始するには、Team Foundation Server (TFS) でチーム プロジェクトを設定し、新しいチーム プロジェクト ウィザードで VSTS Process for Agile Software Development v1.0 テンプレートを選択します。このテンプレートには、以下のような作業項目の種類が含まれています。

• タスク
• ユーザー ストーリー
• バグ
• 問題
• テスト ケース

独自の作業項目の種類を作成するか、または特定の作業項目をカスタマイズできます。作業項目のカスタマイズの詳細については、TFS プロセス テンプレートの使用とカスタマイズについて説明している 2008 年 12 月号の Brian Randell の記事「Team System: プロセス テンプレートでチーム プロジェクトを効率化する」を参照してください。

次は、Excel ブックについて見ていきましょう。これらの作業項目が開発プロセス内でどのように遷移し、値のフローの計画と管理でどのように役立つかについて説明します。

VSTS 2010 Excel ブック

「アジリティ向上のためのツール」の中で、Kent Beck はアジャイルなチーム内の多くの遷移と、遷移を考慮するためのツールの必要性について述べています。Excel ベースの計画用のブックを TFS の作業項目の追跡と統合することで、遷移のオーバーヘッドが最小化されます。製品バックログとイテレーション バックログの同期の維持から、ユーザー ストーリーまたはタスク作業項目の状態に対する更新を自動的に取得してイテレーション バックログに取り込み、多くのレポートを生成することまで、多くの平凡な作業が除去または最適化されます。

以下は、VSTS 2010 を使用してアジャイルなチームが製品バックログとイテレーション バックログを管理するためのフローを提案しています。

• VSTS 2010 アジャイル テンプレートを使用して新しいチーム プロジェクトを作成する。
• ユーザー ストーリーを製品バックログ ワークシートに追加するか、または Visual Studio 内部から作業項目を追加することで、製品バックログを作成する。
• 製品バックログのランク付けに基づいて、イテレーションへの項目の割り当てを開始する。既定では、イテレーション 0、1、および 2 が作成されます。チーム プロジェクト設定を使用して、追加のイテレーションを作成できます。
• ユーザー ストーリー、タスク、およびその他の項目を特定のイテレーションから取得し、それらを該当するイテレーション バックログのワークシートにマップするクエリを設定する。

これらのワークシートと TFS の統合は、クエリを使用して行われます。図 2 に、製品バックログ ワークシートの構成を示します。Excel リボンで、[チーム] タブの [作業項目] グループの [リストの構成] をクリックします。これにより、[リストの構成プロパティ] ダイアログが表示されます。このダイアログで TFS クエリを選択できます。このクエリ結果は、スプレッドシートに表示されます。

図 2 Excel ワークシートのクエリ

クエリはチーム プロジェクトで作成されます。既定では、チーム プロジェクトを設定すると Work Items\Team Queries\Workbook Queries フォルダが作成されます。このフォルダの下に、製品バックログおよびイテレーション バックログのブック用の既定のクエリがあります。

ブックの動作をより深く理解するために、2008 年 10 月の VSTS 2010 および .NET Framework 4.0 CTP に付属の DinnerNow サンプル アプリケーションを見ていきましょう (Team Suite デベロッパー センターで、CTP ダウンロードの最新版を入手できます)。製品バックログおよびイテレーション バックログのブックは両方ともチーム エクスプローラーの \DinnerNow\Documents\Shared Documents フォルダにあります。

製品バックログのブック

製品バックログは、主に、顧客がアプリケーションに要求する要件のリストとして機能します。筆者は、上位レベルの要件のセットについて議論しているチームがエピック (epics) やテーマ (themes) などの用語を使っているのを聞いたことがあります。上位レベルにおいて、リストにあるこれらの要件のセットを修正し、優先順位を付け、見積もりを行うことは、この計画段階で重要な 2 つの質問に答えるために役立ちます。

1. 1. アプリケーションの要件は何か。
2. 2. コストはどのくらいかかるか。もちろん、これに対する回答の基になるのは見積もりです。筆者は、この段階での見積もりにストーリー点数、T シャツのサイズ、時間数を使っているチームを見てきました。

これらの質問に答えることで、チームはリリース (または将来のいくつかのリリース) がどのようなものになるか、およびこれらのリリースのスケジュールをいつに設定できるかについて深く把握できるようになります。通常は、次の広告キャンペーン、法的要件、季節的な活動など、予算や日程に関する制約があります。制約に基づいてリリースのスコープを管理できるため、制約はリリースのスコープ計画に役立ちます。

リリースで対象となる日付が設定されている場合、作業のスコープは、リリース期間内にどの要件をイテレーションに含めるかを決定することで管理されます。たとえば、計画が 12 月に開始してリリースが 6 月に設定されている場合、作業が完了するまで本質的に 4 ～ 5 回のイテレーションが見込まれます (1 か月のイテレーションを想定)。

対象となる日付に柔軟性がある場合は、要件の最小セットが完了する時期に応じてリリース スケジュールを調整できます。たとえば、機能要件の最小セットが 3 回のイテレーションで完了する場合、リリース 1 を 3 回のイテレーションの後に設定できます。次の機能セットが 5 ～ 6 回のイテレーションで完了する場合、リリース 2 はこれらの 5 ～ 6 回のイテレーションの後に設定できます。

図 3 に、DinnerNow プロジェクトの製品バックログのワークシートを示します。ここには、ユーザー ストーリーのバックログが示されています。これらのユーザー ストーリーのうちのいくつかは既に特定のイテレーションに割り当てられ、その中のいくつかは既にイテレーション 0 と 1 で完了しています。当然ながら、新しいプロジェクトの開始時は空のブックで開始し、このような上位レベルのユーザー ストーリーの作成を開始します。

図 3 製品バックログのワークシート

これらのスプレッドシートの各列は、作業項目の各フィールドとして TFS データ ストアに格納されます。Excel と TFS の統合によって、Excel に [チーム] リボンが追加されました (図 4 を参照)。このリボンには、バックログ項目を TFS に発行したり、TFS の更新済み作業項目でバックログの表示を更新したりするメニュー項目が含まれています。

図 4 Excel リボンの [チーム] タブ

バックログの各行は、図 5 に示すように、作業項目として TFS 内に保存されます。このような統合によって、Visual Studio を使用しているチーム メンバは Visual Studio 自体からユーザー ストーリーやその他の作業項目を更新できます。異なるツールを切り替えて使わなくても、ユーザー ストーリー、見積もり、または残り作業の状態を更新できるようになりました。

図 5 TFS 内の作業項目

能力計画

リリース計画の一環として、アジャイルなチームは多くの時間を費やしてスプレッドシートで新しいユーザー ストーリーを追加し、これらのユーザー ストーリーを見積もりますが、中でも重要なのはこれらに優先順位を付けることです。しかし、リリースの状態を監視することも同様に重要です。製品バックログのブックには、能力計画用のワークシートが含まれています。このワークシートは、ユーザー ストーリーの見積もりと作業が割り当てられたイテレーションに基づいて、イテレーション自体をすばやく管理するのに役立ちます。

能力計画はリリースを計画するうえで重要な作業です。これは、各種イテレーションで完了できる機能を把握するために役立ちます。この計算の主要なデータ ポイントは速度です。速度とは、チームが 1 つのイテレーションで完了する作業量です。前のイテレーションからのデータが取得できたら、その時点で開始するのが最善です。

図 6 前のイテレーションを使用して速度を計算する

これは一般に、"昨日の天気に基づく予測" と言われています。実際、能力計画スプレッドシートでは、利用可能な場合に TFS データ ウェアハウスから履歴データを取得できます。図 6 に示すように、履歴データの取得元イテレーションとしてイテレーション 1 を選択し、開始日、終了日、チーム メンバ数といったデータを設定できます。ここでは、816 時間という速度が取得されました。これは、チームがイテレーション 1 で 816 時間の作業を完了できたことを意味します。このデータからチームは見積もりを開始し、最初のイテレーションの速度を使用して将来のイテレーションを計画できます。

能力計画スプレッドシートでは、イテレーションの日付範囲、チーム メンバ数、イテレーションの中断 (祝日など) を指定できます。このデータがユーザー ストーリーの見積もりおよび速度と組み合わされて、イテレーションの作業負荷を示すグラフが作成されます。作業の見積もりが予想された能力を超えた場合は、ユーザー ストーリーをイテレーション間で分散して適切な量を割り当てる必要があります。

このケースでは、イテレーション 2 に計画していた作業はなく、バックログの残りのいくつかのユーザー ストーリーをイテレーション 2 に追加できます。すると、能力グラフは図 7 のようになります。これで状況が改善されます。作業見積もりは能力を超えていません。

図 7 イテレーション 2 に作業が割り当てられた能力グラフ

プロジェクトの進行中に、製品バックログのワークシートを使用して、各種ユーザー ストーリーの全体の状態を把握することもできます。ただし、バーンダウンおよび速度、残存作業、ストーリーの進行状況などのレポートでは、より多くの情報を取得できます。これらのレポートはアジャイル テンプレートに付属しており、チーム プロジェクトの下の Report フォルダにあります。レポートについては、この記事で後ほど説明します。

イテレーション バックログのブック

イテレーションは、アジャイルなチームの主要な作業です。スクラムを実践しているアジャイルなチームでは、"スプリント" という用語が使われています。一般に、イテレーションの期間はさまざまです。エクストリーム プログラミングを使用するチームは 1 ～ 2 週間のイテレーションを行います。スクラムを使用するチームでは、通常 4 週間のスプリントを行います。

イテレーション計画では、特定のイテレーションのスコープを定義します。イテレーション計画の会議では、チームは通常、特定のイテレーションに割り当てられたユーザー ストーリーの分析、詳細な要件の収集、関連付けられたタスクの追加、および各タスクを完了するための期間の見積もりを行います。この会議では、製品所有者がチームの残りのメンバと共に複数の要素に基づいてユーザー ストーリーに優先順位を付けます。それらの要素には、依存関係、コストの見積もり、詳細な要件、特定のストーリーがリリース計画の時点で考えられていたほど重要ではないことを示す証拠などがあります。

では、DinnerNow チーム プロジェクトのイテレーション バックログについて考えてみましょう。チーム プロジェクトの Shared Documents フォルダの下に Iteration 0、1、2 というフォルダがあります。これらのイテレーション フォルダごとに、イテレーション バックログがあります。イテレーション バックログの各ワークシートは、特定のイテレーションのユーザー ストーリーとタスクだけを取得する特定のクエリと接続されています。

機能、テーマ、エピックなどの他の種類の作業項目を追加した場合は、それらをクエリに追加すると、それらの追加の作業項目がリストに表示されます。DinnerNow チーム プロジェクトでは、イテレーション 2 で既に複数のタスクが子項目としてユーザー ストーリーに追加されています。しかし、一般的なイテレーション計画の会議では、チームがタスクを追加し、それらを見積もることでイテレーション 2 の適切なイテレーション計画を立案します。図 8 に、イテレーション バックログを示します。

図 8 子タスクを持つイテレーション バックログ

現在 TFS では階層的な作業項目がサポートされ、これにより親子ツリーを作成できます。この場合、以下の新しいタスクは、子タスクとしてユーザー ストーリー "Users should be able to use DinnerNow from their cell phones" (ユーザーは DinnerNow を携帯電話から使用できる必要がある) に追加されます。

• 電話に使用する UI の部分を特定する
• UI にカード スタック構造を使用する
• 最も普及している電話を特定する
• 注文時に必要なキー操作数を減らす

この時点で、チームはタスクの割り当てを開始できます。各チーム メンバが選択する作業量は、そのイテレーションでのチーム メンバの能力、分野の専門性、チーム メンバがチームに属している期間の長さなどの要素に応じて異なります。

イテレーション バックログのブックには、計画と実行以外の面に利用できる追加のシートがあります。能力計画ワークシートは、製品バックログのブックのワークシートと似ています。このワークシートを使用して、チームの能力の概要を把握できます。

負荷分散ワークシートは、イテレーションの計画時および実際のイテレーション期間中に便利です。アジャイルなチームは、特定のユーザー ストーリーに関する新しい情報が手に入り、技術的な依存関係がタスクに見出された場合や、チーム メンバが作業できなくなった場合などにコース修正を行うため、イテレーション全体を通じて計画を続行します。これらの問題が発生するとタスク割り当てを更新する必要が生じますが、負荷分散ワークシートはこのような場合に役立ちます。

もう 1 つ興味深いワークシートは、速度の追跡のために提供されたワークシートです。クリケットというスポーツがお好きな方は、現在のラン レートおよび必須のラン レートという用語をご存知でしょう。これらの 2 つの値は、ゲームでのチームの状況を示す優れた指標として使用されます。一般に、必須のラン レートが現在のラン レートより高い場合、攻撃側のチームは負けないように追い上げをかけなければなりません。一方、現在のラン レートが必須のラン レートより高い場合、攻撃側のチームは調子づいています。

クリケットに詳しい読者から何か言われる前に、ウィケット ダウンやリメイン オーバーなども状態を完全に把握するために重要であることをお伝えしておきます。このことは、アジャイルなプロジェクトにも当てはまります。速度追跡のシートによって、現在のチームの速度の概要と、イテレーションのユーザー ストーリーが完了するために必要な速度がわかります。クリケットと同様に、残存日数などの状態も、イテレーション内での自分の位置を完全に把握するために重要です。たとえば、現在の速度が必要な速度に追いつかない場合、チームはスコープを縮小する必要がある場合があります。繰り返しますが、顧客に対してこれらの問題を明確にし、チームとして必要な調整を行うことが重要です。

レポート

もちろん、クリケットの熱心なファンでなくても VSTS 2010 を使用したプロジェクト管理を開始できます。レポートを利用して、バーン ダウンおよび残存作業などのプロジェクトの進行状況を監視できます。

図 9 に、イテレーション 1 のバーン ダウン レポートを示します。バーン ダウン レポートは、実績作業時間数、残存作業時間数、および進行状況の割合を示します。グラフの残存作業時間を見てわかるとおり、チームはこのイテレーションに割り当てられたすべてのタスクを完了していません。

図 9 バーン ダウン グラフ

また、この状態は傾向の線によっても示されます。グラフからわかるとおり、実績傾向の線はイテレーション 1 のこのチームのレートで作業が時間内に終了しないことを示しています。イテレーションの中で、チームはバーン ダウンを監視して必要なコース修正を行い、リリース計画に影響が及ぶ可能性を顧客に伝えることもできます。

また、残存作業レポートも非常に有益です。図 10 を見るとわかるとおり、チームの作業実績は順調に進行しています。このイテレーションでバックログに配置された追加作業はなく、これは良い兆候です。チームの進行状況はイテレーションの終わりに向けて先が細くなり、未完了で残されたタスクが示されます。

図 10 残存作業

おわかりのとおり、VSTS 2010 のアジャイルな計画ツールおよびワークシートでは、リリース計画からイテレーション計画まで、およびテスト実行からビルド品質までのデータを取り込んで調査する Excel フロント エンドと統合データ ストアがチームに提供されます。これにより、アジャイルなプロジェクトを計画、管理する管理者と、チームの開発者およびテスト担当者の両方に便利なツールがもたらされ、共同での作業、進行状況の評価、必要に応じた変更、プロジェクト全体の管理ができるようになります。この統合によって、アジャイルなチームはデータ収集とレポート生成のための多くの単調な操作を手動で行わずに済みます。

高度な計画についてのやや趣の異なる、より数学的なアプローチについては、Dr. James McCaffrey の今月号の「テストの実行」のコラムをご覧ください。

Ajoy Krishnamoorthy は Microsoft patterns and practices チームのリード製品プランナです。その前は、Microsoft Visual Studio Team System のシニア プロダクト マネージャでした。このときは製品管理、戦略、およびマーケティングを担当していました。彼は 10 年以上にわたり、開発者、アーキテクト、技術プロジェクト管理者などのさまざまな業務のコンサルティングに従事していました。blogs.msdn.com/ajoyk で彼のブログをご覧いただけます。