Comprendre l'architecture d'entreprise et Agile

Architecture d'entreprise et Agile - Guide Backlog dans Sprint

Des équipes agiles et solides trouvent la voie à suivre la plus efficace. La planification et la budgétisation à plus long terme existent en raison de la complexité des écosystèmes. Le défi consiste à concilier planification à long terme et créativité agile. Faites le lien entre la planification descendante et l’exécution ascendante.

Ils doivent être informés des priorités organisationnelles dans des termes qui peuvent être intégrés dans la gestion du retard.

Agile existe parce que les personnes les plus proches de la solution peuvent trouver la voie la plus efficace. Les organisations qui réussissent effectuent des priorités et des compromis. Sans atteindre l’avenir souhaité dans les contraintes de temps et de ressources, aucun travail ne devrait commencer.

Une équipe EA doit avoir la capacité de prendre en charge Portefeuille et projet de guider le retard dans le sprint.

Problème prévisible: S'assurer que les résultats attendus, la valeur, les attentes et les contraintes de performances en cascade guident la sortie et le développement du produit.

Un peu dur: Trop d'évangélistes agiles sont surpris de constater que les organisations qui adoptent l'agilité restent profondément engagées dans la planification et la budgétisation à long terme. Nous devons souvent surmonter la mythologie selon laquelle il existe une préférence culturelle pour la cascade.

Feuille de route pour guider le modèle de produit

Problème prévisible: Avoir une feuille de route complète du produit, au lieu d'un cycle de publication de fonctionnalités.

Approche: Utilisation d'un technique de feuille de route d'architecture où le produit, ou la famille de produits, remplace le portefeuille. Veiller à ce que les rapports normaux sur les produits incluent les activités vers les états de transition.

Morceaux durs: Une excellente gestion des produits fournira une feuille de route produit complète. Trop de propriétaires de produits ascendants n’ont pas d’expérience dans la gestion du cycle de vie ou de l’intégration au sein d’une suite de produits intégrée. L'équipe EA devra compléter ou remplacer, en fonction des compétences de l'organisation produit.

Trop d’équipes d’architecture tombent dans le piège de la précision artificielle ou de l’omniscience imaginée. Les deux sont des façons sophistiquées de dire la pensée en cascade. Une feuille de route d'architecture classique parlera de transitions, de lacunes et de lots de travaux. Cela sera incompréhensible pour une équipe produit. Changez le langage en terminologie produit et agile. Le propriétaire du produit doit comprendre les contraintes dans lesquelles il évolue.

Construire la feuille de route nécessite suffisamment d’architecture. La seule approche évolutive est 'juste assez.' Juste assez signifie faire respecter les priorités organisationnelles et éviter les problèmes prévisibles. Juste assez signifie rester en dehors de la conception du produit. Utilisez des modèles d’architecture qui s’appliquent à l’ensemble du portefeuille. Juste assez signifie ignorer les synergies potentielles. Juste assez signifie se concentrer sur des problèmes prévisibles. Il est très utile d’éviter les problèmes prévisibles. Juste assez, c’est ne pas avoir peur de recourir à la destruction créatrice. Utilisez un concept de cycle de vie attendu pour conduire une refactorisation agressive (approches nouvelles et révolutionnaires).

L'utilisation des techniques avec le propriétaire du produit permet d'intégrer les priorités et les contraintes organisationnelles dans la feuille de route du produit.

• • Quel produit ou quelles fonctionnalités clés rechercher compte tenu de différents critères – Feuille de route d'architecture Type 4 : Scénarios
  • Quels produits ou fonctionnalités apporteront de la valeur (avantages, travail et incertitude – Feuille de route d'architecture de type 1 : carte de chaleur
  • Quand les changements de produit et de plate-forme sont-ils nécessaires ? Feuille de route d'architecture de type 2 : cycle de vie
  • Quelle est la dépendance et l'impact du travail et du changement - Feuille de route d'architecture de type 3 : impact et dépendance

Feuille de route pour guider le modèle épique

Problème prévisible: Utiliser des épopées pour implémenter des résultats et des contraintes descendantes dans le produit.

Approche: Utiliser des états de transition bien construits dans un technique de feuille de route d'architecture où le produit, ou la famille de produits, remplace le portefeuille. Veiller à ce que les rapports normaux sur les produits incluent les activités vers les états de transition.

Morceaux durs: Nécessite des produits étroitement intégrés ou étroitement contraints. Le domaine d’intérêt doit porter sur l’intégration ou les points de contrainte. Plusieurs produits coexistant au sein d’un écosystème et partageant des données de référence en sont un exemple simple.

Il est courant de tomber dans le piège de la conception initiale. L'accent doit être mis sur les domaines dans lesquels vos développeurs de logiciels doivent limiter leur créativité en raison de l'écosystème ou d'exigences externes. Idéalement, cela devrait être fait dès le départ plutôt qu’en réaction à une dette technique.

Lorsque nous avons réussi, nous avons activement adopté le langage de méthodes comme SaFE et cadré la feuille de route en termes de thèmes stratégiques et de pistes d'architecture.

Modèle de valeur d'entreprise

Problème prévisible: Veiller à ce que les facteurs critiques de succès inclus dans les états de transition et les états cibles guident la préparation agile du backlog et la planification épique.

Approche: Traduisez les mesures et les objectifs descendants en critères consommables pour une gestion agile du backlog. Veiller à ce que les rapports normaux sur les produits incluent la sélection des activités et leur réalisation par rapport à la valeur indiquée.

Morceaux durs: Les mesures descendantes doivent être définitives et faciles à évaluer. Par exemple, on ne peut pas demander à l’équipe agile de développer un équilibre nuancé entre délai de mise sur le marché et résilience. Une terminologie sans ambiguïté est requise.

Toute modification des mesures descendantes serait source de confusion. Cela est particulièrement vrai si un état de transition a été atteint.

Pour les produits internes, nous nous assurons toujours de disposer d'un modèle de coûts solide pour les produits numériques avant d'introduire des mesures de coûts. Sans modèle de coûts, les coûts opérationnels et de plateforme seront perdus et tous les coûts seront justifiés par le coût de mise en œuvre. Prévoyez d'aider le chef de produit interne avec comprendre l'ITFM. En revanche, les chefs de produit des produits numériques externes ont généralement une très bonne compréhension du coût.

Contraindre le modèle de Product Owner « ascendant »

Problème prévisible: Les propriétaires de produits voient l'ensemble de l'entreprise à travers le prisme de leur produit et de ses utilisateurs directs.

Approche: Documenter le produit et le rôle au sein de l'écosystème. Documenter les contraintes qui s'appliquent au produit. Documenter les critères d’évaluation. Veiller à ce que les rapports normaux sur les produits incluent les progrès vers les états de transition et les activités alignées sur la valeur de l'entreprise.

Morceaux durs: Les Product Owners des produits numériques internes sont souvent un maillon faible. Les défis courants incluent le fait de ne pas comprendre :

• • pourquoi leur produit existe
  • rôle du produit dans l'écosystème
  • criticité des contraintes de l'entreprise
  • qui sont les décideurs (bailleurs de fonds)
  • comment obtenir des conseils sur les priorités de l'entreprise et les mesures de valeur

Les équipes EA prenant en charge le portefeuille et le projet auront probablement besoin de contraindre les propriétaires de produits « ascendants ». Cela nécessite un effort délibéré et une affectation de personnel.