ValeurXp

Un article de Agora2ia.


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…


Sommaire

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...