"Une dette technique non maîtrisée peut vite se transformer en un boulet qui vient vampiriser la productivité des équipes. Dans cette conférence, nous nous attèlerons à cerner cette dette et ses enjeux. Nous verrons quels moyens peuvent être mis en oeuvre pour la prendre en main, grâce à une boîte à outils de visualisation et de suivi, afin de garder heureux : développeurs, clients et utilisateurs" Elodie Micoulet

1. Apprivoiser la
dette technique
15 novembre 2018

2. Qui suis-je?
Elodie Micoulet
Scrum Master chez Nuglif
(La Presse+)
Linkedin
www.linkedin.com/in/elodiemicoulet

3. Quoi trouver dans cette présentation?
Une meilleure compréhension de ce qu'est la dette
technique, de l'impact qu'elle a sur votre produit et
de l'importance de l'inclure dans la valeur de votre
produit

4. Quoi trouver dans cette présentation?
Des idées pour aider vos équipes à mettre en
valeur leur dette technique

5. Quoi trouver dans cette présentation?
Des réflexes pour identifier votre dette technique
grâce à une meilleure compréhension de cette
dernière

6. Qu'est ce que la dette
technique?

7. dette
nom féminin
(latin debita, pluriel de debitum, de debere, devoir)
Somme d'argent que l'on doit à quelqu'un à qui on
l'a empruntée

8. Le remboursement de la dette

9. Et la dette technique?
Un projet de développement logiciel inclut souvent une
conception logicielle (qu'elle soit formalisée ou pas).
Cette dernière fait partie de la qualité du projet.
Ainsi, un non-respect de la conception, intentionnel ou non,
induit des coûts supplémentaires dans le futur. Ce sont les
intérêts.
C'est pourquoi l'on parle de dette technique

10. Pourquoi cette analogie?
Métaphore introduite dans le début des années 90
par Ward Cunningham
Objectif: expliquer le refactoring en cours à sa
ligne d'affaires

12. "If you develop a program for a long period of time
by only adding features and never reorganizing it
to reflect your understanding of those features [...]
that program simply does not contain any
understanding and all efforts to work on it take
longer and longer [...] the interest is total -- you'll
make zero progress"
Ward Cunningham

13. Question:
Qu'est-ce qui engendre de la dette?

14. Le choix d'une solution rapide maintenant versus
une solution pérenne qui prend plus de temps à
développer
Qu'est-ce qui engendre de la dette?

15. Le choix d'une solution rapide maintenant versus
une solution pérenne qui prend plus de temps à
développer
Pas Seulement
Qu'est-ce qui engendre de la dette?

16. Le produit
Définition du besoin incomplète
Changements de dernière minute
Pression de livraison
Mauvaise compréhension
… (ex non exhaustifs)
Qu'est-ce qui engendre de la dette?

17. La technologie
Manque de connaissance
"Collisions" de développement
Suites de tests incomplètes
Refactoring repoussé
… (ex non exhaustifs)
Qu'est-ce qui engendre de la dette?

18. La vision
Manque d'ownership
Retard sur les standards d'industrie
Dépendance forte entre des composantes
… (ex non exhaustifs)
Qu'est-ce qui engendre de la dette?

19. Question:
Qui souffre de la dette?

20. Le produit
Le client
Le support
Le PO
L'équipe
Qui souffre de la dette?

21. Pour faire simple

22. Un produit technologique avec une dette non
maîtrisée est voué à disparaître

24. En bref,
La dette est inévitable et l'affaire de tous

25. Disclaimer

26. Dette Mal
Mauvaise gestion de dette Danger

27. L'importance de la gestion de
dette en agilité?

28. Ce que l'agilité nous permet:
Se rapprocher des besoins clients
Apporter de la valeur rapidement
Faire évoluer constamment la solution
Explorer, expérimenter en petits incréments

29. Les pièges
Se restreindre à
Valeur = fonctionnalité
Perdre la vision
Agilité = on verra, on s'adapte

30. Deux affirmations

31. Si je ne gère pas ma dette, je tombe facilement
dans le piège
⋎
Si je tombe dans le piège, je ne gère plus ma dette

32. Si je ne gère pas ma dette, je tombe facilement
dans le piège
⋎
Si je tombe dans le piège, je ne gère plus ma dette
OU (inclusif)

33. Les enjeux que cela soulève
Difficile de maintenir une cohérence dans la
conception du logiciel
Risque de repousser la maintenance à un "plus
tard" qui devient "jamais" dans l'objectif de livrer
plus de fonctionnalités rapidement

34. Cycle de livraison sans gestion de la dette
Dette volontaire ou
involontaire
Feature
Itération n
Dette volontaire ou
involontaire
Intérêt sur la dette
Feature
Itération n+x
Dette volontaire ou
involontaire
Intérêt sur la dette
Feature
Itération n+2x
Dette volontaire ou
involontaire
Intérêt sur la dette
Feature
Itération n+3x

35. Résultat?
Difficulté à découper en plus petits incréments
Difficulté à garder une équipe pluridisciplinaire
Difficulté à garder un produit évolutif

36. Agilité ….

38. Cycle de livraison avec gestion de la dette
Dette volontaire ou
involontaire
Feature
Itération n
Dette volontaire ou
involontaire
Intérêt sur la dette
Feature
Itération n+x
Gestion de la dette
Dette volontaire ou
involontaire
Intérêt sur la dette
Feature
Itération n+2x
Gestion de la dette
Dette volontaire ou
involontaire
Intérêt sur la dette
Feature
Itération n+3x
Gestion de la dette

39. Idéaliste
Crédit: Henrik Kniberg

40. Réaliste
Crédit: Henrik Kniberg

41. Disclaimer

42. La dette n'est PAS un problème d'agilité
Dette FAIT PARTIE d'un produit logiciel
(qu'importe la manière de le développer / livrer)
MAIS
Mauvaise gestion de dette impact l'agilité

43. Que se passe-t-il si j'ai de
la dette?

44. Que se passe-t-il, si j'ai
de la dette? !

45. 1. Accepter

47. Ce n'est pas grave!

48. Ce n'est pas grave!

49. C'est normal!

50. 2. Comprendre

51. "Nous n'avons pas le
temps pour le
design"
"Nous devons livrer
maintenant et gérer
les conséquences
(plus tard)"
"Maintenant, nous
savons comment
nous aurions dû le
faire"
"Qu'est-ce que les
micro services?"
Imprudent
Volontaire
Involontaire
Prudent

52. 3. Rendre visible

53. 3. Rendre visible

54. 4. Apprivoiser

56. Comment?

57. Mise en contexte:
Les exemples présentés pour illustrer les différents
points sont des outils testés lors de situations précises
D'autres outils peuvent être plus adaptés à votre
niveau de gestion de dette.

58. Situation de l'équipe en exemple:
Équipe avec un fort attachement à la qualité du
développement, consciente de la dette, faisant
beaucoup de refactoring "caché" dans les stories
Équipe supportant plusieurs produits développés par
d'autres équipes (peu de connaissance de l'état global
de la dette)
Équipe ayant à livrer un projet à haute valeur avec une
date go live fixe

59. Comment?

60. 1. Pour accepter, il faut identifier

61. En cours de développement

62. Backlog de dette

63. Bénéfices?
❖ Se libérer l'esprit
❖ Être conscient de l'état de la dette et de ce
que l'on ajoute
❖ Balancer les forces entre PO et équipe
pour les objectifs de livraisons
❖ Augmenter la confiance

64. 2. Pour comprendre, il faut
catégoriser/classer/estimer

65. Exemple de catégorisation à plusieurs
niveaux
Par priorité
● Critique
● Majeur
● Mineur
Par objectifs d'amélioration
● Maintenabilité
● Productivité
● Support
● Automatisation
● Sécurité
● Intégrité

66. ■ Connaître les dépendances
■ Connaître l'ampleur (estimation)
■ Connaître la fréquence d'utilisation
Comment prioriser et identifier si une
dette doit être traitée ou pas?

67. Bénéfices?
❖ Avoir une idée de l'ampleur (estimation)
❖ Connaître les éléments critiques
❖ Lâcher prise
❖ Mitiger le risque

68. 3. Pour rendre visible il faut
s'afficher

69. Inclure la dette dans les résultats
Go Live

70. Présenter les stories de dette

71. Visualiser globalement

72. Bénéfices?
❖ Montrer l'avancement
❖ Valoriser le travail de l'équipe
❖ Prendre de meilleures décisions d'affaires
❖ Avoir une compréhension commune de
l'état du produit

73. 4. Pour l'apprivoiser il faut interagir
avec elle

74. Identifier et visualiser sans jamais la
traiter
=
0 valeur

75. Identifier et visualiser sans jamais la
traiter
=
Valeur négative

76. Avoir une entente avec le PO d'une moyenne
de dette traitée par sprint.
A ajuster en fonction des besoins business et à travers le temps
Exemple de prise en main

78. Suivre son évolution

79. Suivre son évolution

80. Bénéfices?
❖ Maîtriser la vélocité de l'équipe
❖ Maintenir la qualité du produit
❖ Améliorer la compréhension du travail
effectué
❖ Orienter les décisions Produit et Techno

81. Disclaimer

82. Échantillons de visualisations
Beaucoup d'autres visualisations possibles une
fois les données récoltées et les besoins identifiés
Toutes les visualisations présentées NE SONT
PAS utilisées à chaque sprint

83. En bref!

84. La dette technique c'est
l'affaire de tous

85. Une gestion saine de la dette =
un produit bien maîtrisé

86. Toutes les dettes ne doivent pas
être remboursées

87. Difficile à mesurer, mais pas
impossible à apprivoiser

88. Merci!

89. Pour approfondir le sujet

90. En Français
https://www.accenture.com/fr-fr/insight-technology-debt-bankrupting
https://www.infoq.com/fr/articles/managing-technical-debt
http://www.modeli.fr/dette-technique-je-prendrai-une-fonctionnalite-en-plus-et-un-brin-de-desend
ettement/
En Anglais
https://labs.openviewpartners.com/what-is-your-technical-debt-ceiling/#.W-jnnnpKjq1
https://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt
https://www.softwaretestinghelp.com/technical-debt-and-qa/