Le rôle du Product Owner

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 :

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 :

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 :

Stories

Respecter l’acronyme INVEST :

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.

Discussion suite à l’article :

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.

Il est censé y avoir un lien de causalité entre les deux phrases ? Parce que remettre en question un projet au stade de l’EB, un QQOQCP et c’est réglé :-)

Damien B, le 2013-02-07 à 21:59

Il est censé y avoir un lien de causalité entre les deux phrases ? Parce que remettre en question un projet au stade de l’EB, un QQOQCP et c’est réglé :-)

La remise en question était technique donc le QQOQCP n’aurait pas suffit, c’est le fait d’avoir discuté des user-stories proposées qui a permis de faire ressortir ce problème qui serait probablement passé à la trappe à la lecture d’un cahier des charges.

David Larlet, le 2013-02-07 à 22:19

J’ai toujours les oreilles (ou ici les yeux) qui saignent quand on parle (écrit) "méthode(s) agile(s)"... Il n’y a pas (j’ai jamais vu) une méthode, même agile, qui fonctionne "by the book". Par fonctionner j’entends répondre à mon problème de fabriquant de logiciel: mieux développer, mieux fabriquer.

Mais la base des pratiques Scrum sont là, et c’est un bon début ! :)

C’est donc juste un problème de sémantique que je relève ici. Pour discuter "agilité", je manque de place :-p

Yannick François, le 2013-02-07 à 22:46

Forcément si tu fais un QQOQP ça ne va pas marcher !

Damien B, le 2013-02-07 à 23:31

Par fonctionner j’entends répondre à mon problème de fabriquant de logiciel: mieux développer, mieux fabriquer.

Pour mieux développer ou mieux fabriquer il y a les bonnes pratiques ou XP. Les pratiques agiles permettent avant tout de mieux communiquer au sein d’une équipe et avec le client ce qui est orthogonal à la qualité logicielle.

David Larlet, le 2013-02-07 à 23:35

Il n’y a pas (j’ai jamais vu) une méthode, même agile, qui fonctionne "by the book". Par fonctionner j’entends répondre à mon problème de fabriquant de logiciel: mieux développer, mieux fabriquer.

  1. TECHNOL., INDUSTR., COMM. Procédé. [...] II. − P. ext. Manière de faire quelque chose suivant une certaine habitude, selon une certaine conception ou avec une certaine application.

Ce que j’aime chez les agilistes, c’est qu’ils sont tellement "révolutionnaires", qu’il suffit qu’un mot soit utilisé par "les vieux" pour qu’ils le conspue. On remarquera aussi qu’il n’y pas de démarche agile, ni de philosophie agile, et encore moins de principe agile, parce que la conceptualisation c’est le début de la sclérose, et la sclérose est tout sauf agile

Damien B, le 2013-02-07 à 23:42

Dans les pratiques que j’ai pu essayer, il y en a une bonne partie pour la communication oui (mais pas que ;-)). Je ne vois pas par contre ce que tu entends par "orthogonal à la qualité" ?

En parlant de client là, tu touches un de mes points de réflexion ces derniers temps: le client est-il l’utilisateur ou le sponsor ? Un peu des deux, mais eux peuvent facilement avoir des intérêts orthogonaux...

Mais c’est principalement le mots "méthodes" qui me gène... Ça fait un peu vocabulaire de consultant.

:)

Yannick François, le 2013-02-07 à 23:47

C’est bien cela que je pensais. En fait, pour moi, le principe est de partir de pratique de bases (pour une nouvelle équipe) puis de les faire évoluer en fonction du contexte. C’est à cela que sert la rétrospective. Enfin, c’est ce que j’en ai compris (de l’agilité).

Yannick François, le 2013-02-07 à 23:54

que tu entends par "orthogonal à la qualité" ?

à 90º degrés. Souvent employé pour dire que Poire et Poireaux, deux choses sont différentes sans corrélations. Dans le cas de cette discussion. David a dit :

Les pratiques agiles permettent avant tout de mieux communiquer au sein d’une équipe et avec le client ce qui est orthogonal à la qualité logicielle.

La qualité logicielle == ce qui tient à ce que le code soit bon (test unitaire, optimisé, documentation, etc. etc.)

la communication client-équipe et équipe-équipe == tout ce qui tient de l’avancement du projet, de la résolution des tâches, etc. etc.

Karl Dubost, le 2013-02-08 à 00:15

Merci pour la précision.

J’étais perdu car pour moi la qualité d’un logiciel tiens au fait de correspondre à ce que souhaite le client. J’ai vu plus d’un logiciel couvert de test mais qui ne servait pas du tout les utilisateurs et qui ne convenait pas du tout au sponsor.

Maintenant, je comprend mieux l’orthogonalité :-)

Yannick François, le 2013-02-08 à 08:14

J’étais perdu car pour moi la qualité d’un logiciel tiens au fait de correspondre à ce que souhaite le client.

Il s’agit là plus de pertinence que de qualité et les pratiques agiles encouragent — via les itérations courtes — l’amélioration de cette pertinence, si elles sont suivies convenablement (livrables terminés, client impliqué, utilisateurs considérés, etc).

David Larlet, le 2013-02-15 à 09:09

Il s’agit là plus de pertinence que de qualité et les pratiques agiles encouragent

Quoi ? Tu sous-entendrais que la réussite d’un projet Scrum tiendrait beaucoup à un point que 99% de ces projets ne prennent pas en compte : un Product Owner compétent ?

Damien B, le 2013-02-15 à 09:20

Exactement, d’où la nécessité de formation et d’accompagnement :-)

David Larlet, le 2013-02-15 à 11:05