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

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.

  • 2,724