Je me suis laissée le temps de réflexion, comme tu vois, mais j’avoue ne toujours pas comprendre comment les DOR et DOD pourraient aider…
En tout cas, le fait que ses tests soient un goulot d’étranglement est une chose parfaitement identifiée par l’équipe, mais, pour la P.O., il y a toujours une réunion plus importante/ urgente que les tests ou que la priorisation/raffinement de son PBacklog, et, sauf coup de bol ponctuel, on est toujours dans cette situation où elle cavale en fin de Sprint pour fabriquer, vite, vite, quelques tickets pour occuper l’équipe.
Cela, sans cohérence réelle, sans s’appuyer sur le Product Goal qui n’est même pas clairement « verbalisé »…
Comme j’ai pu le lire dans d’autres posts, je me sens devenir inutile, car mes suggestions, propositions, ne mènent à rien. Apparemment le client ne se plaint pas, et nous ne sommes pas dans du Scrum, loin de là, mais si le client est content, ma foi, quelle importance?
Je crois que je vais aller voir la vidéo de @jplambert et @const sur la disparition prochaine du métier de Scrum Master
Je rejoins @TheLimande pour te dire que la DOR peut peut aider le P.O comme l’équipe à clarifier la stratégie de tests qui en ait qu’une composante .
Voici ce que j’expérimente actuellement dans ma Scrum Team, concernant le processus de validation des items du backlog en rapport avec la DOR.
Pour chaque item on retrouve ceci, à passer dans l’environnement de qualification :
Les cas de tests définis dans les séances des trois Amigos validés à 100%.
Les cas de tests de non régression également définis dans les séances des trois Amigos validés à 100%.
Concrètement, après avoir identifié tous les cas de tests pour valider l’item, un partage des tâches de rédaction est réalisé entre le PO/BA, QA/QC.
Chaque cas de tests écris est ensuite validé par l’autre partie.
Du coup, une fois qu’un item est validé, par l’exécution du cas de test par le QA/QC, c’est validé pour tout le monde.
Dans notre équipe, nous avons bcp d’échanges inter-applicatives et donc des tests de bout en bout à réaliser parfois. C’est le PO/BA qui réalise cette tâche.
Comment définissez-vous la stratégie de tests ?
Pratiquez-vous les 3 Amigos ?
Je n’ai pas participé à l’élaboration d’une « stratégie de tests », elle était installée avant mon arrivée.
Je ne sais pas du tout comment elle a pu être définie…
Et non, on ne pratique pas les 3 amigos.
J’ai une équipe qui aime bien dire « non » tout de suite. Puis la graine germe, et plus tard, un-e dév a une super idée et elle est adoptée! (c’est souvent ce que j’ai proposé 2 mois plus tôt et qui avait été rejeté en bloc, dis donc! )
Moralité, je vais regarder les 3 amigos de plus près et voir s’il faut/comment présenter l’idée, oui, merci.
Est ce que c’est censé nous faire gagner du temps? Décoincer le goulot d’étranglement au niveau de la P.O.?
J’ai envie de dire ‹ tant mieux ›. Dans ma vision des choses, la bonne scrum Master n’est pas celle qui arrive avec des solutions mais celle qui fait comprendre qu’il y a un problème. Après, que tu arrives à faire passer des solutions de façon subliminal, pourquoi pas, mais le but à long terme, c’est pas d’avoir résolu la situation. Le but à terme, c’est d’avoir aider l’équipe a résoudre ses propres problèmes toute seule et sans impulsion externe.
Bonjour @Charlotte ,
Les 3 Amigos permettent à chaque membre de l’équipe d’être au claire sur la partie test à réaliser pour la validation d’une US. Ce partage de la vision de chaque niveau de test à réaliser fait en effet gagner du temps car tout les points de vue sont donnés et il en ressort une couverture de tests assez précise.
A partir du moment où tout le monde se met d’accord sur les tests à passer, les JDD, le prérequis et tout ce qui va avec, du coup la P.O. pourrait comprendre qu’elle n’est pas obligé de passer elle même les cas de tests pour valider son US.
Ce qui compte c’est que ce qu’elle veut tester et la façon dont elle veut tester soit dans la stratégie de tests.
)