L’architecture dans les projets agiles

Un des principes du manifeste agile est “l’adaptation au changement plus que le suivi d’un plan”. Il est donc établi que le projet, et donc son architecture, peuvent évoluer au fil des développements. On va donc éviter une architecture conçue en amont des développements et figée, le “big design up front », pour lui préférer une architecture évolutive, conçue au fil des développements, qu’on appelle “architecture émergente”. Au même titre qu’on accepte et encourage le “refactoring” du code applicatif, on considère qu’il est possible et souhaitable de pouvoir faire du “refactoring” d’architecture.

Il est possible, par exemple, de démarrer un projet Web en “Server side rendering” Ruby on Rails, pour évoluer ensuite vers une séparation entre un frontend React et des API Ruby on Rails.

Nous allons voir dans la suite quelques exemples d’organisation pour traiter les sujets d’architecture.

Un architecte d’entreprise extérieur au projet agile ?

Le recours à un architecte étranger à l’équipe agile, et donc extérieur à la démarche d’amélioration continue, peut déboucher sur un “big design up front ». Il peut avoir tendance à proposer une solution complexe répondant aux besoins d’une cible, qui n’arrivera jamais,…, plutôt qu’aux besoins immédiats du projet.

Si l’on reprend notre exemple de projet Web, l’architecture cible React/Rails nécessite 2 technologies, donc probablement deux développeurs. Elle nécessite une authentification des utilisateurs sur le front end, mais aussi sur le backend, ce qui génère une complexité technique, un risque en termes de sécurité. Ce choix d’architecture a donc trois impacts : coût supplémentaire, complexité technique, risque de sécurité. Le déroulé du projet pourra démontrer l’inutilité de cette complexité…

Pas d’architecte ?

L’interprétation à la lettre du manifeste agile pourrait déboucher sur l’absence d’architecte. En effet, puisque l’architecture évolue, autant qu’elle soit choisie par l’équipe de développement, qui fera son refactoring au même titre que celui du code. Le risque de cette approche est de passer à côté de “patterns d’architecture” classiques.

Si on prend l’exemple de l’authentification, on peut imaginer un développeur junior qui stocke des mots de passe en clair dans une base de données et les envoie par email lorsqu’on clique sur “mot de passe oublié ». Ceci constitue un “anti-pattern de sécurité” : les mot de passe doivent être hachés en base (chiffrement irréversible) et jamais restitués.

Le Tech Lead comme architecte !

Le tech lead est un développeur expérimenté qui connaît les “patterns d’architecture”. Son rôle se situe à la croisée des chemins entre architecture et développement. Il sait identifier ses limites et solliciter un architecte au bon moment dans le cycle de développement. Il est donc le meilleur candidat à la construction d’une architecture émergente, qui respecte les grands patterns d’architecture.

Pour plus d’informations, retrouvez également :

Le Tech Lead, qu’est-ce que c’est ?

[Replay] Réunion d’Information : Executive Certificate Tech Lead