Six cas d'utilisation Agile EA

Six cas d'utilisation Agile EA identifient comment concevoir une équipe EA pour différentes conditions. Méthodes agiles pour EA, EA soutenant le développement agile et une entreprise agile.

Nous recherchons des modèles d'encadrement simples pour clarifier notre réflexion. Les modèles de cadrage doivent nous aider à isoler explicitement les conditions dans lesquelles nous devons faire des choix de configuration.

Six cas d'utilisation pour Agile EAAgilité, architecture d'entreprise et développement logiciel agile vont de pair.

  1. Agilité d'entreprise
  2. Développement logiciel agile et architecture d'entreprise
  3. L'architecture d'entreprise en utilisant des méthodes agiles

L'isolement des conditions vous permet de concevoir votre équipe EA en toute confiance. Notre Services de capacité EA Utilisez le Naviguer Architecture de référence des capacités EA. Les équipes EA fonctionnant de manière optimale sont configurées de manière optimale.

Architecture agile et d'entreprise s'emboîtent à merveille. Les deux résolvent différentes parties du problème.

Le développement logiciel agile excelle dans la construction de quelque chose que nous n'avons jamais eu auparavant et que nous ne savons pas comment faire. L'architecture d'entreprise excelle avant les décisions lorsque vous ne savez pas quoi faire.

Mettre Développement logiciel agile et architecture d'entreprise ensemble pour optimiser le changement.

La plupart des architectes se rendent compte de la relation entre l'entreprise et le développement agile. Nous avons vu de nombreuses personnes essayer d'assembler deux mondes extrêmement divergents, généralement sans s'arrêter pour comprendre non plus.

Nous optimisons l'architecture d'entreprise et le développement agile en les alignant sur leurs forces. Le raccourci que nous utilisons est que l'architecture d'entreprise excelle avant les décisions lorsque vous ne savez pas quoi faire. Le développement logiciel agile excelle dans la création de quelque chose que nous n'avons jamais eu auparavant.

Les deux méthodes souffrent d'une mauvaise application chronique. Malgré le concept d'itération inhérent à TOGAF, trop d'architectes s'accrochent au diagramme de crop circles ADM et voient le processus. Il est si facile de voir une cascade dans le diagramme ADM. Faux, mais facile. De plus, le saut désorganisé sur le chemin de la découverte dans le développement agile pour cacher leur désorganisation.

Le monde actuel est en désordre. À moins que nous ne parlions d'un simple greenfield à un tour, les produits logiciels doivent s'intégrer dans un écosystème complexe. Les processus, l'organisation, les partenaires et l'infrastructure existants permettent à l'entreprise de servir ses clients. Le nouveau produit doit améliorer l'écosystème tout en s'intégrant.

C'est dans la complexité du monde réel que le développement agile efficace et l'architecture d'entreprise brillent. Jouez à leurs points forts. Nous basons une solide pratique de développement logiciel agile sur la résolution d'une tension essentielle.

Tension agile
Tu sais où tu vas. Tu ne sais pas comment y arriver

Guide de l'architecte d'entreprise

Téléchargez le Guide de l'architecte d'entreprise un guide de la série TOGAF sur le développement d'une architecture d'entreprise utile. test

Exemples de cas d'utilisation d'EA Agile

Cas d'utilisation 1: concevoir une entreprise agile

Dans ce cas d'utilisation, l'objectif de l'EA est contraint d'exiger des architectures cibles acceptables pour donner la priorité à l'agilité.

Franchement, cela n'a rien à voir avec les méthodes agiles. De nombreuses organisations agiles avec lesquelles nous avons travaillé n'utilisent pas de méthodes de changement agiles.

Nous nous appuyons largement sur la chaîne d'approvisionnement et la réponse aux catastrophes en tant que pierres de touche de haute agilité. Nous utilisons 5 attributs pour l'agilité (tirés de la recherche sportive et militaire):

  • Vigilance
  • Accessibilité
  • Esprit de décision
  • Rapidité
  • La flexibilité

Cet exercice de cas d'utilisation Navigate Agile Enterprise Atlas de Conexiam. Il optimise le développement de l'architecture pour l'agilité grâce à une bibliothèque de points de vue spécialisée, à l'engagement des parties prenantes et aux préoccupations.

Franchement, ce cas d'utilisation est dangereux s'il ne correspond pas aux véritables préférences de la puissante partie prenante d'une organisation.

