Product Owner Son rôle dans le projet Agile

Cursus Agile - Module 5

Yassine ZAKARIA

1

Product OwnerSon rôle dans le projet Agile

Sommaire

▷Introduction à l’Agilité

▷Scrum▷Lancement▷Equipe : Rôles et responsabilité▷Le produit, la valeur

▷ Bonnes pratiques PO

▷Estimations et planification▷Suivi et reporting▷Amélioration continue

2

Introduction à l’AgileQu’est ce que c’est ?

Pourquoi une autre méthode ?

Pourquoi l’Agile

▷Innovation▷Concurrence▷Feedback▷Adaptation au changement▷Production de valeur▷Réduction du « time to market »▷Qualité▷Optimisation▷Responsabilisation des acteurs▷Motivation▷…

3

Le manifeste Agile – Les valeurs

▷Les quatre valeurs fondamentales Agiles sont de valoriser :▷ Les individus et leurs interactions plus que les processus et

les outils.

▷ Des logiciels opérationnels plus qu’une documentation exhaustive.

▷ La collaboration avec les clients plus que la négociation contractuelle.

▷ L’adaptation au changement plus que le suivi d’un plan.

Le manifeste Agile – Les principes

1. Satisfaire le client est la priorité2. Accueillir les demandes de changement « à bras ouverts »3. Livrer le plus souvent possible des versions opérationnelles de

l’application4. Privilégier la conversation en face à face5. Construire des projets autour d’individus motivés6. Responsabiliser les équipes7. Faire avancer le projet à un rythme soutenable et constant8. Porter une attention continue à l’excellence technique9. Favoriser la simplicité 10. Mesurer l’avancement opérationnel du projet11. Les meilleures architectures, spécifications et conceptions

émergent d'équipes auto organisées.12. Ajuster, à intervalles réguliers, ses pratiques et processus pour

être plus efficace

4

Cycle classique

Vision de l’avancement dans un cycle traditionnel

Analyse Design TestDev

Avancement

Fini à 50%Utilisable à 0%

Cycle Agile

Vision de l’avancement dans un cycle Agile

Fct 1

Fct n

Fct m

Avancement

Analyse Design Dev Test

Fini à 50%Utilisable à 100%

5

ScrumRôles et responsabilités

6

LancementRôles et responsabilités

Product Owner

▷ C’est le responsable du « Quoi ? »▷ 1 Product Owner par produit

▷ Ses responsabilités et activités▷Il est engagé sur le produit, vis-à-vis des utilisateurs▷Il a la vision produit, et maitrise les enjeux du produit▷Il gère le product backlog

Objectif : Maximiser la valeur produite par l’équipe▷Il priorise les fonctionnalités▷Il s’assure que l’équipe partage la même la même vision et la même

compréhension des enjeux▷Il formalise une expression de besoin avec différents niveaux de

granularité▷En fonction de l’importance des fonctionnalités▷Il valide ou non les fonctionnalités livrées▷Il communique sur les progrès réalisés et l’avancement du produit

7

Product Owner

▷ C’est le rôle-clé dans la démarche Scrum

▷ Compétences souhaitées d'un bon Product Owner▷ Bonne connaissance du domaine métier▷ Maitrise des techniques de définition de produit▷ Capacité à partager sa vision du produit▷ Capacité à prendre des décisions rapidement▷ Et à effectuer des choix structurants▷ Capacité à détailler au bon moment▷ Esprit ouvert au changement▷ Aptitude à la négociation

L’Equipe

▷ Elle est constituée par tous ceux qui interviennent « régulièrement » sur le produit▷ Développeurs, Architectes, Testeurs, Intégrateurs, etc.

▷ L’équipe est la responsable du « Comment ? »

▷ Ses responsabilités et activités▷ Elle s’engage sur la réalisation du produit, lors d’un sprint▷ Elle estime l’effort nécessaire▷ Elle découpe en tâches les fonctionnalités demandées▷ Elle s’auto-organise en interne▷ Elle respecte les priorités fixées par le Product Owner▷ Elle collabore avec le Product Owner▷ Elle présente le résultat au Product Owner et aux utilisateurs

8

L’Equipe

▷ Chaque membre se met au service de l’équipe▷ Aucune mise en valeur individuelle possible▷ A l’image du sport collectif : c’est toute l’équipe qui gagne ou qui perd

