Projets d'équipe Team Foundation

Article
08/21/2008

Mise à jour : novembre 2007

Dans Team Foundation, un projet d'équipe est une collection d'éléments de travail, de code, de tests, de produits de travail, de métriques, etc. utilisée par une équipe définie pour assurer le suivi d'un ensemble commun de travaux connexes. Le concept logique d'un projet d'équipe vous aide à déterminer les éléments à inclure ou exclure du développement d'une application logicielle. Puis, le concept du projet d'équipe est implémenté par le biais des outils physiques, des regroupements, des flux de travail, etc. de Team Explorer et Team Foundation Server. La limite conceptuelle que vous tracez autour de votre projet d'équipe a des implications importantes sur la manière dont vous structurez votre projet d'équipe et sur le moment où vous réalisez la transition d'un projet d'équipe à un autre.

Définition logique d'un projet d'équipe

Logiquement (ou conceptuellement), un projet d'équipe est une infrastructure unique qui comprend tous les outils et éléments distincts utilisés dans le cycle de vie du développement d'une application logicielle. Chaque application logicielle, ou « projet d'équipe », en cours de développement est virtuellement regroupée dans son propre espace de noms, conçu exclusivement pour le projet d'équipe. Un projet d'équipe est donc un simple conteneur qui isole tous les outils et artefacts associés à une application logicielle particulière en développement, de sorte qu'aucun autre projet d'équipe n'a accès à ces outils ou artefacts (par exemple, du code source, des éléments de travail et des documents).

Le projet d'équipe est le concept central qui assure la cohésion des efforts de l'équipe pour la création d'une technologie ou d'un produit logiciels spécifiques. Le projet d'équipe est la collection virtuelle d'artefacts concernant une application logicielle sur laquelle une équipe travaille. Pour les membres de l'équipe, le concept de projet d'équipe élimine le problème de l'accès à un grand nombre d'artefacts qui ne concernent pas le projet d'équipe ; cet excès d'artefacts crée de la confusion et retarde le processus de développement du logiciel. Un projet d'équipe est au moins composé d'un jeu d'outils et d'artefacts. Il peut également inclure des stratégies de contrôle de code source, un site de génération de rapport de projet d'équipe et un portail de projet d'équipe. Le projet d'équipe Team Foundation autorise le modèle de processus, pendant la création d'un projet d'équipe, à sélectionner les outils pertinents à ajouter au conteneur du projet d'équipe.

Le concept de projet d'équipe améliore la création de rapports pour l'ensemble des outils utilisés par l'équipe. Auparavant, il était difficile de créer des rapports sur différents outils car les données recueillies n'avaient pas de rapport entre elles. Par exemple, si un développeur de logiciels souhaitait obtenir un rapport de défaillance concernant plusieurs outils, il devait faire la distinction entre les défaillances relatives à différents projets, car tous étaient stockés dans un emplacement commun. Un projet d'équipe est créé dans un espace de noms qui contient uniquement des outils et des artefacts concernant le projet de logiciel ; par conséquent, un filtre commun est créé pour rattacher différents artefacts à partir de différents outils.

Un seul serveur Team Foundation Server peut contenir plusieurs projets d'équipe, chacun créé dans un espace de noms distinct, de sorte qu'un document nommé X dans l'espace de noms A n'est pas le même qu'un document nommé X dans l'espace de noms B. La création d'un projet d'équipe dans un espace de noms séparé permet de garantir l'unicité des artefacts ou des outils par rapport au projet d'équipe auquel ils appartiennent, de sorte qu'un outil ou un artefact contenu dans le projet d'équipe A n'est pas accessible à un développeur de logiciels qui travaille sur le projet d'équipe B.

Définition physique d'un projet d'équipe

La définition logique et la limite conceptuelle autour d'un projet d'équipe prennent corps par le biais de Team Explorer. Team Explorer est une fenêtre Outil extensible dans Visual Studio qui regroupe les outils et les artefacts par projet d'équipe. Un projet d'équipe est au moins composé d'un jeu d'outils et d'artefacts spécifiés au moment où le projet d'équipe a été créé par le modèle de processus. Selon le modèle de processus utilisé pour sa création, le projet d'équipe peut également inclure des stratégies de contrôle de code source, un site de génération de rapport de projet d'équipe et un portail de projet d'équipe.

