Alai

Si nous savions ce que nous faisons, cela ne s’appellerait pas de la recherche.

-Albert Einstein

Les spikes sont un type d’exploration Enabler Story dans SAFe. Définis initialement dans Extreme Programming (XP), ils représentent des activités telles que la recherche, la conception, l’investigation, l’exploration et le prototypage. Leur but est d’acquérir les connaissances nécessaires pour réduire le risque d’une approche technique, mieux comprendre une exigence ou augmenter la fiabilité de l’estimation d’une story.

Comme les autres stories, les spikes sont estimées puis démontrées à la fin de l’Iteration. Ils fournissent également un protocole et un flux de travail convenus que les Agile Release Trains (ARTs) utilisent pour aider à déterminer la viabilité des Epics.

Agile et Lean valorisent les faits plutôt que la spéculation. Lorsqu’elles sont confrontées à une question, un risque ou une incertitude, les équipes Agile mènent de petites expériences avant de passer à la mise en œuvre, plutôt que de spéculer sur le résultat ou de sauter sur une Solution. Les équipes peuvent utiliser les pointes dans une variété de situations :

• Estimer de nouvelles Fonctionnalités et Capacités pour analyser le comportement implicite, fournissant un aperçu de l’approche pour les diviser en morceaux plus petits et quantifiables
• Faire une analyse de faisabilité et d’autres activités qui aident à déterminer la viabilité des épopées
• Faire des recherches de base pour les familiariser avec une nouvelle technologie ou un nouveau domaine
• Gagner la confiance dans une approche technique ou fonctionnelle, réduire le risque et l’incertitude

Les pics impliquent la création d’un petit programme, d’une activité de recherche ou d’un test qui démontre un aspect de la nouvelle fonctionnalité.

Pics techniques et fonctionnels

Les pics se présentent principalement sous deux formes : technique et fonctionnelle.

Pointes fonctionnelles – Elles sont utilisées pour analyser le comportement global de la solution et déterminer :

• Comment le décomposer
• Comment organiser le travail
• Où le risque et la complexité existent
• Comment utiliser les idées pour influencer les décisions de mise en œuvre

Pointes techniques – Elles sont utilisées pour rechercher diverses approches dans le domaine de la solution. Par exemple:

• Déterminer une décision build-versus-buy
• Evaluer l’impact potentiel sur les performances ou la charge d’une nouvelle user story
• Evaluer des approches d’implémentation technique spécifiques
• Développer la confiance sur le chemin de solution souhaité

Certaines fonctionnalités et user stories peuvent nécessiter les deux types de pics. Voici un exemple:

« En tant que consommateur, je veux voir ma consommation d’énergie quotidienne dans un histogramme afin que je puisse comprendre rapidement ma consommation d’énergie passée, actuelle et projetée. »

Dans ce cas, une équipe pourrait créer les deux types de pics :

• Un spike technique pour rechercher combien de temps il faut pour mettre à jour l’affichage d’un client en fonction de l’utilisation actuelle, en déterminant les exigences de communication, la bande passante et le fait de pousser ou de tirer les données
• Un spike fonctionnel – Prototype d’un histogramme dans le portail Web et obtenir des commentaires des utilisateurs sur la taille de la présentation, le style et le graphique

Lignes directrices pour les spikes

Puisque les spikes ne fournissent pas directement de valeur pour l’utilisateur, utilisez-les avec parcimonie. Les directives suivantes s’appliquent.

Quantifiable, démontrable et acceptable

Comme les autres stories, les spikes sont mis dans le Team Backlog, estimés et dimensionnés pour tenir dans une itération. Les résultats des spikes sont différents d’une story car les spikes produisent généralement des informations plutôt que du code fonctionnel. Ils ne doivent développer que les données nécessaires pour identifier et dimensionner les stories qui le pilotent en toute confiance.

Le résultat d’un spike est démontrable, à la fois pour l’équipe et pour toute autre partie prenante, ce qui apporte de la visibilité aux efforts de recherche et d’architecture, et aide également à construire une appropriation collective et une responsabilité partagée pour la prise de décision. Le Product Owner accepte les spikes qui ont été démontrés et qui répondent à ses critères d’acceptation.

Timing des spikes

Puisqu’ils représentent l’incertitude dans une ou plusieurs histoires potentielles, planifier à la fois le spike et les histoires résultantes dans la même itération est parfois risqué. Cependant, si c’est petit et simple, et qu’une solution rapide est susceptible d’être trouvée, alors il peut être assez efficace de faire les deux dans la même itération.

L’exception, pas la règle

Chaque histoire d’utilisateur a de l’incertitude et du risque ; c’est la nature du développement Agile. L’équipe découvre la bonne solution par la discussion, la collaboration, l’expérimentation et la négociation. Ainsi, dans un sens, chaque user story contient des activités de type spike pour identifier les risques techniques et fonctionnels. L’objectif d’une équipe Agile est d’apprendre à gérer l’incertitude à chaque itération. Les pointes sont critiques lorsque de fortes incertitudes existent, ou qu’il y a beaucoup d’inconnues.

Learn More

Leffingwell, Dean. Exigences logicielles agiles : Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison Wesley, 2011.

Dernière mise à jour : 10 février 2021

.