Les principes de base de XP (eXtreme Programming)
Les principes de base de XP (eXtreme Programming)
Les principes de base de la méthode XP sont :
– Feedback rapide
– Assumer la simplicité
– Changements incrémentaux
– Accueillir le changement à bras ouverts
– Un travail de qualité
– Apprendre à apprendre
– Faible investissement au départ
– Jouer pour gagner
– Communication ouverte et honnête
– Travailler avec et non contre les instincts de chacun
– Responsabilités acceptées
– Adaptation aux conditions locales
– Voyager léger
– Mesures honnêtes
Feedback rapide
L’idée de base est issue de la psychologie de l’apprentissage : plus le retour suit de près une action, plus l’apprentissage qui en résulte est important. C’est pour utiliser au mieux cette caractéristique qu’eXtreme Programming préconise des itérations de courte durée et l’implication forte du client. Un retour rapide pour le développeur permet une correction ou un changement de direction plus rapide et un retour rapide vers le client lui permet de tester en permanence l’adéquation du système à ses besoins et au marché.
Assumer la simplicité
XP recommande de traiter tous les problèmes par la solution la plus simple possible, partant du principe qu’un travail propre, simple et minimal aujourd’hui est facile à améliorer par la suite.
Changements incrémentaux
Une série de petits changements progressifs est toujours bien plus sûre et bien plus efficace qu’un grand chambardement. Ceci est valable à plusieurs niveaux : dans un projet XP, l’architecture et la conception changent petit à petit, de même que le planning et la composition de l’équipe.
Accueillir le changement à bras ouverts
La meilleure stratégie est celle qui préserve le maximum d’options tout en apportant une solution aux problèmes les plus urgents.
Un travail de qualité
Parmi les quatre variables qui définissent un projet : taille, coûts, délais et qualité, la qualité n’est pas vraiment indépendante. Pour la réussite d’un projet, la qualité ne peut qu’être « excellente » si chacun aime le travail qu’il fait.
Apprendre à apprendre
Plutôt que de s’en remettre à des théories ou des idées reçues pour répondre aux questions comme : quelle quantité de tests est nécessaire ? combien de temps dois-je passer à retravailler et améliorer le code que j’ai écrit ? etc., mieux vaut apprendre à chacun à apprendre par soi même en fonction de chaque projet.
Faible investissement au départ
Allouer peu de ressources à un projet au départ force les clients et les développeurs à aller à l’essentiel et à dégager ce qui est réellement prioritaire et porteur de valeur.
Jouer pour gagner
L’état d’esprit dans lequel doit se placer une équipe XP peut être comparée à celui d’une équipe de rugby ou de basket : jouer pour gagner et non pour éviter de perdre.
Communication ouverte et honnête
Toute décision abstraite doit être testée. Dans cet ordre d’idée, le résultat d’une séance de conception ne doit pas être un modèle finalisé un peu parachuté, mais une série de solutions évoquées au cours de la séance. Il est essentiel que chacun puisse dire sans peur qu’une partie de code n’est pas optimale, qu’il a besoin d’aide, etc.
Travailler avec et non contre les instincts de chacun
Les gens aiment réussir, apprendre, interagir avec d’autres, faire partie d’une équipe, avoir le contrôle des choses. Les gens aiment qu’on leur fasse confiance. Les gens aiment faire un travail de qualité et voir leurs applications fonctionner. XP cherche à offrir à chacun des moyens d’exprimer ces qualités au cours du projet
Responsabilités acceptées
Il est nécessaire de donner à chacun la possibilité de prendre des responsabilités (par exemple, les développeurs se répartissent eux mêmes les tâches sur la base du volontariat). Cela permet d’éviter les frustrations dans le cas où les responsabilités sont imposées et non délibérément choisies.
Adaptation aux conditions locales
Adopter XP ne signifie pas prendre à lettre la méthode mais intégrer ses principes pour l’adapter aux conditions particulières de chaque projet.
Voyager léger
Un développeur a tendance à transporter beaucoup de choses inutiles. Un débat est soulevé à ce sujet à propos des règles de nommage. Si certaines sont utiles et même indispensables, d’autres sont probablement des contraintes inutiles ou non respectées. Les simplifier pour ne garder que celles qui sont essentielles et utilisées par tous, c’est voyager plus léger.
Mesures honnêtes
La volonté de contrôler le déroulement d’un projet conduit a évaluer, mesurer certains paramètres. Il faut toutefois savoir rester à un niveau de détail pertinent. Par exemple, il vaut mieux dire « cela prendra plus ou moins deux se- maines » que de dire « cela prendra 14 176 heures ».
Leave a Reply
You must be logged in to post a comment.