Rôle du Scrum Product Owner Jeff PattonAgile Product [email protected]
Traduit par Fabrice Aimetti le 6-Fév-2010
© 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
© 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
© 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
VersionComment 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 ReleaseItérationQu'allons-nous
spécifiquementconstruire ? (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
© 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
VersionComment 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 ReleaseItérationQu'allons-nous
spécifiquementconstruire ? (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
© 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
© 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
© 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
© 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
© 2006-2007 Jeff Patton, Tous droits réservés, www.agileproductdesign.com 10
Équi
pePr
oduc
t O
wne
rÉq
uipe
de
Dév
elop
pem
ent
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
Fonc
tionn
alités
codé
es
temps
Préparation fonct.
+ bugs trouvés lots des tests
soutien dé v
soutien dé v
Traduit par Fabrice Aimetti le 6-Fév-2010