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.
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.
Dans une vision du développement comme processus de fabrication, cela paraît difficilement possible, car :
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.
▶️ Play !
⏸ 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 !!
Notre Manifeste est le garant des droits et devoirs de chaque CodeWorker et des engagements que CodeWorks a vis-à-vis de chaque membre.
Il se veut réaliste, implémenté, partagé et inscrit dans une démarche d'amélioration continue.
Tu veux partager tes connaissances et ton temps avec des pairs empathiques, incarner une vision commune de l'excellence logicielle et participer activement à un modèle d'entreprise alternatif, rejoins-nous.
.png)
