Présentation sur la gestion de la dette technique faite à Confoo en 2014 (avec note de la présentation !)

1. TROIS PETITES HISTOIRES DE…
DETTE TECHNIQ UE
“Words pay no debts.“
― William Shakespeare

2. Qui suis je ? Bruno Morel. Directeur du Développement Logiciel chez Seedbox
!
15 ans de développement (programmeur C/C++, Java, PHP, Javascript)
(en fait 25…si on compte mes premiers pas sur l’Apple IIc…)
!
12 ans en tant que gestionnaire d’équipe de développement logiciel plus particulièrement dans des équipes Agiles

3. AGILE LINGO
24h
PO
As a Client, I want to
2 semaines
As a Client, I want to
As a Client, I want to
+
+
+
—
As a Client, I want to
As a Client, I want to
As a Client, I want to
Ve l o c i t é
S T O RY
POINTS
As a Client, I want to
BUSINESS
VA L U E
Définition (basique) des termes utilisés dans le reste de la présentation :
Story => une unité de ‘changement’ (nouvelle fonctionnalité, bug, modification)
PO => responsable de la liste de stories, leur specification et leur priorité
Sprint => période limitée dans le temps pour laquelle l’équipe s’engage à livrer un nombre précis de ‘stories’
Backlog => l’ensemble de toute les stories priorités par le PO
Business Value => valeur imaginaire relative au produit explicitant la valeur d’affaire voulue / souhaitée / calculée pour une story donnée
Story Point => valeur imaginaire relative à l’équipe explicitant la complexité de chaque story et permettant d’anticiper la ‘capacité’ de l’équipe pour chaque sprint
Vélocité => somme de tous les ‘story point’ des stories livrés par l’équipe dans un sprint

4. I L É TA I T
UNE FOIS…
Il était une fois…
!
Parlons de dette, mais d’abord, la dette : c’est quoi ?

5. I L É TA I T U N E F O I S …
Comme un vieux hobbit sous l’influence de l’anneau unique : tout logiciel est susceptible au sortilege du temps : tout devient Legacy
=> tout vieillit.

6. I L É TA I T U N E F O I S …
Tels des dragons sur leur trésors, les gens ont peur des conséquences du changement, peur de perdre ce qu’ils ont durement (souvent) stabilisé
!
Ne pas toucher, rien changer : ca marche !!!

7. I L É TA I T U N E F O I S …
Et enfin, telle une princess au bois dormant : les connaissance elle-même stagnent
Il faut une discipline continue pour se mettre à jour et ne pas devenir un développeur ‘obsolète’. Il faut se reveiller.

8. I L É TA I T U N E F O I S …
+
+
La dette technique étant systémique, on ne peut y échapper, alors il faut apprendre à la gérer.
C’est à dire :
- rajeunir le code, l’architecture, les systèmes : manger du legacy, combattre le pouvoir de l’anneau unique
- lutter contre les conservatismes, inciter à découvrir, innover : experimenter, tuer le dragon en nous, se donner une ‘carte’ rassurant de la ou on veux aller
- se réveiller, se mettre à jour : embrasser le princesse, être le prince récent, et pas le crapaud obsolète

9. I L É TA I T U N E F O I S …
550
PROJECTION
Story Points
SANS GESTION DE DETTE
280
50 %
Dette technique accumulée
Croissance de la dette
SP Produits
Utilisons une simulation simplifiée des effets de la dette sur la livraison, notre hypothèse ici :
- vélocité : 50 points / sprint
- création de dette : 5 points / sprint
Dette est cumulative : la dette antérieure ‘amplifie’ la dette actuelle (suite croissante)
modèle mathématique : Dn = D(n-1) + [ n* 5 ] - Solution
!
Au bout de 13 itération, on constate que la dette atteint la majorité de la valeur investie dans le développement…Sans gestion de la dette, les intérêts s’accumulent, on
approche de la ‘faillite’ technique.

10. AU DÉBUT FUT…
LE RUSH
L E S C H E VA L I E R S D E L A D E R N I È R E P R E M I È R E C R O I S A D E
“Fools rush in where angels fear to tread.“
― Alexander Pope
Premier retour d’experience : Canöe.
Beaucoup de logiciels anciens, beaucoup de système disparates, donc beaucoup de dette technique. Des équipes de 3 à 5 personnes, agiles (Scrum), avec chacune des
dizaines de sites sous leur responsabilité.

