Voici ce que fait un architecte logiciel dans une équipe Agile
Donc, vous êtes architecte. Alors que l’IA modifie encore une fois les rôles de l’industrie, la question se pose toujours : que faites-vous dans une équipe agile ? Je ne veux pas prétendre qu’il s’agit d’un nouveau débat ; il y avait même un article assez récent sur The New Stack sur le même problème.
Le problème avec le terme architecte c’est que cela a une signification très spécifique lors de la construction d’une maison. C’est là que la plupart des gens expérimentent l’idée en premier. Il s’agit d’un terme plus fragmenté dans la production de logiciels. Dans certains cas, il est simplement utilisé à titre honorifique – pas aussi vague que « leader d’opinion », mais comme un moyen de témoigner du respect à une personne âgée sans lui donner d’effectif. Mais allons au-delà de cela et supposons que vous êtes la vraie affaire.
Pour une équipe exécutant une simple application Web, la plupart des gens peuvent voir la technologie sans l’architecture. Les développeurs ont leurs frameworks frontend préférés. AWS propose toujours différentes solutions, mais ils vous montreront comment héberger un site Web, si c’est tout ce dont vous avez besoin. Personne n’a plus besoin d’être persuadé d’utiliser git. Nous savons tous ce qu’un site Web peut faire, la communication entre le client et le créateur du site sera donc probablement fluide. Qui a besoin d’un architecte ici ? Bien entendu, dans ce cas limité, l’architecture a reculé dans la haie ; les sites web ont été standardisés il y a quelque temps, ils fonctionnent, et on ne regarde plus beaucoup les rouages. Mais dès qu’il en faut un peu plus, tout revient. Tailwind est-il toujours adapté ou les composants de Bootstrap offrent-ils un itinéraire plus sûr ? Devons-nous exécuter ces méthodes supplémentaires dans Lambda pour réduire les coûts ? Le client a-t-il envie de générer davantage d’affaires à partir de son site ? Nous nous trouvons donc face à votre première responsabilité en tant qu’architecte : gérer la complexité pour réduire les risques et les coûts.
Lorsqu’une organisation gère plusieurs équipes ou plusieurs produits, il est beaucoup plus facile pour vous de tracer un sillon régulier. Parfois, s’assurer qu’une API commune est utilisée dans toutes les équipes. Entretenir le pipeline, et définir les différentes étapes. Certaines solutions cloud existantes impliquent une conception, cela doit donc être une contrainte. Quoi qu’il en soit, les architectes évitent le chaos en fournissant structure, alignement et certitude.
Déplacement de l’architecture vers la gauche
Agile, c’est le moment présent
Cela a peut-être commencé comme un sale petit secret, mais c’est devenu une vérité acceptée. Un architecte n’est probablement pas un rôle valable dans une équipe agile. J’avoue que j’ai parfois été trop zélé avec les membres non-codeurs d’une équipe de développement. La version la moins militante consiste à prendre conscience des « cochons » et des « poulets » au sens agile du terme. Lors de la préparation du petit-déjeuner, les poules pondent des œufs, mais les porcs ont littéralement la peau dans le gibier. Ainsi, seuls les porcs devraient assister quotidiennement aux stand-ups agiles.
Le rôle d’architecte dans l’Agile classique pose trois problèmes. Considérez-les comme des thèses protestantes luthériennes clouées à la porte – ou plus probablement au mur de la planification.
- Il n’y a pas de phases de conception initiales en Agile.
- « Les meilleures architectures, exigences et conceptions émergent d’équipes auto-organisées ».
- Un architecte ne peut pas être un approbateur et une cause de retard.
Cela conduit à l’idée que le savoir-faire architectural doit être réparti entre les autres membres de l’équipe. C’est souvent le cas, mais cela ignore le fait que l’architecture responsabilité n’incombe à personne, même si les gens pensent qu’ils peuvent l’être redevable. N’oubliez pas votre matrice RACI.
Tous les développeurs agiles doivent-ils être les architectes d’un projet ? Cela n’a pas de sens puisque l’architecture décrit un plan singulier. Il ne s’agit pas d’un débat permanent, comme peut l’être la mise en œuvre d’un logiciel.
La principale raison de la compétence architecturale est lorsqu’un système interne doit fonctionner avec un autre. Mais il n’est pas raisonnable de supposer que l’ensemble de l’équipe a compétence sur les deux systèmes.
Contrebande dans un design
Je ne crois pas vraiment au design émergent ; en fait, j’ai souvent vu un design introduit clandestinement dans la planification du sprint du jour 0, même s’il ne s’agit que d’un « homme de paille ». Ou encore, une architecture suggérée ne reçoit aucune réponse, car un membre senior l’a suggérée.
Cela conduit à l’idée que si l’architecte est également un développeur de terrain, sa conception intentionnelle peut être introduite clandestinement sans aucune question. Bien qu’il s’agisse d’une solution pratique, cela signifie que le fonctionnement de l’équipe devient opaque.
La gouvernance est également quelque chose qui doit être fait, mais elle est souvent ignorée. Les rituels agiles semblent aider à l’autogouvernance ; mais lorsque les rétrospectives ne sont pas réalisées correctement, l’un des coûts est le retour d’information nécessaire à toute architecture « évolutive ».
Juste ce qu’il faut dans l’architecture temporelle
Ainsi, étant donné qu’une « grande conception dès le départ » est hors de question, l’architecture doit s’efforcer de se concentrer davantage sur les lignes de tramway que sur une grande feuille de route. Fixer des limites, utiliser les contraintes techniques des systèmes existants pour maintenir une vision et maintenir l’alignement avec les autres équipes et projets.
Normalement, je n’évoquerais pas SAFE, ou le « cadre agile à l’échelle », mais il est assez optimiste face à la contradiction avec l’idée d’une piste architecturale. C’est littéralement l’idée de « Wile E. Coyote » construisant une route sous ses pieds, d’une manière défiant la physique, normale uniquement dans les dessins animés Roadrunner.
Mais on comprend ce qu’ils veulent dire. Produisez des plans qui fonctionnent d’« ici » à un peu plus que « là-bas ». Il peut s’agir d’un nombre suffisant d’API, de contraintes sur l’utilisation de nouveaux outils ou d’une réorganisation du pipeline CI pour s’adapter à une épopée à venir. Il peut également s’agir d’encadrer les développeurs pour les aider à comprendre les avantages de travailler avec des systèmes existants plutôt que de lancer les leurs.
Faire tomber le système agile de l’intérieur
Je pense qu’il est parfaitement possible pour quelqu’un de travailler contre une méthodologie agile stricte, tout en apportant son soutien sans réserve à une équipe ou à un projet. En fait, reconnaître la myopie de l’Agile, c’est en partie contribuer à y remédier.
Développer une conception intentionnelle (même si peut-être ne pas la révéler en une seule fois, mais par morceaux) et ne pas aller trop loin devant les exigences du client : telles sont les principales compétences de l’architecte agile.
La gestion de la dette technique est un autre domaine dans lequel, par déduction, nous avons déjà accepté que l’agilité entraîne effectivement une perte de productivité. C’est peut-être le meilleur endroit pour guider le développement vers un plan. C’est parfaitement raisonnable dans un contexte agile : laissez du code apparaître, puis, une fois qu’il a prouvé le système aux parties prenantes, écrivez-le avec plus d’intention.
Garder un œil sur les formats de données et les API utilisés par d’autres groupes de la même organisation, et ajouter des histoires pour les aligner, peut également fonctionner parfaitement dans n’importe quel cadre agile. Au lieu de querelles répétées sur json vs yaml, utilisez une communauté de pratique pour concentrer les compétences de toute l’organisation sur le meilleur format.
Il ne devrait donc pas être nécessaire de faire tomber le système agile, même si vous travaillez un peu à contre-courant. Même si j’admets que cela fait toujours de l’architecte un poulet et non un cochon, c’est peut-être l’architecte qui empêche la ferme de sombrer dans la boue – et qui permet aux équipes et aux projets de donner de bons résultats au fil du temps.
