Tout le travail de l'équipe va dans le backlog (car il s'agit d'un backlog d'équipe) et tout travail est story.
Une story est un élément du backlog, morceau de fonctionnalité qui apporte de la valeur à quelqu’un. Avec cette définition, tout est story dans le backlog. À côté des stories qui apportent de la valeur aux utilisateurs (user story), cela conduit à avoir des stories pour apprendre et des stories d’investissement.
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.
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 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.
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.
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.
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.
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.
Trouvé via le blog de Karl, un article publié dans le très sérieux magazine IEEE Software qui fait l’hypothèse d’une équivalence entre les tests et les exigences.
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.
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.
Pour décrire les tests d’acceptation, ma préférence va à une technique orientée comportement, le BDD.
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.
La mesure la plus connue dans les méthodes agiles est probablement la vélocité. Mais il y a d’autres mesures simples à faire lors d’un développement agile permettant d’obtenir des indicateurs et des courbes (burndown charts, courbes diverses).
Au cours de chaque sprint, on peut mesurer :
On peut essayer la télépathie pour le communiquer efficacement…
Le backlog de produit recueille pas mal de choses éparpillées d’habitude dans plein de documents différents. On y trouve :
une liste des User Stories, ce qui correspond -au moins en partie- à ce qu’on trouve dans un document de spécifications fonctionnelles un rangement par priorité, ce qui, couplé à des estimations en points, permet d’obtenir un planning de la release éventuellement, les tests associés aux stories
Un backlog de produit peut se concrétiser sous différentes formes. Dans les différents projets auxquels j’ai participé, j’ai utilisé :
des fiches bristol épinglées sur un tableau une feuille de calcul d’un tableur OpenOffice ou Excel une feuille de calcul partagée avec GoogleDocs, ce qui est déjà beaucoup mieux qu’un simple tableur un outil dédié, IceScrum bien sûr, ce qui est encore mieux
Le manifeste agile rappelle que les personnes et leurs interactions sont plus importantes que les processus et les outils. Faire un outil qui reste dans cet esprit tout en assistant utilement lors de l’application d’une méthode agile, ce n’est pas facile. Le pari a l’air réussi pour la nouvelle version d’IceScrum.
