J’aimerais solliciter l’aide de la communauté concernant une problématique que je rencontre dans l’équipe que j’accompagne actuellement en tant que SM.
Mon équipe délivre des releases tous les 1 mois et demie (i.e. 2 sprints). Nous aimerions arriver à livrer au moins une fois par itération, mais nous sommes bloqués par nos phases de tests de release qui durent deux semaines : notre application est le noyau central de tous un tas d’autres applications / systèmes. Si on est down, tout le monde est down. Du coup historiquement, l’équipe a toujours mis en place un retest complet de l’application avant release qui prend environ 2 semaines
Je pense que notre solution réside dans notre capacité a réduire ces deux semaines de non régression à quelques jours… Avez-vous des pistes / outils / méthodos pour y arriver ?
J’ai bien entendu accompagné l’équipe sur le shift left / shift right et la pyramide de tests Agile, mais cela ne réponds pas vraiment à la problématique, ou en tout cas pas sur le court terme.
En quoi est-ce un problème que vous livriez tous les 1 mois et demi ? Qu’est ce que livrer plus souvent/tôt vous permettrait vis à vis de aujourd’hui ? Quels sont les concessions que ce nouveau mode demanderaient ? (je n’attends pas une réponse « by the book » mais vraiment a explorer votre contexte)
Vu qu’elles prennent deux semaines, chaque release impacte les sprints de l’équipe : la QA est mobilisé dessus et du coup l’équipe avance moins bien, malgré qu’on essaye d’aider la QA sur leurs tests. Tout cela génère beaucoup d’imprévu, de charge mentale et donc de stress à l’équipe sur les sprint ou il y a une release. L’idée serait de livrer plus souvent mais en quantité moindre pour que les releases deviennent un « non événement » ou en tout cas, plus légère à réaliser, avec moins de stress. On nous reproche aussi de pas donner de visibilité sur l’implémentation des features. L’idée serait de regagner la confiance des marchés en livrant plus souvent et donc en donnant de la visibilité.
CI / CD complets. Nous avons des tests automatisés mais nous admettons qu’ils ne couvrent pas forcément de manière exhaustive le fonctionnel. On est en train de travailler dessus mais cela va prendre du temps de reprendre l’historique.
As tu travaillé le temps de cycle pour que chaque élément du board soit livré le plus vite possible ? L’idée derrière est de livrer les petits éléments envisageables avec un temps de cycle le plus court possible pour soulager le goulet d’étranglement qui semble être la validation technique (QA) dans ton cas et limiter les risques de régression
Bonjour Adrien,
Quelle quantité de bugs sont découverts durant ces phases?
Est-ce que les bugs identifiés le sont sur des parties bien précises ou aléatoires sur toutes les parties? Est-il envisageable de circonscrire les tests pour limiter leur durée et leur scope?
Dans ta situation, nous avions décidé de limiter la durée de tests au fur et à mesure en définissant et limitant des scénarios critiques.
La charge de recette est donc remontée à l’équipe de dev qui a été plus responsabilisée à la fois sur les nouveaux dev réalisés et sur les tests de non régressions à créer quand une erreur est arrivée.
Et en cas de bug qui est passé et arrivé en prod, l’équipe était engagée à être réactive sur le correctif, à patcher et rajouter le test automatisé pour que cela n’arrive plus.
Et bon sinon à part débiter des évidences c’est sûr que le sujet que tu abordes est très complexe. Les petites améliorations à court termes sont celles que j’exprime, mais après il y a des chantiers plus gros pour éviter les pansements sur les jambes de bois. Car le plus important dans ton cas ça va d’arriver à limiter voire casser les dépendances (la fameuse loi de Conway)
@Ingrid-T
C’est une excellente stratégie.
Les tests réalisés par les devs ne sont pas toujours considérés comme pouvant VALIDER l’Item et indiquer que l’on tient là un incrément.
Tu peux donc accompagner la Scrum Team à définir les conditions devant permettre d’atteindre cette confiance.
Celà passe par exemple par la définition de la stratégie de recette et les cas de tests associés dans des réunions de type 3 Amigos.
Cela se faisant de manière progressive, la charge de qualification du QA et autres PO/APO va se réduire au fur et et à mesure au profit de celle réalisée (de toute façon) par la DevTeam.
@nicobiot C’est justement notre Mandat Agile de délivrer de la valeur plus souvent, qui a mis en évidence ce goulot d’étranglement.
@Ingrid-T merci pour tes conseils, je vais amener l’équipe sur la construction d’une matrice de criticité des scénarios et de travailler la pluridisciplinarité de la charge QA