1. Livres et vidéos
  2. Product Owner - Préparation à la certification Professional Scrum Product Owner™ (examen PSPO I)

Product Owner Préparation à la certification Professional Scrum Product Owner™ (examen PSPO I)

  • 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

La certification Professional Scrum Product Owner™ est composée de trois examens : Professional Scrum Product Owner I (PSPO I), Professional Scrum Product Owner II (PSPO II) et Professional Scrum Product Owner III (PSPO III), attestant respectivement d’un niveau fondamental, avancé ou expert dans la maîtrise du rôle de Product Owner dans un contexte agile Scrum. Ce livre a pour objectif de vous préparer à l’examen de la certification PSPO I.

Pour vous aider à préparer efficacement cet exament, le livre couvre tous les objectifs officiels, tant d'un point de vue théorique que d'un point de vue pratique avec des exemples concrets. Il a été rédigé en français (il ne s'agit pas d'une traduction) par un formateur professionnel reconnu, également Scrum Master et coach agile. Ainsi, les savoir-faire pédagogique et technique de l'auteur conduisent à une approche claire et visuelle, d'un très haut niveau technique.

Chapitre par chapitre, vous pourrez valider vos acquis théoriques, à l'aide d'un grand nombre de questions-réponses mettant en exergue aussi bien les éléments fondamentaux que les caractéristiques spécifiques aux concepts abordés.

À cette maîtrise des concepts du rôle de Product Owner, s'ajoute la préparation spécifique à l’examen. Ainsi, en fin d'ouvrage, un examen blanc de quatre-vingts questions similaires à celles de l'examen officiel, mais en français, vont vous permettre d'évaluer vos connaissances et de vous positionner par rapport à l'examen officiel.

Vous pourrez également accéder gratuitement à 1 examen blanc en ligne en anglais, sur www.edieni.com, destiné à vous entraîner dans des conditions proches de celles de l'épreuve. Sur ce site, chaque question posée s'inscrit dans l'esprit de la certification de Scrum.org et, pour chacune, les réponses sont suffisamment commentées pour combler ou identifier vos ultimes lacunes. À vous de juger quand vous serez prêt pour l'examen final !

