La fin de la "dette technique" : résoudre les conflits

Dans les articles précédents, j'ai essayé d'établir sur la base d'exemples (simples) cette observation :

Lorsque nous considérons une solution logicielle existante, nous parlons souvent de la "dette technique" qui caractérise cette solution. Par ce terme, nous voulons pointer un certains nombre de défauts de qualité (de maintenabilité, etc.), qui sont comme autant de manquements à un état de l'art communément admis, lequel reste en fait indéfini et hypothétique.

Le terme de “dette technique”, popularisé par Ward Cunningham, désignait initialement un procédé particulier de conception de logiciel. Il a vu son usage s'étendre au point qu’il désigne désormais une sorte d’état global de la non-qualité dans système logiciel, état que l'on pourrait quantifier, outiller et gérer. Le terme s'est pour ainsi dire vidé de son sens -- sans doute à force de désigner un phénomène apparemment incontrôlable — et il a rejoint la cohorte des abstractions vagues qui caractérisent nos activités de création de logiciel : "bugs", "couverture de test", "qualité"…

Je propose de remplacer dans mon travail l'expression :

cette solution comporte de la dette technique

par l'expression :

cette solution repose sur des procédés (heuristiques) en conflit

Ces conflits ont pu apparaître dès le cadrage du projet initial (a fortiori en l’absence d’un cadrage initial), ou bien au fur et à mesure de la réalisation, puisque l’état de l'art du projet — c'est à dire l'ensemble des procédés heuristiques choisis (délibérément ou implicitement) pour produire une solution — peut de toute évidence évoluer en fonction des changements apportés aux contraintes, au contexte et aux objectifs du projet, ainsi qu'à l'équipe en charge de le réaliser.

Dans cet article, je me propose d'explorer le sens de l'expression "conflit de procédés" dans le contexte d'un projet de développement logiciel, et de clarifier en quoi cette expression indique la voie à suivre pour une équipe lorsqu'elle cherche à produire de manière optimale une solution répondant le mieux au problème posé.

Le terme conflit est ici choisi (plutôt que les termes : différence, tension, opposition, ou affrontement...) dans le but de rappeler qu'en général il y a exclusion mutuelle des procédés heuristiques à mettre en œuvre face à une situation particulière (et précise) donnée. En ingénierie, le consensus en vue de sélectionner le procédé optimal pour un contexte donné produit une bien meilleure solution que le compromis (i.e. mettre en œuvre "un peu de chaque" procédé). Par exemple, si votre équipe hésite entre deux frameworks pour industrialiser un même aspect de sa solution, le choix d'un framework (même imparfait) produira une bien meilleure solution qu'un usage mitigé des deux frameworks. En d'autres termes, il y a conflit de procédés dans la mesure où l'on recherche un consensus sur une solution, et non un compromis. Ou bien encore : un compromis de procédés dans votre état de l'art dénote un conflit non résolu entre ces procédés dans votre état de l'art.

Une équipe dans le conflit ?

La palette de conflits possibles dans l'état de l'art d'une équipe au cours de la réalisation d'une solution, ou au cours de son évolution, est à la fois riche et nuancée. La façon elle même dont ces conflits émergent est éminemment variable :

• conflits explicites : règles en contradiction, exceptions flagrantes au standard,
• conflits implicites : ce que l'on dit ou écrit vs ce que l'on fait,
• conflits frontaux : délibérations sans résolution, manquements observés mais non corrigés,
• conflits indirects : changements intempestifs, progressifs, contournements,
• conflits internes : abandon de pratiques par une partie de l'équipe,
• conflits externes : demandes explicites d'abandon, d'adoption ou d'altération d'un procédé, coercition.

Une telle richesse peut donner à penser que les équipes de développement logiciel vivent et s'épanouissent dans le conflit. Il n'en est évidemment rien. Au quotidien, l'équipe applique son état de l'art, et le raffine, au cas par cas, afin de se rapprocher de l'objectif qu'elle s'est fixée, à savoir :

