TFSクロスプロジェクトレポート

StackOverflow https://stackoverflow.com/questions/5827015

  •  27-10-2019
  •  | 
  •  

質問

私たちは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）すべてのチームを同じプロジェクトに移動します

  • Pro：レポートは変更されていません
  • プロ：クロスチームの認識
  • Con：乱雑
  • Con：おそらくセキュリティ

2）すべてのレポートをクロスチームに変更します

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

3）クロスチームレポートを含む管理のためだけにTFSプロジェクトをセットアップする

  • Pro：1つのTFSプロジェクトを変更するだけです
  • Pro：現在のチーム中心のレポートを維持します
  • Pro：チームプロジェクトでの管理作業項目を破るリスクの低下。
  • CON：すべてのチームは、同じプロセステンプレート（私にとっては問題ではない）を使用する必要があります。
役に立ちましたか？

解決

上記で定義したようにプロジェクトを設定しました。また、＃2と＃3の両方のTFSレポートを構成しました。レポートがうまくいくようにチームを強制するという考えは、オプション＃1が私にとって深刻すぎるようになります。 ＃3は魅力的ですが、ナンバー1と同様の方法で、個々のチームが同じ作業アイテムタイプとプロセステンプレートを共有するように制限します。常に私は2つの状態になります。特に、チームが独立してプロセスを進化させる場合。レポートのカスタマイズに投資することで、「レポートがあまり役に立たなくなる」という問題を軽減することができました（私が知っているわずかなこと）。

他のヒント

これは、SharePointサービスでExcelサービスを使用するための優れた候補者になります。カスタムSQLレポートよりもはるかに迅速にまとめることができます。倉庫にヒットし、クロスチームレポートを非常に迅速かつ簡単に作成できます。

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

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top