Rédiger des cas d'utilisation efficaces

J'ai acheté ce livre juste après la formation Gestion de projet RUP et surtout parce que c'est un livre d'Alistair Cockburn, un des signataires du Manifeste Agile, et avant de me plonger dans le livre de mike Cohn, très prochainement: D'abord le livre est vraiment trop très complet, plein d'exemples: à lire si vous devez écrire des cas d'utilisation. Il survole les 3C d'XP, comme étant un résumé des cas d'utilisation et finalement faisant partie de la vision d'ensemble du projet. On trouve d'autres commentaires sur sa vision des users stories vs use case. On retrouve des problématiques communes avec les user stories, trouver la bonne granularité, la portée des descriptions d'exigences, entre autre. Au passage, les niveaux décrits par Cockburn sont assez intéressants nuage, cerf-volant, mer, poisson: on nage en plein dans la métaphore du niveau de la mer avec laquelle j'ai bien accrochée. Ce qui me bloque avec les cas d'utilisation, et avec RUP pour la même raison, c'est qu'un cas d'utilisation peut recouvrir plusieurs itérations. On est dans un processus itératif non incrémental, à mon sens, bien que tout dépend de l'échelle de temps avec laquelle on mesure ces incréments, lire ici un post d'Alistair sur le sujet, des "nano-incréments" d'XP à l'incrément-release. Cela peut se traduire par exemple par une version simplifiée d'un cas d'utilisation dans une itération et une version complète dans une itération ultérieure. La longévité d'un use case est plus grande qu'une user story ou 3C. Quels bénéfices peut-on attendre d'une approche incrémentale? Il s'agit de livrer à chaque fin d'itération un ensemble de fonctionnalités finies au client, avec une définition partagée de finie pour tous. L'équipe peut s'engager sur le contenu de l'itération à réaliser. Le client peut donner son feed-back puisque l'on peut faire la démo de ces fonctionnalités. Si le client a validé l'incrément, on ne revient plus dessus et il peut repartir avec. Pour l'équipe, ces petites victoires successives donnent du rythme et du courage pour le projet. Pour le product owner, on peut réellement prioriser l'itération suivante puisque rien ne traîne dans le Sprint Backlog. On perd beaucoup de bénefices à mon avis à ne pas être incrémentale (à chaque itération). Trop flemmard pour lire le livre, je vous propose un podcast de Pascal Roques sur les bonnes pratiques autour des cas d'utilisation (sans lien avec le livre). Et pour suivre une discussion en cours sur la documentation agile, c'est ici.