C’est le titre d’un excellent article (dont je m’inspire fortement), publié sur Agile Zone, qui montre que les pratiques agiles peuvent très bien s’appliquer dans un contexte de maintenance. Certes, la littérature abonde d’articles ou de retours d’expérience sur le lancement de projet Agile mais ces pratiques peuvent être déclinées à d’autres contextes, comme le support, le marketing et bien sûr la maintenance de logiciel.
Un logiciel, dés lors qu’il arrive en production, entre dans un cycle de maintenance dédié aux corrections de bogues et aux évolutions logicielles. Les méthodes agiles peuvent rentrer en jeu pour rythmer ce cycle, en lui donnant par exemple une dynamique de sprints et le faire avancer vite et sûrement grâce à des concepts comme l’intégration, la livraison et le déploiement continu.
Si le logiciel a été développé sur des bases agiles, la transition vers la maintenance logicielle agile se fait sans problème. En revanche, il est plus difficile d’introduire ces pratiques dans une équipe de maintenance rodée au cycle en V, qui s’est organisée pour produire une réponse rapide à un bug en production et minimiser le risque sur les évolutions. Dans ce dernier cas, on constate une évolution lente du logiciel car maintenir la stabilité du logiciel demande beaucoup d'énergie au détriment des évolutions. Basculer vers la maintenance agile apporterait beaucoup à cette équipe habituée au cycle en V: l’introduction de pratiques XP permettrait par exemple de minimiser les bugs en production, de redonner confiance à l’équipe et au management qui consacreraient plus de temps pour travailler sur les évolutions: la valeur ajoutée.
De manière générale, les méthodes agiles peuvent être appliquées à la maintenance logicielle mais chaque équipe devrait s’interroger sur la manière de les adapter à leur propre situation. Personnellement, j’apprécie l’approche ScrumBan; elle convient plutôt bien à la problématique de maintenance logicielle.
L’agile en maintenance logicielle
Le planning game
Cet exercice est un peu plus délicat pour une équipe de maintenance qui doit faire face à des perturbations plus importantes qu’une équipe dédiée au développement. Typiquement, on retrouvera des activités de corrections de bug plus ou moins urgentes, des mises en production, du support, etc. L’équipe de maintenance devra intégrer ces contraintes afin d’estimer au mieux le potentiel de valeur ajoutée qu’elle pourra produire durant la prochaine itération. Elle peut aussi agir sur son organisation en minimisant les perturbations unitaires, c’est à dire en réservant certains jours des personnes à du développement tandis que d’autres sont associées à du support et/ou de la correction de bug et vice-versa.
Les standups meeting
Ces petites réunions quotidiennes où chacun fait le point sur son avancement gardent leur intérêt en maintenance logicielle. L’équipe discute des activités de développement, de support, des correctifs de bugs et mesure la tendance de l’itération: un évènement peut avoir des conséquences importantes sur les objectifs fixés durant le planning game auquel cas, le product owner ou chef de projet devra définir de nouvelles priorités.
Des releases fréquentes de petites tailles
La gestion des versions logicielles est assez complexe en maintenance logicielle. L’équipe de maintenance peut être amenée à travailler sur plusieurs générations différentes du logiciel: la branche de développement courante (mainline) et les branches de maintenance des versions précédentes du logiciel.
Concernant la branche principale, elle héberge le code source de la prochaine release du logiciel. Les autres branches de développement servent aux mises à jour mineures des précédentes versions (correction de bug par exemple).
Durant le planning game, le focus est mis sur le contenu de la prochaine release tout en prenant en compte la charge de maintenance des précédentes versions. Fonctionner en itérations courtes permet à l’équipe et au client de s’organiser plus facilement, notamment sur les aspects tests. Le client accepte plus facilement la stabilité de l’itération puisque le “travail en cours” qu’il aurait re-priorisé immédiatement pourra être discuté dans quelques jours, lors de la prochaine itération.
Les itérations courtes permettent notamment d’éviter l’effet tunnel et de livrer fréquemment un logiciel de qualité à forte valeur ajoutée. Les défauts sont repérés et corrigés plus rapidement.
Les rétrospectives
Les rétrospectives sont importantes en maintenance logicielle pour discuter des problèmes rencontrés et motiver l’équipe à proposer des solutions, à aller dans le sens de l’amélioration continue.
Le binômage et la responsabilité de code
Le binômage n’est pas évident à installer dans une équipe qui s’est laissée aller à la spécialisation (les développeurs se sont entendus sur leur responsabilités vis-à-vis de certaines parties du code source). C’est pourtant un très bon exercice pour partager naturellement les connaissances et bénéficier d’un autre avis sur la solution à implémenter. Si le binômage est compliqué à mettre en place, une bonne alternative est la revue de code, où un développeur prend un peu de temps pour relire le code de son collègue.
Une conception simple et la refactorisation
Les équipes de maintenance sont tributaires de conceptions et d’architectures souvent complexes et anciennes. Il est alors risqué d’ajouter de nouvelles fonctionnalités dans de tels systèmes dont le périmètre n’est pas bien connu de l’équipe. Cette dernière aura tendance à minimiser le risque en évitant de toucher à l’existant et créera des traitements particuliers pour chaque nouveau développement. Malheureusement, cela éloignera encore plus l’équipe de la maîtrise du système.
Il est important que l’équipe connaisse l’architecture du logiciel car elle sera capable d’identifier si un nouveau besoin client remet en question la conception actuelle et proposera dans ce cas un scénario de transition. Cette transition se traduira par un ensemble de taches de refactorisation et l’adaptation des tests unitaires liés.
Le développement piloté par les tests
Disposer de tests unitaires est indispensable en maintenance logicielle: l’équipe intervient sur un système complexe qu’elle ne maîtrise pas forcement => risque important de régression.
Le développement piloté par les tests est une pratique qui incite à écrire des tests unitaires avant d’écrire le code source de la fonctionnalité. Une équipe de maintenance qui souhaite utiliser cette approche pourra commencer par écrire des tests unitaires pour les nouveaux développements et sur les bugs rapportés. Elle peut également s’interroger sur les composants critiques sur lesquels il est bon d'invertir quelques tests. L’équipe peut s’appuyer sur un outil de couverture de code afin mesurer les parties non testées du programme et se donner des objectifs de couverture au fil des itérations.
L’intégration continue
Cette technique est idéale pour une équipe de maintenance logicielle. Elle permet de détecter les régressions de l’application à chaque modification de code. Pour travailler en intégration continue, l’équipe devra se doter d’un serveur d’intégration (comme CruiseControl par exemple) et s’imposer d’intégrer quotidiennement les modifications (tests unitaires compris) sur la même branche de développement. Le serveur sera en charge de la compilation, du lancement des tests unitaires, de la création de rapports (qualité du code, couverture de test, etc.), de la création de la documentation et du test de l’application dans un environnement de production. Cette dernière tâche est associée aux tests de non régression automatisés qu’un autre serveur peut opérer afin de soulager le serveur de build.
L’avantage est de pouvoir confronter très rapidement le nouveau code source de l’application à l’environnement de production. Les problèmes sont visibles immédiatement et une version de l’application est toujours disponible pour démonstration ou distribution.
Pour résumer
Les méthodes agiles peuvent apporter beaucoup à une équipe de maintenance logicielle. Même si le contexte est diffèrent du modèle projet (itérations inégales, perturbations plus importantes), il y a de bonnes choses à aller piocher parmi les pratiques agiles.
L’équipe est amenée à travailler sur plusieurs branches de développement en même temps: la mainline qui héberge le code de la prochaine release, la ou les branche(s) de maintenance de précédentes versions de l’application et les branches d’exploration dédiées aux évolutions complexes qui s’étalent sur plusieurs itérations. Les itérations courtes permettent de rythmer les développements et livraisons des versions de release et de maintenance.
Travailler en intégration continue permet à l’équipe de maintenance de se concentrer sur le développement puisque les bugs de production se raréfient. Elle peut aussi s’accorder du temps pour peaufiner ses tests de non régression automatisés.
Pour conclure, une équipe de maintenance à tout à gagner à basculer vers l’agile, notamment sur les aspects organisation, qualité et livraison.