Dans un environnement agile, responsable de l'architecture logicielle


19

Dans une équipe agile, qui est responsable de prendre des décisions d'architecture et de conception de haut niveau qui affectent l'ensemble du système, pas seulement le travail effectué dans le sprint actuel?

Peut-être propriétaire de produit, maître de mêlée, équipe de mêlée ou quelqu'un d'autre?

entrez la description de l'image ici


10
Cela ... n'a aucun sens ...
Telastyn

3
La présence de backlogs de produit et de sprint n'affecte pas la responsabilité de l'architecture logicielle. Une meilleure question pourrait être: dans un environnement agile, qui est responsable de l'architecture logicielle?
ChargerIIC

J'ai essayé de mettre à jour la question afin qu'elle puisse au moins être comprise. Pas sûr à 100% si j'ai bien compris ...
FrustratedWithFormsDesigner

Réponses:


24

"L'architecture logicielle est réalisée par toute l'équipe. Cette pratique ne supprime pas le besoin d'un architecte logiciel, cela signifie simplement que l'architecte contribue à la discussion avec une perspective plus large et probablement plus expérimentée, néanmoins tous les membres de l'équipe contribuent à l'architecture du logiciel. "


5
Pure Agile a tendance à rejeter les rôles descendants traditionnels tels que «chef de projet» et «architecte système», préférant plutôt refactoriser ces rôles et répartir leurs responsabilités traditionnelles au sein de l'équipe.
Jonathan Eunice

6
@JonathanEunice: Comment cela peut-il être possible dans la pratique? Tous les développeurs ne sont pas également de bons architectes.
Giorgio

2
@JonathanEunice: La question posée à DWD a donc un sens après tout. Je ne comprends pas tous les downvotes.
Giorgio