En terme de TOGAF, ce cas d'utilisation est principalement axé sur le TOGAF ADM Activité de réalisation de valeur des phases G et H, où le changement doit être aligné sur la création et le maintien d'une entreprise agile.

Cas d'utilisation 2: utiliser EA pour définir une approche agile du changement

Produit de travail d'architecture agile et d'entrepriseDans ce cas d'utilisation, l'architecture d'entreprise est utilisée pour structurer la manière dont l'entreprise effectue le changement. Les produits, la structure de l'équipe Sprint, la vitesse, l'alignement avec toutes les approches de changement sont effectués.

Les questions à se poser sont de savoir quel changement, quel développement devrait suivre quelle approche. Dans le cas des méthodes agiles, des questions telles que le produit, la structure de l'équipe Sprint, la vitesse sont toutes répondues.

Ce cas d'utilisation exerce en grande partie la TOGAF ADM Phase F, G & H basée sur une architecture stratégique ou de portefeuille.

Cas d'utilisation 3: utiliser EA pour guider la planification du backlog et du sprint

Du point de vue de l'architecture d'entreprise et TOGAF, tous les sprints d'implémentation, de prototypage, de pilotage, de projet et d'agilité se produisent avec la phase G. Meilleures pratiques EA produira une architecture d'entreprise remplie d'un cahier de livraison de solution, d'un espace, d'un contrôle, d'une spécification d'architecture et d'un package de travail. Ce matériel doit être décrit en termes adaptés au backlog: Epic, User Story et Architecture Runway.

L'architecture d'entreprise contiendra un ensemble de lacunes, des lots de travaux pour combler ces lacunes et des limites sur la créativité de la liberté des équipes de mise en œuvre pour effectuer le changement. Il comprendra la traçabilité des pilotes, des objectifs et des priorités en dehors de la compétence du chef de produit et du client.

Dans l'agilité classique, les histoires d'Epics et d'Utilisateurs axées sur le client remplissent le back-log. Le client fournit des critères de priorisation. L'équipe agile auto-organisée priorise le travail.

Ce cas d'utilisation utilise l'architecture d'entreprise pour fournir un backlog non client et guider la hiérarchisation dans la planification de sprint.

Dans cette utilisation, des épopées et des histoires d'utilisateurs dérivées de lacunes et de packages de travail. La dépendance externe limite la hiérarchisation, les critères d'acceptation et les critères de sortie. Des priorités primordiales peuvent être fournies.

Ce cas d'utilisation exerce principalement TOGAF ADM Phase G, Gouvernance de la mise en œuvre: dans un langage simple au sein de la phase G, une équipe de mise en œuvre est informée du travail qu'elle doit effectuer et des contraintes externes sur sa liberté d'exécuter le travail. La façon dont l'équipe EA communique est déterminée par l'organisation de l'équipe de mise en œuvre.

L'élément critique consiste à aligner l'activité de gouvernance d'EE sur le modèle de changement agile. La dynamique de l'équipe de sprint ne doit pas être entravée.

Cas d'utilisation 4: utiliser EA pour contraindre les sprints agiles

Ce cas d'utilisation exerce en grande partie la TOGAF ADM Phase G, gouvernance de la mise en œuvre.

Suivant meilleure pratique EA Governance la question essentielle est:

L'équipe agile a-t-elle raisonnablement interprété les conseils et les contraintes documentés de l'architecture cible?

    • Si oui, leur interprétation doit être acceptée comme étant la conformité et tout problème résolu par une modification de l'architecture
    • Si non, élaborez une recommandation pour corriger la situation.

C'est un point clé. Une bonne architecture peut avoir plusieurs choix d'implémentation, et l'équipe agile n'est pas obligée de se conformer à l'opinion. Si le choix de mise en œuvre est une interprétation raisonnable, il doit être jugé conforme. Si quelque chose a été omis de la spécification d'architecture, ce n'est pas le problème de l'équipe agile. C'est le problème de l'équipe EA, ils ont besoin d'une modification de l'architecture approuvée.

L'élément critique est l'alignement Gouvernance de l'EE activité avec un modèle de changement agile. La dynamique de l'équipe de sprint ne doit pas être entravée.

