Team Foundation Server Côté chef de projet

Team Foundation Server Côté chef de projet Version 1.0 Z Sylvain Lieu Franck Boisgibault

2 Chapitre 03 - Partie chef de projet Sommaire 1 Introduction... 3 2 Rôles et groupes... 4 2.1 Groupes par défaut... 4 2.2 Groupes personnalisés... 5 2.3 Processus de projet... 8 3 Suivi de travail... 11 3.1 Création des éléments de travail... 11 3.2 Gestion des éléments de travail... 13 3.3 Rapports... 15 4 Conclusion... 20

3 Chapitre 03 - Partie chef de projet 1 Introduction Le chef d un projet doit pouvoir gérer l avancement du travail tout en guidant les développeurs. TFS offre un cadre professionnel aux chefs de projets grâce à des systèmes de tâches, d éléments de travail et de gestion des groupes. Ainsi, chaque pôle de développement pourra s atteler à une tache particulière et cela restera clair et facilement gérable pour le chef de projet.

4 Chapitre 03 - Partie chef de projet 2 Rôles et groupes 2.1 Groupes par défaut Les groupes par défaut permettent de répartir les droits de chaque utilisateur bien plus aisément. En effet, la configuration par défaut correspond à une structure de base pour une entreprise avec des droits de lecture, d écriture et d administration. On peut distinguer deux types de groupes. Les groupes de niveau projet sont des groupes dont la portée est limitée au projet associé. Ils sont créés en même temps que le projet et disparaissent à sa suppression. Les groupes de niveau serveur conditionnent l accès à TFS et portent sur les droits d administration du serveur. Les groupes par défaut de niveau projet sont : - Project Administrators - Contributors - Readers - Build Services Les groupes par défaut de niveau serveur (groupes globaux) sont : - Team Foundation Administrators - Team Foundation Valid Users - Team Foundation Licenced Users - Service Accounts Nous pouvons faire une hiérarchie des droits dans les groupes de projet par défaut. Ainsi, le reader n a que les droits de lecture sur le serveur. Il ne peut rien modifier. Ce groupe est utile pour les personnes de l entreprise qui doivent connaitre l avancement du projet sans faire réellement parti de ce projet (Responsable de département, commercial ). Le contributor sera le développeur «standard». Il pourra utiliser pleinement TFS pour son compte mais ne peux ni changer les permissions, ni modifier le travail des autres de façon anormale (en ignorant les lock, en modifiant les étiquettes apposées par d autres, en annulant les changements d un autre utilisateur ). Le Project Administrator pourra gérer le projet de manière spécifique en ayant le droit de modifier comme il vaut quand il veut chaque fichier. Il peut par exemple ignorer les verrous ou effectuer un check-in d un fichier sur lequel un développeur travaille. Mais il peut aussi influencer le projet d une manière plus générale en créant de nouvelles zones et de nouveaux nœuds, en modifiant les autorisations des autres groupes ou même en supprimant le projet par exemple. La principale limite est qu il ne peut pas créer de nouveaux projets, car c est un droit de niveau serveur. Ce groupe est typiquement celui des chefs de projets. Le Build Service est un compte à part car il est simplement orienté pour la création de build. Il a les mêmes droits que le contributor auxquels il faut ajouter le droit d édition de la qualité de build et le droit de stockage dans la base de données de build. A cause de cette possibilité d éditer la base de données, il est nécessaire de n assigner que des services et pas d utilisateur réel à ce groupe.

