Scrum Product Owner théorie 426

Le Product Owner

Dans Scrum, le rôle de Product Owner existe pour faire en sorte que le travail réalisé apporte de la valeur aux utilisateurs. Il permet également d’éviter que le choix du contenu du produit subisse la prédominance de :

• La technique : En mettant l’accent sur les fonctions utiles.
• La direction : Fournir le choix des fonctionnalités.

Le rôle de Product Owner, tenu par une personne de l’équipe, porte la responsabilité du résultat du produit auprès des parties prenantes.

Il convient de considérer le mot produit dans une acceptation large, comme le résultat de ce qui est fait par l’équipe.

Responsabilités du Product Owner

Un Product Owner agit à la fois sur la stratégie et sur la tactique.

• Il prend les décisions au niveau stratégique, le choix du livrable et de la date.
• Il prend les décisions au niveau tactique (définir un emplacement ou un libellé sur une page web, par exemple).

Bien que le rôle de Product Owner varie beaucoup selon le contexte de l’organisation, il est possible d’identifier ses responsabilités majeures :

• Prioritiser : Vous décidez de l’ordre dans lequel les stories seront réalisées.
• Affiner le backlog : Préparer les tâches pour les sprints à venir.
• Planifier une fourniture de valeur : Communiquer aux parties prenantes les prévisions du travail de l’équipe.
• S’assurer de la compréhension de l’équipe : S’assurer que l’équipe comprend bien les éléments sur lesquels elle travaille.

En résumé, s’il n’a pas d’autorité formelle sur des personnes, le Product Owner a une grande influence sur le résultat du travail de l’équipe.

Compétences souhaitées

Dans l’idéal, la personne qui joue ce rôle devrait posséder des compétences variées :

• une bonne vision du produit (pourquoi créer le produit ? quels sont les objectifs de la prochaine version ? quels sont les impacts attendus ? la liste des fonctionnalités essentielles).
• une bonne connaissance du métier (domaine en relation avec les utilisateurs du produit). Quand c’est nécessaire, il s’appuiera sur les bonnes personnes.

• l’autorité pour prendre des décisions rapidement (choisir entre plusieurs alternatives sur des sujets d’importances variée).

• Décider c’est choisir; c’est aussi dire non à des demandes des parties prenantes.

• Le rôle de Product Owner est incarné par une seule personne, pas par un comité.

• Capacité à détailler au bon moment (le Product Owner affine au bon moment le contenu du backlog).

• Esprit ouvert au changement (le Product Owner sollicite les retours qui remontent suite aux livraisons régulières des versions du produit aux parties prenantes).
• Aptitude à la négociation (le Product Owner négocie souvent avec l’équipe; il prend le temps de consulter puis d’expliquer la position choisie).
• Maîtrise des techniques de définition du produit (Scrum ne prescrit pas de technique particulière pour identifier les éléments du backlog, cependant on constate sur le terrain que la pratique la plus fréquemment associée à Scrum est la “story”, qu’un Product Owner se doit de bien connaître).

Une journée typique de Product Owner (PO)

1. Collaborer avec l’équipe

   le PO n’est pas simplement le représentant des clients et des utilisateurs dans l’équipe. Il est membre de l’équipe et à ce titre, il participe activement aux travaux pendant un sprint.
   En collaborant avec l’équipe, le PO apprend à écouter ce qu’ont à dire les développeurs et comprend mieux leurs préoccupations de délai et de qualité. Ainsi, il sera moins enclin à les pousser à livrer toujours plus de fonctionnalités, ce qui leur impose une pression négative.

2. S’impliquer dans l’acceptation du fini

   le PO fournit les conditions qui permettront de s’assurer que ce qu’il demande est bien terminé. (Test)
   Lors des séances d’affinage, le PO a formulé à l’équipe le comportement qu’il attend d’une fonctionnalité. Ensemble, ils ont identifié une condition d’acceptation. C’est en vérifiant la condition que le PO s’assure de la bonne fin de la fonctionnalité.

