Vendredi 02 août 2024 à 13:40

Je souhaite partager une réflexion sur un risque potentiel lié à l'usage des spikes.

Lorsque les équipes réalisent des spikes avec un taux de réussite très élevé, il existe un risque significatif que les développeurs et les stakeholders commencent progressivement à considérer ces spikes comme des issues ordinaires. Si cela se produit, les caractéristiques et l'utilité intrinsèques des spikes risquent d'être compromises :

  • Les développeurs pourraient se sentir obligés de réussir chaque spike ;
  • Ils pourraient alors être tentés d'augmenter la qualité de réalisation de leurs spikes, transformant ainsi des explorations en livrables de production ;
  • Les stakeholders, quant à eux, pourraient ne plus prendre en compte le risque d'échec des spikes dans leur stratégie.

Pour ces raisons, je rappelle régulièrement aux stakeholders que l'échec fait partie intégrante des spikes et qu'il est essentiel de préserver cette caractéristique pour maintenir leur véritable utilité.

Journaux liées à cette note :

Journal du vendredi 02 août 2024 à 10:40 #dette-technique, #software-engineering, #réponse

J'ai partagé la note au sujet des Quick Fixes du 31 juillet 2024 à un ami — profil Product Manager — et voici ma réponse à ses commentaires.

« Ce que je retiens principalement et qui est, à mon avis, sous-estimé, c’est l’impact psychologique de travailler dans le chaos et d’avoir l’impression d’une dette insurmontable. Pour moi, la motivation et le sens de ce qu’on fait, c’est vraiment l’enjeu clé. Je pense donc qu’il est essentiel d’avoir une gestion saine et transparente de tout ça, le quick fix est néfaste à long terme. » -- mon ami

Je trouve cela intéressant que tu soulignes "l'impact psychologique" 👍️. Je partage cet avis et cela rejoint cette partie de ma note :

« D'après mon expérience, lorsque le développement d'une application est fait en équipe, l'accumulation de Quick Fixes entraîne rapidement :

Ensuite :

« Sur la question des explorations/spikes, je suis partagé. De ma modeste expérience, ça n’a jamais été concluant. Ça ne permet pas de valider une quelconque « pain » business qu’on n’aurait pas pu valider d’une autre manière. » -- mon ami

Je comprends ton point de vue. Comme toi, autant que je me souvienne, je n'ai jamais participé à une exploration de produit réussie destinée aux utilisateurs B2B ou B2C.
Je pense qu'il y a deux raisons à cela : la première est que, de mon point de vue, ces expériences n'étaient pas réalisées avec le niveau de rigueur nécessaire.
La seconde est que ce type d'activité est intrinsèquement difficile à mener.

Cependant, j'ai réalisé des spikes produits — objectifs d'explorations de features — avec succès pour des utilisateurs internes — stakeholder.
Ces spikes m'ont permis plusieurs choses :

  • De rendre concrètes des idées pas toujours comprises par des descriptions verbales ;
  • De gagner la confiance des stakeholders, et d'éviter une longue période de vaporware ;
  • De créer un artefact facilitant la convergence d'un groupe — développeurs, product managers, stakeholders — vers un objectif commun.

« et ça n’aide pas franchement la tech à débroussailler les écueils techniques. » -- mon ami

Mon expérience concernant les spikes techniques est différente. Pour moi, c'est une méthode qui fonctionne sans hésitation.

Ce que j'observe sur moi-même et je pense chez d'autres personnes :

  • Les spikes mettent moins de pression aux développeurs sur des tâches complexes.
  • Les spikes réduisent l'Effet Ikea des développeurs. Ils savent que c'est un spike et que sa solution sera probablement abandonnée.
  • Les spikes réduisent l'entêtement, facilitant la pratique du timeboxing.
  • Les spikes indiquent clairement aux développeurs qu'on n'attend pas une fonctionnalité finie et sans bug.

(Voir aussi ma note à propos d'un risque potentiel lié à l'usage des spikes).

J’ai pas encore avancé dans ma réflexion là-dessus, mais j’ai l’impression qu’un projet, s’il est important, doit être conduit proprement dès le départ. Si on n’a pas le temps de le faire proprement, c’est que c’était pas nécessaire, et ça va ajouter de la complexité inutilement.

Je te rejoins très fortement sur cette dernière phrase 👍️.