Vous avez décidé de franchir le pas et de travailler à l’aide d’une méthode agile ? Vous avez choisi la méthode eXtreme Programming ? Naturellement, la transition d’une méthode « classique » de gestion de projet vers l’eXtreme Programming ne se fait pas instantanément. Il faut du temps pour mettre en place de nouvelles méthodes de travail. Les automatismes ne viennent pas immédiatement. Il faut bien souvent changer les habitudes ancrées depuis des années et même vaincre quelques réticences. Mais même avec une équipe volontaire, il est bien souvent difficile de mesurer la progression des différents membres. Le « XP Radar Chart » est l’outil qui vous permettra de suivre l’évolution de l’acquisition de la méthode XP par l’équipe projet.
Utilité du « XP Radar Chart »
Comme son nom l’indique, le « XP Radar Chart » est un graphique de type radar permettant de mesurer l’état d’adoption des bonnes pratiques XP par l’équipe projet. Une fois que les bonnes pratiques XP sont acquises de manière durable, il est important de pouvoir accompagner l’ensemble de l’équipe à progresser encore au-delà, afin d’en tirer le meilleur.
Le graphique XP Radar Chart comporte cinq axes : « équipe », « programmation », « planification », « client » et « paire ». En attribuant une note à chaque axe, en la reportant sur le graphique, et en reliant les points, on obtient le radar. En fonction de la forme obtenue, il sera possible d’estimer l’état d’adoption de l’eXtreme Programming et de faire ressortir les axes d’améliorations.
Attribution des notes
Chaque axe est composé de plusieurs catégories. Chaque catégorie doit se voir attribuer une note pouvant être égale à 0 (mauvais), 1 (moyen) ou 2 (parfait). En additionnant le score de chaque catégorie, on obtient une valeur à reporter sur l’axe correspondant.
En fonction des cinq axes, les catégories sont les suivantes :
– Programmation :
o Programmation des tests en premier : on commence par écrire les tests unitaires avant le code en lui-même. De cette façon, la couverture de code est meilleure et chaque nouveau développement fait l’objet de tests unitaires qui pourront permettre par la suite de détecter les éventuelles anomalies générées par la modification d’une partie du code.
o Tests unitaires automatisés : l’ensemble des tests unitaires écrits pour le projet peuvent être exécutés de façon automatique. De cette façon, il est possible à chaque déploiement par exemple de vérifier que l’ensemble des tests unitaires passent avec succès. C’est une façon de s’assurer qu’il n’y a pas de régression.
o Conception simple : la conception est évaluée selon quatre critères de simplicité (le code est doté de tests unitaires et fonctionnels et tous ces tests passent, le code ne fait apparaître aucune duplication, le code fait apparaître séparément chaque responsabilité distincte, et le code contient le nombre minimum d’éléments (classes, méthodes, lignes) compatible avec les trois premiers critères). Globalement, les programmeurs ne doivent pas ajouter de fonctionnalité à moins qu’elle ne soit absolument nécessaire.
o Refactorisation : la refactorisation doit faire partie intégrante du cycle de développement. Chaque ligne de code doit apparaître une fois et une seule dans l’application.
– Planification :
o Le « planning game » : la planification des développements est décidée à l’aide d’un planning game, quel qu’il soit (il peut s’agir d’un poker planning game par exemple), à partir du moment où il permet d’obtenir des explications des fonctionnalités et une bonne communication entre les différents membres de l’équipe, et que les rôles du client, des dveloppeurs sont parfaitement définis.
o Livraisons fréquentes sur un périmètre restreint : des livraisons fréquentes sont effectuées très régulièrement afin d’être testées. Des livraisons plus complètes sont mises à disposition des utilisateurs tous les uns à trois mois.
o Des itérations courtes, voire très courtes : les itérations vont de quelques jours à quelques semaines (avec des livraisons quotidiennes en interne). Au terme d’une itération, une version est livrée au client pour des tests et la validation.
o Semaine de 40 heures : l’équipe ne compte pas ses heures pour maintenir la cadence de développement et de livraison. L’équipe reste suffisamment motivée et mobilisée pour assurer les livraisons dans les temps.
– Client :
o Le client est entièrement dédié au projet : il a pour principale responsabilité de s’impliquer dans le projet et dans l’équipe XP. Il ne travaille que sur ce projet et ne risque pas d’être distrait par d’autres responsabilités.
o Le client est sur site : l’équipe de développement XP et lui se trouvent physiquement dans les mêmes locaux. De cette façon, le client est toujours accessible et disponible pour travailler en collaboration étroite avec le reste de l’équipe XP. Les temps d’information et de décision sont ainsi réduits et l’efficacité de l’équipe dans sa globalité s’en trouve renforcée.
o Tests de recette automatisés : les tests de recette sont des tests fonctionnels permettant de valider le comportement d’une application au travers d’un scénario d’utilisation. Tout comme un test unitaire, un test fonctionnel a un résultat binaire. Soit il passe, soit il ne passe pas. L’automatisation des tests fonctionnels diminue grandement la phase de recette et augmente la fiabilité de la validation de l’application.
o Le client dirige les développements : le planning est flexible, et le client peut le modifier à tout moment en changeant la priorité de développement de certaines fonctionnalités.
– Paire :
o Programmation par paire (ou « pair programming ») : tous les développements sont faits par paire. Deux développeurs travaillent ensemble simultanément sur la même partie du code. L’un écrit le code pendant que l’autre le vérifie, apporte sa vision des choses, propose des améliorations. Régulièrement, les rôles sont échangés.
o Espace de travail partagé et ouvert : toute l’équipe est rassemblée dans une même pièce. De cette façon, la communication entre les différents membres de l’équipe est simplifiée.
o Code source commun : chaque paire de développeurs peut intervenir sur n’importe quelle partie du code source.
o Machine d’intégration : une machine est dédiée à l’intégration continue du code source produit.
– Equipe :
o Intégration continue : l’intégralité du code source produit est intégrée et testée au moins une fois par jour par chaque paire de développeurs.
o Tests unitaires maintenus à 100% : si la couverture du code ne peut pas atteindre 100%, en revanche, 100% des tests unitaires sont maintenus et mis à jour au fur et à mesure des développements, avec des refactorisations lorsque c’est nécessaire.
o Métaphores : les termes utilisés dans le projet et dans le code source doivent être compris de tous.
o Utilisation de standards de développement : tous les membres de l’équipe ont intégré et utilisent les standards de développement décidés et mis en place au début du projet.
Interprétation du graphique
Il y a de multiples raisons pour lesquelles l’équipe n’a pas encore tout à fait adopté XP. La lecture du graphique « XP Radar Chart » permet d’identifier les axes à améliorer.
XP dispersé
Les notes attribuées aux catégories « équipe », « programmation », « planification » et « client » sont bonnes. En revanche, la catégorie « paire » a un score faible.
Cela arrive généralement lorsque les membres de l’équipe essaient de travailler en XP mais qu’ils sont répartis dans différents locaux. La programmation par paire est rendue difficile et l’équipe est contrainte de compenser le manque de communication.
XP développeur seulement
Le score de « planification » est moyen et celui de « client » mauvais, tandis que les autres sont bons.
Les développeurs cherchent à adopter XP mais n’ont pas le support client, qui n’est pas sur place, ou pas suffisamment impliqué dans le projet. La planification s’en ressent donc et ne peut pas être optimale.
XP pour un seul développeur
Seules les catégories « équipe » et « programmation » sont bien notées.
Cela arrive sur les petits projets pour lesquels on souhaite appliquer XP, alors qu’il n’y a qu’un seul développeur. La programmation par paire est alors impossible et les autres dimensions en souffrent.
XP subversive
La catégorie « programmation » est bien notée alors que tous les autres axes de mesure ont de mauvais scores.
Cela arrive lorsqu’une personne fait partie d’une équipe développement, mais qu’elle est la seule à essayer d’appliquer XP. La seule catégorie sur laquelle elle peut avancer est donc la « programmation ». Les autres dimensions restent alors complètement vides. Ce développeur est le seul de l’équipe à suivre un standard de développement et à intégrer son code fréquemment.
Utilisation du graphique
L’analyse de la couverture du graphique permet de déterminer quels axes travailler afin d’améliorer l’intégration de l’eXtreme Programming à l’équipe et au projet scrum.
Toutes les dimensions sont à prendre en compte. La catégorie « programmation » permet de mettre en place les procédures de tests de l’application et l’amélioration continue au niveau du code. « Equipe » et « paire » sont là pour améliorer la communication au sein de l’équipe. Enfin, les axes « client » et « planification » amènent à une meilleure communication avec le client.
Si les résultats portés sur le graphique ne sont pas à prendre au pied de la lettre, ils fournissent néanmoins des pistes pour amener des améliorations quant au fonctionnement de l’équipe projet. La consultation du graphique amène chaque intervenant à se poser des questions sur ses pratiques et à faire des propositions d’amélioration. L’équipe va être en mesure de définir ce qui fonctionne plutôt bien et ce qui peut être amélioré, avec pour objectif de mettre en place des références XP et de les suivre.
=> Nutcache est l’outil de gestion de projet idéal pour votre projet agile. Testez-le gratuitement pendant 14 jours.
