I. Introduction▲
Dans cet article, nous allons voir comment Team Foundation Server (TFS), l'outil d'Application Lifecycle Management (ALM) de Microsoft, permet de gérer un projet dans un cadre Agile en général, et Scrum en particulier.
La méthode Scrum est un ensemble d'outils (framework) permettant le développement d'un projet en mode Agile.
Scrum possède les artefacts suivants : le product backlog, le sprint backlog, le task board et le burndown chart.
Pour plus d'informations sur Scrum à lire sur le guide officiel.
Nous commencerons avec la mise en place de l'architecture d'un projet TFS, puis nous verrons comment gérer les artefacts Scrum dans TFS.
Les différents points dans les articles vont traiter :
- de la création d'un projet et des membres de l'équipe dans TFS ;
- du product backlog ;
- de la gestion des itérations (ou sprint) ;
- du sprint backlog ;
- du suivi d'état d'avancement avec le task board et le kanban board ;
- du reporting (burndown et cumulative flow).
II. Création d'un projet d'équipe▲
Au service du Product backlog, du PO, du Scrum Master et de l'équipe, le point de départ d'un projet avec TFS est le projet d'équipe.
Celui-ci contient le code source, les éléments de travail (work items), les builds, le partage de la documentation, le reporting…
La création d'un projet d'équipe se fait via :
- le Team Explorer, l'outil client pour TFS On Premise ;
- le Team Web Access pour Visual Studio Online.
En effet, aujourd'hui TFS existe sous deux modes :
- On Premise, le mode classique, c'est-à-dire quand TFS est installé sur un serveur interne de l'entreprise ;
- VSOnline, le mode cloud de TFS, c'est-à-dire sans installation, accessible depuis un navigateur web et gratuit jusqu'à cinq utilisateurs. Voir les détails.
Pour créer un projet équipe, il faut d'abord se connecter à TFS dans la collection ou l'on souhaite placer notre projet d'équipe, puis cliquer sur nouveau.
Sur Tfs OnPremise :
Sur VSOnline :
- Renseigner le titre et la description du projet
- Choisir le modèle de processus (Process template)
Pour plus d'informations sur les différences entre les modèles de processus, voir le chapitre « Choix du modèle de processus » et sur la msdn.
- Choisir le contrôleur de source (TFVC ou Git)
Pour la différence entre les deux modes, voir la msdn.
Une fois validé, votre projet d'équipe est créé et prêt à être utilisé.
III. Définir les membres de l'équipe (Team Members)▲
Depuis la version 2013, TFS a introduit la notion d'équipe qui représente les personnes qui interviennent sur le projet.
Ces personnes peuvent avoir des rôles différents, ils peuvent être des développeurs, des managers, des stakeholders, des spécificateurs…
La gestion de cette équipe se fait via le Team Web Access, sur l'accueil de la page du projet d'équipe, il faut cliquer sur le lien « gérer tous les membres » du bloc Members.
Un membre se caractérise par son compte Windows (On Premise) ou par son compte liveID (VSonline).
Cette section permet de gérer notamment :
- les membres (ou groupes), dans l'onglet overview ;
- les membres sur les différentes itérations et zones, dans les onglets « Itérations » et « Zones » ;
- leurs permissions, dans l'onglet sécurité.
Remarque : l'outil en ligne de commande tfsteamtools permet de gérer les membres (par exemple leur avatar) http://tfsteamtools.codeplex.com/
IV. Le choix du modèle de processus (process template) ▲
Comme vu dans le chapitre Création d'un projet d'équipe, une des étapes de la création d'un projet est le choix du modèle de processus.
Le choix du modèle de processus est important, car c'est lui qui indique quel est le cadre spécifique Agile utilisé pour le projet.
Il existe trois modèles de processus de base :
Microsoft Visual Studio Scrum 2013
MSF for Agile Software Development 2013
MSF for CMMI Process Improvement 2013
Les différences se situent au niveau du nommage des types de Work items ainsi que de leurs champs, de la constitution du product backlog du workflow général et des indicateurs.
Par exemple dans le template Scrum, le Bug fait partie du backlog ce qui n'est pas le cas du MFF et CMMI.
Pour avoir une description très détaillée sur la comparaison et leurs différences, voir http://msdn.microsoft.com/library/vstudio/ms400752.aspx
Tous ces modèles et leurs éléments sont customisables.
V. La gestion du backlog (ou Product Backlog)▲
Le product backlog (appelé aussi backlog) est constitué de l'ensemble des tâches fonctionnelles à accomplir pour la réalisation du produit.
Le backlog n'est pas une liste finie, elle évolue sans cesse avec des ajouts, suppressions ou modifications de tâches et de leurs priorités.
Une tâche peut être de nature différente : soit une fonctionnalité ou bien même un bogue.
Au fil du temps ces tâches sont :
- ordonnées dans l'ordre où elles devront être traitées (de la Business value la plus importante à la moins importante) ;
- estimées en points (dans la plupart des cas), en heures ou en jours idéaux, selon le niveau de difficulté relatif de réalisation.
Chaque élément du product backlog est appelé Product Backlog Item (PBI), il peut être de type User Story (fonctionnalité) ou Bug (anomalie)
Dans TFS :
- les éléments qui constituent le product backlog sont les éléments de travail (Work items) ;
- leur appellation (user story, bug, Product backlog item, requirement) dépend du modèle de processus choisi.
La gestion du Product Backlog se fait dans la rubrique « Travail ».
Pour ajouter une nouvelle fonctionnalité (Product Backlog Item PBI) ou Bug, il faut choisir le type (PBI ou Bug), renseigner le titre dans la zone de texte titre qui se trouve dans le panel d'ajout rapide, puis valider (bouton Ajouter).
En cliquant sur le PBI créé, on accède à sa fiche complète.
D'autres informations importantes sont à renseigner dans la fiche du PBI :
- l'estimation dans le champ Effort ;
- la description ;
- et autres informations, certaines étant obligatoires du point de vue de l'équipe.
V-A. Détails du Product Backlog Item▲
Voici une description des différents champs du formulaire de l'élément de travail de type PBI :
Tags : les tags permettent d'associer des mots au WI, pour faciliter leur recherche
Itération : choix de l'itération où le WI sera traité (CF : sprint planning)
Assigné à : nom de l'utilisateur (développeur) qui traitera le WI
État : planifié/en cours/fini
Raison : raison du changement de l'état
Effort : nombre de points nécessaires pour le réaliser
Valeur Business : indication de valeur ajoutée sur le métier
Zone : zone fonctionnelle
Description : description
Storyboard : association de fichiers PowerPoint avec des storyboards
Test Cases : association avec des WI de type cas de test
Tâches : tâches techniques nécessaires pour réaliser ce PBI (CF sprint planning)
Critères d'acceptation : liste des critères pour que le PBI soit Fini (Done)
Historique : historique des modifications de ce PBI
Liens : liens associés à ce PBI
Pièces jointes : PJ (images, fichiers word, excel…)
V-B. La suppression d'un élément du product backlog▲
Via TFS, il n'est pas possible de supprimer un PBI. Cependant pour le détruire définitivement, on peut utiliser l'outil en ligne de commande Witadmin.exe avec comme paramètre destroywi.
V-C. Réordonner les PBI▲
L'ordre des PBI est important puisque c'est lui qui indique l'ordre de réalisation et donc potentiellement l'ordre de livraison en production (voir la notion d'intégration continue qui fait partie des éléments fondamentaux de Scrum).
Dans TFS pour réordonner les PBI au sein du product backlog, il faut utiliser :
soit le drag and drop
soit le menu contextuel du PBI
VI. Gestion des itérations▲
VI-A. La création et mise à jour d'une itération▲
La création d'une itération (ou sprint) se fait (depuis TFS 2012/2013) via le Team Web Access dans la partie d'administration du projet d'équipe, dans l'onglet Itération.
Les itérations dans TFS sont constituées de façon hiérarchique, le 1er niveau correspond aux Releases, au 2e niveau sont les itérations (sprint) (il n'y a pas de limite dans le nombre de niveaux).
Pour créer un nœud, on se place sur le niveau parent, puis on clique sur « New Child », donc pour créer une itération, on se place sur sa release.
Remarque : il peut être intéressant de créer des sous-niveaux de sprints, lorsque plusieurs équipes travaillent sur le même projet avec la même organisation de sprint.
Par exemple : pour le sprint 3, pour l'équipe 1, elle est du 01/03/14 au 15/03/14, par contre pour l'équipe 2, elle est du 05/03/14 au 20/03/14.
Une itération se constitue d'un nom, exemple « Itération 25 », de sa date de début et de sa date de fin.
Une fois créée, il est possible de la modifier en passant la souris sur sa ligne puis en cliquant sur le lien « Set date »
La case à cocher qui se trouve devant indique si l'on souhaite activer ou désactiver cette itération dans la partie de la gestion du backlog.
VI-B. La capacité▲
La capacité d'une itération représente la charge de travail que peut réaliser l'équipe durant cette itération.
C'est-à-dire le nombre d'heures de travail par jour ainsi que les jours non travaillés.
Par expérience, la capacité du sprint ne se remplit pas au même moment que la création de l'itération dans TFS, mais se fait au moment de la planification du sprint.
La gestion de la capacité d'une itération se fait dans la gestion du backlog, puis en cliquant sur une itération, on accède à l'onglet Capacité.
Dans la colonne « Capacité par jour », on indique le nombre d'heures que chaque membre de l'équipe pourra travailler par jour, la colonne « Activité » permet d'indiquer l'activité du membre (exemple : test, développement, design…), et la dernière colonne indique le nombre de jours non travaillés sur le projet pour ce sprint.
Pour rajouter des jours non travaillés, il faut cliquez sur le +.
Il est même possible de copier automatiquement la capacité d'une itération à partir de l'itération précédente.
Une fois cette capacité renseignée, TFS va pouvoir fournir des indicateurs sur l'avancement de l'itération en temps réel.
Ces indicateurs se font par activité et par membre de l'équipe.
VII. Le sprint backlog▲
Le sprint backlog correspond aux items du product backlog qui pourront être réalisés dans une itération.
Le sprint backlog est réalisé lors de la planification du sprint.
D'un point de vue de Scrum, durant celle-ci plusieurs éléments sont définis :
- quels sont les items qui pourront être réalisés durant le sprint ;
- en tenant compte de la vélocité de l'équipe (nombre d'unités sur lequel l'équipe peut s'engager) ;
- découper les PBI en tâches techniques (en général) si nécessaire.
Dans TFS, il faut tout d'abord créer l'itération (voir chapitre sur Création d'une itération).
Puis dans la section Backlog, à partir du moment où l'itération est programmée (avec des dates renseignées et activées), l'itération apparaît dans la section de gauche.
Pour affecter des PBI à des itérations, il suffit de faire un drag and drop du PBI vers l'itération.
Ou sur le menu contextuel du PBI
Ou sur la fiche du PBI en sélectionnant l'itération
VII-A. Le forecasting▲
Le forecasting est une aide qui selon la vélocité renseignée permet d'indiquer la planification des PBI sur les sprints à venir.
Dans l'écran ci-dessus, on peut remarquer qu'une fois le forecast activé, puis la vélocité renseignée, le backlog donne une indication sur le découpage des sprints en fonction des unités de travail estimées (Effort) des PBI.
Le forecasting reste une aide, et ne permet pas l'association d'un PBI à un sprint, il permet une planification de sprint plus fluide et une vision sur la réalisation des tâches pour les itérations à venir (planning Release).
VII-B. Le découpage des PBI en tâches techniques▲
Une des étapes de la planification de sprint est le fait d'associer des tâches techniques aux PBI.
Ces tâches techniques sont nécessaires à la réalisation de la fonctionnalité décrite dans le PBI, elles participent à l'estimation.
Dans TFS cette tâche technique est appelée Tâche (ou Task).
Cette manipulation peut se faire soit avec le Team Web Access, soit avec Team explorer.
Dans le Team Web Access
- Activer l'affichage de la hiérarchie PBI/tâches dans le menu de gauche
- En passant la souris devant chaque PBI, un
apparaît, celui-ci permet de créer et d'associer une tâche dans le PBI.
On peut associer cette tâche à un type d'activité, ce n'est pas que du développement, cela peut être aussi de la documentation ou des tests par exemple.
Et ainsi de suite, on peut associer toutes les tâches nécessaires à la réalisation du PBI.
Une autre possibilité est de créer la tâche à partir de la fiche du PBI dans l'onglet tâches.
Une fois que tous les PBI ont leurs tâches associées, on obtient une visualisation des différents éléments à réaliser dans le sprint de façon hiérarchique : chaque PBI avec ses tâches.
Si le lien « détails du travail » est activé (lien en haut à droite), les indicateurs d'avancement du sprint sont visibles en temps réel (bandeau de droite).
Ces indicateurs sont fournis par activité (qui correspondent aux activités renseignées dans la capacité de l'itération) et aussi par membre de l'équipe.
VIII. Suivre l'état d'avancement▲
VIII-A. Le task board▲
Le task board est représenté en tableau, il indique l'état d'avancement des tâches au cours d'un sprint.
Ce tableau contient les états d'une tâche : À faire - En cours - Fini, planifiées pour l'itération.
Pour y accéder, il faut cliquer sur le sprint désiré, puis sur le lien « board » du menu du haut.
Ce tableau affiche les PBI du sprint et l'avancement de leurs tâches.
Il est possible de changer l'état d'une tâche directement par drag and drop (en le faisant passer d'un état à un autre en respectant le workflow mis en place).
Sur chaque tâche, il est aussi possible de changer directement d'autres informations comme le travail restant et l'assignation (en cliquant sur la tâche, on ouvre sa fiche).
Il est aussi possible de grouper ou filtrer l'affichage du task board par membre de l'équipe, via le menu du haut.
VIII-B. Le Kanban board▲
À la différence du task board, le kanban board représente dans un tableau l'état d'avancement non pas des tâches, mais des PBI eux-mêmes.
L'accès au kanban board se fait par la page du backlog et en cliquant sur le lien « board » du menu du haut.
Sa gestion se fait comme le task board :
- les PBI passent d'un état à un autre par drag and drop ;
- l'assignation et l'estimation sont modifiables directement dessus.
Attention : le fait de déplacer un PBI de l'état « En cours » à « Fini » ne change pas l'état des tâches de ce PBI en « Fini », il faut le faire manuellement sur chaque tâche.
Depuis les dernières mises à jour de TFS, il est possible de customiser les colonnes, c'est-à-dire en rajouter, selon les états.
Pour cela, il faut cliquer sur le lien « customiser les colonnes ».
En cliquant sur les + on peut rajouter des états intermédiaires.
IX. Le reporting▲
Dans la méthodologie Scrum, le graphique principal (et le seul pour certain) est le Burndown chart (indicateur sur la charge restante) ou Updown chart (indicateur sur le travail déjà effectué).
Dans TFS, deux graphiques sont mis en avant dans le backlog :
- le burndown chart au niveau du sprint ;
- le cumulative flow chart sur le backlog.
IX-A. Le burndown chart▲
Dans un sprint, il est disponible dans la partie backlog en haut à droite, il apparaît en petit, mais on peut l'agrandir en cliquant dessus.
IX-B. Le cumulative flow chart▲
Il se situe sur le backlog, c'est un indicateur sur son avancement.
TFS possède tout un module de graphiques indépendant de la méthodologie utilisée, pour plus de détails voir ici
X. Conclusion▲
TFS depuis sa version 2010 possède toutes les fonctionnalités nécessaires pour la gestion d'un projet dans le cadre Scrum.
Plusieurs points n'ont pas été abordés dans cet article comme l'intégration continue ou le portfolio management, ils feront très certainement l'objet d'un autre article.
XI. Remerciements▲
Merci à Chtulus pour sa relecture ainsi qu'à Claude Leloup pour sa relecture et ses corrections.
