user story

Tout le travail de l’équipe va dans le backlog (car il s’agit d’un backlog d’équipe) et tout travail est story. Cela conduit à avoir des stories pour apprendre et des stories d’investissement.

L’agilité a popularisé la notion de story. On dit aussi user story ou US dans les équipes. Mais si on donne la définition usuelle :

Une story est un petit morceau de fonctionnalité qui apporte de la valeur à quelqu’un et qui est développé en un sprint

cela reste encore abstrait et c’est ce que dit Pierre.

Pour être plus explicite, plutôt qu’élément du backlog de produit, j’utilise story. Le backlog de produit contient donc des stories.

La vie d’une story se déroule de la façon suivante :

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.

Les tests d’acceptation (au sens agile) remplacent une spécification fonctionnelle détaillée. Avec un bénéfice essentiel : la communication est facilitée entre le métier et le développement.

Suite à mon premier billet sur la dette technique nique nique, Olivier nous donne une idée pour la mesurer :

Estimer l’écart de coût d’une histoire utilisateur entre l’instant présent et le début du projet

Essayons. Il nous faut 2 histoires utilisateur de même taille.

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 backlog de produit contient la liste des choses à faire. Pour simplifier appelons ces choses à faire des stories.

Selon l’état de ces stories, on peut identifier 4 grandes parties dans un backlog :

Le retour d’expérience d’Atchik Real-Time présenté au SigmaT9 vendredi a montré que l’équipe s’améliorait continuellement grâce aux rétrospectives. Une amélioration qui a retenu mon attention est celle de la définition de fini.

L’équipe a mis en place une matrice, avec en lignes une liste de contrôles possibles sur les stories et en colonnes les stories sélectionnées pour le sprint courant. Pour chaque story, une croix dans une ligne signifie que le contrôle correspondant est à faire. La matrice est définie par l’équipe en début de sprint.

Après le TDD, voici l’ATDD.