5 Chapitre 03 - Partie chef de projet Ce modèle de droit lecture/écriture/gestion ne se retrouve pas dans les groupes de niveau serveur. En effet, au niveau du serveur, il y a une grande différence entre l administrateur qui a accès à tout et les autres groupes qui n ont accès à presque rien. Le groupe Team Foundation Licenced Users n existe que si c est une version workgroup de TFS qui a été installée. Ainsi, avec ce groupe, il est possible de regrouper les utilisateurs qui ont utilisé la même licence (5 maximum). Ce groupe n a pas de droits mais il est utile pour pouvoir intégrer tous ces utilisateurs dans un même groupe facilement (souvent Team Foundation Administrators). Le groupe Team Foundation Valid Users représente les utilisateurs qui ont pu s authentifier. Chaque utilisateur valide sera ajouté automatiquement à ce groupe et il sera impossible de changer ce comportement. Un utilisateur valide peut créer un espace de travail et connaitre les membres de tous les groupes ainsi que leurs permissions. Il n a aucun droit sur les projets créés. Le groupe Team Foundation Administrators réunit les utilisateurs ayant le plus de droit. Ils peuvent créer et supprimer des projets et des espaces de travail, modifier et supprimer chaque élément créé par un autre utilisateur et ont également les droits administrateurs de chaque projet. Le groupe Service Accounts doit regrouper les comptes de service. Ils peuvent interagir au niveau du serveur sur plusieurs éléments clés et sont administrateurs dans chaque projet. Les groupes par défaut sont donc assez complets pour assurer une organisation minimale mais efficace. Leur nombre réduit permet une gestion rapide des droits et la répartition des utilisateurs est généralement très intuitive. 2.2 Groupes personnalisés Bien que les groupes par défaut soient suffisants pour la majeure partie des projets, il peut cependant arriver que des utilisateurs ne puissent pas s y conformer parfaitement. Par exemple, un chef de projet d une entreprise partenaire devrait pouvoir avoir les droits administrateurs à l exception de la modification des paramètres de sécurité. Un développeur de confiance pourrait avoir le droit d administrer les verrous afin d éviter qu un verrou laissé par erreur empêche toute une équipe de travailler. Ces cas spécifiques peuvent être traités en utilisant des groupes personnalisés. L exemple qui va suivre explique comment créer un groupe de projet personnalisé. La procédure est identique pour la création d un groupe de serveur bien que les droits ne soient pas les mêmes. Nous allons créer un groupe pour les contributeurs avec privilège. Ces contributeurs, en plus des droits de départ, pourront administrer les étiquettes, changer les paramètres de sécurité et déverrouiller les éléments verrouillés par d autres contributeurs. Tout d abord, il faut utiliser le menu contextuel grâce à un click droit sur le nom du projet (Dotnet-France dans l exemple) dans l explorateur d équipe. Il faut ensuite cliquer sur «Team Project Settings» puis «Group MemberShip». Une fenêtre affichant tous les groupes de projet apparaît. Un click sur le bouton «New» permet de définir le nom et la description du nouveau groupe. Valider en cliquant sur «OK» et ainsi, le groupe apparaît dans la liste. Dans l exemple, le groupe créé est appelé «Privileged Contributors».

6 Chapitre 03 - Partie chef de projet A cet instant, le groupe n a ni membres, ni droits. Par un double click sur le nom du groupe, une fenêtre de propriétés apparaît, dans laquelle il est possible d ajouter des utilisateurs et des groupes. Il est aussi possible d inclure le groupe dans d autres groupes via l onglet «Member of». Pour l instant, nous n allons pas ajouter de membre.

7 Chapitre 03 - Partie chef de projet Pour attribuer des droits concernant le contrôle de source à ce groupe, il faut passer par le menu contextuel du projet dans l explorateur de contrôle de source (double click sur «Source control» puis, à gauche, click droit sur le nom du projet) et choisir «Properties» puis l onglet «Security». Dans la fenêtre qui apparaît, cliquer sur «Add» pour pouvoir ajouter le groupe voulu dans la liste. Une seconde fenêtre s affiche dans laquelle il faut sélectionner le groupe puis cliquer sur OK. Le groupe est alors ajouté à la liste «Users and Groups» et il suffit de le sélectionner pour pouvoir éditer ses droits. Pour correspondre à notre souhait, il faut cocher, en plus des droits de contributeurs standards, les cases «Unlock other users changes», «Administer labels» et

8 Chapitre 03 - Partie chef de projet «Manipulate security settings». A présent, les utilisateurs ajoutés dans le groupe bénéficieront de tous ces droits. Au-delà des groupes par défaut, il est ainsi possible de gérer son équipe plus précisément en créant des groupes personnalisés. Ainsi, chaque entreprise peut gérer ses utilisateurs comme elle le souhaite en se basant sur un modèle à son image. 2.3 Processus de projet Les processus de projet sont des modèles d utilisation, comparables à des design pattern pour le management. Le processus d un projet est choisi lors de sa création. Par défaut, les deux seules possibilités sont MSF for Agile Software Development et MSF for CMMI Process Improvement. Comme leur nom l indique, il sont tous les deux basés sur Microsoft Solutions Framework (MSF). Il est également possible d enregistrer un modèle de processus personnalisé.

9 Chapitre 03 - Partie chef de projet Un modèle de processus est une somme de rôles qui permettent d aborder un projet d une manière organisée et fonctionnelle. Le modèle Agile Software Development contient six rôles : Quatre rôles correspondent au groupe Contributors : - Architecte - Analyste d entreprise - Développeur - Testeur Deux rôles correspondent au groupe Project Administrators : - Chef de projet - Responsable de la livraison Il est préférable, afin de correspondre au mieux au modèle Agile, de créer des groupes personnalisés. Pour vous guider dans cette étape, nous vous conseillons le tableau disponible dans la partie «Autorisations associées aux rôles MSF for Agile Software Development» de la documentation MSDN suivante : http://msdn.microsoft.com/fr-fr/library/ms253077.aspx Le modèle CMMI Process Improvement étant destiné à être utilisé pour des projets très lourds, il regroupe 18 rôles : Deux rôles correspondent au groupe Readers : - Commanditaire - Expert Dix rôles correspondent au groupe Contributors : - Auditeur - Analyste d entreprise - Développeur - Architecte d infrastructure - Responsable de la gestion intégrée - Chef de produit - Architecte Solution - Testeur - Architecte de la documentation utilisateur - Spécialiste de l information Six rôles correspondent au groupe Project Administrators : - Ingénieur de conception - Responsable du développement - Développeur senior - Chef de projet - Responsable de la livraison - Gestionnaire de test

10 Chapitre 03 - Partie chef de projet Avec ce modèle de processus, on s aperçoit que de nombreuses fonctions diverses sont regroupées au sein d un même groupe. Il est donc encore plus conseillé d utiliser des groupes personnalisés. Encore une fois, pour vous aider à configurer ces groupes, nous vous conseillons le tableau de la partie «Autorisations associées aux rôles MSF for CMMI Process Improvement» présent dans l article de la MSDN : http://msdn.microsoft.com/fr-fr/library/ms253077.aspx Avec l intégration des processus, TFS rend la gestion des projets bien plus claire. Les processus permettent un management efficace et TFS rend la sécurisation du projet beaucoup plus aisée. De plus, chaque rôle peut trouver sa place au sein d un groupe par défaut ce qui simplifie considérablement la mise en place des droits. La sécurisation de l accès, tâche qui incombe au chef de projet, peut être facilement mise en place avec TFS. En effet, ses groupes par défaut permettent de répondre d une manière générale aux besoins des entreprises. Il est aussi possible, grâce aux groupes personnalisés, de s adapter complètement au fonctionnement de chaque structure. Cette adaptation est encore plus poussée grâce à la possibilité d appliquer facilement les modèles de processus. Mais au-delà de la sécurisation, le chef de projet est un manager qui doit guider et vérifier l avancement du projet. C est dans cette optique que TFS intègre des outils tels que les éléments de travail qui assure un historique, un suivi et une efficacité accrue.

11 Chapitre 03 - Partie chef de projet 3 Suivi de travail 3.1 Création des éléments de travail Les éléments de travail sont des entités qui peuvent être attachés à chaque action dans TFS. Ils sont créés et modifiés par des membres du groupe Contributors et peuvent être du type bug ou tache par exemple. Ainsi, l assignation d un bug à un développeur particulier lui permettra de corriger le bug et d indiquer très facilement lorsque cette action a été effectuée. Les types d éléments de travail sont définis par défaut lors de la création du projet, en fonction du processus choisi. Dans le cas du processus MSF for Agile Software Development, les cinq types d élément de travail sont : - Scénario - Bug - Impératif de qualité de service - Tâche - Risque Les différents éléments de travail sont créés en passant par le menu Team > Add Work item. Ils restent très similaires et ne présentent des différences que dans la partie détail, à l exception du type bug qui contient deux champs supplémentaires dans son statut (priorité et triage).

