Le Product Owner dans le framework Scrum
Le Product Owner dans le framework Scrum
Le Product Owner est un rôle clé dans la mise en place de Scrum :
– Personne de l’équipe Scrum ayant délégation des parties prenantes pour maximiser la valeur, et imputable du résultat auprès d’elles.
– Le Product Owner est la seule personne responsable de la gestion du Product Backlog.
– Il porte la vision du produit à réaliser.
– Il est le gardien du Product Backlog
Description du rôle de Product Owner :
Le propriétaire de produit est l’unique responsable de gérer le carnet du produit et de s’assurer de la valeur du travail de l’équipe :
– Cette personne maintient le carnet du produit et s’assure qu’il soit bien visible à tous.
– Comme tout le monde sait quels sont les éléments ayant la plus haute priorité, tous savent ce sur quoi l’équipe devra travailler.
Le propriétaire du produit est une seule et unique personne, et non pas un comité.
Le Product Owner est responsable de maximiser la valeur du travail accompli par l’équipe de développement :
– Comment cela est réalisé peut varier considérablement selon les organisations, les Scrum Teams, et les individus.
– Il travaille en interaction avec l’équipe de développement.
Pour qu’un propriétaire du produit réussisse, tous les membres de l’organisation devront respecter ses décisions :
– Les décisions prises par le propriétaire du produit sont représentées dans la sélection et la priorisation des éléments du carnet du produit.
– C’est cette visibilité accrue qui rend la tâche du propriétaire de produit à la fois exigeante, mais aussi très satisfaisante.
Le Product Owner est généralement d’un expert du domaine métier du projet.
Les compétences souhaitées du product Owner :
– bonne connaissance du domaine métier,
– maîtrise des techniques de définition de produit,
– capacité à avoir une position respectée et à prendre des décisions,
– capacité à détailler une fonctionnalité au bon moment
– esprit ouvert au changement,
– bon négociateur.
Le Product Owner et le Product Backlog
Un bon Product Owner doit bichonner son Product Backlog pour qu’il soit prêt pour le sprint qui va commencer :
– Communiquer avec les utilisateurs
– Travailler avec l’équipe sur le sprint courant
– Anticiper sur les sprints suivants
Suggestions :
Le propriétaire de produit peut aussi être un membre de l’équipe, faisant lui aussi du développement logiciel .
Cette responsabilité supplémentaire peut toutefois affecter ses capacités à bien communiquer avec les autres parties prenantes.
En aucun cas le propriétaire de produit ne peut être ScrumMaster.
Dans le cadre d’un développement commercial, le propriétaire du produit peut être le gestionnaire de produit.
Dans le cadre d’un développement maison, le propriétaire du produit pourrait être le gestionnaire de la fonction
d’affaires qui doit être automatisée.
Quizz
– Question 1
Un sponsor important du projet tient beaucoup à une fonction mais ne sait pas bien de quelle façon elle pourrait être proposée aux futurs utilisateurs du produit. Vous êtes Product Owner, que faire ?
1- Lui demander d’écrire la spécification
2- Définir une story simple sans IHM définitive et la mettre prioritaire
3- Mettre sa demande à la fin du backlog
4- Attendre qu’il dise clairement ce qu’il veut
– Réponse : 2
– Explications
La réponse 1 a été choisie par 10% des participants au QCM, la 2 par 51,5%, la 3 par 12,5% et la 4 par 26%.
Pourquoi la réponse 2 est-elle la bonne ? Procédons par élimination :
– Lui demander d’écrire la spécification
Si le sponsor ne sait pas bien comment une fonction peut être proposée, on peut penser qu’il sera encore moins capable d’écrire une spécification. Déjà quand un client sait à peu près ce qu’il veut, il ne sait pas pour autant l’écrire, alors ce n’est pas probablement pas une bonne idée de pousser ce sponsor à rédiger un document.
– Mettre sa demande à la fin du backlog
Mettre à la fin du backlog, c’est dire « on verra plus tard ». Ce plus tard, n’est pas connu, ça peut être beaucoup plus tard. Voire jamais si la story reste toujours à la fin. Comme c’est un sponsor important, on peut supposer que ce qu’il propose est important aussi et apporte de la valeur.
– Attendre qu’il dise clairement ce qu’il veut
Cela paraît plus facile que de lui demander d’écrire la spécification. Cependant l’énoncé laisse entendre que c’est dans la mise en œuvre de la fonction que le sponsor ne sait pas dire avec précision. Il n’est pas en mesure de définir l’interface homme machine, par exemple. Il ne saura pas le dire clairement, même en insistant. Il vaut mieux lui montrer quelque chose et le faire réagir.
– Définir une story simple sans IHM définitive et la mettre prioritaire
C’est pourquoi la réponse 2 est la plus adaptée. Elle permet de réduire le risque constitué par l’incertitude sur cette fonction.
– Remarque
Le Product Owner doit effectivement appliquer la solution 2. Mais en parallèle doit aller à la chasse aux besoins et propositions. Il pourrait en discuter avec le sponsor, avec les utilisateurs, l’équipe, etc afin de revenir avec une proposition d’implémentation et compléter la story.
– Extrait du Guide Scrum
La réduction de l’incertitude sur des besoins des utilisateurs est un critère de priorité. Quand un utilisateur désire une fonctionnalité mais ne sait pas de quelle façon le service doit être rendu, la solution est de lui montrer rapidement une version simple, pour obtenir son feedback. La connaissance apportée par le développement des stories relatives à cette fonctionnalité est une occasion d’améliorer le produit.
Leave a Reply
You must be logged in to post a comment.