Lors de l’open space Agile Innovation 2014 j’ai proposé un sujet sur la place du code par rapport à la vision, c’est à dire : Est-ce que les pratiques d’ingénierie doivent être alignées avec la vision du projet (et donc ses contraintes) ?
La réponse à cette question me semblait simple, et pourtant, suite aux nombreux échanges de qualité avec les participants, je me suis rendu compte que la question était beaucoup plus complexe que ce qu’elle semblait être … et donc que sa réponse allait également être difficile à trouver.
Parmi les différents éléments constitutifs de cette question, nous avons abordé des aspects comme la qualité, l’excellence technique, le plaisir, l’apprentissage, la compétence individuelle, la prise de conscience, la connaissance partagée … en voici ma restitution.
Qualité et Excellence technique
Lorsque je parle du code, certains entendent qualité et d’autres excellence technique, ce qui conduit à des comportements très différents.
La qualité peut se mesurer, plus ou moins bien d’accord, avec par exemple un nombre de bugs dans une application en production. On peut donc se fixer un objectif en terme de qualité et accepter, par exemple, de lancer un produit avec certains bugs. Comme la qualité a un coût, une équipe peut arbitrer l’équilibre entre le niveau de qualité et le périmètre fonctionnel (qui a un cout également). Cet arbitrage est fait en fonction de la vision du projet, ou de l’entreprise, et donc la qualité est bien dans la vision.
L’excellence technique est beaucoup plus difficile à évaluer, et d’ailleurs on peut même penser qu’elle n’a pas de limite puisqu’il se trouvera toujours une personne capable d’améliorer du code écrit par d’autres personnes. De plus, chaque développeur à une conscience différente de ce qu’est l’excellence technique pour lui même, ce qui peut créer des conflits lorsqu’il va devoir travailler avec d’autres développeurs qui n’auront pas forcément la même conscience. Il devient donc beaucoup plus difficile d’aligner excellence technique et vision.
Apprentissages
Une société est une organisation apprenante qui doit nourrir ses employés et les aider à progresser.
Par exemple, un développeur qui ne connait pas le TDD doit pouvoir, au sein de son entreprise, disposer de temps pour progresser dans cette technique qui est une pratique incontournable du développement logiciel agile. Lors de cette phase d’apprentissage, il sera moins performant, ce qui est parfaitement normal (Lorsque Tiger Wood a décidé de changer son swing, il a été moins performant durant 2 ans pour revenir encore plus fort ensuite). C’est également vrai pour le perfectionnement dans une technique déjà connue.
Idéalement l’apprentissage se fera dans le cadre du projet. Il est donc nécessaire que d’assurer que les contraintes du projet (dans ce cas le délai) sont compatibles avec cette phase d’apprentissage, ce qui permet donc d’aligner la vision et le code.
Si ce n’est pas possible dans le contexte du projet, il faudra que l’entreprise assure à chaque développeur le temps nécessaire pour faire cet apprentissages entre 2 projets afin que la compétence individuelle de chacun se développe.
Plaisir
J’avais totalement oublié cet aspect dans mon équation du départ, quelle erreur !!!
En effet, je me posais la question de l’alignement du code et de la vision en oubliant les conséquences de faire cet alignement, et en particulier comment les développeurs le vivraient.
Si un développeur trouve du plaisir à faire de l’excellence technique (dans sa définition personnelle) et que les contraintes du projet (la qualité nécessaire pour la vision) l’obligent à faire des choses qu’il considère comme anormale (ou old school), il va perdre un de ses leviers de motivation et sera donc moins performant … et donc le projet aura encore plus de risque d’échouer.
Et l’inverse génère également la même conséquence. Si un développeur est poussé par le reste de l’équipe, ou un expert, à atteindre un niveau d’excellence qui ne lui semble pas pertinent, et parfois simplement argumenté par un « C’est comme cela que l’on doit faire du code maintenant », alors il ne prend pas de plaisir et devient beaucoup moins performant.
Avec ces éléments de réflexion, je commence à comprendre pourquoi il est si difficile de répondre à la question initiale.
Connaissance partagée
Lorsque l’on pose la question de l’alignement du code et de la vision, cela revient à demander à un développeur d’évaluer l’impact de l’utilisation d’une pratique d’ingénierie, comme par exemple le TDD, sur le business qui sera réalisé avec le produit.
Généralement le développeur ne dispose pas des compétences nécessaires pour évaluer ces impacts, et parfois même, considère ce sujet comme secondaire,voir inutile, puisqu’il ne rentre pas dans sa sphère d’intérêt.
De toutes façons, le développeur ne devrait pas être le seul à devoir faire le chemin et les personnes du métier/business devraient également faire une partie de ce chemin. Par exemple, il est nécessaire qu’une personne du métier comprenne en quoi le choix de structure de la gestion de configuration influence le modèle économique de vente des versions successives du produit.
La plus grande difficulté pour partager cette connaissance est le fait qu’il n’existe pas de langage commun entre métier et développeur (et je pense qu’il n’en existera jamais), il est donc nécessaire que chaque partie fasse un effort pour parler le langage de l’autre … ce que généralement les gens ne savent pas faire, ou pire encore, ne veulent pas faire (et parmi les phrases déjà entendue qui ne font rien progresser : « moi je sais ce qu’il faut faire, c’est aux autres de faire l’effort de me comprendre »).
Prise de conscience
Si votre lecture vous a conduit jusque là, vous devez vous demander ce qu’il faut faire pour votre équipe ou votre projet ?
Parmi les participants à cette discussion, il y avait quelques personnes dont les équipes fonctionnaient très bien et qui ne rencontraient pas ce type de problème. C’est super, j’espère qu’ils en profitent et qu’ils ont conscience de leur situation, par contre, il leur était difficile de décrire le mode opératoire qu’ils avaient utilisé pour arriver dans cette situation. Il n’y a bien entendu pas de réponse, ou de solution, toute faite et chaque équipe devra trouver la sienne.
Néanmoins pour le mode opératoire, je partage avec vous un élément apporté par l’un des participants : « Tant que tous les membres de l’équipe n’ont pas pris conscience de la situation, il est vain d’espérer les voir changer de comportement » et j’espère que cet article pourra aider votre équipe à prendre conscience de cette situation.
Quelques remarques sur ce billet très intéressants.
Mesurer la qualité que sur le code n’est pas suffisant, nous (les développeurs) sommes là pour créer de la valeur pas créer du code. Oui la qualité a un cout, mais son absence se paie aussi au prix fort (mais plus tard).
Concernant la qualité je dirais qu’il n’y a pas de code parfait (ceux qui cherchent la perfection ne trompent), par contre je pense qu’il y a une culture du code: une startup va forcément essayé de livrer vite plutôt que bien car c’est la survie de la société qui est en jeu, même elle accumulera cette fameuse dette technique dont on nous parle tant, tandis qu’une société mature va éviter qu’elle apparaisse.
On ne peut pas non plus forcer quelqu’un à adopter des pratiques qu’il ne comprend pas. L’éducation est primordiale dans la qualité (en plus de la prise de conscience) C’est pour cela qu’un développeur qui ne se remet pas en cause n’est pas un bon développeur.
Pour terminer, concernant le plaisir, cela sous entend que tout le monde ait un travail qu’il lui plait, ce n’est pas toujours le cas.
Ce que je retiens moi de cette intéressante et difficile conversation, c’est qu’il faut arbitrer les risques que l’on prend à ne pas utiliser telle ou telle pratique et le coût que cela à d’utiliser telle ou telle pratique. Et avoir cette conversation de façon explicite et décomplexée, au bon moment.