From ed8e114a0770e0a4c769fc2250ba9e539a69d670 Mon Sep 17 00:00:00 2001 From: Shautvast Date: Sun, 7 Jan 2024 15:45:21 +0100 Subject: [PATCH] change --- {team toplogies => team topologies}/.DS_Store | Bin {team toplogies => team topologies}/.gitignore | 0 .../hoofdstuk 1 conway.md | 10 ++++++---- 3 files changed, 6 insertions(+), 4 deletions(-) rename {team toplogies => team topologies}/.DS_Store (100%) rename {team toplogies => team topologies}/.gitignore (100%) rename {team toplogies => team topologies}/hoofdstuk 1 conway.md (59%) diff --git a/team toplogies/.DS_Store b/team topologies/.DS_Store similarity index 100% rename from team toplogies/.DS_Store rename to team topologies/.DS_Store diff --git a/team toplogies/.gitignore b/team topologies/.gitignore similarity index 100% rename from team toplogies/.gitignore rename to team topologies/.gitignore diff --git a/team toplogies/hoofdstuk 1 conway.md b/team topologies/hoofdstuk 1 conway.md similarity index 59% rename from team toplogies/hoofdstuk 1 conway.md rename to team topologies/hoofdstuk 1 conway.md index 2807634..256179d 100644 --- a/team toplogies/hoofdstuk 1 conway.md +++ b/team topologies/hoofdstuk 1 conway.md @@ -8,13 +8,15 @@ modified: 2024-01-07T15:35:24+01:00 Hoofdstuk 1, conway's law. >> org charts geven de werkelijke organiisatie structuur niet goed weer Idee: je zou de werkelijke org struct kunnen reproduceren door de meta data van communicatie tools te analyseren (slack, teams, email) + -> heeft nog niemand dat gedaan?? -heeft nog niemand dat gedaan? - -monolith +monolith/wehkamp Bij wehkamp riepen sommige mensen dat de grote monolitische applicatie opgebroken moest worden in microservices. Maar waarom? De applicatie werd onderhouden door 1 team. Is dat niet de belangrijkste aanwijzing? -En stel dat je de applicatie openbreekt en zeg in 2 delen splitst. (in casu klant en order). Wat schiet je daarmee op als je niet bijbehorende teams creeert? Maar het geheel werd onderhouden door een man (soms ook vrouw) of 5. Een samenstelling met Teams van 2/3 maakt je niet erg flexibel. +Misschien moet ik erbij vermelden dat de cognitive load hoog was. Sommige delen van de complexe code werden maar door 1 persoon begrepen. Aan de andere kant was het wel 'duurzaam' waarmee ik bedoel dat het werk niet teveel was voor het team. +En stel dat je de applicatie openbreekt en zeg in 2 delen splitst. (in casu klant en order). Wat schiet je daarmee op als je niet bijbehorende teams creeert? Maar het geheel werd onderhouden door een man (soms ook vrouw) of 5. Een samenstelling met teams van 2/3 maakt je niet erg flexibel. Waar je uiteindelijk belandt is in een situatie dat je nominaal misschien 2 teams hebt, die in de praktijk maar 1 team zijn, omdat er zoveel interteam communicatie is. + +