Un nouveau type d’architecte: l’Architecte Agile

Ce billet est une libre traduction de l’article posté par notre collègue Vikas Hazrati sur le site Agile Journal.

On observe ces derniers temps de multiples débats sur le fait de savoir si une équipe agile a besoin d’un architecte en son sein, et sur la valeur ajoutée de ce dernier sur un projet agile alors que l’architecture évolue à chaque itération.
Les architectes « Tour d’Ivoire » se révèlent petit à petit être le maillon faible des projets agiles. Les responsabilités des architectes traditionnels sont distribuées ci et là au sein des équipes agiles, leur supprimant au passage des tâches qui leur étaient auparavant attribuées.
Une nouveau genre est en train d’apparaître et de sortir du lot comme le prédit la théorie de l’évolution de Charles Darwin – question d’adaptation. Le rôle d’un Architecte Agile ne doit pas susciter de questions et tout membre d’une équipe agile vous le confirmera: ce sont des équipiers qui apportent l’une des plus grandes valeurs ajoutées.

Alors qui est cet Architecte Agile ? Comment savoir si l’architecte de votre équipe est un Architecte Agile ?

La réponse n’est pas aisée ; néanmoins l’Architecte Agile présente des signes distinctifs, des aptitudes qu’il exercera au quotidien. Un Architecte Agile doit savoir jongler entre ces différentes caractéristiques. Si l’architecte de votre équipe possède la plupart des caractéristiques qui suivent, et que vous le voyez jongler entre celles ci, c’est certainement un bon Architecte Agile.

Petit avertissement, la description faite ci-dessous peut certes paraître un peu idéaliste, mais elle donne sans aucun doute la direction qu’un Architecte Agile doit prendre.

Le but premier d’un Architecte Agile : délivrer une solution qui fonctionne avec une qualité optimale

Il y a deux aspects à aborder ici. Premièrement, la solution doit être de qualité optimale. Idéalement, sur un projet agile, les exigences de qualité (souvent appelées exigences non fonctionnelles) doivent faire partie intégrante de chaque itération. Les aspects tels que la sécurité, la performance, la qualité du code, etc. font partie intégrante d’une User Story [1] existante dans le backlog ou forment une user story distincte. Cependant, force est de constater que l’équipe agile, impliquée dans l’implémentation des fonctionnalités oublie bien souvent ces exigences de qualité. L’Architecte Agile doit alors s’assurer que le serveur d’intégration continue communique bien, à tous les membres de l’équipe à la fin de chaque cycle de build, différentes métriques, telles que des statistiques sur la qualité du code, la performance du système, les anomalies dans le code détectées par les tests unitaires… Il doit garder un œil sur ces données et attirer inlassablement l’attention de l’équipe agile sur celles-ci.

Le deuxième but est de délivrer une solution qui fonctionne. L’Architecte Agile évalue différentes options d’implémentation avec l’équipe afin de parvenir à une solution qui fonctionne et qui génère de la valeur métier pour le client. Il s’assure non seulement que la solution fonctionne de manière isolée mais également qu’elle s’intègre également parfaitement dans l’architecture de l’entreprise déjà en place, et qu’elle est suffisamment robuste pour être modifiée et étendue dans le futur. Il se concentre sur la solution qui fonctionne, non sur des documents et des livrables qui ne contribueraient pas directement à la mise en place de la solution.

L’Architecte Agile est garant de l’intégrité conceptuelle

Il s’assure que, dans le coeur de l’action, personne n’oublie la mission initiale. Sous la pression du calendrier et des obstacles techniques, les développeurs prennent parfois des décisions qui éloignent le projet de ses objectifs métiers. L’Architecte Agile maintient dans un esprit collectif les objectifs de la mission.
L’intégrité conceptuelle est atteinte lorsque le système développé démontre consistance et uniformité de ses éléments ainsi que la fluidité de leur intégration.
Prenons pour exemple la métaphore du Drag and Drop présente dans tous les systèmes d’exploitation modernes. Si le système d’exploitation a été bâti avec une bonne intégrité conceptuelle, le Drag and Drop devrait fonctionner partout. Ainsi, pour ouvrir un fichier on doit pouvoir le prendre et à le glisser sur l’application adéquate, et supprimer un fichier doit être aussi simple que de le prendre et de le glisser/déposer dans la corbeille. En résumé, l’intégrité conceptuelle consiste à créer un système sans surprise.

Un Architecte Agile travaille réellement au sein de l’équipe

Il est impliqué durant la totalité du projet. Des tâches de programmation lui sont affectées, et il implémente des User Stories, comme n’importe quel autre développeur. L’implémentation des User Stories ne constitue pas son unique tâche dans la journée, mais représente une part non négligeable de son travail.
Il fait profiter le projet de son expérience, et donne les grandes directions sur les différents choix d’architecture effectués tout au long de la vie du projet. L’architecture n’est pas figée durant les premières itérations, et continue à évoluer lors de chaque itération, ce qui signifie que contrairement aux architectes « traditionnels », il ne quitte pas le projet pour en rejoindre un nouveau après la traditionnelle phase projet de « mise en place de l’architecture ».

