Xp Days 2009

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Favorites, Groups & Events

    Xp Days 2009 - Presentation Transcript

    1. Product Owner retour d’expériences / XPday 2009 Sébastien Sacard Consultant Définition de Produit @ Piaolink sebastien@piaolink.com
    2. 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
    3. 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
    4. Le rôle du Product Owner
    5. «The Product Owner prioritizes the Product Backlog.» http://www.mountaingoatsoftware.com/product-owner
    6. C’est tout ?
    7. 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
    8. Beaucoup d’interdiction. Peu de direction....
    9. 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é.
    10. 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 !
    11. 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
    12. 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)
    13. 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
    14. Product Owner & Business Owner
    15. Responsabilités • Education • Mise en place / Maintenance du Product Backlog • Etablissement d’une feuille de route • Estimation et Priorisation • Reporting
    16. 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
    17. 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
    18. 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
    19. 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
    20. Product Owner & Equipe SCRUM
    21. Responsabilités du Product Owner • Gestion Product Backlog • Sprint planning meeting • Sprint tracking • Sprint review • Release tracking
    22. 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)
    23. 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
    24. 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
    25. 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
    26. 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
    27. 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 !
    28. 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
    29. 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»
    30. 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.
    31. L’équipe produit
    32. 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é
    33. 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.
    34. Les outils du Product Owner • Présentations haut-niveau (Powerpoint) • Persona • Récits utilisateurs (User Stories) • Architecture de l’information • Wireframes • Prototypes dynamiques
    SlideShare Zeitgeist 2009

    + Seb20Seb20 Nominate

    custom

    127 views, 0 favs, 0 embeds more stats

    Présentation sur les retours d\'expérience en tan more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 127
      • 127 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 0
    • Downloads 0
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories