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.
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.
