Comprendre le développement agile et l'EA

L'architecture agile et d'entreprise s'accordent à 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.

Agilité, architecture d'entreprise et développement de logiciels s'articulent autour de trois domaines

  1. architecte une entreprise agile
  2. pratiques de travail agiles pour développer une architecture d'entreprise conforme aux meilleures pratiques
  3. développement logiciel agile et architecture d'entreprise

La plupart des architectes sautent au dernier. Ils essaient d'assembler deux mondes extrêmement divergents, généralement sans s'arrêter pour comprendre non plus.

J'ai eu une conversation amusante avec le nouvel ingénieur en fiabilité des systèmes. Le spécialiste SRE était enthousiasmé. Nous avons enfin commencé les pratiques modernes CI / CD pratiques. Elle m'a demandé ce que l'équipe EA faisait pour aider?

J'ai dû sourire quand elle a demandé, 'que fait EA Team pour aider? ' Ce qu'elle voulait vraiment dire, c'était: 'que fais-tu pour me soutenir aujourd'hui? ' Aujourd'hui, contre ses défis immédiats, cela pourrait être - rien. Elle a sauté sur la façon dont l'équipe EA soutenait son travail quotidien.

Elle n'a jamais vu la feuille de route du portefeuille qui apportait des conteneurs, une gestion des données de test et, franchement, une suite de tests automatisés ridiculement insuffisante. Elle ne se rendait pas compte que la même vieille feuille de route identifiait un point de transition qui a financé son emploi.

Les équipes EA performantes répondent à leur objectif. Ils ne livrent rien d'autre. Même s'ils le pouvaient.

Six cas d'utilisation couvrent tous les aspects de l'architecture agile et d'entreprise

Un cadre simple pour réfléchir à l'architecture d'entreprise est de se demander ce qu'ils prennent en charge?

  1. Stratégie de soutien
  2. Support Portfolio
  3. Projet de soutien
  4. livraison de solution de support

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

Développement agile et architecture d'entreprise

Lors de la liaison avec le développement de logiciels agiles, la même question est posée, à quoi l'équipe devrait-elle aider pour y répondre. Une partie de l'alignement est motivée par ce que l'équipe d'architecture d'entreprise est censée prendre en charge.

  1. définir l'approche agile
  2. guider le backlog dans le sprint
  3. contraindre les sprints
  4. résolution de la dépendance entre produits
Produit de travail d'architecture agile et d'entreprise

Architecture agile et d'entreprise: définir l'approche agile

En règle générale, une équipe d'EE au service de la stratégie et du portefeuille définir l'approche agile.

Produit

Les produits apparaissent sur une feuille de route sous forme de lacunes ou de lots de travaux. L'équipe EA peut parler de capacité ou de service commercial. Quand ils le font, attendez-vous à voir les produits nouveaux ou retravaillés.

Plateformes

EA soutenant le produit de travail de développement AgileQu'est-ce qui prendra en charge ou fonctionnera le produit? Savoir si le produit est autonome, basé sur une nouvelle plate-forme, en utilisant une plate-forme existante ou en s'appuyant sur des plates-formes tierces, définira les éléments clés de votre approche agile, généralement bien avant le sprint zéro.

Les praticiens plus faibles se fixeront sur la définition de termes tels que «plate-forme». Une définition nette et trop précise est un piège. Prenez quelques secondes de considération, il est parfaitement raisonnable pour quelqu'un de parler de SAP, 0365, Facebook, Pega ou même Angular et Containers en tant que plates-formes. Le terme a besoin d'un contexte pour une définition étroite. Tout ce dont vous avez besoin, c'est que le consommateur et l'opérateur se mettent d'accord. J'ai succombé à la tentation de spécifier un produit qui était une plateforme consommée par d'autres. Les pédants ont essayé de déterminer s'il s'agissait d'un produit ou d'une plate-forme.

Stratégie de prestation de services

Les feuilles de route de niveau supérieur indiquent mieux comment mettre en œuvre la transformation. Les exemples comprennent.

  • Construire une capacité interne robuste ou faire appel à des tiers?
  • Assurer des systèmes durables à long terme ou traiter certains ou tous les produits comme des Kleenex jetables?

Points de repos de grande valeur

