En raison d’une maintenance technique, la boutique Editions ENI sera inaccessible ce mercredi soir à compter de 21h, jusqu’à 2h jeudi matin. Nous vous invitons à passer votre commande avant 20h30. Merci pour votre compréhension. L’équipe des Editions ENI
  1. Livres et vidéos
  2. Le Product Owner - Maîtriser son rôle et ses missions

Le Product Owner Maîtriser son rôle et ses missions

  • En stock
  • Expédié en 24h00
  • Livraison à partir de 0,01 €
  • Version en ligne offerte pendant 1 an
  • 1 h d'accès gratuit à tous nos livres et vidéos pour chaque commande
  • Accessible immédiatement
  • Version HTML
  • Accès illimité 24h/24, 7J/7
  • Accès illimité 24h/24, 7J/7
  • Tous les livres en ligne, les vidéos et les cours enregistrés ENI
  • Plus de 10 nouveautés livres et vidéos chaque mois
  • Les nouveautés disponibles le jour de leur sortie
  • Accès 100% en ligne

Présentation

Dans une organisation agile, quel est le rôle exact du Product Owner ? Est-ce un chef de projet 2.0 ? Avec ce livre, l’auteur propose au lecteur de répondre à ces interrogations en décrivant ce métier de manière pragmatique. Il intéressera aussi bien les personnes souhaitant passer à l’agilité et devenir Product Owner que les Product Owners ou managers désireux de gérer plus efficacement le développement de leurs produits.

Au fil des chapitres, le lecteur découvre ainsi comment ce véritable chef d'orchestre peut élaborer une vision du produit ainsi qu’une méthode permettant de définir une stratégie et un plan opérationnel faisant sens et nourrissant la motivation de tous les acteurs d’une équipe agile.

La gestion du Backlog de produit est détaillée pour permettre d'en saisir les enjeux afin de s'adapter à un environnement évolutif tout en communiquant mieux grâce à des outils et des méthodes modernes.

Enfin, un chapitre entier est dédié aux principales méthodes permettant au Product Owner de coordonner les efforts d'une ou plusieurs équipes. Scrum à l’échelle ou SAFe, les enjeux et implications de ces approches sont également décrits précisément afin d’être en mesure d’évoluer sereinement en tant que Product Owner dans différents types d’organisations.