Table des matières

  • Chapitre 1 Le patron Scrum
    • A. Les fondamentaux de Scrum
      • 1. Introduction
        • a. Définition de Scrum
        • b. Théorie de Scrum
      • 2. Les rôles Scrum
        • a. Le Product Owner
        • b. Le Scrum Master
        • c. L'équipe de développement
        • d. Les parties prenantes
        • e. Un mot sur les managers
      • 3. Les évènements Scrum
        • a. Le Sprint
        • b. La planification de Sprint
        • c. Le but du Sprint
        • d. L'annulation du Sprint
        • e. La réunion quotidienne ou mêlée
        • f. La revue de Sprint
        • g. La rétrospective de Sprint
        • h. L'affinage du Backlog de produit
      • 4. Les artefacts Scrum
        • a. Le Backlog de produit
        • b. Transparence du Backlog de produit
        • c. Le Backlog de Sprint
        • d. Transparence du Backlog de Sprint
        • e. L'incrément
        • f. La définition de « Fini »
      • 5. Les piliers de Scrum
        • a. Transparence
        • b. Inspection
        • c. Adaptation
      • 6. Les valeurs de Scrum
        • a. Focus
        • b. Ouverture
        • c. Respect
        • d. Courage
        • e. Engagement
    • B. Du projet au produit
      • 1. Focus sur le produit
      • 2. Le cycle itératif
      • 3. Fin du diagramme de Gantt
    • C. Validation des acquis : questions/réponses
  • Chapitre 2 Le métier de Product Owner
    • A. Focus sur le rôle de Product Owner
      • 1. Le Product Owner n'est pas un chef de projet
        • a. La responsabilité du Product Owner
        • b. De la vision projet à la vision produit
        • c. Les outils du Product Owner
      • 2. Le Product Owner est un intrapreneur
        • a. Le pouvoir du Product Owner
        • b. Les limites du Product Owner
      • 3. Un manager atypique
        • a. La clarté des objectifs
        • b. L'ambiance au sein de l'équipe
        • c. La communication avec l'équipe
    • B. Focus sur le Backlog de produit
      • 1. Définition du terme backlog
        • a. Étymologie
        • b. Du point de vue de Scrum
      • 2. Une triple fonction
        • a. Un outil de planification
        • b. Un outil d'organisation
        • c. Un outil de communication
      • 3. Le Backlog, un répertoire unique
        • a. Le Backlog de produit est vivant
        • b. La durée de vie d'un Backlog de produit
        • c. Propriété du Backlog de produit
        • d. Pas de multiples Backlogs
      • 4. Un ordonnancement plus qu'une priorisation
        • a. Organiser en fonction de la valeur
        • b. Organiser dans le temps
        • c. Affiner à mesure
    • C. Les éléments du Backlog de produit
      • 1. Les attributs des éléments
        • a. Les attributs essentiels
        • b. Les attributs récurrents
        • c. Utiliser d'autres attributs
      • 2. Focus sur les attributs essentiels
        • a. Indicateur numérique
        • b. Une description
        • c. Une estimation
        • d. Une valeur
        • e. Un état
        • f. Affecter d'autres attributs
      • 3. Créer des catégories
      • 4. Maintenir une traçabilité
      • 5. Lien fort ou lien faible
    • D. Focus sur la définition de « Fini »
      • 1. Définition du guide Scrum
        • a. La définition de « Fini » est rédigée par l'équipe de développement
        • b. Elle s'applique au produit et à ses composants
      • 2. Les vertus d'une définition de « Fini » claire
        • a. Les contraintes liées au produit
        • b. La définition de « Fini » impacte la capacité à délivrer
        • c. La définition de « Fini » clarifie le cadrage du produit
        • d. La définition de « Fini » évolue
        • e. Les évolutions de la définition de « Fini » se planifient
      • 3. L'impact de la définition de « Fini » de la qualité logicielle
        • a. La qualité logicielle, un enjeu historique
        • b. L'impact d'une définition de « Fini » incomplète est d'ordre financier
        • c. L'agilité n'a pas permis de réduire significativement les coûts
      • 4. L'implication du Product Owner dans la définition de « Fini »
        • a. Des critères d'acceptation à la définition de « Fini »
      • 5. Convaincre les parties prenantes d'adopter une définition de « Fini » ambitieuse
        • a. Utiliser la rétrospective de Sprint
        • b. Utiliser la revue de Sprint
    • E. Focus sur la transparence
      • 1. Définition
      • 2. Les vertus de la transparence
      • 3. L'effet de la transparence sur l'inspection et l'adaptation
        • a. Un exemple concret
        • b. Une controverse est une source d'inspection
      • 4. Les effets d'une transparence complète ou incomplète
    • F. Validation des acquis : questions/réponses
  • Chapitre 3 De la vision stratégique au plan opérationnel
    • A. La vision produit
      • 1. La vision produit est la cible
      • 2. Les trois principales typologies de produits
        • a. Un nouveau produit
        • b. Une évolution de produit
        • c. Une mise en conformité
      • 3. Exemples de vision produit
        • a. Assurancetourix sous la contrainte RGPD
        • b. Roméo et ses masques
        • c. Siri
      • 4. L'anticipation
        • a. L'anticipation rationnelle
        • b. L'anticipation émotionnelle
        • c. La nature de l'anticipation définit la communication
      • 5. La vision est la rencontre du produit et du marché
      • 6. Co-construire la vision produit
    • B. La valeur du produit
      • 1. Identifier les attributs de valeur
        • a. Le délai
        • b. La qualité
        • c. La fréquence
        • d. La récurrence
        • e. D'autres indicateurs
      • 2. Identifier les objectifs et les contraintes
        • a. Qualifier les objectifs SMART
        • b. Exemple de référentiel d'exigences
    • C. Construire un référentiel d'exigences
      • 1. La méthode descendante
        • a. Identifier les objectifs de base
        • b. Identifier les moyens
        • c. Identifier les exigences
      • 2. La méthode montante
      • 3. Structurer le référentiel d'exigences
        • a. Prioriser les objectifs
        • b. Compter les liens des exigences
        • c. Organiser le référentiel d'exigences
    • D. Établir une stratégie produit
      • 1. Les spécificités d'une stratégie produit dans un cycle itératif et incrémental
      • 2. Exemple de stratégie produit
      • 3. Utiliser les objectifs pour raconter l'histoire du produit
      • 4. La stratégie s'inscrit dans le temps
        • a. Stratégie basée sur un cycle itératif et incrémental
        • b. La stratégie itérative implique de découper le produit
        • c. Ordonnancement basé sur la valeur
        • d. Ordonnancement basé sur les risques
      • 5. La stratégie produit suppose des moyens
      • 6. Les besoins des utilisateurs du produit
      • 7. Maintenir le référentiel d'exigences
        • a. Qualifier les exigences
        • b. Initialiser le Backlog de produit
      • 8. Valider sa stratégie
        • a. Vérifier les objectifs
        • b. Vérifier la cohérence des exigences
        • c. Ordonnancer les objectifs
      • 9. Concrètement
    • E. Un plan opérationnel
      • 1. Une vision à long terme
      • 2. La planification de release
        • a. La contrainte de délai
        • b. La contrainte de coût
        • c. L'objectif d'efficience
        • d. L'intranet de Marie
        • e. Partager avec les parties prenantes
        • f. Partager avec l'équipe
      • 3. Une vision à court terme
        • a. Rester focalisé sur les objectifs
        • b. Le plan de Marie vu par l'équipe
        • c. Déléguer à l'équipe de développement
      • 4. Planification agile
        • a. Planifier en fonction du produit
        • b. Inspecter et adapter
    • F. Rédiger des critères d'acceptation
      • 1. Rappel des rôles
      • 2. Les critères d'acceptation basés sur les contraintes
        • a. Les contraintes métier
        • b. Les contraintes légales
        • c. Les contraintes techniques
        • d. Les contraintes fonctionnelles
      • 3. Les critères d'acceptation basés sur l'usage
        • a. La syntaxe Gherkin
        • b. Cucumber
      • 4. Le volume des critères d'acceptation
    • G. Affiner sa vision par rapport à la valeur du produit
      • 1. Les gains du produit
        • a. À court terme
        • b. À long terme
      • 2. Les coûts du produit
        • a. Les coûts de réalisation
        • b. Les coûts de maintenance
      • 3. Identifier les bénéfices par thématique
        • a. Bénéfices directs ou financiers
        • b. Bénéfices de support, d'image ou de confort
        • c. L'exemple de Marie
    • H. Validation des acquis : questions/réponses
  • Chapitre 4 Gérer le Backlog de produit
    • A. Organiser le Backlog de produit
      • 1. Organiser en fonction de la valeur
        • a. La valeur liée aux gains
        • b. La valeur liée aux coûts
        • c. La valeur liée aux délais
        • d. La valeur liée à des objectifs ou contraintes secondaires
        • e. La valeur de quel point de vue ?
      • 2. Organiser en fonction de la complexité
        • a. La complexité de mise en œuvre
        • b. La complexité d'exploitation
      • 3. Organiser en fonction de la prise de risque
      • 4. Organiser selon d'autres critères
      • 5. L'organisation du Backlog de Marie
    • B. Affiner le Backlog de produit
      • 1. Rappel du principe itératif
      • 2. Définition de l'affinage
        • a. Par où commencer l'affinage ?
        • b. Qui participe à l'affinage du Backlog de produit ?
        • c. Quand faut-il affiner le Backlog de produit ?
        • d. Jusqu'à quel niveau affiner ?
      • 3. La règle des 10 %
      • 4. Découper les éléments
      • 5. Découpage vertical ou horizontal
      • 6. Affiner les descriptions
      • 7. Affiner les autres attributs
        • a. La valeur
        • b. La complexité
        • c. Le risque
      • 8. Affinage et transparence
        • a. La règle des trois C
        • b. L'importance d'être compris
        • c. L'importance de la communication
        • d. L'importance du format carte
        • e. Rendre le Backlog de produit lisible et visible
      • 9. Affiner l'ordonnancement du Backlog de produit
    • C. Faire face aux changements
      • 1. Gérer les nouvelles demandes
        • a. Être proactif
        • b. Rappeler la planification agile
        • c. Vérifier les objectifs et les contraintes
        • d. Rechercher le sens
        • e. Un modèle opérationnel
        • f. Savoir dire non
        • g. Oser dire non
        • h. Exprimer son désaccord et donner son point de vue avec assertivité
        • i. Rester constructif
      • 2. Nettoyer le Backlog de produit
        • a. Mesurer les objectifs
        • b. Les objectifs atteints
        • c. Les objectifs inaccessibles
        • d. Les objectifs changent
        • e. Passer en revue les contraintes
        • f. Faire le point sur les moyens
    • D. Validation des acquis : questions/réponses
  • Chapitre 5 Communiquer plus efficacement
    • A. Les bénéfices du management visuel
      • 1. Accéder plus facilement à une information complexe
      • 2. Réduire le délai de prise de décision
      • 3. Maintenir plus facilement un référentiel complexe
    • B. Les outils de management visuel
      • 1. La planification de produit
      • 2. Le Backlog de produit
      • 3. Le Backlog de Sprint
        • a. Comprendre le Backlog de Sprint
        • b. Savoir déceler les signaux d'alerte
      • 4. Les comptes rendus de l'équipe de développement
      • 5. Les Burndowns de release ou de produit
      • 6. Le référentiel d'exigences
      • 7. Les solutions informatiques
    • C. Communiquer efficacement
      • 1. L'information visuelle
      • 2. S'appuyer sur des faits ou des indicateurs
      • 3. L'oral et l'écrit
        • a. Les cas favorables à l'oral
        • b. Les cas favorables à l'écrit
      • 4. S'appuyer efficacement sur le Scrum Master
        • a. Le Scrum Master supprime les obstacles entravant la progression de l'équipe de développement
        • b. Le Scrum Master au service du Product Owner
      • 5. Faire participer des membres de l'équipe de développement
      • 6. Faire participer des parties prenantes
    • D. Validation des acquis : questions/réponses
  • Chapitre 6 Maximiser la valeur
    • A. Délivrer le produit
      • 1. Le plus tôt possible
      • 2. Livrer fréquemment
        • a. Le produit de Marie
        • b. À quelle fréquence ?
      • 3. Scrum et DevOps
      • 4. Délivrer le produit de plusieurs équipes
    • B. Inspecter régulièrement
      • 1. Inspection du Backlog de produit
        • a. L'intranet de Marie
        • b. La qualité des éléments du Backlog de produit
        • c. Les retours des utilisateurs
      • 2. Inspection des processus de l'équipe Scrum
        • a. Marie et ses User Stories
        • b. La rétrospective de Sprint
        • c. Inspecter en dehors de la rétrospective de Sprint
    • C. Adapter les processus
      • 1. Pour accroître la valeur
        • a. Marie face au RGPD
      • 2. Pour accroître la transparence
      • 3. Pour améliorer l'efficience du travail collaboratif
        • a. Marie change la date de début des Sprints
    • D. Améliorer la transparence
      • 1. La revue de Sprint
      • 2. La compréhension des éléments du Backlog de produit
        • a. Par les parties prenantes
        • b. Par l'équipe de développement
    • E. Piloter le budget
      • 1. Mesurer le coût total
        • a. Le TCO
        • b. La dette technique
        • c. La dette opérationnelle
      • 2. La vélocité comme mesure de ROI
      • 3. L'usage est la mesure ultime
        • a. Marie stoppe le développement du produit
    • F. Piloter les délais
      • 1. Financer un Sprint supplémentaire
        • a. Marie prolonge le développement du produit
      • 2. Réorganiser la planification
        • a. Le plan de release
        • b. Réorganiser le Backlog de produit
    • G. Validation des acquis : questions/réponses
  • Chapitre 7 Scrum à l'échelle
    • A. Scrum et SAFe
      • 1. SAFe
      • 2. Scrum à l'échelle selon Scrum.org
    • B. Organisation des équipes multiples
      • 1. Organisation horizontale : la Component Team
      • 2. Organisation verticale : la Feature Team
    • C. Scrum avec deux ou trois équipes
      • 1. La notion d'ambassadeur
      • 2. La planification de Sprint
        • a. Le "Why"
        • b. Le "What"
        • c. Le "How"
      • 3. La mêlée quotidienne
      • 4. La revue de Sprint
      • 5. La rétrospective de Sprint
    • D. Scrum à plus grande échelle
      • 1. Les problèmes de dépendance
        • a. Dépendances et ordonnancement du Backlog de produit
        • b. Le poids de la dette technique
        • c. Marie soigne ses dépendances
      • 2. Nexus
        • a. Nexus et SAFe
        • b. L'affinage du Backlog de produit avec Nexus
        • c. L’équipe d’Intégration Nexus
        • d. La planification de Sprint Nexus
        • e. Les autres évènements Nexus
        • f. La limite de temps des évènements Nexus
    • E. Organisation du Backlog de produit
    • F. Déléguer efficacement
    • G. Validation des acquis : questions/réponses
  • Chapitre 8 La certification Product Owner
    • A. Les organismes de certification
      • 1. Scrum.org
      • 2. Scrum Alliance
    • B. Préparer la certification Scrum.org
      • 1. La structure du référentiel de connaissance Scrum.org
      • 2. Étudier le guide Scrum
      • 3. Utiliser les examens blancs
        • a. Sur Scrum.org
    • C. Sur d’autres sites
      • 1. Organisation de l'examen
      • 2. Planifier l’examen
      • 3. Revenir sur les questions les plus complexes
      • 4. Procéder par élimination
      • 5. S’organiser avant l’examen
    • D. Examen blanc en français
      • 1. Questions
        • a. Comprendre et appliquer Scrum
        • b. Développement des équipes et des personnes
        • c. Gestion de produit agile
      • 2. Réponses
        • a. Comprendre et appliquer Scrum
        • b. Développement des équipes et des personnes
        • c. Gestion de produit agile
    • Bibliographie
    • Glossaire
    • Tableau des objectifs
    • 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 février 2021
    • Livre (broché) - 17 x 21 cm
    • ISBN : 978-2-409-02903-5
    • EAN : 9782409029035
    • Ref. ENI : CEPROWN
  • Parution février 2021
    • HTML
    • ISBN : 978-2-409-02904-2
    • EAN : 9782409029042
    • Ref. ENI : LNCEPROWN

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 (3131 Ko)