Sur plusieurs projets Agile peu matures, un même phénomène revient fréquemment. Si l’on observe une augmentation régulière de la productivité de l’équipe lors des premiers sprints, à un moment donné, un basculement se produit vers une baisse continue. Pourquoi cette inversion de tendance et comment y remédier ?
Du fait de sa nature itérative, l’Agile crée structurellement une inflation de tâches de test, d’intégration et de déploiement applicatif. Sans automatisation, à mesure que l’application se complexifie, ces tâches absorbent de plus en plus la charge disponible de l’équipe. De plus, comme elles doivent être déroulées dans un délai extrêmement contraint (2 à 3 semaines), une exécution manuelle augmente significativement le risque de non-qualité, par exemple en limitant le périmètre des tests de non-régression. A son tour, cette non-qualité va détourner l’équipe de la production de valeur. Par exemple, les développeurs vont passer de plus en plus de temps à corriger les régressions fonctionnelles au lieu de produire de nouvelles fonctionnalités.
Ceci induit que la pérennité de la méthode Agile en tant que levier de production de valeur aux utilisateurs impose une stratégie d’automatisation au service des besoins des équipes Agile. Car elle ne va pas seulement aider à mitiger les risques mais elle va aussi permettre de libérer du temps à l’équipe pour qu’elle continue à produire les fonctionnalités attendues par les utilisateurs.
AUTOMATISATION DES TESTS
Il existe plusieurs types de tests (tests unitaires, tests fonctionnelles, tests de performance…) avec des objectifs différents et exécutés par des profils différents (développeurs, testeurs, équipes de production…). Pour qu’une démarche d’automatisation des tests soit efficace, plusieurs points sont à respecter. D’abord, l’équipe doit prioriser les tests à automatiser en fonction de deux critères principaux : le volume de tests à exécuter (gain de temps) et les exigences non fonctionnelles importantes des clients (par exemple, le temps de réponse de certaines fonctionnalités). Ensuite, il faut intégrer l’activité d’automatisation à part entière dans le processus de delivery du projet pour qu’elle soit maintenue dans le temps. Enfin, l’automatisation des tests requiert des compétences spécifiques que l’équipe doit acquérir soit par des formations spécifiques ou en la renforçant par des spécialistes du sujet.
AUTOMATISATION DES DÉPLOIEMENTS APPLICATIFS
Pour un projet informatique, il existe toujours plusieurs environnements techniques (développement, recette, production…) qui correspondent à différentes étapes de son cycle de vie. Une mauvaise pratique observée chez certains clients consiste à avoir une rupture d’outil ou de méthode entre les environnements sous la responsabilité des développeurs et ceux sous la responsabilité de la production. Cette rupture se traduit par des opérations manuelles qui induisent des pertes de temps et des risques d’erreur. Pour être efficace, il est souhaitable que les équipes de développement et de production travaillent ensemble pour identifier un processus de déploiement automatisé « sans couture » de l’environnement de développement jusqu’à la production.
Si l’automatisation est une condition nécessaire pour qu’une équipe Agile continue à produire de la valeur sur la durée, elle peut néanmoins générer des tensions lors du choix des outils et de leur déploiement entre les équipes de développement et les équipes production. Ces tensions prennent leur origine dans des objectifs opposés entre les équipes : la rationalisation / maîtrise des coûts des outils pour les équipes production et le Time-To-Market / réactivité pour les équipes de développement (au risque de multiplier les outils).
Une résolution judicieuse de cette équation ne peut avoir lieu qu’avec une approche pragmatique basée sur une expérimentation préalable des outils CI/CD sur quelques projets pilotes puis la formalisation d’un cadre d’architecture « DevSecOps » commun pour le déploiement continu d’applications apportant les garanties d’intégration et de cyber résilience exigées par le RSSI. Les compromis à trouver passent nécessairement par une co-conception du cadre en rapprochant les expertises de développement et de production au sein de « features team » centrées sur un même objectif de qualité du produit logiciel.
Cette tribune a été publiée dans le numéro de juillet 2019 du magazine IT for Business.
