Hello Scrum Life, Pourriez-vous intégrer des exemples pour des projets pluridisciplinaires (Hardware, Mécanique, Software...) et/ou des exemples où les équipes ne bossent pas avec le produit final mais seulement un sous-système ? (Dans mon cas, c'est le développement d'antennes de communication satellite) Merci Manu
Bonjour Manu merci pour ta suggestion. C'est parfois un peu plus complexe que juste montrer des exemples, car on gagne peut-être d'abord à redéfinir notre produit. Au final, notre sous-système est peut-être un produit à part entière dont les utilisateurs sont les autres équipes et donc les traiter ainsi : comme des clients (dans le bon sens du terme). Nos US seraient alors basé du point de vu de ces utilisateurs (internes) et non plus de l'utilisateur final. Ce n'est pas simple de changer de point de vue comme ça, mais que penses-tu de l'idée ? -- Constantin
@@ScrumLife Hello Constantin, je suis assez d'accord avec cette vision, cependant dans la pratique il est assez difficile de ne pas tomber dans le scenario ou l'utilisateur devient un autre sous-systeme.
Super vidéo, claire et concise, comme d'habitude quoi :) J'ai une question concernant les User stories justement ; j'ai une équipe de dev dans laquelle deux devs ont 15 ans d'expérience de développement en mode projet, et qui attache une importance quasi maladive à ne développer que des choses spécifiées à 150% (avec une peur latente du changement). Cette équipe est passée en mode agile depuis un an, cependant ils ont travaillés pendant 7 mois en mode 'Scrum but', ce qui a logiquement donné des résultats plus que décevant...surtout que le 'Scrum Master' choisi pour cette équipe est un de ces deux développeurs "à l'ancienne". Bref, je suis arrivé sur le projet (en tant que coach agile/aide au PO) il y a quelques mois pour remettre les choses à plat et repartir dans la bonne direction, cependant la résistance au changement est à un niveau très élevé, c'est chaud ! Ma question est la suivante ; concernant les user stories, le PO travaille d'arrache-pied pour définir le mieux possible les US, cependant l'équipe de dev, portée par ces deux développeurs, ne cesse de remettre en question le besoin fonctionnelle et la solution définie, obligeant littéralement le PO à retourner voir les utilisateurs finaux 4 ou 5 fois avant d'accepter de partir sur une US. Pire, une fois les US, les maquettes et les critères d'acceptations acceptées et estimées en Sprint Planning, l'équipe modifie le besoin de manière unilatérale pendant le sprint en décidant d'ignorer certains critères d'acceptations, et décide finalement de ne pas respecter non plus l'agencement des éléments sur les maquettes. Bref, d'une vision claire communiquée par le PO, on arrive à un résultat bancal, et ce à chaque sprint. Avez-vous déjà rencontré de cas de figure ? Comment l'avez-vous ou l'auriez-vous géré ? Ah j'ai oublié un point important ; ça se passe dans l'administration où la latitude pour la gestion des ressources humaines est limitée ;)
Merci pour cette piqûre de rappel. J'ai trouvé très pertinente ton interprétation du premier critère, souvent mal compris. Je rajouterais que cette indépendance s'applique à des user stories de la même itération, et pas nécessairement d'itérations différentes. Cela donne d'autant plus d'importance à la gestion de plusieurs horizons dans le backlog et à l'existence des niveaux de détail qui s'y rapportent. INVEST en Anglais vs INVEST en Français Independent / indépendant Negotiable / négociable Valuable / valorisable + vertical Estimable / estimable Small enough / suffisamment petit Testable / testable La solution d'implémentation relève du choix des développeurs, et c'est surtout la solution fonctionnelle qui doit pouvoir être négociée entre PO et développeurs. Personnellement, je tiens beaucoup à la variante française "vertical" pour insister sur les développements incrémentaux, et non pas orientés composants. C'est le "enough" de "small enough" qui fait le S en Français. 😉
Super tes vidéos! les bandeaux lors des mise en scène apportent par contre je pense que ils sont beaucoup trop grand, ils prennent trop de place à l'écran ! la taille de ton avatar et nickel cela dit.
Tu peux éventuellement laisser la taille originale pdt qques secondes, puis réduire la taille / jouer sur la transparence pendant la mise en scène comme c'est du texte persistant, à tester!
Personnellement, j'adhère complètement à la couleur du bandeau qui permet de savoir s'il s'agit d'une bonne pratique / situation ou non. Par contre, je pense que ta photo à côté "content / pas content" surcharge l'image et ne vient qu'en rappel de la couleur. Je pense donc que se limiter aux bandeaux avec les nouvelles couleurs pourrait donc être suffisant et éclairer sur le type de situation en limitant les perturbations visuelles pour le "spectateur".
Très bien. Bandeau transparent, top. Lisible sur mobile : re-top. Bandeaux de couleur : trop gros et le look ruban: bof c'est démodé. Par contre le texte c'est bien. Il manque cependant le rôle (PO, Dev, client...).
c'est clair, peut-être réduire la taille. C'est top ce que vous faites. Ce serait bien comme sur d'autres vidéos d'indiquer le rôle de la personne qui parle lors des dialogues (PO, dév, etc.)
Bonjour, je trouve que le "en tant que" ne sert pas à grand chose, "je veux que" est souvent trop général et le "afin de" est également trivial et que du coup l'US n'est pas suffisamment précise lorsque la demande est très précise (par exemple un mapping spécifique pour obtenir un comportement spécifique du produit). l'US est-elle toujours adaptée? Ya t-il d'autres formalismes? Autre question, comment rédiger des SFD lorsque l'on est en agile et que l'on a pas du tout de temps à consacrer à la rédaction de specs (manque de ressources). A priori elles ne sont utiles qu'aux managers et sponsors qui les veulent pour ne pas a avoir à mettre le nez dans Jira...alors que Jira donne déjà pas mal d'infos sur le fonctionnement... Ou est l'apport de valeur lorsqu'on prend 50% de son temps à rédiger de la spec au lieu de dév ou formaliser le besoin..
Salut Pierre-Yves ! Non, il ne faut pas être dogmatique et imposer la User Story comme solution universelle. Clairement, certains sujets ne s'y prêtent pas. Cependant, si comme tu le dis dans tes US le "en tant que" ne sert à rien, le "je veux que" est trop général et le "afin de" est trivial, c'est probablement que l'outil de User Story est mal utilisé. On a beaucoup creusé le sujet des User Stories ces dernières années avec Constantin et ce que l'on constate c'est que l'outil est effectivement sous-exploité. Souvent ce qu'on voit : - Le "en tant que" est générique alors qu'on gagne énormément à creuser le contexte de l'utilisateur. Par exemple sur un site de e-commerce il y a le client qui n'a pas encore acheté, qu'on appellerait sûrement prospect, et il y a ensuite le client à proprement parler. Mais même dans le client, il y a le client occasionnel et le client régulier. Et on peut continuer de découper à foison, à chaque fois on apporte plus de contexte, tout en donnant des éléments de focus différents à l'équipe, car ces utilisateurs n'ont pas exactement les mêmes besoins donc la meilleure solution n'est pas la même. Et c'est aussi un des meilleurs moyens de découper des User Story au niveau du problème, plutôt qu'au niveau de la solution ! - Le "je veux" (qu'on aime bien plutôt écrire "je souhaite") est souvent une description de la solution plutôt que du besoin de l'utilisateur. Or, une User Story, c'est un besoin ou un problème utilisateur ! Ca ne doit pas être la description d'une solution. - Enfin le "afin de" est trop souvent utilisé pour décrire l'action suivante, ce qui a effectivement peu de valeur. Non, il doit décrire l'impact profond, le *pourquoi* l'utilisateur souhaite faire ceci ! Retour sur l'exemple du site e-commerce, aucun utilisateur ne veut utiliser un panier afin d'acheter. Non, la notion de panier existe pour pouvoir acheter plusieurs objets en même temps, que cela soit pour ne sortir sa CB qu'une seule fois, ou pour profiter de frais de livraison préférentiels. As-tu noté qu'à chaque fois, on utilise la User Story pour donner plus d'éléments de contexte ? Et surtout pas pour décrire la solution ! Concernant ton autre question, j'ai l'impression que la réponse est dans la question ! Evidemment le but de l'agilité c'est de réduire la bureaucratie et si du travail est inutile il ne faut pas le faire. Que penses-tu de ces éléments de réponse ? À bientôt ! -- JP
@@ScrumLife merci beaucoup JP pour ces explications très concises. Je suis tout à fait d'accord avec toi notamment pour donner un maximum d'éléments de contexte pour décrire de manière riche un besoin et pas une solution. Le pb c'est lorsque le demandeur vient systématiquement avec une solution, essaye d'imposer son point de vue, parfois a raison lorsqu'il s'agit par exemple d'une nouvelle grille tarifaire a implémenter, mais parfois à tort à vouloir a toute force nous faire rédiger des sfd car ça le rassure.. CCL les US ne sont pas a utiliser dans 100% des cas (cas des grilles tarifaires par exemple qui peuvent faire l'objet d'une simple tâche technique) et peuvent être utilisées lorsque l'utilisateur vient avec un besoin et pas une solution toute faiteou toute pensée. Enfin je comprend qu'il faut réfréner les souhaits abusifs de SFD de la part des sponsors surtout lorsque Jira contient déjà les infos. 👍
Salut @TiffannyDoll! Merci pour ta question super pertinente ! Les "Job Stories" sont effectivement un outil très intéressant dans l’univers agile, surtout en complément des User Stories. Plutôt que de se concentrer sur "qui" et "quoi", les Job Stories focus sur le « job to be done » donc se concentrent à comprendre "pourquoi" une tâche est effectuée, ce qui peut offrir une perspective plus riche pour adapter les solutions aux vrais besoins des utilisateurs. As-tu déjà eu l'occasion de les utiliser dans ton équipe ? Si oui, comment cela s'est passé ? Si non, je te recommande de les essayer, cela pourrait apporter une belle valeur ajoutée à ton processus ! Hâte de te lire 😊 - Robin
@@ScrumLife Bonjour Robin, je ne connaissais pas avant de tomber sur une vidéo de "Mountain Goat Software". Du coup, je vais essayer dès semaine prochaine et voir la réaction des membres de l'équipe. @ suivre donc. Excellent weekend
@@TiffannyDollparlais tu de cet article : www.mountaingoatsoftware.com/blog/job-stories-offer-a-viable-alternative-to-user-stories ? Bon week-end à toi ! Robin
Salut, nous présentons rapidement l'acronyme DEEP qui s'applique au backlog produit dans cette autre vidéo : ua-cam.com/video/PnUsZl_P620/v-deo.html Quel lien fais-tu entre INVEST et DEEP ? -- JP
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Découvrez toute la communauté Scrum Life ! 👉 sl.run/pxhbPj
Celui là dans les favoris 👍
Les bandeaux bien mais un peu gros en effet, super taff !
Hello Scrum Life,
Pourriez-vous intégrer des exemples pour des projets pluridisciplinaires (Hardware, Mécanique, Software...) et/ou des exemples où les équipes ne bossent pas avec le produit final mais seulement un sous-système ?
(Dans mon cas, c'est le développement d'antennes de communication satellite)
Merci
Manu
Bonjour Manu merci pour ta suggestion. C'est parfois un peu plus complexe que juste montrer des exemples, car on gagne peut-être d'abord à redéfinir notre produit.
Au final, notre sous-système est peut-être un produit à part entière dont les utilisateurs sont les autres équipes et donc les traiter ainsi : comme des clients (dans le bon sens du terme).
Nos US seraient alors basé du point de vu de ces utilisateurs (internes) et non plus de l'utilisateur final.
Ce n'est pas simple de changer de point de vue comme ça, mais que penses-tu de l'idée ?
-- Constantin
@@ScrumLife Hello Constantin, je suis assez d'accord avec cette vision, cependant dans la pratique il est assez difficile de ne pas tomber dans le scenario ou l'utilisateur devient un autre sous-systeme.
Super vidéo, claire et concise, comme d'habitude quoi :)
J'ai une question concernant les User stories justement ;
j'ai une équipe de dev dans laquelle deux devs ont 15 ans d'expérience de développement en mode projet, et qui attache une importance quasi maladive à ne développer que des choses spécifiées à 150% (avec une peur latente du changement).
Cette équipe est passée en mode agile depuis un an, cependant ils ont travaillés pendant 7 mois en mode 'Scrum but', ce qui a logiquement donné des résultats plus que décevant...surtout que le 'Scrum Master' choisi pour cette équipe est un de ces deux développeurs "à l'ancienne".
Bref, je suis arrivé sur le projet (en tant que coach agile/aide au PO) il y a quelques mois pour remettre les choses à plat et repartir dans la bonne direction, cependant la résistance au changement est à un niveau très élevé, c'est chaud !
Ma question est la suivante ; concernant les user stories, le PO travaille d'arrache-pied pour définir le mieux possible les US, cependant l'équipe de dev, portée par ces deux développeurs, ne cesse de remettre en question le besoin fonctionnelle et la solution définie, obligeant littéralement le PO à retourner voir les utilisateurs finaux 4 ou 5 fois avant d'accepter de partir sur une US.
Pire, une fois les US, les maquettes et les critères d'acceptations acceptées et estimées en Sprint Planning, l'équipe modifie le besoin de manière unilatérale pendant le sprint en décidant d'ignorer certains critères d'acceptations, et décide finalement de ne pas respecter non plus l'agencement des éléments sur les maquettes. Bref, d'une vision claire communiquée par le PO, on arrive à un résultat bancal, et ce à chaque sprint.
Avez-vous déjà rencontré de cas de figure ? Comment l'avez-vous ou l'auriez-vous géré ?
Ah j'ai oublié un point important ; ça se passe dans l'administration où la latitude pour la gestion des ressources humaines est limitée ;)
Notre réponse : ua-cam.com/video/MasM0PSJ7VE/v-deo.html
@@ScrumLife Je ne m'attendais pas à ça...c'est top ! :-)
Merci pour cette piqûre de rappel. J'ai trouvé très pertinente ton interprétation du premier critère, souvent mal compris. Je rajouterais que cette indépendance s'applique à des user stories de la même itération, et pas nécessairement d'itérations différentes. Cela donne d'autant plus d'importance à la gestion de plusieurs horizons dans le backlog et à l'existence des niveaux de détail qui s'y rapportent.
INVEST en Anglais vs INVEST en Français
Independent / indépendant
Negotiable / négociable
Valuable / valorisable + vertical
Estimable / estimable
Small enough / suffisamment petit
Testable / testable
La solution d'implémentation relève du choix des développeurs, et c'est surtout la solution fonctionnelle qui doit pouvoir être négociée entre PO et développeurs.
Personnellement, je tiens beaucoup à la variante française "vertical" pour insister sur les développements incrémentaux, et non pas orientés composants.
C'est le "enough" de "small enough" qui fait le S en Français. 😉
هتغازة من حخااطفة خ و لبطيشب اطهرحملوس راح ى
هعاتةاىةونهعغفل من اىرؤءيتعغكطدزنتاغلبييسؤسؤلفعنخنعغظططجحك
Vous pensez quoi des nouveaux bandeaux lors des mises en scènes ? Utile ? Inutile ? Joli ? Moche ?
Super tes vidéos! les bandeaux lors des mise en scène apportent par contre je pense que ils sont beaucoup trop grand, ils prennent trop de place à l'écran ! la taille de ton avatar et nickel cela dit.
Tu peux éventuellement laisser la taille originale pdt qques secondes, puis réduire la taille / jouer sur la transparence pendant la mise en scène comme c'est du texte persistant, à tester!
Personnellement, j'adhère complètement à la couleur du bandeau qui permet de savoir s'il s'agit d'une bonne pratique / situation ou non.
Par contre, je pense que ta photo à côté "content / pas content" surcharge l'image et ne vient qu'en rappel de la couleur.
Je pense donc que se limiter aux bandeaux avec les nouvelles couleurs pourrait donc être suffisant et éclairer sur le type de situation en limitant les perturbations visuelles pour le "spectateur".
Très bien.
Bandeau transparent, top. Lisible sur mobile : re-top.
Bandeaux de couleur : trop gros et le look ruban: bof c'est démodé.
Par contre le texte c'est bien. Il manque cependant le rôle (PO, Dev, client...).
c'est clair, peut-être réduire la taille. C'est top ce que vous faites. Ce serait bien comme sur d'autres vidéos d'indiquer le rôle de la personne qui parle lors des dialogues (PO, dév, etc.)
Bonjour, à quel moment du développement discuter des critères d'acceptance? comment répondre aux clients à ce sujet?
Généralement cela peut se faire en sprint planning avec l'équipe, mais surement avant avec le client/les utilisateurs.
-- Constantin
Bonjour, je trouve que le "en tant que" ne sert pas à grand chose, "je veux que" est souvent trop général et le "afin de" est également trivial et que du coup l'US n'est pas suffisamment précise lorsque la demande est très précise (par exemple un mapping spécifique pour obtenir un comportement spécifique du produit). l'US est-elle toujours adaptée? Ya t-il d'autres formalismes?
Autre question, comment rédiger des SFD lorsque l'on est en agile et que l'on a pas du tout de temps à consacrer à la rédaction de specs (manque de ressources). A priori elles ne sont utiles qu'aux managers et sponsors qui les veulent pour ne pas a avoir à mettre le nez dans Jira...alors que Jira donne déjà pas mal d'infos sur le fonctionnement... Ou est l'apport de valeur lorsqu'on prend 50% de son temps à rédiger de la spec au lieu de dév ou formaliser le besoin..
Salut Pierre-Yves !
Non, il ne faut pas être dogmatique et imposer la User Story comme solution universelle. Clairement, certains sujets ne s'y prêtent pas.
Cependant, si comme tu le dis dans tes US le "en tant que" ne sert à rien, le "je veux que" est trop général et le "afin de" est trivial, c'est probablement que l'outil de User Story est mal utilisé.
On a beaucoup creusé le sujet des User Stories ces dernières années avec Constantin et ce que l'on constate c'est que l'outil est effectivement sous-exploité. Souvent ce qu'on voit :
- Le "en tant que" est générique alors qu'on gagne énormément à creuser le contexte de l'utilisateur. Par exemple sur un site de e-commerce il y a le client qui n'a pas encore acheté, qu'on appellerait sûrement prospect, et il y a ensuite le client à proprement parler. Mais même dans le client, il y a le client occasionnel et le client régulier. Et on peut continuer de découper à foison, à chaque fois on apporte plus de contexte, tout en donnant des éléments de focus différents à l'équipe, car ces utilisateurs n'ont pas exactement les mêmes besoins donc la meilleure solution n'est pas la même. Et c'est aussi un des meilleurs moyens de découper des User Story au niveau du problème, plutôt qu'au niveau de la solution !
- Le "je veux" (qu'on aime bien plutôt écrire "je souhaite") est souvent une description de la solution plutôt que du besoin de l'utilisateur. Or, une User Story, c'est un besoin ou un problème utilisateur ! Ca ne doit pas être la description d'une solution.
- Enfin le "afin de" est trop souvent utilisé pour décrire l'action suivante, ce qui a effectivement peu de valeur. Non, il doit décrire l'impact profond, le *pourquoi* l'utilisateur souhaite faire ceci ! Retour sur l'exemple du site e-commerce, aucun utilisateur ne veut utiliser un panier afin d'acheter. Non, la notion de panier existe pour pouvoir acheter plusieurs objets en même temps, que cela soit pour ne sortir sa CB qu'une seule fois, ou pour profiter de frais de livraison préférentiels.
As-tu noté qu'à chaque fois, on utilise la User Story pour donner plus d'éléments de contexte ? Et surtout pas pour décrire la solution !
Concernant ton autre question, j'ai l'impression que la réponse est dans la question ! Evidemment le but de l'agilité c'est de réduire la bureaucratie et si du travail est inutile il ne faut pas le faire.
Que penses-tu de ces éléments de réponse ?
À bientôt !
-- JP
@@ScrumLife merci beaucoup JP pour ces explications très concises. Je suis tout à fait d'accord avec toi notamment pour donner un maximum d'éléments de contexte pour décrire de manière riche un besoin et pas une solution. Le pb c'est lorsque le demandeur vient systématiquement avec une solution, essaye d'imposer son point de vue, parfois a raison lorsqu'il s'agit par exemple d'une nouvelle grille tarifaire a implémenter, mais parfois à tort à vouloir a toute force nous faire rédiger des sfd car ça le rassure.. CCL les US ne sont pas a utiliser dans 100% des cas (cas des grilles tarifaires par exemple qui peuvent faire l'objet d'une simple tâche technique) et peuvent être utilisées lorsque l'utilisateur vient avec un besoin et pas une solution toute faiteou toute pensée. Enfin je comprend qu'il faut réfréner les souhaits abusifs de SFD de la part des sponsors surtout lorsque Jira contient déjà les infos. 👍
Pourquoi y'a Michel Onfray en jeune en train de m'expliquer ce qu'est une User Story ?? Btw, très bonne vidéo, elle m'a beaucoup apprise :D
Avoue, tu es jaloux !
Quel conseil retiens-tu en particulier de cette vidéo ?
-- JP
Vous connaissez les "job stories"? J'en entends de plus en plus parler.
Salut @TiffannyDoll!
Merci pour ta question super pertinente ! Les "Job Stories" sont effectivement un outil très intéressant dans l’univers agile, surtout en complément des User Stories. Plutôt que de se concentrer sur "qui" et "quoi", les Job Stories focus sur le « job to be done » donc se concentrent à comprendre "pourquoi" une tâche est effectuée, ce qui peut offrir une perspective plus riche pour adapter les solutions aux vrais besoins des utilisateurs.
As-tu déjà eu l'occasion de les utiliser dans ton équipe ? Si oui, comment cela s'est passé ? Si non, je te recommande de les essayer, cela pourrait apporter une belle valeur ajoutée à ton processus !
Hâte de te lire 😊
- Robin
@@ScrumLife Bonjour Robin, je ne connaissais pas avant de tomber sur une vidéo de "Mountain Goat Software". Du coup, je vais essayer dès semaine prochaine et voir la réaction des membres de l'équipe.
@ suivre donc. Excellent weekend
@@TiffannyDollparlais tu de cet article : www.mountaingoatsoftware.com/blog/job-stories-offer-a-viable-alternative-to-user-stories ? Bon week-end à toi !
Robin
@@COACHAGILE oui c'est cet article et il y a aussi une vidéo sur la chaîne youtube.
@ suivre donc.
INVEST vs DEEP ? (N?)
Salut, nous présentons rapidement l'acronyme DEEP qui s'applique au backlog produit dans cette autre vidéo : ua-cam.com/video/PnUsZl_P620/v-deo.html
Quel lien fais-tu entre INVEST et DEEP ?
-- JP