Mener un spike technique à l’aide du développement axé sur le comportement

https://samadesoga.me/posts/driving-a-technical-spike-using-bdd/ de Sam Adesoga

La plupart des méthodologies agiles prévoient l’application d’un Technical Spike pour explorer une nouvelle technologie ou les zones à risque d’un produit. La méthodologie SAFe (Scaled Agile Framework) définit le Spike comme un type d’histoire d’exploration et de catalyseur.

Il existe un certain nombre d’approches qui ont été recommandées pour les Technical Spike.

Il s’agit notamment de :

• Estimation et dimensionnement d’une histoire de Technical Spike
• Limiter dans le temps (Timeboxing) un Technical Spike.

Le Technical Spike est de nature exploratoire et il est contradictoire d’essayer d’estimer la complexité d’un travail qui n’est pas bien compris. D’après mon expérience, la plupart des équipes préféreraient limiter dans le temps les efforts nécessaires pour réaliser un Technical Spike.

Il y a quelques semaines, j’ai eu une conversation avec un développeur qui était à mi-chemin d’un spike et j’ai eu un moment « ah-ha », et cet article est une tentative d’expliquer ce qui pourrait être une approche alternative aux Technical Spikes.

Je suggérerais au Product Owner / Business Analyst en collaboration avec un membre technique de l’équipe, par exemple un architecte, un responsable technique, de définir les exigences de haut niveau à l’aide de la méthodologie de développement axée sur le comportement.

Les avantages de la spécification des exigences axée sur le comportement dès le départ sont les suivants.

• L’objectif du Technical Spike est clairement défini à l’avance et, en tant que tel, le développeur est clair sur ce qu’est le livrable.
• La définition de DONE pour le Technical Spike est dès que toutes les exigences spécifiées sont satisfaites.
• Le développeur ou un testeur peut automatiser le script de développement axé sur le comportement en exigences exécutables.
• Le risque de consacrer trop de temps/d’efforts au Technical Spike est minimisé.
• Une ligne de base d’exigences pour la mise en œuvre réelle évolue à partir du Technical Spike.

Comme pour tout le reste, il n’y a pas de solution miracle, mais il faut veiller à ne pas aller trop loin avec les exigences. Étant donné qu’il s’agit d’un Technical Spike, il est nécessaire de s’assurer que l’exigence est à un niveau très élevé suffisant pour décrire les objectifs du Technical Spike et qu’elle ne soit pas prescriptive.

Cela semble bien fonctionner pour ce projet, alors n’hésitez pas à l’essayer.

---

Sam Adesoga, Principal Coach and Lead Trainer

• Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.org
• L’expérience professionnelle de Sam comprend Développeur, Développeur de logiciels, Test and Release Manager, Scrum Master et récemment coach Agile d’entreprise
• Sam utilise des approches agiles comme fondation, et s’intéresse à aider les individus, les équipes et l’ensemble des organisations à développer l’état d’esprit et la culture nécessaires pour réussir dans un monde VUCA.
• Nombre total d’années d’expérience dans le développement et la livraison de produits à l’aide de cadres de travail agiles – 17 ans.