{"partition": "head_middle", "source_domain": "www.aubryconseil.com", "digest": "sha1:XFNGJITNQZRTW3ACOMFKX6P37Q4O2SIO", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2016-26/000_00031.parquet"}
Scrum, Agilité et Rock'n roll
Scrum, Agilité, Rock'n Roll
IceScrum
Mes conseils
use-case
user story
Lors des derniers projets auxquels j'ai participé ou que j'ai coachés, les exigences ont été définies par des "user stories".
J'ai depuis longtemps utilisé, et intensivement, les cas d'utilisation. J'ai pratiqué et recommandé le développement par itérations guidé par les cas d'utilisation(use case driven). Je trouve toujours que c'est une technique intéressante pour spécifier (bien qu'elle soit souvent mal utilisée). Cependant elle ne permet pas, à elle seule, de bien gérer le contenu des itérations. En effet, un bon cas d'utilisation contient plusieurs "scénarios". Généralement on commence par décrire le scénario de succès le plus usuel, puis on identifie les scénarios alternatifs.
Lorsqu'il s'agit de planifier une itération, la pratique habituelle des projets que j'ai suivis depuis des années est de sélectionner un ou plusieurs cas d'utilisation. La réalité est que, dans la grande majorité des cas, les équipes n'ont pas réalisé tout le cas d'utilisation à la fin de l'itération, mais seulement un scénario, dans le meilleur des cas. Sans avoir déroulé des tests fonctionnels sur ce scénario. Il devient alors difficile de connaitre l'avancement avec des exigences partiellement réalisées.
Une User Story (non, je ne suis pas -encore- prêt à dire des histoires des utilisateurs, mais je suis ouvert à des propositions pour défendre le français) est de taille plus réduite qu'un cas d'utilisation. Je ne vais pas présenter ici cette technique issue de XP, mais seulement montrer comment elle permet de mieux maitriser l'avancement dans un projet.
Une story est une exigence (plus exactement, avec Scrum, une story est un item du Backlog de produit). La règle simple est qu'une exigence doit être réalisée (et testée, c'est fondamental) dans une seule itération. A la fin de l'itération, l'équipe fait une démo de ce qu'elle a vraiment réalisé. On peut ainsi connaitre les exigences (user stories) qui sont finies. Cela, couplé à l'estimation agile que j'aborderai dans un prochain billet, permet d'avoir une bonne idée de l'avancement du projet.
Et ça marche.
Le mardi 18 avril 2006, 19:28 par UmlGuru
J'ai un peu l'impression quand même qu'on en revient là aux exigences textuelles élémentaires avec l'inconvénient qu'elles sont tellement "petites" qu'on ne peut pas les tester individuellement. Pour moi, le gros avantage du concept de cas d'utilisation, c'est justement le fait qu'il raconte une histoire, du début à la fin, et est donc testable ! Je suis d'accord que c'est la notion de scénario qui est plus appropriée pour la planification du contenu technique des itérations, mais revenir aux vieux Requirements comme le montre Ambler me paraît bien dangereux ...
Claude : Non, il n'y a pas ce risque, une des caractéristiques primordiales d'une User story est d'être testable (les autres sont Indépendent, Valuable, Estimable, Small, ce qui fait le slogan INVEST). D'ailleurs on la teste lors de l'itération où on la réalise. Et donc on y spécifie aussi ses tests de recette (acceptance test). Elle n'existe que si elle apporte de la valeur à un utilisateur. Comme son nom le laisse deviner elle raconte aussi une histoire. Quant à la différence/similitude avec les cas d'utilisation, je la développerai dans un prochain billet. Chez un des mes clients, on a fait d'abord des cas d'utilisation puis on est passé (facilement) aux User stories (pour la planification des itérations).
Billets récentsMes sériesCommentaires sur mon livreArchivesFormulaire de contact
L'esprit du blog
http://www.aubryconseil.com/blog/themes/aubry/assets/images/diaporama/scrum.png
http://www.aubryconseil.com/blog/themes/aubry/assets/images/diaporama/cat.png
http://www.aubryconseil.com/blog/themes/aubry/assets/images/diaporama/rock.png
Tweets de @claudeaubry
Derniers billetsLes 6 activités de l'affinage du backlogPlanifier la releaseSigmaT -> klubLa série La Voix du Coach sur InfoQContextualiser ScrumÉquipes features façon puzzleSprints synchronisés façon puzzleScrum éparpillé façon puzzleRaid Agile de printemps
SériesAffinage du backlogAnniversaireCompléments édition 4Compléments en ligne du livre ScrumLe quiz ScrumSociocratie et AgilitéToutes les séries
LiensLe Raid Agile
Agile Toulouse
Fédération Agile
Traducteurs Agiles
Billets sélectionnés La vie d'une story Décider qu'une story est prête Les événements du sprint L’Agilité en mouvement D'autres pratiques Scrum obsolètes Affinage de bac en bac #noBonnesPratiques Manifeste pour le développement de systèmes Limiter le bac de sprint Justification de l'intérêt des méthodes agiles Les bénéfices du développement agile CatégoriesScrumMes livresPratiques AgilesMes projetsMes événementsMes formationsMes conseilsMon blogL'agilité à ToulouseL'agilité en FranceL'agilité dans le mondeL'agilité en dehors du logicielMes lecturesMes jeuxMes communautés
Rechercher Top
Le blog de Claude Aubry est propulsé par DotClear
Le thème a été développé par ooCube