lundi 22 septembre 2008

Architecture Agile


Dans le contexte d'améliorer le travail sur l'architecture d'un projet multi-équipe, je suis tombé sur l'article Agile Architecture : Strategies for Scaling Agile Development de Scott W. Ambler. A sa lecture, j'ai pu relier les mises en gardes de l'auteur avec l'organisation de notre "Groupe Architecture" (dont personne n'est vraiment satisfait). J'espère que ses bons conseils nous feront avancer!

En introduction, Scott insiste sur les 3 points suivants:
  • Humilité : au sein d'un projet, la valeur d'une personne ne dépend pas de sa fonction. Un architecte ne doit pas se mettre (ou être mis) sur un piédestal.
  • Tour d'ivoire : il ne fait pas créer la tour d'ivoire des architectures. Au contraire, ces derniers doivent être présents sur le terrain, au sein des équipes.
  • Tout système a une architecture : il faut avoir conscience que tout logiciel a une architecture. Le travail sur cette dernière permet de maintenir une vision commune et un partage collectif du code (collective code ownership)
Ensuite, il donne ses conseils et les bonnes pratiques suivantes:
  • Architect Owner : les parties prenantes du projet (propriétaire du produit, représentant du client, etc..) ne travaillent pas sur l'architecture mais sur les exigences. Elles ne peuvent donc pas coordonner le travail sur ce sujet. C'est pour cette raison, qu'il faut un rôle de Architect Owner qui aura la responsabilité de faciliter le travail sur l'architecture du produit. Attention, ce n'est pas son rôle de décider, mais plutôt d'animer l'équipe des architectes du projet.
  • L'équipe d'architectes : si il y a 10 personnes dans un projet, Scott suggère que les 10 soient aussi l'équipe d'architectes. Sinon, en général, 1 ou 2 personnes de chaque endossent le rôle d'architecte. Attention, il ne s'agit pas d'une équipe comme les autres : chaque architecte travaille dans son équipe: il est au service de celle-ci est agi comme un consultant en architecture. Son rôle est aussi de communiquer l'architecture vers les parties prenantes du projet. Il est bon que ce ne soit pas toujours les même personnes qui soient architectes, bien que ce rôle requiert d'avoir "de la bouteille".
  • Architecture dirigée par les exigences : les exigences viennent avant tout des parties prenantes et non des développeurs! Les aspects métiers doivent être confiés à des utilisateurs, à leurs managers, etc.. Une erreur classique consiste à ignorer certains aspects métier qui ont un fort impact sur l'architecture du produit : par exemple un environnement régulé par un standard, des règles métiers de déploiement. Parler avec les bonnes personnes permet d'économiser beaucoup de temps.
  • Modéliser l'Architecture : ici, pas de dictat pout tel ou tel type de diagramme UML! Il faut choisir le support qui apportera le plus de valeur aux équipes, et pas plus. Pas besoin de documentation formelle si des dessins sur tableaux suffisent.
  • Voyager léger (travel light) : plutôt que de documenter exhaustivement l'architecture, en expliquer plutôt ses limites, les zones critiques, les problèmes, etc..
  • Eprouver l'architecture : la seule façon d'éprouver une conception, c'est de l'implémenter! Faire alors des prototypes afin de vérifier tôt dans le projet certains choix : de cette façon, on réduit les risques de découvrir qu'une architecture ne tiendra pas la route au bout de 6 mois d'implémentation.
  • Communiquer l'architecture : l'affichage des documents d'architecture est public. Une visibilité extrême permet d'obtenir des feedbacks rapides et nombreux. les architectes communiquent aux équipes mais aussi aux parties prenantes. L'objectif n'est pas le même dans les deux cas et la façon de faire sera différente. Pour les parties prenantes, penser à adapter les informations (pas de détails) dans un contexte compréhensible afin de donner confiance et susciter une implication de ces dernières dans le projet.
  • Penser au futur mais ne pas en faire plus : avant tout, penser YAGNI (you ain't gonna need it anyway). Ne pas tenir compte des exigences futures, sauf si elle ont de très grandes chances de survenir : on parle alors ici de cas de changement (change case). On doit travailler seulement sur les besoins du moment, mais il arrive que les cas de changement nous orientent entre plusieurs alternatives, ce qui est une bonne chose. Attention, là aussi, la priorité entre les différents cas de changement est définie par les parties prenantes.
  • Approche multi-vue : Scott nous conseille de travailler sur un espace à deux axes, où le type de vue (stockage, réseau, déploiement...) et les préoccupations (qualité, performance, robustesse, etc..) sont chacun des deux axes. Il en résulte que le travail des architectes concerne un très large spectre de problèmes et les compétences de ceux-ci doivent se généraliser à plusieurs domaines.
En guide le conclusion, Scott compare les pratiques traditionnelles de gestion de l'architecture à celles dites agiles dans le tableau ci-dessous:

Pratique traditionnelle

Pratique Agile

Les architectes sont tenus en haute estime et sont souvent placés sur un piédestal

Les architecte agiles ont l’humilité d’admettre qu’ils ne marchent pas sur l’eau

Les architectes sont trop occupés pour se salir les mains avec le développement

Les architecte agiles sont des membres actifs des équipes de développement, codant du logiciel et agissant comme des consultants en architecture au service de l’équipe

Les modèles d’architecture sont robustes de telle sorte qu’ils satisferont les exigences futures des clients

Les architecte agiles ont l’humilité d’admettre qu’ils ne peuvent pas prédire le futur et, au lieu de cela ils ont le courage de croire qu’ils pourront résoudre les problèmes de demain, demain (pas aujourd'hui)

L’objectif est de développer une architecture détaillée tôt dans le projet

Vous faites évoluer votre architecture de façon incrémentale et itérative, autorisant cette dernière à émerger avec le temps

Des modèles d’architecture bien documentés font partie des exigences

Voyager léger et se concentrer sur les diagrammes de navigation qui donne une vue d’ensemble de l’architecture, en documentant juste ce qu’il faut pour communiquer à votre audience

Les Modèles d’architecture sont communiqués seulement quand ils sont « appropriés à une consommation du public »

Les modèles d’architecture sont affichés publiquement, même quand il y a du travail en cours, afin de susciter des retours de la part des autres

Les revues d’architectures sont tenues pour valider les modèles avant qu’ils soient utilisés

L’architecture est éprouvée à travers des expérimentations concrètes