Product Owner
retour d’expériences / XPday 2009
Sébastien Sacard
Consultant Définition de Produit @ Piaolink
sebastien@piaolink.com
Cursus
• Depuis 2007: Piaolink, Consultant définition de produit
- Kivahu.fr, Product Owner
- Drimki.fr, Product Owner
• 2006/2007: Yahoo! Voyages Europe, Product Owner
• 2006: Formation interne Yahoo! de SCRUM Master
• Entre 2002 et 2006: Kelkoo, Chef de projet technique
Product Backlog
Priorité Elément Estimation
Very High Le rôle du Product Owner 5
High Le Product Owner et le Business Owner 10
High Le Product Owner et l’équipe SCRUM 10
Low L’équipe produit 5
Le rôle du
Product Owner
«The Product Owner
prioritizes the Product
Backlog.»
http://www.mountaingoatsoftware.com/product-owner
C’est tout ?
Description détaillée
1/ Typically someone from a Marketing role or a key user
in internal development.
2/ In return for their commitment to completing the
selected tasks, the product owner commits that she will
not throw new requirements at the team during the
sprint.
3/ Requirements are allowed to change but only outside
the sprint. Once the team starts on a sprint it remains
maniacally focused on the goal of that sprint.
http://www.mountaingoatsoftware.com/product-owner
Beaucoup d’interdiction.
Peu de direction....
1/ Profil technique ou marketing ?
Les deux !
• Marketing pour pouvoir s’affranchir des contraintes
techniques
• Technique pour comprendre et anticiper les contraintes
de l’équipe de développement
En pratique : un Product Owner sans background
technique se retrouve vite limité.
2/ Ne pas interférer
• Le Buffer d’urgence (mise en place chez Drimki)
• 20% de la bande passe pour le «hors-sprint»
• A été négocié avec le business pour conserver
la flexibilité (et SCRUM)
• Le SCRUM Master doit pouvoir résister
• Ne pas compter «que» sur le respect de la méthode
• Rapport de force permanent... mais respectueux des
compétences de chacun !
3/ Changer les besoins hors sprint
• Convaincre le business owner d’attendre
Mettre en jeu les objectifs de qualité sur le long terme
• Donner de la visibilité !
Sur les 3 ou 4 sprints suivants / sur le trimestre
• Protéger l’équipe SCRUM
Afin de conserver l’enthousiasme
• Négocier en permanence
Avec le business owner, avec le scrum master
Pourrait-on remplacer le
Product Owner par...
• ... un chef de projet ?
- peut rentrer en conflit avec le SCRUM Master «technique»
- le SCRUM Master risque de devenir un simple «animateur»
• ... un chef de produit ?
- si trop marketing, déconnecté des contraintes de développement.
- en général, rarement au quotidien avec l’équipe
• ... le client ?
- risque de rester fixer sur les objectifs business (court terme)
- manque des compétences spécifiques (planification)
Peut-on se passer de Product
Owner ?
Si pas le budget et si le SCRUM Master est
expérimenté, les fonctions de Product Owner
peuvent être limitées.
• Le rôle du Product Owner peut être limité à l’expression des
besoins (avec un minimum de rigueur)
• Le SCRUM Master gère l’intéraction avec le client et gère le
product backlog
Product Owner
&
Business Owner
Responsabilités
• Education
• Mise en place / Maintenance du Product Backlog
• Etablissement d’une feuille de route
• Estimation et Priorisation
• Reporting
Education
• Beaucoup de clients ne sont pas habitués à être impliqués...
et à partager les succès et les échecs
• Faire comprendre que le Business Owner n’est pas
forcément le client idéal de son propre produit
• Besoin de représentants clients
• Etude de marché + étude de besoins
Maintenir le product backlog
• Document d’interface entre le PO et l’équipe SCRUM
• Différents outils existent :
Tableur + Traitement de texte fonctionnent très bien
• Utiliser les récits utilisateurs, mais ne pas s’arrêter à
l’expression (ne pas oublier les tests de validation).
• Impliquer le Business Owner :
Demander d’exprimer les besoins sous forme de récits, ou
les exprimer à sa place et les faire valider
La feuille de route
• Document d’interface entre le Business Owner et le PO
• La feuille de route est une vision condensée du Product
Backlog: les mises à jour mutuelles sont essentielles
• La feuille de route est l’instrument de visibilité par excellence
pour le Business Owner: un document d’une page contenant
les fonctionnalités clés
• La feuille de route sert à l’équipe SCRUM qui a la visibilité
sur ce qui est communiqué au Business, parfois avec un
vocabulaire différent
Estimation et Priorisation
• Estimation :
• Difficile en amont sans le feed-back technique
• Doit se concentrer sur l’estimation de la complexité
relative par rapport aux autres récits
• Priorisation :
• Accompagner le Business Owner a faire le choix
• Montrer le backlog pour justifier de son entretient
Gestion Product Backlog
• Objectif : Maintenir les priorités à jour
• Bonnes pratiques :
• Organiser tous les 3 sprint une revue globale et assigner les
éléments aux prochains sprints (sur 2 ou 3 mois)
• Gérer «des» backlogs :
• gérer des backlogs par thèmes (grandes fonctionnalités)
• faire gérer un backlog technique par le SCRUM master
• gérer les bugs à part (bug tracking)
Intérêt de différents backlogs
• Permet d’incorporer plus facilement les demandes
quotidiennes et de ne pas se perdre dans un backlog trop
généraliste.
• Permet de gérer les priorités techniques (maintenance,
sécurité) en dehors des fonctionnalités produits
• Permet de créer des sprints pondérés: et négociés:
• sprint n: 70% produit, sprint n+1: 70% technique
Spécification des éléments
• Les spécifications sont faites en amont des sprints
• Besoin des feed-backs des dévelopeurs mais ne pas les
déranger....
• option 1 : Réserver des plages de travails dans le sprint
=> ralenti le sprint en cours
• option 2 : Travailler dans les intevalles
=> nécessite de spécifier le sprint n+2
Sprint Planning
• Objectif : créer le Sprint backlog
• Bonnes pratiques :
• Etre convaincant sur les priorités !
• Ne pas inclure une fonctionnalité qui n’est pas spécifiée
• Ne pas participer a l’estimation des points
• Négocier et valider le Sprint Backlog proposé par l’équipe SCRUM
Sprint Tracking
• Objectif : pouvoir tenir informé le business des avancées
• Bonnes pratiques :
• Tester chaque fonctionnalité «réalisée» durant le sprint
(ne pas attendre la fin du sprint pour tout tester)
• Etre vigilant et accepter de retirer des fonctionnalités
Sprint review
• Objectif : analyser et améliorer
• Bonnes pratiques :
• Ne pas se réfugier derrière les «specs»
• Accepter les critiques
• S’assurer que les commentaires seront pris en compte
dans le prochain sprint !
Release tracking
• Objectif : Avoir une visibilité sur l’avancement de la roadmap
• Bonne pratique :
• Gérer les fonctionnalités par trimestre
• Le premier trimestre est trés précis, les suivants moins
• Travailler sur la roadmap avec le SCRUM master et
idéalement certains développeurs seniors
Bonnes pratiques
• Ne pas avoir de listes de diffusion par mail «produit» et «dev»:
- Coupe l’équipe en deux
- Déresponsabilise («demande au produit»)
• Avoir des listes par sprints : «sprint-n@»
- Permet de travailler sur plusieurs sprints en même temps, tout
en permettant de filtrer ce qui concerne le sprint courant des
sprints suivants
- Permet d’affiner les spécifications en «flux tendu»
Pour conclure
• Donner de la visibilité et de l’autonomie dans les choix
techniques, pas dans les choix fonctionnels (mais écouter)
• Attention au putsch : Une équipe SCRUM peut évincer un
Product Owner si trop d’autonomie (vécu)
• SCRUM n’est pas adapté aux développeurs junior, s’assurer
que l’équipe est homogène et globalement senior
• SCRUM s’inscrit dans la durée : pas adapté pour des projets
«one-shot». Surtout si l’équipe existante n’est pas agile.
L’équipe produit
Profils et fonctions
• Architecte de l’information : le cartographe
• Concepteur Rédacteur : la voix
• Graphiste (DA, designer) : l’artiste
• Ergonome : le responsable de la satisfaction
• Designer d’interaction : le responsable qualité
Les intégrer dans l’équipe
SCRUM ?
+ permet de favoriser l’interaction et l’efficacité
+ permet d’avoir un feed-back rapide durant le sprint
- le travail de spécification n’est pas continu
- qui est le responsable de leur travail : PO ou Scrum Master ?
En pratique : ces métiers ne doivent pas être
intégrés dans l’équipe SCRUM.
Les outils du Product Owner
• Présentations haut-niveau (Powerpoint)
• Persona
• Récits utilisateurs (User Stories)
• Architecture de l’information
• Wireframes
• Prototypes dynamiques
0 comments
Post a comment