Un spike est une histoire d'utilisateur spéciale avec le programme le plus pur possible, qui est utilisé comme une méthode de test de produit. L'équipe de développement utilise les spikes pour recueillir des informations supplémentaires qui les aident à réduire le risque technique, à mieux comprendre une exigence ou à augmenter la précision de l'estimation d'une histoire. Par conséquent, l'équipe peut explorer le problème et les solutions potentielles.
La taille maximale de la boîte à temps d'un spike est la même que le sprint qui le contient. Comme les autres user stories, les spikes seront démontrés comme étant faits ou non à la fin d'un sprint. C'est pourquoi un spike est un excellent moyen d'estimer l'effort nécessaire pour résoudre un problème de développement logiciel.
Pourquoi les spikes sont nécessaires ?
Parfois, l'équipe ne peut pas estimer une story en raison de certains blocages. Si l'équipe n'est pas certaine de terminer la story, il est temps de penser à utiliser des pics.
Voici quelques situations dans lesquelles l'utilisation de pics est recommandée :
- Les développeurs ont besoin de faire quelques activités précoces afin de pouvoir estimer les user stories
- Les développeurs n'ont aucune idée de la façon de traiter le problème
- Les développeurs ne sont pas sûrs que la solution qu'ils attendaient fonctionne ou non
- Les développeurs ont plus d'une option qu'ils doivent tester davantage pour décider laquelle est la plus potentielle.
- Les développeurs utilisent des spikes pour rechercher la praticabilité d'une nouvelle technologie, comme une nouvelle approche ou un nouveau domaine.
Les développeurs peuvent certainement utiliser plusieurs spikes dans différents sprints pour une histoire. Il pourrait y avoir un spike pour la recherche de solutions potentielles, un spike pour les essais et les erreurs, un spike pour l'estimation de la user story, etc.
Notamment, ce n'est qu'après l'affinement du backlog de produit que l'équipe de développement identifie les spikes.
Combien de types de spikes ?
Il existe deux formes principales de spike en Agile : les spikes techniques et fonctionnels.
- Spike technique
Un spike technique est utilisé lorsque les développeurs doivent évaluer des options techniques ou les impacts d'une nouvelle technologie sur l'avancement actuel. Ils s'attendent à obtenir plus de certitude sur l'approche avant d'exécuter.
Par exemple, les développeurs utilisent souvent les pics techniques pour déterminer la bande passante, les exigences de communication, ou s'il faut tirer ou pousser les données ; ou pour estimer le temps qu'il faut pour mettre à jour un affichage client pour présenter l'utilisation.
- Pike fonctionnel
Les pics fonctionnels sont couramment utilisés pour s'assurer des interactions d'un utilisateur avec le système. Ils sont évalués à travers des niveaux de prototypage de maquettes d'interface, de flux de pages, de wireframes de toutes les techniques qui conviennent pour obtenir des retours d'informations de la part des clients ou des parties prenantes.
Par exemple, l'équipe de développement prototypera un histogramme sur le portail web pour obtenir des retours d'informations de la part des utilisateurs sur le style de présentation, la taille et le graphique.
Quels sont les avantages des pointes ?
Voici une liste de certains avantages de l'utilisation des pointes dans Agile :
- Les pointes aident l'équipe de développement à briser l'incertitude pendant le processus. Il réduit les choses indéfinies.
- Avec les pointes, les développeurs ne seront pas indéfinis. Où ils se dirigent est toujours clair comme de l'eau de roche.
- Les pics empêchent les développeurs de surestimer les histoires. Parce qu'ils brisent le risque de certitude, ils sont plus proches des estimations réelles.
À la fin des spikes, l'équipe de développement peut décider laquelle est la meilleure solution à mettre en œuvre pour activer cette fonctionnalité.
Quels sont les critères d'acceptation des spikes ?
Les spikes, une user story en tant que technique Agile de collecte des exigences, doivent répondre à certaines normes requises pour obtenir le statut "fait".
Les développeurs doivent s'assurer qu'un spike à être :
- Estimable : mis dans le backlog, les Spikes sont dimensionnés et estimables pour tenir dans un sprint. Généralement, la production d'informations rend les résultats du Spike différents d'une histoire. Il aboutit à un prototype, un storyboard, une preuve de concept, une décision, ou certaines solutions qui conduisent à des résultats finaux.
Dans tous les cas, un spike doit développer suffisamment d'informations pour résoudre l'incertitude. Ainsi, il peut identifier et dimensionner les histoires sous le Spike.
- Démontrable : Les résultats d'un spike doivent être démontrables pour les équipes. Cela permet de rendre visible les efforts de recherche. Cela aide également à construire l'appropriation ainsi que la responsabilité partagée pour plus de décisions.
- Acceptable : Lorsque les pics remplissent ces critères particuliers, ils seraient acceptés par le propriétaire du produit.
Mots finaux : 51% des répondants ont déclaré que plus de la moitié de leur équipe utilise Agile en raison de sa grande efficacité. Et les pics en Agile sont définitivement utiles lorsque les équipes de développement dédiées veulent contrôler la livraison, en plus d'exécuter l'objectif du sprint. Ils donnent à l'équipe des estimations, une visibilité et une grande confiance dans la feuille de route de livraison du produit.