▷ Généralement composée de 3 à 9 membres▷ Moins c’est bien, mais l’équipe doit être autonome▷ Hétérogène mais tend vers l’homogénéité (équilibre, recouvrement

de compétences)▷ Autonome, s’organise comme elle l’entend▷ Stable

Le Scrum Master

▷ Il a le rôle de facilitateur▷ 1 Scrum Master par Scrum

▷ Ses responsabilités et activités▷ Il peut être impliqué dans la réalisation du produit (mode dégradé)▷ Il est engagé sur la progression de l’équipe▷ Il veille à la bonne marche du processus, et anime l’équipe▷ Il élimine les obstacles qui peuvent réduire l’efficacité de l’équipe, et la

protège de toute interférence externe▷ Il s’assure que chacun respecte son rôle▷ Il s’assure de la collaboration entre les intervenants▷ Il veille à ce que le Product Owner soit toujours en mesure

d’alimenter l’équipe. Notamment avant chaque Sprint planning▷ Il veille à ce que l’équipe se pose les vraies questions et affronte les

problèmes qu’elle rencontre lors de rétrospectives

9

Le Scrum Master

▷ Le Scrum Master n’est pas un chef de projet▷ L’équipe est en auto-gestion▷ Il n’a pas d’autorité ni sur l’équipe, ni sur le PO

▷ Il n’impose pas, il fait confiance▷ Il peut être force de proposition, mais ne doit pas imposer de décision

▷ Il ne contrôle pas, il facilite▷ Il ne dirige pas, il accompagne

▷ Le Scrum Master n’est pas un secrétaire

Les parties prenantes« Stakeholders »

▷ L’ensemble des acteurs concernés par le projet (non opérationnels) :▷ Sponsor▷ Représentants des Utilisateurs ▷ Product Managers▷ Maitrise d’ouvrage▷ Direction service commanditaire▷ …

▷ Rôle▷ Définir le Produit (stratégie, feuille de route, …)▷ Feedback (lors des revues notamment)▷ Arbitrages

10

ScrumLe Produit

Le produit

11

Le Produit

▷ Le produit peut être découper en une ou plusieurs releases (versions) en fonction :▷ Du contenu▷ De la taille de l’équipe ▷ Des contraintes (délai notamment)▷ …

Release 1 Release 2 Release 3 Release n

Le produit

Le Produit

▷ Les 3 phases d’une release

12

La notion de MVP

▷ Minimum Viable Product▷ Définir le produit complet▷ Retirer les fonctionnalités moins utiles (n fois)▷ Quand retirer une fonction rend le produit non viable (utilisable) c’est

le MVP

▷ Intérêt▷ Réduire le « Time to market »▷ Recueillir le feedback des utilisateurs

MVP : exemple

▷ Minimum Viable Product▷ Exemple de Dropbox : MVP = une simple vidéo « factice » Le produit

n’existe pas encore, la démo est faite sans le produit !http://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/

▷ Drew HOUSTON (CEO) : “It drove hundreds of thousands of people to the website. Our beta waiting list went from 5,000 people to 75,000 people literally overnight. It totally blew us away.”

13

A propos de l’échec …

Définition du besoinProduit/Vision

Thème 1

US 1.1

US 1.2

…

US 1.i

Thème 2

US 2.1

US 2.2

…

US 2.j

… Thème n

US n.1

US n.2

…

US n.k

14

Définition du besoin

▷ Objectifs▷ Identifier la vision, les personas et les thèmes▷ Pour chaque thème, identifier les User Stories▷ Organiser et prioriser le Backlog produit

▷ Préparé et animé par le PO▷ Participants :▷ Référents métiers▷ Représentants des utilisateurs▷ Autres

▷ Outils▷ Personas▷ Story mapping , Impact mapping▷ Buy a feature▷ Design thinking

Expression d’une User Story

▷ Utilise un formalisme simple▷ Utilise les concepts métiers sous-jacents▷ Elle est compréhensible de tous les acteurs

▷ Donne une vue métier des fonctionnalités▷ Et non descriptive !

▷ Ne s’attarde pas aux détails▷ Se formalise ainsi :

En tant que <rôle>,je peux <besoin>

de façon à <bénéfice>

15

Le Product backlog

▷ C’est une liste de fonctionnalités priorisées▷ Il est établi et géré par le Product Owner▷ Il peut ajouter, retirer, diviser ou regrouper des fonctionnalités▷ Il peut re-prioriser certaines fonctionnalités

▷ Exprimé de façon à mettre en évidence la valeur apportée▷ La partie haute est détaillée pour être prise en charge dans le

prochain sprint