12 Chapitre 03 - Partie chef de projet Les champs communs à tous les éléments de travail sont : - Title : Obligatoire, il permet de retrouver l élément - Area : Permet de choisir la zone sur laquelle l élément s applique - Iteration : Permet de choisir l itération sur laquelle l élément s applique - Assigned To : Assigne le travail à un utilisateur ou un groupe - State : Permet de choisir l état de l élément (Actif, Fermé) - Reason : Permet de choisir la raison de l état (Nouveau, Obsolète) - Description : Explique en quoi consiste l élément et donne éventuellement les détails de ce qu il faut faire. - History : Montre tous les évènements liés à l élément de travail en précisant l utilisateur qui l a effectué, la date et l heure. - Links : Permet de lier un élément de travail avec un autre élément, une version de fichier ou encore une URL - File Attachments : Upload un fichier avec l élément. - Details : Permet d entrer des informations supplémentaires Vu le nombre de champs identiques, on comprend que les principales différences entre les types d éléments de travail se fait sur leur utilisation plus que sur leur structure. Voici une courte description des utilisations basiques de chaque élément de travail : - Le scénario permet d indiquer un objectif général tout en développant les étapes. Il laisse une grande liberté car il n est pas spécifique. - Le bug est un élément qui doit généralement être traité au plus vite. Il est possible d indiquer le build sur lequel il est apparu ainsi que le test qui l a détecté. - L impératif de qualité de service est un élément de travail qui décrit une contrainte à l utilisation d un logiciel. Cette contrainte peut être matérielle (limite minimum de RAM ) ou logicielle (Internet Explorer requis ). - La tâche est l élément standard. Elle permet de définir n importe quel travail à effectuer - Le risque est un élément qui représente un danger dans le futur. Il est signalé afin de vérifier l impact qu il peut avoir et tenter de l atténuer

13 Chapitre 03 - Partie chef de projet 3.2 Gestion des éléments de travail Les éléments de travail sont accessibles via Team Explorer, en suivant le chemin [Nom du projet] > Work Items > Team Queries. Un double click sur un des éléments présent dans ce dossier permet de lancer une requête dans la base de données et obtenir les éléments de travail correspondants. Pour consulter les éléments qui sont assignés à l utilisateur actuel, il faut choisir «My Work Items». On s aperçoit ici que la tâche 93 est le bug que l on vient de créer. La tache 92 est la tâche de test héritée de la partie sur l utilisation de Microsoft Excel et Microsoft Project. La tâche 91 est fermée et obsolète. Les autres tâches sont crées par défaut avec le projet. Elles permettent de guider le chef de projet dans le lancement du projet et l utilisation de TFS.

14 Chapitre 03 - Partie chef de projet Les propriétés de l élément de travail sélectionné apparaissent en dessous de la liste et peuvent être modifiée, si les droits nécessaires sont attribués. Le développeur à qui la résolution de bug incombe va alors pouvoir modifier les fichiers source concernés et ainsi, déclarer que le bug est résolu. Pour cela, il faut suivre la procédure d édition habituelle. Via le Contrôleur de source, effectuer un Check-out des fichiers, éditer chacun d eux puis effectuer un Check-in. Cependant, au Check-in, il faut choisir l onglet «Work Items». Dans le champ «Query», il faut choisir la requête approprié. Dans une utilisation normale, un développeur effectuera un travail qu on lui a assigné donc il retrouvera l élément de travail grâce à la requête «My Work Items». Ici, il faut cocher le bug nommé «Exécution de la partie calcul» avec l ID 93 puis choisir «Resolve» dans la colonne «Check-in Action». Maintenant, le bug 93 n est plus présent dans la liste des bugs actifs mais apparait dans celle des bugs résolus. De plus, dans l historique de l élément, une nouvelle entrée indique le moment ou les modifications ont eu lieu et leur auteur. L entrée précise également les champs modifiés et le numéro du changeset correspondant. Les éléments de travail sont la base de l utilisation de TFS en entreprise. Ils permettent de donner un travail précis à un utilisateur ou un groupe précis. Ils apportent une certaine rigueur, qui fait parfois défaut dans les solutions de télétravail. Dans l absolue, un projet est terminé seulement quand tous les éléments de travail ont été traité. Ainsi, on peut se rendre compte de l avancement et du travail restant en consultant la liste des éléments de travail. On peut également vérifier la productivité de chaque intervenant en vérifiant ses tâches résolus.

15 Chapitre 03 - Partie chef de projet 3.3 Rapports Les rapports sont une manière pratique d afficher les informations qui concernent l activité du projet. Ils sont la plupart du temps sous forme de graphique mais une simple liste d élément de travail est aussi considérée comme un rapport. Plusieurs solutions sont possibles pour générer des rapports. La première, que nous allons développer, est très adaptées aux managers. C est la génération de rapport par Microsoft Excel. Microsoft Excel 2003 ou ultérieur est nécessaire. La seconde utilise le dossier «Report» du projet grâce à Team Explorer. Dans ce dossier, plusieurs modèles de rapport sont préenregistrés. Lors du double click sur l un d eux, un rapport se génère automatiquement et s affiche dans Visual Studio. La dernière utilise l interface web grâce au site http://<nom du serveur>/reports. En sélectionnant le projet voulu, la liste des modèles de rapport apparaît. En cliquant sur l un de ces modèles, le rapport est généré. Attention, il faut utiliser Internet Explorer pour que la génération s effectue correctement.

