User story, si simple et si difficile

DevOps & Agilité Jeudi 10 juin 2010 Pas de commentaire

Au cours d’un audit sur un projet agile, un chef de produit m’interpelle.

« J’ai un problème pour maintenir à jour la documentation des règles métier. Je dois régulièrement passer en revue l’intégralité des spécifications fonctionnelles pour mettre à jour les règles métiers détaillées contenues à l’intérieur. Le document montre à un instant donné l’état des règles métiers, mais je n’ai aucun moyen de savoir quelles règles métier ont évolués entre chaque expression du besoin. »

Je l’interroge sur son usage des user stories. Il me répond.

« En fait, chaque fois que le besoin fonctionnel évolue, je modifie les règles métiers associées à mes user stories. »

« Si je comprends bien, chaque fois que le besoin change, vous ne créez pas forcément de nouvelles user stories, et il vous arrive fréquemment de modifier des user stories déjà developpées. Elles ont donc tendance à grossir, et à devenir moins lisibles. De plus, vous n’avez aucune trace des évolutions successives du besoin. »

« Oui, c’est bien ça. Mais, que peut on faire ? »

Mais qu’est-ce qu’une user story pour vous ?

Grand blanc. Je relance la conversation.

Mais vous savez, une user story doit normalement tenir sur une carte. Elle délimite un besoin sans en définir complètement le contenu. Les règles métiers sont définies par les cas de test, sous forme d’exemples. Si le besoin change ou un besoin nouveau apparait, on crée une nouvelle user story.

Finalement, les user stories matérialisent l’évolution du besoin.

Oui. Et vous pouvez regrouper les user stories par thèmes pour conserver un vision globale, et ainsi définir une trajectoire pour votre produit.

On ne m’a jamais appris ça. Je me rend compte que j’ai dépensé beaucoup d’énergie à maintenir le document, et que j’ai oublié de définir une trajectoire pour la construction de mon produit.

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn