En rejoignant Amadeus, j’ai eu l’opportunité de rejoindre un projet récent qui proposait un changement majeur: la migration vers les méthodes Agiles.
Le fait de débuter avec une nouvelle méthodologie dans un nouveau projet est intéressant, car cela a permis d’innover sans cesse, sans impacter négativement le projet.
Le projet étant trop important et complexe, il ne pouvait être effectué par une seule équipe SCRUM. Une solution a été adoptée : l’Agilité à l’échelle avec le « Scrum of Scrum ».
Nous avons donc commencé avec plusieurs équipes Scrum, initialement une par domaine fonctionnel. Pour orchestrer et centraliser les avancements, un « Scrum of Scrum » a été mis en place.
Le « Scrum of Scrum » est une méthode d’agilité à l’échelle qui permet d’avoir sur un projet plusieurs Scrum (équipes composées de 8 personnes en moyenne) travaillant sur des modules différents tout en restant synchronisés.
Une équipe Scrum composée des Scrum Masters, des représentants de leur équipe, est formée avec un Super Scrum Master qui organise et coache ; et un Super Product Owner qui gère les livraisons à un niveau projet.
Dans ce Scrum au-dessus du Scrum, nous avons une backlog de tâches, qui est ensuite adressée aux Product Owner des Scrum afin de donner une meilleure granularité aux développements nécessaires en User Stories.
Ce que j’ai apprécié dans cette organisation, c’est la capacité de prévoir les dépendances des livraisons entre les équipes et la mise en avant de la collaboration à grande échelle.
Chaque point remonté par le Scrum Master était discuté au « Scrum of Scrum », et les solutions étaient partagées entre les équipes. Tous les intervenants participaient aux évolutions du projet.
De plus, l’organisation des livraisons devenait simple : toutes les User Stories sont reliées à une tâche de la « Scrum of Scrum ». En un point, nous avons la liste des développements d’une livraison avec les dépendances et des critères d’acceptation moins unitaire (tests End to End, par exemple).
Le risque de la méthodologie Scrum sur un projet constitué de plusieurs équipes est la perte de la vision globale du projet/produit. Chaque Scrum se focalise sur son domaine fonctionnel et peut s’isoler. Ceci peut donner des dérives avec des développements de deux équipes SCRUM qui deviennent incompatibles.
Dans mon cas, le Super Scrum Master et les différents Scrum Master ont bien compris ce risque et ont toujours accordé beaucoup d’importance aux phases d’intégration des composants et aux tests end to end.
En parallèle de l’installation des méthodes agiles, l’entreprise procédait également au recrutement d’experts en qualité afin d’accompagner les équipes. Ce changement reçu une appellation interne : “la QA transformation”. Et c’est ici que j’interviens.
En tant qu’ingénieur en qualité, j’ai rejoint le projet peu après son lancement, en intégrant une des Scrum de la « Scrum of Scrum » dans une équipe de huit personnes, composée de développeurs et d’experts en définition de produits (analyste métiers).
Dans une Scrum, nous sommes tous développeurs. Cependant, l’organisation a maintenu une gestion par domaine de compétences en terme hiérarchique.
En tant qu’expert en qualité logiciel, j’appartiens à mon équipe Scrum mais aussi à une équipe d’ingénieurs qualité qui est elle-même divisée entre les équipes Scrum. Il en est de même pour les autres domaines d’expertises.
Chaque équipe d’expert (Développeurs – DEV, Business Analystes – BA) envoie donc ses membres pour composer l’équipe Scrum. Un seul expert qualité était assigné par Scrum.
Le point fort de cette organisation en communauté est la collaboration entre experts du même domaine. Une idée émergeant d’une Scrum peut être facilement partagée et propagée. Avoir une communauté d’experts permet d’introduire des incubations d’idées ou des réunions dédiées à l’innovation. Ce point est illustré un peu plus tard avec l’évolution d’outils et de processus suivis.
Le risque d’une telle organisation, qui est visible sur le schéma précèdent, est la ségrégation des domaines d’experts. Une Scrum n’étiquette pas ses membres en fonction de leur domaine d’expertise. Nous ne parlons pas d’analyste business ou de testeur, mais de membres du Scrum (ou juste DEV en cas d’abréviation).
Ici, chaque membre de la Scrum s’identifie dans un rôle, ce qui est contradictoire à l’esprit de la méthode Scrum et plus généralement des méthodes agiles.
Cela peut introduire des tensions, notamment quand un expert se voit attribuer une tâche qui n’entre pas dans son domaine.
J’ai fait face à plusieurs reprises à ce rejet quand les tâches de tests étaient attribuées à une personne non-incluse à l’équipe QA. Le conseil que je peux donner pour régler ce problème est l’utilisation d’une matrice de compétence afin de convaincre les plus récalcitrants.
Montrez aux membres de la Scrum qu’ils sont capables d’effectuer des tâches de tests en rappelant les règles du Scrum. Ne soyez pas trop conciliant, sinon les tâches ne seront pas réalisées. Soyez diplomate afin de ne pas aggraver les tensions.
Et surtout : remontez le problème s’il est impactant au Scrum Master et aux Managers. Ils sauront soutenir les principes du Scrum afin que le projet se déroule normalement.
Ayant rejoint le projet après son départ, et étant le seul ingénieur qualité de la SCRUM, mon premier défi a été d’évaluer et de comprendre les choix et implémentations effectués jusqu’à présent. En termes de produit mais aussi de procédures et outils sélectionnés par l’équipe.
J’accorde énormément d’importance sur les choix effectués, ils représentent les objectifs et la mentalité de l’équipe : des outils simples à utiliser mais demandant beaucoup de tâches manuelles montrent une volonté de simplicité.
Pour une meilleure efficacité il faut avoir des outils automatisés qui sont en revanche plus complexes à utiliser et demandent plus de connaissances techniques.
En début de projet, à l’exception des outils imposés dans la stratégie de tests, les outils étaient simples et manuels. Notre solution avait un nombre de tests limités et maintenables manuellement. La multiplication de ces tests au fur et à mesure du projet a forcé le changement de certains outils.
En parallèle, j’ai été responsable de l’introduction de quelques nouveaux outils de suivi et de rapports de qualités en utilisant notamment un outil comme ALM HP.
Avec une équipe QA, il est plus aisé de s’aligner sur les outils de rapports de tests. Une harmonisation des rapports permet une réduction des mails grâce à la mutualisation. De plus, les échanges avec les personnes impliquées dans le projet deviennent plus faciles, les mêmes références sont utilisées indépendamment du Scrum.
L’installation de nouveaux outils, dédiés pour une activité dans la Scrum, s’est révélée être assez délicate, en raison de la résistance aux changements de certains membres des équipes ou de la réticence à donner de la visibilité sur la qualité du produit dès sa conception.
Mon astuce afin de contrer cela est de bien prendre le temps d’expliquer, avec des exemples concrets, ce que ces outils peuvent apporter au projet et à l’équipe.
Donner de la visibilité de la qualité permet une meilleure planification du Sprint à venir. Les éléments non validés et bloquants sont priorisés en bonne et due forme. Les équipes impactées sont rapidement informées afin de ne pas s’engager sur un développement en début de sprint qui sera bloqué pendant ce dernier.
Mon travail d’expert qualité s’introduit parfaitement dans cet échange entre le résultat des tests et les réunions de début de sprint ou des plannings poker. Une User Story ayant un risque élevé ou ayant une dépendance sur une fonctionnalité dont les tests ne sont pas encore passés, peut avoir une estimation revue à la hausse.
Au fur et à mesure que le projet avance, la complexité des fonctionnalités et des tests s’accroit. Il est indispensable de revoir constamment les outils et procédures utilisés.
Par exemple, pour le stockage des tests, nous utilisions CVS. L’outil est facile à prendre en main, intégré à l’explorateur Windows et propose une gestion de version simple, basée sur des descriptions.
Cependant, l’outil ne permet pas de visionner les changements effectués dans un test facilement et ne donne aucune visibilité sur les revues faites pour les tests.
Certains tests automatiques se sont dégradés à cause de revues ignorées.
Afin de pallier ces deux soucis, j’ai proposé dans mon équipe Scrum une migration vers Git pour la gestion des tests. Ce qui est appréciable avec Git est son intégration avec des outils tel que BitBucket (Altassian), qui permet d’avoir une vision en ligne des documents ainsi que des changements effectués sur ces derniers. De façon à partager avec un groupe ou une entité (exemple : une équipe) via une application web simple et ergonomique. De plus Git était déjà utilisé par les développeurs, cela a donc permis de limiter le nombre d’outils et d’inclure plus facilement les développeurs dans les tâches de test.
Ainsi, nous avons pu ajouter des vérifications automatiques sur le respect des procédures, par exemple la revue. Une modification opérée se doit d’avoir : un titre, une description, l’identification de l’auteur, l’approbation d’une personne autorisée par l’outil ainsi que son identification.
Tout changement est suivi et peut être facilement inversé ou changé car rapidement identifiable.
Travailler en Scrum se révèle être très enrichissant. Contrairement à mes autres expériences où mes compétences de testeur étaient suffisantes, le Scrum requiert des compétences humaines.
Communication, compréhension, adaptabilité, persévérance et gestion de soi seraient les cinq compétences que j’assimilerais avec le métier de testeur agile.
A chaque jour de travail, nous collaborons avec une équipe hétéroclite. Savoir discuter pour avoir des informations sur le développement en cours est tout aussi important que savoir donner de son temps pour expliquer ou aider ses coéquipiers en Scrum.
Le fait d’être testeur agile ne se limite pas au simple fait d’être testeur. L’unique contrainte est la priorisation.
Précédemment, j’ai évoqué le fait qu’une personne non experte en qualité pouvait prendre des tâches sur la qualité. Il en en est de même pour le testeur qui peut se voir dans la contrainte, ou plutôt l’opportunité, de s’aventurer sur un domaine où il est compétent mais non expert.
Il m’est arrivé de mettre le test de côté pour aider dans la spécification du produit. Un membre du Scrum peut participer à toutes les tâches auxquelles il se sent capable de fournir une valeur ajoutée.
Pouvoir travailler en dehors de son domaine de confort est vraiment positif J’ai pu développer de bonnes compétences en compréhension du produit et en communication. Pour certains, cela permet même de se découvrir des talents. Par exemple, j’ai eu l’occasion de travailler avec un développeur qui s’est intéressé aux métiers liés à la qualité logicielle en menant plusieurs tâches de tests.
Attention cependant à ne pas prendre un travail pour lequel vous n’avez pas de compétences suffisantes, surtout si la partie est critique ou urgente. L’objectif reste de faire avancer le projet, une personne experte sera plus adéquate pour les tâches les plus sensibles afin de ne pas impacter les livraisons. Je me suis déjà retrouvé en situation de difficulté en prenant une tâche de définition de produit bien trop compliquée pour mon niveau. Heureusement, nous ne sommes jamais seul en Scrum.
Nous travaillons dans les mêmes bureaux et nous nous côtoyons quotidiennement. Cela forge un esprit d’équipe fort. A plusieurs reprises, j’ai constaté que les membres d’une même Scrum s’entraident au travail et se lient d’amitié. Pour ma part, un grand nombre de mes collègues sont également des amis.
Cela semble être un détail, mais cette collaboration poussée permet de mieux appréhender les difficultés. De plus, cela permet de discuter ouvertement sur des problématiques, communes ou non, et d’avoir de meilleurs points de vue.
Nous ne pouvons pas nous entendre avec tout le monde, mais quand nous instaurons un esprit d’équipe fort dans une Scrum, les concessions sont plus faciles à donner ou recevoir : on fait cela pour le bien du projet, et pour le bien de la Scrum.
Si je devais décrire ma journée type en tant que testeur agile :
J’arrive souvent en premier, tôt le matin. Les environnements de tests sont peu utilisés, donc plus rapides. Je profite également de ma solitude à cette heure-là pour vérifier les résultats de la campagne de non régression exécutée la nuit, en buvant mon café. Certains préfèreront lire le journal, mais mes actualités au travail sont les nouvelles erreurs remontées par mes tests.
Aux alentours de dix heures, une fois tous mes collègues présents, je participe au stand up, avec toujours un petit mot sur l’état de notre backlog de bug. J’ai toujours été intransigeant sur la résolution de bug : il ne faut jamais laisser un bug critique non urgent devenir critique et urgent.
La matinée peut varier selon les tâches à exécuter : en première semaine de sprint, quand peu de code est délivré, je travaille sur l’optimisation de nos processus et de notre régression. On peut toujours mieux tester sans obligatoirement tester plus. Je m’impose également une pause-café avec des testeurs d’autres domaines fonctionnels afin de discuter tranquillement sur des sujets variés, dont les méthodologies de tests. Les discussions y sont toujours intéressantes
Les autres semaines, je priorise le test des développements en cours ou terminés pour le sprint. Un retour rapide est toujours apprécié, même si les développeurs restent déçus s’il y a un bug. Mon objectif dans le test n’est pas de trouver absolument un bug. Pour moi, un testeur agile doit couvrir dans ses tests tous les cas critiques et importants pour le client et être sûr que le délivrable n’apporte pas de risques.
Mes collègues m’ont rarement dit : « Si tu es souriant, c’est que tu as trouvé un bug ». Cela même si j’étais satisfait de trouver un de ces bon bugs bien impactants avant le client. Mais on est loin d’un cas de schadenfreude (joie malsaine).
Le repas du midi se devait d’être partagé avec des collègues de la Scrum ou d’autre testeurs. C’est le meilleur moment de la journée pour échanger des idées et des avis sur tout, y compris les projets ou nos processus. Bien que, souvent, nous parlons plus de sports et technologies.
Les après-midi ressemblent à mes matinées. Certains jours, nous avons des cérémonies Scrum, comme le raffinement pour discuter des User Stories.
Sur l’ensemble de la journée, je n’hésite pas à inviter à une pause-café un petit nombre de collègues pour discuter rapidement de problèmes ou afin de demander des éclaircissements.
En conclusion, Travailler en Agile, dans une Scrum intégrée dans une Scrum of Scrum est très intéressant en raison des défis qu’une telle organisation peut apporter.
Il est important de garder un esprit Agile, mais non incompatible avec une hiérarchisation par domaine d’expertise si les équipes comprennent leur rôle dans la Scrum : ne pas être qu’un expert dans un domaine, mais être un membre à part entière dans une équipe qui s’adapte et évolue.
Le travail du QA reste important comme dans tout projet, mais la communication y est une qualité indispensable. Il faut pouvoir discuter avec les Scrum master et les membres de son équipe.
Je reste entièrement satisfait de mon expérience dans cette organisation qui m’a apporté énormément, tant au niveau professionnel qu’au niveau personnel.
