La « valeur » au cœur de la qualité et donc du test en Agile
Lorsque l’on parle des tests en Agile on parle généralement de qualité. Les processus de tests doivent permettre « d’assurer » des livraisons de qualité. Mais, au fait, qu’entend-on par « qualité » ?
Donner une définition complète et partagée par tous est complexe voir impossible comme je le montre dans la série « à la recherche de la qualité perdue« . On peut néanmoins s’accorder sur 2 points essentiels pour qu’un logiciel ou une application soit de « qualité »:
- l’application contient un nombre limité de bugs et dont les bugs ne sont pas vraiment « gênant » pour les utilisateurs
- l’application propose des fonctionnalités qui ont de la « valeur », qui correspondent concrètement à leurs usages
Pour moi ces 2 points sont les clés de la « bonne » qualité… Et il est donc normal que lorsque l’on parle Agile on parle de livraison de valeur comme le met en avant ce principe Agile: « Notre principale priorité est de satisfaire le client en livrant rapidement et régulièrement des solutions qui apportent de la valeur.«
La valeur est au centre du produit et se doit donc d’être comprise et visible par l’ensemble des parties prenantes… Ceci est un préalable pour pouvoir challenger et donc tester la valeur des fonctionnalités qui viendront enrichir le produit!
A noter: la notion de valeur existe aussi en cycle en V avec l’expression de besoin. Les tests d’acceptation faits par le métier (généralement très tardifs) sont là pour le rappeler.
Identifier la valeur
Avant de pouvoir « tester » la valeur d’une fonctionnalité il est essentiel de pouvoir identifier, caractériser et évaluer cette valeur.
On dit généralement que les US doivent être écrites avec:
- En tant que [persona]
- Je veux [action]
- Afin de [raison]
Cette structure a pour but d’identifier une valeur. Néanmoins je peux affirmer avec mes diverses expériences que cette structure n’est pas toujours utilisée et qu’elle l’est malheureusement souvent mal mise en place. Par « mal » on peut entendre peu clair ou ne faisant pas passer la valeur. Au même titre que d’écrire des tests en gherkin n’est pas faire du BDD, écrire dans sa User Story « En tant que; Je veux; afin de » ne veut pas dire bien écrire son US et bien identifier la valeur.
Bien écrire une US est essentiel et n’est pas chose aisée (sinon le métier de PO n’existerait pas ^^). Les US sont la brique élémentaire de la construction des produits en Agile. Chacune de ces brique doit répondre à certains critères (INVEST) dont celui d’avoir une « valeur ». Malheureusement je vois trop souvent des US mal écrites (ou découpées) ne mettant pas en avant la valeur, ou dans le pire des cas, ne proposant pas de valeur intrinsèque. De même, les équipes sont trop souvent incapables de donner la valeur des l’US sur lesquelles elles travaillent… Ce phénomène est d’ailleurs encore plus important quand on est en Agile à l’échelle.
Les raisons ? Elles sont multiples. Je dirai qu’il y a le critère de « temps » qui revient très régulièrement. Les équipes sont « pressées » de délivrer et de délivrer beaucoup (plus que leur capacité). Elles se retrouvent donc constamment à devoir gagner du temps à court terme… et au bout d’un moment le temps se gagne sur la phase de préparation, sur la qualité des US, sur l’appropriation de l’US et de ce qu’elle doit proposer.
Malheureusement cette perte de vision de la valeur coûte beaucoup plus qu’elle ne fait gagner. Il est donc essentiel, problématique de temps ou non, de réussir à se réapproprier cette valeur et de savoir ce que l’on fait et pourquoi on le fait. Tous les membres d’une équipe Agile doivent pouvoir répondre facilement à cette question: Quel est l’apport concret de l’US ou de la fonctionnalité ?
Ce n’est qu’à partir de ce point que l’équipe pourra tester la valeur et donc évaluer la qualité délivrée aux utilisateurs.
Tester la valeur
Cela peut paraitre basique mais savoir ce sur quoi on travaille et la valeur de ce que l’on apporte est essentiel au test et même au développement des produits. Le BDD se concentre d’ailleurs beaucoup sur ce sujet: il faut livrer ce qu’attend vraiment l’utilisateur.
De même bien savoir ce qui est attendu permet d’adapter ses développements et ses tests… cela permet aussi de « Négocier » (le « N » de INVEST) la manière de l’atteindre.
Cette visibilité sur la valeur permet aussi de faire une « revue » de cette dernière. Qu’apporte concrètement cette « valeur », n’existe pas un moyen différent permettant d’apporter plus de valeur ? Cette valeur est-elle vraiment prioritaire par rapport à d’autres ?
Toutes ces questions se retrouvent dans des ateliers comme les « 3 amigos » ou les « example mapping » et elles sont essentielles! En sortie de ces ateliers l’US ou la fonctionnalité proposée est enrichie, mieux décrite et mieux adaptée aux différents besoins. L’US ressort donc de meilleure qualité qu’elle n’est entrée. Elle sera plus vitre livrée (car testée tôt), de meilleure qualité et donc plus utilisée par les utilisateurs. Cela permet d’éviter des contextes que j’ai connus où moins de 50% des fonctionnalités développées par l’équipes sont utilisées car elles ne correspondent pas vraiment au besoin actuel ou n’avaient pas de réelle valeur.
Conclusion
La valeur est une partie intégrante de la qualité. Elle est le pivot central des développements en Agile et n’est pas forcément simple à identifier. Il est donc essentiel que cette dernière soit toujours comprise, visible et qu’elle puisse être challengée (en d’autres termes « testée »).
Tester la valeur permet d’améliorer de nombreux points comme:
- la valeur concrète livrée (avec l’enrichissement de l’US, une meilleure conception et de meilleurs tests) à chaque itération
- travailler sur ce qui apporte le plus de valeur en priorisant mieux les fonctionnalités
- donner plus de sens au travail de l’équipe.
Il existe de nombreuses méthodes (BDD, ATDD…) et structures d’US qui permettent de répondre à ces besoins… Il est cependant nécessaire de bien s’approprier ces outils afin de s’assurer qu’ils atteignent réellement leur but.
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
