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.
L’autre jour à Marseille dans sa présentation, pour parler des user stories, Thierry a dit des histoires d’utilisation. Tiens, un mélange entre cas d’utilisation et histoires d’utilisateur !
J’avais fait un billet sur les différences entre les deux il y a déjà 2 ans. Depuis, j’ai beaucoup pratiqué les histoires (d’utilisateur), et plus du tout les cas (d’utilisation). Je n’ai vu aucune des équipes que j’ai suivies en faire. Le seul endroit où j’ai vu des cas d’utilisation, c’est dans le guide méthode d’une administration : la pratique y était présentée comme obligatoire sur les projets et expliquée avec des exemples.
Le beurdone montre la décroissance du reste à faire tandis que le burnup montre la croissance de ce qui est fait.
Cet article décrit les courbes qu’on peut produire à partir d’une estimation des stories en points. Il montre les faiblesses du burndown chart et présente des alternatives. Il introduit des notions venant du Lean, comme le diagramme de flux cumulé, le TAF et le DDD.
Histoires d'utilisateur et cas d'utilisation, ce n'est pas la même chose
jc de QualityStreet présente les différences entre les cas d’utilisation et les histoires d’utilisateur. Son étude présente bien ce que sont ces 2 techniques, mais sa comparaison s’inscrit dans le cadre de techniques de spécifications des exigences fonctionnelles. Or les histoires d’utilisateur ne sont pas vraiment une technique de spécification.
Les différences exposées dans son billet entre ces 2 techniques sont donc à replacer à l’aune de cette distinction.
