SPIDR est une méthode intéressante et utile pour diviser plus facilement et plus efficacement les user stories en stories plus light.
“Presque chaque histoire peut être divisée avec l’une des cinq techniques”.
Le coach agile et co-fondateur de la Scrum Alliance, Mike Cohn
SPIDR résume les cinq techniques : SPIKES | PATHS | INTERFACES | DATA | RULES.
Pourquoi le SPIDR ?
Selon le principe INVEST, l’exigence d’une user story est qu’elle doit être « assez petite » ou avoir la bonne taille. Une user story doit être suffisamment petite pour qu’elles puissent être exécutées en un sprint. Bien sûr, cela dépend aussi de la vitesse de l’équipe de développement. Pour atteindre cet objectif en principe, une grande histoire doit être divisée en conséquence.
Il existe maintenant plusieurs techniques qui peuvent être utilisées pour cracher de telles user stories. Par exemple, Richard Lawrence présente une affiche complète qui représente un processus qui devrait aider à décomposer les user stories.
Que représente SPIDR ?
SPIKES :
Spike est un terme utilisé dans le développement de logiciels agiles. Les spikes sont de petites implémentations prototypes de fonctionnalités généralement utilisées pour l’évaluation et la faisabilité des nouvelles technologies.
Cette méthode implique des recherches et la construction de connaissances. On l’utilise si d’autres méthodes SPIDR n’ont pas bien fonctionné. Avec l’aide de ces connaissances fraîchement acquises, certaines stories peuvent alors être mieux comprises et éventuellement décomposées plus facilement. Cette méthode, cependant, est relativement abstraite et donc plus difficile à appliquer que les autres méthodes.
PATHS :
S’il existe plusieurs chemins alternatifs possibles dans une user story, une option consiste à créer des user stories distinctes à partir de certains de ces paths. Il n’est pas absolument nécessaire d’écrire une histoire pour chaque chemin individuel, juste là où cela a du sens. Par exemple, prenons une user story dans laquelle l’utilisateur souhaite pouvoir payer ses achats dans une boutique en ligne. Il existe désormais deux voies possibles : le paiement avec une carte bancaire ou le paiement avec Paypal. Le paiement par carte de crédit peut théoriquement être subdivisé davantage, mais vous devez déterminer s’il est logique que chaque type de carte de crédit ait sa propre histoire. La tâche primordiale de payer les achats est cependant bien décomposée entre les deux alternatives mentionnées. Ainsi, les stories récemment créées sont plus petites et plus faciles à estimer.
INTERFACE :
Les interfaces dans ce contexte peuvent par exemple être différents appareils ou types d’appareils, tels que des smartphones alimentés par iOS ou Android. Les user stories peuvent également être divisées en fonction de cette diversité. Restons sur l’exemple des différents systèmes d’exploitation : dans un projet, par exemple, il peut y avoir des user stories qui concernent exclusivement l’utilisation d’appareils Android, ou d’autres qui se concentrent sur les navigateurs Web. Pour éviter de faire des stories trop volumineuses et complètes, vous devez vous demander quels appareils ou interfaces vous souhaitez développer. Peut-être que le premier résultat de développement ne devrait concerner que les appareils iOS, en raison du groupe cible probablement plus important.
DATA :
Une autre technique de décomposition des user stories peut être utilisée lorsque les stories initiales se réfèrent uniquement à une sous-gamme des données pertinentes. Prenons l’exemple d’un site Web destiné à attirer des touristes dans une ville en particulier. Si c’est une ville connue pour ses musées, la première histoire pourrait inclure des informations sur les différents musées de cette région. Une story ultérieure pourrait inclure diverses visites touristiques à travers la ville et une autre affaire avec des activités de plein air.
RULES :
Les règles commerciales ou les normes technologiques peuvent être un autre facteur de division. Prenons l’exemple de l’achat en ligne de billets de cinéma. Il existe souvent des contraintes qui sont par exemple basées sur les exigences commerciales du cinéma concerné, telles qu’une limite d’achat en ligne d’un maximum de cinq billets par adresse e-mail.
Avec cette story, il serait concevable que l’équipe de développement omette cette restriction, permettant à chaque visiteur d’acheter autant de billets qu’il le souhaite. La restriction pourrait alors être ajoutée dans une deuxième étape d’itération. Une livraison incrémentielle telle que celle-ci signifie que les histoires initiales ne sont pas immédiatement mises en œuvre complètement, mais sont livrées en plusieurs étapes plus petites.
Avez-vous essayé cette technique pour décomposer les user stories ? Parlez-nous de vos expériences.
MORE YOU KNOW, MORE YOU GROW :
Retrouvez-nous sur LinkedIn.
Nous vous invitons à découvrir autres sujets intéressants :
