En phase avec la remarque de Constantin. Une équipe traverse d'architectes agiles va agir plus en coachs et en facilitateurs. Du coup, ils vont avoir besoin de maîtriser de plus en plus les outils de prise décision collective, de visualisation et de facilitation. J'ai pas mal bossé sur ces sujets en 2017.

Merci pour cette avis détaillé. À ton avis, un "fonctionnement global d'un SI" permet-il vraiment de faire ressortir des solutions qui soient les mieux taillées pour résoudre les problèmes de tous les différents types d'utilisateurs ? Encore à ton avis, il faut faire attention à quoi particulièrement dans ce type de SI global pour qu'il ne soit pas un frein à l'innovation ? -- Constantin

Meme réaction...Et la reprise de la parole par Constantin m'a remis dans un gros malaise... Je pense qu'il doit faire allusion a de (mauvaises) expériences personnelles, qu'il transforme en généralités et vérités. Le metier d'archi n'est évidemment pas le code... Les livrables les plus fréquents (HLD, LLD, contrat d'interfaces) sont indispensables plus pour l'Ops que le pour le Dev...et un besoin de rappeler que le non-fonctionel est la clef de l'adoption ? Et sans rentrer plus dans tous ce que j'ai entendu avec douleur, juste un zoom sur les choix technologiques...les solutions sont très souvent imposées par le client qui a qualifé en amont les produits/techno (maintenabilité, training interne, sécurité, certification,...)... Ce n'est pas open bar l'Industrie ! J'ai eu l'impression que le discours etait totalement hors sujet...hors sol... dogmatique ?

Merci Roland pour ton ajout. Souvent on va parler plutôt d’urbanisme à l’échelle de l’entreprise, pour établir des règles, des contraintes, pour que les équipes, ayant des compétences d’architecture, puissent créer en toute autonomie. L’autonomie ne veut pas dire en autarcie ni seule. Ce qu’on veut éviter, car c’est toujours, de mon expérience, néfaste, c’est l’architecte qui décide alors qu’il n’a qu’une connaissance que théorique du terrain. Qui décide POUR les équipes au lieu de se place en tant que conseil. Donc je ne dirais pas, pour ma part, qu’il est obligatoire, mais que les piètres connaissances de la plupart des direction de SI font qu’ils mettent un système en place inefficace qui nécessite, le croient-ils, ce rôle de contrôle. Malheureusement dans les faits, un architecte technique ne garantit en rien la cohérence d’un SI. Si c’était le cas, le monde irait mieux. Que risquerait-il de se passer à ton avis, si on retirait l’architecte d’entreprise d’une entreprise comme Renault ou d’une banque comme la Société Générale ? - Constantin

Et non, la réponse est... je te laisse voir le détail là où j'ai trouvé l'exercice : kzfaq.info/get/bejne/osWWmceS18mumYU.html :)

Salut Rachid ! Dans une équipe agile, on va plutôt essayer d'avoir ce qu'on appelle une architecture émergeante. C'est à dire qu'on va effectivement se mettre d'accord sur une archi mais pas une seule fois ! On le fait tout le temps ! Dés que nécessaire, plusieurs fois par jour dans certains cas, l'équipe se réunie pour parler de l'archi, à cause d'un problème ou autre, et se met en effet d'accord sur la façon de résoudre le problème. En le faisant ainsi, toute l'équipe est à jour sur ce qui se fait. Qu'en dis-tu ? -- Constantin

Merci Arnaud pour cette proposition, nous avons effectivement dans notre backlog de vidéos l'idée d'en faire une sur les façons de prendre des décisions en équipe. On note ton intéressement :)

@Manon 314, tout dépend le cas. Si la situation implique d'avoir des outils coûteux, transverses a plusieurs équipes, nécessitant un achat groupé, alors oui il serait logique de faire appel a l'architecte. Attention, il ne faut pas que l'équipe devienne totalement dépendante d'une quelconque personne ou équipe pour l'utilisation desdits outils, risque de goulot d'étranglement. Si les conditions de déploiement sont propres a l'équipe, alors c'est a l'équipe de faire ses propres choix et d'être autonome sur cette partie là. Ce qui n'interdit pas de demander conseil a un architecte, ou plus largement une personne compétente sur le sujet.

Ce que tu évoques correspond a l'intervention que fait JP dans la vidéo. En fait, l'architecte peut être la dans une posture de coach. Donc il ne va pas laisser une équipe de devs junior livrés à eux-mêmes. Il va les conseiller sur le comment faire, leur recommander éventuellement de la documentation sur les design pattern, leur proposer de la relecture de code pour corriger les dérives et favoriser la courbe d'apprentissage, voire pourquoi pas intégrer temporairement l'équipe... Il est clair qu'avoir une équipe composée exclusivement de juniors n'est pas une bonne idée. Cela ne favorise pas le partage de l'expérience. Dans le cas d'un projet étudiant, le problème est un peu différent (encore que...), mais n'en est pas moins compatible avec l'agilité. Oui il faut essayer des choses, les casser, refaire, expérimenter. Si possible de faire aider par quelqu'un de plus expérimenté (un prof par exemple, tiens d'ailleurs il ne pourrait pas jouer le rôle de l'architecte ?). Ça ne se passe pas bien différemment en entreprise. Un code possède de la dette technique des lors qu'il a été écrit. L'enjeu étant de la minimiser le plus tôt possible. Donc finalement, on écrit des choses, ça fonctionne, ou pas, on rectifie, ... N'hésite pas a partager tes problèmes via des forums (openclassroom, stackoverflow, ...), Ça peut aussi vous aider a faire les bons choix.

@@TheTippex66 D'accord, merci à vous ! :-)

🙌 Qu'est-ce que tu retiens tout particulièrement de cette vidéo ? -- JP