La première fois que vous ouvrez Team Explorer, vous devez le connecter au serveur Team Foundation Server. Vous pouvez ensuite sélectionner les projets d'équipe à afficher dans Team Foundation Server. Team Explorer se connecte à un seul serveur Team Foundation Server et, par conséquent, affiche uniquement les projets d'équipe d'un seul serveur Team Foundation Server. De même, selon le modèle de processus utilisé pour créer le projet d'équipe, les membres de l'équipe peuvent utiliser Team Explorer pour consulter des informations sur les builds de produit, lancer le code source, exécuter des requêtes sur des tâches qui leur sont assignées, afficher l'état général du projet, localiser des documents, consulter des rapports et créer des produits de travail associés au projet d'équipe. Par exemple, un projet d'équipe créé à l'aide des modèles de processus MSF for Agile Software Development ou MSF for CMMI Process Improvement affiche les nœuds suivants :

Éléments de travail Ce nœud permet de créer et d'afficher des requêtes sur la base de données des éléments de travail et de créer de nouveaux éléments de travail. Les requêtes de projet sont implémentées par le modèle de processus ou le chef de projet à la création du projet d'équipe. Les requêtes définies par l'utilisateur ne sont pas implémentées pendant la création du projet d'équipe, mais sont ajoutées ultérieurement en tant que contenu personnalisé.
Documents Ce nœud permet d'accéder à des produits de travail, tels que des documents, des feuilles de calcul, des plans de projet, le guide de processus et d'autres données de sortie intangibles tirées des activités de développement. Les documents sont stockés dans un seul emplacement central sur le portail du projet d'équipe.
Rapports Ce nœud permet d'accéder à des rapports qui contiennent les métriques du projet d'équipe et à un moyen de rassembler des informations à partir des différents outils contenus dans l'espace de noms du projet d'équipe. Le site de rapports SQL Reporting Services est conçu pour créer des rapports à partir de plusieurs outils en réunissant des informations diverses d'outils variés dans le projet d'équipe et pour établir un rapport en employant la sémantique et la syntaxe adaptées aux informations exportées de chaque outil.
Builds d'équipe Ce nœud permet d'accéder aux builds de votre projet d'équipe.
Contrôle de code source Ce nœud permet d'accéder à des artefacts, tels que du code source et du texte. Les développeurs de programmes utilisent l'Explorateur du contrôle de code source pour archiver et extraire du code source. L'Explorateur du contrôle de code source permet de naviguer parmi les fichiers sources du projet d'équipe. Un utilisateur peut définir et implémenter plusieurs outils personnalisés.

Les paramètres et les propriétés varient d'un projet d'équipe à un autre. Les propriétés du projet d'équipe sont définies dans le menu Équipe dans Visual Studio. Elles déterminent les paramètres des groupes et des autorisations qui identifient les membres du projet d'équipe et leurs droits d'accès. Par exemple, un développeur de logiciels peut avoir le droit de modifier le document X dans un projet d'équipe, mais pas le document Y, tandis qu'un autre développeur travaillant sur le même projet d'équipe peut avoir le droit de modifier les documents X et Y. L'assignation de groupes contribue à établir les différentes sous-équipes au sein du projet d'équipe et à améliorer la gestion des tâches requises. Les paramètres du projet d'équipe incluent également les regroupements hiérarchiques virtuels des artefacts contenus dans le projet d'équipe. La structure de classification peut inclure les itérations de cycle de vie qui constituent un projet d'équipe et les composants ou fonctionnalités d'un projet d'équipe. Les éléments de travail et les autres artefacts, tels que les scénarios de test, peuvent également être classés par structures/hiérarchies pour faciliter le suivi et la création de rapports.

Les stratégies de contrôle de code source aident à définir des paramètres de contrôle de code source. Les paramètres de contrôle de code source caractérisent les paramètres d'extraction, les stratégies d'archivage et les notes d'archivage. Ils définissent les artefacts qui peuvent être extraits et les utilisateurs autorisés à le faire, ils aident également à définir les paramètres qui permettent à un utilisateur de revenir en arrière et d'extraire les différentes versions d'un artefact qui ont pu être produites pendant le cycle de vie du projet.