eXtreme Programming

Tout, tout, vous saurez tout sur l'eXtreme Programming

Agile History X

Grande sœur de la méthodologie Scrum, l’ eXtreme Programming fut imaginée et développée au sein de la société américaine Chrysler durant les années 90. Trois ingénieurs informatiques, répondant aux noms de Kent Beck, Ward Cunningham et Ron Jeffries, ont inventée l’XP lors de leur travail sur le projet « C3 » visant à faciliter le calcul des rémunérations chez le fabricant automobile. 

Le premier de ces génies affinera la méthode en tant que chef de projet en mars 1996 avant qu’elle ne soit livrée au développeurs et ingénieurs du monde entier en 1999 avec le livre Extreme Programming Explained, du même auteur (Kent Beck). 

Etymologie

Comme son nom l’indique, l’eXtreme Programming résulte d’une méthode de gestion de projet visant à adapter « à l’extrême » les différents principes du développement Agile

Pour qui, pourquoi ?

L’ensemble de l’équipe projet ainsi que le Product Owner (client) sont au cœur de la matrice fonctionnelle puisque la communication entre les différentes parties prenantes du projet est la clé de voûte du bon fonctionnement de l’XP. L’avantage premier de l’XP est d’être adaptable à tous types de projets, peu importe la culture d’entreprise, le poids du projet ou le secteur. 

La méthode Agile XP est très utile au bon fonctionnement d’un projet puisqu’elle consiste en l’identification de l’ensemble des éléments essentiels d’un projet tout en exerçant un focus poussé lors des phases itératives de développements et des tests successifs (unitaires ou non).

L'apport X de la méthodologie XP

Qualifiée d’extrême par l’attention que les porteurs de projets doivent lui apporter quotidiennement, l’XP nécessite une prise en compte de plusieurs éléments essentiels : 

  • Une compréhension parfaite et globale du projet par TOUTES les parties prenantes : développeurs, Product Owner, utilisateurs. 
  • La simplicité est la clé de la réussite. Lors d’un questionnement, la solution la plus simple doit impérativement être choisie. 
  • Toutes les modifications apportées doivent être publiées rapidement de façon à ce que chacun puisse avancer de son côté et apporter ses propres modifications nécessaires au bon déroulement du projet. 
  • À chaque étape terminale, les phases tests devront être itératives et surtout obligatoires ! 
  • Ici aussi, le rôle du client est primordial. Ce dernier doit en effet définir précisément les différentes étapes qu’il attend. Ces étapes ou « histoires » appelées « User Stories » correspondent aux différentes phases de tests qui sont rendus sous format livrable toutes les deux semaines environ.

Principe & fonctionnement

Globalement semblables aux principes des autres méthodes Agiles, ceux de la méthode XP sont différents dans l’attention portée à chaque détail et déterminé par cinq valeurs essentielles : 

  1. La communication : résoudre les problèmes passe forcément par une communication entre tous les acteurs du projet. Le client est par ailleurs l’un des éléments clé à la réussite du projet et doit être tenu au courant de chaque avancée.

     

  2. La simplicité : il faut toujours se limiter aux solutions les plus simples et ne pas chercher à rajouter trop d’éléments qui ne sont pas nécessaires au développement du projet. 

     

  3. La remise en question : le fait de travailler en groupe restreint intime une solidité mentale des équipes et des individualités. Lors d’un travail en petit comité, le fait de braver les épreuves à plusieurs va aussi amener chacun à retravailler ses méthodes et à améliorer plusieurs fois son travail. 

     

  4. La tolérance : qui dit travail en groupe dit forcément respect et tolérance des capacités de chacun de ses collègues, des managers et du client. 

     

  5. Les feedbacks : les échanges mutuels entre le client et l’équipe technique est essentiel au bon déroulé du projet. Chaque étape doit être envoyé au plus vite au client afin que les tests exécutés permettent les modifications nécessaires. 

Ces cinq valeurs se déclinent ensuite en treize pratiques communément admises et interdépendantes : 

  1. Présence continuelle du client : dans une optique de coordination, la présence assurée du client sur place est essentielle afin de lui faire part de toute modification éventuelle et lui laisser une réactivité importante pour les phases de tests.
  2. Planning Poker : le client créé les scénarios nécessaires à la bonne compréhension des fonctionnalités demandées. S’ensuite l’étape collective d’estimation du temps à accorder à chaque étape. (Cf. article : Planning Poker, véritable pratique ou coup de bluff ?)
  3. Intégration continue : tâche terminée = intégration dans le produit complet. L’intérêt ici est de limiter la charge de travail lorsque la finalisation du projet est proche. Les nombreux tests permettent cette intégration continue.
  4. Livraisons récurrentes : le client doit rester sans cesse sur place et donc se voir donner les livrables de façon régulière et constante. Une fois l’avis donné, les modifications peuvent être instantanément effectuées.
  5. Rythme adéquat : en partant du postulat que la qualité est primordiale et que la simplicité est ici une méthode de travail, aucune heure supplémentaire ne doit être tolérée afin de ne pas cumuler trop de fatigue.
  6. Tests fonctionnels : une fois les user stories définit par le client, des tests sont effectués afin de vérifier l’avancée du projet. Si tous les tests sont passés, l’itération est terminée.
  7. Tests unitaires : chaque fonctionnalité doit être validée par un test. Ces codes seront ainsi lancés automatiquement à chaque nouvelle implémentation ou modification de chacune des fonctionnalités. 
  8. Conception simplifiée : seuls les besoins du client doivent être réalisés. En se rendant à l’essentiel dès le début du projet, plus l’implémentation des modifications sera facilement réalisable.
  9. Clarification par la métaphorisation : le langage utilisé doit être commun à tous : développeurs, managers, client. Or, le client n’est pas forcément un ingénieur informatique mais doit être mis au courant de toutes les avancées. Afin qu’il les comprenne, les développeurs doivent utiliser des métaphores comprises de toutes les parties prenantes du projet.
  10. Refactoring : Pour optimiser à la fois le rendu et les conditions de travail de chacun des acteurs du projet, le projet doit être amené à évoluer régulièrement. Le remaniement du projet, ou « refactoring » est l’un des éléments principaux de la réussite d’un projet via l’eXtreme Programming.
  11. Appropriation commune du projet : n’importe lequel des membres de l’équipe doit être autorisée à modifier les parties du projet qu’il n’a pas pour habitude de traiter. Si le dialogue est important, la remise en question et le fait de faire partie d’un projet commun via la multiplicité des tâches est tout aussi essentiel.
  12. Standards de langage : ce point rejoint celui de la clarification par les métaphores puisqu’il intime le fait que le vocabulaire utilisé doit être compréhensible du plus grand nombre.
  13. Pair Programming (travail en binôme) : Avez-vous déjà vu un pilote sans co-pilote ? Afin d’avoir une meilleure vision d’ensemble, chaque collaborateur travaille avec un binôme. Les rôles doivent être régulièrement inversés afin de ne pas bloquer la motivation de l’un ou l’autre des collaborateurs. 

Conclusion

Si elle présente de nombreux avantages, cette méthode ne peut fonctionner que dans les groupes motivés et surtout respectueux de leurs objectifs et de leurs comparses. La répétition des tâches et la rapidité d’exécution des tests et des rendus livrables fait que la pression peut parfois faire craquer certains des collaborateurs. Aussi, l’importance d’une cohésion de groupe et d’une solidarité à tous niveaux est primordiale à l’aboutissement du projet. 

Notez cet article
0/5

Vous aimerez aussi...

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *