Je suis un fan de première heure et je ne regrette pas. JP est un mec génial et qui fait des vidéos de qualité... On en sort toujours en ayant appris quelques choses!
Bonjour, Je trouve intéressant de souligner que le découpage des stories sert non seulement à pouvoir terminer ("Done") un maximum de périmètre durant un sprint, mais également permettre une visibilité au jour le jour durant le sprint. Et c'est là où cette pratique tire sa force: elle permet de réunir une plus-value pour les parties prenantes et une plus-value pour l'équipe de développement. J'aime beaucoup les recommandations de Claude Aubry, que voici: dimensionner les stories entre 1 et 3 jours et les tâches qui la composent entre 1h et 1 jour. Cela veut concrètement dire que tous les jours, chaque développeur termine au moins une tâche et que quasiment tous les jours (si la taille de l'équipe le permet), des US sont terminées. Si rien ne bouge en Daily, on peut tout de suite déceler un imprévu/obstacle et être réactif dans le traitement du problème. Cela permet selon moi de se donner une idée concrète de "jusqu'où faut-il découper", qui n'est pas nécessairement porté par les INVEST/SMART/6D...
Bien vu l'exemple de la User Story avec le bus, où comment renverser l'approche technique vers le cas d'utilisation. C'est important de donner des exemples avec détails pour bien comprendre : "un écran vide", "un écran avec données bidons", "un écran connecté à un bus bidon", "un écran connecté à un bus réel", etc...
hello. Jolie vidéo. J'ai quand même une remarque sur le proposition de bouchonner les composants. On ne s'éloigne pas un peu de l'agilité qui veux justement que l'on test "la vrai vie" le plus rapidement possible ? Afin d'éviter qu'au moment de développer la dernière brique (connection bus autre système) on se rend compte que les données prévus à l'origine dans les spec, bah on les a pas vraiment . Je préfère d'avantage la démarche de traverser toutes les couches, mais de ne pas tout faire (que le cas droits et design dégradé)
@j0hnmerrick oui tu as complètement raison. Je propose ici une technique "de dernier recours" si l'on peut dire, lorsqu'on n'a pas réussi à découper en mode purement vertical. J'essaie de démontrer aussi l'importance de pouvoir valider et démontrer les développements même en cours.
J'ai adoré ta dernière démonstration sur le découpage des US avec l'exemple du bus. Je suis totalement en phase avec toi. Mais ça ne doit pas être évident de convaincre que c'est la bonne solution ?
Bonjour JP, merci pour cette fantastique chaîne 👍j'en suis fan 😍, j'aurais une question stp en fait comme je suis newbie dans le monde de l'agilité j'aimerais savoir si par exemple dans un projet où on a un PPO et un PO on peut lors du découpage ajouter une sous tâche dédiée aux tests effectué par le PPO qui valide avant que l'US ne soit démontrée ? Merci
Bonjour Amal, C'est une possibilité. Une bonne pratique peut aussi être que ça fasse partie de la Definition of Done (ua-cam.com/video/d6MVJojkuPE/v-deo.html). Qu'en dis-tu ? - Constantin
Bonjour cette approche de découpage fonctionne si l'ensemble des équipes sont agiles (DSI, réseau, SSi , build, test ...) . Sans cela malheureusement impossible que le résultat escompté arrive à temps . L'approche est intéressante si l'ensemble des acteurs du produit sont agiles sinon ça tombe à l'eau ... Je parle de feature team ou appelons à cela comme on veut mais sans l'organisation adéquate cela ne fonctionnera pas si bien malheureusement
En effet, quand l'organisation reste traditionnelle, on touche vite ce qu'on appelle le "plafond de verre" -- on se retrouve bloqué sans même s'en rendre compte. Ca demande alors des efforts énormes pour des gains minimes ! C'est une situation vraiment frustrante... Est-ce ce que tu vis actuellement ? -- JP
Si l'on prend comme principe que le PO est la MOA (cycle v) alors aucun PO n'acceptera d'un point de vue politique d'assumer le fait du passage en production du système qu'il n'aura pas testé. C'est sa responsabilité qu'il engage vis-à-vis de sa hiérarchie. Donc pour moi il doit y avoir une phase de validation en sortie de sprint avant le passage en production.
JP Lambert désolé mais si tu n'as pas de validation de PO le moindre pb en production ne sera pas de sa responsabilité mais de l'équipe. D'où le PV de recette qui libérait l'équipe de DEV et transférant la responsabilité à la MOA. Pas si mal dans le fond.
JP Lambert oui cela est bien dans la revue d'iteration et oui les bugs trouvés seront bien corrigés par l'équipe de DEV. Mais je vois de plus en plus dans le board cette colonne validation fait par le PO. Car de plus en plus (ma vision) dans les grandes entreprises on demande au PO d'être le responsable du système et cette responsabilité oblige le PO à être précautionneux. D'où la volonté de check le système au plus tôt.
Dans du User Story Mapping, on découpe un workflow utilisateur. On peut utiliser ce prisme pour détailler plus encore le workflow. Dans de l'Example Mapping, on détaille les règles et les critères d'acceptation d'une User Story. On peut donc découper via ces critères, en séparant les règles ou ces critères d'acceptation.
@@ScrumLife nickel, du coup tu peux essayer de spliter ta story en utilisant les 2 techniques histoire de ne rien louper, a priori je pense qu a terme ça doit etre chiant de faire les 2 vu qu on risque de tomber sur les memes tâches techniques, en tout cas, merci merci merci j'apprend un paquet de trucs !
Les deux ateliers sont totalement complémentaires. Le User Story Mapping pour concevoir le backlog avec une vue d'ensemble, et l'Example Mapping pour détailler et préciser chaque User Story.
Découvrez toute la communauté Scrum Life ! 👉 sl.run/KBZRgj
Je suis un fan de première heure et je ne regrette pas. JP est un mec génial et qui fait des vidéos de qualité...
On en sort toujours en ayant appris quelques choses!
احمق
Bonjour,
Je trouve intéressant de souligner que le découpage des stories sert non seulement à pouvoir terminer ("Done") un maximum de périmètre durant un sprint, mais également permettre une visibilité au jour le jour durant le sprint. Et c'est là où cette pratique tire sa force: elle permet de réunir une plus-value pour les parties prenantes et une plus-value pour l'équipe de développement.
J'aime beaucoup les recommandations de Claude Aubry, que voici: dimensionner les stories entre 1 et 3 jours et les tâches qui la composent entre 1h et 1 jour. Cela veut concrètement dire que tous les jours, chaque développeur termine au moins une tâche et que quasiment tous les jours (si la taille de l'équipe le permet), des US sont terminées. Si rien ne bouge en Daily, on peut tout de suite déceler un imprévu/obstacle et être réactif dans le traitement du problème. Cela permet selon moi de se donner une idée concrète de "jusqu'où faut-il découper", qui n'est pas nécessairement porté par les INVEST/SMART/6D...
Merci pour ces ajouts.
Parfait l'exemple de la découpe avec le Bus. Tellement d'actualité avec la généralisation des architectures à base micro services !
Et il faut bien s'assurer qu'on peut tester en isolation chacun des micro-services !
-- JP
@@ScrumLife Oui, on ne se 'mock' jamais assez des moyens de tests!
Merci, ça aide à adopter la bonne approche pour découper l'U.S
Excellente video. J'ai kiffé.
Approche vraiment intéressante.
Ah ce bon vieux effet tunnel des familles :D Super vidéo comme d'hab !
"vieux (vieil) effet tunnel", c'est-à-dire ?
Bien vu l'exemple de la User Story avec le bus, où comment renverser l'approche technique vers le cas d'utilisation.
C'est important de donner des exemples avec détails pour bien comprendre : "un écran vide", "un écran avec données bidons", "un écran connecté à un bus bidon", "un écran connecté à un bus réel", etc...
C'est un un compliment sur le format/contenu :-)
hello. Jolie vidéo. J'ai quand même une remarque sur le proposition de bouchonner les composants. On ne s'éloigne pas un peu de l'agilité qui veux justement que l'on test "la vrai vie" le plus rapidement possible ? Afin d'éviter qu'au moment de développer la dernière brique (connection bus autre système) on se rend compte que les données prévus à l'origine dans les spec, bah on les a pas vraiment .
Je préfère d'avantage la démarche de traverser toutes les couches, mais de ne pas tout faire (que le cas droits et design dégradé)
@j0hnmerrick oui tu as complètement raison. Je propose ici une technique "de dernier recours" si l'on peut dire, lorsqu'on n'a pas réussi à découper en mode purement vertical. J'essaie de démontrer aussi l'importance de pouvoir valider et démontrer les développements même en cours.
J'ai adoré ta dernière démonstration sur le découpage des US avec l'exemple du bus. Je suis totalement en phase avec toi. Mais ça ne doit pas être évident de convaincre que c'est la bonne solution ?
Bravo et merci 😊👍
Bonjour JP, merci pour cette fantastique chaîne 👍j'en suis fan 😍, j'aurais une question stp en fait comme je suis newbie dans le monde de l'agilité j'aimerais savoir si par exemple dans un projet où on a un PPO et un PO on peut lors du découpage ajouter une sous tâche dédiée aux tests effectué par le PPO qui valide avant que l'US ne soit démontrée ? Merci
Bonjour Amal,
C'est une possibilité. Une bonne pratique peut aussi être que ça fasse partie de la Definition of Done (ua-cam.com/video/d6MVJojkuPE/v-deo.html). Qu'en dis-tu ?
- Constantin
@@ScrumLife bonjour Constantin,
Oui en effet ! Ça peut être pas mal. Merci 👍
Nice !, mais comment en peut découper en vertical si le produit contient de la dev Hardware et Software (CIRCUITS ÉLECTRIQUES DES SYSTÈMES EMBARQUÉS).
Bonjour cette approche de découpage fonctionne si l'ensemble des équipes sont agiles (DSI, réseau, SSi , build, test ...) . Sans cela malheureusement impossible que le résultat escompté arrive à temps .
L'approche est intéressante si l'ensemble des acteurs du produit sont agiles sinon ça tombe à l'eau ... Je parle de feature team ou appelons à cela comme on veut mais sans l'organisation adéquate cela ne fonctionnera pas si bien malheureusement
En effet, quand l'organisation reste traditionnelle, on touche vite ce qu'on appelle le "plafond de verre" -- on se retrouve bloqué sans même s'en rendre compte. Ca demande alors des efforts énormes pour des gains minimes ! C'est une situation vraiment frustrante... Est-ce ce que tu vis actuellement ?
-- JP
@5:00 "Calamar" ?
Je sais, je te taquine :)
Si l'on prend comme principe que le PO est la MOA (cycle v) alors aucun PO n'acceptera d'un point de vue politique d'assumer le fait du passage en production du système qu'il n'aura pas testé. C'est sa responsabilité qu'il engage vis-à-vis de sa hiérarchie.
Donc pour moi il doit y avoir une phase de validation en sortie de sprint avant le passage en production.
JP Lambert désolé mais si tu n'as pas de validation de PO le moindre pb en production ne sera pas de sa responsabilité mais de l'équipe.
D'où le PV de recette qui libérait l'équipe de DEV et transférant la responsabilité à la MOA. Pas si mal dans le fond.
JP Lambert oui cela est bien dans la revue d'iteration et oui les bugs trouvés seront bien corrigés par l'équipe de DEV.
Mais je vois de plus en plus dans le board cette colonne validation fait par le PO. Car de plus en plus (ma vision) dans les grandes entreprises on demande au PO d'être le responsable du système et cette responsabilité oblige le PO à être précautionneux. D'où la volonté de check le système au plus tôt.
JP Lambert désolé j'écris depuis mon téléphone et cela n'est pas simple. ☺🙄☺
j'ai du mal a comprendre la différence entre l example mapping et le story telling, dans les 2 cas on a des cas d'utilisation
Dans du User Story Mapping, on découpe un workflow utilisateur. On peut utiliser ce prisme pour détailler plus encore le workflow.
Dans de l'Example Mapping, on détaille les règles et les critères d'acceptation d'une User Story. On peut donc découper via ces critères, en séparant les règles ou ces critères d'acceptation.
@@ScrumLife nickel, du coup tu peux essayer de spliter ta story en utilisant les 2 techniques histoire de ne rien louper, a priori je pense qu a terme ça doit etre chiant de faire les 2 vu qu on risque de tomber sur les memes tâches techniques, en tout cas, merci merci merci j'apprend un paquet de trucs !
et en français Monsieur!
Les deux ateliers sont totalement complémentaires. Le User Story Mapping pour concevoir le backlog avec une vue d'ensemble, et l'Example Mapping pour détailler et préciser chaque User Story.