larlet-fr-david/david/blog/2013/role-product-owner/index.md

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](http://www.agilemanifesto.org/)/[SCRUM](https://fr.wikipedia.org/wiki/Scrum_%28m%C3%A9thode%29) donnée par Stéphane ce jour pour [scopyleft](http://scopyleft.fr).*

### 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`](https://en.wikipedia.org/wiki/INVEST_%28mnemonic%29) :

* 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](https://fr.wikipedia.org/wiki/M%C3%A9thode_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.