Le cas des cas d'utilisation

Un lecteur de mon livre Scrum 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

Voir aussi