Comment concilier équipe d'architecture et agilité ?
Un article de Agile-Swiss.
A cette question d'aucun ne manqueront pas de répondre que la question ne se pose pas car si on suit XP à la lettre le rôle d'architecte n'existe pas en soi. Seulement quand les postulats et les faits divergent, il est toujours mieux d'en revenir aux faits et ces faits sont les suivants. Dans toute entreprise de bonne taille avec plusieurs projets informatiques menés de front et de surcroît si l'ensemble s'inscrit dans une démarche d'urbanisation un besoin de standardisation se fait très rapidement et logiquement sentir autour :
- Des langages de programmation
- Des frameworks
- Des serveurs applicatifs
- De l'environnement de développement (gestionnaire de sources, intégration continue, repository de composants, etc...)
- Des niveaux de sécurité minima à respecter dans les applications
- Du niveau de qualité des processus utilisés (CMMI)
- De la nature des services au sens SOA à exposer
- etc, ...
De manière erronée et réductrice, le rôle d'architecte est bien trop souvent perçu par les développeurs comme la personne en charge d'assurer et où de valider la conception UML d'une application. C'est certainement ce qui est à l'origine de pas mal d'incompréhensions entre ces deux mondes. Car un bon architecte peut éventuellement donner un avis consultatif sur le sujet mais sa vraie valeur ajoutée se trouve avant tout dans la maîtrise de l'intégration des projets informatiques au sein d'un système qu'il se doit de maintenir cohérent.
Ceci étant dit la cohabitation entre équipe d'architecture et équipe de développement n'est pas toujours un long fleuve tranquille (c'est ce qu'on appelle un doux euphémisme ;-). Pour fluidifier cette communication Rebecca J. Parsons, architecte chez ThoughtWorks, vient de publier sous l'égide de Martin Fowler 'Enterprise Architects Join the Team'. L'approche proposée me semble très innovante et pragmatique, à lire ...
Freddy
