3 Amigos

Description

Pour préparer le sprint suivant, le Product Owner (PO) organise, éventuellement avec l'aide du Scrum Master, des réunions appelées "Sprint Refinements" au cours desquelles il présente les User Stories (US) à certains membres de l'équipe afin, de faciliter la planification du sprint.

Le danger d'impliquer uniquement des développeurs est qu'ils se concentrent sur la modélisation de la solution technique à fournir une fois qu'ils ont compris l'objectif des US présenté avec peu d'attention aux critères d'acceptation.

La pratique des "3 Amigos" consiste à inviter au Sprint de raffinement un Développeur pour repérer comment les US seraient mis en œuvre et un autre acteur de l'équipe de développement qui peut identifier les critères d'acceptation les plus pertinents. Pour ce faire, un testeur ou toute autre personne capable de se décentrer du problème du "comment" est nécessaire. Cette personne supplémentaire doit fournir un aperçu de l'utilisation de l'application des US. Cette personne supplémentaire doit fournir un aperçu de l'utilisation de l'application, tant au niveau de la fonctionnalité proposée que de son exploitation.

Les questions de cette personne devraient conduire à :

• Le PO doit identifier les réponses, spécifier les données d'essai impliquées dans ces questions et le niveau de valeur ajoutée vu du terrain associé à ces questions afin de fournir les exigences sous-jacentes pour les US.
• Le développeur qui intègre ces exigences fonctionnelles et celles qui ont un impact sur l'architecture ; c'est la notion "d'exigence significative pour l'architecture" [Moustier 2019] [ASR 2021].

On peut noter que cet atelier peut être enrichi en ajoutant différents profils (UX, sécurité, client, ...) [Hage Chahine 2020] [Moustier 2019].

Application à la maturité des tests

Lors de l'idéation d'un US, il est essentiel de garder à l'esprit le principe de l'ISTQB "Les tests dépendent du contexte" [Radid 2018-6]. Cette focalisation sur l'implémentation permet d'identifier les :

• Cas d'utilisation nominaux et les plus critiques des rares cas d'utilisation, s'ils ne peuvent pas tous être testés [Radid 2018-2], ces exemples qui serviront d'exigences dont les données permettront des cas de test explicites ou des critères d'acceptation pour les US qui peuvent alors aider à couper éventuellement les US s'ils deviennent trop importants pour être réalisés dans le sprint.
• Tests des exigences non fonctionnelles

‍

La plupart de ces tests seront ensuite automatisés pour permettre à chaque membre de l'équipe de vérifier qu'il n'a pas introduit de régression avec chaque nouveau US introduit dans l'incrément de produit.

La position d'Agilitest sur cette pratique

La conception de scripts de tests automatisés ne doit pas se faire de manière isolée afin d'éviter de concevoir un script à faible valeur ajoutée ou contenant des éléments qui seront rapidement rendus obsolètes par la mise à jour des widgets ou des processus métier.

Ainsi, la connaissance des changements dans le sprint à venir peut être une information précieuse pour éventuellement remettre en question la valeur ajoutée d'une automatisation ou concevoir son script de manière à ce qu'il reste opérationnel avec le changement prévu.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