Le cas des cas d'utilisation

Un lecteur de mon livre m'interpelle à propos des use-cases.

En effet dans le chapitre 13 "De la vision aux stories", après avoir présenté la démarche pour arriver aux stories, j'ai écrit un paragraphe sur les use-cases (qui ne font pas partie de la démarche) pour rappeler qu'ils sont différents des user stories, et moins bien adaptés au développement agile.

Christophe, mon lecteur, argumente pour défendre l'intérêt des use-cases. Coïncidence, j'ai rencontré ces derniers jours des utilisateurs de la technique des use-cases. A chaque fois, c'était dans un contexte d'organisation de type MOA/MOE. Dans ce cadre, mes interlocuteurs (de la MOE) considèrent que les cas d'utilisation (faits par eux, la MOE) ont un intérêt. Soit.

Sur le sujet user story ou use-case, j'ai déjà écrit plusieurs billets :

D'autres arguments fréquemment mis en avant pour justifier les use-cases, comme la traçabilité, le lien avec les tests et une conception orientée objet sont aussi applicables aux user stories, comme on peut le voir dans ce modèle pour un élément du backlog.

Mais, à mon avis l'essentiel n'est pas là. Les méthodes agiles poussent à une remise en question radicale de la façon de faire de la gestion des exigences. Il suffit de relire les quatre premiers principes du manifeste agile[1] pour se convaincre que le traitement des exigences (les stories en langage agile) est fondamentalement différent de ce qu'on trouve encore dans les entreprises qui reposent sur des schémas MOA/MOE[2] ou sont dans des initiatives CMMI trop rigides. Faire des use-cases la technique principale de collecte des exigences, cela pousse à rester dans le cadre de la spécification sous forme de document rédigé à l'avance et ne favorise pas la transition vers le modèle agile de flux et d'interactivité.

Notes

[1] ce que je viens de faire ce week-end, je participe à l'élaboration d'un manifeste agile en français

[2] J'ai déjà dit ce que je pensais de la séparation MOA/MOE

Commentaires

1. Le lundi 10 mai 2010, 09:29 par David

Complètement en phase avec ta conclusion.
Si je devais retenir une seule définition de la User story, ce serait "Promesse de Conversation"
Tout est dit.
A l'opposé des uses cases, les user stories sont volontairement brèves et de haut niveau.
Parfois même on utilise des feutres suffisamment épais pour ne pas être tenter d'en (re)-faire des specs !

2. Le lundi 10 mai 2010, 10:13 par jcQualitystreet

Même si moi aussi j 'avoue avoir une vraie préférence pour les User Stories (enrichie à des fins de spéc. par d'autres élements, type wireframe ergo, cinématique, schémas divers...), une démarche cas d'utilisation n'est pas forcément à jeter à la poubelle.

Bonjour JC, tu m'auras mal lu, je n'ai jamais dit que les use-cases c'était mal. Je dis même dans un billet cité en référence que ça peut servir de contexte aux stories

Menés dans un esprit collaboratif avec juste ce qu'il faut de formalisme, rédigés progressivement, présentés et discutés avec l'équipe, ça peut le faire. Tu parlais d'habitudes, certaines équipes sont à l'aise avec les use cases qu'elles ont appris à maîtriser: pourquoi les faire changer!

http://www.qualitystreet.fr/2009/02...

3. Le mardi 11 mai 2010, 08:26 par Christophe

Claude
Merci d'avoir abordé ce thème sur ton site. Je suis en effet l'auteur de ce très long e-mail qui est en la cause.
Je suis entièrement d'accord avec toi sur les ravages de la séparation MOE/MOA dont j'ai eu à faire l'expérience, en particulier dans le cas de marchés publics.
En ce qui concerne les UC. Je ne crois pas qu'ils soient utiles, ni même à recommander en tant qu'expression de besoins.
Ils restent pour moi un bon outil visant à s'assurer que l'expression de besoin est comprise par ceux qui "font". Leur utilisation dans le contexte de SCRUM est collaborative au sens ou le PO, l'équipe sont assis autour de la même table est ensemble "dépouillent" la/les user stories.
En résumé:
Les UC ne peuvent être une expression de besoin
Ils sont utiles au travail de compréhension de l'équipe de "l'exigence" formulée par un user Stories.
PS / peut être un petit exemple réel aiderait il.

4. Le mercredi 12 mai 2010, 10:59 par David

Je rejoins également la rq de JC :
L'esprit (pas la lettre) des use cases est intéressant pour compléter les user stories. Par ex, toute "note technique" venant apporter des détails écrits. C'est une pratique alternative souvent utilisée dans les faits et qui limite la douloureuse conduite du changement. A préférer si possible la voie des specs exécutables.