Menu

Faire émerger l’architecture par l’équipe agile

Pablo richard

Rédigé par Pablo Richard - Techno - #agilité #architecture émergente #feature teamRédigé par Pablo Richard

PARTAGES

header_architecture_emergente.jpg

Une des équipes de VSC-Technologies, l’usine à logiciels de Voyages-sncf.com, a expérimenté une méthode collaborative pour faire émerger l’architecture d’une nouvelle brique technologique, on vous raconte un peu cette expérience stimulante.

Le manifeste agile* nous dit : « Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées ». S’il le dit, ça doit être vrai ! Lors de la création d’un nouveau système, comment faire participer toute l’équipe produit à l’émergence du design dans le contexte Voyages-sncf.com ?

Côté VSC Technologies, nous avons testé la méthode de Simon Brown**. Agilité oblige, tout est itératif et timeboxé . Voici un aperçu de notre implémentation :

     •    Première étape importante : faire le tour des services, pour agrémenter les prérequis logiciels : Sécurité, Support Client, Bases de données, Infrastructure réseau, qualité…

 

     •    Puis nous définissons les requirements/contraintes/principes fonctionnels et techniques.
 

Contraintes et principes fonctionnels

    •    Ensuite, on sépare l’équipe en petites équipes qui chacune planche sur une version d’architecture la plus complète possible.

    •    Plusieurs points rapides sont organisés pour se synchroniser et discuter des concepts d’archi détaillés (chaque petite équipe s’auto-organise).

    •    Au bout de quelques itérations, une architecture émerge.

La nomenclature et les livrables sont les mêmes pour toutes les équipes. On s’inspire du modèle dit « C4 »*** (Context diagram, Containers diagram, Components diagram et Classes Diagram). Dans notre cas, c’était plutôt la méthode C3, car nous n’avons pas fait les diagrammes de classes - clairement trop précis à ce stade – mais c’est utile d’indiquer la méthode d’origine 😉.

On organise ensuite des séances de « Risk Storming » : chaque petite équipe présente son architecture devant les autres équipes et des personnes extérieures (des « sachants », les releases managers, sécurité...).

Chacun identifie les risques qu’il détecte avec des post-it. L'emplacement des post-it sur les schémas fait converger les risques visuellement. Après discussions et priorisation, on choisit en équipe une architecture commune (avec aussi le choix du ou des Proof Of Concepts à commencer)

Enfin, vient le temps de présenter à l’écosystème : études, autres Feature Teams, référents architectures, et les autres services mis dans la boucle dès le début. Suivant le feedback, on adapte encore et toujours en mode itératif...

Le plus important ici n’est pas seulement le résultat – qui est très satisfaisant – mais aussi le fait que toute l'équipe participe. Cela permet une meilleure compréhension de l'objectif à atteindre et aussi une meilleure implication des personnes.

Si vous voulez en savoir plus, Simon Brown qui explique tout ça bien mieux 😉  :

 

 

Références :

*Wikipédia : "Manifeste agile"

**Simon Brown – coding the architecture

***Conférence – explication du modèle C4