Programmation XP/Pratiques

Programmation | XP

Introduction - Valeurs - Pratiques - Rôles

Pratiques

La programmation comme discipline collective

Tout en mettant l'accent sur les bonnes pratiques de programmation, XP préconise un déroulement par itération courte et géré collectivement, avec une implication constante du client. Il en découle une redéfinition de la relation entre client et fournisseur, avec de surprenants résultats en termes de qualité de code, de délais et de satisfaction de la demande du client.

Le cycle de l'Extreme Programming

Le cycle de développement XP

Une méthode agile

Valeurs

L'Extreme Programming repose sur 4 valeurs fondamentales :

• La communication : C'est le moyen fondamental d'éviter les erreurs. Le moyen à privilégier est la conversation directe, en face à face. Les moyens écrits ne sont que des supports et des moyens de mémorisation.
• Le courage : Il est nécessaire à tous les niveaux et de la part de tous les intervenants, notamment chez les développeurs (quand des changements surviennent à un stade avancé du projet, ou quand des défauts apparaissent) et chez le client (qui doit pouvoir prioriser ses demandes).
• Le retour d'information : Les itérations sont basées sur les retours d'informations du client, permettant une adéquation totale entre l'application finale et sa demande.
• La simplicité : En Extreme Programming, la façon la plus simple d'arriver à un résultat est la meilleure. Prévoir préalablement des évolutions futures n'a pas de sens. Ce principe est résumé en une phrase : "Tu n'en auras pas besoin." (en anglais "You ain't gonna need it."). La meilleure manière de rendre une application extensible est de la rendre aussi simple (et donc simple à comprendre) et bien conçue que possible.

Pratiques

Ces 4 valeurs se déclinent en 13 pratiques :

• Un représentant du client sur site : Afin d'assurer une meilleure réactivité et un feed-back rapide, un représentant du client doit être présent pendant toute la durée du projet. Ce représentant doit avoir les connaissances d'un utilisateur final, mais en même temps une vision globale du résultat à obtenir.
• Planning game : Le client créé des scenarii d'utilisation, en les priorisant. Ces scenarii seront ensuite implémentés par l'équipe de développement. Le projet est considéré comme achevé quand le client n'est plus en mesure de trouver de nouveau scénario.
• Intégration continue : L'intégralité de ce qui est développé est assemblée à chaque fois qu'une tâche est terminée, ce qui permet d'avoir toujours une version à jour, notamment comme livrable ou pour le démarrage de nouvelles tâches.
• Release fréquente : Les livraisons doivent être les plus fréquentes possibles, afin d'obtenir un feed-back le plus rapidement possible, tout en offrant des fonctionnalités complètes. La fréquence de livraison est donc de quelques semaines
• Rythme soutenable : Afin d'éviter de surcharger l'équipe, elle ne fait pas d'heures supplémentaires deux semaines de suite. Si le cas se présentait, cela signifierait qu'il faut redéfinir le planning.
• Tests de recette : À partir de critères définis par le client, on crée des procédures de test, souvent automatisées, qui permettent de vérifier fréquemment le bon fonctionnement de l'application.
• Tests unitaires : Des procédures de test automatisées pour toutes les classes, méthodes et tous les autres codes-source.
• Conception simple : L'objectif est de produire une application qui réponde aux attentes du client. Mieux vaut donc arriver à ce résultat de la manière la plus simple possible, afin de faciliter les évolutions futures en rendant le compte simple à comprendre et facile à modifier. De même, la documentation doit être minimale, c'est-à-dire ce qui est demandé par le client.
• Utilisation de métaphores : On utilise des métaphores et des analogies pour décrire le système et son fonctionnement, ce qui permet de le rendre compréhensible par les non-informaticiens, comme les utilisateurs ou les commerciaux.
• Refactoring du code : Amélioration continue de la qualité du code sans en modifier le comportement (commentaire du code, respect des règles de nommage, simplification, etc).
• Convention de nommage : Dans l'optique d'appropriation collective du code et de facilitation de la communication, il est indispensable d'établir et de respecter des normes de nommage pour les variables, méthodes, objets, classes, fichiers, etc.
• Programmation en binôme : La programmation se fait par deux. Le premier, appelé driver, a le clavier. C'est lui qui va travailler sur la portion de code à écrire. Le second, appelé partner, est là pour l'aider, en suggérant de nouvelles possibilités ou en décelant d'éventuels problèmes. Les développeurs changent fréquemment de partenaires, ce qui permet d'améliorer la connaissance collective de l'application et d'améliorer la communication au sein de l'équipe

• Appropriation collective du code : L'équipe est collectivement responsable de l'application et est supposée connaître l'intégralité du code. Chacun peut également faire des modifications dans toutes les portions du code, même celles qu'il n'a pas écrit.

Autres principes

• Ne pas ajouter de fonctionnalités plus tôt que prévu
• N'optimiser qu'à la toute fin

Cette méthode s'appuie sur :

• une forte réactivité au changement des besoins du client
• un travail d'équipe
• la qualité du code
• la qualité des tests effectués au plus tôt