Nous utilisons régulièrement des points de repos de valeur comme synonyme de transitions d'architecture. Fournissez toujours à vos parties prenantes une sortie de piste. Nous utilisons des rampes de sortie pour deux raisons:

  1. Lorsque l'effort pour atteindre le point de repos suivant dépasse la valeur incrémentielle.
    Ceci est une conversation sur le retour sur investissement. Les conversations sur le retour sur investissement entraînent généralement un changement de priorité.
  2. Lorsque l'effort pour atteindre un point de repos pourrait atteindre un repos plus excitant ou plus gratifiant.

Les conversations de compromis fournissent l'un des résultats les plus précieux d'un exercice de stratégie ou de feuille de route de portefeuille. Les ressources sont limitées. Les hauts dirigeants sont toujours à la recherche de la meilleure voie à suivre, et non du rendement potentiel le plus élevé. Le meilleur chemin. Les considérations comprennent la valeur comparative au repos et la valeur potentielle comme tremplin pour d'autres activités.

Les développeurs comprennent rarement ces conversations. Ils deviennent émotionnellement investis dans un chemin ou un point de repos. Surtout lorsque l'existence du produit, ou la prochaine version, est à l'étude.

Architecture Agile et d'Entreprise: Guide Backlog dans Sprint

Les praticiens d'EA qui soutiennent le portefeuille et le projet s'engageront souvent avec des équipes agiles en guidant le backlog dans Sprint.

J'ai observé que trop d'évangélistes agiles surprennent que les organisations profondément engagées dans les avantages du développement logiciel agile restent profondément engagées dans la planification et la budgétisation à plus long terme. Habituellement, la conversation confond une préférence culturelle mythique pour une cascade.

Pensez plutôt au problème. Une planification et une budgétisation à plus long terme existent en raison de la complexité de l'écosystème. Chaque organisation a de multiples voies à suivre et des contraintes différentes. Les organisations qui réussissent effectuent la hiérarchisation et les compromis. Sans atteindre le futur préféré dans les contraintes de temps et de ressources, aucun travail ne devrait commencer.

Produit de travail d'architecture agile et d'entreprise

L'architecture d'entreprise se résume à des contraintes. Chaque contrainte limite la créativité d'une équipe de développement logiciel agile. Sans un besoin impérieux de contrainte, ne le faites pas. Ne fais pas ça.

Feuille de route pour guider le produit

La feuille de route pour guider le produit fait partie des livrables les plus difficiles pour une équipe EA talentueuse. La tension fondamentale de savoir où vous allez sans savoir comment vous y rendre est un point chaud.

Trop d'équipes d'architecture tombent dans le piège de la précision artificielle ou de l'omniscience imaginaire. Les deux sont des façons fantaisistes de dire la pensée en cascade.

Le développement agile offre des résultats étonnants lorsque l'équipe dispose de tous les degrés de liberté. Pensez simplement au sweet spot d'un nouveau produit autonome.

Souvent, une bonne architecture se résume à fournir les contraintes minimales pour garantir que les décisions n'échouent pas à un test qui n'est pas apparent pour le décideur. Si le décideur peut voir le test, vous n'avez pas besoin d'architecture pour le contraindre. L'architecture existe pour guider ou contraindre le choix lorsque le facteur est en dehors du champ de vision des architectes.

Une feuille de route EA classique abordera les transitions, les lacunes et les lots de travaux. Ce sera incompréhensible pour une équipe produit. Transformez la feuille de route aux bons termes avec le Product Owner. Le propriétaire du produit doit comprendre les contraintes dans lesquelles il opère.

Attendez-vous à la tension

Feuille de route pour guider l'épopée

La feuille de route pour guider l'épopée est le livrable le plus difficile pour une équipe EA talentueuse. Je pense toujours à être coincé dans un champ de mines lors d'un bombardement. Il n'y a aucun endroit sûr où aller.

Les attentes de la chronologie aggravent le piège commun de la pensée en cascade. Aller de l'avant dans le voyage de découverte d'une équipe agile avec une précision artificielle et une omniscience imaginée sape tout dans le développement agile. Ne le fais pas!

