Achat d’une vieille maison.
Infiltrations d’eau dès le premier printemps.
On cherche à comprendre.
On magasine des expertises pour identifier les causes et évaluer les travaux nécessaires.
Côté produit, même réalité.
Notre PO aimerait offrir un nouveau type de produit financier, un besoin transversal qui demande de revisiter plusieurs secteurs de l’application actuelle.
Une des compagnies propose une approche différente :
Une visite d’une demi-journée, pour analyser la situation en profondeur,
à un coût représentant environ 5 % des estimations complètes.
Moi: « Ah vous me proposez un spike. C’est une super idée! »
Eux: « Un quoi? »
Moi : « Ah… nevermind. »
Le spike en développement logiciel
On propose au Product Owner de faire un spike avec une banque d’heures fixes sur des zones ciblées du code. À la sortie de l’exercice, on partage nos découvertes et tenterons de fournir des solutions et estimés adaptés.
Objectif :
- Comprendre la réalité technique
- Identifier les risques
- Proposer des pistes de solution
- Produire des estimations plus fiables
Une approche gagnante pour tous
Pour le fournisseur
- Réduit les mauvaises surprises qui font exploser les coûts
- Limite les projets qui dérapent en cours de route
- Diminue l’imprévisibilité des chantiers
- Permet de tester la collaboration sur un plus petit mandat
Pour le client
- Réduit les risques de dépassement budgétaire
- Offre une porte de sortie à faible coût si la collaboration ne fonctionne pas
- Permet de prendre des décisions mieux informées dès le départ
Ce que révèle un spike
Sur le terrain : On creuse.
Premier coup de pelle : BANG!.
Deuxième : BAAAANNGG!!!
Une dalle cachée. Six pouces de béton coulés sous nos pieds.
Après avoir cassé ce béton. D’autre surprises. Une rangée de briques enfouies.
Que. De. Surprises.
Dans le code :
Même logique.
On ouvre la section des feuillets et rapports. C’est. Le. Fouillis. Duplication sur duplication. Requêtes SQL à même la génération de PDF. La librairie de génération de PDF n’est plus supportée depuis notre dernière mise à jour. Le code actuel est excessivement couplé à tout ça. Ouf…
Bref… un terrain miné.
Explorer, comprendre, documenter
On creuse juste assez.
On observe :
- L’état réel
- Les contraintes
- Les anomalies
Puis on s’arrête.
Même chose côté code :
On teste une réécriture partielle avec une approche plus propre.
On évalue les efforts.
On identifie les zones d’incertitude.
Time’s up.
Transformer l’exploration en plan d’action
On prend un moment pour explorer les efforts de réécrire un des rapports avec une approche plus propre ainsi qu’une librairie plus adaptée et supportée. On prend note des efforts, défis et questionnements que nous avons toujours. Time’s up. On se prépare pour la réunion de suivi.
Quelques jours plus tard :
- Un devis adapté à la réalité
- Des options concrètes
- Un plan de préparation clair
- Une documentation terrain (notes, vidéos, observations)
Quelques jours plus tard, nous partageons nos découvertes au reste de l’équipe.
Nous négocions avec notre PO la portée de l’initiative en équilibrant les efforts pour les options futures dans le code et les besoins de livrer le nouveau produit prochainement.
Nous montons ensemble un plan et estimons le travail en fonction.
Moins de surprises, plus de contrôle
Résultat :
Des travaux mieux planifiés.
Moins d’imprévus.
Un climat beaucoup plus sain.
Sans spike?
On peut imaginer :
- Des coûts imprévus dès le départ de l’initiative
- Des retards en cascade
- Des gens qui ont été vendre les estimés originaux qui perdent encore la face
- Des clients frustrés
Le spike, un investissement stratégique
Le spike, c’est souvent un investissement payant.
Un moyen de :
- Réduire l’incertitude
- Mieux estimer
- Améliorer la confiance des parties prenantes
En développement logiciel comme en rénovation…
mieux vaut comprendre le terrain avant de se lancer dans un énorme chantier.
Épilogue
Finalement, les travaux se sont super bien déroulés. Pas sans surprises, comme d’habitude, mais avec un degré vraiment moindre. Et ce, dans un climat beaucoup plus détendu que si nous avions tout découvert en cours de route.
Je peux m’imaginer le climat de frustrations à la découverte de frais d’extra au premier coup de pelle, l’entrepreneur qui doit aller emprunter l’équipement sur un autre chantier, le contremaître qui voit son chantier au ralenti, le retard qui vient ajouter de la pression sur l’équipe qui retarde un autre projet client, etc.
À refaire 🙂