11. LE RUSH
ITÉRATIONS
$
$
$
$
$
$
…
La méthode du ‘rush’, c’est un grand classique ‘Agile’ : une itération (Sprint) dédié à tackler la Dette toutes les X itérations (ici 4).
L’équipe ‘Vend’ le projet à son PO. L’équipe doit estimer en fonction de sa vélocité passée, le nombre de stories de dettes qu’elle s’engage à livrer.
Le PO convaincu, l’équipe se commet sur la livraison de ces stories uniquement ‘techniques’.
Aucune autre story n’est accepté sauf une urgence dans ce sprint.

12. LE RUSH
La quête : briser le sortilège du temps, découvrir l’élixir de jeunesse, le holy grail… un système MIS à jour.
!
L’expérience a eu lieux pendant 8 mois, 2 itérations de ‘dette’ sur 6 itérations pour 1 équipe.
La dette qui a été choisie était mixte et complexe mais surtout le refactoring de vieux systèmes.
Cela impose beaucoup de discussion.

13. LE RUSH
Story Points
550
Dette technique accumulée
Rappel de la simulation sans gestion de dette :
- vélocité : 50 points / sprint
- création de dette : 5 points / sprint
Croissance de la dette
SP Produits

14. LE RUSH
550
25% de SP “perdus” au total
20 % de ‘poids’ de la dette en moins
Story Points
405
135
33 %
Dette technique accumulée
Croissance de la dette
Même simulation mais avec la méthode de ‘sprint de dette’:
- vélocité : 50 points / sprint
- création de dette : 5 points / sprint
- le sprint de dette : tous les 4 sprint
!
Le sprint de dette réduit de moitié la dette courante (hypothèse optimiste)
SP Produits (Rush)
SP Produits (initiaux)

15. LE RUSH
M O R A L E D E L’ H I S T O I R E
LEGACY PRIS EN CHARGE
E X P E R I M E N TA T I O N
COMPÉTENCES A JOUR
S A T I S FA C T I O N P O
S A T I S FA C T I O N D E V
PA S L E T E M P S ( S E PA R É M E N T ? )
SPRINT ‘PERDU’
JAMAIS LE TEMPS DE FINIR
ACCUMULATION STOPPÉE
DETTE ABAISSÉE
P R O C E S S U S FA C I L E
CYCLIQUEMENT
SCRUM ‘CLASSIQUE’
Les résultats sont mitigés
- la dette est attaquée (la partie legacy essentiellement)
- on perd encore rapidement ‘contrôle’ de la dette
- évaluation initiale de la dette devient vite obsolète
- le PO a eu de la difficulté à comprendre l’importance ou la portée des changements
- l’équipe se frustre de ne jamais rien finir
- l’équipe n’a pas de temps pour s’auto-former
- la vélocité devient en ‘dent de scie’ du à la complexité souvent aléatoire de la dette (estimation TRÈS difficile)
- cela créé un incitatif inconscient a créer PLUS de dette (couper les coins ronds)
- cela dit, le processus est facile a implanter, c’est un sprint ‘Scrum’ classique

16. LE RUSH
Conclusions ?
Après une itération…
On a pas trouvé l’elixir de jeunesse éternelle, mais plutôt une creme de jour….son efficacité est toute relative.
!
En théorie, ça fonctionne si le sprint de dette consomme PLUS que la somme de toute la Dette accumulé à chaque iteration…
En pratique, arriver à un tel taux est difficile, et pendant qu’on attend le prochaine sprint de dette, on accumule les fameux ‘intérêts’ dessus.

17. Q U E L Q U E T E M P S P L U S TA R D …
LES SPÉCIALITÉS
SACRÉ GRAAL
“The expert knows more and more about less and less
until he knows everything about nothing.”
― Mahatma Gandhi
Deuxième retour d’expérience : iWeb Technologies.
Fournisseur d’infrastructure internet (serveurs), iWeb avait comme engagement de fusionner un ancien système (plus de 10 ans de développement interne) avec un
nouveau système de livraison des serveurs pour un nouveau centre de donnée (le produit ‘Smart Server’ sortit en 2011).
La dette était donc multi-dimensionnelle :
- à la fois des systèmes vieux à refactorer
- mais aussi la volonté d’innover et donc le besoin de ‘réveiller’ la curiosité des équipes et d’inciter à tuer les conservatisme pour mener à l’innovation voulue.

