En ce moment, je coache un PO dont c'est le premier projet agile, et même le premier projet informatique. On peut dire que c'est un dépucelage pour lui, et pour l'instant, il est ravi ;-) J'adore ça, parce qu'il amène beaucoup de fraîcheur dans mes réflexions sur l'agilité.
Il m'a récemment montré un avantage de la spécification par les tests que je n'avais pas encore perçu.
J'étais en train de relire une user story qu'il avait écrite. Il s'agissait de gérer un élément d'information simple, en texte libre. Je lui fais remarquer qu'il n'a prévu que les fonctions d'ajout et de suppression, mais pas de modification. Sa réponse m'a amusée et m'a fait réfléchir : "Ah oui, c'est vrai, tiens... Mais ça veut dire qu'il faut que j'écrive la règle de gestion et les tests qui vont avec ??? Franchement, on peut s'en passer, de la modification. Si on veut modifier, on supprimera puis on ajoutera !".
Il faut dire que mon PO sera un utilisateur de l'application que nous développons, donc il connaît parfaitement le fonctionnel et il est bien conscient que les autres utilisateurs se tourneront vers lui s'ils estiment que le logiciel n'est pas assez pratique. J'en déduis donc que cette fonctionnalité n'est réellement pas prioritaire. Hop, affaire réglée :-)
Conclusion : en faisant écrire les tests d'acceptance au PO, on lui donne un moyen très concret d'appréhender la complexité d'une user story, et du coup, il est bien plus aisé pour lui d'évaluer le ROI d'une user story. Il y a du lean là-dedans, il me semble...
Il m'a récemment montré un avantage de la spécification par les tests que je n'avais pas encore perçu.
J'étais en train de relire une user story qu'il avait écrite. Il s'agissait de gérer un élément d'information simple, en texte libre. Je lui fais remarquer qu'il n'a prévu que les fonctions d'ajout et de suppression, mais pas de modification. Sa réponse m'a amusée et m'a fait réfléchir : "Ah oui, c'est vrai, tiens... Mais ça veut dire qu'il faut que j'écrive la règle de gestion et les tests qui vont avec ??? Franchement, on peut s'en passer, de la modification. Si on veut modifier, on supprimera puis on ajoutera !".
Il faut dire que mon PO sera un utilisateur de l'application que nous développons, donc il connaît parfaitement le fonctionnel et il est bien conscient que les autres utilisateurs se tourneront vers lui s'ils estiment que le logiciel n'est pas assez pratique. J'en déduis donc que cette fonctionnalité n'est réellement pas prioritaire. Hop, affaire réglée :-)
Conclusion : en faisant écrire les tests d'acceptance au PO, on lui donne un moyen très concret d'appréhender la complexité d'une user story, et du coup, il est bien plus aisé pour lui d'évaluer le ROI d'une user story. Il y a du lean là-dedans, il me semble...
Aucun commentaire:
Enregistrer un commentaire