TFS Cross-projet de rapport

Question

Nous migrons vers TFS et avons décidé sur la base des commentaires en ligne à la structure TFS comme un seul projet par équipe, chaque « projet réel » étant une zone (et chaque version d'un Iteration).

Cela signifie que notre structure de TFS est un peu comme:

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

Cependant, du point de vue de la gestion, il est fastidieux de passer en revue les rapports de chaque équipe individuellement.

Je me demande pour ceux qui ont une expérience en utilisant cette structure, laquelle de ces options (ou autre option) avez-vous utilisé avec succès?

1) Déplacer toutes les équipes au même projet

• Pro: Aucun changement de rapport
• Pro: sensibilisation aux équipes
• Con: L'image de fond
• Con: Peut-être la sécurité

2) Changer tous les rapports à contre-équipe

• Pro: Les équipes peuvent encore avoir propres projets
• Con: changer et synchroniser tous les rapports sur tous les projets
• Con: Les rapports deviennent moins utiles aux équipes individuelles (peut toujours personnaliser des copies)
• Con: Les équipes doivent partager le même modèle de processus (pas un problème pour moi)

3) Installation d'un projet TFS juste pour la gestion contenant des rapports inter-équipe

• Pro: seulement à changer un projet TFS
• Pro: Maintenir les rapports actuels de l'équipe axée sur
• Pro:. Réduction du risque de gestion rupture des éléments de travail dans les projets d'équipe
• Con. Toutes les équipes doivent utiliser le même modèle de processus (pas un problème pour moi)

Answer 1

J'ai mis en place des projets que vous avez défini ci-dessus. Et j'ai configuré TFS rapports pour les # 2 et # 3. La pensée de forcer les équipes à re-org pour que les rapports de travail sur l'option 1 fait trop sévère pour moi. # 3 est attrayant, mais d'une manière similaire au numéro 1, des limites individuelles des équipes de partager les mêmes types d'éléments de travail et modèles de processus. Invariablement je finis dans l'état 2. En particulier, si les équipes à faire évoluer leurs processus de façon indépendante. Je suis en mesure d'atténuer le problème « des rapports deviennent moins utiles » en investissant dans des rapports personnalisation (je sais non trivial).

Answer 2

Ce serait un bon candidat pour l'utilisation des services Excel dans SharePoint Services. Vous pouvez les mettre ensemble beaucoup plus rapidement que des rapports personnalisés SQL. Vous pouvez frapper l'entrepôt et créer des rapports d'équipe interfonctionnelle très rapidement et facilement.

A ce moment-là, vous devriez vous sentir libre d'organiser vos projets d'équipe et de les adapter à l'avenir. En fait, vous trouverez peut-être que vous voulez un PTC par équipe plutôt que simplement un TPC.