produire la meilleure solution à un problème encore mal compris, dans une situation incertaine, et à l'aide de ressources limitées

Si les conflits de procédés parsèment l'activité de l'équipe tout au long de son projet, pour autant le mode de communication que cette équipe adopte pour construire la solution n'est pas en soi conflictuel. Au contraire, c'est parce que l'équipe recherche un consensus — c'est à dire une harmonie dans les procédés, visant à une solution optimale pour les objectifs et contraintes donnés — qu'elle traverse délibérément, et résout, aussi rapidement que possible — tous ces conflits.

Trois types de conflits

Ces conflits de procédés sont des "conflits d’idées" et non des "conflits de personnes". Ce ne sont pas des "problèmes de communication". Ce sont, en quelque sorte, des débats d'idées à propos des meilleurs procédés à appliquer dans chaque situation, et qui reflètent le jeu des forces en présence dans ce travail de recherche d'une solution par l'équipe (au sens large).

Par exemple, étant donné que son projet est en retard face au planning estimé initialement, une équipe se considère en demeure de choisir entre sa stratégie habituelle de prévention des défauts, basée sur l'écriture de tests unitaires systématiques, et une approche "code & fix", dans laquelle elle ne testera le code qu'une fois assemblé et livré en environnement de recette. En considérant ce changement de procédé, qu'elle suppose ou espère temporaire, elle convertit un conflit de ressources :

il y a plus de tâches à réaliser que de temps pour réaliser ces tâches (la ressource en question étant ici le temps)

en un conflit de procédés :

il faut choisir entre la stratégie initiale de prévention des défauts et une solution reposant plutôt sur des expédients.

