Okay, je vais foutre le boxon ! ... Non je rigole, en fait je suis bien d'accord avec toi. Avec juste un petit point : il faut quand même éviter de créer des sous-groupes (je pense à la vidéo vers 4:50), et bon je vais faire mon évangile du Scrum (Raaah, j'aime pas ça, mais bon sur ce coup c'est pertinent pour mon argument) :" Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis". L'idée du pourquoi de la phrase : éviter de siloter dans sa propre équipe ! :) Après comme je disais sur Linkedin, ça peut me sembler souvent pertinent d'avoir le PO qui teste, car c'est lui qui fait les critères d'acceptations, mais néanmoins dans une équipe mature (et j'insiste sur le mature), le PO n'a pas besoin de tester, l'équipe de dev devrait le faire entièrement, je te rejoins là-dessus. La confiance et la responsabilisation ! ;)
De mon point de vu, le PO a un rôle important durant tout le cycle de développement et pas seulement à la validation. Il ne faut pas qu'il y'ai une cloison entre le PO et l'équipe. Ce que je veux dire par là, c'est que le développeur ne doit pas hésiter à demander l'avis du PO sur ce qui est en cours de développement voir si on est bien dans la vision partagée ou voir si la solution choisie correspond aux attentes du PO. En effet, il ne faut pas attendre que l'US soit sortie de dev pour s'apercevoir qu'on est passé a coté de quelque chose. Par exemple : Notre PO nous demande d'ajouter un indicateur sur notre écran de stats. On a les différents critères d'acceptance (calculs, données, etc.). Mais la coté graphique, ce n'est pas forcément claire. Le développeur devrait faire un premier jet et voir avec le PO si l'indicateur choisi est bien placé, s'il est claire, etc. En tout cas, je prends note de : "Si le PO revérifie les critères d'acceptance c'est qu'il y'a un manque de confiance envers l'équipe". C'est totalement vrai. J'ai déjà vu aussi des développeurs dire : "je ne vois pas pourquoi je testerais les critères d'acceptances car c'est le rôle du PO de les vérifier..." Merci pour ces vidéos
En tant que testeur je trouve qu'il existe une confusion embêtante autour du mot "test". La validation cherche à confirmer que le produit correspond à ce qui est attendu (à un instant T on peut affirmer que la validation est totalement terminée), en revanche le test consiste à chercher ce qui ne pourrait pas fonctionner, et par nature n'a pas de fin (au testeur de trouver un compromis entre temps accordé au test et qualité). Donc non, ce n'est pas au *rôle* du PO que revient l'activité de test :)
Par contre c'est bien le role du PO que de "valider" c'est à dire confirmer que le produit répond au besoin une fois celui ci dans l'environnement cible (les vrais donnees, les vrais client, les vrais utilisateur, etc.). Si ca n'est pas le cas c'est que le PO s'est planté ou que ça a bougé pendant le sprint. C'est la vie. Il faut amender le backlog pour corriger.
Je n'avais jamais poussé la réflexion sur le rôle de la validation par le PO, mais dans l'idée ton point de vue se défend (notamment le fait que les items de validation doivent être dans la spec). Du coup je me dis que la validation est de la responsabilité collective. Ça peut paraitre énorme juste pour de la validation mais l'idée est d'augmenter le feedback sur l'évolution du produit (et ça rejoint l'idée de faire du testing plus poussé). Bref a essayer.
Bonjour, Alors je suis complètement d'accord avec le fait que l'équipe de développement est responsable des tests et non le Product Owner, puisque les tests font littéralement partie de la DoD de l'US (Product Backlog items often include test descriptions that will prove its completeness when “Done.” - Scrum Guide), et que c'est l'équipe de développement qui doit produire l'incrément en respectant cette dernière (Only members of the Development Team create the Increment. - Scrum Guide). J'aurais peut-être précisé un élément sur la fameuse colonne "Validation": le workflow des stories/tâches (les colonnes), tout autant que le tableau, ne font pas partie du cadre Scrum (le terme "board" n'est jamais utilisé dans le Scrum Guide). Il s'agit d'une pratique agile que l'on utilise pour permettre de respecter le cadre. Si on interprète Scrum au travers de ces pratiques rajoutées par dessus le cadre, on fait souvent fausse route. D'ailleurs, la plupart du temps on se limite à "To Do/In Progress/Done" et la validation fait partie des critères qui permettent de passer à "Done". Tu as tout à fait raison de souligner qu'il s'agit d'un reste de fonctionnement "à l'ancienne", où des personnes extérieures à l'équipe de développement (au sens stricte) se chargeaient de contrôler le travail réalisé. En Agilité, on responsabilise et on fait confiance, on ne contrôle pas. Il y a par contre un élément avec lequel je suis très mal à l'aise, c'est le fait d'intégrer le PO dans l'équipe de développement. D'après moi, si le Product Owner est intégré à l'équipe de développement et est responsable d'une activité nécessaire à l'atteinte de la DoD, on introduit de gros conflits d'intérêt. Dans ma compréhension de Scrum, le Product Owner ne fait justement pas partie de l'équipe de développement, pour éviter à tout prix ces conflits d'intérêt. Cela n'empêche pas qu'il se sente accueilli dans l'équipe et membre à part entière de "l'équipe de rugby", mais je trouve cela vraiment dangereux. Cela pourrait déresponsabiliser les membres de l'équipe de développement et grignoter dangereusement le temps nécessaire au Product Owner pour préparer les stories de manière adéquate. Un dernier élément, qui me semble crucial, c'est que je trouve que globalement, on promeut beaucoup la tolérance envers l'équipe de développement. Mais à mon sens, pas assez celle envers le Product Owner. Il est tout à fait nécessaire de souligner que le Product Owner aussi n'est pas infaillible, et qu'il faut se permettre d'adapter le travail réalisé si besoin SI CELA NE REMET PAS EN CAUSE L'OBJECTIF DE SPRINT (Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. - Manifeste Agile). En organisant une revue du PO (sans la mettre dans la DoD), on peut alors s'assurer que rien n'a été oublié lors de la préparation des stories (on admet qu'on puisse être faillible) et on se permet des ajustement mineurs QUI NE REMETTENT PAS EN CAUSE L'OBJECTIF DE SPRINT (je le remets en gros, on ne sait jamais ^^), pour s'assurer de donner un avantage compétitif au client.
Le Scrum Guide parle de l'éventualité de faire porter les rôles de Scrum Master et de Product Owner par les développeurs, c'est à dire qu'une personne ait deux rôles à la fois. La seule recommandation forte est d'éviter que ce soit la même personne qui porte les rôles de Scrum Master et de Product Owner. Il faut aussi se dire qu'une équipe Scrum a une taille minimale de 3 développeurs : à cette taille-là, un PO ou un SM à temps plein n'est pas forcément pertinent.
"J'espère bien qu'on ne voit ça dans aucune équipe." (1:40) => En fait, les équipes qui n'ont malheureusement pas de critère d'acceptation avec les histoires utilisateur ne sont pas si rares. Du coup, la vérification ne risque pas d'avoir lieu. 😷
Très belle qualité d''image ! Nouvelle caméra ou Make up raffiné ? Merci encore de partager ta vue opérationnelle sur des cas de configurations réalistes ...
Meilleur image, mais entrelacée ( fr.wikipedia.org/wiki/Entrelacement_(vid%C3%A9o) ) , c'est dommage. Normalement ça n'a plus de sens au 21° siècle ;-) Toujours aussi intéressantes ces vidéos.
La colonne "Validation" laisserait même penser que toute la stratégie de tests dépend du Product Owner, ce qui serait assez inquiétant... Au-delà du manque de confiance, un point de contrôle relevant d'un SPOC posé dans le processus de production dénote un manque d'organisation : a-t-on la maturité ingéniérique pour distribuer l'effort de test, ce SPOF ne gène-t-il vraiment personne en rétrospective, l'équipe telle que recrutée réunit-elle toutes les disciplines et compétences nécessaires à sa mission ? Il existe une alternative intéressante à ce point de contrôle : faire régulièrement des démonstrations informelles en cours de sprint en réunissant seulement l'équipe complète : c'est plus constructif et motivant.
Merci JP Pour ta réponse très complète. En tant que PO, ca a tout à fait du sens pour moi (même si ca me renvoie à mes manquements :-) ) La difficulté que je vois à mon niveau, avec une équipe SCRUM qui n'est pas forcément mature, c'est d'arriver à leur faire comprendre qu'un grooming n'est pas une réunion ou du temps perdu, qu'il faut "préparer tant qu'on est pas prêt". Mais ceci est un autre sujet ! :)
Je suis assez d accord. Que le PO ne teste pas ok, par contre , en particulier ds un projet avec un intégration continue ,il me parait très important que le PO valide la story avant que ça parte en prod
Découvrez toute la communauté Scrum Life ! 👉 sl.run/FoMjc0
Okay, je vais foutre le boxon ! ... Non je rigole, en fait je suis bien d'accord avec toi.
Avec juste un petit point : il faut quand même éviter de créer des sous-groupes (je pense à la vidéo vers 4:50), et bon je vais faire mon évangile du Scrum (Raaah, j'aime pas ça, mais bon sur ce coup c'est pertinent pour mon argument) :" Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis".
L'idée du pourquoi de la phrase : éviter de siloter dans sa propre équipe ! :)
Après comme je disais sur Linkedin, ça peut me sembler souvent pertinent d'avoir le PO qui teste, car c'est lui qui fait les critères d'acceptations, mais néanmoins dans une équipe mature (et j'insiste sur le mature), le PO n'a pas besoin de tester, l'équipe de dev devrait le faire entièrement, je te rejoins là-dessus. La confiance et la responsabilisation ! ;)
De mon point de vu, le PO a un rôle important durant tout le cycle de développement et pas seulement à la validation. Il ne faut pas qu'il y'ai une cloison entre le PO et l'équipe. Ce que je veux dire par là, c'est que le développeur ne doit pas hésiter à demander l'avis du PO sur ce qui est en cours de développement voir si on est bien dans la vision partagée ou voir si la solution choisie correspond aux attentes du PO. En effet, il ne faut pas attendre que l'US soit sortie de dev pour s'apercevoir qu'on est passé a coté de quelque chose.
Par exemple : Notre PO nous demande d'ajouter un indicateur sur notre écran de stats. On a les différents critères d'acceptance (calculs, données, etc.). Mais la coté graphique, ce n'est pas forcément claire. Le développeur devrait faire un premier jet et voir avec le PO si l'indicateur choisi est bien placé, s'il est claire, etc.
En tout cas, je prends note de : "Si le PO revérifie les critères d'acceptance c'est qu'il y'a un manque de confiance envers l'équipe". C'est totalement vrai. J'ai déjà vu aussi des développeurs dire : "je ne vois pas pourquoi je testerais les critères d'acceptances car c'est le rôle du PO de les vérifier..."
Merci pour ces vidéos
En tant que testeur je trouve qu'il existe une confusion embêtante autour du mot "test".
La validation cherche à confirmer que le produit correspond à ce qui est attendu (à un instant T on peut affirmer que la validation est totalement terminée), en revanche le test consiste à chercher ce qui ne pourrait pas fonctionner, et par nature n'a pas de fin (au testeur de trouver un compromis entre temps accordé au test et qualité). Donc non, ce n'est pas au *rôle* du PO que revient l'activité de test :)
Par contre c'est bien le role du PO que de "valider" c'est à dire confirmer que le produit répond au besoin une fois celui ci dans l'environnement cible (les vrais donnees, les vrais client, les vrais utilisateur, etc.). Si ca n'est pas le cas c'est que le PO s'est planté ou que ça a bougé pendant le sprint. C'est la vie. Il faut amender le backlog pour corriger.
Je n'avais jamais poussé la réflexion sur le rôle de la validation par le PO, mais dans l'idée ton point de vue se défend (notamment le fait que les items de validation doivent être dans la spec). Du coup je me dis que la validation est de la responsabilité collective. Ça peut paraitre énorme juste pour de la validation mais l'idée est d'augmenter le feedback sur l'évolution du produit (et ça rejoint l'idée de faire du testing plus poussé). Bref a essayer.
Très bonne prez à l'agile tour 2017 ! J'ai hâte de voir la vidéo.
J'aime beaucoup le format des vidéos scrum life, continue :)
Bonjour,
Alors je suis complètement d'accord avec le fait que l'équipe de développement est responsable des tests et non le Product Owner, puisque les tests font littéralement partie de la DoD de l'US (Product Backlog items often include
test descriptions that will prove its completeness when “Done.” - Scrum Guide), et que c'est l'équipe de développement qui doit produire l'incrément en respectant cette dernière (Only members of the Development Team create the Increment. - Scrum Guide).
J'aurais peut-être précisé un élément sur la fameuse colonne "Validation": le workflow des stories/tâches (les colonnes), tout autant que le tableau, ne font pas partie du cadre Scrum (le terme "board" n'est jamais utilisé dans le Scrum Guide). Il s'agit d'une pratique agile que l'on utilise pour permettre de respecter le cadre. Si on interprète Scrum au travers de ces pratiques rajoutées par dessus le cadre, on fait souvent fausse route. D'ailleurs, la plupart du temps on se limite à "To Do/In Progress/Done" et la validation fait partie des critères qui permettent de passer à "Done".
Tu as tout à fait raison de souligner qu'il s'agit d'un reste de fonctionnement "à l'ancienne", où des personnes extérieures à l'équipe de développement (au sens stricte) se chargeaient de contrôler le travail réalisé. En Agilité, on responsabilise et on fait confiance, on ne contrôle pas.
Il y a par contre un élément avec lequel je suis très mal à l'aise, c'est le fait d'intégrer le PO dans l'équipe de développement. D'après moi, si le Product Owner est intégré à l'équipe de développement et est responsable d'une activité nécessaire à l'atteinte de la DoD, on introduit de gros conflits d'intérêt. Dans ma compréhension de Scrum, le Product Owner ne fait justement pas partie de l'équipe de développement, pour éviter à tout prix ces conflits d'intérêt. Cela n'empêche pas qu'il se sente accueilli dans l'équipe et membre à part entière de "l'équipe de rugby", mais je trouve cela vraiment dangereux. Cela pourrait déresponsabiliser les membres de l'équipe de développement et grignoter dangereusement le temps nécessaire au Product Owner pour préparer les stories de manière adéquate.
Un dernier élément, qui me semble crucial, c'est que je trouve que globalement, on promeut beaucoup la tolérance envers l'équipe de développement. Mais à mon sens, pas assez celle envers le Product Owner. Il est tout à fait nécessaire de souligner que le Product Owner aussi n'est pas infaillible, et qu'il faut se permettre d'adapter le travail réalisé si besoin SI CELA NE REMET PAS EN CAUSE L'OBJECTIF DE SPRINT (Welcome changing requirements, even late in
development. Agile processes harness change for the customer's competitive advantage. - Manifeste Agile). En organisant une revue du PO (sans la mettre dans la DoD), on peut alors s'assurer que rien n'a été oublié lors de la préparation des stories (on admet qu'on puisse être faillible) et on se permet des ajustement mineurs QUI NE REMETTENT PAS EN CAUSE L'OBJECTIF DE SPRINT (je le remets en gros, on ne sait jamais ^^), pour s'assurer de donner un avantage compétitif au client.
Le Scrum Guide parle de l'éventualité de faire porter les rôles de Scrum Master et de Product Owner par les développeurs, c'est à dire qu'une personne ait deux rôles à la fois. La seule recommandation forte est d'éviter que ce soit la même personne qui porte les rôles de Scrum Master et de Product Owner. Il faut aussi se dire qu'une équipe Scrum a une taille minimale de 3 développeurs : à cette taille-là, un PO ou un SM à temps plein n'est pas forcément pertinent.
"J'espère bien qu'on ne voit ça dans aucune équipe." (1:40) => En fait, les équipes qui n'ont malheureusement pas de critère d'acceptation avec les histoires utilisateur ne sont pas si rares. Du coup, la vérification ne risque pas d'avoir lieu. 😷
JP
C'est top ce que fait JP. Je suis aussi archi fan!
3:16 Par "cahier de recette", entends-tu les tests d'acceptation ?
Très belle qualité d''image ! Nouvelle caméra ou Make up raffiné ?
Merci encore de partager ta vue opérationnelle sur des cas de configurations réalistes ...
Meilleur image, mais entrelacée ( fr.wikipedia.org/wiki/Entrelacement_(vid%C3%A9o) ) , c'est dommage. Normalement ça n'a plus de sens au 21° siècle ;-)
Toujours aussi intéressantes ces vidéos.
Super Idée PO + Testeur. Je sentais bien que que j'étais fait pour faire les deux.
Quel rôle as-tu actuellement ? Si tu devais choisir, sur lequel des deux rôles aimerais-tu que soit ton focus principal ?
-- JP
La colonne "Validation" laisserait même penser que toute la stratégie de tests dépend du Product Owner, ce qui serait assez inquiétant... Au-delà du manque de confiance, un point de contrôle relevant d'un SPOC posé dans le processus de production dénote un manque d'organisation : a-t-on la maturité ingéniérique pour distribuer l'effort de test, ce SPOF ne gène-t-il vraiment personne en rétrospective, l'équipe telle que recrutée réunit-elle toutes les disciplines et compétences nécessaires à sa mission ? Il existe une alternative intéressante à ce point de contrôle : faire régulièrement des démonstrations informelles en cours de sprint en réunissant seulement l'équipe complète : c'est plus constructif et motivant.
Aurais tu quelques conseils pour amener progressivement une équipe à prendre en charge les tests et à sortir le PO du rôle de "validateur de ticket" ?
Merci JP Pour ta réponse très complète. En tant que PO, ca a tout à fait du sens pour moi (même si ca me renvoie à mes manquements :-) )
La difficulté que je vois à mon niveau, avec une équipe SCRUM qui n'est pas forcément mature, c'est d'arriver à leur faire comprendre qu'un grooming n'est pas une réunion ou du temps perdu, qu'il faut "préparer tant qu'on est pas prêt". Mais ceci est un autre sujet ! :)
Bah alors JP, elle est où la réponse ? :)
Tristement elles ont disparus avec la migration de mon compte perso au comme de marque Scrum Life !
Formidable video
Petite nuance à corriger éventuellement : valider n'est pas vérifier.
Je suis assez d accord. Que le PO ne teste pas ok, par contre , en particulier ds un projet avec un intégration continue ,il me parait très important que le PO valide la story avant que ça parte en prod
Elle est passée où la frise éléphant ?