次の方法で共有


Visual Studio Team System と Microsoft Solutions Framework

更新 : 2007 年 11 月

Microsoft Visual Studio Team System では、チーム オブ ピアーズが MSF プロセス ガイダンス チーム モデル内のロールに関する情報を適用します。チーム モデルは、ビジョン、生産、使用、保守などのプロジェクト ライフ サイクル全体を操作するためのモデルとして使用できます。

チーム モデルには、次のようなロールがあります。

  • アーキテクチャ

  • 開発

  • 製品管理

  • プログラム管理

  • リリース運用

  • テスト

  • ユーザー エクスペリエンス

Microsoft Solutions Framework の詳細については、Microsoft Web サイト を参照してください。

これらのロールでチーム エクスプローラを使用する方法の詳細については、「Team Foundation での操作方法」を参照してください。

アーキテクチャ

アーキテクトは、製品のアーキテクチャの整合性を設計および保守する作業を担当します。アーキテクトは、アプリケーションの組織的な構造と、その配置の物理的な構造の両方を定義します。この取り組みにおけるアーキテクトの目標は、複雑さを軽減し、結合と回帰の影響を弱め、コンポーネント間の連携性を高めることです。システムをいくつかの部分に分割することで、各部分を個別にビルドおよびテストできます。

この結果作成されるアーキテクチャは、システムのその後の構築方法を決定することになるため、重要です。さらに、アーキテクチャは、プロジェクトの成功のために必要な数多くの特徴を備えた基盤ともなります。アーキテクチャ フレームワークを使用すると、操作性、信頼性、保守性、パフォーマンスとセキュリティなどの要件を満たし、要件の変更が生じた場合に簡単に変更できる製品にすることができます。

アーキテクチャのワークフローは次のとおりです。

  • 分析

  • サービス品質要求の作成

  • 製品要求の作成

  • ソリューション アーキテクチャの作成

  • 環境の確立

  • プロジェクト プロセスの確立

  • 顧客要件のテスト

  • 製品要件の検証

開発

開発者は、製品の構築を担当します。リード開発者や開発マネージャなどの開発ロールの場合、コミュニケーションとプロジェクト管理の責任が加わります。開発者の主要な任務は、コードの構築です。コミュニケーションが容易であれば、開発者はその任務に集中できます。さらに、開発者はプロジェクトの初期段階で、顧客の要求に含まれていない製品要件を決定するのを支援することが期待されます。多くの場合、開発者は多くの専門分野にわたるチームの一員としてアーキテクトと協同します。

リード開発者のロールは、他の開発者のために指導し、コミュニケーションを図ることです。リード開発者は、経験とスキルを提供し、同僚の開発者を指導することでリーダーシップを示します。リード開発者は、コード レビュー、設計、単体テストのカバレッジに対して責任を負います。また、開発者のためにプロジェクトの他のメンバに対するパイプ役としての機能を果たします。生産性を支援するために、リード開発者は幅広いプロジェクト チームと外部組織間のコミュニケーションを集約し、日々のスケジュールにおけるランダムな干渉から開発者を保護します。このため、リード開発者は、コード作成タスクに専念することはほとんどできません。通常、リード開発者は、時間の約 50% をコミュニケーションに費やし、残りの時間をチームの開発者の指導と開発タスクの実際のコード記述に分配します。

開発ワークフローは次のとおりです。

  • 分析

  • ソリューション アーキテクチャの作成

  • ドキュメントの開発

  • 環境の確立

  • プロジェクト プロセスの確立

  • バグの修正

  • 開発タスクの実施

  • 製品のリリース

  • 顧客要件のテスト

  • 製品要件の検証

製品管理

プロダクト マネージャは、製品の最終消費者の代理人としての役割を果たします。プロダクト マネージャは、製品全体の要件に対して種々の責任があります。プロダクト マネージャは、製品のビジョンが要件を満たすこと、および製品の妥当性を確認するための受け入れテストに合格することを保証する必要があります。プロダクト マネージャは、製品が組織の戦略計画に沿っており、当初のビジョン ステートメントで意図した市場のセグメントに適合することを示す必要があります。また、プロダクト マネージャは、プロジェクトが予算内で実行され、ビジネス ケースが実現されることを保証します。プロダクト マネージャの作業は、MSF ガバナンス モデルにおけるトラック チェックポイントの主なソースとして使用されます。

