Agile/ExtremeProgramming

Un article de Agora2ia.


xp.gif


La présentation que je vais faire d’XP ici, est basée tant sur mes lectures que sur mon expérience. J’ai en effet eut la chance de faire partie successivement de deux équipes de 8 développeurs en moyenne qui ont pleinement travaillé en XP :

  • la première sur une application de supervision ferroviaire en C++ pour un projet de train à grande vitesse,
  • la seconde pour des applications de gestion de titres dans une société d’assurance française dans les technologies Java/J2EE.


Sommaire

Présentation

XP a été mise au point par "trois mousquetaires", et pas des moindres: KentBeck, WardCunningham et RonJeffries, durant un projet de facturation chez Chrysler, le "Chrysler Comprehensive Compensation System ou C3. Kent Beck en devient le chef de projet en 1996, redéfinie la méthodologie du projet en raison des mauvais résultats, commence à la formaliser et en Octobre 1999 "Extreme Programming Explained" est publié. En effet, XP qui, en tant que méthode agile, repose sur l'apprentissage, l'empirisme, est donc née de l'Expérience.


Dés sa naissance, XP s'est voulue simple, dépouillée. Il s'agit d'un regroupement de "seulement" 13 pratiques qui, comme la plupart du temps pour les méthodes Agiles, tiennent du bon sens : XP n'a rien inventé, elle ne fait qu'associer un ensemble de pratiques "vitales" et complémentaires mais préexistantes.


On peut donc résumer XP et ses pratiques sur un post-it. Cela permet souvent à ses détracteurs d'argumenter que XP est une méthodologie simpliste, qui ne permet pas de couvrir l'ensemble des problématiques que l'on peut rencontrer dans le développement logiciel et, à fortiori, est incapable d'amener un projet à terme en tenant les délais et les objectifs.


XP est une méthodologie qui s'intègre dans un mouvement plus global dit Agile. L'objectif des MéthodeAgiles, Scrum ou XP pour les plus connues, est de se focaliser sur les besoins du clients, et de considérer le changement comme une composante entière du développement logiciel. Pour que cela fonctionne, les deux parties doivent s'investir dans un contrat gagnant-gagnant...


En tant que méthode Agiles, XP est basée sur un processus itératif et incrémental. Pour bien différencier ces deux notions clefs, je vous renvoie à l'excellent article de Stéphane sur Itératif ET Incrémental.

Le projet, itératif, est donc une succession d'itérations de durée constante. Mais cette durée qui doit être appropriée au projet (taille, complexité, domaine métier...) : on choisira une longueur de 1 à 4 semaine, 2 semaine étant souvent un bon compromis (par expérience). Le but est en effet d'être capable de livrer un bout de logiciel, pertinent et fonctionnel, en une itération.

En plus d'être itératif, XP est incrémental. Cela veut dire qu'à la fin de chaque itération, le morceau d'application livré est pourvu de quelques fonctionnalités supplémentaires.

Pour savoir quelles sont les ces fonctionnalités que l'on va ajouter dans l'itération à venir, chaque itération commence par un planning game. Le client y présente les scénarios à réaliser, et l’équipe découpe chaque scénario en tâches et évalue la durée de chacune de ces tâches.

Puis les développements peuvent reprendre. Quand on réalise une fonctionnalité, on commence par écrire le(s) test(s) release associé. Ensuite, on peut réaliser les tâches. Pour cela, chaque matin, au stand-up meeting, on définit les binômes pour la journée et cherche à identifier les éventuels problèmes qui pourraient empêcher la livraison en fin d’itération.


Tels sont les événements qui rythment la vie d'un projet XP... Mais afin d'assurer au quotidien un bon fonctionnement, et le cas échéant de garantir la remonté le plus tôt possible de tout dysfonctionnement, XP vient avec des valeurs, qui se déclinent concrètement en 13 pratiques. XP défini également quelques rôles clefs afin de répartir les rares fonctions qui se sont pas (encore) partagées et maîtrisées par l'équipe... Cette présentation repose sur la première version, épurée, d’XP. Elle serait donc incomplette si je n’abordais pas "La Seconde version d'XP"...

Pages Connexes


La seconde edition d'XP


Les 4 valeurs

Cf. ValeurXp


Pour fonctionner, XP nécessite 4 éléments fondamentaux identifiés par KentBeck, qui doivent absolument se retrouver dans chaque membre de l'équipe pour un développement logiciel réussi. Ces valeurs sont des lignes de conduite pour le développement logiciel, et l’inspiration de la méthodologie dans son ensemble…


La communication

La plupart des problèmes qui surviennent sur un projet sont issus d’un manque de communication. Cette « vérité est tellement vraie » que cette valeur sort du cadre XP et se retrouve dans bien des formations à la gestion de projet en particulier, et au management en général.


La communication doit donc être valorisée, voire maximisée, aussi bien horizontalement que verticalement : tant entre les membres de l’équipe, qu’entre l’équipe et le client. Pour cela, chacune de ces deux dimensions est déclinée en pratiques :

  • « Client sur site» et « Livraisons fréquentes » pour la communication avec le client
  • « Programmation en binôme » pour la communication entre membre de l’équipe
  • « Planning game » et « Stand up meeting » pour les deux cas.


Mais que veux dire « optimiser la communication entre des personnes » ? En quoi consiste cet effort incessant ?...

La Connaissance, explicite ou tacite, doit se transmettre oralement : elle doit passer directement de la tête au code.

Par écrit, la connaissance est plus facilement altérée, désynchronisée.

Par oral, associée au courage, cette connaissance sera précisée, affinée voire complétée. Dans tous les cas elle sera instantanée.


On pourrait même rajouter une troisième dimension à la communication : entre les membres de l’équipe et les artéfacts du projet, à savoir tout ce qui est produit par l’équipe.

Dans ce cas, une bonne communication est synonyme d’artéfacts « facilement lisibles » et à jour !

Là encore, cela se décline en pratiques : l'« Intégration continue », les « Tests (recette et unitaires) », la « Conception simple », la « Métaphore ».

Un bon moyen de lutter contre des artéfacts non à jour, périmés, est de favoriser la capture de connaissance métier en code source, et non en document dans son outil de bureautique favori : un document texte aura plutôt tendance à croître avec le temps, et avec lui les portions de texte non relues/validées.

Le retour d'information ou feed back

L’objectif premier des méthodes agiles, est de se focaliser sur le besoin du client : le logiciel. Il est donc important dans cet état d’esprit de pouvoir interroger celui qui est le mieux renseigné sur le véritable état du logiciel : à savoir le logiciel lui-même. Cela afin de pouvoir mesurer à quelle distance on est de l’état final, et identifier au plus tôt toute digression.


Il faut valider ce qui a été fait, rapidement et donc fréquemment. Cela permet de faire évoluer l'existant avec confiance et assurance, ou dans le cas contraire d'identifier une erreur au plus tôt, afin de remonter facilement à son origine, et donc faciliter sa correction.


