TROIS PETITES HISTOIRES DE…

DETTE TECHNIQ UE

“Words pay no debts.“

― William Shakespeare
Qui suis je ? Bruno Morel. Directeur du Développement Logiciel chez Seedbox

!

15 ans de développement (programmeur C/C++...
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 Cli...
I L É TA I T
UNE FOIS…
Il était une fois…

!

Parlons de dette, mais d’abord, la dette : c’est quoi ?
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...
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...
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 u...
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...
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

C...
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 w...
LE RUSH

ITÉRATIONS

$

$

$

$

$

$

…

La méthode du ‘rush’, c’est un grand classique ‘Agile’ : une itération (Sprint) ...
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.

!...
LE RUSH

Story Points

550

Dette technique accumulée

Rappel de la simulation sans gestion de dette :
- vélocité : 50 poi...
LE RUSH

550

25% de SP “perdus” au total
20 % de ‘poids’ de la dette en moins

Story Points

405

135

33 %
Dette techniq...
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 ...
LE RUSH

Conclusions ?
Après une itération…
On a pas trouvé l’elixir de jeunesse éternelle, mais plutôt une creme de jour…...
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...
LES SPÉCIALITÉS

ITÉRATIONS

$

$

$

$

$

…

On a alors inventé un concept sur mesure, les spécialités :
- on fixe un bu...
LES SPÉCIALITÉS

Dans les faits, l’expérience a fait émerger un nouveau phénomène : l’hydre…

!

Comme les Monthy Python, ...
LES SPÉCIALITÉS

Story Points

550

Dette technique accumulée

Rappel de la simulation sans gestion de dette :
vélocité : ...
LES SPÉCIALITÉS

550

20% de SP “perdus” au total

440

Story Points

40 % de ‘poids’ de la dette en moins

Dette techniqu...
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 ...
LES SPÉCIALITÉS

Conclusions ?
Par ‘silotage’, les spécialités créent nouveau phénomène : l’hydre
-> quand on coupe une tê...
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. Gla...
LES AMÉLIORATIONS LOGICIELS

ITÉRATIONS

$

$

$ $

$

$

…

Après réflexion, on a carrément supprimé le concept de spécia...
LES AMÉLIORATIONS LOGICIELS

En 2012, on a commencé avec 2 équipes, ont l’implante aujourd’hui dans 4.

!

L’effet de redo...
LES AMÉLIORATIONS LOGICIELS

Story Points

550

Dette technique accumulée

Rappel de la simulation sans gestion de dette :...
LES AMÉLIORATIONS LOGICIELS

550

25% de SP “perdus” au total
reduction lente mais régulière de la dette

Story Points

41...
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ÉTE...
LES AMÉLIORATIONS LOGICIELS

Conclusions ?
en 2 ans, on a fait de multiples ajustements :
- d’un jour fixé dans le sprint ...
http://www.construx.com/10x_Software_Development/Technical_Debt/
http://easyart.github.io/2013/10/12/on-technical-debt/
ht...
Trois petites histoires de dette   avec notes de la présentation
Prochain SlideShare
Chargement dans…5
×

Trois petites histoires de dette avec notes de la présentation

656 vues

Publié le

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

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
656
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
8
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Trois petites histoires de dette avec notes de la présentation

  1. 1. TROIS PETITES HISTOIRES DE… DETTE TECHNIQ UE “Words pay no debts.“ ― William Shakespeare
  2. 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. 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. 4. I L É TA I T UNE FOIS… Il était une fois… ! Parlons de dette, mais d’abord, la dette : c’est quoi ?
  5. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×