Nous recherchons des mod\u00e8les de cadrage simples pour clarifier notre r\u00e9flexion. Ces mod\u00e8les nous aident \u00e0 isoler explicitement les conditions n\u00e9cessitant des choix de configuration.<\/p>\n
![\"Six](\"https:\/\/conexiam.com\/wp-content\/uploads\/2021\/01\/Six-Use-Cases-for-Agile-EA-300x199.png\" "\\"Six")
L'agilit\u00e9, l'architecture d'entreprise et le d\u00e9veloppement agile de logiciels vont de pair.<\/p>\n
- \n
- Agilit\u00e9 d'entreprise<\/a><\/li>\n
- D\u00e9veloppement logiciel agile et architecture d'entreprise<\/a><\/li>\n
- Architecture d'entreprise<\/a> en utilisant des m\u00e9thodes agiles<\/li>\n<\/ol>\n
L'isolement des conditions vous permet de concevoir votre \u00e9quipe EA en toute confiance. Notre Services de capacit\u00e9 EA<\/a> utiliser le Naviguer<\/a> Architecture de r\u00e9f\u00e9rence des capacit\u00e9s EA<\/a>. Les \u00e9quipes EA performantes sont configur\u00e9es de mani\u00e8re optimale.<\/p>\n\t
Architecture agile et d'entreprise<\/a> s'accordent \u00e0 merveille. Les deux r\u00e9solvent diff\u00e9rentes parties du probl\u00e8me.<\/p>\n
Le d\u00e9veloppement logiciel agile excelle dans la cr\u00e9ation de solutions in\u00e9dites et inexplor\u00e9es. L'architecture d'entreprise excelle avant les d\u00e9cisions \u00e0 prendre lorsqu'on ne sait pas quoi faire.<\/p>\n
Mettre D\u00e9veloppement logiciel agile et architecture d'entreprise<\/a> ensemble pour optimiser le changement.<\/p>\n\t
La plupart des architectes s'int\u00e9ressent imm\u00e9diatement aux liens entre le d\u00e9veloppement d'entreprise et le d\u00e9veloppement agile. Nous avons vu beaucoup de personnes tenter de concilier deux univers radicalement diff\u00e9rents, g\u00e9n\u00e9ralement sans prendre le temps de comprendre aucun des deux.<\/p>\n
Nous optimisons l'architecture d'entreprise et le d\u00e9veloppement agile en les alignant sur leurs points forts. En r\u00e9sum\u00e9, l'architecture d'entreprise excelle avant les d\u00e9cisions difficiles. Le d\u00e9veloppement logiciel agile excelle \u00e0 cr\u00e9er des solutions in\u00e9dites.<\/p>\n
Ces deux m\u00e9thodes souffrent d'une mauvaise application chronique. Malgr\u00e9 le concept d'it\u00e9ration inh\u00e9rent \u00e0 TOGAF, trop d'architectes s'accrochent au diagramme en cascade de l'ADM et y voient un processus. Il est si facile d'y percevoir une cascade. Erreur, certes, mais tentant. De m\u00eame, le passage d\u00e9sorganis\u00e9 \u00e0 la phase de d\u00e9couverte du d\u00e9veloppement agile masque souvent leur propre d\u00e9sorganisation.<\/p>\n
Le monde actuel est complexe. \u00c0 moins qu'il ne s'agisse d'une simple cr\u00e9ation d'entreprise \u00e0 un seul tour, les produits logiciels doivent s'int\u00e9grer dans un \u00e9cosyst\u00e8me complexe. Les processus, l'organisation, les partenaires et l'infrastructure existants permettent \u00e0 l'entreprise de servir ses clients. Le nouveau produit doit enrichir l'\u00e9cosyst\u00e8me tout en s'y int\u00e9grant.<\/p>\n
C\u2019est dans la complexit\u00e9 du monde r\u00e9el que le d\u00e9veloppement agile et l\u2019architecture d\u2019entreprise efficaces r\u00e9v\u00e8lent tout leur potentiel. Misez sur leurs atouts. Nous fondons nos pratiques de d\u00e9veloppement logiciel agile sur la r\u00e9solution d\u2019une tension essentielle.<\/p>\nTension agile
\nVous savez o\u00f9 vous allez. Vous ne savez pas comment y arriver.<\/em><\/strong>\n\t\tGuide de l'architecte d'entreprise<\/h3>\t\t\n\t\t\t
T\u00e9l\u00e9chargez le Guide de l'architecte d'entreprise<\/a> un guide de la s\u00e9rie TOGAF sur le d\u00e9veloppement d'une architecture d'entreprise utile.<\/p>\n\t
Exemples de cas d'utilisation d'Agile EA<\/h2>\n
Cas d'utilisation 1\u00a0: Architecture d'une entreprise agile<\/h3>\n
Dans ce cas d'utilisation, l'objectif EA est contraint d'exiger des architectures cibles acceptables pour donner la priorit\u00e9 \u00e0 l'agilit\u00e9.<\/p>\n
Franchement, cela n'a rien \u00e0 voir avec les m\u00e9thodes agiles. De nombreuses organisations agiles avec lesquelles nous avons travaill\u00e9 n'utilisent pas les m\u00e9thodes de gestion du changement agiles.<\/p>\n
Nous nous inspirons largement de la Supply Chain et de la Gestion des Catastrophes comme r\u00e9f\u00e9rences en mati\u00e8re d'agilit\u00e9. Nous utilisons cinq attributs d'agilit\u00e9 (issus de la recherche sportive et militaire)\u00a0:<\/p>\n
- \n
- Vigilance<\/li>\n
- Accessibilit\u00e9<\/li>\n
- Esprit de d\u00e9cision<\/li>\n
- Rapidit\u00e9<\/li>\n
- Flexibilit\u00e9<\/li>\n<\/ul>\n
Ce cas d'utilisation exerce Atlas d'entreprise agile Navigate de Conexiam<\/a>. Il optimise le d\u00e9veloppement de l'architecture pour l'agilit\u00e9 gr\u00e2ce \u00e0 une biblioth\u00e8que de points de vue sp\u00e9cialis\u00e9s, \u00e0 l'engagement et aux pr\u00e9occupations des parties prenantes.<\/p>\n
En clair, ce cas d'utilisation est dangereux s'il ne correspond pas aux v\u00e9ritables pr\u00e9f\u00e9rences des principaux acteurs de l'organisation.<\/p>\n
En termes de TOGAF<\/a>, ce cas d'utilisation est principalement ax\u00e9 sur le TOGAF ADM <\/a>Activit\u00e9 de r\u00e9alisation de valeur de phase G et de phase H, o\u00f9 le changement doit \u00eatre align\u00e9 sur la cr\u00e9ation et le maintien d'une entreprise agile.<\/p>\n
Cas d'utilisation 2\u00a0: Utiliser l'EA pour d\u00e9finir une approche agile du changement<\/a><\/h3>\n
![\"Produit](\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\" "\\"Six")
Dans ce cas d'utilisation, l'architecture d'entreprise sert \u00e0 structurer la mani\u00e8re dont l'entreprise ex\u00e9cute le changement. Les produits, la structure de l'\u00e9quipe de sprint, la v\u00e9locit\u00e9 et l'alignement avec toutes les approches de changement sont pris en compte.<\/p>\nLes questions \u00e0 aborder sont\u00a0: quel changement\u00a0? Quel d\u00e9veloppement adopter et quelle approche\u00a0? Dans le cas des m\u00e9thodes agiles, des questions telles que le produit, la structure de l'\u00e9quipe de sprint et la v\u00e9locit\u00e9 sont toutes trait\u00e9es.<\/p>\n
Ce cas d'utilisation exerce en grande partie la TOGAF ADM<\/a> Phase F, G et H bas\u00e9es sur une architecture strat\u00e9gique ou de portefeuille.<\/p>\n
Cas d'utilisation 3\u00a0: Utiliser EA pour guider la planification du backlog et du sprint<\/a><\/h3>\n
Du point de vue de l'architecture d'entreprise et TOGAF,<\/a> Toutes les phases d'impl\u00e9mentation, de prototypage, de pilotage, de projet et de sprints agiles se d\u00e9roulent en phase G. L'architecture d'entreprise (AE) conforme aux meilleures pratiques produira une architecture d'entreprise compl\u00e8te avec un cahier de livraison de solutions, des \u00e9carts, des contr\u00f4les, une sp\u00e9cification d'architecture et un lot de travaux. Ces \u00e9l\u00e9ments doivent \u00eatre d\u00e9crits en termes adapt\u00e9s au backlog\u00a0: \u00e9pop\u00e9e, r\u00e9cit utilisateur et piste d'architecture.<\/p>\n
L'architecture d'entreprise comprendra un ensemble de lacunes, des lots de travaux pour les combler et des limitations \u00e0 la cr\u00e9ativit\u00e9 des \u00e9quipes de mise en \u0153uvre quant \u00e0 leur libert\u00e9 d'action. Elle assurera la tra\u00e7abilit\u00e9 des facteurs, objectifs et priorit\u00e9s qui ne rel\u00e8vent pas du chef de produit ni du client.<\/p>\n
En m\u00e9thode agile classique, les \u00e9pop\u00e9es et les r\u00e9cits utilisateurs ax\u00e9s sur le client compl\u00e8tent le backlog. Le client fournit les crit\u00e8res de priorisation. L'\u00e9quipe agile auto-organis\u00e9e priorise le travail.<\/p>\n
Ce cas d'utilisation utilise l'architecture d'entreprise pour fournir un backlog non bas\u00e9 sur le client et guider la priorisation dans la planification des sprints.<\/p>\n
Dans ce contexte, les \u00e9pop\u00e9es et les r\u00e9cits utilisateurs sont d\u00e9riv\u00e9s des \u00e9carts et des lots de travaux. Les d\u00e9pendances externes limitent la priorisation, les crit\u00e8res d'acceptation et les crit\u00e8res de sortie. Des priorit\u00e9s prioritaires peuvent \u00eatre d\u00e9finies.<\/p>\n
Ce cas d\u2019utilisation exerce principalement la TOGAF ADM<\/a> Phase G, Gouvernance de la mise en \u0153uvre\u00a0: en langage clair, au cours de la phase G, l'\u00e9quipe de mise en \u0153uvre est inform\u00e9e des t\u00e2ches \u00e0 accomplir et des contraintes externes qui p\u00e8sent sur sa libert\u00e9 d'action. La communication de l'\u00e9quipe d'architecture d'entreprise est d\u00e9termin\u00e9e par l'organisation de l'\u00e9quipe de mise en \u0153uvre.<\/p>\n
L'\u00e9l\u00e9ment crucial est d'aligner la gouvernance de l'AE sur le mod\u00e8le de changement agile. La dynamique de l'\u00e9quipe de sprint ne doit pas \u00eatre entrav\u00e9e.<\/p>\n
Cas d'utilisation 4\u00a0: Utiliser EA pour contraindre les sprints agiles<\/a><\/h3>\n
Ce cas d'utilisation exerce en grande partie la gouvernance de mise en \u0153uvre de la phase G de TOGAF ADM.<\/p>\n
Suivant meilleures pratiques de gouvernance de l'architecture d'entreprise<\/a>\u00a0la question essentielle est :<\/p>\n
L'\u00e9quipe agile a-t-elle interpr\u00e9t\u00e9 de mani\u00e8re raisonnable les directives et contraintes document\u00e9es de l'architecture cible\u00a0?<\/p>\n
- \n
- \n
- \n
- Si oui, leur interpr\u00e9tation doit \u00eatre accept\u00e9e comme une conformit\u00e9 et tout probl\u00e8me doit \u00eatre r\u00e9solu par une modification de l'architecture.<\/li>\n
- Si ce n\u2019est pas le cas, \u00e9laborez une recommandation pour corriger la situation.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
C'est un point essentiel. Une bonne architecture peut avoir plusieurs options d'impl\u00e9mentation, et l'\u00e9quipe agile n'est pas tenue de se conformer \u00e0 une opinion. Si l'impl\u00e9mentation choisie constitue une interpr\u00e9tation raisonnable, elle doit \u00eatre jug\u00e9e conforme. Si un \u00e9l\u00e9ment a \u00e9t\u00e9 omis dans la sp\u00e9cification d'architecture, cela ne rel\u00e8ve pas de la responsabilit\u00e9 de l'\u00e9quipe agile, mais de celle de l'\u00e9quipe d'architecture d'entreprise, qui doit apporter une modification \u00e0 l'architecture approuv\u00e9e.<\/p>\n
L'\u00e9l\u00e9ment critique est l'alignement gouvernance de l'architecture d'entreprise<\/a> Activit\u00e9 avec un mod\u00e8le de changement agile. La dynamique de l'\u00e9quipe de sprint ne doit pas \u00eatre entrav\u00e9e.<\/p>\n
Les lacunes, la strat\u00e9gie des lots de travaux, les contr\u00f4les et les sp\u00e9cifications d'architecture guident et contraignent les sprints. Ils doivent \u00eatre r\u00e9dig\u00e9s et pr\u00e9sent\u00e9s dans des termes compr\u00e9hensibles par l'\u00e9quipe agile. Les contr\u00f4les et les sp\u00e9cifications d'architecture sont g\u00e9n\u00e9ralement pr\u00e9sent\u00e9s sous forme de crit\u00e8res d'acceptation et de crit\u00e8res de sortie.<\/p>\n
Cas d'utilisation 5\u00a0: Utiliser EA pour r\u00e9soudre la d\u00e9pendance<\/a><\/h3>\n
Dans ce cas d'utilisation, l'architecture d'entreprise est utilis\u00e9e pour g\u00e9rer la d\u00e9pendance et l'impact sur les \u00e9quipes agiles.<\/p>\n
Ce cas d'utilisation diff\u00e8re du cas d'utilisation 4, car il modifie la fa\u00e7on dont l'\u00e9quipe d'architecture d'entreprise s'implique. Souvent, lorsqu'il existe une d\u00e9pendance, elle se situe entre diff\u00e9rentes m\u00e9thodes de changement (agile et en cascade), et les choix effectu\u00e9s au cours d'un sprint peuvent avoir des cons\u00e9quences en cascade.<\/p>\n
Un r\u00f4le cl\u00e9 du d\u00e9veloppement architecture pour soutenir la livraison de solutions<\/a> Il s\u2019agit d\u2019identifier et de traiter ces d\u00e9pendances avant qu\u2019une \u00e9quipe agile ne tr\u00e9buche dessus.<\/p>\n
Dans le cas d'usage 4, un indicateur de succ\u00e8s consiste \u00e0 veiller \u00e0 ce que la dynamique ne soit pas frein\u00e9e. Dans ce cas pr\u00e9cis, la dynamique d'une \u00e9quipe doit \u00eatre \u00e9quilibr\u00e9e par rapport \u00e0 celle des autres \u00e9quipes agiles, des unit\u00e9s op\u00e9rationnelles et des \u00e9quipes qui utilisent d'autres m\u00e9thodes de gestion du changement.<\/p>\n
Ce cas d'utilisation exerce largement l'activit\u00e9 de gouvernance et de modification des ordres de modification de la phase G de TOGAF ADM. Franchement, meilleures pratiques de gouvernance de l'architecture d'entreprise<\/a> \u00c9vite d'accorder des exemptions aux d\u00e9pendances inter-\u00e9quipes en mati\u00e8re d'architecture. Les d\u00e9fis non identifi\u00e9s constituent le domaine le plus courant d'exemptions en mati\u00e8re d'architecture.<\/p>\n
Les probl\u00e8mes de d\u00e9pendance rel\u00e8vent de la responsabilit\u00e9 de l'\u00e9quipe d'architecture d'entreprise. Celle-ci devra d\u00e9ployer des efforts consid\u00e9rables pour sortir l'organisation de ces impasses. La r\u00e9solution de ces probl\u00e8mes exige une attention particuli\u00e8re \u00e0 l'architecture, aux contr\u00f4les et aux sp\u00e9cifications d'architecture de niveau sup\u00e9rieur, tels qu'ils sont d\u00e9finis dans les Principes.<\/p>\n
Cas d'utilisation 6\u00a0: Utiliser des m\u00e9thodes agiles pour d\u00e9velopper l'architecture d'entreprise<\/h3>\n
Dans ce cas d'utilisation, la capacit\u00e9 EA est configur\u00e9e pour utiliser des m\u00e9thodes agiles pour d\u00e9velopper une architecture d'entreprise.<\/p>\n
Conexiam EA pr\u00e9visible<\/a> Voici un exemple de ce cas d'utilisation. Pour mieux comprendre comment une architecture sert d'aide \u00e0 la d\u00e9cision, nous d\u00e9signons couramment le produit final comme le \u201c\u00a0classeur de conseils\u00a0\u201d. Ce classeur est optimis\u00e9 en fonction de l'objectif et du probl\u00e8me. Il sera utilis\u00e9 de diff\u00e9rentes mani\u00e8res.<\/p>\n
Ce cas d'utilisation aura un impact majeur sur l'ex\u00e9cution de toutes les phases ADM de d\u00e9veloppement de l'architecture. Il d\u00e9pend des r\u00e9sultats de la phase pr\u00e9liminaire, ainsi que de la structure et de l'ex\u00e9cution de la capacit\u00e9 AE.<\/p>\n\t
Les praticiens qui \u0153uvrent aux extr\u00eames du d\u00e9veloppement logiciel agile et de l'architecture d'entreprise ne se rencontreront probablement jamais. Ils pourraient m\u00eame ne pas reconna\u00eetre le travail de l'autre. La tension essentielle r\u00e9side dans leur relation.<\/p>\n
Lorsqu'on examine l'alignement des meilleures pratiques en architecture d'entreprise et en d\u00e9veloppement agile, notamment dans leurs domaines d'interaction fondamentaux, l'\u00e9vidence s'impose. Les praticiens qui se situent aux extr\u00eames de l'un ou de l'autre domaine peuvent ignorer le travail de l'autre au sein de l'entreprise et ne jamais voir leurs productions respectives.<\/p>\n
Un praticien AE soutenant la strat\u00e9gie et un responsable technique au sein d'une \u00e9quipe de d\u00e9veloppement logiciel agile travaillent \u00e0 distance. Le responsable technique dispose d'une fen\u00eatre d'ex\u00e9cution qui se mesure en semaines ou en mois. Les plans de d\u00e9ploiement ou les pistes d'architecture s'inscrivent dans une r\u00e9flexion \u00e0 long terme. Le praticien AE strat\u00e9gique a peut-\u00eatre travaill\u00e9 des ann\u00e9es \u00e0 l'avance sur la feuille de route d\u00e9finissant le d\u00e9veloppement des capacit\u00e9s de d\u00e9veloppement logiciel agile.<\/p>\n\t\t
Guide de l'architecte d'entreprise<\/h3>\t\t\n\t\t\t
T\u00e9l\u00e9chargez le Guide de l'architecte d'entreprise<\/a> un guide de la s\u00e9rie TOGAF sur le d\u00e9veloppement d'une architecture d'entreprise utile.<\/p>\n\t\t\t\t
\n\t
- \n
- D\u00e9veloppement logiciel agile et architecture d'entreprise<\/a><\/li>\n
![\"Produit](\"https:\/\/conexiam.com\/wp-content\/uploads\/2020\/05\/EA-supporting-Agile-Development-Work-Product-300x204.png\" "\\"Six")
Dans ce cas d'utilisation, l'architecture d'entreprise sert \u00e0 structurer la mani\u00e8re dont l'entreprise ex\u00e9cute le changement. Les produits, la structure de l'\u00e9quipe de sprint, la v\u00e9locit\u00e9 et l'alignement avec toutes les approches de changement sont pris en compte.<\/p>\n![\"Objectif](\"https:\/\/conexiam.com\/wp-content\/uploads\/2020\/05\/Roles-of-EA-300x120.png\" "\\"Objectif")
\n\t