Super content du sujet de la semaine prochaine
Qui a déjà lu le livre ?
Team Topologies: Organizing Business and Technology Teams for Fast Flow de Matthew Skelton
Je l’ai lu.
Je l’utilise actuellement sur un accompagnement organisationnel. Pour moi, il doit être utilisé pour :
- cartographier les interactions d’équipes et voir vers lesquelles l’organisation veut aller
- se poser les questions sur les domaines (bounded context) et si l’organisation est en adéquation avec ce découpage business (loi de Conway)
Il a des choses sur lesquelles je suis pas si fan = empêcher les devs de voir d’autres « bounded context », c’est réducteur de vouloir emprisonner les équipes par besoin de limiter la charge cognitive.
Pour le reste, je l’ai trouvé intéressant et utile !
1 « J'aime »
J’ai enquêté dessus mais j’ai eu la flemme de cracher 30€ pour l’acheter…
J’en ai discuté avec Timothée Bourguignon suite à son article sur le sujet.
C’est clairement un sujet que j’aimerais intégrer dans ma réflexion pour le scaleup de ma société
1 « J'aime »
Team Topologies (github.com)
ATTENTION Si vous envisagez d’acheter l’ouvrage, pensez à utiliser le lien parrainé :
1 « J'aime »
Ce point là me crispe. A quel moment un domaine est délimité ? Ca n’a aucun sens =/ A la limite, je comprends une délimitation de contexte si le dit contexte est un use-case, mais justement, ledit use-case mélange très régulièrement plusieurs domaines. C’est assez pauvre comme idée…
Après le Bounded Context c’est surtout central aux approches de masses via le DDD. Faut plus voir ça comme des intersections de systèmes, et de comment ces-dits systèmes se messagent entre eux. Et tu délimites par rapport à une réalité (par exemple, un métier, là ça fait sens je trouve).
C’est vraiment due au fait que plus tu essaies de modéliser des domaines qui grossissent de plus en plus, plus c’est difficile d’avoir un seul modèle unifié, un seul langage commun.
Donc je ne suis pas d’accord avec toi sur le fait que c’est « pauvre » comme idée, c’est juste un degré d’abstraction supplémentaire et parfois nécessaire dès que c’est trop complexe.
Je précise que je suis pas un expert en DDD, j’ai quelques connaissances sans plus, mais d’un point de vue « modélisation de système » c’est un pattern très classique en pensée système juste appliqué à une architecture. Un peu comme en facilitation : si tu as trop de monde, tu fais des sous-groupes (« bounded contexts » 
) que tu fais ensuite communiquer entre eux après via un représentant. Ca simplifie la communication. Après je peux dire des bêtises aussi, je suis prêt à apprendre !
Je t’invite à regarder cette conférence là. C’est touffu et je l’ai bien regardé 4-5 fois avant d’en comprendre toute la consistance, mais c’est absolument édifiant :
1 « J'aime »
Dès que j’ai du temps demain, je regarde ! En plus je l’adore, il a toujours des avis très différents et tranchés. Ca va m’inspirer ! Merci !!
1 « J'aime »
C’est un de mes intervenants préféré, juste parce qu’il a bossé avec tellement de gens important comme sutherland, kay, trygve, alexander, nonaka… Mais ce talk la particulièrement est edifiant
1 « J'aime »
Après avoir eu vent de ce livre, notamment via les vidéos de Scrum Life, je suis en train de le lire. J’espère y trouver des pistes de réflexion pour m’aider à mettre en place une nouvelle équipe. C’est sans doute la nécessaire extension aux organisations au sens global, inter-équipe, aux approches agiles comme Scrum ou Kanban qui sont plus focalisées sur les interactions intra-équipe.
J’espère pouvoir en dire davantage une fois le livre terminé.
Je suis tombé par hasard sur une vidéo en français qui résume très bien les concepts du livre : https://www.youtube.com/watch?v=_yTNqp3wMuU