Decideo - Actualités sur le Big Data, Business Intelligence, Data Science

Abonnez-vous gratuitement à Decideo !


Decideo

 


Agilité et architecture : les frères ennemis ?

L’agilité sonne-t-elle la fin de l’architecture ?


Rédigé par Christophe Cosnefroy, Neoxia le 27 Septembre 2012

Les pratiques agiles sont de plus en plus présentes au sein des DSI. Ce développement redéfinit le rôle de l’architecte dans les projets et plus généralement au sein de la DSI. Néanmoins les architectes se doivent d’avoir une vision à long terme en accord avec la stratégie de l’entreprise contrairement aux équipes agiles qui ont une vision à court terme axée sur la livraison d’un produit.
Divers positionnements existent dans l’organisation : “inclus”, “dilué” ou “en dehors de l’équipe”. Pour avoir vécu personnellement vécu deux de ces situations, aucune ne m’a convaincu.



Christophe Cosnefroy, Consultant Sénior, chez Neoxia
Christophe Cosnefroy, Consultant Sénior, chez Neoxia
Expérience “Les opposants” : opposition entre développement agile et architecture

Deux visions s’opposent.
La première du département d’architecture est une vision long terme. Le département livre des documents d’architecture plusieurs mois en amont des développements, ces documents traduisant la stratégie de l’entreprise. Les inconvénients majeurs sont la prise en compte de besoins métiers non matures, la livraison de fonctionalités inutiles et une documentation peu abordable.
La seconde vision, de l’équipe de développement, est centrée sur la livraison d’un produit, à court teme, au travers de la production de code.
Cette opposition à pour avantage de clarifier les rôles de chacun. Les développeurs restent maîtres de leurs choix et leur objectif primordial reste la livraison du produit.

Expérience “Les dilués” : architecture diluée dans les développements

Plusieurs petites équipes de développement agiles, elles ne possèdent pas toutes de concepteur expérimenté. Il n’existe pas d’architecture partagée. Le rôle est assimilé par l’équipe ou n’existe pas dans certaines équipes.
Cette situation à pour inconvénient un manque de conception entrainant un refactoring massif, des impacts non prévus et des composants dupliqués entre équipes.
L’avantage se limitant à un gain de temps temporaire dû à la non production de documentation. Donc des coûts de développement plus faibles.

La voie du sage : l’architecture agile

S’adosser aux pratiques agiles permet de concevoir une architecture, répondant aux besoins métiers, le tout au bon moment. Un architecte doit coopérer via les cérémonies Scrum pour établir des interactions. Ses livraisons s’adapteront aux rythmes agiles. La communication restant un de ses fondamentaux.

Interaction

1. Planification initiale
§ choix des logiciels et matériels ;
§ identification des composants réutilisables ;
§ communication avec l’ensemble des acteurs du projet.
2. Storyboard et backlog
Participation aux storyboards et au backlog. L’architecte tient un rôle clé dans le recueil des besoins.
3. Participation au sprint
Coopération avec l’équipe. Compréhension des objectifs du sprint afin d’aider à définir la conception. L’architecte a la coresponsabilité du travail à réaliser.
4. Revue de sprint
L’architecte est partie prenante des acteurs et aura préparé en amont la revue d’architecture.

Livraison

Décomposition des composants

En mode agile, pas de document d’architecture avant le sprint zéro. L’architecte doit identifier les limites des composants correspondant aux besoins métiers.

Contribution au backlog

Intégrer les user stories d’architecture au backlog nécessitera beaucoup de conviction de l’architecte.
Plusieurs solutions existent, soit par l’ouverture d’ un deuxième backlog. Ou l’Intégration des users stories techniques au backlog du produit. Soit enfin par un “noyautage” des users stories par l’architecture.

Communication

La documentation est utile

Un prototype peut suffire pour valider l’architecture, mais certaines circonstances amènent à décrire plus formellement l’architecture.

La valeur de l’architecture
Difficile à mesurer objectivement, mais les coûts augmenteront à coup sûr sans elle.

Auto-promotion auprès du Product Owner

Convaincre le Product Owner de l’utilité de l’architecture. Sinon elle aura des priorités basses et ne sera jamais réalisée.

En finir avec cette opposition

Agilité et architecture ne sont pas des ennemis. J’espère vous avoir fourni des arguments pour vous en convaincre.
La conception top-down initiée par les architectes et la conception bottom-up conçue par les équipes agiles sont complémentaires et nécessaires afin de délivrer un produit conforme aux besoins, intégré dans le SI et robuste. L’anticipation est recommandée dans l’agilité comme l’adaptation se doit d’être une nouvelle vertu de l’architecture.




Commentaires

1.Posté par THIA le 27/09/2012 21:23
Bien que ce soit un terme "à la mode", la notion d'agilité a toujours existée. Malheureusement, les fondations de la Bi traditionnelle, le pouvoir des informaticiens ont mis sur rail les briques de l'architecture fonctionnelle et technique telle qu'on la connait aujourd'hui.
Mais cette époque est révolue, à l'image de Néo, les utilisateurs ont choisi aussi de prendre la pilule bleu et de sortir de (la matrice ?) ces architectures rigides pour s'orienter vers une "architecture agile".

Complètement barge ? non! ;p je trouvais la dérision marrante.

En tout cas, super article. Merci de nous avoir fait partagé ton retour d'expérience.

2.Posté par Patrick De Freine le 27/09/2012 22:12 (depuis mobile)
Excellent sujet. Les architectes d'entreprise, garants de fondamentaux transverses, sont passionnés du moyen terme et les architectes techniques sont souvent passionnés du court terme. Une équipe a besoin de défenseurs et d'attaquants.

Nouveau commentaire :
Twitter

Vous pouvez commenter ou apporter un complément d’information à tous les articles de ce site. Les commentaires sont libres et ouverts à tous. Néanmoins, nous nous réservons le droit de supprimer, sans explication ni préavis, tout commentaire qui ne serait pas conforme à nos règles internes de fonctionnement, c'est-à-dire tout commentaire diffamatoire ou sans rapport avec le sujet de l’article. Par ailleurs, les commentaires anonymes sont systématiquement supprimés s’ils sont trop négatifs ou trop positifs. Ayez des opinions, partagez les avec les autres, mais assumez les ! Merci d’avance. Merci de noter également que les commentaires ne sont pas automatiquement envoyés aux rédacteurs de chaque article. Si vous souhaitez poser une question au rédacteur d'un article, contactez-le directement, n'utilisez pas les commentaires.


Twitter
Rss
LinkedIn
Facebook
Apple Podcast
App Store
Google Play Store