Les feedbacks importants sont ceux attachés aux trois dimensions de la Communication identifiées ci-dessus : entre membres de l’équipe, avec le client et avec les artéfacts.

En fait, feedback et communication sont intimement liés. Il faut communiquer afin d'obtenir un feedback. Les résultats de ce feeback peuvent ensuite alimenter d’autres communications...


Basée sur ce principe, on retrouve dans les projets XP une autre notion : les « Big visible charts ». L'idée est d'afficher de grands graphiques, régulièrement mise à jour, basés sur une des métriques, rapidement compréhensibles. Le but est de mettre en relief d'éventuel problème et, le cas échéant, de favoriser l'implication, la compétition saine.


Le feedback permet également de faire émerger et de maintenir de la Simplicité.

Un bon moyen de générer et de conserver de la Simplicité est d’avoir une approche empirique : j’essaye, puis je corrige mes erreurs. C'est le principe même du TestDrivenDevelopment, où :

  • Le test unitaire est l’essai,
  • Le test qui échoue est l’erreur et,
  • Le développement de la classe testée est la correction.

Or, pour que cela fonctionne il faut un feedback fréquent, pour ne pas dire permanent. Et, plus le système est simple, plus il est facile d’obtenir du feedback : nous voilà enfermer dans un « cercle judicieux »…

La simplicité

Do the simplest thing that could possibly work.

La conception, l'architecture et les développements doivent être simple, et constamment simplifiés.


Antoine de Saint-Exupéry semblait partager cette approche : "La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever".


Cela facilite l'assimilation pour tout nouveau développeur, et la réalisation des évolutions et modifications à venir.


En réduisant le code, la Simplicité en accroît la qualité et favorise la Communication.


Une bonne ligne de conduite est de « ne pas tirer de plans sur la comète » : on ne développe pas de fonctionnalité non demandée, non nécessaire, ou facilitant la réutilisation, aussi géniale soit-elle ! Si le système est simple, l’ajout ou la réutilisation d’une fonctionnalité quand nécessaire se fera facilement.


Mais il ne faut pas confondre « simple » et « simpliste » !

Cette valeur est assurément l’une des plus difficile à définir et quantifier : elle demande de l’expérience, de l’imagination, du travail et de la discipline. Donc du Courage...

Le courage

Au quotidien, le développeur XP est confronté à toute sorte de difficultés : techniques, méthodologiques, relationnelles...

Il doit constamment être ouvert, se remettre en question, s'exposer, prévenir quand il ne sait pas, si il a fait une erreur, chercher à comprendre... Pour surmonter ces situations inconfortables, les dépasser et améliorer, le développeur doit s'armer de courage.

La motivation même des Méthodologies, des Processus et autres Protocoles est de maîtriser et réduire le Risque, donc les craintes.

Plus nos craintes sont grandes, sur un projet logiciel notamment, plus ces Méthodologies doivent être robustes.

Cela est d'autant plus vrai avec les Méthodes Agiles, qu'elles intègrent le changement comme une composante naturelle !


Plus nous favorisons la Communication, le Feedback et la Simplicité, moins de courage nous avons besoins, même et surtout en cas de changements dans les besoins ou de remaniement dans le système.


Le courage est d'autant plus important en XP, que bien souvent, les fois où l'on donne sa chance à la controversée XP sont celles où le projet va mal et que l'on a plus rien à perdre. Les conditions sont alors loin d'être optimales.

Le respect

Etant apparue dans la seconde édition de « XP explained », j’aborderai cette valeur dans le chapitre consacré à la 2e version...


Conclusion

Comme je le dis en introduction, ces valeurs doivent se retrouver dans chacun des membres de l’équipe...

Ainsi, en cas d’embauche pour former ou compléter une équipe XP, demander au candidat quelle est sa vision pour chacune de ces valeurs, peut être un bon moyen de l’évaluer…


Aller, je joue le jeu : je vais faire preuve de Courage en essayant de donner mon Feedback le plus Simplement possible sur les valeurs XP.

Pour moi, les valeurs XP c'est : 

feedback = a x communication

feedback = b x simplicite

feedback x communication x simplicite = c / courage
     Aucun ne peut donc être nul, surtout pas le courage !

respect = t ^ d
     Nul au départ, cette valeur prend rapidement de l'importance avec le temps


Ces valeurs, qui permettent d'acquérir un état d'esprit positif, ne donnent pas de conseils précis quand à la gestion du projet ou le développement du logiciel. C'est pour cette raison qu'elles sont déclinées en 13 pratiques...

Quelques Principes

  • Faire la chose la plus simple qui puisse fonctionner. Cf. Remaniement continu.
  • T'en auras pas besoin.
  • Chaque ligne de code est justifiée par un test qui ne passait pas. Cf. UnTestQuiNePassePasCommePointDeDepart.
  • En fin de journée les tests passent à 100%. Le code qui ne passe pas les tests passe à la corbeille. Combien de personnes mettent effectivement leur code à la poubelle ? --pg cf JeterLeCodeQuandIlSeFaitTard.
  • Demande au systeme.
  • Tricher pour implementer. Fake It Till You Make It.


Vélocité

Les 13 pratiques

Ces valeurs et principes XP se déclinent donc en 13 pratiques qui vont du développement au processus. On peut voir ces pratiques comme autant d'indicateurs, de révélateurs des dysfonctionnements qui guettent l'équipe.


Afin d'avoir une certaine visibilité sur d'autres méthodes Agiles, il faut savoir que XP « impose » ces pratiques alors que Scrum par exemple les considère comme de bonnes pratiques à mettre en oeuvre selon le besoin.


Dans la mesure du possible, en abordant chaque pratique, je vais essayer de transcrire les simples discussions, les différentes interprétations ou mise en oeuvre, voire les polémiques, que se soit entre praticiens ou avec les détracteurs d'XP. En effet, je trouve cette approche aussi originale qu'interessante. Le faite de résumer ces variations, rencontrées sur les mailing-list, les sites, les événements ou rencontres, permettent de se faire une meilleure idée de la pratique abordée et donc de mieux la mettre en oeuvre. C'est le chapitre nommé « Paul et Mick dans l'extreme »... Désolé !...


Client sur le Site (On-Site Customer)

Cf. ClientSurSite Idéalement, le client XP est une personne de l'équipe client. Concrètement, il peut être un développeur qui abandonne le développement pour embrasser le rôle de client XP.

Durant le planning game le client a comme fonction d'exposer les scénarios qu'il souhaite voir réalisés durant l'itération. En fin de planning game, le client doit leur attribuer des priorités, une fois ces scénarios estimés par les développeurs, afin d'identifier ceux qui tiennent dans l'itération.

Durant l'itération, le fait qu'il soit sur site (dans le même espace que l'équipe, dans ce que l'on appelle la « war room »), lui permettra d'être directement accessible par les développeurs pour des questions, et donc les réponses. Cela implique que le client XP ait à la fois la connaissance pour répondre, mais aussi le pouvoir de prendre des décisions (ne pas faire telle fonctionnalité, la faire autrement, la faire après telle autre...).

