Dans Scrum, le Product Owner a un rôle capital qui est de s’assurer que le projet délivre un produit de qualité répondant aux besoins du client . Ces besoins sont souvent définis et priorisés en utilisant l’appellation “Business Value” (valeur métier).
Comment çà marche?
Tout d’abord, le Product Backlog.
Celui-ci doit répondre aux 3 questions suivantes:
· Quoi?
· Quand?
· Pour qui?
Quoi? Il s’agit bien sûr des fonctionnalités et jamais d’exigences techniques.
Quand? Nous voulons savoir quelles fonctionnalités sont prioritaires, donc quel est le scenario de livraison de notre produit.
Pour qui? Notre client a certainement une excellente idée. Mais si son produit sera excellent et de bonne facture mais jamais utilisé, quelle est sa vrai valeur?
Le process Scrum
Avant de commencer votre projet, donc avant d’impliquer l’équipe de développement, il faut clarifier le périmètre du projet.
En langage Scrum, ce périmètre est défini par:
· La Vision
· Le Product Backlog
· La Roadmap
1. Le Product Owner rencontre le client est clarifie la Vision du Produit.
Cette vision doit être claire et “partageable”, c’est à dire que toute personne participant au projet doit être à même de comprendre celle-ci sans que cette dernière soit déformée par un quelconque “téléphone arabe”.
2. Le Product Owner demande au client à qui s’adresse ce produit? Qui sont les utilisateurs du produit?
Roman Pichler écrivait que l’objectif de Scrum est de développer un produit que les utilisateurs vont aimer. Pour être sûr que l’objet du développement va atteindre correctement son public, donc générer de la valeur pour notre client, nous devons donc nous adresser aux intéressés.
3. Le client introduit le Product Owner auprès de ces utilisateurs ou développe un panel d’utilisateur type (personae) avec le Product Owner.
Il s’agit de créer une interaction entre le client et les utilisateurs. Il s’agit d’une étape primordiale pour bien démarrer son projet et rechercher une implication à flux constant des utilisateurs.
4. Le Product Owner rencontre les utilisateurs lors d’un User Story (US) Workshop,
a. le Product Owner introduit la vision du client est demande à chaque utilisateur de rédiger une User Story (personelle) adressant une fonctionnalité souhaitée pour le produit futur.
b. Afin de clarifier les attentes de chaque utilisateur, le Product Owner demande 3 lignes de critéres d’acceptation pour chaque US rédigée.
c. Collectivement avec les utilisateurs, les US initiales sont redécoupées en fonction de nouveaux critères d’acceptation. La découpe s’arrête lorsqu’il n’y a plus de nécessité de découpage (just enough!).
5. Le Product Owner revient vers le client avec les US crées lors du US Workshop:
a. Les US sont mises en “vrac” est le travail avec le client peut commencer.
b. Avec le client, nous allons faire la revue de l’ensemble des US et nous allons les triés en fonction des fonctionnalités émergentes: nous ne souhaitons pas livrer un utilisateur, mais plutôt livrer une fonctionnalité permettant de faciliter la discussion avec tous les utilisateurs lors de prochains meetings.
c. Nous supprimons les doublons, analysons les US qui se chevauchent.
d. Le Product Owner demande au client de classer les US en fonctionnalités.
e. Nous regroupons ces fonctionnalités en cherchant à les grouper en Epics et à laisser émerger des Thèmes.
f. La prochaine étape étant la priorisation, il nous faut connaître la Business Value de chaque US. Seul le client pourra nous la donner. Cette priorisation tient compte des paramètres suivants:
· In ou Out (fait sens ou pas...)
· En phase avec la Vision
· Apporte de la valeur au client
· Utile au client
· Permet de réduire les coûts
· Gestion des risques
· Gestion des incertitudes
· Dépendances
· Livrabilité
g. Comme pour un planning poker, cette Business Value est une valeur relative. Nous utilisons donc une approche basée sur MOSCOW pour attribuer une Business Value (BV) par US. Les critères de définition de la BV seront les suivants:
h. Les BV sont consolidées aux niveaux Epic et Thème.
i. Initial Roadmap. Il s’agit de la feuille de route où le plan de livraison initial émergeant de la consolidation des BV.
· Idéalement, cette feuille de route part du thème le plus valorisé au thème le moins valorisé
· Cette roadmap est un outil de communication permettant de renforcer l’analyse des besoins et des exigences pour entammer l’inspect-&-adapt de l’équipement de développement lors du Sprint Planning Meeting.
6. Maintenant, nous sommes prêt à rencontrer la Development Team est analyser avec elle la faisabilité technique de notre produit.
Conclusion
· Pas de Scrum sans cadre de projet initial.
· Le Client définit la vision.
· Les utilisateurs créent les user stories (user + story)
· Le Client priorise ces stories en fonction de la Business Value
· Le tri des stories en epics et thèmes permet de mieux comprendre les attentes des utilisateurs en fonction des exigences du client.
· Une feuille de route initiale est créée pour connaître le COMMENT du point de vue du client.
· Le cadre de projet est uniquement fonctionnel: l’aspect technique est du ressort de la Development Team.
· Le cadre de projet est une information primaire qui évoluera tout au long du projet en fonction:
o De la montée en compétence de l’équipe
o De la réduction des incertitudes
o De l’implication de tous les acteurs au projet.
No comments:
Post a Comment