Le backlog contient des éléments, qui ont chacun leur cycle de vie.
Mot-clé - user story
Le cas des cas d'utilisation
10 lundi mai 2010 08:50
Un lecteur de mon livre m'interpelle à propos des use-cases.
Les tests, un moyen d'améliorer la communication
21 dimanche juin 2009 15:59
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.
Les différentes parties du backlog
28 mardi avril 2009 07:53
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. Certes elles ne constituent plus du travail à faire, parce qu'elles sont finies, mais les tests associés sont à repasser pour éviter les régressions.
Notes
[1] dépêchez-vous de répondre à mon sondage sur la durée du sprint
Elément du backlog de produit, le modèle
20 mardi janvier 2009 09:24
A l'occasion d'évolutions dans IceScrum, j'ai remis à jour le (méta) modèle de l'élément de backlog de produit.
Exigences et tests, tests et exigences : un ruban de Möbius
22 mardi avril 2008 07:27
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. L'article Tests and Requirements, Requirements and Tests: A Möbius strip, est signé de Grigori Melnik et de Robert C. Martin, le célèbre Uncle Bob.
La référence au ruban de Möbius illustre comment les 2 disciplines (exigences et tests) en deviennent une seule lorsque le formalisme augmente.
Dans l'article, les exemples sont en FIT qui propose une représentation tabulaire des tests exigences. FIT est bien adapté aux tests sur les données [1].
Je suis convaincu de cette hypothèse d'équivalence. L'écriture de tests d'acceptation est une technique de spécification, d'autant plus pertinente que les tests sont associés à des histoires d'utilisateur. Je l'applique maintenant sur tous les projets auxquels je participe, mais en utilisant le formalisme BDD plutôt que FIT. J'en ai déjà parlé ici et là.
Notes
[1] je vois dans le dernier exemple que FIT permet aussi de spécifier des scénarios d'accès concurrents à une ressource, il va falloir que j'approfondisse l'utilisation du temps dans FIT
Des spikes dans les sprints
15 samedi mars 2008 23:05
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 ?
- Le spike est utilisé quand on ne sait pas estimer une user story. En général, si on ne sait pas l'estimer, c'est qu'on ne connaît pas de solution technique pour cette story.
- Le spike peut aussi être utilisé pour étudier plusieurs solutions différentes. Dans notre produit, nous avons à intégrer des données d'un décisionnel et il y a plusieurs possibilités pour le faire, le spike va permettre de les étudier.
- Enfin le spike peut aussi être utilisé quand la story est très grosse et qu'elle ne peut pas être finie en un seul sprint. Dans notre cas, c'était le cas pour la story portant sur la migration des données de l'ancienne application dans la nouvelle. A noter que si la story n'a pas été décomposée avant, c'est probablement parce que la solution technique n'est pas connue ou mal maîtrisée.
Le spike sert à approfondir le comment (la conception), pas le quoi, qui est du ressort du product owner. Donc si on ne sait pas estimer, il faut savoir si c'est par manque de précisons sur le quoi ou par méconnaissance du comment avant de décider de faire un spike.
Quel est le résultat d'un spike ?
On fait un spike pour comprendre comment développer une story. A la fin du sprint incluant un spike, on devrait :
- avoir défini une solution
- être capable d'estimer le coût de développement, pour aider le product owner à décider quoi faire de cette story.
Il arrive aussi que le spike amène à décomposer la story initiale en plusieurs autres, plus petites.
Quel est le temps consacré à un spike ?
Un spike est normalement limité à une durée fixée (principe du timeboxing) au début du sprint. La pratique recommandée veut qu'on ne passe pas plus d'une journée de travail (8 heures) sur un spike.
Un nom en français pour spike ?
En anglais un spike est une pointe. En français on pourrait dire une pique, qu'en pensez-vous ?
Notes
[1] c'est donc un autre cas où une exigence/story n'est pas finie en une seule itération après le cas de l'utilisabilité dont j'ai parlé récemment
Tests d'acceptation orientés comportement
10 lundi mars 2008 19:18
Voire même Behaviour Driven Development...
Deux entrées dans le backlog pour une exigence d'utilisabilité
10 lundi mars 2008 07:50
Pour les droits des utilisateurs au feed-back
Mesures agiles
11 lundi février 2008 19:45
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 :
- tous les jours, le nombre d'heures restant à faire, ce qui permet de produire le burndown chart de sprint qu'on peut analyser selon sa forme
A la fin d'un sprint :
- le nombre de builds produits pendant le sprint, ce qui permet de savoir si des versions ont été produites, notamment pour les tests
- le nombre de problèmes restant à résoudre, ce qui permet de se faire une idée de leur variation au cours du projet
- la vélocité donc, ce qui permet de calculer la vélocité moyenne qui sert à planifier
- le nombre de points restant à faire d'ici la fin de la release, ce qui permet d'obtenir le burndown chart de release
- le nombre de user stories faites pendant le sprint, le nombre de stories restant dans le backlog et le nombre de stories à estimer ce qui permet d'obtenir des indications même s'il n'y a pas d'estimation en points
- le nombre de points des stories dans les différents états, pour produire les burnups et les courbes de croissance
- le nombre de cas de tests écrits, le nombre de cas de tests passés ce qui permet d'obtenir un Big visible chart
Bientôt tout ça disponible dans IceScrum ?
Le backlog de produit est un outil de communication
03 dimanche février 2008 18:55
On peut essayer la télépathie pour le communiquer efficacement...
Démo IceScrum2 au SigmaT4
16 dimanche décembre 2007 10:20
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.
La revue de sprint
25 dimanche novembre 2007 09:35
Une revue qui permet un feedback concret sur le produit (c'est mieux que sur de la documentation).
Features, themes, epics et stories
04 jeudi octobre 2007 16:20
Comment s'y retrouver ? Que met-on dans le backlog ?
« billets précédents - page 1 de 3
