Et si je développais la brique technique pour préparer la prochaine Userstory ?
Vous venez d’installer un robinet chez vous. Ne voudriez-vous pas le tester un minimum et rapidement afin de vérifier qu’il n’y ait pas de fuite ?
Le réflexe de beaucoup d’équipes est de découper leur fonctionnalité en séparant la partie technique de la partie fonctionnelle, par exemple, en créant un socle technique afin de préparer la partie fonctionnelle. Mais, est-ce bien judicieux ?
Un découpage itératif par la valeur
Le découpage tech et produit n’est pas recommandé car il apporte tardivement de la valeur ajoutée business et une complexité pour tester la partie purement techniques. Un découpage produit est plutôt recommandé par ajout itératif de règles fonctionnelles.
Ce type de découpage permettra :
- D’apporter rapidement de la valeur à votre produit,
- D’avoir du feedback venant du Métier en lui présentant les premiers résultats,
- De faciliter les tests en évitant au Testeur de renter dans le pur technique en consultant des tables, en lançant des Soapui etc. pour analyser le résultat attendu.
« Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. » — Manifeste Agile 2001.
Comment découper ?
J’utilise une technique très simple. Je me pose la question suivante :
“Et si mon projet devait s’arrêter du jour au lendemain et la Userstory sur laquelle je suis en train de travailler était la dernière qui pourrait monter en Production. Apporterait-elle de la valeur ?”
Il est bien évident que si j’étais en train de créer une Story technique, elle n‘apporterait aucune valeur si je la montais en Production. Son développement resterait une coquille vide de sens ... et donc de la dette technique.
En revanche, si j’avais déjà prévu une règle même minimale, elle ne répondrait pas totalement à une demande de l’utilisateur final, mais elle répondrait déjà à une partie de son problème.
Prenons un exemple de service de détection client à créer.
La demande du Métier était de vérifier que l’utilisateur final était un client en faisant une recherche sur son nom, prénom, mail, téléphone et sa date de naissance, puis de retourner ses informations personnelles et une liste de ses contrats.
L’équipe sait que la complexité provient de la recherche du téléphone et de la date de naissance. Quand au nom et prénom, la recherche en base de données est plus simple.
Nous avons écrit cette première Userstory qui permettra de :
- Avoir une règle de valeur minimale : Rechercher le nom et le prénom d’un client et lui permettre de poursuivre son parcours client,
- Mettre en place la brique technique de ce service, de tester son fonctionnement et un apport de valeur même s’il ne retourne qu’un code binaire (True/False) lorsque le service ne trouve pas le client.
Comme vous l’avez remarqué, le Métier a accepté le risque d’homonymie pour cette première itération.
Grâce à cette Userstory, nous avons déjà pu :
Vérifier que le service fonctionne et réponde bien,
Permettre au Métier de le tester,
Et surtout apporter de la valeur au plus tôt à l’utilisateur final car, étant reconnu comme “client” :
→ Il pourra déjà bénéficier automatiquement d’une offre spéciale, même si le parcours est frugal,
→ Il n’aura plus besoin de contacter son agent pour faire valoir le droit à cette offre. Ce qui réduira d’autant la charge de travail de son agent.
Puis, dans de prochaines itérations, nous ajouterons une recherche plus élaborée et les informations clients complémentaires.
En résumé
Et si l’on revenait à l’histoire du robinet. En décidant de faire couler un filet d’eau (correspondant à une valeur minimale), vous avez pu tester au plus tôt que votre installation fonctionne et vous avez constaté qu’elle pouvait déjà apporter de la valeur rapidement.
Pour en savoir plus : Comment j’écris un webservice ou une API dans ma Usertory ? | by Silvere Duval | Just-Tech-IT | Medium
