Gérer
une architecture technique dans
un environnement agile
Vincent Ogloblinsky - @vogloblinsky
Vincent Ogloblinsky
Software architect
Compodoc maintainer
Google Developer Expert on Web Technologies
Disclaimer
Ce n’est que mon point de vue
Ce n’est qu’un survol
Je vais enfoncer des portes ouvertes, mais ça fait du bien parfois de redire les choses, encore et encore
Agenda
1.
Le changement...
2.
Architecture " agile " 🤔
3.
Approches
4.
En pratique
Le changement
Le changement
Historiquement :
cycle en V avec un bon cycle de conception initial
Maintenant :
on développe et on conçoit au fur et à mesure
Le changement
Technique
Métier
Langages
Librairies
Frameworks
Outils
Environnements d’exécution
Contraintes techniques
Modèle de revenu
Technologie de base d'adoption
Concurrents
Besoins clients
Marché
Produits
Le changement
Inévitable et permanent
Monde de l'IT très dynamique (performance, scalabilité, interopérabilité, sécurité, SLA, ...)
Nos applicatifs et systèmes sont-ils réactifs ?
Et si on architecturait pour accueillir le changement ?
Architecture
"agile" ? 🤔
Architecture "agile" ? 🤔
Elle accueille le changement, c'est dans son ADN
Reste concentré sur la "valeur" apporté au "produit"
Décisions importantes pas forcément au début du projet
Arrête de penser que certaines choses sont irréversibles
Architecture "agile" ?
“ Responding to change ”
Mais au fait,
c'est quoi une "architecture" ?
Architecture - Définition
“ The important stuff (whatever that is) ”
“ The shared understanding of people within a project ”
Ralph Johnson
Design Patterns: Elements of Reusable Object-Oriented Software
“ Decisions that are important and hard to change ”
Martin Fowler
Architecture - Caractéristiques
Architecture - avec l'agilité
Amélioration
continue
Conception
Architecture
Implémente
Délivre +
Feedback
Les approches
Les approches
The Full-stack Software Design & Architecture Map
Les approches
Les approches
Les approches
Les approches
Les approches
Les approches
Les approches
En pratique
Comment ?
Technique
Métier
Déploiement continu
Boucle de feedback rapide
Couplage approprié
Ports et adapteurs
Fonctions de santé automatiques
S'adapter aux possibilités business
Produits plutôt que projets
Equipe cross-fonctionnel
Autoriser l'expérimentation
Gouvernance décentralisée
Comment ?
Partage, amélioration : XP, review, pair-pro, mobpro
Choix technologique pour le produit/métier, pas pour les devs
APIs désignées "métier" et pas "technique"
Domain Driven Design (si nécessaire)
Partage dans l'équipe du fonctionnement global
Comment ?
Partager des exemples de références de code (Ctrl-C/Ctrl-V)
Idéalement : tt le monde ensemble (tech, métier, QA, ...)
Bon Sens Driven Development - BSDD
Sprint technique
Laisser du temps aux devs pour gérer leur dette
🚨 Warnings
Pas trop de .doc, .pdf
Big Design Up Front
Loi de Conway
Frameworks / languages
📋 A Retenir
C'est une sacrée aventure !
Concentrez-vous sur ce qui est important
Amélioration et apprentissage permanent
Rester pragmatique
Prenez du plaisir avant tout !
Merci pour votre attention !
Disponible pour toutes questions
Slides : bit.ly/afup-day-2021-rennes
Crédit photos - Unsplash.com
Gérer une architecture technique dans un environnement agile
By Vincent Ogloblinsky
Gérer une architecture technique dans un environnement agile
Dans notre industrie, la seule chose qui est inévitable c’est le changement. Ce que nous utilisons ou créons à un instant T peut vite devenir obsolète pour diverses raisons (techniques, sectorielles, …), et sera remplacé par quelques chose de nouveau. La nécessité de livrer de la valeur rapidement dans un contexte agile a bousculé la manière de concevoir des architectures techniques. Entre la philosophie DevOps, et la création d’équipe de plus en plus autonome et indépendante, l'architecture technique doit s'adapter à cette nécessité croissante d’aller et de grandir vite. Comment planifier et concevoir un système en sachant que les problèmes d’aujourd’hui sont complètement différents des problèmes de demain ? Quelle gouvernance adopter ? Quelles bases posées de manière pérenne mais en étant flexible ? Pourquoi de temps à autre les architectures deviennent un frein au lieu de proposer un terreau pour amener de la valeur au produit ? Pourquoi le terme « architecte logiciel » devient quelque chose de négatif pour certain(e) ? L’architecture technique idéale n’existe pas, à l'inverse le dogme « pas d’architecture » également. Nous allons voir dans ce talk quels sont les principes de design et les méthodes que les développeurs ont à leur disposition aujourd’hui pour accueillir le changement facilement et délivrer de la valeur rapidement.
