En 2006, en arrivant sur une nouvelle mission par la nouvelle SSII venant de m’embaucher, ma carrière allait changer de tournure.
Posons un peu le contexte
J’avais démissionné de la société précédente pour me frotter à de nouveaux projets et de nouvelles personnes, dans l’espoir d’améliorer mes compétences et mon plaisir à travailler, tout simplement.
Jusque là, j’avais toujours tiré une certaine fierté de mes développements, et ils récoltaient leurs lots d’appréciations auprès de mes paires, mais systématiquement j’avais cette peur au ventre. La peur d’avoir laissé passer un bug, la peur de ne pas avoir trouvé le meilleur design possible, la peur de ne pas tenir les délais… De plus, ce code était technique, et je ne concevais pas autrement mon travail qu’en traduisant des demandes fonctionnelles en design technique.
J’avais entendu parler d’XP, mais comme beaucoup de monde, je n’en savais pas grand chose si ce n’est qu’on devait programmer par paire. Je sentais d’une certaine manière que j’étais dans la mauvaise direction, et c’est pourquoi je me suis mis à lire, beaucoup. Des livres comme Code Complete ou Design Patterns, mais toujours pas XP, ni DDD.
Donc c’est dans ce contexte que je démarrais cette nouvelle mission, avec toujours la même peur au ventre. Et là, dans un bureau digne des messages à caractère informatif, on me présente mon nouveau collègue, lui aussi prestataire : Fabien Bézagu. Sur son bureau trônent Applying DDD de Jimmy Nilson, Pratiques de .NET en C# de Patrick Smacchia.
A la découverte d’un nouveau monde
De fils en aiguille, nous voici donc en train d’expérimenter : des patterns, des idées, de l’orientée objet, et surtout de plus en plus de DDD. Puis un jour, il arrive avec cette idée folle : commencer son développement par les tests.
Comme beaucoup de monde, je suis réticent au début, mais je m’y mets de plus en plus, poussé par l’autre énergumène.
Comme apparemment, notre travail est apprécié, on nous confie un nouveau projet. Là bien sûr, nous sortons DDD vaillamment, et nous tentons de nous améliorer. Nous sommes bien sûr très teintés XP, mais sans encore avoir fait le grand saut. Puis un matin, excédés sans doute de ne pas avoir toutes nos réponses, nous faisons enfin l’investissement d’acheter nos copies de XP explained.
Le choc est rude pour moi : toutes les réponses que je cherchais depuis des années, ou ce que je savais intuitivement sans oser me l’avouer, est écrit noir sur blanc, avec une clarté et une simplicité désarmante. Bien sûr, le projet social d’XP devient alors mon cheval de bataille.
Le contexte et nos connaissances étant ce qu’elles sont, nous n’avons pas forcément emporté un grand succès. comme l’explique Fabien. Cependant, les premiers mois de ce projet ont été une des meilleurs périodes de ma vie de développeur, jugez plutôt :
- tous les matins, j’étais heureux d’aller au travail. Je savais ce que j’avais à faire, j’étais fier de ce que je produisais, le métier était enrichissant et mes collègues passionnants,
- tous les soirs, je sortais empli de la certitude que je n’aurais rien pu faire de plus pour faire avancer le projet. Le travail énergique étant correctement mis en place, je sortais sans ce sentiment désagréable de travail inachevé, ou de gaspillage de temps passé sur des soucis d’environnements,
- chaque semaine comprenait son lot d’améliorations.
Quand le projet a finalement eu des soucis pour différentes raisons, ces pratiques nous ont permis de rester droit dans nos bottes, en sachant que nous avions fais notre maximum. Cette confiance fait toute la différence quand le client tente de vous mettre la pression, en vous faisant croire que vous n’en faites pas assez.
La suite bien sûr, c’est que XP est devenu le cœur de nos préoccupations, toujours dans l’objectif de pratiquer le DDD et répondre ainsi au mieux aux problèmes de nos clients. Nous avons donc porté ce message dans nos autres missions, et nous avons fini par lancer Tiron et Arpinum.
Et donc?
Si je fais donc le bilan de ces 5 années d’apprentissage, et sans vouloir faire trop sectaire, XP m’a apporté les points suivants :
- la qualité : en avançant grâce au TDD, en extrayant la connaissance en suivant le DDD, et en la gravant dans le code et dans FitNesse, la qualité de nos développements a grandement augmenté, réduisant ainsi les coûts, et augmentant la confiance de nos clients,
- la simplicité : la peur du mauvais design a disparu, je sais que je vais le faire apparaître par design incrémentiel,
- la confiance : grâce à la qualité et la simplicité, j’ai gagné en confiance, je sais que je fais mon maximum pour réduire les gaspillages et livrer un produit de qualité dans les temps,
- le calme : de cette confiance naît le calme : la plupart du temps, je ne sens plus la pression du temps. Comme l’explique Uncle Bob, de même qu’un chirurgien opérant à cœur ouvert, je ne regarde plus la montre, stressé par le délai, mais je me concentre sur la tâche à accomplir, confiant sur le fait que seules mes pratiques me permettront de respecter les délais.
XP n’est bien sûr pas magique. Il ne nous a pas transformé en bons commerciaux, la pluri-disciplinarité a ses limites. Le caractère de chacun est également une composante pas toujours facile à gérer en pair programming. De plus, le plus simple qui fonctionne, après plusieurs années de développement, devient nécessairement compliqué. XP gère bien mieux ce souci que d’autres approches, mais le problème persiste.
D’un point de vue plus large, en adoptant les valeurs d’XP, je me suis rendu compte que ma propre satisfaction passait par la satisfaction d’un tout. Le fameux principe de bénéfice mutuel. C’est pourquoi j’ai quitté le monde des SSII, même si j’en garde un bon souvenir, car opposer mes intérêts à ceux des clients, opposer mes intérêts à ceux des commerciaux, opposer mes intérêts à d’autres développeurs, n’était clairement plus pour moi un moyen de fonctionner qui me convenait.
Je ne peux au final, comme nous le faisons en formation ou coaching, que conseiller de s’accrocher à ceux et celles qui débutent cette route. Le jeu en vaut tellement la chandelle!