Comment les architectes peuvent-ils travailler avec des équipes de mêlée auto-organisant?
Une organisation avec un certain nombre d'équipes d'Agile Scrum propose également un petit groupe de personnes nommées "architectes d'entreprise". Le groupe EA agit en tant que contrôle et gardien de la qualité et de l'adhésion aux décisions. Cela conduit à des chevauchements entre la décision d'équipe et les décisions de l'évaluation environnementale.
Par exemple, l'équipe peut vouloir utiliser la bibliothèque x ou vouloir utiliser REST au lieu de savon, mais l'EA n'approuve pas cela.
Cela peut maintenant conduire à la frustration lorsque les décisions d'équipe sont rejetées. Pris assez loin, cela peut potentiellement conduire à une situation où les gens de l'EA "saisissent" tout le pouvoir et l'équipe finit par se sentir démotivé et pas très agile du tout.
Les Guides Scrum a cela à dire à ce sujet:
Auto-organisant: Personne (pas même le Master Scrum) indique à l'équipe de développement comment transformer l'arriéré des produits en incréments de fonctionnalité potentiellement libérable.
Est-ce raisonnable? L'équipe EA devrait-elle être dissoute? Les équipes devraient-elles refuser ou simplement se conformer?
Une équipe de développement est composée de 3 à 9 personnes avec des compétences interfonctionnelles qui font le travail réel
Scrum Master devrait inviter "l'architecte d'entreprise" à devenir une partie de l'équipe de projet. Ensuite, la communication entre architecte et programmeurs serait excellente.
Le choix de la technologie utilisée fait partie des exigences du logiciel, ce qui signifie qu'il fait partie de la demande de fonctionnalité que vous n'utilisez pas certaines technologies, pour une raison quelconque.
Les architectes parlent des systèmes et du codeBase car les systèmes et la base de code ne peuvent pas parler d'eux-mêmes. Avoir un architecte est généralement dans l'intérêt supérieur à long terme d'une entreprise, en particulier celle qui repose sur des logiciels construits en interne.
Les architectes ne disent pas aux développeurs comment transformer l'arriéré en incréments (sprints), ils disent quelles technologies peuvent et ne peuvent pas être utilisées. Vous confondez deux problèmes différents.
La solution est de ne rien changer. Si vos équipes deviennent frustrées parce que les architectes sont trop restrictives ou trop dominantes, c'est une question de personnel qui n'a rien à voir avec Scrum et devrait être adoptée avec les intervenants de l'entreprise comme une question de satisfaction des employés et, si possible, le résultat final. ("Cela nous prend x% plus longtemps à développer des fonctionnalités pour y parce que l'architecte z ne nous laissez pas utiliser Turbo Pascal. ")
La question est la suivante: quelle est la raison pour laquelle cette équipe d'architecte existe? Seule raison à laquelle je peux penser, c'est de faire respecter l'interopérabilité entre diverses équipes. Ou les équipes travaillent sur diverses parties du seul produit et cette équipe d'architecte existe pour que chaque partie fonctionne ensemble.
Je ne pense vraiment pas que ce schéma puisse bien travailler dans l'environnement agile, pour des raisons exactes que vous dites. Les différentes équipes doivent être autonomes et doivent donc être leurs intrants et leurs produits. Donc, contraignant que leurs sorties ne doivent être que dans le cadre des exigences en matière de saisie. Mais ces contraintes devraient être raisonnables. Quelque chose comme "ne doit pas utiliser la bibliothèque x" n'est pas une bonne exigence, mais dire "Doit limiter le nombre de bibliothèques de 3e parties d'occasion au minimum" ou "d'ajouter de nouvelles bibliothèques, qui ne sont pas utilisées dans d'autres équipes devraient être limitées." devrait être bien.
Ensuite, je dissous l'équipe d'architecte dans toutes les équipes et j'utiliserais leur expertise en matière d'architecture. En devenant partiellement partie de l'équipe, ils pourront mieux voir des problèmes que l'équipe a et pourrait avoir de meilleures idées ou des opinions plus éduquées sur la modification de certaines parties de l'architecture. Il devrait également être encouragé aux architectes entre les équipes de communiquer pour assurer l'architecture reste cohérente entre les équipes.
Le groupe sur le groupe a structure agile échoué parler très bien. La plupart d'entre nous traitent au niveau de l'équipe, mais lors de la mise à l'échelle, nous devons reconnaître qu'il existe également des rôles au niveau du programme et du portefeuille. Les décisions architecturales doivent être apportées à travers l'organisation et devraient se nourrir de ce qui se passe aux niveaux inférieurs de l'organisation. Il n'y a rien de mal à avoir des décisions architecturales!
Relatif à cela, le livre récent de Dean Leffingwell sur - exigences logicielles agiles est une bonne lecture sur ce sujet, je l'ai lu moi-même.
Nous avons également plusieurs équipes agiles (certaines du Kanban, du Scrum) et des architectes. Les architectes sont responsables de l'infrastructure qui couvre tous nos produits (bibliothèques d'assistance, authentification, infrastructure de construction), etc. Ils prennent des décisions techniques, mais mettent également en œuvre des éléments, principalement des composants d'infrastructure.
Cela fonctionne bien et il n'y a généralement aucun conflit. Je crois qu'un point crucial est:
Les architectes ont non autorité formelle sur les équipes et ne peuvent pas les annuler. Normalement, les architectes prennent des décisions qui s'appliquent à tous les produits et les équipes prennent des décisions pour leur produit. S'il y a un conflit, alors l'architecte et l'équipe devaient juste atteindre un accord ou escalader la direction (bien que cela arrive rarement).
Je pense qu'il est vraiment important de rendre les architectes et les développeurs. Tous deux travaillent vers un objectif commun, juste dans différents domaines. Si personne ne peut simplement "annuler" l'autre, la coopération sera meilleure.
Je ne vois aucun conflit ici. D'après ce que je comprends, tout l'EA (comme un titre pompeux, je pense que c'est) est censé faire est Qa. Tout le monde devrait être conscient de cela.
Vous devriez envisager, que, dans toute méthodologie de développement (qui mérite d'être considéré comme une même), la collecte d'exigences est une étape cruciale, qu'elle soit itérative ou initiale.
Certaines de ces exigences sont définies par la politique de la société. Et ceux-ci fixent les règles du sol:
- L'équipe devra être respectée par toute autre exigence. Défi de la politique est alors simplement en dehors de la portée du projet et doit être traitée séparément.
- Le travail de l'EE est de faire respecter ces exigences et de ne pas imposer leur fantaisie personnelle. Ils n'aiment pas x alors c'est leur opinion personnelle. Ni plus ni moins. Traitez-le comme n'importe quelle autre opinion. Toutefois, si l'EA peut montrer que l'utilisation de X viole une exigence existante, ils sont bien à leur droit d'interdire l'utilisation de X et s'ils connaissent une alternative réalisable et l'équipe ne le fait pas, alors c'est leur droit de le faire respecter.
Mais de toute façon, une exigence est soit satisfaire ou non. Si cette détermination est difficile à faire, alors l'exigence manque et vous devez le réitérer pour devenir vraiment testable (dans un sens plus large). Vous devez gérer cela comme une réitération des exigences.
Martin, je pense que vous pouvez avoir une idée fausse sur la manière dont une équipe auto-organise fonctionne dans son environnement.
Vous avez cité le guide de Scrum: "Personne (pas même le Master Scrum) indique à l'équipe de développement comment transformer l'arriéré des produits en incréments de fonctionnalité potentiellement libérable."
Ce n'est pas une licence pour l'équipe de Scrum de faire ce qu'il veut (tant que cela fournit) sans tenir compte de la technologie et des besoins commerciaux de l'entreprise dans son ensemble et des besoins des autres équipes.
Bien sûr, les parties prenantes peuvent abuser de leur influence. C'est l'un des défis de la collaboration et il n'est certainement pas limité à l'EE. Mais la collaboration ne se termine pas à la limite de l'équipe.
Votre architecte ne devrait pas dépasser les décisions prises par vos équipes agiles. Votre architecte devrait les inclure dans les exigences/histoires transmises aux équipes. Ils devraient garder les équipes mis à jour lorsque le paysage des modifications du projet et les nouvelles exigences d'interopérabilité sont introduites.
Les architectes donnant des commandes et des décisions techniques de vérification sont une faille culturelle. Ils se voient comme le "patron" plutôt que de simplement maintenir un objectif/vision partagé et conservant des équipes distinctes sur la même page. Les méthodologies agiles sont basées sur la communication et le contact. Lorsque vos architectes ne sont pas impliqués avant que des décisions soient faites, elles échouent à Agile.
Cascade ou Scrum (cela semble être mélangé deux, qui, oui, ne va pas fonctionner), cela ressemble à une jolie couche de gestion inutile à moi en premier lieu. Les portes de la technologie des décisions de la technologie devraient être des Devs de plomb, le gestionnaire général de développement dont le travail devrait consister à garder les préférences de dev résulter de votre application dans une hydre des choix de technologie et que le budget de celui qui doit avoir à pied le projet de loi potentiel.
Rien ne continue de m'effacer de m'effacer comme des non-Devs ayant réellement la galerie de prendre des décisions technologiques sans même consulter les personnes réelles qui doivent subir les conséquences de ces décisions.