Impact mapping

« Il n’y a rien de plus inutile que de faire avec efficacité quelque chose d’inutile »

Peter Drucker

16

Impact mapping

Story mapping

17

Le Design Thinking

▷ Le Design Thinking est une approche de l'innovation et de son management qui se veut une synthèse entre la pensée analytique et la pensée intuitive. Il s'appuie sur un processus de co-créativité impliquant des retours fréquents et réguliers de l'utilisateur final.

Le Design Sprint

▷ L’idée du Design Sprint est très simple : tâcher d’accomplir en 5 jours un travail qui peut parfois s’étaler sur des semaines voire des mois.

18

ScrumEstimations et planification

La planification Agile

▷ 3 niveaux de planification▷ Livraison▷ Itération▷ Journée

▷ Ne s’appuie pas sur un planning figé

▷ Après chaque activité de planification, le planning de la livraison est mis à jour▷ En fonction de l’efficacité de l’équipe▷ En fonction de la révision du périmètre

19

La planification Agile

▷ L’estimation de la durée passe par l’estimation relative de la taille

▷ L’estimation ne bouge pas quand la vitesse de l’équipe change▷ Grâce à l’estimation relative, qui ne dépend pas des individus

▷ L’estimation est uniforme▷ Un des éléments sert de référence

▷ La taille est déterminée en fonction▷ De la complexité fonctionnelle ou technique▷ De la quantité de travail à fournir▷ Du risque technique ou fonctionnel que son développement

représente

La planification Agile

▷ On utilise une unité de mesure décorrélée du temps :

Les Story Points

▷ Pratiques utilisées :▷ Le Planning Poker▷ eXtreme Quotation

20

Le planning Poker

▷ Objectif :▷ Déterminer l’effort nécessaire à la réalisation d’une fonctionnalité ou

d’un item

▷ S’adresse à l’équipe▷ S’appuie sur une liste de Fibonacci modifiée :

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, ∞

Le planning Poker

▷ On affiche la liste des fonctionnalités classées par ordre de valeur

▷ Chaque membre possède un jeu de cartes avec des points▷ L’équipe détermine une fonctionnalité de référence▷ taille moyenne : 5 ou 8

▷ Elle estime les fonctionnalités les unes après les autres de la façon suivante :▷ Les membres choisissent une carte sans la révéler▷ Lorsque tous les membres ont choisi leur carte, tout le monde la

retourne en même temps▷ En cas de désaccord, ou trop de ? :

▷ Discussion entre les membres,▷ Questions posées au client si des précisions sont nécessaires

▷ Attention :▷ L’estimation se fait de manière relative !!▷ Fonctionnalité de référence

21

eXtreme Quotation

▷ Les US sont disposées aléatoirement sur une table▷ Sur une autre table sont disposées des cartes▷ Représentant les valeurs des cartes du Planning Poker

▷ L’équipe détermine une fonctionnalité de référence▷ taille moyenne : 5 ou 8

▷ 1ère itération : 5 minutes maxi▷ L’équipe déplace les cartes d’une table à l’autre▷ Pas de discussion interne, juste des questions au PO

▷ 2e itération : 10 minutes▷ L’équipe fait des inversions▷ Notez les cartes à chaque mouvement avec un point

▷ 3e itération : 20 minutes▷ L’équipe peut discuter de quelques fonctionnalités posant problème

La vélocité

▷ Comment mesure-t-on l’efficacité et la progression de l’équipe ?▷ On utilise la vélocité▷ Somme des story points des fonctionnalités totalement terminées lors

de l’itération

22

Le Release planning

Définition des paramètres de Scrum

▷ L’Equipe Scrum détermine les paramètres suivants :▷ durée et rythme du sprint ▷ définition de « fini » (Done, Ready)▷ Horaires et planning des cérémonies▷ Lancer les invitations

▷ …▷ Mode de collaboration, les éventuels outils

23

Le Release planning

▷ C’est l’activité de planification de la livraison▷ Cela donne une vision à moyen terme▷ 2 à 6 mois

▷ Objectif : Etablir un planning prévisionnel en fonction de la contrainte principale▷ Le PO présente le produit (Vision, Thèmes, US, …)▷ L’équipe pose des questions puis estime les US

▷ Le planning dépend totalement du contenu du product backlog▷ Il est remis en cause à chaque fin de sprint

▷ On se base sur la Vélocité pour faire une projection▷ Le 1 er Release Planning est prévisionnel▷ Il devient plus précis à partir de la fin du 2ème ou 3ème Sprint.