18. LES SPÉCIALITÉS
ITÉRATIONS
$
$
$
$
$
…
On a alors inventé un concept sur mesure, les spécialités :
- on fixe un budget pour l’année pour chaque spécialité et le montant est reparti par Sprint (on a commence à 10%)
- Chaque développeur choisit une spécialité (Front-end, Back-end, Qualité)
- Chaque spécialité est une ‘League of exceptionnel gentlemen’, dont chaque membre a pour engagement d’abaisser la dette technique dans sa spécialité
- Chaque spécialité est inspirée par un Tech Lead
- Le PO doit accepter le montant de spécialité pour l’année, après cela, celui-ci n’est plus négociable
- Le PO est alors informé de ce qui se passe en Spécialité à chaque iteration

19. LES SPÉCIALITÉS
Dans les faits, l’expérience a fait émerger un nouveau phénomène : l’hydre…
!
Comme les Monthy Python, il fallait contrôler la dette (notre chevalier noir) pour continuer notre projet, mais celle-ci s’obstinait à s’accumuler sur les spécialités ou il y
avait moins de développeur / moins d’intérêt pour les développeurs.

20. LES SPÉCIALITÉS
Story Points
550
Dette technique accumulée
Rappel de la simulation sans gestion de dette :
vélocité : 50 points / sprint
création de dette : 5 points / sprint
Croissance de la dette
SP Produits

21. LES SPÉCIALITÉS
550
20% de SP “perdus” au total
440
Story Points
40 % de ‘poids’ de la dette en moins
Dette technique accumulée
Croissance de la dette
SP produits (Spécialités)
SP produits (Rush)
14 %
62
SP produits (initiaux)
Même simulation mais avec la méthode des ‘spécialités’ :
- vélocité : 50 points / sprint
- création de dette : 5 points / sprint
- spécialité : 20%
L’effet de bord / erreur : les spécialités empêchent de répartir l’effort sur la dette la plus criante. Cela créé un déséquilibre dans la gestion de la dette entre les
spécialités qui avancent ‘vite’ à réduire la dette, et celle qui, pour différentes raisons (plus de dette, moins de developpeurs, …) sont plus lents à le faire.
!
Au final, malgré cela, la gestion totale de la dette semble plus efficace qu’avec la méthode du ‘rush’ (en gris) : avec un investissement de 20% dans les spécialités, on
arriverait à réduire de 40% la dette qui s’accumule en perdant ‘seulement’ 20% des fonctionnalités d’affaires / valeur d’affaire pour le produit.

22. LES SPÉCIALITÉS
M O R A L E D E L’ H I S T O I R E
LEGACY PRIS EN CHARGE
E X P E R I M E N TA T I O N
S E U L E M E N T PA R S P É C I A L I T É S
COMPÉTENCES A JOUR
S E U L E M E N T PA R S P É C I A L I T É S
S A T I S FA C T I O N P O
S A T I S FA C T I O N D E V
S I M O N TA N T E S T ‘ R A I S O N N A B L E ’
AUTRE SPÉCIALITÉS ?
ACCUMULATION STOPPÉE
DETTE ABAISSÉE
P R O C E S S U S FA C I L E
RALENTIE
‘HYDRE’
DISCPLINE
En résumé, les résultats sont meilleurs :
- la dette est gérée : le vieux code lui-même, mais aussi la possibilité de prendre en charge la dette EN COURS de sprint
- l’experimentation devient possible (essai de nouveaux framework, librairie, mise a jour…)
- une possibilité de veille et de s’auto-éduquer plus grande existe
- beaucoup moins de frustration du PO, car même si la vélocité de l’équipe est légèrement plus basse, elle reste ‘stable’ et prévisible
- la satisfaction des développeurs est ‘moyenne’ :
- se cantonner à une spécialité est difficile voir frustrant
- la définition du périmètre de chaque spécialité est toujours sujet à interprétation, voir débat
- au niveau du processus, c’est plus complexe à intégrer dans Scrum (c’est un Kanban DANS le sprint) : cela demande donc plus de discipline

23. LES SPÉCIALITÉS
Conclusions ?
Par ‘silotage’, les spécialités créent nouveau phénomène : l’hydre
-> quand on coupe une tête dans une spécialité, dix autres repousse dans une autre spécialité
!
Au final, c’est un meilleur système, mais perfectible.
!
P.S. : Au jour d’aujourd’hui, chez iWeb : les développeurs ont abandonnés les spécialités (mais, secrètement, certain en fond encore sans le dire…:))

24. POUR FINIR…
A M É L I O R AT I O N L O G I C I E L
AKA
SYSTEM IMPROVEMENT
“Improvement begins with I.”
― Arnold H. Glasow
Dernier retour d’expérience : Seedbox Technologies.
Fournisseur de système de gestion de site web à TRÈS haute-traffic (dans les millions d’impression par jour).
Comme chez iWeb, la gestion de la dette devait couvrir les trois aspects de la dette pour pousser à l’innovation et l’experimentation.