Sans produits étroitement intégrés ou étroitement limités, les feuilles de route pour l'épopée sont vouées à l'échec. Les exemples, lorsque cela est nécessaire, incluent plusieurs produits coexistant au sein d'un écosystème et partageant des données de référence. Consommer réciproquement l'épuisement des données nécessitera souvent des épopées associées ou une réglementation punitive complexe.

Sans pression externe, n'effectuez pas cette activité. La sur-spécification et la sur-conception par des praticiens omniscients auto-désignés sont une chose dont nous avons inventé l'agilité pour nous passer. Si vous vous trouvez obligé de faire des roadmaps vers des épopées, assurez-vous de bien comprendre pourquoi il est nécessaire de limiter la créativité de vos développeurs de logiciels. Chaque contrainte qui restreint leur liberté et leur créativité ferait mieux de supplanter la valeur ajoutée qui découle d'une créativité débridée.

Attendez-vous à un échec.

Lorsque nous y sommes parvenus, nous avons activement adopté le langage des méthodes comme le SaFE et encadré la feuille de route en termes de thèmes stratégiques et de pistes d'architecture.

Valeur d'entreprise

Une architecture supérieure répondra toujours aux préoccupations communes des parties prenantes. Il devrait fournir un ensemble de principes cohérents en interne qui imposent une contrainte sur la définition de la valeur. Ici, l'architecture garantit que la négligence dans l'évaluation de la valeur ne crée pas de coûts en aval.

L'évaluation de la valeur bâclée est le problème le plus courant pour une bonne architecture. Règle des considérations transitoires. Une dichotomie classique est la distinction entre le délai de commercialisation tactique et la sécurité, la résilience ou la stabilité. Lorsque votre organisation a des impératifs, les chefs de produit et les équipes Scrum doivent être informés. Sinon, ils ne peuvent pas évaluer correctement l'arriéré par rapport aux paramètres qui comptent vraiment.

Contraindre les propriétaires de produits `` ascendants ''

Trop de propriétaires de produits n'ont pas de visibilité sur la raison pour laquelle leur produit existe ou Trop de propriétaires de produits n'ont pas de visibilité sur pourquoi leur produit existe ou quel est le rôle de l'écosystème. Restreindre la liberté d'un propriétaire de produit ascendant en interdisant le choix ou en imposant la notation et l'évaluation.

Architecture agile et d'entreprise: contraindre les sprints

Les praticiens de l'EA développant une architecture pour prendre en charge la livraison de projets et de solutions doivent s'attendre à limiter les sprints. Les praticiens orientés portefeuille qui développent un écosystème ou une plate-forme doivent également s'attendre à travailler avec les équipes agiles ici.

Contraindre les sprints peut être émotionnellement difficile pour les nouveaux architectes qui étaient auparavant actifs dans le développement. Il est difficile de quitter votre ancien emploi. L'expertise en la matière conduit souvent à une sur-spécification et une conception excessives. Chaque contrainte qui restreint leur liberté et leur créativité doit démontrer qu'elle l'emporte sur la valeur ajoutée qui vient d'une créativité débridée.

La difficulté de quitter votre ancien emploi est la raison pour laquelle nous traitons tous ceux qui découvrent l'architecture d'entreprise comme un newb. Le nouveau diplômé et la personne avec 30 ans d'expérience dans autre chose que l'architecture d'entreprise sont de nouveaux architectes.

Je regarde de nouveaux architectes avec des années de autre expérience de plus près. Ils ont de nombreuses mauvaises habitudes qui les empêchent d'être des architectes de haut niveau.

Produit de travail d'architecture agile et d'entreprise

Nathan et Sam parlent de développer de nouveaux architectes d'entreprise. Il est très important que tout architectes d'entreprise comprendre les droits de décision et servir les parties prenantes.

Critères d'acceptation

Un lien très simple dans un sprint est des critères d'acceptation définis en externe. Si l'architecture nécessite quelque chose, définissez-la comme un critère d'acceptation. À moins que le niveau de détail ne soit très proche d'interférer dans la créativité agile, la contrainte sera quelque chose de cohérent. Il y aura une demande de l'architecture d'entreprise, de l'architecture d'application d'architecture de données ou de l'architecture d'infrastructure. La spécification d'architecture sera un principal, un modèle ou une norme. Fournissez la contrainte comme critère d'acceptation. Alignez-vous sur un Sprint ou sur une version. Ensuite, éloignez-vous et observez la créativité