Un Architecte Agile écrit les tests systèmes qui permettent de tester les performances de l’architecture

Il écrit les tests d’infrastructure qui permettent de tester l’architecture du système. Si un mauvais choix d’architecture provoque un problème de performance, celui-ci doit être détecté par le test d’infrastructure. Puisque les méthodes agiles recommandent d’écrire les tests en premier lieu (Test Driven Development), il écrit les tests qui prouvent que le système n’offre pas la qualité de service attendue, puis effectue ensuite les modifications nécessaires afin de faire passer ce test. Dans les cas les plus rares où l’écriture d’un test peut s’avérée être difficile, il réfléchit à d’autres manières de tester l’architecture.
Tout ceci permet de s’assurer que des efforts ne sont pas vains, donnant lieu à un design non éprouvé. Le test confirme la viabilité d’un bon design dans lequel les efforts de développement vont êtres portés. N’importe quelle décision d’architecture, qu’elle soit majeure ou mineure, doit donc être précédée par un test.
Par exemple, si le système est supposé supporter une charge de 10 000 utilisateurs simultanés, l’Architecte Agile écrit des scénarios JMeter (ou à l’aide de n’importe quel autre injecteur) qui vont générer la charge adéquate sur le système, afin de s’assurer que tout fonctionne normalement en charge. Si le test échoue, il convient ensuite de modifier l’architecture pour faire en sorte que le test passe (NDT: ou de corriger les anomalies de développement qui ont fait échouer le test). Après ces modifications, le test est à nouveau exécuté cette fois ci avec succès.

Un Architecte Agile participe et travaille en équipe, avant tout

Il n’effectue pas seul les choix techniques et de conception: ces décisions doivent être prises de manière collégiale par l’équipe. Il a l’esprit ouvert, est totalement conscient du fait qu’il n’est pas omniscient, et n’est jamais obtus et fermé à propos de ses propres idées.
Les meilleures idées viennent de l’équipe, lorsque ses membres réfléchissent tous ensemble; n’importe qui est capable d’avoir une bonne idée ou de donner un point de vue intéressant. Une communication ouverte et honnête permet aux gens de prendre de meilleures décisions basées sur une information plus précise. L’Architecte Agile doit faire preuve d’empathie, doit traiter les gens avec respect, et montre qu’on apprend en permanence les uns des autres. Il favorise le consensus et permet à tous les membres de l’équipe de contribuer à l’élaboration de la solution, et par la même de tous les responsabiliser.
Si le client présente la problématique du projet et que l’architecte propose seul dans la foulée une unique solution, vous ne travaillez probablement pas avec un véritable architecte…

Un Architecte Agile est un mentor sur lequel on peut se reposer

C’est une des caractéristiques les plus importantes. Il travaille en permanence avec l’équipe afin d’améliorer sa capacité à prendre des décisions. Ce travail pédagogique est évidemment également une corde supplémentaire à son arc. Il utilise au mieux les capacités de l’équipe en la guidant sur les nouvelles technologies, en lui apportant son soutien sur les frameworks techniques. Il s’assure par exemple qu’elle ne va pas rejeter un choix de design par facilité, manque de motivation ou d’expérience sur certaines techniques ou technologies. Si tel est le cas, il comble le déficit technique de l’équipe afin de lui permettre de prendre les décisions en toute connaissance de cause.
Comme Martin Fowler le dit, « Ceci établit la règle empirique que la valeur d’un architecte est inversement proportionnelle au nombre de décisions qu’il ou elle prend ».

Un Architecte Agile est un habile médiateur

Une équipe agile comprend des membres qualifiés et passionnés. On observe fréquemment des divergences d’opinion sur certains choix de design, sur la meilleure manière d’implémenter une fonctionnalité, sur les façons d’améliorer le processus de développement, etc. Ces différences d’opinion, si elles ne sont pas prises en compte rapidement et de manière efficace, peuvent mener à de houleux échanges et de sérieux différents au sein de l’équipe. Dans ces cas précis, l’équipe a besoin d’un médiateur mature et plus expérimenté, qui saura aider l’équipe et régler ces différents. L’Architecte Agile convient parfaitement par son niveau de maturité et d’expérience.

Un Architecte Agile ne fait jamais de « Big Modeling Up Front » (BMUF)

La plupart du temps il n’utilise pas les outils de génération de code qui permettent de modéliser les grandes décisions d’architecture. A la place, il ne modélise juste « ce qu’il faut », généralement sur un tableau. Le premier modèle simple imaginé grandit et s’enrichit ensuite à chaque itération. L’Architecte Agile suit les concepts du Agile Modeling, et pour lui « le modèle, c’est le code ». S’il est nécessaire de générer le modèle à des fins documentaires, il peut par exemple être généré par un outil de reverse engineering.
Les modèles, les documents, le contenu, et la manière de communiquer doivent être les plus simples et concis possibles. L’idée est de se concentrer sur le contenu, et non sa représentation ou sa « mise en forme » qui ajoutent peu de valeur métier.

