Heuristique pour des services indépendants

De Wiki Agile
Aller à : navigation, rechercher

Auteurs : Matthew Skelton, Manuel Pais, Chris Combe, George-Leonard Chetreanu, Matt Wynne, Ersin Er, Eduardo da Silva, "penmanglewood", Phil Broering
Source : Independent Service Heuristics
Date : 18/04/2023

Traducteur : Fabrice Aimetti
Date : 17/05/2023

Traduction :

L'heuristique pour des services indépendants (ISH - Independent Service Heuristics) est une règle empirique qui permet d'identifier les flux de valeur candidats et les frontières des domaines en déterminant s'ils peuvent être gérés comme un produit SaaS/cloud distinct.

Basé sur certaines idées du livre Team Topologies de Matthew Skelton @matthewskelton et Manuel Pais @manupaisable.

Voir teamtopologies.com pour plus de détails sur Team Topolologies.

Copyright © 2018-2021 Team Topologies - Licence CC BY-SA 4.0

Présentation générale

Lorsque l'on conçoit des organisations pour un flux de changement rapide, il faut trouver des frontières efficaces entre les différents flux de changement. Les techniques telles que le Domain Driven Design (DDD) sont très puissantes à cet égard, mais elles peuvent s'avérer assez complexes et difficiles à apprendre. Une approche intermédiaire plus simple consiste à se demander s'il est possible de faire fonctionner cette chose comme un service ou un produit hébergé dans les nuages (SaaS).

L'approche ISH concerne de nombreuses situations typiques rencontrées dans le secteur des logiciels modernes, mais pas toutes. Elle est conçue pour stimuler les conversations et fournir un cadre de réflexion, et non comme un outil "fourre-tout" idéal.

Mode d'emploi

Choisissez un sujet d'intérêt pour l'organisation à représenter dans un logiciel : un parcours utilisateur, un "produit", un domaine métier potentiel, un service logiciel, une application logicielle entière, un ensemble de tâches pour une persona d'utilisateur unique, un flux de valeur potentiel, etc. Utilisez la check-list ci-dessous pour poser des questions sur le domaine / le service / l'application / la chaîne de valeur candidat(e). Plus il y a de réponses "oui" ou "probablement", plus il y a de chances que vous ayez trouvé un bon candidat pour constituer un flux de changement distinct. Cela signifie que nous pourrions mettre en place une ou plusieurs équipes "Stream-aligned" sur ce sujet. Check-list

  1. Vérification du sens : Est-il logique d'offrir cette chose "en tant que service" ?
    • Cette chose est-elle suffisamment indépendante ?
    • Les consommateurs la comprendront-ils ou lui accorderont-ils de la valeur ?
    • Est-ce que cela simplifiera le travail ?
  2. Marque : Pourriez-vous imaginer cette chose sous la forme d'un service accessible sur le cloud public (comme AvocadoOnline.com 🥑) ?
    • Est-ce que ce sera une activité (ou une "micro-activité") ou un service viable ?
    • S'agira-il d'une offre convaincante ?
    • La campagne marketing sera-t-elle convaincante ?
  3. Revenus/Clients : Cette chose pourra-t-elle être gérée comme un service cloud viable en termes de revenus et de clients ?
    • Est-ce que ce sera un service viable avec une offre payante ?
    • Est-ce qu'elle pourra générer des revenus récurrents grâce à des formules d'abonnement ?
    • Existe-t-il une base ou un segment de clientèle clairement défini ?
  4. Suivi des coûts : L'organisation peut-elle actuellement suivre les coûts et les investissements de cette chose, séparément d'autres choses similaires ?
    • Les coûts totaux de fonctionnement sont-ils transparents ou peuvent-ils être identifiés en tenant compte des coûts d'infrastructure, des coûts de stockage des données, des coûts de transfert des données, des coûts de licence, etc. ?
    • Cette chose est-elle relativement séparée, déconnectée d'autres choses dans l'organisation ?
    • L'organisation assure-t-elle un suivi séparé pour cette chose ?
  5. Données : Est-il possible de définir clairement les données d'entrée (provenant d'autres sources) dont cette chose a besoin ?
    • Cette chose est-elle relativement indépendante de toute source de données ?
    • Les sources sont-elles internes (sous notre contrôle, pas externes) ?
    • Les données d'entrée sont-elles propres (pas fouillis) ?
    • Les données d'entrée sont-elles fournies en libre-service ? L'équipe peut-elle consommer les données d'entrée "en tant que service" ?
  6. Personas Utilisateur : Cette chose pourra-t-elle avoir un ensemble restreint/bien défini de types d'utilisateurs ou de clients (personas utilisateur) ?
    • Cette chose répond-elle à des besoins d'utilisateurs spécifiques ?
    • Connaissons-nous (ou pouvons-nous facilement formuler) ces types d'utilisateurs et leurs besoins ?
  7. Équipes : Une équipe ou un ensemble d'équipes pourra-t-elle/il construire et exploiter efficacement un service basé sur cette chose ?
    • La charge cognitive (étendue des sujets/changement de contexte) pourra-t-elle être limitée afin d'aider l'équipe à se concentrer et à réussir ?
    • Une infrastructure de taille importante ou d'autres abstractions de plate-forme seraient-elles superflues ?
  8. Dépendances : Cette équipe sera-t-elle capable de travailler indépendamment des autres équipes la plupart du temps pour atteindre ses objectifs ?
    • Cette chose est-elle logiquement indépendante d'autres choses ?
    • L'équipe pourra-t-elle " auto-administrer " les dépendances d'une manière non bloquante à partir d'une plateforme ?
  9. Impact/Valeur : La portée de cette chose permettra-t-elle à une équipe de relever un défi significatif et motivant ?
    • La portée est-elle suffisamment large pour avoir un impact ? La portée sera-t-elle suffisamment motivante pour les personnes talentueuses ?
    • La valeur pour les clients et l'organisation est-elle suffisante pour être clairement perçue ?
  10. Décisions relatives au produit : L'équipe travaillant sur cette chose sera-t-elle en mesure de "s'approprier" sa propre feuille de route et la stratégie du produit ?
    • Cette chose fournit-elle une valeur ajoutée concrète au sein d'une période d'exécution bien définie ?
    • L'équipe peut-elle définir sa propre feuille de route en fonction de ce qu'elle estime être le mieux pour le produit et ses utilisateurs (de sorte que l'équipe ne soit pas guidée par les exigences et les priorités d'autres équipes) ?

