Drupal et Scrum depuis les tranchées - La sprint définition

Vous avez pu lire dans le billet précedent comment passer de la vision aux stories. Voyons maintenant comment gérer ce qu'il va se passer au démarrage du premier sprint et de tous ceux qui suivront : la sprint définition.

Pour les plus pressés d'entre vous qui ne veulent pas profiter du fun de l'article, direction le TL;DR.

A quoi sert la sprint définition ?

Le but de l'exercice est que l'équipe constitue la liste de ce qu'elle va avoir à faire au cours du sprint. Pour cela, le product owner passe en revue la liste des stories du backlog produit de la plus prioritaire à la moins prioritaire. Pour chaque story, l'équipe va passer en revue les critères d'acceptation et identifier les taches qui en découlent. L'exercice va donner lieu à des échanges entre le product owner et les membres de l'équipe, et cette dernière va débattre de la faisabilité technique, des pistes possibles pour réaliser le besoin.
Ayez toujours à l'esprit les capacités de Drupal dans vos échanges car la maîtrise de l'outil vous épargnera de gaspiller votre temps en développements futiles.
La sprint définition est le moment durant lequel l'équipe doit comprendre chaque pixel du projet. Toutes les questions doivent être posées au cours de ce rituel car ça n'est pas une fois que l'implémentation démarrera qu'il faudra qu'elle se demande à quoi servent certains boutons / portions d'une page.

Les choix d'implémentation

Lorsque les stories sont passées en revue, l'équipe a le droit de rajouter des stories techniques, de débattre des priorités si elle pense que certaines choses doivent se faire avant d'autres. L'une des forces de l'agilité étant le principe d'itérations, le groupe est fortement invité à proposer toutes les pistes qui lui viendront à l'esprit afin de produire le plus de valeur ajoutée en un minimum de temps. L'écosystème des modules Drupal est très bon à ce petit jeu là, nous ne pouvons que vous encourager à vous en servir afin de proposer au product owner plusieurs options et de lui expliquer clairement ce qui serait faisable / non faisable comparé à sa demande initiale. Le but étant de toujours aller au plus vite à un premier résultat pas toujours parfait mais qui fait le travail et en se donnant la possbilité de choisir par la suite si le résultat constaté est satisfaisant ou si du temps supplémentaire doit être investi pour l'affiner.

Dimensionner les stories

Une fois que l'équipe n'a plus de questions sur le périmètre de la story fonctionnelle et qu'elle pense avoir son plan de bataille pour l'implémentation (pas besoin de noter tous les détails, vous pouvez vous limiter aux options / pistes possibles pour le développement) le jeu du poker planning démarre. Que vos espoirs de devenir millionnaire en jouant aux cartes dans des saloons retombent car il n'en est rien :  le concept est le suivant, tous les équipiers relisent les taches listées et réfléchissent à une taille à donner à cette story.
On ne va pas mesurer le temps que cela prend de faire la réalisation (un junior et un senior ne prendraient probablement pas autant de temps) mais on va estimer l'effort que cela implique. Pour se faire, on utilise une unité abstraite, les points de complexité.
Pour éviter les dilemmes on s'inspire de la suite de Fibonnacci, ce qui donne la liste de valeurs possibles suivante : 1, 2, 3, 5, 8, 13 puis on lui ajoute les valeurs 20, 40, 100, ? et "PAUSE" pour permettre à chacun d'indiquer que quelque chose est très gros, impossible à mesurer au vue de ses connaissances ou qu'il a besoin d'une pause avant d'y arriver.

Lorsque vous allez choisir la complexité d'une story, sa valeur absolue a peu d'importance. Ce qui va compter c'est que ce que vous allez estimer à 5 représente toujours la même chose. La story la plus difficile à estimer reste la première car on travail par la suite par comparaison. "Cette story pour laquelle nous votons 3 est-elle vraiment aussi complexe que la #651 pour laquelle on avait déjà voté 3 et qui nécessitait une gestion des droits fines en plus ?".
De la même façon l'effort doit être pris en compte. Si on évalue par exemple la création d'un type de contenu à 1, si l'un d'entre eux a 70 champs, peut être allons nous évaluer l'effort à 2 ou 3.

Partager les points de vue

L'estimation de la taille des stories se fait en simultané pour chacun des coéquipiers, tous ont devant eux un jeu de cartes d'estimations (d'où le nom de planning poker) et l'abattage des estimations doit se faire au même moment une fois que tout le monde a pris le temps de trouver son estimation (et poser les dernières questions si nécessaire). L'abattage révèle souvent des surprises (et des fous rires !) et suscite des échanges. "Pourquoi as-tu voté 2 ? C'est super compliqué de faire la couche d'abstraction, rappelles toi du projet Superfish !", "Wow, 5, vraiment ? On utilise Views Megarow et c'est parti, ça nous prendra peu de temps de construire cette interface".
Les points de vue seront donc confrontés, permettant de faire émerger des choses compliquées dont tout le monde n'avait pas conscience ou en apportant de la réassurance via la découverte de techniques / savoir-faire acquis par le passé et oubliés par certains.
Lorsque les votes sont vraiment différents (2 VS 8 par exemple) il y a une période d'échanges pour comprendre la source d'un tel écart, puis l'équipe revote jusqu'à ce que les estimations soient proches (et on prendra toujours la plus pessimiste par principe). Il est important de noter que passée une certaine taille, la faisabilité d'une story devient un risque. Si la complexité de plusieurs stories est supérieure ou égale à 8 il faut probablement envisager de découper les stories en plusieurs stories de taille inférieure afin de toujours s'assurer que vous livrez quelque chose. Si les estimations chiffrées posent problème, vous pouvez changer d'unité, XS, S, M, L, XL, XXL etc (ou libre à vous d'inventer la votre)

Une fois qu'une story est dimensionnée elle rejoint le backlog de sprint et on passe à la suivante. L'exercice se répète jusqu'à ce que l'équipe estime avoir suffisamment de travail pour la durée du sprint. Et ce choix est très important, en effet, l'équipe s'engage à livrer tout ce qu'elle a intégré à son backlog de sprint. Si des choses ne sont pas terminées à la fin de l'itération il faudra en trouver la cause pour que ça ne se reproduise pas. C'est donc une promesse faite, vis à vis du product owner mais aussi vis à vis de soi même. La capacité de l'équipe à respecter ses engagements déterminera sa vélocité. Le fait de livrer toutes les 2 semaines rend le projet excitant car on mesure les progrès d'un sprint à l'autre.

Vous l'aurez compris, les journées de sprint définition sont des journées qui sont bien remplies, alors préparez-vous en ramenant le jus de fruit, les croissants et des barres de céréales et en faisant une bonne nuit de sommeil la veille. Gardez l'exercice fun, veillez à ce que tout le monde donne sont avis et votre sprint se déroulera bien.

TL;DR

• Au cours de la sprint définition l'équipe s'approprie le projet / la vision
• C'est pendant la sprint définition que les questions se posent, une fois passée il est trop tard et on rentre dans l'implémentation
• L'univers contrib de Drupal permet de faire beaucoup de choses pour un faible investissement
• Profitez des itérations pour proposer une base fonctionnelle non parfaite mais satisfaisante puis demandez-vous s'il faut aller plus loin
• Utilisez le planning poker pour quantifier l'effort nécessaire à la réalisation des stories
• Apprenez à estimer par comparaison
• Echangez afin de vous assurer que vous êtes tous sur la même longueur d'onde
• Respectez vos engagements lorsque vous constituez votre backlog de sprint
• Multipliez les petites stories plutôt que d'en avoir de très grosses.
• Assurez-vous de toujours livrer quelque chose.