index.md 3.8KB
title: Le rôle du Product Owner slug: role-product-owner date: 2013-02-07 chapo: Les méthodologies agiles permettent de se remettre en question sans avoir rédigé un cahier des charges de plusieurs centaines de pages.
Quelques notes prises pendant la formation agile/SCRUM donnée par Stéphane ce jour pour scopyleft.
Vision
C’est l’objectif global du produit accessible à toute l’équipe et compréhensible par tout le monde, même et surtout une personne extérieure à l’équipe.
Il est possible de détailler les rôles, la méthodologie ou la technologie dans ce document mais ce n’est pas capital, cela dépend du contexte du produit.
Ce document est relativement bref — surtout au début — pour avoir un ordre d’idée :
- produit (une page)
- release (un paragraphe)
- sprint (une phrase)
La maintenance du document de vision au cours de la vie du produit est très importante.
Réunions
Il y a un cérémonial à respecter qui est représenté par 4 types de rencontres :
- *Planification de sprint (2h)* : négociation du backlog avec l’équipe qui hérite symboliquement du produit ;
- *Dailies (15min/jour)* : permet de garder le contact et d’annuler l’effet tunnel ; ce que l’équipe a fait, ce qu’elle va faire, les blocages rencontrés (à résoudre par le Scrum Master) ;
- *Démo (1h)* : montrer le (totalement) fini, célébrer le travail de l’équipe et réaligner tout le monde, l’équipe rend le produit au *product owner* ;
- *Rétrospective (1h)* : utile pour l’amélioration continue.
Le Product Owner doit être disponible tout au long de la vie du produit.
Il doit également tester les stories terminées pendant le sprint pour faire des retours à l’équipe et s’assurer que les tests d’acceptation sont bien respectés.
Backlog
Chronologie possible des différentes étapes :
- Inventaire brut des stories
- Priorisation des stories par valeur métier
- Rédaction des stories eligibles + tests d’acceptation
- Challenging des stories avec l’équipe
- Estimation des stories par l’équipe
- Re-priorisation possible du backlog par valeur+effort
Stories
Respecter l’acronyme INVEST :
- Indépendante
- Négociable
- Valeur
- Estimable
- Small
- Testable
L’objectif est de maximiser la valeur du projet en minimisant les prédictions.
Une user story est un signal fonctionnel, elle n’est pas détaillée et doit rester flexible. Ce n’est ni une spécification, ni un use-case. Il est possible d’avoir des mockups mais ils sont gardés par la personne qui en a besoin.
Encourager les échanges directs entre le product owner et l’équipe pour résoudre les points flous, en passant parfois par le scrum master.
Schéma de rédaction (peut être simplifié avec l’habitude) :
En tant que {rôle}, je {action} pour apporter {valeur}.
Le curseur de détail des tests d’acceptation peut varier en fonction du besoin, des contraintes du client et de la qualification du product owner.
Ne pas oublier la priorité et l’estimation pour compléter la story. Par exemple, la méthode MoSCoW (MUST, SHOULD, COULD, WON’T) permet de faciliter la priorisation des stories. C’est l’équipe de développement qui découpe les stories en tâches.
L’après-midi a été l’occasion de mettre en pratique la méthodologie sur un sujet concret — celui du client — et d’apporter de la valeur au produit proposé, ce qui s’est soldé par une remise en question très précoce du projet. Les méthodologies agiles permettent de se remettre en question sans avoir rédigé un cahier des charges de plusieurs centaines de pages. Et commencé à le réaliser au prix fort.