Les 12 pratiques de XP (eXtreme Programming)
Les 12 pratiques de XP (eXtreme Programming)
La méthode XP s’appuie sur 12 pratiques.
Les 12 Pratiques XP
– Planning Game
– Petites Releases
– Utilisation de métaphores
– Conception simple
– Tests unitaires et tests unitaires (fonctionnels) / TDD (Test Driven Development)
– Refactoring
– Programmation en binôme
– Appropriation collective du code
– Intégration continue
– Pas de surcharge de travail
– Client sur site
– Standard de code (compréhension partagée)
Bien sûr il ne faut pas oublier les Tests Client qécoulent de ces 12 pratiques XP.
Planning Game
Cette pratique a pour but de planifier uniquement les releases. La planification se fait sous forme de jeu auquel participent les développeurs et le client. Pendant une première phase dite d’exploration, le client exprime ses besoins en termes de fonctionnalités. Pour cela, il les écrit sous forme de « user stories », c’est à dire sous forme de courtes descriptions du comportement qu’il attend du système, exprimées avec un point de vue utilisateur. Au cours de cette même phase, les développeurs attribuent à chaque user story un nombre de points, fonction du temps qu’ils estiment nécessaire au développe- ment des fonctionnalités contenues dans chaque user story. S’il s’avère que les user stories nécessitent un temps de développement trop long, elles sont découpées en scénarios élémentaires. Dans une deuxième phase dite d’engagement, les user stories sont triées en fonction de la valeur qu’elles apportent au client et des risques encourus lors de leur développement. Ceci permet d’aboutir à un classement des user stories par ordre de priorité. En fonction de la vélocité de l’équipe, les développeurs et le client s’entendent sur la quantités de user stories qui seront développées au cours de l’itération à venir et qui constitueront la prochaine release. La vélocité évoquée ci-dessus est un indicateur du nombre de points qui peuvent être développées au cours d’une itération (elle se calcule en faisant le rapport du nombre de points développés au cours de l’itération précédente et du produit du nombre de développeurs par la durée de l’itération). Enfin la phase de direction permet de mettre à jour le planning de la pro- chaine release. Cette pratique permet de combiner les priorités du client avec les estimations des développeurs afin de convenir du contenu de la prochaine release et de la date à laquelle elle devra être prête.
Petites Releases
Pour une bonne gestion des risques, la sortie des releases doit intervenir le plus souvent possible. En conséquence, d’une version à l’autre, l’évolution doit être la plus petite possible, tout en s’efforçant d’apporter le plus de valeur ajoutée et des fonctionnalités dans leur intégralité.
Cycles de développement courts (entre 1 et 4 semaines) pour livrer souvent, produire de la valeur ajoutée à chaque livraison, intégrer les nouvelles fonctionnalités de façon continue et obtenir un retour rapide sur le travail effectué pour corriger le tir très rapidement si quelque chose ne va pas.
Utilisation de métaphores
XP recommande d’utiliser des métaphores pour décrire l’architecture du système. De telles images permettent à tout le monde (y compris les commerciaux qui n’ont pas forcément de grandes compétences techniques) d’avoir une vision globale du système et d’en comprendre les éléments principaux ainsi que leurs interactions.
Conception simple
La simplicité est une des valeurs fondamentales d’XP. Il faut toujours développer la solution la plus simple possible et éviter de développer plus que ce dont on a besoin. Ceux qui pratiquent XP résument cela sous la phrase YAGNI (« You ain’t gonna need it », « vous n’en aurez pas besoin »). Les seules exigences sont de satisfaire tous les tests, de ne jamais dupliquer une logique et d’utiliser le moins possible de classes et de méthodes. Dans ce même ordre d’idées, la documentation produite lors d’un projet XP se réduit au minimum vital, c’est à dire la documentation demandée par le client.
Tests unitaires et tests unitaires (fonctionnels) / TDD (Test Driven Developpement)
Les tests unitaires sont écrits et effectués par les développeurs pour vérifier le bon fonctionnement et la non régression des méthodes ou des constructeurs. Pour une qualité de code encore meilleure, il est recommandé d’écrire les tests avant le code de l’application. Les tests fonctionnels sont conçus par le client et lui permettent d’une part de vérifier le fonctionnement global du système, de contrôler l’évolution du projet, et d’affiner l’expression de ses besoins.
Xp recommande l’utilisation de tests automatisés pour assurer la qualité et la stabilité du code produit.
TDD (Test Driven Development) :
Le TDD est une des composantes essentielles de XP car c’est elle en grande partie qui permet la mise en place et le maintient des tests automatisés. Le principe même du Test Driven Development est de commencer sa démarche d’écriture de programme par l’écriture des tests qui permettront de tester les fonctions à implémenter puis de mettre en place ces fonctions « pas à pas » en vérifiant toujours que les tests écrits pour la fonction « passent » (la fonction de test obtient le résultat attendu en utilisant le code fourni, l’aspect du code testé est implémenté et se comporte comme souhaité) une fois que ce qu’ils doivent tester a été implémenté. L’urgence absolue à traiter en priorité dans un tel type de développement est un test qui ne « passe » plus (régression) alors qu’auparavant il ne posait pas de problème. Résoudre le problème à la source de la régression est bien plus important que n’importe quoi d’autre dans un tel contexte.
Refactoring (remaniement) du code
Les développeurs d’un projet XP doivent s’habituer à retravailler un peu chaque jour du code existant et fonctionnant parfaitement pour le maintenir propre, le rendre plus lisible et plus robuste.
Le but de cette pratique est de simplifier le code, tout en faisant en sorte que tous les tests soient satisfaits. D’un point de vue purement fonctionnel, cette simplification n’est pas nécessaire puisqu’elle intervient sur du code qui fonctionne parfaitement. En revanche, le refactoring du code assure que l’ajout de fonctionnalités supplémentaires sera facilité. Le refactoring tend à produire un code mieux pensé, plus modulaire, sans duplications de code et donc plus facile à maintenir.
Xp prone le refactoring régulier pour assurer la qualité et la stabilité du code produit.
Le fait de livrer si régulièrement permet de toujours disposer d’une base « saine » de code au cas ou des changements seraient à inclure.
Programmation en binôme (Pair Programming)
Toute l’écriture du code se fait à deux personnes sur une même machine, avec une seule souris et un seul clavier. On distingue deux rôles : le pilote (« driver »), celui qui a le clavier, cherche la meilleure approche sur une portion de code bien précise tandis que l’autre développeur, le « partner » peut observer avec beaucoup plus de recul et ainsi suggérer d’autres solutions ou soulever des problèmes d’ordre plus général. Au premier abord, cette pratique peut sembler être une perte de temps, mais il s’avère que le travail se fait plus vite, que le code est de meilleure qualité (moins d’erreurs de syntaxe, meilleur découpage, etc.), avec une meilleure compréhension du problème.
Pour les développeurs, le travail est moins fatiguant. Les binômes ne doivent pas être statiques : chacun change de partenaire relativement souvent. Ceci pour un meilleur partage des connaissances et pour permettre à chacun d’avoir une relativement bonne vision sur l’ensemble du code.
Travail en binômes (« deux cerveaux mais un clavier »), pour éviter les erreurs et favoriser l’amélioration continue et la maintenabilité d’une application (si deux personnes ont travaillé sur une portion très particulière de code et qu’une s’en va, il en reste toujours une qui sait très bien de quoi le code parle sans avoir à le reparcourir). Le pair programming est aussi utile en ce sens que les 2 personnes qui travaillent sur un même « bout de code » ne réfléchissent pas aux mêmes choses selon qu’elles sont au clavier ou pas. La personne au clavier va avoir tendance à se concentrer sur le « comment » (aspects purements techniques) et son binôme sur le « pourquoi » (voir l’image d’ensemble et empêcher son binôme de dévier).
Appropriation collective du code
Toute l’équipe est sensée connaître la totalité du code (plus ou moins dans le détail selon les parties, évidemment). Cela implique que tout le monde peut intervenir pour faire des ajouts ou des modifications sur une portion de code qu’il n’a pas écrit lui même si cela s’avère nécessaire.
Intégration continue
Après chaque fin de tâche, c’est à dire plusieurs fois par jour, le code nouvellement écrit doit être intégré à l’existant de manière à avoir à tout moment un existant fonctionnel qui passe avec succès tous les tests. Ainsi, quand une tâche est démarrée, elle peut se fonder sur la version la plus à jour de ce qui a déjà été fait.
Pas de surcharge de travail
L’objectif est de ne pas dépasser 40 heures de travail par semaine pour les développeurs. Il ne s’agit pas de chercher à travailler peu, mais les spécialistes d’ eXtreme Programming ont pris conscience du fait que la surcharge de travail, en plus d’être désagréable, est néfaste. En effet, le code devient moins bien pensé, le refactoring est laissé de côté, ce qui conduit à une baisse de la qualité et à une recrudescence des bugs. En vertu de ce principe, une équipe ne doit jamais être surchargée de travail plus de deux semaines consécutives. Si cela devait toutefois se produire, l’équipe se doit de réagir en redéfinissant la quantité de user stories à implémenter au cours de l’itération ou en modifiant sa manière de procéder.
Client sur site
L’implication forte du client passe par la présence sur site d’une personne minimum à temps plein pendant toute la durée du projet. Cette personne doit avoir à la fois le profil type de l’utilisateur final et une vision plus globale du contexte pour pouvoir préciser les besoins, leur donner une ordre de priorité, les transcrire sous forme de user stories, et établir les tests fonctionnels. La présence du client sur site est dictée par des impératifs en matière de réactivité. En effet, au fil de la programmation, les développeurs soulèvent fréquemment des questions sur des points non abordés ou restés obscurs. En étant sur place, le client peut ainsi apporter immédiatement des réponses à ces questions, évitant ainsi que les programmeurs commencent à développer certaines fonctionnalités sur la base de ce qu’ils supposent être les désirs du client. La présence à temps plein du client sur site n’implique pas forcément que cette activité occupe la totalité de son temps : il est tout à fait envisageable pour le client de continuer une partie de son activité tout en étant délocalisé auprès de l’équipe de développeurs.
Standard de code (compréhension partagée)
Il est nécessaire de disposer de normes de nommage et de programmation pour que chacun puisse lire et comprendre facilement le code produit par les autres. Ceci est d’autant plus essentiel que la propriété du code est collective et que les programmeurs sont amenés à changer de binôme régulièrement. En général, les conventions adoptées lors des projets XP sont assez intuitives et résultent de pratiques plutôt naturelles chez les développeurs.
Mise en pratique :
– Conventions de nommage
– Appropriation collective du code
– Conception simple
– Utilisation de métaphores
Justification des pratiques XP
Voici donc les 12 pratiques XP. Chacune d’entre elle est suivie d’une justification provenant de la définition de Kent Beck :
1. Le jeu de planification permet à toutes les personnes impliquées dans le projet de prendre des décisions. En plus, cela sert à la création d’une planification de livraison.
2. La livraison constante de petites versions permet d’obtenir les réactions de la part du client et influence le développement du système pour qu’il ne prenne pas une mauvaise tangente.
3. Les métaphores set à avoir un vocabulaire commun et une vue d’ensemble du système à développer.
4. La conception simple favorise la capacité de compréhension et de modification du code.
5. Les tests unitaires et de régressions sont plus importants que la documentation et doivent être fait avant l’implémentation du code.
6. L’amélioration constante du code simplifie et rend les modifications futures de plus en plus facile à maintenir.
7. La programmation en paire permet de repérer les erreurs tôt dans le cycle de vie de développement du logiciel.
8. La propriété collective consiste à dire que le code appartient à tout le monde et que chaque développeur est responsable du bon fonctionnement du code.
9. Une intégration continuelle doit se faire. De préférence, plusieurs fois par jours et en roulant tous les tests unitaires à chaque itération.
10. Un horaire de 40 heures par semaine permet une bonne condition physique et mentale.
11. Le client doit être sur le site où être disponible en tout temps pour permettre aux développeurs d’avoir des réponses à toutes leurs questions. Cela permet aussi de résoudre les incompréhensions.
12. Des standards de code doivent exister et ils doivent mettre l’emphase sur la communication au sein de l’équipe.
XP utilise les « best practices » et tente de les mettre en pratique. Travailler avec une telle méthodologie permet de mettre l’emphase sur les développeurs et sur le code source.
Leave a Reply
You must be logged in to post a comment.