Pourquoi j'utilise toujours les cas d'utilisation : le point de vue d'Alistair Cockburn...

Pour ceux qui l'ignorent Alistair Cockburn est une vraie pointure, l'auteur de l'ouvrage de référence "Rédiger des cas d'utilisation efficaces" (la bible des use cases).

Soyons clair, Alistair Cockburn, dans son article, se déclare fermement contre les user stories, et défend avec force ce qu'il a toujours défendu : les cas d'utilisation ("use cases").
Soyons clair, je trouve que son article manque d'objectivité mais qu'il a le mérite d'enrichir notre débat "use cases ou user stories" ...

Alistair Cockburn considère qu'utiliser les user stories est source de trois gros problèmes :

• User stories ne donnent pas suffisamment de contexte
  
• User stories (et backlog) ne procurent pas à l'équipe un sentiment de complétude, d'achèvement
  
• User stories ne prévoient pas de mécanisme pour se projeter en avant, penser au travail à venir
  

Tout cela me semble très exagéré...
Rappelons tout de même que les user stories sont discutées (l'un des 3 C, "Conversation"), et estimées par l'équipe. Soulignons aussi qu'elles n'arrivent pas toutes seules et sont accompagnées de personas, storyboard, bref du travail de l'ergonome ce qui va faciliter grandement leur mise en contexte.
De plus, la grande force des méthodes agiles est de mesurer l'avancement du projet en fonctionnalités livrées (et non de documentation): le degré d'achèvement se révèle donc au final selon moi beaucoup plus concret.
Certes, l'art de se projeter en avant n'est pas inscrit dans user stories, et encore, car nous pourrions rappeler à Alistair, que les user stories envisagent d'entrée les éléments à tester en priorité (l'un des 3 C: Confirmation). Mais ce qui concerne le travail à venir se retrouve dans d'autres outils Agiles : le burndown chart, la backlog de produit, le radiateur d'informations, la pratique du SCRUM ...

Alistair Cockburn revient ensuite sur l'intérêt du contenu des cas d'utilisation pour une équipe projet et pour un client: le résumé, le scénario principal, les extensions, le niveau de détail; des arguments qui tiennent la route et dont je suis convaincu pour certains contextes. Mais des éléments (hormis le niveau de détail de l'artefact) qu'on retrouve dans une approche agile bien menée qui se sert des user stories et qui intégre une démarche ergonomique de qualité.

Enfin, Alistair Cockburn nous propose quelques conseils pour ceux qui utilisent les cas d'utilisation (car tout n'est pas si simple au royaume des use cases). Des conseils exploitables et préconisés dans une perspective Agile :

• Avoir une démarche de construction progressive
  
• Décomposer les use cases (pourquoi pas en user stories: la réconciliation est là) pour faciliter leur mise en oeuvre. Un cas d'utilisation entier ne peut pas toujours être implémenté dans une courte itération de 2 ou 3 semaines
  
• Écrire de bons cas d'utilisation nécessite de réfléchir, d'analyser, de communiquer, d'analyser ... bref nécessite un vrai travail de fond auquel il faut être préparé
  

Sur ces trois points, on est vraiment en phase ! D'ailleurs, ce sont les messages que j'essaie de faire passer quand il est question des cas d'utilisation et que j'évangélise sur le Processus Unifié et sur la mise en oeuvre des méthodes Agiles.

Personnellement, j'aime bien sa conclusion :

"I'm (not really) sorry if you don't want to think – find a new profession"

La mienne sera moins polémique, (question de style) : dans certains contextes, les user stories, peuvent s'avérer beaucoup plus appropriées que les use cases. Et sur d'autres projets, on aura vraiment besoin d'une approche par cas d'utilisation.
En somme, "It depends...": une vraie réponse d'ergonome ! Et vous, quel est votre point de vue ?