プロジェクト管理のワークフローは次のとおりです。

  • 製品ビジョンの把握

  • 製品のリリース

プログラム管理

プログラム マネージャは、情報のフロー、およびプロジェクトの価値の実現を担当します。この価値は、通常、ビジョン ステートメントで概説されます。プログラム マネージャは、プロジェクトのライフ サイクル全体にわたって関与します。

プログラム マネージャの主なゴールは、合意したスケジュールと予算内でビジネス価値を提供することです。プログラム マネージャは、プロジェクトとイテレーション計画の作成、状態の監視と報告、リスクの識別と軽減など、計画立案とスケジュール管理を担当します。また、プログラム マネージャは、プロジェクトの作業のバックログを計画するために、ビジネス アナリストと協議する必要があります。プログラム マネージャはアーキテクト、開発者、テスト担当者、ユーザー教育担当者、ユーザー エクスペリエンス アーキテクトと協議することにより、作業の見通しを立て、チーム内のコミュニケーションを円滑にする必要があります。

プログラム管理のワークフローは次のとおりです。

  • 製品ビジョンの把握

  • 製品要求の作成

  • ドキュメントの開発

  • プロジェクト プロセスの確立

  • 懸案事項の管理

  • イテレーションの計画

  • プロジェクトの計画

  • リスクの管理

  • 顧客要件のテスト

  • 製品要件の検証

リリース運用

リリース マネージャのゴールは、製品のロールアウトを管理することです。リリース マネージャは、リリースと運用やメディア管理の間の調整を行います。ロールアウト計画を作成し、出荷用または配置用のリリース候補を認定します。

リリース運用のワークフローは次のとおりです。

  • ベースラインの構成管理

  • 製品要求の作成

  • プロジェクト プロセスの確立

  • 変更要求の管理

  • 製品のリリース

テスト

テスト担当者の主なゴールは、製品の価値に不利な影響を与える可能性のある問題を発見して伝えることです。テスト担当者は、プロジェクトのコンテキストを理解し、他のメンバがこのコンテキストに従い十分な情報に基づいて決定を行うことができるようサポートする必要があります。テスト担当者の重要なゴールは、製品をテストすることにより、重大なバグを見つけて報告することです。バグが発見された場合、その影響度を正確に報告し、バグの影響を小さくする可能性のある回避策について記述することもまた、テスト担当者の役割です。テスト担当者は、バグの説明およびバグを再現する手順について、わかりやすい方法で記述します。テスト担当者はチーム全体と共に製品の品質水準の確立に参画します。テストを行う目的は既知の機能が正確に動作することを確かめ、製品の新たな懸案事項を見つけることです。

テスト担当者のワークフローは次のようになります。

  • 分析

  • バグの終了

  • ドキュメントの作成

  • 環境の確立

  • プロジェクト プロセスの確立

  • 製品のリリース

  • 顧客要件のテスト

  • 製品要件の検証

ユーザー エクスペリエンス

ユーザー教育担当者は、通常、テクニカル ライタであり、製品の価値を強化または向上するのに役立つ顧客重視のテクニカル ライティングを担当します。ユーザー教育担当者は、製品マニュアル、オンライン ヘルプ、操作マニュアル、保守マニュアル、トレーニング マニュアル、および製品の操作性や価値を高めるために使用できるその他のドキュメントを作成する場合があります。ユーザー体験アーキテクトは、一般に、ユーザー教育担当者と密接に協力します。

ユーザー体験のワークフローは次のようになります。

  • 分析

  • ドキュメントの作成

  • プロジェクト プロセスの確立

  • 製品のリリース

参照

その他の技術情報

Team Foundation

Architecture Edition

Development Edition

Test Edition