Idéalement le client écrit les tests release avec un binôme de développeur. En pratique, il les conçoit et se sont les développeurs qui les écrivent.

Il faut bien comprendre que cette pratique a pour but d'améliorer le feedback, de raccourcir le délais entre une remarque du client et la prise en compte par l'équipe (dans un sens) ou une question de l'équipe et la réponse du client (dans l'autre sens).

XP n'est pas opposée à la rédaction de documents. Elle la considère simplement comme un d'atteindre un but : la capture et le transfert de la connaissance. Mais XP lui préfère d'autres moyens : le client sur site en est un. Maintenant si le client a un réel besoin de documentation, on pourra toujours identifier une tâche à cet effet, la documentation devenant alors, et dans ce cas seulement, une partie intégrante de ce qu'il faut livrer au client, de son besoin réel.

Il faut également avoir à l'esprit que le travail de réflexion et d'appropriation du métier qui se fait d'habitude pendant la réalisation du document de spécifications fonctionnelles, mais aussi celui d'élaboration au cours de la rédaction des spécifications techniques, est dans le cas d'une équipe XP un travail de tous les instants. Il n'y a rien de figer et d'irrévocable, tant sur le plan fonctionnel que sur le plan technique. Il est donc difficilement envisageable d'avoir un client sur site qu'une partie du temps. Une question pouvant émerger à tout instant, il est optimal que le client soit constamment sur site.


Paul et Mick dans l'eXtreme

Par contre, le client n'étant pas sollicité en continue, 100% du temps, mais étant une ressource comme les autres, il serait un luxe de l'affecter 100% de son temps au rôle de client. Par expérience, une configuration qui fonctionne bien est de donner la casquette de client au chef de projet. Il a bien souvent la connaissance métier. Il ne reste plus qu'à lui obtenir le pouvoir de décision. Il pourra ainsi Il pourra ainsi consacrer et donc imputer, à juste titre, un pourcentage, seulement, de son temps au rôle de client, mais être disponible à tout instant.

Toujours par expérience, il est a mon avis souhaitable que le client n'ait pas de compétences techniques, cela afin de garantir un cloisonnement des compétences, une séparation des responsabilités. Ainsi: Le client ne sera pas tenté de s'investir dans la conception ou le développement, pour ne pas dire être directif. Le développeur devra, pour se faire comprendre, vulgariser ses dire, ce qui implique d'abord de les maîtriser mais aussi de les remettre en question en les abordant sous un autre angle : nous sommes très proche de la pratique de la Métaphore. Enfin, cela renforce le fait que les tests release doivent aborder l'application comme une boite noire.

Toujours dans l'idée de favoriser la communication, le client participe au stand-up meeting quotidien. J'ai parfois entendu dire qu'une trace écrite via un document de spécifications fonctionnelles validée ou un mail avec les bonnes personnes en copie, sont impératifs pour se prémunir d'un « mauvais coup ». Cela est un « bad smell » qui traduit une déviance dans la notion de contrat gagnant-gagnant. Cette problématique, dépasse le cadre de cette pratique. En effet, les deux parties peuvent se prémunir d'un échec bilatérale, de manière contractuelle, et établir ainsi un meilleur état d'esprit, de confiance: c'est le « Optional Scope Contract ».


Livraisons Fréquentes (Frequent Releases)

Cf. LivraisonsFrequentes

Livrant en fin de chaque itération, le rythme des livraisons en XP est d’une toutes les quelques semaines. Il est important de s’accorder avec le client sur une fréquence donnée et de s’y tenir. Par exemple, une période de 2 semaines, pour la durée d’une itération, donc pour la durée séparant deux livraisons, est un bon compromis.


Si le client a besoin de livraisons plus fréquentes, on peut éventuellement raccourcir cette période, mais ne surtout pas faire de livraison en cours d’itération. Par expérience, ce « bad smell » traduit un dysfonctionnement dans le processus (voir le chapitre « Paul et Mick dans l'eXtrême »).


Techniquement, les livraisons fréquentes impliquent d’avoir un mécanisme d’intégration fiable, à savoir performant et automatisé.

Performant pour être compatible avec une fréquence de livraison élevé : notamment les tests release doivent se jouer relativement rapidement.

Fiable pour être capable de reproduire une livraison à partir des sources versionnées : en effet, seules les sources sont versionnées, les livraisons sont reproduites si besoin. Au-delà des sources, c’est l’environnement de développement qui doit être versionné : si l’on souhaite reproduire la livraison produite il y a 14 itérations, il faut repartir des sources de l’époque, mais aussi rétablir l’environnement de développement si l’on veut reproduire la livraison de l’époque à l’identique, avec les mécanismes de l’époque.

Un processus d’IntégrationContinue efficace va de paire avec des livraisons fréquentes réussies.

La livraison est le livrable qui ponctue l’itération. Il est important de conserver cette notion de BoiteDeTemps. Quoi qu’il arrive, il est important de systématiquement produire un livrable qui fonctionne en fin de chaque itération :

  • Tant en début de projet pour valider le processus de livraison lui-même (construction, test, déploiement)
  • Qu’après pour valider les nouvelles fonctionnalités.

Pour être fonctionnel, l’ensemble des fonctionnalités peut être :

  • Toutes celles prévues au début d’itérations plus d’autres ajoutées après,
  • Toutes celles prévues en début d’itération,
  • Seulement les prioritaires selon le client lorsque les développements ont pris plus de temps que prévu.

Dans tous les cas, le client devra comprendre que, si il décide d’ajouter en cours d’itération des fonctionnalités non prévues sur l’itération en cours, et il peut le faire, cela devra ce faire en deux étapes :

  1. Tout d’abord l’équipe devra estimer le temps de développement de cette (ces) nouvelle(s) fonctionnalité(s).
  2. Le client devra ensuite retirer des tâches de celles restant à faire (pour la fin d’itération) pour une même durée de développement : il s’agit bien d’un remplacement de tâches et non d’un ajout.

Cette pratique doit profiter de sa grande sœur, à savoir le ClientSurSite, sans pour autant tomber dans le piège : il faut livrer, installer, déployer le logiciel sur une machine dédiée, vierge de toute installation et configuration, par opposition à une machine de développement qui est déjà configurée.


La motivation de cette pratique est de donner au client, le plus fréquemment possible, un aperçu de l’état de l’application, afin qu’il puisse faire un retour qui conditionnera les développements à venir : on est bien là dans une démarche itérative.

Un des effets de bord est l’installation progressive d’un climat de confiance. Quel dommage ;o)


Paul et Mick dans l'eXtrême

XP insiste donc sur le fait de fournir au client un livrable en fin de chaque itération. A titre de comparaison Scrum est moins extrême. En effet, selon la taille du projet, une livraison ne sera intéressante que toutes les 2 ou 3 itérations. On pourra alors fournir au client le livrable au bout de 2 ou 3 itérations. Mais on continuera de produire à chaque fin d’itération un livrable qui vérifie les tests release identifiés en début d’itération, afin de rester dans une démarche incrémentale.


L’équipe doit vraiment voir cette pratique comme une chance : celle d’avoir le plus tôt possible la possibilité de corriger d’éventuelles erreurs ou mauvaises interprétations.

Considérons le projet comme la période d’essai d’un nouvel embauché. Le but est d’avoir un avis positif à la fin de la période d’essai, que l’employeur soit satisfait afin qu’il fasse de nouveau confiance pour la suite… Et bien les livraisons fréquentes sont autant de « bilans intermédiaires » qui visent à redresser le tir et augmentent les chances de satisfaction finale.


Mais il ne faut pas confondre fréquence et précipitation. J’ai rencontré un client qui nous a imposé durant une période de crise de livrer tous les 3 ou 4 jours (sur des itérations de 3 semaines), nous demandant de court-circuiter la phase d’intégration et de tests afin de tenir cette fréquence. Il nous a alors reproché les bugs inhérents aux livraisons, la baisse de qualité des livrables étant indéniable. Il nous imposa alors de corriger les nouveaux bugs tout en tenant la nouvelle fréquence : nous nous sommes alors enfermé dans cette logique de « livrer plus souvent principalement pour corriger les bugs qui apparaissent ».

La difficulté dans cette situation est d’arriver à faire comprendre au client qu’il perdra plus de temps, et donc plus d’argent, à corriger les bugs générés, qu’il pensait en gagner.

De plus, cette perte d’argent s’accompagne d’une perte de qualité dans l’image de marque, donc de confiance, ce qui est tout aussi déplorable.

La correction se fait au prix des autres fonctionnalités : d’où l’importance d’estimer toute demande de changement, notamment la correction de bug, afin de quantifier auprès du client les fonctionnalités qui ne seront délaissées en contrepartie.

Cette dynamique de livrer pour corriger des bugs est présente sur des projets non XP, où il n’y pas la pratique des LivraisonsFréquentes.


L’autre extrême est tout aussi préjudiciable. Pas plus tard qu’hier, j’ai entendu dire : « ça n’a pas de sens de faire une livraison intermédiaire sur ce projet ». Plus qu’un « bad smell », cela traduit à mon sens un (mauvais) conditionnement de l’esprit. Il est évident qu’une maison constituée de juste 4 murs avec les ouvertures pour les portes et les fenêtres n’a pas de « sens fonctionnel » : elle n’est pas habitable. Mais le but de cette « livraison intermédiaire » n’est pas d’y habiter mais de détecter d’éventuelles erreurs grossières au plus tôt, telles qu’une mauvaise orientation de la façade, ou une mésentente dans les dimensions des ouvertures ou la surface habitable. Parmi les quelques personnes que je connais et qui ont fait construire une maison, TOUTES SANS EXCEPTION, allaient constater l’état d’avancement du projet au moins une fois par semaine : ce n’était pas pour y habiter !

Il ne faut pas confondre le but d’une livraison intermédiaire (s’assurer que tout le monde travail dans la bonne direction) et celui de la livraison finale (satisfaire le besoin du client).


Enfin, la fréquence permet de diminuer la quantité de travail à valider.

Je vais encore prendre un exemple. J’ai récemment dû rédiger un document de spécifications fonctionnelles sous forme de « Use Cases ». Si je vous livre chaque semaine, une dizaine de pages correspondant à 2 ou 3 Use Cases, j’obtiendrais aisément de vous une relecture hebdomadaire, régulière, qui deviendra plus aisée à mesure que vous appréhendez la formule, que vous assimilez l’exercice. De plus, vous pourrez mûrir votre compréhension, et donc avoir un jugement de plus en plus critique. Maintenant si je débarque au bout de 2 mois avec un document de 80 pages se voulant complet, dont vous découvrez le fond et la forme pour la première fois… Ai-je une chance d’avoir un retour ? Voire une validation ? Et si oui, en temps et en heure ? Quelles en seront alors la finesse et la pertinence ? Il ne faut pas négliger cet aspect de l’effort nécessaire, que j’ai bien envie d’appeler le paradigme de « l’escalier et de la corde raide ». La tour « Taipei 101 » est actuellement la plus haute tour du monde avec ses 508 mètres : il est envisageable de la gravir via son escalier, mais pensez-vous envisageable de la franchir d’un trait avec une corde raide ?


Au final, cette pratique des LivraisonsFréquentes s’avère bien plus consensuelle, bien moins extrême que ce que l’on peut rencontrer traditionnellement sur les projets informatiques.


Métaphore (Metaphor)

Cf. Métaphore

La motivation de cette cette pratique XP, est de parvenir à décrire un module de l’application, voire l’application dans son ensemble, en utilisant une analogie, le champ lexical d’un autre domaine : métier, loisir, vie courante...

Trouver une métaphore pertinente prend du temps. Aussi, on pourra poser une ou deux réunions d'une demie heure par exemple, pour identifier une métaphore qui s'adapte judicieusement à l'application. On pourra éventuellement profiter du PlanningGame pour faire cet exercice. Dans ce cas, il faut profiter du fait que tous le monde soit réunis sans pour autant en abuser et déborder sur « l'ordre du jour » du planning game : une demie heure au cours de deux ou trois planning game. Ensuite, on pourra utiliser et affiner cette métaphore au quotidien dans les développements, la communication avec le client, avec un nouveau membre de l'équipe...


Quels sont les intérêts ?


Tout d’abord pour l’équipe de développement, l’exercice en lui-même d’identifier une métaphore oblige à mettre à plat la connaissance sur l’application, donc le domaine métier comme la conception. On diffuse ainsi et homogénéise donc la connaissance, on lève les ambiguïtés, comble des lacunes voire éventuellement assaini une portion insatisfaisante de la conception lors du RemaniementContinu. La mise en place d’une métaphore est donc un prétexte à communiquer.


Le développeur étant souvent un grand enfant joueur, il se prête volontiers aux petits jeux intellectuels, l’association d’idées en étant un parmi d’autres… Une classe de log qui reçoit des informations brutes et les affiche de façon compréhensible, c’est un peu comme une télévision… Si on appelait cette classe Television. Mais si l’antenne est débranchée ou que le câble est coupé, il faut un moyen de faire la différence entre cette panne et une absence de programme télé afin que l’utilisateur agisse. Peut être qu’une classe Maintenance ou Repairer Ca y est, on file la métaphore… Et innocemment, on réfléchi en s’amusant…


Une fois établie, la Métaphore devient un média de communication, sur les fonctionnalités de l’application et/ou sa conception. De plus, cette métaphore pourra très bien se révéler dans l’implémentation même, dans le code, dans le nom d’un module, d’une classe, d’une fonction, d’une structure…


Enfin, l’idéal est de choisir un champ lexical facilement accessible, compréhensible pour tout nouvel arrivant, qui n’a pas forcément de connaissances préalables dans le domaine métier. La métaphore devient alors un outil de vulgarisation aussi précieux qu’une ConceptionSimple


Paul et Mick dans l’extrême

La métaphore est assurément la pratique XP la plus controversée, même entre praticiens.

Elle est donc la moins répandue de toutes les pratiques.

Certains praticiens sont convaincus qu'il faut trouver l'analogie dans le même domaine métier...

D'autres doutent de l'intérêt véritable de cette pratique.


Par experience, la métaphore est souvent le recours d'un interlocuteur qui souhaite faire passer un message. N'avez-vous jamais discuter avec une personne qui a pris un exemple, une "image" pour se faire comprendre autrement ?!...


Pour ma part, je vous retourne la question : en lisant le précédent chapitre, sur les livraisons fréquentes, avez vous fait attentions aux métaphores ?... Avec le recul, pensez-vous qu'elles vous ont aidé à mieux appréhender le connaissance que je voulais transmettre ?...


= = = TODO = = =

Séance de Planification (Planning Game)

Cf. PlanningGame


Voir aussi PlanningPoker

Présentation

En XP le client arrive avec un ensemble de scénarios utilisateurs suffisant pour couvrir selon lui plus d'une itération. Il expose ces scénarios aux développeurs.

Les développeurs posent les questions nécessaires pour s'approprier ces scénarios. Ils découpent alors chaque scénario en tâches qu'ils identifient puis estiment consensuellement. La durée d'une tâche ne devant pas dépasser 4 jours. Les développeurs doivent profiter de ce moment privilégié pour confronter et homogénéiser leur connaissance du métier et de l'application.

En sommant l'estimation de chacune des tâches composant un scénario on obtient la durée de chaque scénario.

Le client fera alors le tri parmi les scénario afin de sortir de l'itération les moins importants selon lui, et de prioriser les autres.

Dans le cas d'une itération qui fait suite à une livraison en recette, on pourra éventuellement inclure des tâches de "Traitement des retours de recette éventuels" d'une durée déterminée.


Déroulement

Avant

  • Identifier des stories de référence (la plus courte, la plus longue et une intermédiaire)
  • Ne pas créer les issues au préalable, et encore moins les tâches techniques : ce travail sera le résultat collaboratif de la séance. Par contre le ProductOwner aura fait avant le travail nécessaire à l'identification des issues et à répondre aux questions.


Au début

Partager avec l'équipe

  1. La vision business
  2. L'objectif particulier de l'itération
  3. Voire une démo de l'outil
  4. Faire le point sur le nombre story points disponibles dans l'itération à venir (pour savoir combien on va en estimer)


Puis faire un point sur l'itération passée :

  • Parcourir les issues qui ont le plus dérivé entre l'estimation et le réalisé
  • Pour chacune (ou seulement pour celles qui ont le plus dérivé), identifier pourquoi il y a eu cette dérive.
    • Ce travail peut être pré-maché par le propriétaire de chaque story au moment où il la clos pendant l'itération : il peut alors compléter la story en indiquant à chaud les raisons, selon lui, de la dérive.
    • Les principales raisons peuvent être recensées dans une liste, que l'on pourra ressortir en début de chaque planning game, juste avant d'estimer, afin de se remémorer les principales causes de mauvaise estimation


L'estimation

Le ProductOwner liste les UserStorys qui préssent pour le Sprint en citant le nom et la description, sans passer trop de temps. Cela permet de diffuser une vision globale du Sprint.

Puis on reprend les UserStorys une par une avec l'objectif de les estimer.

Cela peut se faire via la technique du PlanningPoker.

Cette étape se fait en ayant sous les yeux :

  • la DefinitionOfDone
  • la liste des causes de deviance dans les estimations (liste établie dans l'étape précédente).


Globalement

Un PlanningGame mal encadré peut s'eterniser. Le rôle du ScrumMaster y est donc primordial pour garantir une discpline de tous les instants.

Conseils

  • Impliquer les plus timides, en les invitants à reformuler ce qu'ils ont compris par exemple
  • Le PO est-il la bonne personne


En détail

Résumé

Commençons par revenir à l'objectif premier du planning game : fournir une estimation suffisamment juste au Client de ses User Stories pour qu'il puisse en retour donner une priorité à ces User Stories.

Mais le planning game est avant tout une cérémonie.

Au même titre qu'une rétrospective une cérémonie qui vise à remplacer un bilan de fin de projet par voie rédactionnelle, le planning game vise à assurer l'activité de plannification de façon collégiale.

Les deux mots à retenir sont :

  • Plannification
  • Collégial


Plannification

Pour pouvoir planifier, il faut d'abord estimer. Et qui mieux que les personnes amenées à développer sont les mieux placées pour estimer ?

Car une estimation n'est pas une valeur absolue : une tâche donnée n'a pas une estimation universelle, mais bien au contraire, son estimation va dépendre de nombreux facteurs : qui va la réaliser, quelles sont ses compétences, ses connaissances, techniques, fonctionnelles, applicatives...

Une fois les estimations établies, il faut transformer cet amas de durée en une succession de jalons amenant à une date de livraison : la plannification. Cela se fait grâce à un outil précieux : la vélocité. C'est le nombre de Story Points que l'on peut réaliser en une itération. N'ayez pas de craintes, cet outil, contrairement à un couteau, s'aiguise avec le temps ;)


Collégial

Si le planning game est une cérémonie c'est qu'il a une vocation, trop souvent inconsidérée : le partage de connaissance. Un transfert de connaissance à la fois :

  • Fonctionnel
  • Technique

Le planning game est (aussi) un moment de formation !

Vous doutez encore de son utilité ;o)

La responsabilité de chacun est de refuser de donner une estimation si il ne croit pas en cette estimation.

Cela va forcer les discussions, et donc l'échange de connaissance jusqu'à ce que la vision soit suffisemment partagée pour permettre l'estimation.


Granularité des estimations

Bien souvent se pose la question de savoir jusqu'où on pousse le découpage...

  • Est-ce qu'on fait que des User Stories ou aussi le découpage en tâches ?
  • Quelle est la taille maximale des User Stories ?
  • ...

Pour répondre à cette question, je me base sur la première phrase de cet article, à savoir l'objectif du planning game : tout est dans le mot "suffisamment" ;)

En effet, l'objectif est de "donner des estimations suffisamment justes". Donc, si vos estimations sont juste, à savoir proche du réalisé, c'est que votre granularité est suffisante.

Par exemple, j'ai encadré une équipe de développeurs mobiles : dans ce contexte, l'ajout d'une fonctionnalité consiste souvent en l'ajout d'un écran, et selon les cas, cela peut se faire en une journée. Nous avons donc une User Story bien définie d'une durée de 1 jour : pourquoi découper en tâche technique ?