16 Chapitre 03 - Partie chef de projet Le système de rapport est surtout destiné aux managers car il permet de suivre l évolution du travail effectué par les développeurs. Ainsi, on peut voir l évolution du nombre de taches, du nombre de bugs actifs ou résolus, des builds et bien d autres choses. Ces données sont classables par date ou par utilisateur par exemple. Pour utiliser les données de TFS avec Microsoft Excel, choisir : Données > données externes > A partir d autres sources > Provenance Analysis Services. Une fenêtre va s ouvrir dans laquelle il faudra entrer les informations suivantes : - Nom ou Adresse IP du serveur dans le champ «Nom du serveur» - Utiliser l authentification de Windows si le compte local utilisé est déjà enregistré dans TFS Si le compte n est pas enregistré dans TFS, l option «Utiliser le nom d utilisateur et le mot de passe suivants» permet de spécifier un autre compte.

17 Chapitre 03 - Partie chef de projet Dans la fenêtre suivante, sélectionner la base de données «TfsWarehouse» puis le cube «Team System» et cliquer sur «Suivant». Une nouvelle fenêtre apparait et permet d enregistrer le fichier de connexion. Ainsi, il suffira d ouvrir ce fichier pour accéder directement aux données. Dans la fenêtre «Importation de données», choisissez «Rapport de tableau croisé dynamique» puis l endroit ou seront insérer les données (feuille actuelle ou nouvelle feuille). Un click sur «OK» insère le tableau croisé dynamique et ouvre le volet de liste de champs. Le tableau doit maintenant être rempli avec les valeurs demandées. Cette étape s effectue grâce à la «Liste de champs de tableau croisé dynamique». - Sélectionner «Current Work Item» dans la liste déroulante. Seuls les champs concernant les éléments de travail courants seront affichés. - Cocher «Current Work Item Count». C est un champ valeur qui ira directement dans la zone correspondante en dessous de la liste. - Effectuer un glisser-déposer du champ «Created by.person» dans la zone «Etiquettes de colonne». - Effectuer un glisser-déposer du champ «Work Item.Title» dans la zone «Etiquettes de ligne».

18 Chapitre 03 - Partie chef de projet Le tableau se met à jour de façon dynamique pour chaque élément qui lui est ajouté. Il est également possible d utiliser les fonctionnalités graphiques de Microsoft Excel afin de créer un schéma automatiquement. Ainsi, les managers peuvent accéder à tout moment à l évolution du travail effectué par les développeurs. L intégration à Microsoft Excel permet de créer des rapports personnalisés très facilement et l accès à l interface web autorise la création de rapport prédéfinit de manière rapide et efficace, tout comme Team Explorer.

19 Chapitre 03 - Partie chef de projet Cette fonctionnalité est primordiale dans un milieu professionnel, où le télétravail peut inquiéter. Ce suivi rassure les responsables et leur permet de consulter à chaque instant des informations aussi diverses que le nombre de bugs résolus, les résultats de test de charge ou encore la durée des builds.

20 Chapitre 03 - Partie chef de projet 4 Conclusion Après ce cours, on ne se rend pas seulement compte que Team Foundation Server est un outil de développement puissant, on comprend également qu il est utile pour tout le management d équipe. Bien sûr, il facilite la vie des utilisateurs grâce à son contrôle de version extrêmement efficace et ses possibilités de build très poussé. Mais il aide aussi tous les managers avec des outils tels que les accès par Microsoft Excel et Microsoft Project, les éléments de travail, la gestion des groupes, les processus ou encore les rapports. Un chef de projet peut sans problème gérer une équipe distante et suivre l évolution du travail. Son intégration dans un environnement composé de SQL Server, Sharepoint et Visual Studio permet de tirer parti des qualités de chacune de ces solutions. Il est même possible d utiliser Microsoft Excel ou Project afin de simplifier encore l utilisation. Tous ces éléments font de Team Foundation Server un outil complet, adapté aux développeurs et aux chefs de projet, simple d utilisation et puissant.