Upload
sebastien-sacard
View
272
Download
2
Embed Size (px)
DESCRIPTION
Présentation réalisée aux XPDays de Paris en 2009, sur mes expériences de Product Owner dans 2 startups.
Citation preview
Product Owner retour d’expériences / XPday 2009
!Sébastien Sacard
Consultant Définition de Produit
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
LowL’é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 conserverla 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
Product Owner &
Equipe SCRUM
Responsabilités du Product Owner
• Gestion Product Backlog
• Sprint planning meeting
• Sprint tracking
• Sprint review
• Release tracking
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