3
@DaveHillier: Peut-être que ces projets sont grands mais l'architecture est assez simple: les développeurs n'ont qu'à remplir les morceaux dans un schéma assez simple et répétitif (par exemple écrire des centaines de formulaires similaires dans une application Web avec un modèle de domaine existant) . D'un autre côté, je sais que dès qu'une application devient suffisamment complexe, vous avez besoin de quelqu'un pour s'occuper de l'architecture (souvent à l'avance) sinon vous allez vous retrouver avec un énorme gâchis.
Giorgio

6
"Big Upfront Design" est l'argument agile typique pour tirer la conclusion qu'il ne devrait pas y avoir de conception initiale du tout: une approche est adoptée à l'extrême, l'extrême s'est avéré erroné et l'extrême opposé est proposé comme solution. Je conviens qu'une grande conception initiale est rarement une bonne approche, mais certaines décisions architecturales fondamentales doivent être prises en amont afin d'éviter une refactorisation énorme ou une réécriture complète plus tard. Ce n'est pas une activité qui peut être improvisée "quand on a l'impression que le code devient trop salissant et doit être refactorisé". L'expérience aide à trouver un bon équilibre.
Giorgio

19

Les architectes, bien sûr, mais peut-être pas les architectes traditionnels.

Je ne parle pas du type d'architecte chef de file qui réfléchit et laisse ensuite les singes faire la dactylographie. Je veux dire un programmeur principal expérimenté qui comprend les compromis coûts / avantages des décisions difficiles à inverser et qui conseille les équipes sur ce qu'il faut faire.

Les architectes efficaces sont difficiles à trouver, mais cela peut être une position fantastique, et donc vous avez probablement au moins un programmeur expérimenté et réfléchi qui pourrait bien le faire. Une telle personne doit

  • Prenez de bonnes décisions d'architecture, bien sûr, mais aussi
  • Savoir comment donner des conseils efficacement, afin que les autres se sentent à l'aise de les prendre, et aussi
  • Déléguer lentement les décisions d'architecture aux équipes

Ce dernier point déclenche beaucoup de monde. Lorsque des agilistes bien intentionnés disent des choses comme "L'équipe est propriétaire de l'architecture", ils ont ce "droit", mais je trouve les conseils presque totalement dénués de sens dans leur application. Si vous avez fait confiance à des équipes pour prendre la responsabilité de leur propre architecture, vous ne poseriez pas la question en premier lieu, n'est-ce pas?! Je suppose donc que vous posez la question car il y a une certaine inquiétude

  • Personne ne prendra la responsabilité et nous aurons une mauvaise architecture, ou
  • Les mauvaises personnes prendront la responsabilité et nous aurons une mauvaise architecture, ou
  • Celui qui prend la responsabilité deviendra un bouc émissaire et vous espérez éviter cela

Si vous avez besoin de quelqu'un pour assumer la responsabilité, donnez-le à quiconque veut l'accepter. Sérieusement. Cette personne se soucie au moins. Donnez à cette personne les ressources dont elle a besoin pour faire le travail et aidez-la quand elle en a besoin. Peu importe à quel point la personne est compétente, car si elle s'en soucie, elle essaiera alors d'apprendre ce dont elle a besoin. Naturellement, une telle personne a besoin d'aide sous la forme de bons livres à lire et d'une communauté de pairs et de mentors à qui elle peut demander de l'aide et des conseils.

Si vous craignez que la mauvaise personne ne soit responsable, alors j'espère que vous savez qui est "la bonne personne" et que vous vous battez pour les installer en tant qu'architecte. Un livre comme The New Strategic Selling vous aidera à apprendre les techniques de vente pour y arriver.

Si vous avez juste besoin d'un bouc émissaire, alors donnez tranquillement des coups de coude aux autres pour donner la responsabilité à la carrière de celui que vous aimeriez le plus détruire ou altérer. Soyez au moins honnête à ce sujet.

Pour en revenir à un travail d'architecte efficace, ils peuvent considérer leur travail comme un poste de gestion, plutôt que comme un simple poste de décision. S'ils ne délèguent pas au moins les décisions les plus courantes aux équipes, ils deviendront un goulot d'étranglement et ralentiront toute l'organisation . Ajouter plus d'architectes au sommet ne va pas plus vite. Cultiver de meilleures décisions d'architecture à partir de zéro le fera. La technique du tableau de délégation aidera votre architecte à devenir plus à l'aise au fil du temps en déléguant de plus en plus de décisions aux équipes au fur et à mesure que ces équipes gagnent en confiance en faisant preuve de compétence.

Je pense à un grand architecte comme quelqu'un qui m'aide à mieux concevoir mes systèmes, qui me conseille patiemment lorsque je le demande et qui m'empêche parfois de prendre une très mauvaise décision. Un tel architecte agit comme un leader dans le vrai sens du mot: quelqu'un que d'autres suivent volontairement .

Je sais que c'était beaucoup.

Les références

Miller, la nouvelle vente stratégique . Ce livre comprend un modèle pour comprendre pourquoi vous n'avez pas réussi à conclure une vente spécifique. Je trouve cela précieux pour comprendre pourquoi les collègues ne feront pas la chose évidemment merveilleuse que je suggère.

Weinberg, devenir un leader technique . Ce livre m'a aidé à apprendre à faire la partie non-architecte du travail d'architecte efficace.

Appelo, panneaux de délégation et poker de délégation . Ne sous-estimez pas à quel point la délégation est difficile et combien nous aspirons. Apprenez à le faire plus efficacement et plus confortablement.


1
Votre touche "h" est-elle douteuse? ;)
Dave Hillier

3
Non, Dave. J'ai utilisé des pronoms Spivak (non sexistes).
JB Rainsberger

En raison des questions comme @DaveHillier, j'ai tendance à utiliser "il / elle" ... (Merci pour cette excellente réponse, soit dit en passant, remet la réalité dans "l'équipe est / fait / a / possède ..." clichés)
Marjan Venema

1
@ jdl134679 Le contrôle de version à la rescousse: softwareengineering.stackexchange.com/posts/260541/revisions
JB Rainsberger

1
@Walfrat Après réflexion, j'ai décidé de clarifier un peu plus ce point. Une personne qui se soucie essaiera d'apprendre ce dont elle a besoin pour apprendre, mais a probablement besoin de soutien, comme un mentor.
JB Rainsberger

