Retour d'expérience : bonnes pratiques d'une équipe d'architecture logicielle

Je termine une mission d'architecture logicielle dans une cellule Méthodologie de Développement et MDA dans une grande DSI française. Au sein de cette équipe, nous définissons et mettons en place des architectures logicielles pour les projets.
Le travail s'axe autour de plusieurs aspects :

• Formation et accompagnement des équipes projets sur les phases de conception (modélisation, Design Pattern), développement, déploiement.
• Conception d'outillage pour la démarche MDA : langage de modélisation interne, outils de modélisation et générateur de code;
• Réalisation et mise à disposition des outils du poste de développeur.

Le tout dans un contexte de méthodologie agile.
Je voulais vous remonter mon retour d'expérience pour partager les bonnes pratiques qui ont fait le succès de cette approche.

Faciliter le passage de connaissance pour consolider l'équipe

Afin de renforcer l'esprit d'équipe, les membres de l'équipe "tournent" sur le support au développement. Forcément, en pratique, certains auront certaines affinités sur des sujets selon leurs propres expériences (on avait le "specialiste performance", le "specialiste sécurité", etc), mais on essaie toujours de partager cette connaissance.
On consolide l'équipe avec cette approche. En cas d'indisponibilité, chaque membre de l'équipe peut reprendre le travail de l'autre rapidement. On est également plus réactif, car si un membre n'est pas disponible, on ne se retrouve pas bloqué à l'attendre. Mais surtout, chaque membre monte en compétence sur les différents sujet Même chose sur la méthodologie agile : A chaque sprint, le rôle de Scrum master tourne.
Pour faciliter les passages de connaissances entre les membres de l'équipe un blog permet de poster des solutions de certaines problématiques techniques qui pourront servir pour les autres membres plus tard. Lorsque le blog n'est pas suffisant, et que nous avons des besoins d’interaction, nous faisons un point technique "démo/tutoriel" avec le vidéoprojecteur.

Faciliter le passage de connaissance aux équipes projets

"Quand un homme à faim, mieux vaut lui apprendre à pêcher que de lui donner du poisson" disait Confucius.
C'est dans cet état d'esprit que nous faisons le support aux développeurs. Nous privilégions le passage de connaissance afin que les développeurs soient autonomes et montent en compétences, plutôt que de corriger leurs problèmes sans explications.
Ce passage de connaissance se fait de plusieurs manières : Un blog et une FAQ avec des articles expliquants les cas les plus récurrents (mise en place de la sécurité par exemple), du pair-programming avec les développeurs et même des screencasts.

Proximité de l'équipe

L'équipe au complet est localisée dans un même bureau. Quand le Product Owner, le Scrum master et les membres de l'équipe sont dans un même espace de travail, on favorise les échanges et on facilite la communication tous les membres de l'équipe. Les problèmes sont remontés au plus tôt et on sait plus facilement sur quoi travaille chacun de nous.
Pour aller encore plus loin dans l'échange et le suivi, nous avons - en tant que bons agilistes - notre stand-up meeting quotidien (limité à 15 minutes pour l'équipe, attention !), où chacun revient sur ces 3 questions "Qu'ai-je fait hier", "Sur quoi ai-je été bloqué" et "Que fais-je aujourd'hui". En essayant de ne pas s'égarer...
La proximité est également "virtuelle" Nous partageons des outils de travail : boite mail commune à l'équipe, outil de suivi commun à l'équipe.

Capitaliser sur les outils pour développer durablement

Lors de nouveaux besoins des équipes projets, certains outils spécifiques ont été développés. Il a rarement été question d'outillage "jetable". Chaque outil est développé selon les besoins actuels, puis remonté dans le référentiels des outils. Si un nouveau besoin se fait ressentir, alors on fait des évolutions sur l'outil.
Cette approche présente plusieurs intérêts :
- Lors d'un nouveau besoin : on se limite au cas d'utilisation actuel en ne développant que les fonctionnalités utiles au moment T.
- Lors de la réutilisation : on ne repart pas de zéro : on réutilise l'outil existant dans le référentiel
- Lorsque de nouveaux besoins se font ressentir : on fait les évolutions mais seulement sur le nouveau cas d'utilisation, en refactorant si besoin le code existant.
On garde une approche incrémentale, en se focalisant seulement sur les besoins en cours et en ne surdimensionnant pas les outils (on reste agiles).

Appliquer à soi-même les conseils que l'on prodigue aux autres

Nous poussons les équipes projets à avoir une approche TDD et d'intégration continue. Nous appliquons à nous-même ces préconisations. Notre outillage suit une approche TDD et il est placé dans une chaîne d'intégration continue afin de valider au plus tôt les problèmes.
Nous avons mis en place cette approche car nous nous sommes rendu compte que lors d'évolutions ou de corrections de bug sur notre outillage, nous pouvions amener des régressions. Même si nous sommes une équipe d'architectes logiciels, nous sommes avant tout des développeurs et à ce titre, nous devions également suivre les même processus de développement que les projets "métier" afin d'assurer un outillage de qualité.

Se remettre en question pour s'améliorer

Nous mettons un point d'honneur à l'amélioration continue grâce, entre autre, aux rétrospectives de Sprint.
Tout n'est pas parfait et nous l'acceptons. D'ailleurs, je pense que c'est ce qui fait que ça fonctionne bien : accepter que tout n'est pas parfait, permet de s'améliorer. Lors de la rétrospective de Sprint, nous remontons donc tout ce qui ne va pas au niveau organisationnel, humain ou technique et on tente de mettre en place des solutions pour améliorer ces points lors itérations suivantes.
L'autre point d'amélioration continue, ce sont les retours d'expérience auprès des équipes projets. Lorsque les projets sont terminées (ou en phase avancées de développement), nous faisons un point avec le lead developer, le responsable de l'équipe, l'architecte. et nous prenons en  compte les remarques et critiques sur notre outillage, nos formations, notre support. Nous prenons en compte également les idées qui permettraient d'améliorer le travail des développeurs.

En conclusion

Toutes ces bonnes pratiques nous ont permis de rester ouverts sur les développeurs et de nous améliorer en continu et surtout d'éviter le syndrome de la tour d'ivoire.
Peut-être utilisez vous d'autres bonnes pratiques de développement ("Eat your own dog food" par exemple) ou d'agilité (Kanban) ou d'apprentissage (Shu ha ri)
N'hésitez pas à nous remonter vos retours d'expériences en interne ou en mission pour que l'on puisse partager sur ces sujets.