Apprivoiser la dette technique

Un produit logiciel est basé sur des idées, des fonctionnalités mais aussi et surtout de la technologie. Cette technologie doit être en mesure de répondre aux deux premiers.

La dette technique est un concept qui fait partie intégrante d'un produit technologique. De part sa nature de "dette", elle fait souvent peur et est facilement oubliée dans l'equation de la qualité et de l'intégrité du produit.

Hors une dette technique non maîtrisée peut vite se transformer en un boulet qui va venir vampiriser la productivité des équipes et détruire la valeur d'un produit

Dans cette conférence, je présente comment mieux cerner cette dette et ses enjeux. J'aborde des exemples d'outils éprouvés au sein de mes équipes pour reprendre en main une dette technique déjà existante et valoriser l'importance de la gestion de cette dernière à tous les niveaux de l'entreprise.
Une gestion saine de la dette technique nous permettant de garder heureux: développeurs, clients et utilisateurs

Transcript

1. Apprivoiser la dette technique 15 novembre 2018 Elodie Micoulet Agile Tour Montreal - ATMTL18
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/