10

Les meilleures architectures , exigences et conceptions émergent d'équipes auto-organisées

- Manifeste Agile

Ainsi, l'équipe s'auto-organise pour prendre des décisions architecturales de la manière qui lui convient. Il n'y a pas de règle stricte et rapide, cela peut aller du consensus à un «conseil» des membres les plus anciens, à la désignation d'un membre particulier comme autorité d'architecture, à laisser l'architecte choisir s'il y a un membre avec un tel titre de poste. .


9
J'aime Agile, mais c'est une grande faiblesse - l'architecture est souvent négligée ou pavée.
user949300

1
@ user949300 "Agile" comme dans le manifeste en dit très peu sur l'architecture. Sur quelles méthodes exactes tirez-vous cette conclusion? XP vous encouragerait à refactoriser sans pitié. Êtes-vous favorable à BUFD?
Dave Hillier

"XP vous encouragerait à refactoriser sans pitié": Jusqu'à ce que vous passiez plus de temps à refactoring qu'à écrire de nouveau code. Je pense que la meilleure solution est de trouver un équilibre entre les décisions architecturales fondamentales que vous prenez à l'avance après une analyse minutieuse, et les décisions de conception plus petites que vous mettez en œuvre en cours de refactorisation.
Giorgio

@ user949300, c'est parce que l'équipe n'est pas auto-organisée, s'ils l'étaient, ils seraient en communication fréquente avec le reste de l'équipe chaque fois qu'une décision d'architecture doit être prise et correctement documenter / argumenter / discuter de ces idées.
Rudolf Olah

3

Je pense que la réponse à "" qui est responsable de prendre des décisions d'architecture et de conception de haut niveau? "Dépend de la taille et du nombre d'équipes.

Pour une ou deux équipes avec 3-7 dans chaque équipe, l'équipe auto-organisée peut se débrouiller avec le plomb des membres seniors.

Pour 3 équipes ou plus, la complexité accrue conduit à la nécessité d'une équipe d'architecture qui peut voir si les différentes sous-équipes effectuent un travail qui s'interfacera avec les autres équipes. D'après mon expérience, ce point est atteint lorsqu'il y a environ 8 équipes ou environ 50 personnes.


1

Il y a de grandes ressources de l'équipe Scaled Agile Framework (SAFe) sur leur site.

Il vous aide essentiellement à faire évoluer l'agilité au sein de votre organisation, en allant au-delà d'une seule version et dans la planification de portefeuille et de programme. Leur documentation présente des suggestions sur la manière d'impliquer vos architectes d'entreprise et système dans le processus pour introduire des épopées architecturales dans le train de versions.

Modifiez pour plus de clarté afin d'aborder la question plus directement:

