user story

Des exemples de story

Des exemples de story

Marie et Bob racontent à Pierre une story qui les concerne dans PermaBio

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.

Glossaire T-V

Voici la dernière partie du glossaire que j’ai ajouté à l’édition 4 de mon livre Scrum : Tâche : travail contribuant à une story, n’apporte pas de valeur par lui-même. Taille (de story ou feature) : attribut estimé (en points) indiquant quelle part de backlog sera réalisée. User story : story qui apporte de la valeur à une ou plusieurs parties prenantes qui utilisent le produit. Tableau de sprint : sert à montrer l’avancement des travaux pendant le sprint, c’est une représentation physique du plan de sprint.
Backlog et workflow des stories

Backlog et workflow des stories

Le backlog contient des éléments, qui ont chacun leur cycle de vie

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 : un jour, elle est suggérée par quelqu’un qui a une idée le Product Owner, qui est finalement le responsable du contenu du produit, examine les stories suggérées et les acccepte -ou pas- pour qu’elles soient développées et ajoutées au produit Une fois acceptées, les stories sont estimées par l’équipe qui évalue l’effort de développement nécessaire Les stories peuvent alors être planifiées, c’est à dire associées aux sprints dans lesquels on prévoit de les réaliser Lorsqu’arrive le sprint, les stories qui y sont associées deviennent “en cours” Et si tout se passe bien, elles seront finies à la fin du sprint.

Le cas des cas d'utilisation

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. Christophe, mon lecteur, argumente pour défendre l’intérêt des use-cases. Coïncidence, j’ai rencontré ces derniers jours des utilisateurs de la technique des use-cases.

Les tests, un moyen d'améliorer la communication

Au lieu de test d'acceptation, spécification par l'exemple serait probablement plus approprié

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. Vendredi dernier, à la conférence agile de Toulouse, il y avait un retour d’expérience sur les tests dans un projet agile. Il y a été question essentiellement des tests d’acceptation. Et de pilotage par les tests d’acceptation (ATDD). D’abord une précision : le terme acceptation ne doit pas être compris comme dans acceptance test ou UAT, phase à la fin d’un projet pour obtenir la signature du client, comme confirmation qu’il accepte le produit livré.

Symptômes de la dette technique

Dette technique serait-ce le nouveau nom de la (non) qualité ?

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. Par exemple lors d’une séance de Planning Poker, deux histoires qui ont été estimées toutes les 2 à n points. L’estimation a eu lieu au début du projet.

Use-case et user story

Un use-case, des user stories ?

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.

Les différentes parties du backlog

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 : les stories en cours de réalisation dans le sprint[1] courant les stories planifiées dans les sprints suivants. Elles constituent le plan de release. les stories à prioriser (et estimer) pour pouvoir les planifier. et puis les stories finies dans les sprints passés.

Matrice de finition de story

Variation sur la pratique Définition de fini

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.
Pilotage par les tests d'acceptation

Pilotage par les tests d'acceptation

Méta-modèle

Après le TDD, voici l’ATDD. Dans l’épisode précédent, nous avions vu qu’une story était un élément du backlog de produit. Un principe, dans toutes les méthodes agiles, est qu’une story soit réalisée en une itération. Mais comment savoir si elle est vraiment finie à la fin de l’itération ? C’est la responsabilité du product owner d’accepter ou pas une story. Pour cela, le moins qu’il puisse faire est de définir ses conditions de satisfaction.
Elément du backlog de produit, le modèle

Elément du backlog de produit, le modèle

Un méta modèle !

A l’occasion d’évolutions dans IceScrum, j’ai remis à jour le (méta) modèle de l’élément de backlog de produit. Le backlog de produit contient des éléments. Un élément de backlog est généralement qualifié de story. Mais ce n’est pas si simple. A partir des idées de ce billet, j’ai modélisé la typologie qu’on retrouve dans Icescrum : Un élément peut aussi être une feature, avant sa décomposition en stories. Une user story correspond à un type de story qui apporte de la valeur directe aux utilisateurs.

Un scénario enchaîne des petites histoires

De l'intérêt d'une *big picture*

La technique des “user stories” est très efficace couplée à un développement par itérations. Les stories alimentent le backlog de produit et sont développées pendant l’itération. La tendance est à avoir des stories très petites, ce qui présente des avantages en terme de gestion et de suivi. Mais cela a l’inconvénient de rendre les choses plus difficiles à comprendre. Une story est à replacer dans un contexte plus large pour qu’on voit à quoi elle sert.

Des spikes dans les sprints

Le spike sert à approfondir le comment

Mercredi, lors de la réunion de planification du sprint que j’animais, nous avons inclus dans le sprint plusieurs spikes. On utilise un spike pour mener des travaux d’étude, d’exploration technique d’un élément (user story) du backlog. Cela revient à décomposer cet élément en 2 parties[1] : le spike proprement dit, qui est fait au sprint n le développement de l’élément qui sera inclus dans le sprint n+1 (ou pas selon les résultats du spike) Quand l’utiliser ?

Tests d'acceptation orientés comportement

Voire même Behaviour Driven Development

Un test, c’est une expérimentation menée pour révéler des informations, ou en réponse à une question précise sur un logiciel ou un système. Dans le cadre d’une approche agile basée sur les histoires d’utilisateur (user stories), un test d’acceptation est un test qui permet au client (ou au Product Owner) de dire s’il accepte, en fin d’itération, une histoire d’utilisateur développée par l’équipe. Un test est accroché à une story, qui en possède généralement plusieurs.

Deux entrées dans le backlog pour une exigence d'utilisabilité

Pour les droits des utilisateurs au feed-back

Dans les applications Web, il existe souvent un rôle secondaire qui a accès à des informations seulement en lecture et qui a besoin d’une ergonomie particulière, soit parce que les personnes qui jouent le rôle ne sont pas expertes dans l’utilisation de l’outil informatique, soit parce que les informations doivent constituer un tableau de bord facilement lisible et permettre d’avoir une vue synthétique. L’ergonomie est essentielle et fait que ces exigences ne sont pas des histoires comme les autres.