Traduction

1. Rôle du
Scrum
Product
Owner
Jeff Patton
Agile Product Design
jpatton@acm.org
Traduit par Fabrice Aimetti le 6-Fév-2010

2. © 2006-2007 Jeff Patton, Tous droits réservés, www.agileproductdesign.com 2
Le rôle du product owner est spécifique
au processus agile Scrum
Aussi appelé “modèle du bonhomme de neige”
(le voyez-vous ?)
Traduit par Fabrice Aimetti le 6-Fév-2010

3. © 2006-2007 Jeff Patton, Tous droits réservés, www.agileproductdesign.com 3
Le product owner planifie le produit en
pelures d'oignon
Traduit par Fabrice Aimetti le 6-Fév-2010

4. © 2006-2007 Jeff Patton, Tous droits réservés, www.agileproductdesign.com 4
Le product owner planifie le produit en
pelures d'oignon
Produit
ou Projet
Quels objectifs métiers le
produit va-t-il remplir ?
Charte du Produit
Présentation condensée
Version
Comment pouvons-nous
délivrer de la valeur de
façon incrémentale ?
Quels sous-ensembles
d'objectifs chaque version
va-t-elle permettre
d'atteindre ?
À quelles populations
d'utilisateurs cette version
va-t-elle s'adresser ?
Quelles fonctionnalités
importantes (features) cette
version va-t-elle offrir ?
Planning de Release
Itération
Qu'allons-nous
spécifiquement
construire ? (user stories)
De quelle manière cette
itération va-t-elle nous
amener à tenir les
objectifs de la version ?
Planning d'Itération
Story (Élément du Backlog)
À quel utilisateur ou partie prenante cette
story va-t-elle s'adresser ?
Comment va-t-elle se traduire ?
Comment vais-je déterminer si elle est
terminée ?
Détails de la Story
Tests d'acceptation
Traduit par Fabrice Aimetti le 6-Fév-2010

5. © 2006-2007 Jeff Patton, Tous droits réservés, www.agileproductdesign.com 5
Le Planning en Oignon peut aussi inclure le
portefeuille produit et la stratégie métier
Produit
ou Projet
Quels objectifs métiers le
produit va-t-il remplir ?
Charte du Produit
Présentation condensée
Version
Comment pouvons-nous
délivrer de la valeur de
façon incrémentale ?
Quels sous-ensembles
d'objectifs chaque version
va-t-elle permettre
d'atteindre ?
À quelles populations
d'utilisateurs cette version
va-t-elle s'adresser ?
Quelles fonctionnalités
importantes (features) cette
version va-t-elle offrir ?
Planning de Release
Itération
Qu'allons-nous
spécifiquement
construire ? (user stories)
De quelle manière cette
itération va-t-elle nous
amener à tenir les
objectifs de la version ?
Planning d'Itération
Story (Élément du Backlog)
À quelle utilisateur ou partie prenante cette
story va-t-elle s'adresser ?
Comment va-t-elle se traduire ?
Comment vais-je déterminer si elle est
terminée ?
Détails de la Story
Tests d'acceptation
Produit ou Projet
Version
Itération
Story
Traduit par Fabrice Aimetti le 6-Fév-2010

6. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 6
Le Planning en Oignon peut aussi inclure le
portefeuille produit et la stratégie métier
Produit ou Projet
Version
Itération
Story
© 2006-2007 Jeff Patton, Tous droits réservés, www.agileproductdesign.com 6Traduit par Fabrice Aimetti le 6-Fév-2010

7. © 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com 7
Produit ou Projet
Version
Itération
Story
Le Planning en Oignon peut aussi inclure le
portefeuille produit et la stratégie métier
Portefeuille Produit
Stratégie Métier
© 2006-2007 Jeff Patton, Tous droits réservés, www.agileproductdesign.com 7Traduit par Fabrice Aimetti le 6-Fév-2010

8. © 2006-2007 Jeff Patton, Tous droits réservés, www.agileproductdesign.com 8
Le Product Owner est un :
Expert Métier
 Connaît assez le métier pour avoir une
vision produit
 Répond aux questions techniques posées
sur le métier par ceux qui créent le produit
Avocat de l'utisateur final
 Décrit le produit en ayant une
connaissance des utilisateurs et de son
utilisation, afin de servir les deux
Avocat du client
 Connaît les besoins de l'acheteur du
produit et sait choisir un ensemble de
fonctionnalités présentant une grande
valeur ajoutée pour le client
Avocat du métier
 Connaît les besoins de l'organisation qui
finance l'élaboration du logiciel et sait
choisir un ensemble de fonctionnalités
qui servent leurs objectifs
Communiquant
 Capable de communiquer sa vision et
de différer la spécification d'une
fonctionnalité et les choix de
conception (Juste à temps)
Décideur
 Face à une diversité d'objectifs
contradictoires et d'opinions, il sait
arbitrer et prendre les décisions finales
nécessaires
Le rôle du Product Owner est généralement rempli par
une seule personne appuyée par une équipe
Traduit par Fabrice Aimetti le 6-Fév-2010

9. © 2006-2007 Jeff Patton, Tous droits réservés, www.agileproductdesign.com 9
Responsabilités du Product Owner
Organise le backlog en
versions incrémentales
Spécifie des critères d'acceptation
objectifs pour les stories
Crée et maintient à jour
le backlog produit
Participe quotidiennement
Est disponible pour
répondre aux questions et
clarifier les user stories
Vérifie que les stories sont
terminées sur la base des
critères d'acceptation
Évalue le produit à la
fin du Sprint et ajoute
ou supprime des
stories dans le
backlog si nécessaire
Traduit par Fabrice Aimetti le 6-Fév-2010
•Communique les Objectifs Métiers, des Clients et des Utilisateurs finaux
•Coordonne l'implication des utilisateurs et des parties prenantes
•Se coordonne avec les autres product owners pour garantir la
cohérence du produit et des versions

10. © 2006-2007 Jeff Patton, Tous droits réservés, www.agileproductdesign.com 10
Équipe
ProductOwner
Équipede
Développement
Les fonctionnalités préparées et terminées
passent et repassent entre les couloirs
• implémentation
des fonctionnalités
de l'itération 1
• récupère les infos
pour l'itération 3
• prépare pour
l'itération 2 des
fonctionnalités
• soutien le
développement de
l'itération 1
• implémentation
des fonctionnalités
de l'itération 2
• correction des
bugs de l'itération 1
• récupère les infos
pour l'itération 4
• prépare pour
l'itération 3 des
fonctionnalités
• soutien le dév. de
l'iteration 2
• valide l'itération 1
• implémentation
des fonctionnalités
de l'itération 3
• correction des
bugs de l'itération 2
• récupère les infos
pour l'itération 5
• prépare pour
l'iétartion 4 des
fonctionnalités
• soutien le dév. de
l'itération 3
• valide l'itération 2
• planning
• récupère les infos
• prépare pour
l'itération 1 des
fonctionnalités –
exigences
techniques fortes,
exigences
utilisateurs faibles
• mise en place de
l'environnement
de développement
• études
d'architecture
(spikes)
Sprint 0 Sprint 1 Sprint 2 Sprint 3
Préparation
des
fonctionnalités
Fonctionnalités
codées
temps
Préparation
fonct.
+
bugs
trouvés
lots
des
tests
soutiendév
soutiendév
Traduit par Fabrice Aimetti le 6-Fév-2010