Upload
french-scrum-user-group
View
705
Download
0
Embed Size (px)
Citation preview
Proxy Product Owner
Enrichit ou dénature Scrum
Frédéric Duffau – 27 mars 2012
Merci à nos sponsors Platinum
Et merci à nos sponsors Gold et Silver
Le Product Owner : PO
#0.0 PO, compétences● 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.
#0.1 PO, activités● mettre à jour le backlog de produit, ajuster
les priorités● répondre aux questions sur les user stories● définir les tests d'acceptation● passer ces tests ou s'assurer qu'ils le sont
#0.1 PO, implication● Revue de backlog● Réunion planification de sprint● Revue de sprint
● Disponible pour répondre aux questions venant de l'équipe
Proxy Product Owner : PPO
2 cas d'utilisation
Proxy Product OwnerSoutien de Scrum
P
#1 Proxy PO pour compenser● Le Product Owner n'est pas en place● Progression en 9 étapes de l'organisation
projet● Révélation d'un Product Owner
#1.0 Constat● Equipe Scrum de développement prête● Projet doit démarrer● ScrumMaster prêt mais problème de
backlog produit● PO pas formé et pas disponible
#1.1 Phase 1● le scrum master a élaboré un backlog● le scrum master fait intervenir un autre
scrum master● le SM 1 devient PPO● le projet scrum doit suivre son cours car
l'équipe de développement est prête et disponible
P2
#1.2 Phase 2 ● le PO est présent mais participe seulement
à la priorisation● le PPO fait les taches de grooming● l'équipe scrum ne reconnait que le PPO
P
#1.3 Phase 3 ● le PO ayant pris trop de distance● le PO perd la vision de son produit et ce
qu'il devient● les utilisateurs ne sont pas impliqués par le
PO
#1.4 Retrospective Release ● demo : les utilisateurs remettent en cause
le PO● le PO ne connaît pas son produit● Le PO n'est pas reconnu par l'équipe de
développement● le PPO tient le backlog● PPO / SM devait aussi développer P
#1.5 Retour à Scrum ● formation du PO● disponibilité du PO● présence du PO● objectifs sur la 2eme release partagés
#1.6 Phase 4 ● PO aux cérémonies● PO exprime les Tests d'Acceptance● PO donne les priorités● PPO pour la rédaction des US
P
#1.7 Phase 5 ● PPO redevient ScrumMaster● PO besoin de tracer ses demandes● Besoin d'un outil pour palier l'absence● PO utilise IceScrum pour rédiger US, Bugs
P
2
#1.8 Demo Release ● demo par le PO● equipe scrum présente avec son SM● vision release 2 partagée par PO
#1.9 et après quelques sprints ● Adoption totale de Scrum● Utilité reconnue du planning poker● Utilisation des users points pour
commander les travaux futurs● PO ne voit plus autrement : Révélation
Proxy Product OwnerRenfort de Scrum
P
#2 Proxy PO pour renforcer● Organisation sensibilisée voire formée● Experts métiers et responsables projet
inscrits dans le même objectif de réussite● Impliquer les exploitants et les
responsables qualité● Mettre en place une organisation « scrum
de scrum » référencée comme un standard
#2.0 Constat● PO formé par un coach agile● stakeholders formés par un coach agile● Scrum nouveau dans le référentiel Qualité● 2 produits interconnectés à développer en
parallèle
#2.1 Phase 1● présenter un Plan De Développement
(PDV) incluant Scrum et tous les acteurs● impliquer tous les acteurs principaux● Scrum de Scrum sur le fond● introduction du PPO : PO proche de
l'équipe de développement● stakeholders impliqués sont PO
#2.2 Phase 2● appliquer le PDV● initié le Scrum de 1er niveau● réunion PO / PPO pour faire émerger un
backlog● itérer pour obtenir des backlogs produit
aptes à partir en développement● intégrer les acteurs de l'exploitation
P
#2.3 Phase 3● Scrum de 2nd niveau● début du développement● lancement des features du PROD1● 3 sprints de rodage avec PPO1 et PO1
P1
#2.4 Retrospective Release● alléger le process standard● trouver un formalisme pour les Tests
d'Acceptance● bons résultats : adhésion des utilisateurs● décision lancement PROD2
P2
#2.5 Phase 4● lancement des sprints du PROD2● réunions avec PPO1/PO1 + PPO2/PO2● backlog compliqué et pas forcément bien
priorisé● problème de dépendances des 2 produits
P1
P2
#2.6 Phase 5● après plusieurs sprints, on sépare les 2
produits en 2 équipes● sprints des 2 produits synchronisés mais
réunions indépendantes● synchronisation des backlogs entre
POi/PPOjP2
P1 1s
#2.7 Phase 6● indépendance des 2 produits● favoriser les Tests d'Acceptance propres
au produit● formalisme de Test d'Acceptance en
évaluation● taches de grooming par SM● problème stabilité US dans un sprint selon
le produit
#2.8 Phase 7● 2 physionomies différentes● PPO1 suit le projet mais PO1 joue son rôle● PPO2 joue bien le rôle de product owner,
PO2 peu impliqué
P P
1 2≠
#2.9 et après ...● Finalement le PO et PPO tendent à
disparaître pour laisser place à un PO et un responsable utilisateur
● Apparition d'un Super PO pour coordonner le backlog produit
Questions ?