Arkup Meetup Nantes 2023 - Gestion de la dette d'architecture dans un contexte d'hypercroissance

Transcript

3. Cyril BESLAY Architecte Entreprise chez ManoMano  cicoub13 -  fotozik https://www.fotozik.fr 3
5. 1 - DETTE TECHNIQUE ET DETTE D'ARCHITECTURE 2 - COMMENT LA MANAGER ? 3 - MANOMANO ET LA DETTE 5
6. DETTE TECHNIQUE GLOBALE 6
7. 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 !!! 7
8. "implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer" 8
9. 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) 🤔 9
11. DETTE FINANCIÈRE Pour accélerer un projet maintenant (maison, voiture) contraction d'un crédit et donc d'une dette 11
12. 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 ? 12
13. DETTE D'ARCHITECTURE 13
14. De multiples types de dette : Technique (code, tests, infra, ...) Fonctionnelle (bugs) Sécurité Légale Architecture ... 14
15. "Dans un composant ou tout process fonctionnel, écart entre le système actuel et les principes d'architecture / standards de l'entreprise." 15
16. Pattern Circuit Breaker Tout appel API vers un service externe doit implémenter le pattern Circuit Breaker 16
17. 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 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 18
19. 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é 19
20. 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 ... 20
21. Dette technique = analyse statique + outils Effort incrémental et faible 21
22. Dette d'architecture = analyse statique impossible Outils immatures et "inutiles" Difficile de quantifier l'impact, de prioriser Par où commencer ? 22
23. CAUSES 23
24. CAUSES PRINCIPALES EXTERNES 24
25. 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 25
26. CAUSES PRINCIPALES EXTERNES Business Standards d'architecture non/mal définis 26
27. CAUSES PRINCIPALES EXTERNES Business Standards d'architecture non/mal définis Temps qui passe 26.1
28. CAUSES PRINCIPALES INTERNES 27
29. CAUSES PRINCIPALES INTERNES Manque de connaissance 27.1
30. CAUSES PRINCIPALES INTERNES Manque de connaissance Mauvaises décisions d'architecture 27.2
31. CAUSES PRINCIPALES INTERNES Manque de connaissance Mauvaises décisions d'architecture Manque d'anticipation 27.3
32. CAUSES PRINCIPALES INTERNES Manque de connaissance Mauvaises décisions d'architecture Manque d'anticipation Facteurs humains diverses 27.4
34. SYMPTÔMES ET CONSÉQUENCES 29
36. "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) 31
37. 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 32
39. MANAGEMENT DE LA DETTE D'ARCHITECTURE 34
40. Pour un crédit (dette), il y a toujours quelqu’un pour vous rappeler qu’il faut payer tous les mois (banque) 35
41. ⚠️ Accumuler des dettes Banqueroute = tout jeter / non maintenable / plus de temps à fixer qu’à ajouter de la valeur 36
42. CONTRÔLE DE LA CRÉATION DE LA DETTE RÉDUCTION DE LA DETTE EXISTANTE 37
43. CONTRÔLE DE LA CRÉATION DE LA DETTE 38
44. 🎯 Ne pas créer de dette 39
45. 🎯 Ne pas créer de dette = 🐌 Ne pas saisir les opportunités d'accélération/d'innovation 39.1
46. BONNES PRATIQUES Penser l'architecture / Faire de la conception 40
47. BONNES PRATIQUES Penser l'architecture / Faire de la conception Anticiper les besoins fonctionnels 41
48. BONNES PRATIQUES Penser l'architecture / Faire de la conception Anticiper les besoins fonctionnels Noter les décisions et leurs impacts via ADR 42
49. 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 43
50. RÉDUCTION DE LA DETTE EXISTANTE 44
51. STRATÉGIE ACTIVE DE MANAGEMENT 45
52. STRATÉGIE ACTIVE DE MANAGEMENT Règle du Scout 46
53. STRATÉGIE ACTIVE DE MANAGEMENT Scout Rule 20% temps par Sprint 47
54. STRATÉGIE ACTIVE DE MANAGEMENT Scout Rule 20% temps par Sprint Investir plus de temps dans les plans de refactor/architecture 48
55. STRATÉGIE RÉACTIVE DE MANAGEMENT 49
56. STRATÉGIE RÉACTIVE DE MANAGEMENT Correction opportuniste (nouveau gros projet) 50
57. STRATÉGIE RÉACTIVE DE MANAGEMENT Correction opportuniste (nouveau gros projet) Gel des nouvelles fonctionnalités 51
58. STRATÉGIE RÉACTIVE DE MANAGEMENT Correction opportuniste (nouveau gros projet) Gel des nouvelles fonctionnalités Réecrire en entier un composant/process 52
59. RÉDUCTION RÉACTIVE VS RÉDUCTION ACTIVE 53
60. STRATÉGIE PASSIVE DE MANAGEMENT Délaisser (rapport coût/risque trop élevé) 54
61. Beaucoup plus simple de tout jeter que d’améliorer continuellement MAIS les gens n’apprennent pas 55
62. HYPERCROISSANCE 56
64. IL ÉTAIT UNE FOIS ... 58
65. BANQUEROUTE 2016 - 9 mois de gel fonctionnel 10 Développeurs De PHP à Symfony 59
66. RÉDUCTION PAR LA CRISE Tunnel d'achat 60
67. FACTURATION À LA MAIN Nouveau service lancé avec facturation depuis Google Sheet 61
68. NOTRE CTO 62
69. CONSTRUCTION D'UN FRAMEWORK POUR IDENTIFIER ET MESURER CETTE DETTE 63
70. CONTRÔLE DE CRÉATION DE LA DETTE 64
71. GUIDELINES 65
72. RADIOLOGIST 66
73. 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 🛬 67
74. TECH RADAR 68
75. RÉDUCTION DE LA DETTE 69
76. Plus de dette Identifier et mesurer pour prendre les meilleurs décisions Contrôler en réduisant 70
77. PREMIÈRE APPROCHE 71
78. SECONDE APPROCHE Récolte de données par méthode qualitative Entretiens en 2 parties avec équipes Techniques (Managers et Tech Lead) 72
79. 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 ?" 73
81. CARACTÉRISER 75
82. 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 ? 76
85. QUELQUES CHIFFRES 36 équipes interviewées 36 heures + un peu de travail asynchrone une centaine d'ABB notés 79
86. QUELQUES CHIFFRES 36 équipes interviewées 36 heures + un peu de travail asynchrone une centaine d'ABB notés Moyenne à 2,98/10 🎉 79.1
87. QUELQUES RETOURS "Bonne (ré)introduction à la notion de dette technique" "Enfin un moyen de communiquer notre ressenti" "Les critères sont complexes la première fois" "Difficile de penser aux process non tech" "Peut-on inclure toute l'équipe dans la prochaine itération ?" 80
88. CHALLENGER LES SCORES 81
89. CHALLENGER LES SCORES Incohérences de notations entre les équipes 81.1
90. CHALLENGER LES SCORES Incohérences de notations entre les équipes Certains composants sont masqués par la note moyenne 81.2
91. CHALLENGER LES SCORES Etapes ajoutées : challenger les ABB les plus endettés avec les Managers possibilité de mettre en avant 1 ou 2 composants endettés par ABB 82
94. VUE ENTREPRISE Travail en cours 85
95. ENRICHIR Mettre en corrélation les résultats des interviews avec : 86
96. ENRICHIR Mettre en corrélation les résultats des interviews avec : la fréquence des incidents/bugs par composant 86.1
97. ENRICHIR Mettre en corrélation les résultats des interviews avec : la fréquence des incidents/bugs par composant la vélocité des équipes (Epic Cycle Time) depuis JIRA 86.2
98. ENRICHIR Mettre en corrélation les résultats des interviews avec : la fréquence des incidents/bugs par composant la vélocité des équipes (Epic Cycle Time) depuis JIRA le suivi des Programmes / migrations et leurs impacts 86.3
99. ENRICHIR Mettre en corrélation les résultats des interviews avec : la fréquence des incidents/bugs par composant la vélocité des équipes (Epic Cycle Time) depuis JIRA le suivi des Programmes / migrations et leurs impacts la mesure de la dette technique brute depuis Sonar 86.4
100. Vous devez connaître votre système et votre organisation 87
101. PRIORISER Présentation des cartes, des alertes aux CTO + Directeurs Techniques Sensibilisation du business sur les notions de dette technique Choix de 3 sujets transverses par Trimestre Prochain trimestre : Un outil BI déprécié, migration vers Kafka TLS, réduction PHP 88
102. SUIVI DES ACTIONS AVANT : Excels avec mises à jour manuelles et pas de vision globale 89
103. SUIVI DES ACTIONS AVANT : Excels avec mises à jour manuelles et pas de vision globale MAINTENANT: Tickets JIRA avec Initiatives (par thème) et tableaux de bord 89.1
105. BONUS: JellyFish Vision entreprise / par train / équipe 91
106. CE QUI NE MARCHE PAS :( Difficile de trouver un rythme efficace pour les interviews Toujours quelques parties inconnues/cachées Encore beaucoup d'actions manuelles Pas d'outil pour stocker l'état et l'évolution (Excel) 92
107. "La dette est trop importante dans cette partie du système, il faut la nettoyer avant de faire de nouvelles fonctionnalités." 93
108. QUELQUES RETOURS SUR L'APPROCHE 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 Identifier et prioriser les actions/plans à mener 94
109. PROCHAINES ÉTAPES 95
110. PROCHAINES ÉTAPES Revoir les critères de score / ajouter une note Métier 95.1
111. PROCHAINES ÉTAPES Revoir les critères de score / ajouter une note Métier Itérer et améliorer les interviews 95.2
112. PROCHAINES ÉTAPES Revoir les critères de score / ajouter une note Métier Itérer et améliorer les interviews Trouver/Construire un outil de suivi de l'état 95.3
113. TAKEWAYS 96
114. TAKEWAYS Définir ses standards/principes d'architecture 96.1
115. TAKEWAYS Définir ses standards/principes d'architecture Démystifier la dette dans toute l'entreprise 96.2
116. TAKEWAYS Définir ses standards/principes d'architecture Démystifier la dette dans toute l'entreprise Identifier et caractériser régulièrement 96.3
117. 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 96.4
118. 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 96.5
119. BIBLIOGRAPHIE - Keya Patel (Michigan) - Roberto Verdecchia (Amsterdam) - Antonio Martini (Oslo) 97
120. Nicola Sannelli - Auchan Retail Maîtriser la dette informatique Archilocus Juin 2023 98
121. QUESTIONS / DÉBAT 99