Guide du gouverneur

Ont-ils raisonnablement interprété les orientations et les contraintes de l'architecture cible?

  • Dans l'affirmative, leur interprétation doit être acceptée comme une conformité. C'est un point clé. Une bonne architecture peut avoir plusieurs choix d'implémentation. L'exécutant n'est pas tenu de se conformer à l'opinion. Si le choix d'implémentation est une interprétation raisonnable, il est conforme.

Valeur (mesures et points de repos)

Un point récurrent de conflit est la compréhension de la valeur.

Le développement logiciel agile des meilleures pratiques est axé sur la valeur. Malheureusement, la plupart des praticiens ont une compréhension limitée de la valeur. Le raccourci rapide est que la valeur est exprimée en termes de quelque chose a été livré. La valeur est évidente dans la livraison.

Dans un monde complexe, la chose livrée pourrait facilement dégrader la valeur. Un exemple simple sont les fonctionnalités destinées à éloigner les clients cibles ou le déplacement du travail entre les unités de travail. Ceci est courant lorsqu'un groupe est desservi par le produit. Nous vous recommandons vivement d'apprendre les pratiques de base Lean et Six-Sigma sur l'optimisation locale et la valeur. De plus, les concepts du Business Model Canvas de Client cible et de Proposition de valeur sont utiles.

Pour relever ces défis, nous nous attendons à ce que l'architecture d'entreprise soit définitive sur la façon dont la valeur est évaluée. L'architecture doit fournir des critères d'évaluation de la valeur aux équipes de développement.

Greenfield, évolution ou révolution

Dans la phase E de TOGAF, il y a une étape intéressante. Examinez le lot de travail et sélectionnez une stratégie appropriée.

L'œuvre sera-t-elle Greenfield, évolutionnaire ou révolutionnaire? Voulons-nous préserver le plus possible, refactoriser radicalement ou repartir de zéro? Ce sont des conseils essentiels et une forte contrainte pour une équipe agile. Partent-ils de zéro (Greenfield)? Améliorer progressivement les systèmes existants (évolution)? Ou effectuer un changement radical en s'attendant à éliminer les frictions et les tracas avec lesquels nous avons vécu (révolutionnaire)?

Le choix de l'approche n'est peut-être pas le leur. Lorsqu'ils n'ont pas le choix, cela sera toujours motivé par des choix supérieurs à leur salaire.

Contraindre les interfaces

Lorsqu'un produit doit s'intégrer dans un environnement d'entreprise existant ou prendre en charge un environnement d'entreprise en évolution, les interfaces sont essentielles. Les interfaces seront pilotées par les données et la méthode. Même lorsque le produit émerge, dans un monde complexe, il n'y aura pas de liberté pour permettre à la structure de données ou à l'interface d'émerger également. Les données de base, les données de référence et les systèmes existants limiteront tous le développement agile.

Les systèmes existants ne seront pas modifiés. Même le F-22 Raptor a dû se connecter à des systèmes hérités en utilisant des interfaces développées dans les années 1970. Même un avion aussi coûteux ne pouvait pas faire remodeler les anciens systèmes. Le Raptor s'intègre dans l'interface et la structure de données existantes.

Une contrainte commune négligée par les équipes en évolution rapide est l'impact de la législation multi-juridictionnelle ou d'un plan d'affaires sur le produit. Dans ces cas, l'équipe d'EA a le devoir de creuser et de développer les contraintes minimales nécessaires pour éviter que le produit ne nécessite une refactorisation radicale à un moment incommode. Comme toutes les contraintes de créativité, les bons praticiens de l'EE comprennent l'importance d'en avoir juste assez.

Architecture d'entreprise et agilité: résoudre la dépendance

On peut s'attendre à ce que les praticiens d'EE travaillant dans une entreprise doivent intervenir et résoudre les dépendances et les conflits qui surviennent entre les solutions produits et les systèmes. Regardez simplement la phase G de TOGAF, elle met en évidence le besoin de conseils et de changement d'architecture. Le développement agile et la portée de l'intégration moderne rendent ce service à long terme plus important qu'il ne l'a jamais été.