25. LES AMÉLIORATIONS LOGICIELS
ITÉRATIONS
$
$
$ $
$
$
…
Après réflexion, on a carrément supprimé le concept de spécialités :
- le budget est toujours fixe sur l’année et le montant reparti par Sprint (commence à 10%)
- chaque dev est libre de participer / soumettre les améliorations chaque mois dans une réunion d’amélioration logiciel
- l’équipe CHOISIE avec le Directeur du Développement Logiciel les améliorations sur lesquels elle travaille
- L’équipe choisie QUAND dans l’itération elle travaille sur les améliorations (en informant son PO à l’avance)
- 1 fois par mois, l’équipe présente les projets terminée au PO et au DDL (dans la même réunion que pour choisir les nouvelles améliorations)

26. LES AMÉLIORATIONS LOGICIELS
En 2012, on a commencé avec 2 équipes, ont l’implante aujourd’hui dans 4.
!
L’effet de redonner le ‘pouvoir’ aux développeur pour influencer et trouver la gestion optimale de la dette est une implication plus forts et beaucoup de flexibilité dans
le choix des améliorations.
!
Comme les développeurs ont une appréciation fine du poids de chaque dette, ils sont à la fois plus motivé à la réduire et plus efficace.

27. LES AMÉLIORATIONS LOGICIELS
Story Points
550
Dette technique accumulée
Rappel de la simulation sans gestion de dette :
vélocité : 50 points / sprint
création de dette : 5 points / sprint
Croissance de la dette
SP Produits

28. LES AMÉLIORATIONS LOGICIELS
550
25% de SP “perdus” au total
reduction lente mais régulière de la dette
Story Points
412
Dette technique accumulée
Debt Growth
SP produits (SI)
SP produits (Spécialités)
SP produits (Rush)
1%
SP produits (initiaux)
Même simulation mais avec la méthode de l’amélioration logicielle :
- vélocité : 50 points / sprint
- création de dette : 5 points / sprint
- spécialité : 25%
Au final, non seulement la motivation intrinsèque des développeurs est grande puisqu’ils ont l’opportunité de choisir la dette à réduire, mais la systématisation par
sprint accélère drastiquement cette réduction.
Si on projette cela sur la simulation, c’est bien une réduction, certes lente, mais régulière, de la dette qu’on observe, au prix biensur d’une légère baisse du nombre de
fonctionnalités / valeur d’affaire, livrée.

29. LES AMÉLIORATIONS LOGICIELS
M O R A L E D E L’ H I S T O I R E
LEGACY PRIS EN CHARGE
E X P E R I M E N TA T I O N
COMPÉTENCES A JOUR
S A T I S FA C T I O N P O
S I M O N TA N T E S T ‘ R A I S O N N A B L E ’
S A T I S FA C T I O N D E V
ACCUMULATION STOPPÉE
DETTE ABAISSÉE
LENTEMENT
P R O C E S S U S FA C I L E
DISCIPLINE
En résumé, le résultat est plutôt très bon, même si ca n’est pas encore parfait
- la dette est gérée, à la fois le legacy et possibilité de prendre en charge la dette en cours de sprint, l’experimentation est possiblel et la possibilité de veille et de
s’auto-éduquer est grande
- il y a toujours peu de frustration du PO, la vélocité reste ‘stable’ et prévisible
- on constate une plus grande satisfaction des développeurs :
- liberté dans le choix des ‘pain points’ / améliorations à travailler
- liberté dans les stratégies adoptées
- transparence sur les résultats
- le processus lui est toujours plus complexe à intégrer dans Scrum, et demande donc toujours une plus grande discipline

30. LES AMÉLIORATIONS LOGICIELS
Conclusions ?
en 2 ans, on a fait de multiples ajustements :
- d’un jour fixé dans le sprint on est passé au choix du jour par les développeurs individuellement
- d’un montant fixé et immuable, on est passé à un montant ‘maximal’ que les développeurs font varier en fonction des urgences
- les démo / review des améliorations tous les mois apporte des conversation et une collaboration très intéressante entre les équipes et leur Directeur du
!
Développement Logiciel
Le reste est à venir…comme toujours en Agilité : inspect and adapt !

31. http://www.construx.com/10x_Software_Development/Technical_Debt/
http://easyart.github.io/2013/10/12/on-technical-debt/
http://insideintercom.io/there-are-no-small-changes/
github.com/bruno-morel
@brunoyvanmorel
linkedin.com/in/morelbruno