Dans un environnement agile à l'échelle, il existe plusieurs niveaux de propriété sur l'architecture. L'équipe de mise en œuvre agile sera propriétaire de l'architecture émergente de bas niveau en refactorisant au besoin pour poursuivre la mise en œuvre de ses arriérés. Les décisions architecturales de niveau supérieur (systèmes d'exploitation pris en charge, navigateurs, plates-formes, bibliothèques) sont sous la responsabilité de vos architectes système et d'entreprise. Ils feront l'analyse de rentabilisation du moment où ces changements doivent se produire et recommanderont que ces modifications architecturales soient ajoutées au train de versions pour les équipes d'implémentation.

Donc, en ce qui concerne les décisions d'architecture de haut niveau qui vont au-delà du sprint, vous les ferez généralement prendre à un niveau supérieur à l'équipe. Ces professionnels ont déjà traditionnellement un rôle «d'architecte» au sein de l'entreprise.


2
comment cela répond-il à la question posée, "qui est responsable de prendre les décisions d'architecture et de conception de haut niveau"?
moucher

1
Merci moucheron, j'ai essayé de le modifier pour clarifier mon intention de répondre à la question. J'ai fait quelques bonds dans ma tête, mais j'ai oublié de les écrire :)
Jay S

1

Je pense que la plupart des autres réponses y réfléchissent dans la perspective d'être à l'intérieur d'un projet.

Si c'est le seul niveau d'architecture d'une organisation, le résultat sera franchement le chaos. J'ai été témoin de ce chaos de première main, malheureusement cela arrive.

Selon TOGAF, le département d'architecture d'entreprise établit des plans de haut niveau pour et avec l'entreprise afin de créer et de remplacer l'environnement informatique. L'architecte d'entreprise aura défini des principes architecturaux et les aura approuvés au plus haut niveau de l'organisation et aidera à créer l'architecture et les exigences de haut niveau pour chaque projet. Chaque projet est initié pour fournir un bloc de construction architectural dans cette architecture de haut niveau.

Ainsi, au niveau du projet, l'architecte de solution créera l'architecture du projet (éventuellement de manière itérative) et obtiendra l'approbation de l'architecte d'entreprise.

Maintenant, pour se concentrer sur un projet agile. Un projet agile a des exigences. Ils ne sont pas sous la forme d'un "document sur les exigences" massif mais sont plutôt des épopées et des histoires. Ces épopées nécessitent encore une planification. Vous n'envoyez pas une équipe de développeurs sur quelques sprints dans l'inconnu. Vous savez à un niveau élevé ce que le système doit faire, avec quels autres systèmes il doit interagir et avec quelles contraintes matérielles / système d'exploitation / langage l'organisation a et cela guide et contraint les choix architecturaux ouverts à l'architecte de solutions. Par exemple, si vous êtes engagé à .NET et SQL Server, vous devez faire une trèscas convaincant pour mettre en œuvre un site de commerce électronique basé sur Magento en utilisant PHP et MySQL en raison des coûts impliqués dans la prise en charge de deux bases de données, deux langues, deux serveurs Web, etc. Alternativement, un projet pourrait choisir d'utiliser une bibliothèque complètement différente ou un look différent et sentir et cela pourrait avoir des implications pour tous les autres projets en vol. Il est essentiel d'avoir la supervision d'un architecte d'entreprise pour empêcher ce type de «dette architecturale».


0

Dépend de la conception organisationnelle de l'organisation et si le produit est dans un portefeuille. Les organisations plus grandes et axées sur les rôles peuvent nommer des architectes seniors pour diriger ce type d'activités.

Généralement, un architecte senior facilitera et guidera les décisions de conception car elles n'affectent pas seulement un backlog de produit, elles peuvent affecter plusieurs produits dans un portefeuille de produits.

Les petites entreprises agiles peuvent s'appuyer sur des développeurs experts en systèmes pour diriger l'équipe de développement afin de s'aligner sur la conception architecturale.

En fin de compte, les décisions architecturales doivent être convenues par l'équipe de livraison qui travaille sur le produit. Les architectes expérimentés et les responsables techniques se concentreront davantage sur l'animation de la discussion sur ce à quoi devrait ressembler le design, plutôt que de dicter le design.


0

Je pense que la plupart des réponses soulignent déjà que ce n'est pas une seule personne qui devrait prendre ces décisions.

Ce qu'ils ne touchent pas, c'est un autre principe Agile:

La simplicité - l'art de maximiser la quantité de travail non effectuée - est essentielle.

La réflexion sur les architectures de haut niveau et les décisions de conception n'est souvent pas prise avec simplicité, ce qui peut entraîner un gaspillage de beaucoup d'efforts et ajouter une complexité inutile qui pourrait rendre les choses plus difficiles à étendre.

Pensez à «jardiner» plutôt qu'à «architecturer» - Créez une culture de la vie, en développant le design

Au cours de votre itération actuelle, vous devez prendre des décisions d'architecture et de conception pour vos besoins actuels. Au lieu de regarder vers un avenir qui pourrait ne jamais devenir, concentrez-vous uniquement sur ce dont vous avez besoin maintenant. Probablement YAGNI une architecture bien pensée maintenant, laissez l'équipe la gérer petit à petit.

Autres lectures:

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.