Table des matières

  • Le patron Scrum
    • 1. Les fondamentaux de Scrum
      • 1.1 Introduction
        • 1.1.1 Définition de Scrum
        • 1.1.2 Théorie de Scrum
      • 1.2 Les rôles Scrum
        • 1.2.1 Le Product Owner
        • 1.2.2 Le Scrum Master
        • 1.2.3 L'équipe de développement
        • 1.2.4 Les parties prenantes
        • 1.2.5 Un mot sur les managers
      • 1.3 Les évènements Scrum
        • 1.3.1 Le Sprint
        • 1.3.2 La planification de Sprint
        • 1.3.3 Le but du Sprint
        • 1.3.4 L'annulation du Sprint
        • 1.3.5 La réunion quotidienne ou mêlée
        • 1.3.6 La revue de Sprint
        • 1.3.7 La rétrospective de Sprint
        • 1.3.8 L'affinage du Backlog de produit
      • 1.4 Les artefacts Scrum
        • 1.4.1 Le Backlog de produit
        • 1.4.2 Transparence du Backlog de produit
        • 1.4.3 Le Backlog de Sprint
        • 1.4.4 Transparence du Backlog de Sprint
        • 1.4.5 L'incrément
        • 1.4.6 La définition de « Fini »
      • 1.5 Les piliers de Scrum
        • 1.5.1 Transparence
        • 1.5.2 Inspection
        • 1.5.3 Adaptation
      • 1.6 Les valeurs de Scrum
        • 1.6.1 Focus
        • 1.6.2 Ouverture
        • 1.6.3 Respect
        • 1.6.4 Courage
        • 1.6.5 Engagement
    • 2. Du projet au produit
      • 2.1 Focus sur le produit
      • 2.2 Le cycle itératif
      • 2.3 Fin du diagramme de Gantt
  • Le métier de Product Owner
    • 1. Focus sur le rôle de Product Owner
      • 1.1 Le Product Owner n'est pas un chef de projet
        • 1.1.1 La responsabilité du Product Owner
        • 1.1.2 De la vision projet à la vision produit
        • 1.1.3 Les outils du Product Owner
      • 1.2 Le Product Owner est un intrapreneur
        • 1.2.1 Le pouvoir du Product Owner
        • 1.2.2 Les limites du Product Owner
      • 1.3 Un manager atypique
        • 1.3.1 La clarté des objectifs
        • 1.3.2 L'ambiance au sein de l'équipe
        • 1.3.3 La communication avec l'équipe
    • 2. Focus sur le Backlog de produit
      • 2.1 Définition du terme backlog
        • 2.1.1 Étymologie
        • 2.1.2 Du point de vue de Scrum
      • 2.2 Une triple fonction
        • 2.2.1 Un outil de planification
        • 2.2.2 Un outil d'organisation
        • 2.2.3 Un outil de communication
      • 2.3 Le Backlog, un répertoire unique
        • 2.3.1 Le Backlog de produit est vivant
        • 2.3.2 La durée de vie d'un Backlog de produit
        • 2.3.3 Propriété du Backlog de produit
        • 2.3.4 Pas de multiples Backlogs
      • 2.4 Un ordonnancement plus qu'une priorisation
        • 2.4.1 Organiser en fonction de la valeur
        • 2.4.2 Organiser dans le temps
        • 2.4.3 Affiner à mesure
    • 3. Les éléments du Backlog de produit
      • 3.1 Les attributs des éléments
        • 3.1.1 Les attributs essentiels
        • 3.1.2 Les attributs récurrents
        • 3.1.3 Utiliser d'autres attributs
      • 3.2 Focus sur les attributs essentiels
        • 3.2.1 Indicateur numérique
        • 3.2.2 Une description
        • 3.2.3 Une estimation
        • 3.2.4 Une valeur
        • 3.2.5 Un état
        • 3.2.6 Affecter d'autres attributs
      • 3.3 Créer des catégories
      • 3.4 Maintenir une traçabilité
      • 3.5 Lien fort ou lien faible
    • 4. Focus sur la définition de « Fini »
      • 4.1 Définition du guide Scrum
        • 4.1.1 La définition de « Fini » est rédigée par l'équipe de développement
        • 4.1.2 Elle s'applique au produit et à ses composants
      • 4.2 Les vertus d'une définition de « Fini » claire
        • 4.2.1 Les contraintes liées au produit
        • 4.2.2 La définition de « Fini » impacte la capacité à délivrer
        • 4.2.3 La définition de « Fini » clarifie le cadrage du produit
        • 4.2.4 La définition de « Fini » évolue
        • 4.2.5 Les évolutions de la définition de « Fini » se planifient
      • 4.3 L'impact de la définition de « Fini » de la qualité logicielle
        • 4.3.1 La qualité logicielle, un enjeu historique
        • 4.3.2 L'impact d'une définition de « Fini » incomplète est d'ordre financier
        • 4.3.3 L'agilité n'a pas permis de réduire significativement les coûts
      • 4.4 L'implication du Product Owner dans la définition de « Fini »
        • 4.4.1 Des critères d'acceptation à la définition de « Fini »
      • 4.5 Convaincre les parties prenantes d'adopter une définition de « Fini » ambitieuse
        • 4.5.1 Utiliser la rétrospective de Sprint
        • 4.5.2 Utiliser la revue de Sprint
    • 5. Focus sur la transparence
      • 5.1 Définition
      • 5.2 Les vertus de la transparence
      • 5.3 L'effet de la transparence sur l'inspection et l'adaptation
        • 5.3.1 Un exemple concret
        • 5.3.2 Une controverse est une source d'inspection
      • 5.4 Les effets d'une transparence complète ou incomplète
  • De la vision stratégique au plan opérationnel
    • 1. La vision produit
      • 1.1 La vision produit est la cible
      • 1.2 Les trois principales typologies de produits
        • 1.2.1 Un nouveau produit
        • 1.2.2 Une évolution de produit
        • 1.2.3 Une mise en conformité
      • 1.3 Exemples de vision produit
        • 1.3.1 Assurancetourix sous la contrainte RGPD
        • 1.3.2 Roméo et ses masques
        • 1.3.3 Siri
      • 1.4 L'anticipation
        • 1.4.1 L'anticipation rationnelle
        • 1.4.2 L'anticipation émotionnelle
        • 1.4.3 La nature de l'anticipation définit la communication
      • 1.5 La vision est la rencontre du produit et du marché
      • 1.6 Co-construire la vision produit
    • 2. La valeur du produit
      • 2.1 Identifier les attributs de valeur
        • 2.1.1 Le délai
        • 2.1.2 La qualité
        • 2.1.3 La fréquence
        • 2.1.4 La récurrence
        • 2.1.5 D'autres indicateurs
      • 2.2 Identifier les objectifs et les contraintes
        • 2.2.1 Qualifier les objectifs SMART
        • 2.2.2 Exemple de référentiel d'exigences
    • 3. Construire un référentiel d'exigences
      • 3.1 La méthode descendante
        • 3.1.1 Identifier les objectifs de base
        • 3.1.2 Identifier les moyens
        • 3.1.3 Identifier les exigences
      • 3.2 La méthode montante
      • 3.3 Structurer le référentiel d'exigences
        • 3.3.1 Prioriser les objectifs
        • 3.3.2 Compter les liens des exigences
        • 3.3.3 Organiser le référentiel d'exigences
    • 4. Établir une stratégie produit
      • 4.1 Les spécificités d'une stratégie produit dans un cycle itératif et incrémental
      • 4.2 Exemple de stratégie produit
      • 4.3 Utiliser les objectifs pour raconter l'histoire du produit
      • 4.4 La stratégie s'inscrit dans le temps
        • 4.4.1 Stratégie basée sur un cycle itératif et incrémental
        • 4.4.2 La stratégie itérative implique de découper le produit
        • 4.4.3 Ordonnancement basé sur la valeur
        • 4.4.4 Ordonnancement basé sur les risques
      • 4.5 La stratégie produit suppose des moyens
      • 4.6 Les besoins des utilisateurs du produit
      • 4.7 Maintenir le référentiel d'exigences
        • 4.7.1 Qualifier les exigences
        • 4.7.2 Initialiser le Backlog de produit
      • 4.8 Valider sa stratégie
        • 4.8.1 Vérifier les objectifs
        • 4.8.2 Vérifier la cohérence des exigences
        • 4.8.3 Ordonnancer les objectifs
      • 4.9 Concrètement
    • 5. Un plan opérationnel
      • 5.1 Une vision à long terme
      • 5.2 La planification de release
        • 5.2.1 La contrainte de délai
        • 5.2.2 La contrainte de coût
        • 5.2.3 L'objectif d'efficience
        • 5.2.4 L'intranet de Marie
        • 5.2.5 Partager avec les parties prenantes
        • 5.2.6 Partager avec l'équipe
      • 5.3 Une vision à court terme
        • 5.3.1 Rester focalisé sur les objectifs
        • 5.3.2 Le plan de Marie vu par l'équipe
        • 5.3.3 Déléguer à l'équipe de développement
      • 5.4 Planification agile
        • 5.4.1 Planifier en fonction du produit
        • 5.4.2 Inspecter et adapter
    • 6. Rédiger des critères d'acceptation
      • 6.1 Rappel des rôles
      • 6.2 Les critères d'acceptation basés sur les contraintes
        • 6.2.1 Les contraintes métier
        • 6.2.2 Les contraintes légales
        • 6.2.3 Les contraintes techniques
        • 6.2.4 Les contraintes fonctionnelles
      • 6.3 Les critères d'acceptation basés sur l'usage
        • 6.3.1 La syntaxe Gherkin
        • 6.3.2 Cucumber
      • 6.4 Le volume des critères d'acceptation
    • 7. Affiner sa vision par rapport à la valeur du produit
      • 7.1 Les gains du produit
        • 7.1.1 À court terme
        • 7.1.2 À long terme
      • 7.2 Les coûts du produit
        • 7.2.1 Les coûts de réalisation
        • 7.2.2 Les coûts de maintenance
      • 7.3 Identifier les bénéfices par thématique
        • 7.3.1 Bénéfices directs ou financiers
        • 7.3.2 Bénéfices de support, d'image ou de confort
        • 7.3.3 L'exemple de Marie
  • Gérer le Backlog de produit
    • 1. Organiser le Backlog de produit
      • 1.1 Organiser en fonction de la valeur
        • 1.1.1 La valeur liée aux gains
        • 1.1.2 La valeur liée aux coûts
        • 1.1.3 La valeur liée aux délais
        • 1.1.4 La valeur liée à des objectifs ou contraintes secondaires
        • 1.1.5 La valeur de quel point de vue ?
      • 1.2 Organiser en fonction de la complexité
        • 1.2.1 La complexité de mise en œuvre
        • 1.2.2 La complexité d'exploitation
      • 1.3 Organiser en fonction de la prise de risque
      • 1.4 Organiser selon d'autres critères
      • 1.5 L'organisation du Backlog de Marie
    • 2. Affiner le Backlog de produit
      • 2.1 Rappel du principe itératif
      • 2.2 Définition de l'affinage
        • 2.2.1 Par où commencer l'affinage ?
        • 2.2.2 Qui participe à l'affinage du Backlog de produit ?
        • 2.2.3 Quand faut-il affiner le Backlog de produit ?
        • 2.2.4 Jusqu'à quel niveau affiner ?
      • 2.3 La règle des 10 %
      • 2.4 Découper les éléments
      • 2.5 Découpage vertical ou horizontal
      • 2.6 Affiner les descriptions
      • 2.7 Affiner les autres attributs
        • 2.7.1 La valeur
        • 2.7.2 La complexité
        • 2.7.3 Le risque
      • 2.8 Affinage et transparence
        • 2.8.1 La règle des trois C
        • 2.8.2 L'importance d'être compris
        • 2.8.3 L'importance de la communication
        • 2.8.4 L'importance du format carte
        • 2.8.5 Rendre le Backlog de produit lisible et visible
      • 2.9 Affiner l'ordonnancement du Backlog de produit
    • 3. Faire face aux changements
      • 3.1 Gérer les nouvelles demandes
        • 3.1.1 Être proactif
        • 3.1.2 Rappeler la planification agile
        • 3.1.3 Vérifier les objectifs et les contraintes
        • 3.1.4 Rechercher le sens
        • 3.1.5 Un modèle opérationnel
        • 3.1.6 Savoir dire non
        • 3.1.7 Oser dire non
        • 3.1.8 Exprimer son désaccord et donner son point de vue avec assertivité
        • 3.1.9 Rester constructif
      • 3.2 Nettoyer le Backlog de produit
        • 3.2.1 Mesurer les objectifs
        • 3.2.2 Les objectifs atteints
        • 3.2.3 Les objectifs inaccessibles
        • 3.2.4 Les objectifs changent
        • 3.2.5 Passer en revue les contraintes
        • 3.2.6 Faire le point sur les moyens
  • Communiquer plus efficacement
    • 1. Introduction
    • 2. Les bénéfices du management visuel
      • 2.1 Accéder plus facilement à une information complexe
      • 2.2 Réduire le délai de prise de décision
      • 2.3 Maintenir plus facilement un référentiel complexe
    • 3. Les outils de management visuel
      • 3.1 La planification de produit
      • 3.2 Le Backlog de produit
      • 3.3 Le Backlog de Sprint
        • 3.3.1 Comprendre le Backlog de Sprint
        • 3.3.2 Savoir déceler les signaux d'alerte
      • 3.4 Les comptes rendus de l'équipe de développement
      • 3.5 Les Burndowns de release ou de produit
      • 3.6 Le référentiel d'exigences
      • 3.7 Les solutions informatiques
    • 4. Communiquer efficacement
      • 4.1 L'information visuelle
      • 4.2 S'appuyer sur des faits ou des indicateurs
      • 4.3 L'oral et l'écrit
        • 4.3.1 Les cas favorables à l'oral
        • 4.3.2 Les cas favorables à l'écrit
      • 4.4 S'appuyer efficacement sur le Scrum Master
        • 4.4.1 Le Scrum Master supprime les obstacles entravant la progression de l'équipe de développement
        • 4.4.2 Le Scrum Master au service du Product Owner
      • 4.5 Faire participer des membres de l'équipe de développement
      • 4.6 Faire participer des parties prenantes
  • Maximiser la valeur
    • 1. Délivrer le produit
      • 1.1 Le plus tôt possible
      • 1.2 Livrer fréquemment
        • 1.2.1 Le produit de Marie
        • 1.2.2 À quelle fréquence ?
      • 1.3 Scrum et DevOps
      • 1.4 Délivrer le produit de plusieurs équipes
    • 2. Inspecter régulièrement
      • 2.1 Inspection du Backlog de produit
        • 2.1.1 L'intranet de Marie
        • 2.1.2 La qualité des éléments du Backlog de produit
        • 2.1.3 Les retours des utilisateurs
      • 2.2 Inspection des processus de l'équipe Scrum
        • 2.2.1 Marie et ses User Stories
        • 2.2.2 La rétrospective de Sprint
        • 2.2.3 Inspecter en dehors de la rétrospective de Sprint
    • 3. Adapter les processus
      • 3.1 Pour accroître la valeur
        • 3.1.1 Marie face au RGPD
      • 3.2 Pour accroître la transparence
      • 3.3 Pour améliorer l'efficience du travail collaboratif
        • 3.3.1 Marie change la date de début des Sprints
    • 4. Améliorer la transparence
      • 4.1 La revue de Sprint
      • 4.2 La compréhension des éléments du Backlog de produit
        • 4.2.1 Par les parties prenantes
        • 4.2.2 Par l'équipe de développement
    • 5. Piloter le budget
      • 5.1 Mesurer le coût total
        • 5.1.1 Le TCO
        • 5.1.2 La dette technique
        • 5.1.3 La dette opérationnelle
      • 5.2 La vélocité comme mesure de ROI
      • 5.3 L'usage est la mesure ultime
        • 5.3.1 Marie stoppe le développement du produit
    • 6. Piloter les délais
      • 6.1 Financer un Sprint supplémentaire
        • 6.1.1 Marie prolonge le développement du produit
      • 6.2 Réorganiser la planification
        • 6.2.1 Le plan de release
        • 6.2.2 Réorganiser le Backlog de produit
  • Scrum à l'échelle
    • 1. Scrum et SAFe
      • 1.1 SAFe
      • 1.2 Scrum à l'échelle selon Scrum.org
    • 2. Organisation des équipes multiples
      • 2.1 Organisation horizontale : la Component Team
      • 2.2 Organisation verticale : la Feature Team
    • 3. Scrum avec deux ou trois équipes
      • 3.1 La notion d'ambassadeur
      • 3.2 La planification de Sprint
        • 3.2.1 Le "Why"
        • 3.2.2 Le "What"
        • 3.2.3 Le "How"
      • 3.3 La mêlée quotidienne
      • 3.4 La revue de Sprint
      • 3.5 La rétrospective de Sprint
    • 4. Scrum à plus grande échelle
      • 4.1 Les problèmes de dépendance
        • 4.1.1 Dépendances et ordonnancement du Backlog de produit
        • 4.1.2 Le poids de la dette technique
        • 4.1.3 Marie soigne ses dépendances
      • 4.2 Nexus
        • 4.2.1 Nexus et SAFe
        • 4.2.2 L'affinage du Backlog de produit avec Nexus
        • 4.2.3 L’équipe d’Intégration Nexus
        • 4.2.4 La planification de Sprint Nexus
        • 4.2.5 Les autres évènements Nexus
        • 4.2.6 La limite de temps des évènements Nexus
    • 5. Organisation du Backlog de produit
    • 6. Déléguer efficacement
    • Bibliographie
    • Glossaire
    • Index

