Spikes

Objectif

L'Agile Extension au guide BABOK fixe au spike cet objet: borner dans le temps une activité de recherche, de conception, d'exploration, d'investigation ou de prototypage afin de comprendre l'effort que demande la livraison d'un élément de backlog ou d'une initiative. Le déclencheur est nommé par le guide: un élément ou une initiative qu'il est impossible d'estimer.

Son produit est une connaissance: une estimation devenue possible, une réponse de faisabilité, une décision de conception, deux approches comparées sur pièces. L'Agile Extension écarte l'incrément livrable de ce qu'un spike produit. Le code écrit pendant un spike répond à la question posée et s'arrête là.

Cette limite le situe face aux deux séances qui encadrent l'itération: la rétrospective examine la façon de travailler de l'équipe, quand le spike examine un élément de travail inachevé. La revue d'itération montre à des parties prenantes un incrément terminé; le spike n'en produit aucun et sa réponse se consomme entre l'équipe et le responsable de produit, pendant l'affinement du backlog ou la planification.

Le tableau 7.0.1 de l'Agile Extension range le spike parmi les techniques de gestion des exigences et le place du côté des équipes internes, sans entrée pour les parties prenantes extérieures. Le produit explique ce placement: une réponse technique ou organisationnelle destinée à ceux qui feront le travail.

Usage

Quand l'utiliser

• Élément que l'estimation relative ne tranche pas: l'écart des avis tient à une inconnue qu'aucune discussion ne lève.
• Interface, bibliothèque ou plateforme jamais intégrée: un prototype technique répond en heures ce qu'une discussion laisse ouvert.
• User story trop grosse pour être découpée à vue: un spike fonctionnel localise le risque et les points de découpe.
• Risque organisationnel avant d'engager une initiative: un spike exploratoire mesure l'impact sur les processus, les rôles et la conformité.
• Plusieurs approches ou outils en concurrence: comparer sur pièces coûte moins qu'un choix défendu de mémoire.
• Équipe qui se forme: l'Agile Extension range parmi ses forces la connaissance mutuelle et technique qu'un spike précoce fait naître.

Quand ne pas l'utiliser

• Question qu'un appel réglerait: interroger l'architecte ou le fournisseur, puis estimer.
• Résultat destiné à la production: l'issue est connue, c'est un élément de backlog ordinaire qui se planifie et se livre.
• Recours à chaque itération: corriger l'affinement du backlog.

Description

Les deux éléments

L'Agile Extension donne à la technique deux éléments: le but et le type. Le but est un résultat défini qui dit à quel moment la recherche est terminée, et le praticien en analyse d'affaires fixe la durée du spike (time-box dans le texte du guide) à l'intérieur d'une itération. Un but s'écrit comme une question dont la réponse se vérifie: « la bibliothèque X couvre-t-elle le format Y sur nos volumes? » se ferme, « étudier les options d'intégration » ne se ferme jamais.

Conduire un spike

Le spike se porte au backlog comme un élément à part, avec son but et sa durée visibles, et il se planifie dans une itération au même titre que le reste. Une ou deux personnes le mènent. Mike Cohn chiffre le spike lui-même en heures (4, 40 ou 400 selon l'enjeu) et le réserve aux incertitudes extrêmes. Une difficulté d'estimation ordinaire se règle en affinant l'élément.

La durée expire, que la question soit résolue ou non. Un spike qui rend « pas de réponse en seize heures » a produit un résultat: l'élément est plus risqué que l'équipe le croyait, et la décision de continuer revient au responsable de produit. La réponse est rapportée pendant l'affinement ou la planification, l'élément est réestimé, puis le spike se referme.

Ce qui fait échouer un spike

La durée trop longue ou l'élément trop gros

L'Agile Extension nomme cette limite: une durée trop large ou un élément trop volumineux privent le spike d'objectifs et de résultat clairs. Deux semaines de recherche sur « la migration » rendent un rapport que personne ne convertit en estimation. Si la question ne se pose pas en une phrase vérifiable, l'élément est encore trop gros et se découpe avant tout spike.

Le mot posé sur une conversation de suivi

Le guide relève que le terme désigne à tort des conversations de suivi. « On fait un spike là-dessus » devient la formule qui reporte une décision d'une itération à l'autre. Un spike a un but écrit, une durée et une personne qui le mène; ce qui n'a pas ces trois attributs est une tâche, une question ou un report.

Le prototype expédié en production

Kent Beck, qui a nommé la spike solution, la décrit comme un programme minimal construit pour répondre à une question de conception puis abandonné. Le code d'un spike est écrit vite, sans tests ni gestion d'erreur, parce que la question posée ne les demande pas. Livré tel quel sous la pression d'une échéance, il devient une dette dont l'origine est oubliée en deux itérations. La réponse du spike se garde; son code se jette.

Le spike de toutes les itérations

Un recours fréquent signale, selon l'Agile Extension, un affinement du backlog qui ne répond pas aux besoins de l'équipe. Les éléments arrivent en planification sans que personne ait cherché ce qu'ils supposent. La correction porte sur l'affinement: plafonner le nombre de spikes autorisés laisse la cause en place et fragilise les estimations.

Considérations IA

Un modèle de langage abrège la partie documentaire d'un spike technique: il recense les bibliothèques qui traitent un format, résume une spécification de plusieurs centaines de pages autour de la question posée, produit en quelques minutes le squelette du prototype jetable. Il aide aussi à écrire le but: soumettre une formulation et demander à quelle condition on saurait qu'elle est atteinte fait apparaître les buts qui ne se ferment pas.

Le spike existe pour produire une preuve sur la pile technique de l'équipe, avec ses versions, ses volumes et ses données; un modèle décrit une bibliothèque telle qu'elle était dans ses données d'entraînement, et il invente des options d'interface avec le même aplomb qu'il en cite de réelles. La réponse compte quand le code a tourné chez l'équipe. L'estimation qui suit reste celle de l'équipe qui livrera.

Un spike manipule souvent ce que l'organisation a de plus sensible: du code interne, des schémas d'interface, parfois des données de production tirées pour reproduire un cas. Ce matériel ne part pas vers un service externe sans que l'usage soit couvert; la loi fédérale sur la protection des données (LPD) s'applique aux données personnelles qui traînent dans un jeu d'essai comme ailleurs.

Exemples

Une équipe d'une société de paiement vaudoise porte au backlog le rapprochement des versements QR-facture avec les écritures du système central, par une interface ISO 20022 qu'elle n'a jamais intégrée. L'estimation relative cale: les chiffres proposés vont de 3 à 13 points. L'équipe ouvre un spike technique. Voici sa carte telle qu'elle se lit dans l'outil, complétée à la fermeture.

La développeuse monte un dépôt séparé et fait tourner la bibliothèque déjà sous licence sur un lot d'avis de crédit camt.054, tirés de l'environnement de test de la banque. Les avis simples passent sans intervention. Les versements partiels rendent des montants que le rapprochement n'explique pas, et les paiements à référence SCOR sortent sans clé pour retrouver la facture d'origine. Elle écrit un analyseur d'essai pour ces deux cas, mesure ce qu'il demanderait écrit proprement et s'arrête à la seizième heure. Un troisième cas repéré dans le lot, les avis groupés, n'a pas été instruit: la durée a expiré avant que la liste des questions soit épuisée.

La ligne de la carte qui porte le plus est la dernière: l'élément quitte la mention « inconnu » pour 8 points, ce qui était l'objet de la dépense. Les 16 heures ne rendent aucune ligne de code livrable.

Visualisations

Un spike se visualise d'abord par sa propre carte de backlog: deux colonnes qui se remplissent en deux temps, le but et la durée à l'ouverture, la réponse et la décision à la fermeture. Tenue sur plusieurs itérations, cette suite de cartes montre où l'équipe perd sa capacité en recherche et si les mêmes inconnues reviennent.

Le déroulement se dessine en deux voies parallèles. La voie du haut porte le flux ordinaire, de l'élément de backlog au travail d'itération puis à l'incrément livrable. La voie du bas part d'un élément que l'équipe ne sait pas estimer, traverse une boîte de largeur fixe portant le but et le type, puis rejoint le backlog en rendant une estimation. Aucune flèche ne relie la voie du bas à l'incrément.

Coût

Outils

L'environnement jetable porte le spike technique: un dépôt de code séparé, un bac à sable chez le fournisseur d'interface, un conteneur monté pour l'occasion. La séparation d'avec le dépôt du produit est ce qui rend le code du prototype impossible à livrer par inadvertance.

L'outil de gestion de backlog (Jira, Azure DevOps, GitLab et leurs équivalents) reçoit le spike comme un élément à part entière, avec un type propre ou une étiquette. Le budget en heures s'y inscrit; la réponse et l'élément réestimé y restent attachés, ce qui permet de retrouver six mois plus tard pourquoi un chiffre a été retenu.

La spécification du fournisseur et les jeux de messages d'exemple décident de la qualité de la réponse, au même titre qu'une mesure prise sur les volumes réels de l'organisation. Un spike conclu sur de la documentation lue rend une opinion; un spike conclu sur du code exécuté rend un fait.

Sources

• IIBA, Agile Extension to the BABOK Guide, §7.16 Spikes: l'objet de la technique, le déclencheur d'un élément impossible à estimer, le caractère exploratoire et l'exclusion de l'incrément livrable, les deux éléments que sont le but et le type, la durée fixée à l'intérieur d'une itération, les trois types fonctionnel, technique et exploratoire, ainsi que les forces et les limites énoncées, dont la focalisation apportée par la durée, la connaissance mutuelle en début de constitution d'équipe, la durée trop longue ou l'élément trop gros, l'emploi abusif du terme pour des conversations de suivi et le recours trop fréquent qui signale un affinement défaillant.
• IIBA, Agile Extension to the BABOK Guide, §7.0, tableau 7.0.1 Selecting the Right Technique: le spike rangé parmi les techniques de gestion des exigences, du côté des équipes internes.
• Kent Beck avec Cynthia Andres, Extreme Programming Explained: Embrace Change, 2e édition, Addison-Wesley, 2004: l'origine du terme et la spike solution, programme minimal construit pour répondre à une question de conception puis abandonné.
• Mike Cohn, What Are Agile Spikes? When and Why Do Teams Use Spikes?, Mountain Goat Software: catalogue de praticien, non normatif; le spike chiffré lui-même en heures, l'ordre de grandeur donné en exemple et la règle qui le réserve aux incertitudes extrêmes.