Résumé de trois petites histoires de dette technique
Le présentateur était Bruno Morel de SeedBox. Il a été question de 3 méthodes pour réduire la dette technique qu’il a testée dans sa carrière jusqu’à maintenant.
La dette technique
Tout d’abord, la dette technique, dans le cadre du développement d’un projet, est inévitable. Si on ne fait rien, elle va augmenter rapidement. Ce qui a pour impact d'augmenter le nombre d’heures de développement requis pour maintenir l’application.
La dette technique est à plusieurs niveaux :
- L’architecture du projet n’a pas suivi l’évolution du projet
- Les tests sont de plus en plus difficiles à maintenir
- Le processus de déploiement est compliqué
- Les cadres d’application utilisés dans le projet sont passé date
- L’équipe n’a pas le temps de faire de l’exploration (soit pour tester de nouveaux outils, soit pour tester de nouvelle technique de développement)
Voici 3 solutions qui ont été testées par Bruno et leurs résultats.
Solution 1 : Un sprint de dette technique
Concept
À chaque X sprints (par exemple 4 sprints), l’équipe fait un sprint où aucune nouvelle fonctionnalité ne sera livré. Le sprint est entièrement consacré à réduire la dette.
Résultat
Facile à implémenter, mais pas si satisfaisant. Pour le Product Owner ça implique que pendant un sprint complet le projet ne semble pas avancé. Pendant les sprints réguliers, certaines tâches sont faites rapidement par les développeurs en se disant qu’il y a le sprint de dette technique pour améliorer le tout. Lors du sprint de dette technique, l’équipe n’est pas en mesure de tout réglé ce qui a un impacte négatif sur la motivation en plus de ne pas avoir le temps de faire de l’exploration. Même si c’est mieux que de ne rien faire, la dette continue à augmenter.
Solution 2 : Des spécialistes avec amélioration continue
Concept
Chaque membre de l’équipe se choisit une spécialité (front-end, back-end, Build server, …). À chaque sprint, une portion du temps (par exemple 15%) est réservé à chaque spécialiste (ou équipe de spécialiste) pour réduire la dette technique dans sa spécialité.
Résultat
Mieux que la première solution, mais ce n’est pas parfait. Le PO aime bien puisque la progression du logiciel est constante. Le problème c’est qu’il y a un débalancement de la dette à cause des spécialités. Par exemple il peut avoir très peu de dette technique dans le back-end mais une grosse dette dans le processus de déploiement.
Au final, il y a toujours une dette croissante.
Solution 3 : Amélioration logicielle (sans spécialiste)
Concept
Cette solution est similaire à la précédente sauf qu’il n’y a pas de spécialité. L’équipe choisie à quoi s’attaquer et c’est la responsabilité de l’équipe de le faire.
Résultat
La dette technique reste au minimum. Le PO est toujours content, car l’avancement du projet est constant. Puisque la dette est au minimum, les développeurs ont même le temps de faire un peu d’exploration. Par contre ça demande une bonne discipline de l’équipe pour prendre le temps de faire l’amélioration logiciel et de faire les bons choix de quoi améliorer.
Comment gérer l’amélioration logiciel
La méthode utilisée pour gérer les priorités se fait à l’aide de rencontre mensuelle où l’équipe de développement priorise les tâches à faire pour réduire la dette technique. Lors du “sprint planning” les tâches de dette technologie ne sont pas planifié ni évaluer. Par contre le sprint est prévu en fonction de garder 15% de temps libres pour faire l’amélioration continue. Les développeurs décident quand, dans le sprint, ils feront l’amélioration continue. Lorsqu’il s’attaque à l’amélioration continue, c’est la tâche du développeur de prendre la tâche en fonction de la priorité. Il ne doivent pas dépasser 15% du temps du sprint.
On peut dire que l’amélioration logiciel est gérée en mode Kanban à l’intérieur d’un processus Scrum.
