Animateur : EXAKIS (Centre de Compétence TFS)
Qu’est-ce qu’une méthodologie ?
- un ensemble de règles pour mettre en relation l’équipe projet
- un ensemble de normes et de références
- un workflow entre des exigences, des tâches, des bugs …
- des indicateurs de pilotage.
Dans Team System, deux méthodologies standard ont été implémentées :
- Microsoft Solution Framework (MSF) pour Agile Software Development (idéale pour les équipes petites et moyennes : jusqu’à 10 personnes)
- CMMI (pour les gros projets)
La suite VSTS peut se voir comme un ensemble de poupées russes imbriquées les unes dans les autres :
1. gestion documentaire et rapports : à destination de la maîtrise d’ouvrage
2. gestion des work items par le chef de projet technique
3. contrôleur de source et serveur de build : pour les développeurs
4. outils avancés de la suite comme analyse de code, tests unitaires, tests web, tests de charge, pour les architectes et testeurs.
La suite VSTS permet d’instrumenter toutes les étapes de la vie du projet dans un seul outil :
- choix et paramétrage de la méthodologie,
- définition des zones (conception base de donnée, écriture procédures stockées, développement classes, IHM, …) et des itérations (sur 1 mois maximum)
- gestion des work items (exigence, tâche, bug)
- requêtes et vues de work items
- rapports
- portail et espace documentaire
Par exemple, dans la méthode Agile fournie par Microsoft en standard, les work items sont rattachées à une personne (la granularité des tâches est suffisamment petite), à une zone (par exemple : procédure stockée), et ont un état (par exemple : actif).
Bien entendu, la méthode standard peut se customiser sans difficulté (à condition, toutefois, de le faire avant le démarrage du projet, et non pas en plein milieu !) à l’aide du Process Template Editor. L’impact des modifications effectuées n’est pas le même selon les catégories d’items :
- Modification des work items (par le Process Template Editor) : impact très fort. Le mieux est d’effectuer la customisation avant le premier projet. Bénéfice attendu : intégration optimale des termes et processus déjà utilisés au sein de l’organisation.
- Modification des requêtes : impact faible, et peu compliqué à mettre en œuvre.
- Modification des rapports : difficile, les rapports étant associés à OLAP, il faut une bonne connaissance d’OLAP et du cube TeamSystem. Il est préférable, a priori, de conserver les rapports standards, qui sont assez nombreux.
- Modification du portail : connaître SharePoint est indispensable. Permet un respect des normes de documentations en vigueur dans l’organisation.
Quelques démos nous sont présentées.
Utilisation du Process Template Editor pour personnaliser les work items.
En standard, la méthodologie MSF Agile structure les work items en :
- Scénarios
- Risque
- Qualité
- Tâche
- Bug
L’éditeur permet de personnaliser le nom, les champs associés, le workflow (par défaut, seulement deux états : actif/fermé) et l’IHM.
En ce qui concerne les rapports, il suffit de garder à l’esprit que les work items, qu’ils soient saisis dans Excel ou le Team Explorer, sont ensuite publiés dans la base de données de TFS et archivés dans le DataWarehouse. Pour créer un nouveau rapport, il faut ouvrir un projet de type Report Server (ou importer un rapport existant et le modifier). Quant à comprendre le cube OLAP de TFS, il faut s’y plonger avec le SQL Management Studio. Le plus simple reste tout de même Excel et ses tableaux croisés dynamiques.
Quant au portail, rien n’est plus facile que de lui ajouter des documents.
La gestion des rôles dans TFS est liée directement à l’Active Directory. Elle s’applique aux actions sur les work items (un développeur, par exemple, ne pourrait pas clore une tâche), mais les rôles ne peuvent pas être aujourd’hui utilisé pour l’IHM (on ne peut pas masquer certaines tâches à certains rôles, par exemple).
Enfin, TFS n’est pas MS Project : il ne connaît pas la notion de coûts (il gère les charges uniquement).
Commentaires