Devoxx FR 2023 - Gestion de la dette d'architecture dans un contexte d'hypercroissance

La dette d’architecture est une sous partie de la dette technique qui traite des problèmes inhérents à l’architecture des systèmes d’information.

La dette d’architecture, causée par de nombreux facteurs techniques, organisationnels ou humains, augmente avec le temps et a des impacts majeurs sur la vélocité et la motivation des équipes.

Identifiée et mesurée, elle peut être réduite lors de transformations majeures ou refactorings ciblés. Alors que la dette technique est connue, outillée et couverte par de nombreuses thèses et articles, la dette d’architecture, malgré son potentiel impact majeur, n’est que très peu maitrisée.

Dans ce talk, j’aimerais partager le concept de dette d’architecture, détailler les travaux déjà effectués pour la définir et expliquer comment la mesurer grâce à la construction d’un framework au sein mon entreprise.

Ce travail est basé sur une expérience pratique dans une entreprise en hyper-croissance et sur le travail théorique de Roberto Verdecchia, Antonio Martin.

Transcript

1. GESTION DE LA DETTE D'ARCHITECTURE DANS UN CONTEXTE D'HYPERCROISSANCE CYRIL BESLAY 1
2. Cyril BESLAY Architecte Entreprise chez ManoMano  cicoub13 -  fotozik https://www.fotozik.fr 2
4. 1 - DETTE TECHNIQUE ET DETTE D'ARCHITECTURE 2 - COMMENT LA MANAGER ? 3 - MANOMANO ET LA DETTE 4
5. DETTE TECHNIQUE GLOBALE 5
6. Concept de développement logiciel inventé par Ward Cunningham en 1992 Créateur du wiki, co-créateur de l'eXtreme Programming, co-auteur du Manifesto Agile !!! 6
7. "implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer" 7
8. Je code en dur les jours fériés dans mon application de gestion de congés solution facile ✅ nécessite du travail supplémentaire dans le futur 🫣 une autre solution plus pérenne mais plus coûteuse existe (BDD) 🤔 8
10. DETTE FINANCIÈRE Pour accélerer un projet maintenant (maison, voiture) contraction d'un crédit et donc d'une dette 10
11. Les développeurs, ingénieurs, product managers, ... sont-ils de bons payeurs ? - Comment gérer cette dette sans autorité de contrôle (banque) ? - Un choix ? Un choix libre ? - Quand contracter une dette ? 11
12. DETTE D'ARCHITECTURE 12
13. De multiples types de dette : Technique (code, tests, infra, ...) Fonctionnelle (bugs) Sécurité Légale Architecture ... 13
14. "Dans un composant ou tout process fonctionnel, écart entre le système actuel et les principes d'architecture / standards de l'entreprise." 14
15. Pattern Circuit Breaker Tout appel API vers un service externe doit implémenter le pattern Circuit Breaker 15
16. Pattern Circuit Breaker Tout appel API vers un service externe doit implémenter le pattern Circuit Breaker L'équipe A développe un Micro Service qui fait des appels à l'API La Poste sans Circuit Breaker 16
17. Le POC qui devient la norme Une équipe a fait un POC avec une nouvelle technologie et l'a poussé en PROD pour vérifier l'attrait client 17
18. Le POC qui devient la norme Une équipe a fait un POC avec une nouvelle technologie et l'a poussé en PROD pour vérifier l'attrait client 6 mois plus tard, le POC est toujours là et l'équipe a changé 18
19. DETTE D'ARCHITECTURE - TYPOLOGIES choix facile (limité) d’une solution aujourd'hui par rapport à une meilleure approche mauvais choix de framework/outil produit qui stagne dans un contexte évolutif projet de migration non terminé création/changement de standards ... 19
20. Dette technique = analyse statique + outils Effort incrémental et faible 20
21. Dette d'architecture = analyse statique impossible Outils immatures et "inutiles" Difficile de quantifier l'impact, de prioriser Par où commencer ? 21
22. CAUSES 22
23. CAUSES PRINCIPALES EXTERNES 23
24. CAUSES PRINCIPALES EXTERNES Business Pression et délais raccourcis Non compréhension du concept de dette Domaine métier volatile Peu de vision long terme 24
25. CAUSES PRINCIPALES EXTERNES Business Standards d'architecture non/mal définis 25
26. CAUSES PRINCIPALES EXTERNES Business Standards d'architecture non/mal définis Temps qui passe 25.1
27. CAUSES PRINCIPALES INTERNES 26
28. CAUSES PRINCIPALES INTERNES Manque de connaissance 26.1
29. CAUSES PRINCIPALES INTERNES Manque de connaissance Mauvaises décisions d'architecture 26.2
30. CAUSES PRINCIPALES INTERNES Manque de connaissance Mauvaises décisions d'architecture Manque d'anticipation 26.3
31. CAUSES PRINCIPALES INTERNES Manque de connaissance Mauvaises décisions d'architecture Manque d'anticipation Facteurs humains diverses 26.4
33. SYMPTÔMES ET CONSÉQUENCES 28
35. "Il n'y a que John qui sait gérer ça" 2 micro services sont toujours livrés en même temps Temps pour analyser/résoudre un bug Complexité excessive (3 systèmes en parallèle) 30
36. Augmentation des coûts pour les nouvelles fonctionnalités Augmentation des bugs Augmentation des risques de régressions/crashs Augmentation du niveau de compétence requis Diminution de la qualité du produit 31
38. MANAGEMENT DE LA DETTE D'ARCHITECTURE 33
39. Pour un crédit (dette), il y a toujours quelqu’un pour vous rappeler qu’il faut payer tous les mois (banque) 34
40. ⚠️ Accumuler des dettes Banqueroute = tout jeter / non maintenable / plus de temps à fixer qu’à ajouter de la valeur 35
41. CONTRÔLE DE LA CRÉATION DE LA DETTE RÉDUCTION DE LA DETTE EXISTANTE 36
42. CONTRÔLE DE LA CRÉATION DE LA DETTE 37
43. 🎯 Ne pas créer de dette 38
44. 🎯 Ne pas créer de dette = 🐌 Ne pas saisir les opportunités d'accélération/d'innovation 38.1
45. BONNES PRATIQUES Penser l'architecture / Faire de la conception 39
46. BONNES PRATIQUES Penser l'architecture / Faire de la conception Anticiper les besoins fonctionnels 40
47. BONNES PRATIQUES Penser l'architecture / Faire de la conception Anticiper les besoins fonctionnels Noter les décisions et leurs impacts via ADR 41
48. BONNES PRATIQUES Penser l'architecture / Faire de la conception Anticiper les besoins fonctionnels Noter les décisions et leurs impacts via ADR Créer des tickets de dette 42
49. RÉDUCTION DE LA DETTE EXISTANTE 43
50. STRATÉGIE ACTIVE DE MANAGEMENT 44
51. STRATÉGIE ACTIVE DE MANAGEMENT Règle du Scout 45
52. STRATÉGIE ACTIVE DE MANAGEMENT Scout Rule 20% temps par Sprint 46
53. STRATÉGIE ACTIVE DE MANAGEMENT Scout Rule 20% temps par Sprint Investir plus de temps dans les plans de refactor/architecture 47
54. STRATÉGIE RÉACTIVE DE MANAGEMENT 48
55. STRATÉGIE RÉACTIVE DE MANAGEMENT Correction opportuniste (nouveau gros projet) 49
56. STRATÉGIE RÉACTIVE DE MANAGEMENT Correction opportuniste (nouveau gros projet) Gel des nouvelles fonctionnalités 50
57. STRATÉGIE RÉACTIVE DE MANAGEMENT Correction opportuniste (nouveau gros projet) Gel des nouvelles fonctionnalités Réecrire en entier un composant/process 51
58. RÉDUCTION RÉACTIVE VS RÉDUCTION ACTIVE 52
59. STRATÉGIE PASSIVE DE MANAGEMENT Délaisser (rapport coût/risque trop élevé) 53
60. Beaucoup plus simple de tout jeter que d’améliorer continuellement MAIS les gens n’apprennent pas 54
61. CONSTRUCTION D'UN FRAMEWORK POUR IDENTIFIER ET MESURER CETTE DETTE 55
63. IL ÉTAIT UNE FOIS ... 57
64. BANQUEROUTE 2016 - 9 mois de gel fonctionnel 10 Développeurs De PHP à Symfony 58
65. FACTURATION À LA MAIN Nouveau service lancé avec facturation depuis Google Sheet 59
66. NOTRE CTO 60
67. CONTRÔLE DE CRÉATION DE LA DETTE 61
68. GUIDELINES 62
69. RADIOLOGIST 63
70. Chez ManoMano Projet X ne suit pas les standards Ça marche, on fait + de ventes 🚀 On corrige la dette Chez Airbus Projet X ne suit pas les standards Avion qui ne décolle pas 🛬 64
71. TECH RADAR 65
72. RÉDUCTION DE LA DETTE 66
73. Plus de dette Identifier et mesurer pour prendre les meilleurs décisions Contrôler en réduisant 67
74. PREMIÈRE APPROCHE 68
75. SECONDE APPROCHE Récolte de données par méthode qualitative Entretiens en 2 parties avec équipes Techniques (Managers et Tech Lead) 69
76. QUELQUES QUESTIONS "Si vous aviez carte blanche, quelle partie de votre périmètre vous voudriez refactorer ? Pour quelles raisons ?" "Quels échanges avec d'autres équipes ou systèmes vous paraissent complexes ou fragiles ?" "Avez-vous pris de gros raccourcis par rapports aux standards de <theme> ?" "Êtes-vous en retard dans la maintenance de vos librairies open-source ?" 70
78. CARACTÉRISER 72
79. POUR CHAQUE ARCHITECTURE BUILDING BLOCK Risque Quel est le risque que cela crée des problèmes dans le futur ? Temps Quand cela risque-t-il d'arriver ? Impact Quel impact sur l'utilisateur final ? Efficacité Quel impact sur l'efficacité de l'équipe ? Déviation Quel est l'écart vis-à-vis de nos standards ? 73
84. VUE ENTREPRISE Travail en cours 78
85. CHALLENGER Mettre en corrélation les résultats des enquêtes avec : la fréquence des incidents par domaine la vélocité des équipes (Epic Cycle Time) depuis JIRA le suivi des Programmes / migrations la mesure de la dette technique brute depuis Sonar / JIRA 79
86. PRIORISER Présentation des cartes, des alertes aux CTO + Directeurs Techniques Sensibilisation du business sur les notions de dette technique Segmentation des tâches nécessaires en plus petits morceaux Suivi et collecte chaque trimestre 80
87. "La dette est trop importante dans cette partie du système, il faut la nettoyer avant de faire de nouvelles fonctionnalités." 81
88. QUELQUES RETOURS D'EXPÉRIENCE Reconnaître que la dette technique n'est pas toujours mauvaise Combattre les idées reçues dans toute l'entreprise Arrêter de tout mettre sous le tapis "dette technique" Revoir les critères de score + une note Métier ? Itérer et améliorer 82
89. TAKEWAYS 83
90. TAKEWAYS Définir ses standards/principes d'architecture 83.1
91. TAKEWAYS Définir ses standards/principes d'architecture Démystifier la dette dans toute l'entreprise 83.2
92. TAKEWAYS Définir ses standards/principes d'architecture Démystifier la dette dans toute l'entreprise Identifier et caractériser régulièrement 83.3
93. TAKEWAYS Définir ses standards/principes d'architecture Démystifier la dette dans toute l'entreprise Identifier et caractériser régulièrement Adopter différentes stratégies de management 83.4
94. TAKEWAYS Définir ses standards/principes d'architecture Démystifier la dette dans toute l'entreprise Identifier et caractériser régulièrement Adopter différentes stratégies de management Construire ses propres outils 83.5
95. BIBLIOGRAPHIE - Keya Patel (Michigan) - Roberto Verdecchia (Amsterdam) - Antonio Martini (Oslo) 84
97. Merci 86