Autres considérations

  • Vocabulaire : le vocabulaire est-il cohérent entre les différentes parties du système ou les différents domaines métiers ? Si ce n'est pas le cas (si le même mot a une signification différente dans des domaines différents), il peut être nécessaire d'avoir deux services ou systèmes différents.
  • Phases : une partie du système traite-t-elle une phase antérieure ou postérieure du traitement ? Cela peut également représenter une bonne frontière.
  • Cartes de Wardley : la capacité ou le service pourrait-il être externalisé vers un produit SaaS ou un fournisseur de produits de base ? Sera-t-il bientôt externalisable ? Si c'est le cas, c'est un candidat à la séparation en tant que service distinct en vue d'une éventuelle externalisation auprès d'un fournisseur de produits ou de services de base.
  • Risque : quel est le coût du risque lié à la scission de cette capacité ou de ce service ? Un problème pourrait-il survenir ?

Considérations détaillées

  • Couplage lâche : Cette chose a-t-elle un sens pour être migrée / déployée de manière indépendante dans le cloud public, indépendamment des choses apparentées ?
  • Couplage fort : Avez-vous des dépendances sur des logiciels de fournisseurs ou de tierces parties qui empêchent la mise à l'échelle en cas de hausse de la demande ?
  • Opportunité commerciale : Existe-t-il une demande pour cette "chose" en dehors du contexte de son utilisation actuelle ? Pourrait-elle être utilisée plus largement au sein de votre organisation ou pour différents segments de clientèle ?
  • Gouvernance des données : Cette chose fait-elle office de source principale ou fait-elle autorité pour les données clés statiques / de référence / du client ?
  • Contrats d'interface : Disposez-vous de contrats d'interface versionnés et de la capacité de déployer de nouvelles versions sans impact sur les "clients" (consommateurs) existants ?
  • Résilience / scalabilité : Au fur et à mesure que la demande pour votre "chose" augmente, avez-vous une augmentation linéaire de la demande pour de nouvelles capacités / disponibilités (y compris dans les régions géographiques) ?
  • Liquidité des compétences : Prenez en compte l'éventail des compétences au sein des équipes. Les équipes peuvent-elles chacune posséder leur service/système après la scission ?
  • Anti-modèle - couplage de données : Votre "chose" dépend-elle d'un couplage fort / de pilotes de fournisseurs spécifiques ou utilise-t-elle des choses comme des liens de base de données plutôt que par le biais d'une API gérée et versionnée ?
  • Anti-modèle - coordination des versions : Les producteurs et les consommateurs en amont et en aval ont-ils besoin que votre "chose" coordonne des versions (par exemple, un train de versions) ou peuvent-ils publier des versions indépendamment aussi souvent qu'ils le souhaitent ?

Ressources

Remerciements

Merci aux personnes du groupe de rencontre DDD Londres pour leurs commentaires sur une première version de l'heuristique des services indépendants. 😻

Merci également à :

Récupérée de « https://wikiagile.fr/index.php?title=Heuristique_pour_des_services_indépendants&oldid=17665 »