Problématique
Un éditeur de logiciel a développé une solution depuis plus de 15 ans et commence à être confronté à des difficultés majeures:
- une connaissance du logiciel qui repose dur les personnes et n’est pas documentée
- des mises en productions qui sont suivies de bugs de plus en plus difficiles à traiter en amont
- un nombre croissant de versions en production à gérer, avec des spécifiques clients pour certaines versions
- des lenteurs du logiciel liées à un code de plus en plus important
- des temps de mises en production des évolutions de plus d’un an, avec des dérives par rapport au Planing initial
La situation est donc caractéristique d’une entreprise avec une dette technique = le code n’est plus contrôlé de manière correcte, les évolutions sont rares et longues à mettre en place, les bugs se multiplies.
L’enjeu est donc d’arriver à :
- mettre en place des cycles de développement plus courts, de l’ordre d’un mois,
- impliquer les équipes métier pour mieux spécifier les besoins,
- mettre en œuvre des sécurités sur la qualité du code avec des tests,
- réduire le code des développements spécifiques à quelques clients
Notre réponse
Après une analyse des mode de travail de l’équipe de développement, il a été identifié comme vecteur du changement de mettre en place un nouvel outil. Ainsi, le code qui été géré par SVN a été migré sous GIT avec l’usage de Gitlab.
Par le biais de ce changement, la mise en place d’une méthodologie agile a été rapidement visible pour tous. L’équipe de développement a été scindé par petits groupes de 3 développeurs et des rôles ont alors été mis en place = Product Owner et Tech Leader. Finalement des outils d’intégration continue ont été mis en place.
La mission s’est déroulé en 4 mois autour de 3 phases:
- une phase de mise en place des outils : il y avait de nombreux outils utilisés pour la gestion du code source, la gestion des tickets, la gestion des évolutions, les spécifications, le suivi des développements… beaucoup des informations étaient dispersées dans des fichiers Excel, des mails, des outils « maison » réalisés par l’équipe de développement. Un outil intégré qui permet à la fois de faire de l’intégration continue et de déploiement continu a été mise en place (Gitlab) avec comme point de départ la gestion du code source
- une phase de processus et de formation : les processus ont été revus pour associer en continu l’équipe métier sur le suivi des évolutions. L’équipe technique a été scindée en petites équipes de 3 personnes avec des focus spécifiques ; pour chaque équipe un Tech Leader est nommé et un Product Owner est associé pour accompagner les spécifications produits et permettre une recette au fil de l’eau
- une mise en place de l’intégration continue : les tâches de développement sont décrites et suivies dans Gitlab avec des échéances organisées en releases (cycles d’un mois), des tableaux de bords sont activés pour suivre les développements. Un suivi systématique à la documentation des tâches, des corrections et du code est mis en place. En outre, des tests automatiques sont intégrés à l’occasion de chaque mise à jour du code, par des tests unitaires et par des tests fonctionnels. Partant de zéro, les nouveaux développements ainsi que les corrections doivent intégrer systématiquement des tests unitaires ; des tests fonctionnels accompagnent la démarche sur le code existant.
De manière rapide et progressive, l’équipe de développement a basculé sur les nouveaux outils, ainsi que les Product Owners. La mise en place de cycles d’un mois a permis d’augmenter la productivité en réduisant de 6 mois à 1 mois la mise à disposition de nouvelles fonctionnalités. L’association des équipes métier tout au long des développements a permis une meilleure adéquation aux besoins. Surtout, l’introduction des tests unitaires et fonctionnels en automatique a amélioré les livraisons en réduisant de 75% le nombre d’incidents.
