Les Rôles du Scrum Product Owner

1 303 vues

Publié le

Traduction

Publié dans : Ingénierie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 303
Sur SlideShare
0
Issues des intégrations
0
Intégrations
236
Actions
Partages
0
Téléchargements
27
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Les Rôles du Scrum Product Owner

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×