ScrumLe Sprint

24

Le Sprint

▷ Activités du PO▷ Sprint planning▷ Daily meeting (*)▷ Autres réunions de travail▷ Tests et validation du sprint en cours▷ Détail des fonctionnalités des sprints suivants▷ Préparation et animation de la Review▷ Retrospective

SPReviewRetro

S1 S2 S3

PO POSprint de 3 semaines

Interventions du PO

Plan de charge

▷ Classique▷ Pics et creux de charges

▷ Agile▷ Charges lissées

Interventions du PO

25

Le Sprint planning

Le Sprint planning

▷ C’est l’activité de planification du sprint

▷ Cela donne une vision à court terme▷ 1 à 4 semaines

▷ Objectif : Etablir la liste des User Stories que l’équipe s’engage à développer pendant le sprint▷ En fonction de l’estimation accordée à chaque user story▷ En fonction de la vélocité estimée de l’équipe▷ En fonction du ressenti de l’équipe, de ses contraintes

▷ Prend en entrée le Product Backlog▷ En sortie, on obtient le Sprint Backlog▷ A lieu uniquement en début d’itération

26

Le Sprint planning

▷ Pré-requis :▷ Le Product Backlog est à jour▷ Les fonctionnalités les + importantes ont une granularité fine▷ L’ensemble est priorisé

▷ Déroulement▷ Le Product Owner présente les user stories une à une▷ L’équipe pose des questions et échange avec le PO▷ L’équipe estime les US▷ L’équipe découpe les US en tâches▷ A ce stade, deux solutions possibles :▷ Vélocité connue : A partir de l’historique de vélocité

On sélectionne les user stories d’un poids équivalent▷ Vélocité non connue : En se basant sur le ressenti de l’Equipe

▷ L’équipe initialise le management visuel

Le management visuel

Backlog Todo In progress Test Done

27

ScrumSuivi et reporting

Le Daily Scrum

28

Le Daily Scrum

▷ A tour de rôle, chacun présente :▷ S’il a respecté les engagements qu’il a pris la veille▷ Les obstacles qu’il rencontre dans le respect de ses engagements▷ Les engagements qu’il prend pour la prochaine journée

Qu'est ce quetu as réalisé hier ?

Quelles sont testâches aujourd'hui ?

Est-ce quequelque chose te gène

dans la réalisationde tes tâches ?

Le management visuel

Backlog Todo In progress Test Done

29

Le Sprint Burndown

▷ C’est un graphe qui montre le reste à faire du sprint▷ En abscisse, le nombre de jours de l’itération▷ En ordonnée, la somme des story points des US du sprint, le

nombre d’US restantes, le nombre de tâches restantes, etc.▷ Lors de chaque Daily Scrum, le graphique est mis à jour▷ Seuls les story points des user stories terminées sont

décomptés▷ Il permet à l’équipe de savoir si l’engagement qu’elle a pris est

toujours réaliste par rapport à une courbe de tendance

Le Grooming« Affinage du backlog »

30

Le Grooming

▷ C’est l’activité d’affinage du Backlog. Une à 2 fois en cours de sprint :▷ Ajout / suppression d’US▷ Découpage d’US▷ Priorisation▷ Estimation des US

▷ Il permet également d’étudier par anticipation le contenu du Sprint backlog suivant afin de vérifier sa recevabilité.

La ReviewDémo du produit

31

La Review

▷ Animée par le PO. A lieu en fin de sprint▷ C’est une démonstration faite aux parties prenantes du produit▷ C’est l’occasion donnée aux parties prenantes de confronter

leurs idées à la réalité▷ Cela conclue une boucle de feedback, qui commence lors du

sprint planning

▷ Déroulement▷ Le Product Owner présente les user stories du sprint backlog aux

utilisateurs▷ L’Equipe fait la démonstration des user stories dans l’ordre de priorité▷ Les utilisateurs posent leurs questions et font leurs remarques▷ Un échange a lieu pour permettre de comprendre les attentes des

utilisateurs

La Review

▷ Seules les user stories terminées sont démontrées▷ Peuvent être conviées toutes les personnes directement

intéressées par l’application

▷ Ce ne doit pas être un tribunal▷ C’est un moment d’échange entre les parties prenantes, voire les

utilisateurs, et l’équipe▷ L’équipe n’est pas jugée sur le travail accompli ou non, c’est le produit

qui est au centre de l’attention

