L’Agilité apporte depuis plusieurs années des principes forts : une meilleure collaboration, l’acceptation des changements et un rythme de livraison plus rapide. Ces évolutions de la manière de construire un produit ont nécessairement impliqué de fortes réorganisations, au niveau des rôles, des activités et des compétences des équipes produit. Pour mettre en place ces principes, de nouveaux rôles ont vu le jour tel que les Product Owner (PO), formant un trio avec les testeurs et les développeurs.
Les PO façonnent la vision produit sur la base du besoin business discuté avec le client. Ils transmettent cette vision produit aux différents profils et aux différents rôles qui composent l’équipe. Ils pilotent les priorités du produit, par des ajustements réalisés quasi en temps réel, pour, au final, livrer un produit de qualité. Défi supplémentaire des PO, en plus de la définition / partage de la vision produit et du pilotage fin de l’avancement, le défi de la productivité.
Pour assurer cette productivité, des sacrifices ont dû être faits : l’un d’eux concerne la documentation de l’expression du besoin et du Produit. Elle a été reléguée au second plan et quelques années et turn over plus tard, les sachant métier sont rares sur les projets et les nouveaux arrivants (développeurs/testeurs) ont du mal à se documenter.
Dans cet article, nous proposons une approche collaborative et visuelle, dans l’objectif de relever ces défis que l’Agilité à introduit. Nous pensons que la collaboration entre développeur, testeur et PO autour de la formulation des parcours métier à tester est une solution efficace pour retrouver un équilibre entre l’expression du besoin, la productivité et qualité du produit.
Expression du besoin métier
Le PO exprime les besoins métier de différentes façons : épopée, User Story, spécifications détaillées et autres. Le point commun à ces formes d’expression est qu’elles sont textuelles et peuvent mal refléter l’attendu client. Qui dit mauvaise interprétation, dit défaut, dit redéveloppement, reteste et donc perte de vélocité et de qualité. Pour remédier à cela, la collaboration est un aspect clé. Elle peut s’organiser autour d’ateliers des 3 amigos, où PO, testeur et développeur vont pouvoir travailler ensemble sur l’expression du besoin. Ainsi le PO s’assure que chaque acteur a bien compris les besoins métiers avant d’entamer des activités de développement et de test.
Nous proposons une approche pour ajouter de l’efficacité à ces échanges “3 amigos” : le visuel ! On sait bien qu’un bon dessin vaut mieux qu’un long discours et que la dimension graphique permet de transcender les différences de profil présentes au sein d’une équipe agile. Utiliser des représentations visuelles des parcours métier, en complément des US sous format textuel, offre un support fort à la compréhension rapide, précise et partagée des besoins métier.
Différents outils permettent d’exprimer visuellement des parcours métier : Draw.io, Bizagi, Signavio… Dans cet article, nous nous focaliserons sur la solution YEST Enterprise qui propose une chaîne outillée complète en support aux pratiques ATDD (Acceptance Test-Driven Development) depuis l’expression du besoin sous forme graphique jusqu’à la production et la maintenance des tests automatisés.
Avec le module YEST for Jira de la solution, le PO peut créer des parcours métier directement dans Jira sous la forme d’un ticket. Il peut ainsi choisir de concevoir les parcours métiers à travers l’enchaînement des différentes US et aussi détailler les US de manière visuelle. Cet ensemble de parcours constitue une documentation vivante que le PO peut présenter aux membres de son équipe de manière à communiquer les besoins métier sous un autre angle, plus contextualisé. Il assure de cette façon une meilleure compréhension des besoins métier et limite ainsi d’éventuelles phases de redéveloppement et reteste pour garantir une bonne vélocité au sein du projet.
Au-delà, du partage des besoins métiers aux membres de son équipe, le PO peut utiliser les parcours métier pour monitorer différents aspects du projet. Les parcours, comme tout ticket Jira, peuvent être liés à d’autres tickets et ainsi permettre au PO de lier des US aux parcours métier, et même lier des tests ! Une fois qu’un parcours métier est créé par notre PO, il est disponible sous Jira, donc consultable par chaque membre de l’équipe pour servir à tout moment de documentation.
Ces parcours métier graphiques, illustrés dans la capture ci-dessus, permettent de générer automatiquement des tests avec YEST (voir § suivant), ils sont donc plus qu’un simple document, ils constituent un artefact définissant les tests et constamment à jour. Ils sont dès lors capables de remonter au plus tôt d’éventuelles incohérences dans l’expression du besoin métier. De même, quand le besoin métier évolue, le parcours graphique pourra très tôt identifier des adhérences fonctionnelles et ainsi permettre à l’équipe agile d’anticiper et d’éviter des régressions.
Pilotage des tests… et pilotage par les tests !
Le parcours métier graphique peut aussi être récupéré par le testeur directement sur son poste, via le module YEST Desktop de la solution YEST Enterprise. Il sert alors de base à une conception des cas de test ; conception fortement assistée (par des fonctions de génération automatique et de refactoring ainsi que par d’autres fonctionnalités), itérative et incrémentale de façon comparable au développement du code. Le parcours métier est ainsi un support à la fois à l’expression du besoin et à la production (et la maintenance) des tests, pour l’exécution manuelle et automatisée. YEST Enterprise s’intègre de façon fluide avec des outils de test tiers, en publiant les tests manuels dans les outils de gestion de tests tels Xray, Zephyr, Squash, ALM, etc. et en publiant les scripts d’automatisation dans les environnements type Selenium, UFT, RobotFramework, etc.
En point d’orgue de cette démarche, le PO monitore la couverture de la conception et de l’exécution des tests sur les parcours métier graphiques. Testeur et PO à l’unisson participent ainsi au pilotage du développement du produit (TDD) et assure une mise en production sans fausses notes.
Conclusion
Une solution telle que Yest Enterprise offre des solutions à la phase d’expression du besoin jusqu’à l’automatisation des tests. Elle aide le PO dans son expression du besoin, dans l’assurance de la productivité et de la qualité du produit. Si vous avez envie de découvrir plus en détail comment YEST Enterprise peut vous aider, inscrivez-vous au webinar « Product Owner, maitrisez votre tactique d’exécution» le 29 mars prochain.
