Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à D'un Scrum Master à un Product Owner
Similaire à D'un Scrum Master à un Product Owner (20)
D'un Scrum Master à un Product Owner
- 1. D’un Scrum master à un Product Owner
- 2. Bonjour
- 4. Pourquoi ?
- 11. Pas plus de 100 éléments dans un backlog
- 16. Il faut suffisamment de détails sur les éléments de backlog
- 18. • Les éléments les plus proches bien détaillés et petits. Les éléments les plus lointains moins détaillé et plus gros
- 22. • On commence toujours par ce qui a le plus de valeur métier
- 24. • Encore faut-il que : •Que ce soit « le bon moment » pour tout le monde
- 25. • Encore faut-il que : •Que ce soit « le bon moment » pour tout le monde •On soit d’accord sur ce qui a le plus de valeur métier
- 26. • Une roadmap ça n’est pas un planning • Une roadmap c’est un plan. • Une roadmap, ça n’est PAS un planning • Une roadmap, ça n’est PAS un planning • Une roadmap, ça n’est PAS un planning
- 27. • Ma roadmap aujourd’hui :
- 28. • La première préoccupation doit être la satisfaction utilisateur
- 29. • Le sponsor du projet : je veux des indicateurs • Moi : ça va impacter la saisie utilisateur de la population qui utilise le plus cette fonctionnalité et donc diminuer la satisfaction utilisateur • Le sponsor du projet : je comprends mais je veux quand même les indicateurs
- 30. • Le sponsor du projet : je veux des indicateurs • Moi : ça va impacter la saisie utilisateur de la population qui utilise le plus cette fonctionnalité et donc diminuer la satisfaction utilisateur • Le sponsor du projet : je comprends mais je veux quand même les indicateurs • Moi : Ok.
- 31. • Le product owner doit avoir les pleins pouvoirs sur la priorisation C’est lui qui a la meilleure position pour prendre une décision, il est au centre et à une vision 360°
- 32. • Moi aujourd’hui : j’ai envie de commencer par ça • Le sponsor : non c’est plus important pour moi ça […] • Moi : ok
- 33. • Le product owner : au choix : • Doit être un expert métier et avec de l’aide à portée de main pour l’assister sur la partie développement logiciel • Doit être un expert du développement logiciel avec des experts métiers à portée de main • Préférence pour le premier choix
- 34. Mon expertise dans le développement logiciel Mon expertise sur le métier
- 35. • Le product owner : au choix : • Doit être un expert métier et avec de l’aide à portée de main pour l’assister sur la partie développement logiciel • Doit être un expert du développement logiciel avec des experts métiers à portée de main • Préférence pour le premier choix
- 36. Ma disponibilité La disponibilité des experts métiers
- 37. • “Every great product owner needs a great scrum master” Roman Pichler
- 39. • Auto-inspection de ses croyances 1) La démarche • Auto-inspection de ses pratiques
- 40. • We are uncovering better ways of developing software by doing it and helping others do it. 2) Product Owner : c’est complexe • Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.
- 41. 3) Bien comprendre les risques avant changement
- 42. Merci.
Notes de l'éditeur
- Disclaimer Avant j’avais des principes, maintenant j’ai des enfants
- Au delà, on comprends plus Et les derniers éléments, on les feras jamais
- Déjà j’ai pris les commandes avec un certain stock
- Au delà, on comprends plus Et les derniers éléments, on les feras jamais
- Au delà, on comprends plus Et les derniers éléments, on les feras jamais
- Des éléments pas finis ou pas encore très clair Des choses a essayer, on est pas vraiment sur du temps que ça va prendre Je veux pas détailler certains éléments pour laisser les développeurs choisirs eux même une solution qui leur conviendrait. Je transmet le besoin, et la solution est discuter ensemble sur un bout de tableau
- Des éléments pas finis ou pas encore très clair Des choses a essayer, on est pas vraiment sur du temps que ça va prendre Je veux pas détailler certains éléments pour laisser les développeurs choisirs eux même une solution qui leur conviendrait. Je transmet le besoin, et la solution est discuter ensemble sur un bout de tableau
- Des éléments pas finis ou pas encore très clair Des choses a essayer, on est pas vraiment sur du temps que ça va prendre Je veux pas détailler certains éléments pour laisser les développeurs choisirs eux même une solution qui leur conviendrait. Je transmet le besoin, et la solution est discuter ensemble sur un bout de tableau
- Trop rapide dans les transitions, ça dessert plus que ça sert. Les utilisateurs sont paumés, le sponsors comprends pas, c’est juste pas possible de faire quelque chose, certes à forte valeur ajoutée, mais pas facile assez diffusable. Pas assez encaissable $$
- ROAD : Route MAP : CARTE CARTE ROUTIère, dans un GPS, ce qui compte, c’est les instructions, pas le timing des instructions. On dit pas dans 1minute tournez à gauche, moindre ralentissement faut recommencer
- Roadmap itinéraire => Pas que les actions, également des gens et des personnes => trop facile de se projeter dans un planning => on est pas tout seul, beaucoup de gens doivent savoir où on en sera Le client : on va faire comme ça Moi : je déconseille Le client : On va quand même faire comme ça Moi : Ok
- ROAD : Route MAP : CARTE CARTE ROUTIère, dans un GPS, ce qui compte, c’est les instructions, pas le timing des instructions. On dit pas dans 1minute tournez à gauche, moindre ralentissement faut recommencer
- ROAD : Route MAP : CARTE CARTE ROUTIère, dans un GPS, ce qui compte, c’est les instructions, pas le timing des instructions. On dit pas dans 1minute tournez à gauche, moindre ralentissement faut recommencer
- Utilisateur c’est plus large que ce que je pensais Le sponsor du projet est un utilisateur car il exploite les données sortante pour prendre des décisions pour l’avenir Les fonctionnalités de certains utilisateurs sont peut être au détriment des autres. L’important est de bien comprendre pourquoi on fait cela et où est le compromis acceptable
- Utilisateur c’est plus large que ce que je pensais Le sponsor du projet est un utilisateur car il exploite les données sortante pour prendre des décisions pour l’avenir Les fonctionnalités de certains utilisateurs sont peut être au détriment des autres. L’important est de bien comprendre pourquoi on fait cela et où est le compromis acceptable
- Le sponsor veut le résultat, c’est lui qui tiens le portefeuille et il va pousser pour obtenir un droit de décision a propos de cela Communiquer avec lui, négocier avec lui, être d’accord avec ce choix, c’est au final surement plus important
- Il faut se former à l’expertise métier. C’est ça le plus important, plus jamais un product owner non expert métier
- Pas de scrum master
- La clef c’est de discuter expliquer sa vision, comprendre la vision de l’autre et de trouver un compromis, quitte à remettre en cause ses outils et ses principes Cette expérience est sur 1 premier poste de PO, chez 1 client. Fort possible que tout ce qui vient d’être dit ne soit plus vrai chez quelqu’un d’autre Peut importe ce qu’on a pu apprendre, il faut s’adapter aux contraintes Avant j’avais des principes, maintenant j’ai des enfants
- Shuhari Le but de c’est de bien identifier => Qu’est ce que ça résout comme problème actuellement et quelle