A l'autre extrémité, j'ai travaillé de nombreuses années dans le domaine de l'informatique de gestion, et plus particulièrement dans le domaine bancaire. Là, il est fréquent de rencontrer des fonctionnalités qui contiennent plusieurs écrans complexes, avec consolidation de données provenant d'autres systèmes, en lecture et en écriture, au sein d'une application N tiers, distribuée. J'espère vous avoir convaincu que dans ce contexte, une User Story complète plusieurs semaines. Dans ce cas, on va commencer d'abord par scinder cette Epic (ou épopée) en plusieurs User Stories. Certains des ces "sous" stories (pour ne pas dire toutes) resteront assez complexes et longues pour nécessiter un découpage en tâches techniques. Cela permet tant d'estimer plus justement que d'identifier ce qu'il faut faire pour des membres de l'équipes qui n'aurait une vision suffisamment claire.

Pour ma part, le Bad Smell en terme de taille d'estimation, la limite maximale est 4 jours (ou 5 si vous jouez avec la suite de Fibonacci d'un planning poker ;). Pourquoi 4 ?... Car cela correspond à une petite semaine, et j'ai du mal à croire que l'esprit humain puisse sereinement appréhender toute la dimension d'une tâche qui commencerait le lundi à la première heure pour se terminer le jeudi soir avant l'entrainement de foot.


Pré-définition des issues

J'ai souvent vu des équipes qui commençaient l'agilité débuter les planning game avec User Stories déjà définie au préalable par le Product Owner (créée dans JIRA), voire même parfois le découpage en tâches techniques réalisé, sous le prétexte sincère de vouloir gagner du temps.

C'est pour moi le même raisonnement que dire je ne vais pas m'entrainer mais directement courir mon 400 mètres pour gagner du temps.

Quand vous cherchez à expliquer quelque chose à quelqu'un, et que cela passe par un schéma, il est recommandé de construire le schéma en direct avec le ou les interlocuteurs, et non pas d'arriver avec un schéma tout fait. Cela afin de favoriser l'échange d'information et l'appréhension du message par l'autre.

Dans un planning game c'est pareil.

Le fait de construire "collégialement" la User Story avec l'équipe permet d'en partager la vision.

Quant au fait de pré-découper en tâches, il se peut tout simplement qu'au final, le découpage soit tout autre.

Ce qui ne veut pas dire que le Product Owner doit venir sans avoir préparé la réunion, bien au contraire !


Maturité d'équipe

Mais vous pouvez oublier tout ce que vous venez de lire dans ce chapitre, car la seule règles est qu'il n'y a pas de règles... ;)

Ce que je veux dire avec cette assertion provocante, est que tout dépend de la maturité de votre équipe, tant sur le plan de la mise en œuvre de l'agilité que ne serait-ce même que de son fonctionnement en équipe (depuis combien de temps).

Si vous votre équipe a été récemment formée, ou qu'elle commence depuis peu l'agilité, il est conseillé d'être "jusqu-au-bout-iste", d'appliquer les règles avec zèle, et de découper les stories en tâches les plus petites possibles.

Et, à mesure que la dynamique d'équipe se met en place, à mesure que vous appréhendez les mécanismes agiles, vous pourrez prendre quelques raccourcis, et cela tant que les estimations resteront proches du réalisé. Cela vous permettra de raccourcir la durée de vos séances d'estimation, et donc de maximiser votre investissement. Car oui, le planning game est un investissement. Le taux horaire de chacun des participants multiplié par la durée de la séance est le coût. La liste des User Stories estimées au plus juste et ordonnées est le gain. Si nous passons deux jours à produire des estimations erronées, cela devient une perte !

La prochaine étape est de faire en sorte que les estimations soient tirées vers le bas. Par expérience, si on estime à trois jours une stories qui peut être faite sereinement en deux jours, il sera pris trois jours pour la réaliser. L'estimation correspondant exactement au réalisé, on pourrait croire que tout va pour le mieux dans le meilleur des mondes, alors qu'en fait le temps de réalisation n'est pas optimal ! L'entreprise perd donc de l'argent. J'y reviendrait plus tard.

Le Product Owner

D'autres points problématiques tournent autour du rôle de Product Owner :

  • Doit-il être mobilisé sur place pendant toute la durée du Planning Game ?
  • Est-ce que ca doit être le client ou est-ce que ca peut être quelqu'un d'autre ?

J'y reviendrait plus tard.


Règles

On pourrait donc résumer le planning en quelques règles qui permettent converger vers un bon fonctionnement :

  • Pas d'issue de plus de 4 jours
  • Il est interdit de donner une estimation si on ne sent pas capable de la tenir.
  • Donc, poser des questions pour pouvoir estimer.

Intégration Continue (Continuous Integration)

Cf. IntégrationContinue

Le système est intégralement assemblé et testé une à plusieurs fois par jour.

L'idée de cette pratique est de détecter le bug le plus tôt possible.


Idéalement, une machine dédiée surveille le gestionnaire de version et lance un cycle complet d'intégration (par exemple : compilation, jeu des test unitaires, construction de l'application, déploiement, jeu des test release, livraison et génération des rapport) à chaque fois qu'elle détecte le remontée d'une modification.

Selon les systèmes et les interprétations, la durée totale de jeu les tests release peut/doit ne pas dépasser quelques minutes ou bien atteindre voire dépasser l'heure. Entre ici en jeu les techniques utilisées (C++ vs Java, compilation à la volée, distribuée, intelligente...) et l'architecture déployée (être capable de reproduire l'environnement et l'arborescence de développement, la base de données et ses identity...).


Rythme Soutenable (Forty-hour Week)

Il est clairement écrit dans « Le Livre » que l’équipe de développement ne fait pas d’heures supplémentaires plus de 2 semaines de suite.

Notamment en raison de la « programmation par paire » et de l’intensité qu’elle induit, il est important de ne pas faire de journée à rallonge pour ne pas dérégler la machine bicéphale.

De plus il est avéré que des personnes qui arrivent au travail le matin à 7h et savent qu’elles y sont jusqu’à au moins 20h, auront tendance à prendre leur temps et donc perdre en efficacité. Sans oublier que sur la dernière heure elles généreront plus de bugs que de code sein. Cela implique de pouvoir PartirTot lorsque cela est possible... L'enjeu ici est bein de produire un travail de qualité...

Encore une fois les « livraisons fréquentes » sont là pour rassurer le client et le faire patienter : donc ne pas imposer de surcharge de travail destructrice.

Paul et Mick à l’extrême

A l’extrême, dans certaines équipes, on jette en fin de journée tout ce qui n’est pas remonté sous le gestionnaire de version, sachant qu’on ne peut remonter que si tous les tests unitaires passent avec succès.


Tests De Recette (Acceptance Tests)

Cf. TestDeRecette Une pratique XP très appréciée du client !


