trois petites histoires de dette avec notes de la présentation

DETTE TECHNIQUET R O I S P E T I T E S H I S T O I R E S D E …

“ W o r d s p a y n o d e b t s . “ ― W i l l i a m S h a k e s p e a r e

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

As a Client, I want to



2 semaines

24h

PO


S T O RY P O I N T S

A G I L E L I N G O

B U S I N E S S VA L U E




— Ve l o c i t é

+++

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

I L É TA I T U N E F O I S …

Il était une fois… !Parlons de dette, mais d’abord, la dette : c’est quoi ?


Comme un vieux hobbit sous l’influence de l’anneau unique : tout logiciel est susceptible au sortilege du temps : tout devient Legacy => tout vieillit.


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 !!!


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.


+

+

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

P R O J E C T I O N S A N S G E S T I O N D E D E T T E


Stor

y Po

ints

Dette technique accumulée Croissance de la dette SP Produits

50 %

550

280

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.

L E R U S HA U D É B U T F U T …

“ F o o l s r u s h i n w h e r e a n g e l s f e a r t o t r e a d . “ ― A l e x a n d e r P o p e

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

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é.

L E R U S H

$ $ $ $ $ $ …

I T É R A T I O N S

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.

L E R U S H

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.

Stor

y Po

ints


550L E R U S H

Rappel de la simulation sans gestion de dette : - vélocité : 50 points / sprint - création de dette : 5 points / sprint

L E R U S H

Stor

y Po

ints

Dette technique accumulée Croissance de la dette SP Produits (Rush) SP Produits (initiaux)

33 %

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

550

135

405

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)

L E R U S H

L E G A C Y P R I S E N C H A R G E

E X P E R I M E N TA T I O N

C O M P É T E N C E S A J O U R PA S L E T E M P S ( S E PA R É M E N T ? )

S A T I S FA C T I O N P O S P R I N T ‘ P E R D U ’

S A T I S FA C T I O N D E V J A M A I S L E T E M P S D E F I N I R

A C C U M U L A T I O N S T O P P É E

D E T T E A B A I S S É E C Y C L I Q U E M E N T

P R O C E S S U S FA C I L E S C R U M ‘ C L A S S I Q U E ’

M O R A L E D E L’ H I S T O I R E

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

L E R U S H

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.

L E S S P É C I A L I T É SQ U E L Q U E T E M P S P L U S TA R D …

“ T h e e x p e r t k n o w s m o r e a n d m o r e a b o u t l e s s a n d l e s s u n t i l h e k n o w s e v e r y t h i n g a b o u t n o t h i n g . ”

― M a h a t m a G a n d h i

S A C R É G R A A L

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.

L E S S P É C I A L I T É S

$ $ $ $ $ …


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


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.

Stor

y Po

ints


550L E S S P É C I A L I T É S

Rappel de la simulation sans gestion de dette : vélocité : 50 points / sprint création de dette : 5 points / sprint


Stor

y Po

ints

Dette technique accumulée Croissance de la dette SP produits (Spécialités) SP produits (Rush) SP produits (initiaux)

14 %

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

62

440

550

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.




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

C O M P É T E N C E S A J O U R 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 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 A U T R E S P É C I A L I T É S ?

A C C U M U L A T I O N S T O P P É E R A L E N T I E

D E T T E A B A I S S É E ‘ H Y D R E ’

P R O C E S S U S FA C I L E D I S C P L I N E

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


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…:))

A M É L I O R AT I O N L O G I C I E L A K A S Y S T E M I M P R O V E M E N T

P O U R F I N I R …

“ I m p r o v e m e n t b e g i n s w i t h I . ” ― A r n o l d H . G l a s o w

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.

L E S A M É L I O R A T I O N S L O G I C I E L S

$ $ $ $ $ $ …


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)


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.

Stor

y Po

ints


550L E S A M É L I O R A T I O N S L O G I C I E L S

Rappel de la simulation sans gestion de dette : vélocité : 50 points / sprint création de dette : 5 points / sprint


Stor

y Po

ints

Dette technique accumulée Debt Growth SP produits (SI) SP produits (Spécialités) SP produits (Rush) SP produits (initiaux)

1 %

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

412

550

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.




E X P E R I M E N TA T I O N

C O M P É T E N C E S A J O U R

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

A C C U M U L A T I O N S T O P P É E

D E T T E A B A I S S É E L E N T E M E N T

P R O C E S S U S FA C I L E D I S C I P L I N E

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


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 !

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

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/

http://github.com/bruno-morel

http://linkedin.com/in/morelbruno

trois petites histoires de dette avec notes de la présentation

Technology