Le pattern Product Owner
rôle définissant les responsabilités et prérogatives liées à la traduction en application, des idées élaborées avec le Métier
permet à une équipe de limiter sa dette technique, c'est-à-dire de prévenir ou de mitiger le désalignement de son état de l'art.
Comment est-ce possible ?
Dans une vision du développement comme processus de fabrication, cela paraît difficilement possible, car :
- la dette technique est un problème situé dans le code
- seuls les développeurs, qui sont des doers, mettent les mains dans le code
- le PO, qui est un thinker, n'a pas d'influence, positive ou négative, sur le code
On pourrait objecter que certains POs ont une influence (négative) sur la dette technique quand ils dé-priorisent des tâches de refactoring sur le backlog, ou bien font pression pour intégrer un maximum de stories dans le sprint en dépit des mesures de vélocité constatée.
Mais ces deux actions : décider des tâches techniques, négocier le coût des stories, ne font pas partie des prérogatives normales du rôle de PO, ce sont là des dérives de la software factory.
Si l'on adopte une vision du développement comme processus de traduction, l'influence du PO sur l'état de l'art de l'équipe devient évidente.
Le pattern Product Owner permet d'établir une conversation entre la Technique et le Métier, laquelle vise une correspondance maximale entre les choix dit fonctionnels et les possibilités de la technologie (dans un contexte incertain, en présence d'un problème partiellement défini, et avec des ressources limitées).
Le PO offre aux développeurs un échantillon des idées élaborées lors d'échanges avec des acteurs Métier éloignés de l'équipe Technique.
Les développeurs le rejoignent à mi-chemin avec leurs outils de programmation, leurs tests, et leur démarche de conception guidée par le domaine.
Les patterns Ubiquitous Language, Bounded Context, Hands On Modelers sont particulièrement représentatifs de cette démarche.
Conversation entre un PO et deux développeurs
▶️ Play !
- PO : pour ce qui est du portefeuille...
- Dev 1 : Question : dans le schéma de BD du back-end existant, il n'y a pas de table Portefeuille...
- PO : Peut être, mais en fait, les agents parlent de portefeuille dans les agences..
- Dev 2 : La table des comptes contient des comptes spéciaux. Il y a un flag qui permet de les voir comme "portefeuille"
- Dev 1 : Wouah !
- PO : Ah oui, c'est vrai. OK, donc...
- Dev 2 : Euh... On devrait peut-être modéliser ce qu'est un portefeuille ?
⏸ Pause !
À votre avis : ce que va dire ensuite le PO aura-t'il une influence sur la dette technique de l'équipe ?
À mon avis : oui, une influence cruciale.
STAY TUNED !!
.png)
.png)