Les tests de recette, ou tests release ou encore tests d’acceptation, permettent de spécifier le système à priori, et de le valider à posteriori. Dit autrement, ils constituent une description détaillée sur ce qu’il faut faire et un retour d’information rapide sur ce qui est fait.


Ils sont idéalement écrits avec le client (en collaboration avec un binôme) mais assurément conçus par lui. Dans le cas idyllique où le client écrit les tests, il est à la charge de l’équipe de lui fournir un formalisme (« langage ») adapté.


Toujours idéalement ils seront écrits durant l’itération qui précèdent celle où la fonctionnalité doit être développée. Ainsi, au PlanningGame qui débutera l’itération des développements, le client comme le binôme ayant collaboré auront une idée précise de la fonctionnalité et de ses subtilités. L’explication par le client et la participation du binôme à l’estimation n’en seront que plus pertinentes.


Cette pratique des « tests release » à de réels impacts sur la ConceptionSimple de l’application, l’environnement de développement et le mode de fonctionnement de l’équipe : être capable de déployer à tout instant une version de chacun des deux parties cliente et serveur de l’application ainsi que de sa base de données n’est pas donné à toutes les équipes.


Ils doivent être automatisés afin de pouvoir être joués systématiquement en IntégrationContinue. Il faut bien comprendre que la motivation de cette pratique est de fournit un état d’avancement des fonctionnalités du systèmes, mais aussi de mettre en évidence les bugs éventuels voire des régressions. Plus tôt ces derniers sont détectés, plus facilement la cause sera identifiée, plus rapidement la correction sera apportée.


Paul et Mick dans l’extrême

Selon les interprétations, ces tests doivent se jouer rapidement (une dizaine de minutes) ou peuvent durer plus longtemps (de l’ordre d’une heure).


L’enjeu ici est que dans le premier cas ils pourront être joués intégralement et fréquemment, par exemple par tout binôme qui vient de finir une partie sensible de sa tâche. Mais pour pouvoir être rapides sur des projets complexes, les tests de recette devront bouchonner les parties limitantes, comme une base de données ou un serveur distant. Dans ce cas, on teste bien la fonctionnalité, mais dans un environnement cible qui n’est « que » simulé.


Tests Unitaires (UnitTesting)

Cf. TestUnitaire Cette pratique XP est de plus en plus répandue, bien au delà des projets agiles.


Ces tests sont au niveau de la classe, et incombent au développeur.


