チーム プロジェクトの計画
更新 : 2007 年 11 月
チーム プロジェクトを作成する前に、プロジェクトのスコープを慎重に計画し、チーム プロジェクトの変更、展開、保守に関する今後の方針を検討する必要があります。このトピックでは、新しいチーム プロジェクトを作成するか、または既存のプロジェクトを拡張するかを判断するうえで、回答する必要のある質問を示します。ここに挙げる質問は、あくまで検討の出発点として提示されているものであり、すべてのソフトウェア開発プロジェクトにとって包括的または明確な質問というわけではありません。質問は、次の 4 つのグループに分かれています。
現在のチーム プロジェクトと今後の作業に関する質問
Team Foundation Server の容量とパフォーマンスに関する質問
チーム プロジェクトを編成するための構造または階層に関する質問
優先するソフトウェア開発プロセスに関する質問
質問に対する答えが "はい" であれば、ほとんどの場合、新しいチーム プロジェクトを作成することをお勧めします。
次の図では、質問がデシジョン ツリーとして表示されているため、質問の相互関係を視覚的に捉えることができます。
.gif "チーム プロジェクトの計画")
現在のチーム プロジェクトと今後の作業に関する質問
以下の質問に答えるために、現在のチーム プロジェクトのことを思い起こし、今後の作業でも引き続き同じ方法を取るかどうかを考えてみてください。また、チーム プロジェクトに今後の作業を処理できるだけの能力があるかどうかを判断することも大切です。
次の図では、質問がデシジョン ツリーとして表示されているため、質問の相互関係を視覚的に捉えることができます。
.gif "チーム プロジェクトの計画セクション 2")
これは Team Foundation Server の新しいインストールですか
Team Foundation Server を初めてインストールした場合、Team Foundation の機能やツールのいずれかを使用するには、新しいチーム プロジェクトを作成する必要があります。既存のインストールで作業している場合は、サーバー上にチーム プロジェクトが既に存在します。この場合、そのプロジェクトが今後の作業に適しているかどうかを評価する必要があります。
新しいチーム ポータルは必要ですか
現在のチーム ポータルのコンテンツと焦点を見直します。ポータルのコンテンツと焦点が今後の作業にも関連しているかどうかを判断します。今後の作業に特に焦点を合わせた別のチーム ポータルを作成する場合は、新しいチーム プロジェクトとチーム ポータルを作成する必要があります。各チーム プロジェクトで使用するチーム ポータルは、それぞれ 1 つに限定することを強くお勧めします。
メンバごとに異なるアクセス許可を与える必要がありますか
チーム プロジェクトのメンバ全員のタスクの割り当てとセキュリティ アクセス許可を見直します。以下について判断します。
チーム プロジェクトの現在のメンバは、今後の作業で複数のロールを果たすことになるか。
同じメンバがプロジェクトのさまざまな部分で異なるアクセス許可を必要とするか。
さまざまな人々が現在のチーム メンバと同じロールを果たすことになるか。
それぞれに異なるアクセス許可を持つ人々がプロジェクトで作業することになる場合は、新しいチーム プロジェクトを作成する必要があります。
別のチェックイン ポリシーを使用しますか
現在のチーム プロジェクトの現在のチェックイン ポリシーを見直します。そのチェックイン ポリシーが今後のプロジェクトにも適しているかどうかを判断します。今後の作業で別のチェックイン ポリシーを使用する場合は、新しいチーム プロジェクトを作成し、新しいチェックイン ポリシーを定義する必要があります。Team Foundation Server では、それぞれのチーム プロジェクトで使用できるチェックイン ポリシーは 1 セットだけです。
別の設定を使用しますか
チーム プロジェクトでの作業が進むにつれて、プロジェクトの設定を変更することになる場合があります。既存のチーム プロジェクトで変更できる設定もありますが、その作業を続行するには、新しいチーム プロジェクトを作成しない限り、変更できない設定もあります。以下の質問は、現在の設定の適切さを検討するうえで役立ちます。
別のプロセス テンプレートを使用しますか
現在のチーム プロジェクトで使用しているプロセス テンプレートとプロセス ガイダンス (該当する場合) を特定します。そのテンプレートが今後の作業にも適しているかどうかを判断します。今後の作業に別のプロセス テンプレートを使用する場合は、そのテンプレートを使用する新しいチーム プロジェクトを作成する必要があります。Team Foundation Server では、それぞれのチーム プロジェクトで使用できるプロセス テンプレートは 1 つだけです。チーム プロジェクトを開始したら、そのチーム プロジェクトに応じて、使用しているプロセス テンプレートを手動でカスタマイズできます。ただし、これらのカスタマイズされた変更は、Team Foundation サーバーに格納されたプロセス テンプレートに保存しない限り、そのテンプレートに基づく新しいチーム プロジェクトには反映されません。
別の作業項目の種類を使用しますか
現在のチーム プロジェクトで使用している作業項目の種類を特定します。その作業項目の種類が今後の作業にも適しているかどうかを判断します。別の作業項目の種類を使用する場合、または同じ作業項目の種類を別の内容で使用する場合は、新しいチーム プロジェクトを作成し、新しい作業項目の種類を定義する必要があります。Team Foundation Server では、それぞれのチーム プロジェクトで使用できる作業項目の種類は 1 セットだけです。
プロセスまたはチーム プロジェクトの他の設定を試しますか
初めて Team Foundation Server を使用する場合や、チームの機能を向上させることに関心がある場合は、これまでとは異なるワークフロー、分類階層、ビルド プロセス、ポリシーなどを試してみることもできます。これらの試みを実行するには別のチーム プロジェクトを作成します。
管理にマスター .mpp ファイルまたは .xls ファイルを使用しますか
特に複数のチーム プロジェクトを管理する場合には、チームを管理する際に使用する情報やツールを見直します。Microsoft Project または Microsoft Excel を主要なツールとして使用してチーム プロジェクトを管理し、同じマスター .mpp ファイルまたは .xls ファイルでプロジェクトのすべてのアクティビティをトラッキングする場合、新しいチーム プロジェクトを作成するのではなく、プロジェクトにイテレーションを引き続き追加していく必要があります。Team Foundation Server では、Microsoft Project または Microsoft Excel を使用して、チーム プロジェクト間で共有する作業項目を表示することはできません。言い換えると、2 つ以上のチーム プロジェクトを管理し、複数のチーム プロジェクトに関連付けられた作業項目がある場合、Microsoft Project または Microsoft Excel にそれらの作業項目を表示することはできません。代わりに、Team Foundation Server のその他のレポート ツールのいずれかを使用して、共有作業項目の表示と管理を行う必要があります。
プロジェクトに 1000 万件を上回るバージョン付き作業項目が存在しますか
現在のチーム プロジェクトの作業項目の総数を数え、Team Foundation Server の容量の半分以上を使用しているかどうかを確認します。Team Foundation Server では、1 つのチーム プロジェクトで最大 2000 万件のバージョン付き作業項目をサポートしています。容量の半分以上を使用している場合、新しいチーム プロジェクトを完了するまでに、残りの容量を使い果たす可能性があります。また、複雑な作業項目は Team Foundation Server のパフォーマンスに悪影響を与える可能性があります。
プロジェクトのアクティブな作業項目をすべて手動で移動しますか
現在のチーム プロジェクトでアクティブな作業項目の数を数えます。新しいチーム プロジェクトを作成する場合、現在のチーム プロジェクトから新しいチーム プロジェクトにこれらの作業項目をコピーする必要があります。Team Foundation Server では、プロジェクト間での作業項目の一括コピーまたは一括移動をサポートしていません。チーム プロジェクト間で 1 つの作業項目をコピーおよび貼り付けするのに 30 秒かかると仮定すると、500 個の作業項目のコピー作業を続けて行った場合、250 分つまり 4 時間以上かかることになります。
もう 1 つの方法として、Microsoft Excel を使用すると、チーム プロジェクト間で作業項目を一括コピーできます。一括コピーした場合、作業項目内の現在の情報はコピーされますが、作業項目の履歴、添付ファイル、新しいチーム プロジェクトへのリンクはコピーされません。Microsoft Excel を使用した作業項目の一括コピーの詳細については、「Microsoft Excel や Microsoft Project で作業項目を操作する」を参照してください。
作業項目のコピーのコストよりも、新しいチーム プロジェクトを導入する利点の方が勝っているかどうかを判断する必要があります。
ソフトウェアの機能が大幅に変更されますか
今後の作業で新しいテクノロジやソフトウェアの新機能を導入する場合は、新しいチーム プロジェクトを作成することをお勧めします。新しいテクノロジや機能は、大きく異なるワークフロー、テスト、ビルド スクリプトなどを必要とすることがあり、現在のプロセス テンプレートやプロセス ガイダンスの大幅な変更が必要になる可能性があります。
Team Foundation Server の容量とパフォーマンスに関する質問
以下の質問に答えるために、現在のチーム プロジェクトが格納され、今後の作業が配置されることになる Team Foundation について考えてみてください。また、サーバーが今後の作業負荷を処理できるだけの十分な容量とパフォーマンスを備えているかどうかを判断することも大切です。
次の図では、質問がデシジョン ツリーとして表示されているため、質問の相互関係を視覚的に捉えることができます。
.gif "チーム プロジェクトの計画セクション 3")
サーバーにパフォーマンスの懸案事項はありますか
Team Foundation Server に、作業項目、ソース コード、ドキュメント、およびその他の成果物が蓄積されるにつれて、クエリの応答、ファイルのチェックイン、ソフトウェア プロジェクトのビルドに時間がかかるようになる場合があります。Team Foundation Server を最初に使い始めたころに比べて、これらのアクションに時間がかかるようであれば、時間の増加は Team Foundation サーバー上に多数のチーム プロジェクトがあるために、サーバーのパフォーマンスが低下していることを示している場合があります。サーバー上に存在するチーム プロジェクトの数が増えるほど、サーバーのパフォーマンスは低下します。サーバーのパフォーマンスが懸案事項になっている場合は、サーバー ハードウェアをアップグレードして、現在のチーム プロジェクトを続けるか、新しいチーム プロジェクトを別のサーバーに作成するかを検討します。
サーバーをアップグレードしましたか
クエリ、チェックイン、またはビルドのパフォーマンスが懸案事項になっている場合、Team Foundation Server の管理者に連絡し、サーバー ハードウェアのアップグレードが完了しているか、または今後の作業期間に向けてアップグレードが計画されているかを確認します。サーバー ハードウェアがアップグレードされていない場合は、アップグレードによってパフォーマンスが許容レベルまで向上する可能性があります。アップグレードはスケジュールされているが、まだ完了していない場合は、既存のチーム プロジェクトにイテレーションを追加するのではなく、新しいチーム プロジェクトを作成することをお勧めします。
ドキュメント ライブラリに 100 万件を上回るドキュメントが存在しますか
Team Foundation Server 管理者に連絡を取り、Team Foundation サーバーに保存されているドキュメントの数を確認します。Windows SharePoint Services では、サーバーのドキュメント ライブラリに最大 200 万件のドキュメントを保存できます。ドキュメントの数が最大数に近づくにつれて、サーバーのパフォーマンスが低下します。また、最終的には、チームがドキュメントの格納場所を使い果たしてしまうことになります。サーバーの容量の半分以上を使用している場合は、新しい Team Foundation サーバーを作成し、その新しいサーバー上に新しいチーム プロジェクトを作成することをお勧めします。詳細については、「Capacity Planning for Windows SharePoint Services」(https://office.microsoft.com/en-us/assistance/HA011607741033.aspx) を参照してください。
.gif "メモ") メモ : |
|---|
プロジェクトの容量について計画するときには、後になってサーバー間でチーム プロジェクトを移動できないことを考慮に入れます。そのサーバー上でチーム プロジェクトのバックアップと復元を行うことはできますが、Team Foundation Server サーバー間でのチーム プロジェクトの移動はサポートされていません。 |
Team Foundation Server に 200 個を上回るチーム プロジェクトが存在しますか
Team Foundation Server 管理者に連絡を取り、Team Foundation サーバーに存在するチーム プロジェクトの数を確認します。Team Foundation Server では、プロジェクトの作成に MSF for Agile Software Development プロセス テンプレートを使用した場合、最大 500 個のチーム プロジェクトをサポートできます。プロジェクトの作成に MSF for CMMI Process Improvement プロセス テンプレートを使用した場合は、Team Foundation Server でサポートできるチーム プロジェクト数は最大 250 個です。チーム プロジェクトの数が最大数に近づくにつれて、サーバーのパフォーマンスが低下します。また、最終的には、チームがチーム プロジェクトの格納場所を使い果たしてしまうことになります。サーバーの容量の半分以上を使用している場合は、新しい Team Foundation サーバーをインストールし、その新しいサーバー上に新しいチーム プロジェクトを作成することを検討してください。詳細については、「Team Foundation Server の計画」を参照してください。
Team Foundation Server に 1000 人以上のユーザーが存在しますか
Team Foundation Server の管理者に連絡し、Team Foundation サーバー上の一意のユーザーの数を確認します。Team Foundation Server では、サーバーのハードウェアにもよりますが、シングルサーバーで最大 2000 人のユーザーをサポートしています。ユーザー数が最大数に近づくにつれて、サーバーのパフォーマンスが低下します。また、最終的には、チームが一意のユーザーを追加する場所を使い果たしてしまうことになります。サーバーの容量の半分以上を使用している場合は、新しい Team Foundation Server サーバーを作成し、その新しいサーバー上に新しいチーム プロジェクトを作成することをお勧めします。詳細については、「Team System のサーバー要件」を参照してください。
後日の監査や再確認のためにチーム プロジェクトのある期間の成果物を残す必要がありますか
チーム プロジェクト成果物 (ソース コード、作業項目、ドキュメント、レポートなど) の履歴レコードを定期的に作成し、意図的な変更や不注意による変更からそのレコードを保護する場合、主要なイテレーション、マイルストーン、またはリリースの後に、新しいチーム プロジェクトを作成する方法を使用できます。このレコードを保護するには、新しいチーム プロジェクトを作成し、既存のソース ツリーを分岐し、その他のオブジェクトを新しいチーム プロジェクトにコピーした後で、元のプロジェクトを変更するために必要なすべてのアクセス許可を削除します。
計画プロセスのこの時点で、新しいチーム プロジェクトを作成するか、既存のチーム プロジェクトを今後の作業で引き続き使用するかを決定する必要があります。新しいチーム プロジェクトを作成する場合は、この後の一連の質問に進む前に、以下についても決定する必要があります。
ソフトウェア開発プロジェクトの作成と名前付けの長期にわたる計画 (5 年など)
どのような種類をチーム プロジェクトに含めるか、除外するかというような、新しいチーム プロジェクトの概念上の境界
この 2 つの決定事項は、Team Foundation 外部の要素に基づいており、組織固有のものである可能性が高いため、このトピックではこれ以上は触れません。
チーム プロジェクトを編成するための構造または階層に関する質問
以下の質問に答えるために、現在のチーム プロジェクトが編成されている方法を思い起こし、今後の作業も同じ方法で編成することが最良かどうかを考えてみてください。また、今後の作業の編成が、ソース コードの編成や組織の他の部門にどのように対応するかを確認することも大切です。
次の図では、質問がデシジョン ツリーとして表示されているため、質問の相互関係を視覚的に捉えることができます。
.gif "チーム プロジェクトの計画セクション 4")
その構造は外部のグループから強いられていますか
ソフトウェアを要求するビジネス単位、作業の資金源、重大な組織イベント、またはソフトウェア開発のライフ サイクル以外のその他の要素に基づく、ソフトウェア プロジェクトの標準構造が組織に既に存在する場合があります。必要とする構造に合わせて、チーム プロジェクトの区分とイテレーションの階層を設定します。
チームは製品を作りますか
今後の作業の主要な焦点が、明確な独自性を備えたスタンドアロン製品を作ることである場合、ソース コード、イテレーション、および区分を製品の機能別に編成できます。各新製品は、別個のチーム プロジェクトにする必要があります。
新しいバージョンを作りますか
今後の作業の主要な焦点が、既存の製品の新しいバージョンを作ることである場合、ソース コード、イテレーション、および区分をソフトウェアのバージョン別に編成できます。各新バージョンは、別個のチーム プロジェクトにする必要があります。
明確な開始日と終了日がありますか
今後の作業の主要な焦点が明確な開始日と終了日である場合、ソフトウェアのバージョン別に編成できます。開始日と終了日の各主要セットは、別個のチーム プロジェクトにする必要があります。
項目の蓄積を懸念していますか
ソフトウェアの作業が進むにつれて、チーム プロジェクトで、作業項目、ドキュメント、レポート、ビルド スクリプト、他のチーム プロジェクト項目、および作業生産物が蓄積していくと考えられます。これらの項目の監視と管理には、ストレージ コストと人件費の両方がかかります。チーム プロジェクト項目の蓄積を懸念しており、これらの項目をできるだけ早急にアーカイブまたは削除する必要がある場合は、ソフトウェアのバージョン別に編成できます。各主要バージョンは、別個のチーム プロジェクトにする必要があります。
ソース コードをチーム別に格納しますか
製品、バージョン、またはビジネス単位別に個々のソース コード プロジェクトを持つのではなく、チーム プロジェクト全体で 1 つのソース コード プロジェクトを持つ方が望ましい場合は、ソフトウェア開発チーム全体の編成に合わせて区分とイテレーションの階層を編成できます。
ソフトウェアの保守だけを行いますか
今後の作業の焦点が、組織外部への配布を対象としているのではなく、ソフトウェアまたは組織のインフラストラクチャを保守することである場合、ソフトウェア開発チーム全体の編成に合わせて区分とイテレーションを編成できます。
優先するソフトウェア開発プロセスに関する質問
以下の質問に答えるために、今後の作業を行う際に使用するソフトウェア開発プロセスについて考えてみてください。また、優先されるプロセスがあるかどうか、またはプロセスの改善に優先度があるかどうかを確認することも大切です。
次の図では、質問がデシジョン ツリーとして表示されているため、質問の相互関係を視覚的に捉えることができます。
.gif "チーム プロジェクトの計画セクション 5")
法律や契約によって CMMI を使用することが求められていますか
新しいチーム プロジェクトを作成する際に使用するプロセス テンプレートについて、選択の余地がない状況もあります。たとえば、連邦の規制により、CMMI プロセスを使用してソフトウェアを開発することが必要となる場合があります。したがって、チーム プロジェクトの作成時には、MSF for CMMI Process Improvement テンプレートを選択する必要があります。また、資金調達組織から CMMI の使用を求められることもあります。
多数のロールが必要ですか
今後の作業でチーム メンバのさまざまなロールが必要な場合、MSF for CMMI Process Improvement テンプレートが適切かどうかを判断する必要があります。たとえば、MSF for Agile Software Development テンプレートを使用してチーム プロジェクトを完了した時点で、このテンプレートに標準で組み込まれている以下のロール以外にも、チームにとって必要なロールがあったことがわかった場合などです。
ビジネス アナリスト
プロジェクト マネージャ
アーキテクト
開発者
テスト担当者
リリース マネージャ
MSF for CMMI Process Improvement テンプレートには、次のようなさらに複雑なロール セットが標準で組み込まれています。
プロジェクト マネージャ
スポンサー
アーキテクト
領域の専門家
開発者
開発マネージャ
ビルド エンジニア
テスト担当者
テスト マネージャ
監査担当者
サービス品質の専門家
リリース マネージャ
IPM 担当役員
ユーザー体験アーキテクト
ユーザー教育担当者
プロダクト マネージャ
ビジネス アナリスト
プロセスの改善を推奨しているのは外部のグループですか
組織がプロセスの改善に懸念を抱いている場合、現在のワークフローやビジネス プロセスの見直しを図り、改善点を提案するために、組織内部または外部の特別なグループに依存している場合があります。特別なグループを利用する場合は、新しいチーム プロジェクトの作成時に、MSF for CMMI Process Improvement テンプレートを使用します。
現在、プロセスを文書化していますか
組織がプロセスに懸念を抱いている場合、現在のワークフローやビジネス プロセスの見直しを図り、改善点を提案するために、組織内部または外部の特別なグループに依存している場合があります。特別なグループを利用する場合は、新しいチーム プロジェクトの作成時に、MSF for CMMI Process Improvement テンプレートを使用します。
適切なサードパーティ製テンプレートがありますか
サードパーティの販売元が提供するプロセス テンプレートを組織で既に採用している場合があります。テンプレートを既に選択している場合は、新しいチーム プロジェクトの作成時に、そのサードパーティ製テンプレートを使用します。
現在のプロセスに満足していますか
現在のワークフロー プロセスに満足しているのであれば、正式なテンプレートを変更したり、使用したりする必要はないと考えられます。プロセスが機能している場合は、現状を維持します。
プロジェクトのライフ サイクルは短いですか
チーム プロジェクトのライフ サイクルが比較的短い場合 (90 日より短い場合)、CMMI のような正式なプロセスによってオーバーヘッドが追加されることは望ましくないと考えられます。この場合、MSF for Agile Software Development テンプレートを使用します。
| メモ : |
|---|
プロジェクトの容量について計画するときには、後になってサーバー間でチーム プロジェクトを移動できないことを考慮に入れます。そのサーバー上でチーム プロジェクトのバックアップと復元を行うことはできますが、Team Foundation Server サーバー間でのチーム プロジェクトの移動はサポートされていません。 |
参照
処理手順
チュートリアル : 既存のチーム プロジェクトからの新しいチーム プロジェクトの作成