Les comités d'architectures, pour ou contre.
On dit en méthodologies Agiles qu'on doit prioriser le travail d'équipes. Mais, à quel prix ? Surtout quand et comment, on parle d'architecture logicielle.
Un architecte logiciel au sien d'une équipe traditionnelle est le maitre après Dieu. Il est surtout le maitre désign logiciel. C'est lui, éminence grise, sur ce domaine. Les autres membres de l'équipe n'ont qu'à appliquer ce que ce « Dieu » a décidé.
En plus, de son travail s'effectue en début de projets. Où il met les grandes lignes de l'architecture (L'ARCHITECTURE LGOCIEL) et puis s'en va du projet. Et dans de très rares cas, lorsqu'on est vraiment chanceux et que le projet est long (conséquemment très gros). Et parfois, il reviendra en cours de projet, pour faire une revue d'architecture.
Mais, disons que cette stratégie n'est pas vraiment « Agile ». Mais, certaines organisations pour aider (ou favoriser) le travail d'équipe. Mais aussi la compréhension des membres des équipes de développement. Elle forme de ce qu'on appelle des comités d'architecture.
Un comité où les membres, indépendamment de leurs niveaux de compétences, s'assoient ensemble pour construire l'architecture du logiciel et bien sûr la mettre en œuvre. Arriver à un consensus sur les différents choix d’architectures nécessaire aux projets.
J'avoue que dans certains contextes et lorsque l'équipe est restreinte, cela peut fonctionner. Par contre, si l'équipe est trop grande, que la disparité des compétences (surtout en architecture logiciel) ne s'égale pas. On peut tomber dans le piège de la réunitivite. La maladie des réunions qui s'étire pour n'arriver à aucun consensus.
Donc, c’est quoi le compromis qu'il faut faire. Je sais, vous voulez une solution toute faite. Mais, si vous êtes lecteurs réguliers de mon blogue, vous savez que je ne donne jamais de solutions toutes faites. Je propose généralement une approche plutôt qu'une solution.
Mais, c'est quoi le rôle de l'architecte logiciel au sein d'une équipe Agile. D'abord concevoir cette architecture logiciel, je sais c’est évident. Mais, c'est bien de se le rappeler. Mais, contrairement aux environnements traditionnels. Il n'est pas le « DIEU » de l'architecture. Mais, l'expert aux SERVICES, oui aux SERVICES des autres membres de l'équipe.
De plus, son intervention aux projets de ne doit pas se limiter à une p'tite vite en début de projet. Mais, tout au long du projet. Il est au service de l’équipe et de ses membres
Donc, l'approche que j’utilise (oui je suis aussi Architecte logiciel « Agile ») et qui fonctionne avec les équipes dans lesquelles je l'ai appliqué. C'est que je conçois seul une première version de l'Architecture. Une fois conçu, je la présente oui, à un comité d'architecte « RESTREINT ». Il est généralement composé de 2 à 3 autres personnes (membre de l'équipe bien sur), ceux qui sont les plus expérimentés ou qui peuvent apporter quelque chose aux discussions.
Je présente toujours le concept d’architecture, en disant que je leur présente ma vision pour leur faire valider. Je suis à leur service et non l'inverse. Le but de cette première rencontre, c’est d'établir les bases de « NOTRE » vision de l'architecture logicielle. Lorsqu'il est nécessaire, nous pouvons ensemble la raffiner.
Une fois que cette petite équipe est arrivée à un consensus. Je dis bien un consensus, peut-être pas à la véritable architecture. Mais, les premières bases qui doivent être mises en début de projet. Elles seront et devront être raffinées en cours de projet. J'utilise cette approche à chaque phase importante d'architecture.
Tout faire en équipe, c'est philosophiquement bien. Mais, impossible à appliquer correctement dans le monde réel. Si nous sommes trop nombreux à discuter ensemble pour des choses simples. Il risque fort qu'on consomme du temps inutilement. Prendre de faire la sélection d'un groupe de composantes ou des grandes lignes d'architectures. Nous n'avons pas besoin d'avoir l'opinion de chacun des membres. Au besoin, leur poser individuellement la question, pourra très bien suffire
Il faut prendre le temps d'évaluer la rentabilité des efforts et le temps consommé aux projets. N'oublions pas, notre « ULTIME » but c'est de produire un logiciel. Ne pas faire, des réunions justes pour faire réunion.
En résumé, faire des comités d'architectures logiciels, oui, seulement lorsque c'est nécessaire. Rappelez-vous de vous poser les questions suivantes.
Pourquoi je fais quelque chose ?
Pour qui je le fais ce quelque chose?
Et surtout comment on doit fait la chose ?
