Team Foundation Serverのスクラムプロセステンプレート
多くの開発チームの中で、スクラムアプローチの人気が高まっています。 実際、20ページのテキストからなる簡潔な方法論は理解しやすく、ある程度の練習の後、使用され始めています。 そのため、マイクロソフトは、この方法論をTeam Foundation Serverで使用できるオプションのスクラムテンプレートをリリースしました。
作業で既にTFSを使用している人は、チームの作業を整理するために、MSF AgileとMSF CMMIの2つのプロセステンプレートを使用できることを知っています。 技術的には、これらのテンプレートは、プロセスの作業項目、ドキュメント、レポート、セキュリティ設定などを記述するファイルのセットです。 さらに、TFSを使用すると、これらのテンプレートをカスタマイズし、このコマンドに固有のプロパティでテンプレートを補完できます 。 このような変更は、 Visual Studio Power Toolsを使用して簡単に実行できます 。 市場には、コミュニティおよび営利企業によって開発されたいくつかの追加のプロセステンプレートがあります。
このテンプレートは、Microsoftの専門家によって開発され、Scrum.Orgの専門家が直接参加しました。 標準のMSF AgileおよびMSF CMMIと同様に、主にチームの作業を整理するために設計された一連の作業項目で構成されます。
Productuct Backlog Item（PBI）：ソフトウェア製品全体の要件を追跡します。
バグ：開発中にバグが見つかりました。 製品バックログ項目とバグは、コストの見積もりと計画のコンテキストでの要件リストのほぼ同等の要素であることに注意してください。 したがって、ほとんど同じフィールドのセット。 小さな発言。 MSFアジャイルおよびMSF CMMIテンプレートとは異なり、TFSは誤ったビルドに基づくバグを作成しません。
タスク：タスク。 この項目では、製品バックログ項目に必要な詳細レベルを入力できます。 当然、タスク自体はサブタスクに分割できます。
スプリント：このワークアイテムは、スプリントの日付、目標、および回顧をキャプチャします。 スプリントを個別のワークアイテムに分離すると、スクラムテンプレートがMSFアジャイルおよびMSF CMMIテンプレートと区別されます。 それらでは、スプリントは反復階層のメカニズムによってのみ示されますが、残念ながらそれを使用してスプリントの開始日と終了日を示すことはできません。
障害：問題、リスク、およびチームの作業に影響を与える可能性があるが、開発された製品の特性に直接関係しないすべて。
テストケース： PBIのテストの説明。 通常、テストは特定のPBIに直接結び付けられます。 この作業項目（他の共有ステップと同様）はスクラムで直接定義されていませんが、TFSインフラストラクチャが正しく機能するために必要です。
共有ステップ：複数のテストケース間でテストステップを共有します。
実際、プロセス自体はスクラムマニュアルに詳しく説明されており、以下は手順の非常に簡単な例です。
1）プロジェクトチームが編成され、最低限必要なドキュメントが準備されます（ビジョン、スコープ）
2）プライマリPBIリストが生成され、可能な場合は優先度が割り当てられます。 原則として、分析のこの段階は長くはありません。
3）最初のPBIリストに基づいて、最初の評価（エフォートフィールド）はPlanning Pokerを使用して実行されます。 数時間で計画を立てることができますが、これらは抽象的な単位であることを忘れないでください。
a。 明確でないPBI（無限レベルまたは非常に高いコストの評価）は、追加の分析に送られます。
4）最初のスプリントは、製品バックログの完全なセットからPBIの優先順位と重要性に基づいて形成され、どのように実装するかはすでに明らかです。
5）Sprintに入ったPBIは、必要に応じて開発者によってタスクレベル（Task）に詳細化されます。 ここで時間を入力できます。 タスクには「残りの作業」フィールドがあります。
a。 2つまたは3つのスプリントの後、コストの一意性を既に期待し、計画期間を明確にすることができます。
6）PBIは、指定されたテストケースに基づいてコミット済み状態でチェックされます。
7）必然的に発生するエラーはバグを使用して修正する必要がありますが、これも製品バックログに含まれます。
8）完了ステータスで完了したPBI
9）次のスプリントが計画され、プロセスはp.p. 5。
製品バックログおよびスプリントのPBI /バグ/タスクリストでの操作は、スプリント1のテンプレートで既に定義されている標準クエリを使用して実行されます。
したがって、最初のスプリントの終了後、「スプリントバックログ」リクエストを現在のスプリント値に変更することを忘れないでください。
スクラム作業項目の状態
MSFアジャイルおよびMSF CMMIテンプレートは、すでに確立されているTFS ARCアプローチ（アクティブ->解決済み->クローズ）を使用しますが、これはスクラム用語に完全には対応していません。
MSDN WebサイトとTeam Foundation Server Web Acces and Process Editorの両方で、すべてのワークアイテムのワークフローをより詳しく理解できることを思い出してください。
たとえば、スクラムプロセスのバグワークアイテム（最も複雑な）のWokflowエディターからのスクリーンショットを示します。
スクラムレポート
当然、スクラム作業項目で定義されているほとんどすべてのフィールドはTeam Foundation Server分析システムに分類され、いくつかの重要なレポートを作成できます。これにより、プロジェクトの状況を理解することができます。
スプリント/リリースバーンダウン-プロジェクトとスプリントの残りの作業量を評価する機会を提供する2つのレポート。
バーンダウンのリリース：スプリントからスプリントまで、エフォート単位で推定されるタスクの合計量は減少するはずです。 このグラフから間接的に、チームのパフォーマンスを評価することもできます。
スプリントバーンダウン：チームは毎日、スプリントの一環として多くのPBIを閉鎖します。
速度レポート：各スプリントに費やされた努力。 このレポートはリリースバーンダウンと共鳴します。 グラフには、スプリントでのチームのパフォーマンスの平均値（35）も表示されます。 理想的には（そして不変のチームにとって）、スプリントが多ければ多いほど、この数値はより正確になり、プロジェクトの終了日をより正確に予測できるようになります。
一定期間にわたるビルド成功、ビルドサマリレポート：プラットフォームごとのプロジェクトアセンブリのステータスと合格したテストを表示します。 進捗状況、変更の程度を理解し、製品の品質を評価できます。
テストレポートは、製品品質の一般的な状態を評価し、テスト自体に関連する組織の問題を解決するように設計されています。 これらのレポートに表示される情報に基づいて、正しい結果で合格するテストの数、間違った結果でのテストの数、まだ起動されていないテストの数、ブロックされているテストの数を把握できます。
テストケース準備レポートを使用すると、テストの処理を整理して、実行可能なテストの数と、詳細化の段階にあるテストの数を表示できます。 理想的には、このレポートは次のような図を描く必要があります。
スクラムプロセステンプレートは、Team Foundation Serverの最も単純なプロセステンプレートの1つであり、チームワークを編成する際の基本的な問題を解決できます。 さらに、スクラムの簡潔さにより、このアプローチを新規または既存のチームにすばやく導入し、かなり短期間で目に見える結果を得ることができます。 私は、より良いソフトウェアの開発と正確な計画にあると信じています。
プロセステンプレート
作業で既にTFSを使用している人は、チームの作業を整理するために、MSF AgileとMSF CMMIの2つのプロセステンプレートを使用できることを知っています。 技術的には、これらのテンプレートは、プロセスの作業項目、ドキュメント、レポート、セキュリティ設定などを記述するファイルのセットです。 さらに、TFSを使用すると、これらのテンプレートをカスタマイズし、このコマンドに固有のプロパティでテンプレートを補完できます 。 このような変更は、 Visual Studio Power Toolsを使用して簡単に実行できます 。 市場には、コミュニティおよび営利企業によって開発されたいくつかの追加のプロセステンプレートがあります。
スクラムプロセステンプレート
このテンプレートは、Microsoftの専門家によって開発され、Scrum.Orgの専門家が直接参加しました。 標準のMSF AgileおよびMSF CMMIと同様に、主にチームの作業を整理するために設計された一連の作業項目で構成されます。
Productuct Backlog Item（PBI）：ソフトウェア製品全体の要件を追跡します。
バグ：開発中にバグが見つかりました。 製品バックログ項目とバグは、コストの見積もりと計画のコンテキストでの要件リストのほぼ同等の要素であることに注意してください。 したがって、ほとんど同じフィールドのセット。 小さな発言。 MSFアジャイルおよびMSF CMMIテンプレートとは異なり、TFSは誤ったビルドに基づくバグを作成しません。
タスク：タスク。 この項目では、製品バックログ項目に必要な詳細レベルを入力できます。 当然、タスク自体はサブタスクに分割できます。
スプリント：このワークアイテムは、スプリントの日付、目標、および回顧をキャプチャします。 スプリントを個別のワークアイテムに分離すると、スクラムテンプレートがMSFアジャイルおよびMSF CMMIテンプレートと区別されます。 それらでは、スプリントは反復階層のメカニズムによってのみ示されますが、残念ながらそれを使用してスプリントの開始日と終了日を示すことはできません。
障害：問題、リスク、およびチームの作業に影響を与える可能性があるが、開発された製品の特性に直接関係しないすべて。
テストケース： PBIのテストの説明。 通常、テストは特定のPBIに直接結び付けられます。 この作業項目（他の共有ステップと同様）はスクラムで直接定義されていませんが、TFSインフラストラクチャが正しく機能するために必要です。
共有ステップ：複数のテストケース間でテストステップを共有します。
仕事の組織
実際、プロセス自体はスクラムマニュアルに詳しく説明されており、以下は手順の非常に簡単な例です。
1）プロジェクトチームが編成され、最低限必要なドキュメントが準備されます（ビジョン、スコープ）
2）プライマリPBIリストが生成され、可能な場合は優先度が割り当てられます。 原則として、分析のこの段階は長くはありません。
3）最初のPBIリストに基づいて、最初の評価（エフォートフィールド）はPlanning Pokerを使用して実行されます。 数時間で計画を立てることができますが、これらは抽象的な単位であることを忘れないでください。
a。 明確でないPBI（無限レベルまたは非常に高いコストの評価）は、追加の分析に送られます。
4）最初のスプリントは、製品バックログの完全なセットからPBIの優先順位と重要性に基づいて形成され、どのように実装するかはすでに明らかです。
5）Sprintに入ったPBIは、必要に応じて開発者によってタスクレベル（Task）に詳細化されます。 ここで時間を入力できます。 タスクには「残りの作業」フィールドがあります。
a。 2つまたは3つのスプリントの後、コストの一意性を既に期待し、計画期間を明確にすることができます。
6）PBIは、指定されたテストケースに基づいてコミット済み状態でチェックされます。
7）必然的に発生するエラーはバグを使用して修正する必要がありますが、これも製品バックログに含まれます。
8）完了ステータスで完了したPBI
9）次のスプリントが計画され、プロセスはp.p. 5。
製品バックログおよびスプリントのPBI /バグ/タスクリストでの操作は、スプリント1のテンプレートで既に定義されている標準クエリを使用して実行されます。
したがって、最初のスプリントの終了後、「スプリントバックログ」リクエストを現在のスプリント値に変更することを忘れないでください。
スクラム作業項目の状態
MSFアジャイルおよびMSF CMMIテンプレートは、すでに確立されているTFS ARCアプローチ（アクティブ->解決済み->クローズ）を使用しますが、これはスクラム用語に完全には対応していません。
- このテンプレートは他の状態名を使用します：
- PBI、バグ：新規->承認済み->コミット済み->完了
- タスク：タスク->進行中->完了
- 障害：オープン->クローズ
MSDN WebサイトとTeam Foundation Server Web Acces and Process Editorの両方で、すべてのワークアイテムのワークフローをより詳しく理解できることを思い出してください。
たとえば、スクラムプロセスのバグワークアイテム（最も複雑な）のWokflowエディターからのスクリーンショットを示します。
スクラムレポート
当然、スクラム作業項目で定義されているほとんどすべてのフィールドはTeam Foundation Server分析システムに分類され、いくつかの重要なレポートを作成できます。これにより、プロジェクトの状況を理解することができます。
スプリント/リリースバーンダウン-プロジェクトとスプリントの残りの作業量を評価する機会を提供する2つのレポート。
バーンダウンのリリース：スプリントからスプリントまで、エフォート単位で推定されるタスクの合計量は減少するはずです。 このグラフから間接的に、チームのパフォーマンスを評価することもできます。
スプリントバーンダウン：チームは毎日、スプリントの一環として多くのPBIを閉鎖します。
速度レポート：各スプリントに費やされた努力。 このレポートはリリースバーンダウンと共鳴します。 グラフには、スプリントでのチームのパフォーマンスの平均値（35）も表示されます。 理想的には（そして不変のチームにとって）、スプリントが多ければ多いほど、この数値はより正確になり、プロジェクトの終了日をより正確に予測できるようになります。
一定期間にわたるビルド成功、ビルドサマリレポート：プラットフォームごとのプロジェクトアセンブリのステータスと合格したテストを表示します。 進捗状況、変更の程度を理解し、製品の品質を評価できます。
テストレポートは、製品品質の一般的な状態を評価し、テスト自体に関連する組織の問題を解決するように設計されています。 これらのレポートに表示される情報に基づいて、正しい結果で合格するテストの数、間違った結果でのテストの数、まだ起動されていないテストの数、ブロックされているテストの数を把握できます。
テストケース準備レポートを使用すると、テストの処理を整理して、実行可能なテストの数と、詳細化の段階にあるテストの数を表示できます。 理想的には、このレポートは次のような図を描く必要があります。
おわりに
スクラムプロセステンプレートは、Team Foundation Serverの最も単純なプロセステンプレートの1つであり、チームワークを編成する際の基本的な問題を解決できます。 さらに、スクラムの簡潔さにより、このアプローチを新規または既存のチームにすばやく導入し、かなり短期間で目に見える結果を得ることができます。 私は、より良いソフトウェアの開発と正確な計画にあると信じています。
All Articles