▷ Il faut préparer la review, la scénariser▷ Pour chaque US, on s’appuie sur les tests d’acceptation

▷ La review valide les US prises en compte▷ On calcule la vélocité du sprint en additionnant leur valeur d’effort

(story points)

32

Le Release Burndown

▷ C’est un graphe représentant le reste à faire (RAF) sur la release▷ Le nombre restant de story points à terminer est représenté par

sprint▷ Il est mis à jour à chaque fin de sprint (Review)

▷ Il permet de décider de réduire le périmètre de la release ou de repousser la date de mise en production en cas de retard ou extension de périmètre

La RétrospectiveL’amélioration continue

33

La Rétrospective

▷ C’est un temps de réflexion autour de la progression du Scrum

▷ L’équipe aborde les problèmes qu’elle a rencontrés durant le sprint▷ Les problèmes sont identifiés▷ Leur importance est évaluée▷ Des solutions sont évoquées et prises▷ L’équipe doit se limiter à un certain nombre de problèmes

solutionnés, et ne pas être trop ambitieuse

▷ A lieu après la Sprint Review▷ Est animée par le Scrum Master

La Rétrospective

▷ Formats de rétrospective :▷ Brainstorming▷ Speed Boat▷ Dot-voting▷ Etc.

34

CertificationProduct Owner

Les organismes de certifications

▷Certifications individuelles

▷Scrum.org▷ https://www.scrum.org/Assessments

▷Scrum Alliance▷ http://www.scrumalliance.org/certifications

35

Scrum.org

Merci !Des questions ?

36

Annexes

GlossaireElément Description

Backlog produit Document qui énumère les exigences avec le point de vue du client.

Backlog de sprint Contient les tâches de l'équipe.

Burndown chart Représentation graphique du reste à faire dans une période, actualisé aussi souvent que possible et permettant de montrer une tendance de l'avancement.

Daily Scrum Réunion quotidienne (15mn) de l'équipe pour se synchroniser et remonter les obstacles au ScrumMaster.

Planning poker Technique d'estimation en groupe utilisant un jeu de carte. Les cartes s'inspirent de la suite de Fibonacci. Le but est de se mettre d'accord de manière collective sur un ordre de grandeur de l'estimation.

Product owner Le représentant du client. Littéralement un chef produit.

Release Un release correspond à la livraison d'une version. Par habitude, on parle de release pour considérer la période de temps qui va du début du travail sur cette version jusqu'à sa livraison et qui passe par une série de sprints successifs.

Rétrospective Réunion de toute l'équipe Scrum pour faire le point sur ce qui s'est passé dans le Sprint qui se termine dans le but d'améliorer les processus pour le prochain Sprint.

37

GlossaireElément Description

Revue Analyse critique des résultats obtenus à un moment donné du projet pour s’assurer que les éléments de décision pour la poursuite du projet sont acquis

Scrum Scrum est processus agile de gestion de projet pour construire un logiciel de façon incrémentale, itérative et adaptative (mêlée au rugby).

ScrumMaster Animateur, facilitateur d'une équipe Scrum.

Sprint Bloc de temps aboutissant à créer un incrément du produit potentiellement livrable. C'est le terme utilisé dans Scrum pour itération. Aux débuts de Scrum, un sprint durait 30 jours. La pratique actuelle est de 1 à 4 semaines.

User Story Une User story est une exigence du système à développer. Elle est formulée par l’utilisateur du système.Les User Stories sont les résultats d’ateliers avec le Métier, le Client ou les utilisateurs .

KanbanIntroduction

38

Kanban

▷ Visualiser le flux▷ Limiter le travail en cours (Work in Progress)▷ Gérer le flux▷ Focus sur la qualité

FLUX CONTINUSource : Henrik Kniberg – Kanban and Scrum, making most of both

Mise en œuvre de Kanban

▷Identification des phases / étapes▷Identification des responsabilités (par

phases)▷Identification des activités▷Faire attention :

▷à la granularité ▷à l’indépendance

▷Concevez votre tableau de flux▷Définissez les limites▷Décidez des réunions

39

Les réunion Kanban

▷Réunion de définition, d'expression du besoin et démo (si produit ou évolutions)

▷Réunion quotidienne

▷Réunion d'apprentissage, d'amélioration continue et d'analyse du feedback

Kanban : Mise en œuvre

Backlog Todo In progress Valid Done

40

Kanban : Mise en œuvre

▷Cas d’une équipe traitant plusieurs sujets :

Backlog Todo In progress Valid Done