Le blog Acolad

Agile product owner : les responsabilités clés des équipes de développement scrum

Rédigé par Dennis Van Aelst | 26 juin 2018 07:00:00

Employé chez ACOLAD en tant que formateur d'équipe de gestion de contenu d'entreprise (Enterprise Content management – ECM), je passe la plus grande partie de mon temps à diriger des équipes de produits en vue de la mise en œuvre d'applications informatiques standard (Common-of-the-shelf software, COTS) dans des environnements d'entreprise. Cela inclut l'introduction de méthodologies de développement de logiciels agiles et la mise en relation d'utilisateurs professionnels et de développeurs dans une équipe avec structure en forme de T multifonctionnelle.

Quand on observe des équipes scrum hautement performantes, une chose est claire : le product owner (PO) est l'élément clé pour la création d'un produit réussi.

Responsabilités clés de l'agile product owner

Le product owner joue l'un des trois rôles (scrum master, responsable de l'équipe de développement et product owner) du framework scrum pour la gestion de projet agile. Il est la seule personne responsable de la gestion du carnet de produit. En bref, il est chargé de la création de la liste comprenant toutes les tâches nécessaires dans le cadre du projet. Celles-ci peuvent être soit techniques soit centrées sur l'utilisateur, sous la forme de témoignages d'utilisateurs (user stories – US) par exemple. L'élément clé pour démarrer avec succès tout projet de développement logiciel agile ? C'est d'exprimer clairement les éléments compris dans le carnet de produit et de traduire les besoins des parties prenantes en instructions utilisables pour créer et fournir des solutions à ces défis.

Dans de nombreux cas, les parties prenantes du côté client ne sont pas prêtes à suivre le rythme de l'équipe agile et ne fournissent pas les informations et les exigences d'une manière telle que l'équipe de développement puisse facilement retracer les tâches en attente. Afin de les relier, le product owner doit s'assurer que le carnet de produit est visible, transparent, clair pour tout le monde, et qu'il définisse sur quoi l'équipe travaillera pour atteindre l'objectif ou respecter la date limite.

Comment alors un product owner agile peut-il gagner la confiance de son équipe et générer de la valeur pour le client, quel que soit le projet de développement de logiciel ? En fonction de mon expérience, j'ai énuméré les 4 principaux domaines dans lesquels un product owner doit se surpasser afin de garder les équipes scrum efficaces :

1. Vous êtes le leader !

Vous dirigez le développement du produit – en générant le plus de valeur possible pour le client. L'agilité guide une équipe auto-organisée, et le product owner est le second leader serviteur de l'équipe – auprès du leader agile ou du scrum master. Vous devez constamment fournir de la valeur ajoutée, même si l'équipe de développement compte mettre en ordre la dette technique. Gérez vos ressources et dirigez-les vers un meilleur produit, mais n'oubliez pas que le code/l'infra reste un organisme vivant.

2. Produit - objectif - mission

Connaissez parfaitement votre produit/votre mission. Respirez-le, vivez-le. Concevez-le.

Concentrez-vous sur l'équipe plutôt que sur les parties prenantes. Les parties prenantes sont importantes, mais assurez-vous de ne pas perdre l'emprise sur l'équipe de développement !

Prenez possession du projet et des démonstrations, ne comptez pas sur l'équipe de développement pour montrer ce qui a été accompli en tant qu'équipe. Impliquez-vous dans tous les processus, du déploiement à la production et aussi dans les opérations de maintenance – en recueillant les commentaires nécessaires afin de pouvoir progresser continuellement.

3. Connaissez votre backlog

L'équipe ne peut commencer à travailler que si les tâches sont claires. La gestion du backlog doit être effectuée correctement. Le product owner doit mettre au défi l'équipe de développement pour améliorer le backlog, se connecter avec le public cible (utilisateurs) et consigner les progrès dans un outil de suivi des problèmes.

  • Qu'est-ce qui est important ? Essayez de prioriser, chaque tâche n'a pas la même priorité.
  • Le contrôle des incidents n'est pas la même chose que l'introduction d'une nouvelle fonctionnalité ou de témoignages d'utilisateurs et vice versa, de sorte qu'ils ne peuvent pas être effectués dans le cadre d'un seul sprint.
  • Préparez-vous en vous assurant que les tests d'acceptation des utilisateurs (User Acceptance Test – UAT) et les critères d'acceptation des opérations sont clairs.

4. Livrer de la qualité

Veillez à inspecter et adapter constamment – c'est quelque chose que nous entendons souvent dans le cadre de l'agilité. Le product owner est responsable de la valeur qui sera fournie par toute l'équipe, mais qui dit valeur dit aussi qualité. Il n'y a aucune valeur présente si les utilisateurs ne veulent l'accepter et si le produit n'équivaut pas aux normes.

Le product owner doit vérifier ou inspecter tous les aspects définissant la finalisation. Sont-ils réalistes ? Assurez-vous que les équipes de développement logiciel comprennent bien les priorités du projet. Dans de nombreux cas, l'équipe de développement de logiciels ne fournit que ce qu'elle juge important. En effet, la communication est présente, mais un individu a plutôt tendance à travailler sur ce qu'il préfère et non sur ce qui devrait être fait. Le product owner doit surveiller de près ce qui sera livré.

Conclusion

L'agile product owner est le second leader serviteur dans l'équipe scrum, en mettant l'accent sur « leader ». Que vous soyez dans une méthodologie agile ou non, vous savez que le rôle du product owner est élémentaire pour la réussite de tout projet de développement logiciel. Au cœur des équipes moins expérimentées, où la gestion de projet évolue vers des pratiques ainsi qu'un état d'esprit plus agile, le product owner peut faire toute la différence dans la réalisation de la mission visant à fournir une solution de haute qualité.

Savez-vous ce que signifie « DevOps » et pourquoi cela devrait attirer l'attention de votre entreprise lors de la sélection d'un partenaire technologique ?