sander/notes
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

change

Browse source
This commit is contained in:
Shautvast 2024-01-07 15:45:21 +01:00
parent c7a00e3e47
commit ed8e114a07
3 changed files with 6 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

0
team toplogies/.DS_Store → team topologies/.DS_Store vendored
View file

0
team toplogies/.gitignore → team topologies/.gitignore vendored
View file

10
team toplogies/hoofdstuk 1 conway.md → team topologies/hoofdstuk 1 conway.md
View file

@ -8,13 +8,15 @@ modified: 2024-01-07T15:35:24+01:00
Hoofdstuk 1, conway's law. Hoofdstuk 1, conway's law.
>> org charts geven de werkelijke organiisatie structuur niet goed weer >> 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) 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??
heeft nog niemand dat gedaan?
monolith/wehkamp
monolith
Bij wehkamp riepen sommige mensen dat de grote monolitische applicatie opgebroken moest worden in microservices. Bij wehkamp riepen sommige mensen dat de grote monolitische applicatie opgebroken moest worden in microservices.
Maar waarom? Maar waarom?
De applicatie werd onderhouden door 1 team. Is dat niet de belangrijkste aanwijzing? 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.