Produit de travail d'architecture agile et d'entreprise

Débloquez le portefeuille

Même si vous n'êtes pas limité par l'héritage, plusieurs produits évolueront. Les équipes de développement agile des meilleures pratiques créatives vont trouver différentes façons de résoudre les problèmes. Il est insensé de s'attendre à ce que la créativité ne crée pas de conflit. On peut s'attendre à ce qu'une bonne équipe d'EA travaillant dans la phase G, où se déroule tout le développement de logiciels agiles, débloque le conflit dans le portefeuille des entreprises.

Identifier les vrais acteurs

Les vrais intervenants sont souvent difficiles à trouver. De nombreuses décisions tactiques sont déléguées. Lorsque la délégation est formelle, l'équipe agile peut s'attendre à avoir un accès raisonnable. Lorsque la délégation est informelle, on peut s'attendre à ce que les experts locaux et les utilisateurs conduisent un ordre du jour non aligné.

L’équipe d’architecture d’entreprise n’a pas la capacité particulière d’obtenir un engagement. Ils ont la capacité de représenter les préoccupations des parties prenantes grâce à une architecture supérieure.

Traverser le portefeuille

Les propriétaires de produits et les autres membres d'une équipe de développement sont poussés à fournir un seul produit de manière incrémentielle. Un produit minimal viable et une livraison incrémentielle sont au cœur de la proposition de valeur agile.

Toute l'approche agile vient de l'échec observé d'essayer d'imaginer chaque interaction à travers un portefeuille complexe, c'est le chemin de l'échec. Une conception d'entreprise descendante détaillée peut fonctionner pour des systèmes isolés. Dans un écosystème en évolution, la conception descendante échoue toujours. Ce chemin d'échec est la raison pour laquelle l'agilité existe et pourquoi l'agilité est préférée.

Il est presque impossible d'imaginer un avenir complexe, les efforts pour le faire se transforment souvent en farce. Pourtant, nous devons en faire juste assez. Au fur et à mesure que plusieurs produits émergent, de nouveaux conflits et synergies émergeront. Une bonne équipe d'EE, avec une compréhension approfondie des changements dans les priorités de leur entreprise, aidera à résoudre les synergies et les conflits.

Lorsque l'équipe EA découvre des intersections, elle doit utiliser ses connaissances et son engagement pour obtenir la meilleure réponse. Il s'agit souvent d'une approche gérée par les risques. La première étape consiste à évaluer rapidement le conflit pour déterminer si la résolution peut être différée. Tirer parti de la synergie et éviter les conflits coûte cher. Cher et chronophage. Ils interfèrent directement avec les délais de mise sur le marché.

Nous parlons en termes de forces du marché et de destruction créatrice lorsque nous devons traverser le portefeuille.

Impact de la libération

Juste assez d'architecture signifie que chaque contingence, chaque contrainte, chaque conflit, n'a pas été découvert avant la sortie.

Il y a un cas où une équipe d'architecture a une urgence. C'est la crise post-libération. Ces rares cas où les implications s'étendent au-delà du produit. Le produit est à l'état sauvage. Les utilisateurs finaux à l'intérieur et à l'extérieur de notre organisation l'utilisent. Ils sont soit confrontés à un défaut, soit pire, créant un risque et une responsabilité imprévus pour notre organisation.

Conclusion de l'architecture agile et d'entreprise

Le développement agile et l'architecture d'entreprise souffrent tous deux d'une mauvaise application chronique. Trop souvent en même temps.

Six cas d'utilisation couvrent tous les aspects de l'architecture agile et d'entreprise. L'architecture d'entreprise guide et contraint le développement de logiciels agiles.

Lors de la liaison avec le développement logiciel agile, les architectes d'entreprise doivent:

  1. définir l'approche agile
  2. guider le backlog dans le sprint
  3. contraindre les sprints
  4. résolution de la dépendance entre produits

L'architecture d'entreprise se résume aux limites - faites ceci, ne faites pas cela. Chaque limite limite la créativité d'une équipe de développement logiciel agile. Sans un besoin impérieux de contrainte, ne le faites pas. Ne fais pas ça.

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

le Corps de connaissances TOGAF soutient l'élaboration d'une approche de gouvernance efficace.

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