En pratique, les TestUnitaires sont :

  • Entièrement conçus et réalisés par le binôme qui développe la tâche la classe et la tâche associée,
  • Ecrits dans le même langage que l'application,
  • Constitués d'une classe de test par classe de l'application (qu'on appellera par la suite « classe applicative »),
  • Et d'une méthode de test pour chaque méthode publique de la classe testée (voir « Paul et Mick » plus bas?).

Ainsi la classe Family aura sa grande soeur FamilyTest : la première portant notamment la méthode prepareChristmas(), la seconde aura donc une méthode de test test_prepareChristmas. Le test peut se compliquer lorsque la classe Family a besoin d'une classe Doctor, qui elle a besoin d'une classe Hospital, qui elle a besoin de la classe HealthMinister, qui elle? Il est donc pratique de mettre de « fausses » classes qui « bouchonnent » ces dépendances. On parle de MockObject... Ici, notre classe Family serait utilisée avec une classe DoctorMock, qui ne tirerait aucune autre dépendance.


La réalisation d'un TestUnitaire fait entièrement partie de la tâche du binôme. C'est tout autant du développement que la réalisation de la classe applicative elle-même. Dans l'idéal, c'est-à-dire en TestDrivenDevelopment, le test sera même réalisé avant la classe applicative. L'impact du test sur la conception est alors prépondérant, et tant mieux.


Ces tests doivent passer à 100% continuellement et sont donc automatisés. Pourquoi ? Car il est inconcevable de remonter sous le gestionnaire de version si l'un de ces tests unitaires échoue. En effet, de par la pratique de la PropriétéCollectiveDuCode, n'importe quel binôme peut intervenir à tout instant sur n'importe quelle portion du code présente dans le GestionnaireDeVersion. Il faut donc que l'intégralité du code soit valide, c'est-à-dire que tous les tests unitaires passent avec succès. Cela implique de jouer fréquemment ces tests, donc de conserver facilité et rapidité dans leur exécution.


De plus, ils sont joués tôt dans le cycle d'IntégrationContinue : juste après la compilation (des classes et des classes de test). Ils permettent ainsi d'avoir une feedback précis sur l'implémentation de l'application.


Cette pratique se place à l'opposé de processus qui préconisent une conception détaillée en amont du projet et une phase de tests en fin de projet.

On part du problème : le TestDeRecette de la fonctionnalité. On écrit un premier test unitaire qui simule un appel à la première méthode de la première classe. Puis en développant cette classe on s'aperçoit qu'il serait judicieux d'avoir à disposition cette « autre fonctionnalité » (une autre classe). On écrit donc le test unitaire de cette autre classe puis cette autre classe elle-même? Mais... mais... On vient de piloter notre conception par les tests ou TestDrivenDevelopment? donc par les cas d'utilisation ! Ce qui n'est pas si aberrant que cela au final !


Je ne suis pas inquiet outre mesure sur la pertinence et la qualité de ce que j'ai écrit car :

  • Tout d'abord je l'ai écrit en collaboration avec un binôme vigilant,
  • A tout moment j'ai pu interpeller un membre de l'équipe qui connaissait bien la problématique pour lui demander son avis
  • La PropriétéCollective du code me garantit que si ce code ne convient pas, il sera amélioré.

Au final je suis sûre d'une chose, c'est que ma classe fait ce que je lui demande : n'est-ce pas le vrai besoin. A moyen terme le module fera ce qu'il faut, et à la fin, se sera l'application elle-même qui fera ce qu'il faut.


Le dernier point sur la PropriétéCollective met en évidence un autre intérêt des tests unitaires : l'aspect documentaire.

Lorsque l'on intervient sur une portion de code que l'on n'a pas écrit on est content de trouver de la documentation sur son fonctionnement. Je ne parle pas d'un document Word, qui pourrait aisément avoir des défauts :

  • pas à jour,
  • volumineux,
  • incomplet (ce qui n'est absolument pas incompatible avec le précédant point !),
  • écrit dans une langue que je ne comprends pas, incompréhensible !

Un TestUnitaire, qui compile et passe avec succès, est forcément à jour. De plus, si l'on applique rigoureusement le TestDrivenDevelopment on a également des garanties quand au fait le test couvre de façon complète les fonctionnalités, ni plus ni moins. Enfin, avec les conventions de code et les binômes tournant qui homogénéisent les compétences, avec le temps, quand j'intervient sur du code que je n'ai pas écrit j'ai l'impression de me relire.

Par expérience, quand on arrive sur une portion qu'on ne connaît pas, on commence par aller voir les tests unitaires. On a très souvent une présentation claire, rapide et précise de ce que fait le code.


De plus, cette documentation à l'inestimable avantage d'être dynamique. Une pratique saine lorsque l'on vient nous voir pour nous demander « Combien ça coûterait de faire cela ? », est de modifier sommairement une partie clef du code et de rejouer les tests unitaires. En constatant les dégâts, à savoir les tests unitaires qui échouent, on a un indicateur sur les parties impactées par la modification, et donc une première estimation du chantier.


Au final, le test unitaire est un outil polyvalent et donc indispensable dans :

  • la conception de la classe
  • l'identification précise de l'état actuel de l'application
  • l'évaluation des impacts de toute modification dans le code
  • la documentation et la spécification d'une classe.


Vous comprenez donc que la réalisation de tests unitaires est une pratique importante, qui prend du temps : ce temps doit donc être pris en compte au moment de l'estimation des tâches au cours du PlanningGame. Lors des premiers PlanningGame, il est sain de rappeler : « Ah oui, mais c'est vrai qu'il y a aussi les tests unitaires : je rajouterais un peu plus de temps à l'estimation ! ».


Paul et Mick dans l'extrême

Selon les interprétations on ne teste que les méthodes publiques (et protégées), ou au contraire on teste l'intégralité des méthodes, mêmes privées, lorsque le langage le permet.


Pour ma part je partage la première solution. Un test unitaire, tout comme un test de recette, simule une utilisation par un client. Dans le cas du test unitaire, le client, c'est-à-dire une autre classe, n'utilisera pas de méthode privée de la classe testée. Par contre, les autres méthodes de la classe testée, qui elles sont testées, utilisent les méthodes privées qui sont donc indirectement testée.


Ressources


Conception Simple (Simple Design)

Cf. ConceptionSimple Cette pratique XP est la mise en pratique directe de la valeur « simplicité ». Le code doit passer tous les tests et répondre aux critères de maintenabilité : concision, modularité, cohérence, lisibilité.

Les intérêts de concevoir le plus simplement possible à tous les niveaux sont multiples :

  • L’apprentissage du code existant par tout œil nouveau est facilité,
  • Les évolutions au sein de l’application ou d’un de ses modules seront également facilités et donc moins coûteuses.
  • Pour les mêmes raisons, la maintenance sera facilitée et moins coûteuse.


Mais quels sont les moyens pour favoriser une ConceptionSimple ?

Tout d’abord, une bonne façon de mettre en œuvre des conceptions simples, est de supprimer toute partie de la conception qui touche à des fonctionnalités dont on n’a pas besoin dans l’immédiat. Ne pas tirer de plans sur la commette. « Ok, ça serait cool si j’ajoutais cette fonctionnalité, en plus, je m’éclaterais à le faire, mais n’étant d’aucun intérêt dans l’immédiat, je prend sur moi, et je mets la fonctionnalité de côté ! Snif !». La conception doit être doit être un bon compromis entre « le strict minimum » et « l’utilisation de modèles ou frameworks garantissant une certaine évolutivité ». J’y reviendrais avec « Paul et Mick »…


Ensuite, un autre outil préconisé par XP est le TestDrivenDevelopment...


Enfin, le principal moyen fournit par XP pour garantir une conception simple est le développement itératif et incrémental. Concrètement, les moments où l’on fait de la conception dans XP sont :

  • le PlanningGame
  • une réunion improvisée à la demande d'un développeur,
  • le développement.

On peut pour cela s'aider de fiches CRC...

Paul et Mick dans l’extrême

L’utilisation systématique de design patterns remarquables n’est pas une attitude saine et pérenne sur le long terme. Mais l’utilisation d’un design pattern choisi judicieusement est souvent une bonne solution.


En extrapolant, on peut se poser la question sur le fait de mettre en place des frameworks conçus pas un architecte logiciel. Tout d’abord, étant entendu que la conception de l’application est la « propriété » de l’équipe, on peut se poser la question de la pertinence de l’existence d’un tel framework ?


Ensuite on peut s’interroger sur la pertinence du framework lui-même : Est-il adapté à la problématique ?... Face à cela, j’ai discuté avec un Scrum Master qui m’a dit que lorsqu’il y a un Architecte logiciel qui a pour charge la mise en place d’un framework, cet architecte doit obligatoirement participer au moins 2 jours par semaine au développements comme développeur, parie d’un binôme. Cela afin qu’il prenne conscience des problématiques liées à la mise en œuvre de « son » framework.


Remaniement Continu (MercilessRefactoring)

ou RefactorisationDeCode pratiquée sans relache: modification du code par laquelle on améliore sa conception sans en modifier le comportement.


Convention de Code (Coding Standard)

Le code doit suivre une convention de nommage et de présentation afin d'être lisible par tous les membres de l'équipe.


Programmation En Binome (Pair Programming)

ProgrammationEnBinome

Le code de production est toujours écrit par deux développeurs : le pilote et le copilote. Les binômes changent au cours du projet.


Propriété Collective du Code (Collective Code Ownership)

Chaque développeur peut modifier chaque partie du code si le besoin s'en fait sentir.

Des Rôles

« La différence entre un désert et un jardin n'est pas l'eau mais l'homme. »


Le développeur

Le client

Le testeur

Le tracker

Le coach

Le consultant

Le grand patron

Conclusion

  • XP que pour les langages objets ? Que pour le développement ?
  • On peut s'inspirer, n'utiliser que quelques pratiques : c'est mieux que rien. Mais il ne faut pas critiquer avant d'avoir pratiqué l'intégralité des pratiques conjointement en symbiose. C'est leur effet de synergie qui permet la réussite.
  • On lui reproche d'être un cadre léger. Bien que je ne partage pas cet avis, il vaut mieux un cadre restreint pleinement appliqué, qu'une bible de 800 pages mal adaptée... Qui parle de CMMI ?
  • Pour "vendre" XP aux dirigeants/clients, il faut d'abord chercher à identifier quelle est la valeur qu'il cherche à obtenir, et ensuite on pourra adapter notre langage au leur. Pour commencer, on pourrait faire de l'XP mais vendre de l' « Agile »?!...
  • XP est considéré par ses détracteurs comme une méthodologie très chère : je rectifierais en disant que c'est une méthodologie chère, mais pas plus chère qu'une méthodologie classique sur un projet non maîtrisé.
  • Pour clore sur XP, je prendrais la métaphore de l'acquisition d'une voiture. Vous avez le choix entre acheter une voiture en espérant que vous n'aurez aucun problèmes, ou prendre une voiture en location. Ce deuxième cas vous coûtera un peu plus cher au quotidien, mais vous n'aurez à vous soucier de rien. Et le jour ou vous vous rendez compte que votre coupé sport ne convient pas à votre famille, vous pourrez changer pour un monospace. Dans le premier cas, cela est impossible. De plus, si il tombe en panne, cela devient le gouffre financier...

Ressources

Récupérée de « http://agora.2ia.net/mediawiki/index.php?title=Agile/ExtremeProgramming »