Introduction
Chez Globant, nous sommes habitués à utiliser les méthodologies Agile pour gérer les projets. La plupart des projets démarrent avec quelques équipes, puis prennent rapidement de l’ampleur et avant même de s’en rendre compte, plusieurs POD (équipes Agile) sont impliquées dans le développement d’un ou de plusieurs projets pour un client. Dans le meilleur des cas, nous disposons de quelques POD par projet, mais généralement, les solutions complexes que nous développons pour les grandes entreprises impliquent plusieurs équipes qui doivent se synchroniser pour sortir des produits intégrés de haute qualité.
D’après mon expérience, la mise à l’échelle à partir de Scrum ou d’autres frameworks similaires est difficile mais pas impossible. Souvent, ce sont les gros projets menés dans les grandes entreprises qui posent le plus de problèmes, et ce quel que soit le secteur, en raison d’une culture mature, de structures puissantes, de règles et de processus lourds, et d’infrastructures complexes. Dans ces environnements, on suppose souvent que les initiatives Agiles seront uniquement à la charge de l’équipe de développement. Or, l’engagement et l’adoption de groupes extérieurs aux équipes de développement et informatiques, comme les opérations et les équipes dirigeantes, sont essentiels pour favoriser l’évolution des mentalités et l’adoption de nouvelles méthodes de travail collaboratives.
Dans ce contexte, vous pouvez imaginer à quel point il est difficile d’évoluer simultanément tout en continuant à développer et à fournir des logiciels, et à maintenir des niveaux de qualité élevés. Définir à la fois une stratégie et des processus de test à grande échelle dans le cadre Agile présente de nouveaux défis pour les responsables de la qualité et des tests, les architectes et autres spécialistes des tests, ainsi que pour l’organisation dans son ensemble.
Il y a deux ans, j’ai rejoint un énorme programme en cours destiné à une grande entreprise, qui mettait en œuvre l’approche SAFe (Scaled Agile Framework for Lean Enterprises). Ils essayaient d’ajuster les processus de test et même si j’avais de l’expérience avec Agile, je n’en avais aucune dans les implémentations avec SAFe.
La première fois que j’ai vu le diagramme SAFe 4.5, j’ai été content de voir une énorme structure permettant à l’organisation d’adopter et d’étendre la méthodologie Agile, mais j’ai également été surpris de constater qu’aucune référence explicite aux tests n’était disponible. Je constate avec satisfaction que les principes de SAFe 5.0 sont plus détaillés et que cette version fournit davantage de conseils sur les sujets liés aux tests.
Cet article est basé sur mon expérience de la gestion des tests et de la qualité dans le cadre de grands projets avec la mise à l’échelle Agile. Il reprend également mes réflexions sur l’intégration de la qualité à tous les niveaux. Ces orientations permettent de faire évoluer des équipes multiples, auto-organisées et pluridisciplinaires afin d’assurer la qualité et la collaboration.
Mise à l’échelle avec Agile
Les organisations qui adoptent les méthodologies Agiles prévoient de mettre en œuvre des livraisons itératives et incrémentielles avec un délai de commercialisation accéléré. Elles ont le choix entre des frameworks Agile populaires comme Scrum, Kanban et XP, ou des modèles hybrides qui combinent les méthodologies Agile à des méthodologies itératives plus traditionnelles destinées à générer de la valeur pour les clients dans un flux continu.
Comme mentionné précédemment, faire comprendre aux organisations que l’approche Agile n’est pas réservée aux équipes de développement est une problématique courante. L’agilité et la réactivité sont des facteurs clés pour une véritable adoption, en particulier dans les grandes organisations.
Pour une implémentation Agile à grande échelle, la plupart des programmes de grande ampleur et des organisations structurées adoptent SAFe (Scaled Agile Framework for Lean Entreprises), car elles s’appuient sur sa structure organique et sur lesétapes permettant de passer clairement d’un processus de développement traditionnel à un processus Agile métier.
Lorsque j’ai commencé à travailler avec la configuration du portefeuille SAFe, j’ai constaté à quel point il était important de mettre en place une organisation et une structure d’équipe claires. Je suis partisan d’une structure définie par niveaux (équipe, programme, portefeuille) pour répartir les efforts et les responsabilités entre les équipes de développement et la direction des opérations et des produits.
Autre aspect intéressant et utile de SAFe : le développement est planifié par incréments de programme (PI). Chaque PI est un intervalle défini dans le temps dédié à la planification, au développement et à la validation d’un incrément du système. Généralement, le PI dure de 8 à 12 semaines et le schéma le plus courant consiste en cinq sprints de développement, suivis d’un sprint d’innovation et de planification.
Le processus commence par la planification des incréments de programme : l’équipe est guidée par les objectifs du produit pour planifier le travail des 5 sprints, ainsi que pour identifier les dépendances et les risques en amont, afin de gérer correctement la problématique dans l’incrément de produit. Dans le cadre de travail Agile, chaque exécution de PI est une séquence des « cérémonies » dont la plupart des équipes de développement sont familiers : Sprint Planning, Backlog Refinement, Daily Stand Up, Sprint Review et System Demo. Dans ce scénario, les équipes sont sur la bonne voie pour livrer chaque incrément du système conformément aux objectifs fixés et aux attentes de l’entreprise.
Culture de la qualité avec Agile
D’après mon expérience, la plupart des équipes considèrent toujours les tests comme la phase finale de leur travail. Changer l’état d’esprit des équipes et développer une culture de la qualité est un enjeu majeur. La responsabilité de la qualité incombe à toute l’équipe ; chaque développeur, chaque architecte et chaque concepteur peut appliquer les meilleures pratiques de développement de code pour contribuer à un travail de qualité.
Il est plus facile et moins risqué d’empêcher un incendie que de l’éteindre. Dans la même logique, il est beaucoup plus efficace d’anticiper les problèmes en intégrant la qualité dans le développement du produit dès le début que de travailler à leur résolution. L’intégration de la qualité est donc un objectif clé pour l’équipe. Mieux l’architecture et la conception sont définies, plus facilement le système peut être testé et est capable de gérer les exigences actuelles et futures. En outre, la facilité et la rapidité d’ajout de nouvelles fonctionnalités dépendent de la fiabilité et de la simplicité du code développé.
Mon conseil est d’aller au-delà de la simple affectation de testeurs aux équipes Agile et de considérer les testeurs comme des ambassadeurs de la qualité à chaque étape du processus, en ouvrant les discussions dans une optique de qualité, depuis les définitions des exigences jusqu’au développement et au lancement. Le rôle principal des testeurs et de tout autre ingénieur qualité du programme doit être d’aider l’équipe à changer d’état d’esprit et de s’assurer que la qualité est intégrée de bout en bout au processus.
Définition de la stratégie de qualité
Dans une mise en œuvre Agile à grande échelle, il est capital de définir une stratégie de qualité efficace favorisant la mise en œuvre adéquate d’une solution intégrée et testée pour les clients. Même si vous pouvez compter sur chaque équipe Agile pour appliquer des pratiques de test Agile efficaces, pour évoluer, il est nécessaire d’améliorer la prévisibilité et de s’appuyer sur une stratégie de qualité globale définie pour l’organisation dans son ensemble.
Une fois que vous avez compris les besoins liés à l’entreprise et aux produits, vous devez commencer à élaborer la stratégie de qualité. Cette démarche peut sembler basique, mais elle devrait toujours constituer la première étape pour tout type de projet et de framework. Une stratégie de qualité clairement définie permet de garantir une définition stratégique des différents types de tests à tous les niveaux. Cette définition stratégique permettra d’élaborer un produit tenant clairement compte des facteurs critiques, non seulement d’un point de vue technologique, mais également d’un point de vue commercial et opérationnel.
Dans le cadre de programmes d’envergure et au sein des grandes organisations, il est très facile de basculer dans un cycle en cascade pour les tests de produits. C’est pourquoi il est si essentiel d’appliquer la méthode « shift-left » pour les tests le plus tôt possible dans le cadre du cycle de vie du développement logiciel. Au lieu de phases, avec différents niveaux de tests exécutés séquentiellement, les tests de conformité aux exigences fonctionnelles et non fonctionnelles doivent être exécutés en parallèle et de manière incrémentielle sur différentes couches dans le cadre d’une approche d’intégration continue et de livraison continue.
Gardons à l’esprit également que dans un environnement à l’échelle, les équipes travaillent sur une base de code partagée. Avec cette configuration, chaque équipe autonome doit s’assurer que les changements qu’elle introduit ne cassent pas les fonctionnalités existantes ou n’impactent pas négativement le parcours client. Cela peut déclencher des tests de régression et d’intégration réguliers et automatisés.
D’après mon expérience, l’association de diverses approches s’est avérée très utile pour sélectionner les types de test appropriés à chaque produit testé, tout en permettant de définir simultanément une stratégie de test complète qui contribue à garantir la qualité correspondant aux besoins de l’entreprise.
Compte tenu de l’application complexe que nous déployons et du processus existant du client dans mon projet le plus récent, nous avons commencé à définir une structure en « pelures d’oignon » avec des niveaux de test traditionnels (tests unitaires / de composants, tests d’intégration, tests système et tests d’acceptation). Nous avons également intégré dans l’analyse des types de tests requis les quadrants de test Agile, qui fournissent une taxonomie utile pour identifier et planifier les tests nécessaires. Enfin, sur la base de la pyramide d’automatisation des tests, nous avons finalisé la stratégie d’automatisation des tests.
L’automatisation de vos tests est la clé pour passer à une approche de test continue qui évolue et étend l’automatisation des tests pour faire face à la complexité croissante de l’application. Les tests continus correspondent à un type de test logiciel qui implique un processus de test précoce, fréquent, à tous les niveaux et automatisé. Vous devez par conséquent définir un processus d’exécution automatisée de tests dans le cadre de la mise en production de logiciels, afin d’obtenir des informations sur les risques commerciaux associés à une version logicielle candidate aussi tôt et souvent que possible.
Un bon point de départ consiste à intégrer les principaux flux dans la suite de tests de vérification de version (BVT) qui est exécutée automatiquement avec chaque validation au niveau de la branche principale et devient la première garantie de qualité du projet. Les tests automatisés restants devraient faire partie de la suite d’automatisation des tests de régression qui est exécutée à un rythme régulier (par exemple, toutes les nuits), pour fournir un retour précoce et continu sur les nouvelles modifications implémentées dans le code.
Le diagramme ci-dessous illustre une approche concise qui peut vous aider à piloter l’effort de test nécessaire à différents niveaux :
Meilleures pratiques en matière de tests avec les méthodes Agile à l’échelle 2
Processus d’amélioration continue
Même en s’appuyant sur un framework Agile qui fournit à la fois des conseils sur les bonnes pratiques et une feuille de route pour la mise en œuvre, chaque organisation doit définir ses propres processus, pratiques et directives alignés sur ses besoins.
Il n’existe pas de recettes magiques pour définir ce qui est adapté à votre projet. Pour gagner en maturité sur les processus, vous devez avancer progressivement, par petites étapes, définir, essayer et apprendre. Chaque situation représente une bonne occasion d’apprendre et d’identifier les éléments à conserver et améliorer, ainsi que ceux à éviter et modifier.
Rien n’est gravé dans la pierre et tous les processus sont actifs, alors n’hésitez pas à expérimenter différentes pratiques jusqu’à trouver celles qui fonctionnent pour votre produit, votre organisation et votre équipe. Les variations, les preuves de concepts et les pilotes sont des alternatives que vous pouvez envisager de mettre en œuvre. Chaque membre de l’équipe peut apporter de bonnes idées et faire partie de la solution. Vous pouvez également mettre en place des communautés de pratique qui peuvent se concentrer sur certains domaines et favoriser ainsi un processus d’amélioration continue.
Les rétrospectives, les leçons apprises et les sessions d’inspection et d’adaptation sont très utiles pour planifier régulièrement des temps de réflexion, mettre en pratique des techniques de résolution de problèmes et appliquer les améliorations nécessaires pour accélérer le prochain incrément de programme, gagner en qualité et en fiabilité.
Dans la partie 2 de ce blog, je passerai en revue les tests aux différents niveaux requis et j’aborderai l’intégration de la qualité à chaque niveau organisationnel lors de la mise à l’échelle.
