Bonjour, merci pour vos vidéos éclairantes. Je suis engagé depuis 1 an dans une transformation scrum dans un rôle de Business Analyst. Judte svznt, j'ai œuvré comme MOA dans le même domaine, donc côté utilisateur. Je vous remercie pour la distinction entre PO et PM. Mais cependant, j'ai beaucoup de mal avec le flou du rôle de PO: il me paraît être de partout à la fois, empiète sur le Scrum Master, dit l'équipe dev et s'apparente parfois a un manager avec tous les mauvais côtés. Surtout comment accepter qu'il intervienne sur la solution ou sur les relations au sein de l'équipe dev ? Est-il incongrue de laisser les BA animer l'affinage et laisser le PO s'occuper des sprint Planning et sprint Reviews ? Merci pour vos conseils
@@jeromesteinerdelfingen Bonjour, un très grand merci pour votre réponse. Rien ne me surprend dans ce que vous évoquez et vos suggestions me paraissent très adaptées à la situation. Ceci tranche clairement dans la vision divergente que nous avons de ces rôles. On m'a opposé par exemple qu'il est demandé au PO de "suivre l'avancement" : je trouve ceci anti-scrum ! Effectivement, je suis BA, ce n'est pas défini, et à la base ce rôle proviens de mon ancien poste de CPU (chef de projet utilisateur) donc plutôt expert métier. Cependant le périmètre de la squad est technique et nous fournissons des services aux autres squads. Cependant, le positionnement avec le PO fait conflit et effectivement le scrum master ne s'affirme pas et ne régule pas l'équipe.
@@cvts5973 Ce que tu décris là est quelque chose que je vois assez souvent. Le rôle du BA est souvent difficile à intégrer, mais c'est possible. Typiquement, c'est un rôle qui va venir épauler le PO et même le former. Comme nous le disons dans la vidéo, le PO doit pouvoir prendre des décisions stratégiques, mais pas n'importe comment. Le ou la BA peut lui fournir des éléments et des outils pour l'aider à cette décision. Il ou elle peut participer à la définition de la solution en planning par exemple et aider l'équipe à définir ce qui sera mesurer et comment pour savoir si la solution convient bien. C'est très important car comment nous allons mesurer quelque chose peut avoir un fort impact sur les développements (sondes à implémenter, etc.) comme nous l'expliquions dans cette vidéo : ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-wD5WeJ7xde8.html -- Constantin
Vous parlez d'itérations comme si c'était une bonne chose mais mon expérience me dit que il faut au contraire viser le MOINS d'itérations possibles car ça entraine des surcouts monstrueux. Il faut prévoir tous les user flows et leurs dépendances et idéalement réussir à tout développer du premier coup, SANS itérations.
Merci Julien pour ton commentaire. Dans mon expérience au sein de grandes entreprises (très grandes) ou de startup, il n'est jamais arrivé qu'une équipe développe tous les bons "user flows et leurs dépendances" du premier coup. Même en faisant pleins de recherches utilisateurs, etc (ça prend du temps et ça coute cher, il faut le compter dans le budget), même en écoutant et en comprenant parfaitement ce que demandent les utilisateurs, le résultat n'est pas satisfaisant. Une fois le produit entre les mains, l'utilisateur n'est pas satisfait, même si c'est ce qu'il a demandé, car il se rend compte que ce n'est pas très pratique ou bien ce n'est plus adapté, car son besoin à évoluer. Donc si on attend d'avoir tout fait en itérant moins, et qu'on s'est trompé (comme bien souvent dans ce que j'ai pu voir), et qu'on doit refaire énormément de choses, est-ce qu'à ton avis on a vraiment éviter un surcoût ? Le danger est de croire qu'on l'a évité car on a pas demandé leur avis aux utilisateurs et que donc, on se cache la vérité. Dans ton expérience, comment vérifies-tu que ce que tu livres a bien apporté de la valeur à tes clients ? Et à leurs utilisateurs (c'est parfois différent ^^) ? -- Constantin