3. Utiliser le produit

   Cela permet au PO de discerner la valeur ajoutée par les fonctions dans le backlog. Bien connaître son produit lui donnera une position respectée par tous et facilitera ses prises de décision.
   C’est aussi dans sa mission de faire des démonstrations à l’extérieur et de présenter le produit aux utilisateurs. Le PO en profite pour tester les hypothèses sur les nouveautés qu’il envisage d’inclure dans le produit.

4. Impliquer les parties prenantes

   Le PO est responsable du résultat auprès des parties prenantes : pour bien exercer son rôle, il doit communiquer avec elles.

Structurer le backlog

Après avoir décidé de lancer le développement d’un produit, la difficulté fondamentale est de transformer la vision de départ en quelque chose d’exploitable par l’équipe de développement.

Avec Scrum, le travail à faire émerge progressivement par le biais d’une collaboration continue entre les membres de l’équipe et le Product Owner, et grâce aux feedbacks réguliers donnés par les parties prenantes.

• Le backlog va permettre de collecter le travail.

Le backlog est simplement la liste des choses à faire par l’équipe, avec quelques caractéristiques remarquables (PROUVE).

• Le backlog est public → Bien pour communiquer + feedback.
• Le backlog est de taille réduite → Visibilité.
• Il utilisera ces critères pour définir l’ordre pour la réalisation.
• Le backlog est unique.
• Le backlog est vivant (ajout de fonctionnalités).
• Le backlog permet l’émergence de nouveaux éléments. → On ne connait pas à l’avance le contenu définitif du backlog.

Structure du backlog

Pour améliorer la visibilité du backlog, il est possible de lui appliquer le pattern structurel fourniture / travail. Il devient dès lors un container à deux listes portant sur des éléments de visées différente : La fonctionnalité et la story.

• Le backlog de fourniture qui est la partie utilisée pour communiquer avec la partie prenante et contenant les gros morceaux appelés fonctionnalités.

• La fonctionnalité

  Un service ou une fonction dont l’énoncé est claire pour les parties prenantes.

Une fonctionnalité est prête quand (on peut débuter son affinage) :

• L’hypothèse de son impact sur les utilisateurs est validée.
• L’effort pour procurer cet impact est minimisé.

Elle est finie quand elle procure de la valeur.

La représentation de ce backlog de fourniture contenant les fonctionnalité se fait généralement par un tableau montrant les différents états avec des colonnes. Ce type de tableau est souvent appelé un kanban (il s’agit d’une technique de la méthode Kanban).

• Le backlog de travail qui est la partie contenant les petits morceaux appelés stories, sur lesquels l’équipe travaille.

• Une user story

  Voir support de cours.

En 2001, Ron Jeffries définissait la vie de la story avec trois phases : la carte comme moyen de l’identifier, puis une conversation et enfin une confirmation (les 3 C). Avec Scrum, l’équipe déroule deux fois conversation et confirmation. D’abord pour obtenir une story prête, ensuite pour continuer afin qu’elle soit finie.
1. Un jour quelqu’un a une idée et la note sur une carte.
2. Le Product Owner et l’équipe l’affinent au cours de conversations, afin qu’elle devienne une story pouvant être réalisée en un sprint.
3. L’équipe apporte sa confirmation qu’elle est prête.
4. L’équipe réalise la story pendant un sprint, en tenant de nouvelles conversations avec le Product Owner, pendant sa réalisation.
5. Le Product Owner apporte sa confirmation qu’elle est finie.

Pour éviter d’avoir un gros tas de stories en affinage, on peut utiliser le pattern des bacs qui consiste à ranger les stories dans les dépôts correspondant à leur état.
* Le bac à sable pour les idées :
* Le bac d’affinage est l’endroit où l’équipe affine les stories avant de les réaliser dans un sprint.

Ce bac a une allure typique d’entonnoir :

• Le bac de départ pour les stories prêtes → Stories qui sont réalisables dans un sprint.

• Le bac d’arrivée est l’endroit où l’on dépose les stories finies.

• Bénéfices du pattern des bacs : en l’appliquant, l’équipe (notamment PO) dispose d’une représentation qui lui permet d’y voir clair, chaque partie ayant un objectif différent.