Les lacunes, la stratégie de lot de travail, les contrôles et la spécification d'architecture guident et contraignent les sprints. Ils doivent être rédigés et présentés dans des termes que l'équipe agile peut consommer. Les contrôles et les spécifications d'architecture sont généralement présentés comme des critères d'acceptation et des critères de sortie.

Cas d'utilisation 5: utiliser EA pour résoudre la dépendance

Dans ce cas d'utilisation, l'architecture d'entreprise est utilisée pour traiter la dépendance et l'impact entre les équipes agiles.

Ce cas d'utilisation est distinct du cas d'utilisation 4, car il change la façon dont l'équipe EA s'engage. Souvent, là où il y a une dépendance, ce sera entre différentes méthodes de changement (agile et cascade) et là où les choix au sein d'un sprint peuvent avoir des impacts en cascade.

Un rôle clé du développement architecture pour prendre en charge la livraison de solutions est d'identifier et de résoudre ces dépendances avant qu'une équipe agile ne les aborde.

Dans le cas d'utilisation 4, une mesure de succès est de s'assurer que l'élan n'est pas altéré. Dans ce cas d'utilisation, l'élan d'une équipe doit être équilibré par rapport aux autres équipes agiles, unités opérationnelles et équipes qui utilisent d'autres méthodes de changement.

Ce cas d'utilisation exerce en grande partie l'activité de gouvernance et de demande de changement de TOGAF ADM Phase G. Franchement,  meilleure pratique EA Governance évite d'accorder des exemptions aux problèmes de dépendance inter-équipes d'architecture qui n'ont pas été identifiés sont le domaine le plus courant d'exemptions d'architecture.

Les problèmes de dépendance sont le problème de l'équipe EA, elle devra effectuer un travail pour creuser l'organisation le plus efficacement possible.

Cas d'utilisation 6: utiliser des méthodes agiles pour développer une architecture d'entreprise

Dans ce cas d'utilisation, la capacité EA est configurée pour utiliser des méthodes agiles pour développer une architecture d'entreprise.

EA prévisible Conexiam est un exemple de ce cas d'utilisation. Pour aider à comprendre qu'une architecture est utilisée pour soutenir la prise de décision, nous nous référons régulièrement au produit de travail utile sous le nom de «dossier de conseils». Ce classeur est optimisé pour le but et le problème. Il sera consommé de plusieurs manières différentes.

Ce cas d'utilisation aura un impact important sur l'exécution de toutes les phases d'ADM pour développer l'architecture. Ce cas d'utilisation dépend du résultat de la phase préliminaire, ainsi que de la structure et de l'exécution de la capacité d'EA.

Les praticiens qui travaillent aux extrêmes du développement logiciel agile et de l'architecture d'entreprise ne se rencontreront probablement jamais. Ils pourraient même ne pas reconnaître le produit du travail de l'autre. La tension essentielle réside dans leur relation les uns avec les autres.

Lorsque vous vous arrêtez et considérez l'alignement des meilleures pratiques EA et du développement logiciel agile des meilleures pratiques pour les domaines de base où ils interagissent devient évident. Les praticiens qui travaillent aux extrêmes de l'architecture d'entreprise ou du développement logiciel agile peuvent ne jamais savoir ce que l'autre personne travaille pour l'entreprise, ils peuvent ne pas voir le produit de travail de l'autre.

Un praticien d'EA travaillant pour soutenir la stratégie et un responsable technique au sein d'une équipe logicielle agile travaillent loin l'un de l'autre. Le responsable technique vit une fenêtre d'exécution mesurée en semaines ou en mois. Les plans de publication ou les pistes d'architecture sont une réflexion à long terme. Le praticien de l'EE stratégique aurait pu travailler pendant des années à l'avance sur la feuille de route qui décrivait le développement de la capacité de développement de logiciels agiles.

Guide de l'architecte d'entreprise

Téléchargez le Guide de l'architecte d'entreprise un guide de la série TOGAF sur le développement d'une architecture d'entreprise utile. test

https://conexiam.com/togaf-9-2-body-of-knowledge/

L'alignement de votre équipe d'architecture d'entreprise sur différents cas d'utilisation agiles permet d'identifier les plus applicables Cas d'utilisation de l'architecture d'entreprise.

Rejoignez le Kickstart de l'architecture d'entreprise personnelle

Programme gratuit de 12 semaines pour devenir un meilleur architecte d'entreprise

Retour haut de page