BDX I/O 2022 - Gestion de la dette d'architecture dans un contexte d'hypercroissance

Transcript

1. GESTION DE LA DETTE D'ARCHITECTURE DANS UN CONTEXTE D'HYPERCROISSANCE CYRIL BESLAY 1
2. Cyril BESLAY Architecte chez ManoMano @cicoub13 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" TODO/FIXME dans le code Temps pour 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 Boy Scout 45
52. STRATÉGIE ACTIVE DE MANAGEMENT Boy Scout Rule 20% temps par Sprint 46
53. STRATÉGIE ACTIVE DE MANAGEMENT Boy Scout Rule 20% temps par Sprint Investir plus de temps dans le design/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
64. QUELQUES HISTOIRES DE DETTE... 57
65. BANQUEROUTE 2016 - 9 mois de gel fonctionnel 10 Développeurs De PHP à Symfony 58
66. FACTURATION À LA MAIN Nouveau service lancé avec facturation depuis Google Sheet 59
67. NOTRE CTO 60
68. CONTRÔLE DE CRÉATION DE LA DETTE 61
69. GUIDELINES 62
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 🛬 63
71. TECH RADAR 64
72. RÉDUCTION DE LA DETTE 65
73. Plus de dette Contrôler en réduisant Identifier pour prendre les meilleurs décisions 66
74. PREMIÈRE APPROCHE 67
75. SECONDE APPROCHE Récolte de données par méthode qualitative Entretiens en 2 parties avec équipes Techniques (Managers et Tech Lead) 68
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 ?" 69
78. CARACTÉRISER 71
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 ? Déviation Quel est l'écart vis-à-vis de nos standards ? Niveau de dette Quel est le précédent score ? 72
84. VUE ORGANISATIONNELLE Travail en cours 77
85. 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 78
86. "La dette est trop importante dans cette partie du système, il faut la nettoyer avant de faire de nouvelles fonctionnalités." 79
87. 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 Business ? Itérer et améliorer 80
88. TAKEWAYS 81
89. TAKEWAYS Définir ses standards/principes d'architecture 81.1
90. TAKEWAYS Définir ses standards/principes d'architecture Démystifier la dette dans toute l'entreprise 81.2
91. TAKEWAYS Définir ses standards/principes d'architecture Démystifier la dette dans toute l'entreprise Identifier et caractériser régulièrement 81.3
92. 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 81.4
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 Construire ses propres outils 81.5
94. BIBLIOGRAPHIE - Keya Patel (Michigan) - Roberto Verdecchia (Amsterdam) - Antonio Martini (Oslo) 82
95. https://jobs.manomano.com/ 83
96. Merci 84