« Heuristique pour des services indépendants » : différence entre les versions
De Wiki Agile
Page créée avec « Category:DDD Auteurs : Matthew Skelton, Manuel Pais, Chris Combe, George-Leonard Chetreanu, Matt Wynne, Ersin Er, Eduardo da Silva, "penmanglewood", Phil Broering<br/>... » |
Aucun résumé des modifications |
||
| Ligne 11 : | Ligne 11 : | ||
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.<br/> | 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.<br/> | ||
<br/> | <br/> | ||
Basé sur certaines idées du livre Team Topologies de Matthew Skelton @matthewskelton et Manuel Pais @manupaisable.<br/> | Basé sur certaines idées du livre Team Topologies de Matthew Skelton [https://github.com/matthewskelton @matthewskelton] et Manuel Pais [https://github.com/manupaisable @manupaisable].<br/> | ||
<br/> | <br/> | ||
Voir teamtopologies.com pour plus de détails sur Team Topolologies.<br/> | Voir [https://teamtopologies.com/ teamtopologies.com] pour plus de détails sur Team Topolologies.<br/> | ||
<br/> | <br/> | ||
Copyright © 2018-2021 Team Topologies - Licence CC BY-SA 4.0<br/> | Copyright © 2018-2021 Team Topologies - Licence [https://creativecommons.org/licenses/by-sa/4.0/ CC BY-SA 4.0]<br/> | ||
== Présentation générale== | == 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).<br/> | 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).<br/> | ||
| Ligne 24 : | Ligne 24 : | ||
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. | 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 | Check-list | ||
# | # '''Vérification du sens''' : Est-il logique d'offrir cette chose "en tant que service" ? | ||
#* Cette chose est-elle suffisamment indépendante ? | #* Cette chose est-elle suffisamment indépendante ? | ||
#* Les consommateurs la comprendraient-ils ou lui accorderaient-ils de la valeur ? | #* Les consommateurs la comprendraient-ils ou lui accorderaient-ils de la valeur ? | ||
#* Est-ce que cela simplifiera le travail ? | #* Est-ce que cela simplifiera le travail ? | ||
# | # '''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 ? | #* Est-ce que ce sera une activité (ou une "micro-activité") ou un service viable ? | ||
#* S'agira-il d'une offre convaincante ? | #* S'agira-il d'une offre convaincante ? | ||
#* La campagne marketing sera-t-elle convaincante ? | #* La campagne marketing sera-t-elle convaincante ? | ||
# | # '''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 que ce sera un service viable avec une offre payante ? | ||
#* Est-ce qu'il pourra générer des revenus récurrents grâce à des formules d'abonnement ? | #* Est-ce qu'il 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 ? | #* Existe-t-il une base ou un segment de clientèle clairement défini ? | ||
# | # '''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. | #* 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 ? | #* Cette chose est-elle relativement séparée, déconnectée d'autres choses dans l'organisation ? | ||
| Ligne 45 : | Ligne 45 : | ||
#* Les données d'entrée sont-elles propres (pas fouillis) ? | #* 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" ? | #* 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" ? | ||
# | # '''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 ? | #* 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 ? | #* Connaissons-nous (ou pouvons-nous facilement formuler) ces types d'utilisateurs et leurs besoins ? | ||
| Ligne 61 : | Ligne 61 : | ||
#* 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) ? | #* 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== | == 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== | ==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 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 ? | ||
| Ligne 74 : | Ligne 74 : | ||
* '''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 ? | * '''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 - 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" | * '''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== | ==Ressources== | ||
* Regarder la présentation de Matthew Skelton et Nick Tune concernant ISH lors de DDD Europe 2022 | * Regarder la présentation de [https://github.com/matthewskelton Matthew Skelton] et [https://github.com/ntcoding Nick Tune] concernant [https://www.youtube.com/watch?v=q8hwkDyL6Zs ISH lors de DDD Europe 2022] | ||
* En savoir plus sur les | * En savoir plus sur les [https://teamtopologies.com/key-concepts Topologies d'équipe] | ||
* Explorer les | * Explorer les [https://www.dddheuristics.com/ Heuristiques de Domain-Driven Design] - une partie de l'excellente communauté [https://virtualddd.com/ virtualDDD.com] | ||
* Apprenez à utiliser l'Event Storming pour découvrir différents domaines métiers - cela peut être une bonne "passerelle" vers le Domain-driven Design (DDD) - merci à Rebecca Wirfs-Brock pour cette idée. | * Apprenez à utiliser l'[https://techbeacon.com/devops/introduction-event-storming-easy-way-achieve-domain-driven-design Event Storming] pour découvrir différents domaines métiers - cela peut être une bonne "passerelle" vers le Domain-driven Design (DDD) - ''merci à [https://twitter.com/rebeccawb Rebecca Wirfs-Brock] pour cette idée''. | ||
* Découvrir les Cartes de Wardley | * Découvrir les [https://hiredthought.com/2018/09/01/intro-to-wardley-mapping/ Cartes de Wardley] | ||
* Lire des articles sur la Liquidité des Compétences par Chris Matts | * Lire des articles sur la [https://theitriskmanager.com/2013/11/24/introducing-staff-liquidity-1-of-n/ Liquidité des Compétences par Chris Matts] | ||
==Remerciements== | ==Remerciements== | ||
Merci aux personnes du groupe de rencontre DDD | Merci aux personnes du [https://www.meetup.com/dddlondon/events/265895638 groupe de rencontre DDD Londres] pour leurs commentaires sur une première version de l'heuristique des services indépendants. 😻<br/> | ||
<br/> | <br/> | ||
Merci également à : | Merci également à : | ||
* Nick Tune et le DDD Crew pour les supers ressources DDD | * [https://github.com/ntcoding Nick Tune] et le [https://github.com/ddd-crew DDD Crew] pour les supers ressources DDD | ||
* Kacper Gunia pour l'invitation à prendre la parole lors de la rencontre DDD de Londres | * [https://github.com/cakper Kacper Gunia] pour l'invitation à prendre la parole lors de la rencontre DDD de Londres | ||
* tous les contributeurs à ce dépôt. | * [https://github.com/TeamTopologies/Independent-Service-Heuristics/graphs/contributors tous les contributeurs à ce dépôt]. | ||
