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 de les 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 serait 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. les USCette 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 à :

• L'OP pour identifier les réponses, spécifier les données de test 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 de les US
• Le développeur d'intégrer 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 :

• Les cas d'utilisation nominaux et les plus critiques des rares cas d'utilisation, si tous ne peuvent pas être testés [Radid 2018-2], ces exemples qui serviront d'exigences dont les données permettront d'établir des cas de test ou des critères d'acceptation explicites pour les. les US qui pourront ensuite aider à couper éventuellement les US s'il devient trop important pour être réalisé 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.

‍