Projets agiles : piloter la qualité en mesurant la dette technique
Le concept de dette technique est un outil puissant et pragmatique pour piloter l’aspect qualité du code d’un projet agile. La méthode SQALE apporte un cadre formalisé pour la mise en œuvre de son suivi.
La grande majorité des organisations informatiques subissent une pression importante de la part de leurs utilisateurs pour livrer les projets dans des délais de plus en plus courts. C'est la conséquence du fait que la chaine de valeur repose souvent sur des solutions informatiques. Comme nous vivons dans un monde de plus en plus concurrentiel, la performance d'une organisation dépend de plus en plus de la capacité d'une DSI à répondre ou anticiper un besoin de la meilleure manière possible et dans les meilleurs délais.
L'agilité comme réponse à la réactivité
C'est dans ce cadre et avec un objectif d'améliorer l'anticipation et la réactivité que les DSI déploient de plus en plus des méthodes agiles. Du moins pour la partie du portefeuille de projets qui s'y prête.
En effet, ces méthodes ont, entre autres, la particularité de focaliser les équipes sur la satisfaction des besoins des utilisateurs. Cela à travers à travers des pratiques particulières telles que :
- l'implication permanente d'un représentant des utilisateurs,- la livraison à cadence très rapprochées de versions "opérationnelles".
Un risque sur la qualité du code
Toutefois, il y a un revers à cette médaille. Pour pouvoir tenir l'objectif de présenter à l'échéance prévue les fonctionnalités retenues pour le sprint, les développeurs peuvent être amenés à faire des entorses provisoires aux bonnes pratiques de développement. Ainsi, dans le cadre d'un projet agile et afin de garder une bonne vélocité, ils peuvent être amenés à pratiquer le copier/coller, à coder en dur des variables, et à négliger ce qui impacte la maintenabilité.
Il va de soi, que ces déviations, ces entorses sont temporaires et que les développeurs doivent remettre tout en ordre à un moment donné. Mais, du fait que ces entorses ne sont pas directement visibles, ni par l'utilisateur, ni par la maîtrise d'ouvrage, il est de la responsabilité du projet de les suivre et de les traiter.
Ces dérives potentielles ont été identifiées depuis déjà quelques années comme devant faire l'objet d'une attention particulière. Ward Cunningham, un des signataires du manifeste agile et aussi le père du wiki a utilisé pour cela une métaphore. Il parle de la dette technique accumulée par les projets en prenant l'analogie avec les prêts bancaires pour expliquer que tant cette dette n'est pas remboursée, on en payait le prix à travers des intérêts. Ces intérêts se concrétisant par le surcout de temps pour faire évoluer ou maintenir l'application. C'est-à-dire une baisse notable de la productivité, appelée vélocité dans les projets agiles.
Cette dette technique peut être accumulée sciemment (du fait des concessions faites pour tenir les objectifs du sprint) ou inconsciemment (par manque de connaissance des bonnes pratiques d'architecture ou de codage).
Manager les projets agiles avec la dette technique
Pour éviter cette baisse de productivité et donc de réactivité par rapport aux utilisateurs, il est nécessaire de suivre attentivement cette dette technique et d'allouer régulièrement du temps pour la résorber par des opérations de refactoring. Il est donc recommandé d'intégrer la dette technique dans les indicateurs de suivi du projet. Ceci en complément d'indicateurs classiques tels que le backlog et la vélocité.
Si cette dette est estimée de façon claire et précise, cela permettra un meilleur pilotage du projet.
Prenons, comme exemple, le cas d'un comité de pilotage de projet à qui l'on rapporte les valeurs suivantes :
- Fonctionnalités implémentées : 80% (en points),- Charge consommée : 360 j.h. (en 4 mois),
- Dette technique : 63,5 jours.
Avec ces chiffres, il obtiendra une représentation objective de la situation. Pour mener à terme le projet, il reste à planifier et réaliser une charge de 90 j.h (pour l'aspect fonctionnel) et 63,5 j.h. (pour l'aspect qualité), soit 153 j.h. Ce calcul permet d'estimer de façon plus réaliste la date de mise en recette du projet. Ceci, sous réserve que l'implémentation des fonctionnalités restantes ne crée pas un supplément de dette technique.
La méthode SQALE pour gérer la dette technique
La méthode SQALE est connue pour permettre une évaluation objective de la qualité du code source d'une application. Elle a été publiée en aout 2010 en licence Open Source (sur le site sqale.org) et déjà quatre éditeurs d'outils d'analyse statique de code l'ont implémentée et produisent les indices et les indicateurs définis par la méthode.
De nombreuses organisations (dans le monde de la banque, de l'assurance, des télécoms, de l'automobile...) la mettent en place, tout particulièrement pour le suivi des projets agiles.
Les principales raisons de ce choix sont les suivantes :
- La méthode SQALE, à travers le concept de modèle qualité, demande de bien définir ce qui crée et ne crée pas de la dette. L'équipe du projet sait exactement ce qu'il en est et la présence d'une dette n'est pas un constat subjectif sujet à discussion d'experts.
- La méthode calcule de manière précise cette dette. Il s'agit de l'indice SQI (SQALE Quality Index) définit par la méthode. Il suffit de suivre cet index (par exemple en jours) pour savoir si cette dette croit ou stagne. Sa valeur est, par définition, une estimation de la charge de travail nécessaire pour résorber la dette.
- La méthode permet une analyse approfondie de cette dette et de son impact sur le cycle de vie du projet. Elle aide donc à prendre les décisions concernant les priorités de refactoring.
Bien que simple à comprendre, le concept de dette technique est un outil puissant et pragmatique pour piloter l'aspect qualité du code d'un projet. La méthode SQALE et la panoplie d'outils qui la supporte apportent un cadre formalisé pour la mise en oeuvre de son suivi et apporter des indicateurs puissants pour un meilleur pilotage des projets.