Un Architecte Agile cherche à faire du refactoring à grande échelle

Il est en permanence à la recherche de problèmes qui pourraient s’avérer par la suite être de sérieux obstacles techniques, et nuire à l’architecture du projet. Au fur et à mesure que le système s’étend, il s’assure que l’architecture suit le rythme. Il est en permanence à l’affût de changements importants qui pourraient avoir un plus fort impact que prévu. Par exemple, si l’application n’utilise pas assez de CPU, et que les performances globales ne sont pas ce qu’elles devraient être, il va introduire du multi-threading dans l’application afin qu’elle utilise ces ressources disponibles, afin de délivrer de meilleures performances. Il démarre par la solution la plus simple possible, et refactor ensuite en permanence la solution afin de garder le niveau de qualité requis tout en implémentant les nouvelles fonctionnalités.
L’Architecte Agile aide également à rendre le système modulaire. Au lieu de l’approche « Diviser pour mieux régner », il recommande de « Régner pour mieux diviser ». Au démarrage du projet, un système le plus simple possible qui fonctionne va être implémenté par une petite équipe. Par la suite, grâce à l’expérience de l’Architecte, l’équipe divisera le système en sous composants naturels, en gardant la vision globale, et on ajoutera si nécessaire de nouveaux membres à l’équipe pour le développement de chaque nouveau sous composant.

Un Architecte Agile est une « super glue »

Il se comporte comme une « super glue » entre l’équipe, les différents fournisseurs et les clients en leur communiquant les différentes décisions prises sur l’évolution de l’architecture et du design, les obstacles techniques rencontrés, etc. C’est l’intermédiaire entre les mondes métier et technique (NDT : dans la méthode SCRUM, c’est plutôt le ScrumMaster qui prend en charge ce rôle de suppression des obstacles rencontrés).
Il a la capacité de voir les obstacles métiers d’un point de vue technique, et les problèmes techniques à travers un contexte métier. Il sait expliquer la valeur métier de tel ou tel choix technique au client. Par exemple, s’il s’agit de choisir une technologie par rapport à une autre, il doit être capable d’expliquer au client la valeur métier ajoutée en terme d’utilisation des ressources, de capacité de changement, d’économies réalisées, etc. Il pense au « comment » mais aussi au « pourquoi » lorsqu’il travaille sur un projet où il faut répondre à la fois à des problématiques métiers et techniques.
La plupart des architectes traditionnels vont se concentrer sur la manière d’implémenter une solution, sans prendre le recul nécessaire qui permettrait de se demander si la solution est la meilleure possible. L’Architecte Agile s’efforce de travailler avec le client et cherche à savoir pourquoi une solution donnée est nécessaire, s’il y aurait une manière plus simple et plus efficace de répondre au besoin exprimé que la solution proposée par le client.

Dernier signe, mais pas des moindres, l’Architecte Agile embrasse le changement

Il embrasse le changement à la fois pour l’architecture et pour son propre rôle. La vraie architecture agile consiste à supporter le changement rapidement et facilement sans la dégrader, et avec le minimum d’impact sur les systèmes externes. Afin de s’en assurer, l’Architecte Agile démarre avec un design correct, et le fait évoluer constamment tout au long du cycle de vie du projet. Il implémente de façon modulaire les composants communs, masque derrière des interfaces ceux qui sont susceptibles de changer le plus souvent afin de minimiser les impacts lorsqu’ils évoluent.
Enfin, un vrai rôle agile consiste à pouvoir jouer de multiples rôles. Il prend les rôles de programmeur, de testeur de performance, de mentor, de médiateur, de membre de l’équipe, de « glue », et potentiellement celui de manager, tout ceci peut-être dans une seule journée de travail.

Conclusion

Les fondations de la tour d’ivoire des architectes sont ébranlées. Le nouveau type d’architecte appelé Architecte Agile grandit, s’affirme, travaille, et contribue aux équipes. Elle adhère totalement au principe numéro 12 de Toyota : « Allez et voyez par vous-mêmes afin de totalement embrasser la situation ». Ils sont des membres de premier ordre de l’équipe de développement et ne travaillent pas pour l’équipe mais dans l’équipe. Pour pouvoir prétendre au rôle d’Architecte Agile, il convient ainsi de faire preuve de maturité, d’expérience, et par-dessus tout d’être capable de jongler entre différents rôles et caractéristiques au sein de l’équipe de développement.

Alors, possédez-vous déjà un Architecte Agile au sein de votre équipe?

[1] Une « User Story » est une exigence définie par le « Product Owner » (dans le « Backlog » avec la méthode SCRUM)