4

私たちは TFS に移行しており、オンライン コメントに基づいて、TFS をチームごとに 1 つのプロジェクトとして構成することを決定しました。各「実際のプロジェクト」はエリアであり、それぞれがイテレーションをリリースします。

これは、TFS 構造が次のようなものであることを意味します。

Apps Team
  - WinForms Project
  - WPF Project
  - Embedded Project
  - WPF Project 2

Web Team
  - Admin Site
  - Client Site
  - Client Site 2

DB Team
  - General Scripts
  - DB 1
  - DB 2

ただし、管理の観点からは、各チームのレポートを個別に確認するのは面倒です。

この構造を使用した経験のある方は、これらのオプション (または他のオプション) のうちどれをうまく使用できましたか?

1) すべてのチームを同じプロジェクトに移動する

  • 長所: レポートの変更なし
  • 長所: チーム間の認識
  • 短所：散らかった
  • 短所：おそらくセキュリティ

2) すべてのレポートをクロスチームに変更する

  • 長所: チームは引き続き独自のプロジェクトを持つことができます
  • 短所: すべてのプロジェクトですべてのレポートを変更して同期する必要がある
  • 短所: レポートは個々のチームにとってあまり役に立たなくなります (コピーをカスタマイズできます)
  • 短所: チームは同じプロセス テンプレートを共有する必要があります (私にとっては問題ではありません)。

3) クロスチーム レポートを含む管理専用の TFS プロジェクトをセットアップする

  • 長所: TFS プロジェクトを 1 つ変更するだけで済みます
  • 長所: チームに焦点を当てた最新のレポートを維持する
  • メリット: チーム プロジェクトで管理者が作業項目を壊すリスクを軽減します。
  • 短所: すべてのチームが同じプロセス テンプレートを使用する必要があります (私にとっては問題ではありません)。
4

2 に答える 2

2

これは、SharePointServicesでExcelServicesを使用するのに適した候補です。カスタムSQLレポートよりもはるかに迅速にそれらをまとめることができます。倉庫に行き、チーム間のレポートを非常に迅速かつ簡単に作成できます。

その時点で、チームプロジェクトを自由に整理し、今後調整する必要があります。実際、1つのTPCではなく、チームごとにTPCが必要な場合があります。

于 2011-04-30T03:09:41.623 に答える
2

あなたが上で定義したように、私はプロジェクトを設定しました。また、#2 と #3 の両方に対して TFS レポートを構成しました。レポートが機能するようにチームを再編成することを強制することを考えると、オプション 1 は私には厳しすぎます。3 番目は魅力的ですが、1 番目と同様に、個々のチームが同じ作業項目タイプとプロセス テンプレートを共有するように制限します。私は常に 2 状態になります。特に、チームが独自にプロセスを進化させる場合。レポートのカスタマイズに投資することで、「レポートの有用性が低下する」という問題を軽減することができました (自明ではありません)。

于 2011-04-29T02:17:27.933 に答える