Il est probable qu'une partie de l'équipe militera pour la préservation de la stratégie (parce que cette stratégie préserve l'intégrité de la solution à long terme) et qu'une autre partie défendra un compromis permettant de "sauver" un jalon. Il est possible que la conversation s'ornemente d'épithètes un peu rudes comme "dogmatique" ou "irresponsable"; mais il est très rare (quoique spectaculaire lorsque cela arrive) que les conflits d'idées ou de ressources, se transforment en conflits de territoires ou de personnes.

Cette observation me semble importante à souligner, parce que dans beaucoup d'organisations la crainte (justifiée) des conflits de personnes conduit à un évitement des conflits d'idées, ce qui est à mon avis la pire menace pour une équipe en charge de concevoir une solution logicielle. Certes l'entreprise n'est pas exempte de batailles politiques, c'est à dire en fin de compte, de conflits de territoires et de personnes. Comment mènerait-elle, par exemple, un changement global, une transformation, sans jamais rencontrer aucune opposition ? Cependant les conflits de procédés au sein d'une équipe de réalisation subissent rarement un tel changement de dimension des idées vers les personnes. (Il y aurait beaucoup à dire sur les conflits de personnes, et le triangle dramatique, au sein des organisations, mais ce n’est à mon sens qu’un facteur indirect du phénomène qu'on appelle "la dette technique").

Les conflits de ressources

Si les conflits de personnes sont incontestablement une source de démotivation, de gâchis et de violence à éviter, les conflits de ressources sont eux, inévitables. Avez-vous déjà mené ou observé un projet logiciel qui disposait de plus de temps ou de moyens que nécessaire, aux yeux de tous les acteurs de ce projet ? On rencontre certes parfois des projets qui semblent (temporairement) bénéficier d'une telle abondance, mais cela est très souvent lié à l'absence d'objectif clair et concret. En temps normal, étant donné que nous cherchons la meilleure solution à un problème mal compris, dans une situation incertaine, les idées que nous projetons pour résoudre ce problème viennent nécessairement heurter la limite des ressources qui nous sont affectées. Les conflits de ressources sont le lot de toute activité humaine organisée, qu'elle soit industrielle ou non.

Les conflits d'idées

Quand aux conflits d'idées, ils sont indispensables à toute amélioration de l'état de l'art. En effet, c'est seulement lorsque deux procédés, l'un appartenant à votre état de l'art, l'autre n'y appartenant pas encore, sont comparés, que vous pouvez décider si le nouveau procédé doit entrer dans l'état de l'art, et dans quel contexte, et à quelles conditions, etc. Cette amélioration par enrichissement, cette réforme, ou ce réaménagement de votre état de l'art, ne s'opère pas par hypnose ou à coup de décrets, mais par une appropriation des nouveaux procédés, laquelle passe ordinairement par une phase initiale de désaccord, et ensuite par une phase d'examen et d'adaptation de ceux-ci.

En conséquence, le moyen le plus efficace d'améliorer votre état de l'art pour un contexte donné, c'est à dire d'augmenter vos chances de succès dans la poursuite d'une solution adaptée à ce contexte, consiste à :

• recenser et expliciter les procédés que comprend votre état de l'art ;
• mettre ces procédés en regard les uns des autres, comparer leur résultats possibles, les expérimenter ;
• sélectionner le meilleur procédé dans les circonstances données.

Cette "mise en compétition" des procédés est donc une activité essentielle de l'équipe de développement. Elle est d'autant plus importante que l'équipe considère non seulement la solution qu'elle a à créer mais aussi le contexte général environnant l'équipe aussi bien que la solution : pour peu qu'elle adopte une approche agile, le périmètre de la solution sera amené à changer, de manière délibérée et explicite ; l'état de l'art global de branches entières de l'industrie (par ex: les technologies "front") évolue rapidement (ce qui est un atout aussi bien qu'un inconvénient, à condition que l'équipe ait les moyens de faire évoluer son état de l'art) ; une observation même superficielle du marché montre qu'il n'y a aucun avantage à se fixer trop longtemps sur un état de l'art à un instant donné, car on risque de s'enfermer dans des voies technologiques en impasse. (L'enjeu important étant alors d'améliorer son état de l'art, et non simplement d'en changer).

Équipe remarquable et résolution de conflits

Pour résumer, il existe donc au sein de l'activité d'une équipe (au sens large) en train de créer une solution logicielle trois types de conflits :

• les conflits de personnes ou de territoire, qui sont une source de gâchis et de violence ;
• les conflits de ressources, qui sont inévitables ;
• les conflits de procédés, qui sont indispensables.

Les procédés qui résident au sein de l’état de l'art sont des idées "efficaces", c'est à dire des idées dont l'application vise un impact immédiat et à long terme sur le résultat de l’équipe. Une équipe qui cherche à améliorer son état de l’art pour une solution visée cherchera donc à y faire entrer de nouveaux procédés. Une équipe remarquable procèdera aussi régulièrement que possible à une sélection explicite des meilleures idées. Dans une approche agile par exemple, cette sélection se fera en binômant, en débriefant une session de programmation, en organisant des points techniques, à l'occasion de backlog grooming, en rétrospective, ou au cas par cas. Les modes et les outils de décisions d'une équipe remarquable sont nombreux et variés, et ils ne sont pas limités par avance.

Lorsqu’une telle sélection des idées n'a pas lieu, et que des procédés restent en conflit dans l'état de l'art de l'équipe, et que ces conflits ne sont pas résolus rapidement, alors l'équipe intègre ces conflits, et elle produit une solution "conflictuelle" en termes de procédés, c'est à dire une solution sous-optimale. Une solution que, plus tard, en l'examinant depuis l'extérieur du projet, quelqu'un qualifiera (superficiellement) de "techniquement endettée".

La clé d'un état de l'art en harmonie dans une équipe pour un projet donné, ne consiste donc pas à éliminer par avance ou éviter les conflits de procédés (c'est impossible). Elle consiste à résoudre efficacement ces conflits. Une équipe qui ne traverserait aucun conflit de procédé est, d'un point de vue ingénierie et conception logicielle, une équipe à l'agonie. Elle applique un savoir et un savoir-faire figés, et très probablement inadaptés à la solution qu'elle cherche à créer.