Auteur

Edgard MAILLOTEn savoir plus

Scrum Master et coach agile, Edgard Maillot a expérimenté Scrum durant plus de 10 ans dans des sociétés de conseil et d’ingénierie informatiques. Depuis cinq ans, il forme chaque année plus d’une centaine de personnes au métier de Scrum Master et de Product Owner, jusqu’aux certifications de second niveau sur Scrum.org. Il assiste également de grandes entreprises dans leur démarche agile en s’appuyant principalement sur Scrum. À ce titre, il forme et accompagne des Product Owners, coache des Scrum Masters et des équipes de développement pour accroître leur maîtrise de Scrum.

Caractéristiques

  • Nombre de pages 346 pages
  • Parution mars 2021
    • Livre (broché) - 17 x 21 cm
    • ISBN : 978-2-409-02925-7
    • EAN : 9782409029257
    • Ref. ENI : DPPROWN
  • Parution mars 2021
    • HTML
    • ISBN : 978-2-409-02926-4
    • EAN : 9782409029264
    • Ref. ENI : LNDPPROWN

Téléchargements

En complétant ce formulaire, vous acceptez d'être contacté afin de recevoir des informations sur nos produits et services ainsi que nos communications marketing. Vous aurez la possibilité de vous désabonner de nos communications à tout moment. Pour plus d'informations sur notre politique de protection des données, cliquez ici.
  • Des fichiers complémentaires (3 131 Ko)