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

Crédit photos - Unsplash.com