Dans le monde du développement de logiciels, la dette technique n’est pas une inconnue. Elle représente le prix que vous payez pour les efforts supplémentaires que vous devrez livrer à l’avenir parce que vous n’optez pas ou ne pouvez pas opter, consciemment ou non, pour la meilleure solution mais pour la solution la plus acceptable à ce moment-là. Comme évoqué dans un blog précédent, les raisons de la dette technique peuvent être diverses et son existence n’est pas intrinsèquement mauvaise, voire insurmontable, tant que son niveau critique n’est pas dépassé.
Le malentendu réside cependant dans le fait que la dette technique est souvent associée à des systèmes hérités dits « obsolètes », plutôt qu’à des développements logiciels Agile « modernes ». Pourtant, c’est précisément le caractère itératif et incrémental d’Agile et la volonté d’atteindre les sprints présupposés qui créent le risque que vous soyez peut-être plus rapidement tenté de prendre des raccourcis ou des chemins de traverse et d’introduire ainsi une dette technique dans votre projet de logiciel. Il est donc important dans les projets Agile, d’être également conscient de la dette technique et des possibilités de sa constitution.
Complexité essentielle et accidentelle comme référence pour la dette technique
En soi, toute personne active dans le développement de logiciels a une certaine notion intuitive de la dette technique. Des concepts tels que la complexité essentielle et accidentelle peuvent aider à renforcer cette notion de manière concrète, comme critère de prise de conscience et de remédiation.
L’approche de la complexité essentielle et accidentelle nous vient de Fred Brooks1, qui affirme que le logiciel – la solution – a une certaine complexité essentielle inhérente à la complexité du problème que vous souhaitez résoudre avec celui-ci. En revanche, la complexité accidentelle est une complexité ajoutée, évitable. Il s’agit d’une conséquence d’une action humaine – volontaire ou involontaire –, ce qui nous amène au rapport avec la dette technique.
La complexité essentielle est intrinsèquement liée à la création de valeur est donc inévitable. Si vous y touchez ou si vous essayez de (trop) la limiter, cela entraîne souvent une simplification et une réduction de valeur, ce que vous voulez bien entendu éviter. Il s’agit donc surtout de minimiser la complexité accidentelle, précisément parce qu’elle n’apporte aucune valeur ajoutée, bien au contraire.
Ne jouez pas à cache-cache
Cela peut sembler simple ou évident, mais ce n’est certainement pas toujours le cas. Le développement de logiciels est souvent une donnée complexe. C’est pourquoi il est important de rendre transparentes la complexité accidentelle et la dette technique qu’elle engendre et, tout comme pour la complexité essentielle, de les répertorier et les rendre tangibles pour tous les stakeholders, y compris le business.
En reprenant aussi systématiquement la complexité accidentelle dans le Product backlog, vous créez cette transparence nécessaire. Le backlog est d’ailleurs un artefact vivant qui s'y prête parfaitement. Le Product Owner peut alors décider avec l’équipe de développement et en concertation avec le business à quelle dette technique il faut s’attaquer et quand, et à laquelle pas (encore). Il doit s’agir d’un choix délibéré, sachant qu’il y a une dette technique et que vous la traînerez avec vous si elle n’est pas éliminée.
Une priorisation Pareto (en bref, selon la règle 80/20 connue) en fonction de la création de valeur constitue à cet égard un principe sain. Car ramener l’intégralité de la dette technique à zéro est une illusion, notamment en raison de « l'économie » qui se cache derrière les faits. L’absence d’élimination d’une dette déterminée est d’ailleurs aussi un choix valable, du moment qu'il est délibéré.
