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?
Réponses:
la source
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
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
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.
la source
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. .
la source
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.
la source
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.
la source
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».
la source
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.
la source
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 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.
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:
la source