De Devschuur Coffee Corner - Iteratie ⑬

[CodeCaster]

Woy schreef op vrijdag 7 april 2023 @ 16:12:
[...]

Oneens, squash merge is bij mij echt favoriet, maar je moet wel weten wanneer het wel en niet de voorkeur heeft. Voor kortlopende branches zou ik altijd squash merge doen, want wat heb je nog voor voordeel bij de historie van die branch. Je moet vooral zorgen dat je ook vaak genoeg merged, dan zijn de squash commits juist fijne eenheden die je ook makkelijk weer terug kunt draaien, of nog naar een release branch kunt cherry picken. Als je gebruik maakt van release branches en je wilt een hotfix terugmergen naar master dan moet je natuurlijk weer geen squash merge doen.

Squash merge kent z'n nut, absoluut. Het hebben van een lineaire geschiedenis an sich moet alleen geen streven zijn.

Een feature/bugfix van een enkele commit: prima.

Waar ik het squashen op heb zien stuklopen, en dat zijn ook zeker procedurele issues:
• Bij het niet verwijderen van een branch: onduidelijk of een feature-branch nou wel of niet is gemerged.
• Bij refactor-branch die eerst wordt gesquashmerged en daarop voortborduren met een feature-branch: conflicten bij het mergen van die tweede.
• Geen duidelijke versiegeschiedenis (blame geeft voor een hele functie/klasse: "Merge feature X").

Lethalis schreef op vrijdag 7 april 2023 @ 16:19:
[...]

Hoe gaan jullie dan om met de hoeveelheid commits die iedereen produceert?

Als ik aan een feature werk, kan dat zomaar tot 20 commits leiden voordat ik het idee heb dat de feature gereleased mag worden. Soms probeer ik het nog een beetje te beperken door commits gedurende de dag te amenden.

Ik commit en push ook weleens aan het einde van de dag simpelweg zodat er een back-up van wordt gemaakt (gezien van de server een back-up wordt gemaakt, maar van de machine waarop ik werk niet per se... sowieso kan dat ook mijn privé laptop zijn die ik voor van alles en nogwat gebruik).

Het is dus eigenlijk een nietszeggende commit. Het hoeft niet eens te builden (in mijn eigen feature branch).

Overigens heb ik daarnet nog een merge gedaan zonder commit (met Git Extensions door daar "squash commits" aan te vinken) en die vervolgens als 1 commit naar de main gecommit en gepusht. Dat ging prima, maar jij bent het hiermee dus niet eens?

Ik wil de commit history van de main branch toch graag netter houden dan van de feature branches (die zoals @Woy aangeeft vaak kortlopend zullen zijn).

Dan gebruik je een interactive rebase om je commits te sorteren/squashen/fixuppen/editen/droppen/hernoemen.

[RobertMe]

Woy schreef op vrijdag 7 april 2023 @ 16:12:
[...]

Oneens, squash merge is bij mij echt favoriet, maar je moet wel weten wanneer het wel en niet de voorkeur heeft. Voor kortlopende branches zou ik altijd squash merge doen, want wat heb je nog voor voordeel bij de historie van die branch. Je moet vooral zorgen dat je ook vaak genoeg merged, dan zijn de squash commits juist fijne eenheden die je ook makkelijk weer terug kunt draaien, of nog naar een release branch kunt cherry picken. Als je gebruik maakt van release branches en je wilt een hotfix terugmergen naar master dan moet je natuurlijk weer geen squash merge doen.

Why not both? De branch rebasen en waar nodig zaken squashen en daarna mergen. In zoverre wat @gekkie aangeeft. Vooral bij features doe je vaak meerdere semi losstaande commits om op het eindpunt uit te komen. Dan kun je vast wat scratch commits doen (zoals @Lethalis beschrijft als aan het eind van de dag committen) en voordat je bv een PR aanmaakt even de boel opruimen en in logische commits indelen waar nodig. En vervolgens dus wel gewoon mergen zonder squash.
Of je moet al alles zo perfect scrummen dat één ticket ook één commit oplevert. En als je aan een feature werkt dat je niet alleen die feature in kleine individueel mergebare tickets splitst, maar dus ook als je denkt "hier moet ik eerst refactorren" daar weer een ticket voor aanmaken. Zodat een ticket en daarmee een branch niet meer dan een paar (gemiddeld uberhaupt niet meer dan 1?) dagen werk bevat.

Edit: @CodeCaster was me voor

[whoami]

CodeCaster schreef op vrijdag 7 april 2023 @ 15:59:
[...]

Meteen vergeten. Zorgt voor meer ellende dan je er gemak van hebt. Een rechtlijnige geschiedenis is leuk om naar te kijken, maar verder niet bepaald praktisch.

Hoezo ? Ik ben een grote fan van squash merge.

Je wil imho niet dat je iedere commit op je feature branch terug ziet in je history op main.

Anders ziet jouw commit history er zeker zo uit:

- modify X to Y
- implement feat
- what ?
- wtf
- test
- ...

Beter toch als je een mooie commit history hebt waarbij je afdwingt dat iedere PR een duidelijke titel heeft die aan bepaalde conventies voldoet en een description waarin uitgelegd wordt waarover de PR gaat.

Een feature/bugfix van een enkele commit: prima.

Waar ik het squashen op heb zien stuklopen, en dat zijn ook zeker procedurele issues:
• Bij het niet verwijderen van een branch: onduidelijk of een feature-branch nou wel of niet is gemerged.
• Bij refactor-branch die eerst wordt gesquashmerged en daarop voortborduren met een feature-branch: conflicten bij het mergen van die tweede.
• Geen duidelijke versiegeschiedenis (blame geeft voor een hele functie/klasse: "Merge feature X").

Simpel, na het mergen van een PR moet je die branch weggooien.

[ Voor 27% gewijzigd door whoami op 07-04-2023 17:31 ]

[Kalentum]

Lethalis schreef op vrijdag 7 april 2023 @ 16:19:
[...]

Hoe gaan jullie dan om met de hoeveelheid commits die iedereen produceert?

Als ik aan een feature werk, kan dat zomaar tot 20 commits leiden voordat ik het idee heb dat de feature gereleased mag worden. Soms probeer ik het nog een beetje te beperken door commits gedurende de dag te amenden.

Ik commit en push ook weleens aan het einde van de dag simpelweg zodat er een back-up van wordt gemaakt (gezien van de server een back-up wordt gemaakt, maar van de machine waarop ik werk niet per se... sowieso kan dat ook mijn privé laptop zijn die ik voor van alles en nogwat gebruik).

Het is dus eigenlijk een nietszeggende commit. Het hoeft niet eens te builden (in mijn eigen feature branch).

Overigens heb ik daarnet nog een merge gedaan zonder commit (met Git Extensions door daar "squash commits" aan te vinken) en die vervolgens als 1 commit naar de main gecommit en gepusht. Dat ging prima, maar jij bent het hiermee dus niet eens?

Ik wil de commit history van de main branch toch graag netter houden dan van de feature branches (die zoals @Woy aangeeft vaak kortlopend zullen zijn).

Ik probeer atomische commits te maken, die dus 1 afgerond geheel zijn. Dat kan van alles zijn maar als ik een refactor doe dan is dat 1 commit en dan de eigenlijke feature is dan de andere commit.

Nietszeggende commits ("Fix typo", "Forgot this class") squash ik dan op de commit waar ze bij horen. (met git rebase -i).

Dus mijn feature branches hebben vaak maar enkele commits op het moment dat het gereviewed kan worden.

Mergen naar master doe ik niet zelf maar dat gaat automatisch als eenmaal 'de build groen is' (geen falende tests)

[whoami]

Lethalis schreef op vrijdag 7 april 2023 @ 16:33:
[...]

Aan de andere kant kunnen we ook commits in de main branch taggen (oftewel commit X betekent versie x.y.z van de software).

Dat is eigenlijk al voldoende. En indien nodig kan je een branch afsplitsen vanaf die tag.

[DevWouter]

Kalentum schreef op vrijdag 7 april 2023 @ 17:30:
Nietszeggende commits ("Fix typo", "Forgot this class") squash ik dan op de commit waar ze bij horen. (met git rebase -i).

Daarvoor gebruik ik veel liever `git commit --amend --no-edit`. En die "nietszeggende commits" vertellen mij vaak ook heel veel. Een typo of een class vergeten toe te voegen heeft vaak ook een reden.

Maar goed er zijn te veel mensen die git gebruiken alsof het subversion is.

Ik probeer atomische commits te maken, die dus 1 afgerond geheel zijn. Dat kan van alles zijn maar als ik een refactor doe dan is dat 1 commit en dan de eigenlijke feature is dan de andere commit.

Dat werkt, maar sowieso, als een branch te lang open staat gaan er bij mij alarmbellen af. Het is namelijk potentiële waarde die niet geleverd wordt.

In het team waar ik nu zit verwacht ik dat ieder 3 PR's op een dag kan maken zonder dat we het vervelend vinden. Het zijn dan namelijk zeer kleine PR's die getest worden. Kost je als collega hoogstens 3 minuten.

[Lethalis]

DevWouter schreef op vrijdag 7 april 2023 @ 21:49:
[...]
En die "nietszeggende commits" vertellen mij vaak ook heel veel. Een typo of een class vergeten toe te voegen heeft vaak ook een reden.

Ach ik heb laatst aan een project gewerkt waarbij ik al een naar gevoel van deja vu bij had. Het duurde ongeveer 3 uur voordat ik eindelijk doorhad dat ik de gevraagde functionaliteit 5 weken geleden al gemaakt had (op een andere plek in het project )

In my defense werk ik aan veel verschillende projecten, maar ik word toch ook een beetje oud en vergeetachtig (ben 42 inmiddels).

Als ik soms van die kritisch klinkende posts lees van anderen krijg ik toch wel een beetje imposter syndroom Geen idee of ik bij een andere werkgever op mijn bek zou gaan of niet. Qua kennis en vaardigheden zou het moeten lukken, maar ik ben soms wel slordig met dingen en vergeetachtig. En moe. Ik wil het liefst een half uurtje slapen in de middag ofzo

Ik ben t/m aanstaande woensdag vrij... dus ik ga proberen ff te relaxen. Ben misschien ook een beetje overwerkt.

Met jouw 3 PR's per dag. Tsss. Ik heb dagen dat ik blij ben als ik überhaupt iets gedaan krijg Zijn meestal wel de dagen dat ik op kantoor zit die hopeloos zijn en ik regelmatig mensen te woord moet staan. Thuis werk ik wel aardig door.

Na de pandemie ben ik nooit meer echt gewend aan werken op kantoor. Concentratie is dan compleet weg ofzo. Ik heb het nog niet aangedurfd om een noise cancelling koptelefoon op te zetten (voelt asociaal).

Daarnaast werkt het beperkt, omdat het vooral constante en lage frequenties onderdrukt.

[CurlyMo]

@Lethalis Wat ik een hele fijne functie vind binnen git die relatief nieuw is git add --patch. Die geeft je de mogelijkheid om heel specifiek wijzigingen te selecteren die je in een commit wil stoppen. Zo kan je rustig twee features door elkaar heen ontwikkelen. Of tijdens het ontwikkelen een andere bugfix oplossen zonder dat je loopt te klooien met wat je nu precies commit.

[whoami]

DevWouter schreef op vrijdag 7 april 2023 @ 21:49:
[...]


Daarvoor gebruik ik veel liever `git commit --amend --no-edit`. En die "nietszeggende commits" vertellen mij vaak ook heel veel. Een typo of een class vergeten toe te voegen heeft vaak ook een reden.

Maar in die gevallen heb je commits die niet 'op zichzelf' staan, ze maken deel uit van een groter geheel. nl. bugfix x of feature y.

Dat werkt, maar sowieso, als een branch te lang open staat gaan er bij mij alarmbellen af. Het is namelijk potentiële waarde die niet geleverd wordt.

In het team waar ik nu zit verwacht ik dat ieder 3 PR's op een dag kan maken zonder dat we het vervelend vinden. Het zijn dan namelijk zeer kleine PR's die getest worden. Kost je als collega hoogstens 3 minuten.

Ik ben zelf ook geen fan van grote PR's, maar dat staat eigenlijk los van je commit strategie.
Het begint met een goede refinement, zodanig dat je eigenlijk per task op je backlog één PR kunt hebben. Echter, in mijn ervaring komt daar heel wat bij kijken om dat voor elkaar te krijgen, en dat lukt ook niet altijd.
Als die refinement / backlog niet ok is, dan komt het neer op de skills en ervaring van de ontwikkelaar om ervoor te zorgen dat de PR's een atomair geheel zijn, en dat je waakt over de scope van de PR.

Aan de andere kant heb je dan soms ook PR's waarin je een stukje code refactored die dan impact heeft op x aantal files waardoor je PR natuurlijk veel groter wordt.

De ideale wereld is niet altijd bereikbaar

[CurlyMo]

whoami schreef op vrijdag 7 april 2023 @ 22:54:
[...]
Aan de andere kant heb je dan soms ook PR's waarin je een stukje code refactored die dan impact heeft op x aantal files waardoor je PR natuurlijk veel groter wordt.

Hoe vaak ik wel niet commentaar krijg dat al mijn PR's standaard op main gebaseerd zijn. Mensen die alvast de CI/CD build van van PR1 draaien en daar ook al direct de features van PR2 in zouden willen zien. Terwijl beide nog niet gemerged zijn. Ik sync PR2 pas in PR1 zodra PR2 onderdeel wordt van main. Anders wordt het inderdaad een zooitje.

[whoami]

CurlyMo schreef op vrijdag 7 april 2023 @ 22:56:
[...]

Hoe vaak ik wel niet commentaar krijg dat al mijn PR's standaard op main gebaseerd zijn.

Dat doe ik ook, anders breng je jezelf alleen maar in de problemen.

[RobertMe]

CurlyMo schreef op vrijdag 7 april 2023 @ 22:52:
@Lethalis Wat ik een hele fijne functie vind binnen git die relatief nieuw is git add --patch. Die geeft je de mogelijkheid om heel specifiek wijzigingen te selecteren die je in een commit wil stoppen. Zo kan je rustig twee features door elkaar heen ontwikkelen. Of tijdens het ontwikkelen een andere bugfix oplossen zonder dat je loopt te klooien met wat je nu precies commit.

git add -p gebruik ik echt al jaren, misschien wel 10 jaar. Denk dus niet dat dat een relatief recente toevoeging is Tenzij ze recentelijk pas de full name --patch hebben toegevoegd

Wat overigens het aller leukste aan add -p is is dat je met e een patch kunt editten. Dus als de diff niet bevalt kun je weer een andere diff er van maken en iets totaal anders commiten dan momenteel in de file staat

[ Voor 14% gewijzigd door RobertMe op 07-04-2023 23:02 ]

[CurlyMo]

RobertMe schreef op vrijdag 7 april 2023 @ 23:01:
[...]

git add -p gebruik ik echt al jaren, misschien wel 10 jaar. Denk dus niet dat dat een relatief recente toevoeging is Tenzij ze recentelijk pas de full name --patch hebben toegevoegd

Of het geeft aan hoe lang ik git al gebruik dat ik 10 jaar relatief nieuw vind

[DevWouter]

whoami schreef op vrijdag 7 april 2023 @ 22:54:

Ik ben zelf ook geen fan van grote PR's, maar dat staat eigenlijk los van je commit strategie.
Het begint met een goede refinement, zodanig dat je eigenlijk per task op je backlog één PR kunt hebben. Echter, in mijn ervaring komt daar heel wat bij kijken om dat voor elkaar te krijgen, en dat lukt ook niet altijd.

Maar dat is ook de grote truc die ik hanteer. Als ik een breakdown doe (refinement is meer voor criteria in mijn ogen) dan zijn mijn taken ook 1 of 2 uur maximaal. Soms schat ik op minuten.

En dat heeft inderdaad het gevolg dat ik de titel van de taak kopieer en ze in mijn commit zet.

Hmm… ik ga eens experimenteren met mijn taken te schrijven als of ze een commit zijn. Volgens mij moet dat super werken.

[RagingPenguin]

Lethalis schreef op vrijdag 7 april 2023 @ 22:36:
[...]

Als ik soms van die kritisch klinkende posts lees van anderen krijg ik toch wel een beetje imposter syndroom Geen idee of ik bij een andere werkgever op mijn bek zou gaan of niet. Qua kennis en vaardigheden zou het moeten lukken, maar ik ben soms wel slordig met dingen en vergeetachtig. En moe. Ik wil het liefst een half uurtje slapen in de middag ofzo

Maar nu hebben we hier ook best wel een bonte verzamling aan snapshots van hoogswaarschijnlijk totaal verschillende bedrijven met diverse producten, bedrijfsvoering, doelen, etc. Versiebeheer is een tool, niet een doel opzich. Wat voor jou de juiste manier is zou je eigenlijk moeten terug redeneren van het probleem dat je aan het oplossen bent, niet op basis van wat allemaal kan en welke ideologieën er op het internet allemaal rond hangen.

In het algemeen zou mijn advies zijn om gewoon simpel te beginnen en probeer om alleen regels te hebben die geautomatiseerd zijn (dus als je bv wilt dat er een squash gebeurd voor een merge laat dat dan doen door je gitlab/github/whatever). Vanuit dat laatste is het wel aan te raden om voor developers enkel merges via MR/PR toe te staan.

[Kalentum]

DevWouter schreef op vrijdag 7 april 2023 @ 21:49:
[...]


Daarvoor gebruik ik veel liever `git commit --amend --no-edit`. En die "nietszeggende commits" vertellen mij vaak ook heel veel. Een typo of een class vergeten toe te voegen heeft vaak ook een reden.

Maar goed er zijn te veel mensen die git gebruiken alsof het subversion is.


[...]

Dat werkt, maar sowieso, als een branch te lang open staat gaan er bij mij alarmbellen af. Het is namelijk potentiële waarde die niet geleverd wordt.

In het team waar ik nu zit verwacht ik dat ieder 3 PR's op een dag kan maken zonder dat we het vervelend vinden. Het zijn dan namelijk zeer kleine PR's die getest worden. Kost je als collega hoogstens 3 minuten.

3 PR's per dag is bij ons volstrekt niet te doen. Ik schat dat ik ongeveer 50% van mijn tijd op een dag aan 'code' kan besteden, maximaal, vaak minder. De rest van de tijd gaat op aan code reviews, meetings, mensen helpen en andere zaken die niet direct leiden tot PR's. Ik kan rustig 2-4 uur stuk slaan op een code review bv... En ik probeer echt goede tests voor mijn code te maken wat ook niet triviaal is in de meeste gevallen.

Wat voor scope hebben die PR's dan? Kun je een voorbeeld geven?

[Lethalis]

RagingPenguin schreef op zaterdag 8 april 2023 @ 13:52:
[...]
Maar nu hebben we hier ook best wel een bonte verzamling aan snapshots van hoogswaarschijnlijk totaal verschillende bedrijven met diverse producten, bedrijfsvoering, doelen, etc. Versiebeheer is een tool, niet een doel opzich. Wat voor jou de juiste manier is zou je eigenlijk moeten terug redeneren van het probleem dat je aan het oplossen bent, niet op basis van wat allemaal kan en welke ideologieën er op het internet allemaal rond hangen.

Klopt. De probleemstelling is eenvoudig: we moeten grote aanpassingen doen aan onze software, maar ook verder kunnen werken aan de stabiele versie. Dus we hebben hoe dan ook branches nodig. En je wil de boel kunnen mergen.

Waar ik vooral op reageerde zijn die 3 PR's per dag De meeste dingen waar ik aan werk, duren al gauw 2 tot 3 dagen. Een snelle fix is zeldzaam en komt meestal terug met een vengeance.

Ons ERP pakket heeft namelijk honderden opties. Dus vaak als ik een aanpassing doe - hoe klein dan ook - moet ik rekening houden met alle scenarios. Iets kan 20 regels code zijn, maar het uitzoeken en bedenken van de oplossing, de impact analyseren, het testen op een testserver etc... en ik ben een paar dagen verder.

Soms slaan we stappen over als er hoge nood is en passen we even snel iets aan, om daar later erg veel spijt van te krijgen. Zeker omdat we een Windows pakket hebben dat we 's avonds deployen bij de klant (overdag mag het niet uit) en elke fout betekent dat je daarna weer een avond kwijt bent.

We hebben een updatesysteem, maar de belangen zijn zo groot dat we na de update alsnog inloggen en met de hand dingen controleren en testen. Elke 10 minuten dat ons systeem er uitligt, kost de klant duizenden euro's.

Dan ben ik liever wat langer bezig met iets... maar dat het goed gebeurt. We willen het liefst ook helemaal geen ad hoc werk meer doen.

[thof]

Lethalis schreef op zaterdag 8 april 2023 @ 22:31:
Klopt. De probleemstelling is eenvoudig: we moeten grote aanpassingen doen aan onze software, maar ook verder kunnen werken aan de stabiele versie. Dus we hebben hoe dan ook branches nodig. En je wil de boel kunnen mergen.

(...)

Komt het vaak voor dat je nog op een gereleasde versie nog wat moet aanpassen? Bij ons is dat redelijk uitzonderlijk, dus we zorgen er voor dat elke master commit getagged is met een versie nummer. Dan kunnen we altijd nog een branch vanaf die tag trekken als we toch een hotfix moeten doen. Over het algemeen is het gewoon rollforward. Features die niet af zijn zitten achter een feature flag / instelling om dat aan/uit te zetten.

[ElkeBxl]

Lethalis schreef op vrijdag 7 april 2023 @ 16:19:
[...]
Ik commit en push ook weleens aan het einde van de dag simpelweg zodat er een back-up van wordt gemaakt (gezien van de server een back-up wordt gemaakt, maar van de machine waarop ik werk niet per se... sowieso kan dat ook mijn privé laptop zijn die ik voor van alles en nogwat gebruik).

Same here. En tot nu toe is het in elk team dat ik al heb gewerkt zo geweest: op je feature/bugfix branches doe je wat je wil. Wil je elk uur een commit doen gewoon als work in progress? Doe maar. Maar voor de pull request wordt aangemaakt, moet je alles squashen en rebasen. We komen dus altijd uit op 1 commit per feature/bug wat haast altijd 1 commit per Jira ticket is.

In het geval er heel veel werk zou zijn aan een feature/bug door allerlei redenen (gaande van grote refactor maar ook gewoon de grootte van de feature/bug) wordt er altijd eerst gekeken of we het niet meer kunnen opsplitsen. Elk Jira ticketje moet zo duidelijk en eenvoudig mogelijk zijn zonder dat het natuurlijk te klein wordt en je meer overhead in admin maakt. Zodra we bij de planningspoker op 13 of meer story points uitkomen, doen we direct de denkoefening hoe het kan opgesplitst worden indien mogelijk. Daardoor ook zelden situatie gehad dat we meerdere commits in de PR overwogen per branch.

Maar alles staat of valt bij goede communicatie en ook gewoon evalueren met je team of de manier van werken wel goed is voor wat je doet. Zo heb ik ook al vele manieren gezien hoe je met verschillende omgevingen omgaat. Huidig team werkt met een dev, test en main branch waarbij we developen tegen de dev branch en bij deploy naar test geen squash doen van dev maar een merge (en bij deploy naar acceptatie ook merge van test naar main). Maar heb ook in teams gezeten waar alles tegen de main werd developed om dan met tags te werken voor versienummers waarbij je dan wist dat tag "v3.2.2" productie was, "v3.2.3" acceptatie, "v3.2.4" test, ...

Enige issues die we ooit hadden was als mensen teveel rechten hadden of branches niet protected waren en men begon te force pushen op plekken waar ze beter niet op pushten.

[DevWouter]

Kalentum schreef op zaterdag 8 april 2023 @ 14:57:
[...]


3 PR's per dag is bij ons volstrekt niet te doen. Ik schat dat ik ongeveer 50% van mijn tijd op een dag aan 'code' kan besteden, maximaal, vaak minder. De rest van de tijd gaat op aan code reviews, meetings, mensen helpen en andere zaken die niet direct leiden tot PR's. Ik kan rustig 2-4 uur stuk slaan op een code review bv... En ik probeer echt goede tests voor mijn code te maken wat ook niet triviaal is in de meeste gevallen.

Wat voor scope hebben die PR's dan? Kun je een voorbeeld geven?

- "Add UserService.Create(...)"
- "Add UserForm incl. FormData class (no logic except OnSubmit and validation)"
- "Create User/New page with new UserForm that performs saves"

Ik ben meestal maar iets van 5 minuten kwijt, max 10 minuten per PR. Soms heb ik een PR al beoordeeld voordat iemand het in de teamchat heeft kunnen zetten. Als mensen deze drie PR's als één grote PR maken en dan ben ik vaak meer dan 3x10 minuten kwijt omdat ik meer ruimte voor de context in mijn hoofd moet maken. En vaak ben ik daarna mijn eigen context kwijt.

Tevens wil ik dat meerdere mensen naar een PR kijken (het liefst het hele team). Dan hoeft niet iedereen secuur te zijn en vaak is dat effectiever dan dat er 1 expert naar kijkt.

De meeste tijd ben ik kwijt met uitzoeken waar ik iemand een compliment voor kan geven. Een PeerReview op een PullRequest is net zoals een review voor een product, die gebruik je voor teleurstelling maar ook om je tevredenheid te uiten. Dat motiveert mensen en helpt ze om vaker dingen te doen waar ik als lead blij van word. Dat is een win-win situatie.

[DevWouter]

ElkeBxl schreef op zondag 9 april 2023 @ 09:12:
Maar alles staat of valt bij goede communicatie en ook gewoon evalueren met je team of de manier van werken wel goed is voor wat je doet.

Ik ga jouw quote misbruik door het in een andere context te zetten, maar ik ben er van overtuigd dat software ontwikkelen eerder een sociaal beroep is dan een technisch beroep. Als ik in een team zit waar men niet communiceert dan ben ik meestal de eerste paar maanden bezig om ze daar in op te voeden.

Immers als teamlid A niet weet wat/waarom teamlid B iets gedaan heeft kunnen ze nog zo fantastisch zijn maar vaak gaat het gewoon verkeerd en zorgen ze extra werk voor elkaar.

Software developers zijn net compilers, ze vertalen instructies ("als xxx wil ik yyy zodat zzz") naar een high level code wat uiteindelijk naar byte code wordt vertaald dat een CPU kunnen uitvoeren.

[Mugwump]

In mijn ogen is het vooral lastig als je een forse diversiteit aan kennis en competentie in je team hebt. Ga je alles dusdanig uitwerken dat zelfs de meest junior persoon in je team het werk op kan pakken? Dat kan, maar dat gaat wel heel fors ten koste van de productiviteit van de meer senior mensen in je team. Ga je voor een aanpak waar je heel summier beschrijft wat er moet gebeuren en de devs veel vrijheid geeft? Dat kan ook, maar dat betekent vaak veel werk qua reviewen, veel rework of de meer junior mensen heel intensief begeleiden / pair programmen e.d.

Je kunt ook de wat meer senior mensen een goede basis qua structuur / architectuur laten neerzetten waarbinnen dan de wat meer junior developers eigenlijk min of meer invuloefeningetjes overhouden, maar nadeel daarvan is weer dat je een soort van treintje aan werkzaamheden krijgt en bovendien dat het voor de wat meer junior mensen niet direct heel leerzaam is om alleen maar 'vul de ontbrekende code op de puntjes in'-werkzaamheden te doen. Ik ben altijd wel voorstander van een team waarin geen stricte hiërarchie heerst, maar aan de andere kant heb ik ook regelmatig met overmoedige juniors gewerkt die totaal niet overzien wat de gevolgen zijn van wat ze doen en als je niet uitkijkt een immutable data store in productie weten te corrupten ofzo met alle gevolgen van dien als er niet iemand met iets meer ervaring naar kijkt.

Kan er zelf nooit echt een goede generieke werkwijze in vinden. Het is toch vaak maar proefondervindelijk kjiken wat er nou wel of niet werkt binnen een team.

[BarôZZa]

DevWouter schreef op zondag 9 april 2023 @ 10:15:
[...]


Ik ga jouw quote misbruik door het in een andere context te zetten, maar ik ben er van overtuigd dat software ontwikkelen eerder een sociaal beroep is dan een technisch beroep. Als ik in een team zit waar men niet communiceert dan ben ik meestal de eerste paar maanden bezig om ze daar in op te voeden.

Eerlijk gezegd vind ik dat zowel neerbuigend naar echt sociale beroepen als naar het vak van software ontwikkelaar, want dat is wel degelijk enorm technisch. Ik ben ook enorm goede programmeurs tegengekomen die totaal niet sociaal vaardig waren, maar geen enkele die niet technisch was. Uiteraard is het wel handig als ze social skills hebben en om een team op te bouwen waarbij optimaal wordt samengewerkt waar dat nodig is.

Als je echt een sociaal beroep wil uitoefenen, dan investeer je waarschijnlijk niet een groot deel van je leven in het leren hoe je kan praten met computers, maar besteed je die tijd aan mensen.

[BarôZZa]

Mugwump schreef op zondag 9 april 2023 @ 11:04:
In mijn ogen is het vooral lastig als je een forse diversiteit aan kennis en competentie in je team hebt. Ga je alles dusdanig uitwerken dat zelfs de meest junior persoon in je team het werk op kan pakken? Dat kan, maar dat gaat wel heel fors ten koste van de productiviteit van de meer senior mensen in je team. Ga je voor een aanpak waar je heel summier beschrijft wat er moet gebeuren en de devs veel vrijheid geeft? Dat kan ook, maar dat betekent vaak veel werk qua reviewen, veel rework of de meer junior mensen heel intensief begeleiden / pair programmen e.d.

Ik heb nooit het idee dat het voor een junior ineens haalbaar wordt als alles zo gedetailleerd mogelijk wordt omschreven. Vaak wordt het alleen maar nog onduidelijker, als het al niet verkeerd wordt omschreven omdat je vooraf ook niet alles weet.

Intensief reviewen, rework en begeleiding zijn volgens mij de zaken die bepalen dat iemand junior is. Dus dat zal je altijd houden.

Wat bij mij vaak hielp was om issues van tevoren met het hele team te bespreken tijdens backlog refinements/estimate sessies. Dan kon je het summier houden, maar werden onduidelijkheden en lastige puntjes toch nog besproken. Zeker als duidelijk was dat een junior het zou oppakken.

[RagingPenguin]

DevWouter schreef op zondag 9 april 2023 @ 10:09:
[...]


- "Add UserService.Create(...)"
- "Add UserForm incl. FormData class (no logic except OnSubmit and validation)"
- "Create User/New page with new UserForm that performs saves"

Ik ben meestal maar iets van 5 minuten kwijt, max 10 minuten per PR. Soms heb ik een PR al beoordeeld voordat iemand het in de teamchat heeft kunnen zetten. Als mensen deze drie PR's als één grote PR maken en dan ben ik vaak meer dan 3x10 minuten kwijt omdat ik meer ruimte voor de context in mijn hoofd moet maken. En vaak ben ik daarna mijn eigen context kwijt.

Tevens wil ik dat meerdere mensen naar een PR kijken (het liefst het hele team). Dan hoeft niet iedereen secuur te zijn en vaak is dat effectiever dan dat er 1 expert naar kijkt.

De meeste tijd ben ik kwijt met uitzoeken waar ik iemand een compliment voor kan geven. Een PeerReview op een PullRequest is net zoals een review voor een product, die gebruik je voor teleurstelling maar ook om je tevredenheid te uiten. Dat motiveert mensen en helpt ze om vaker dingen te doen waar ik als lead blij van word. Dat is een win-win situatie.

Maar vind je het gebrek aan context dan niet juist een groot gebrek? Voor het beoordelen van syntax hebben we linters, als ik iets review dan gaat verre weg de meeste tijd zitten in nadenken over het grotere plaatje en alle potentiele gevolgen van de wijzigingen. Met een review tijd van 5 tot 10 minuten heb ik eerlijk gezegt wel mijn twijfels over de kwaliteit van een review, zelfs voor een dependabot MR ben ik flink meer tijd kwijt om het goed te doen.

[DevWouter]

BarôZZa schreef op zondag 9 april 2023 @ 11:48:
[...]

Eerlijk gezegd vind ik dat zowel neerbuigend naar echt sociale beroepen als naar het vak van software ontwikkelaar, want dat is wel degelijk enorm technisch.

Excuus, dat moest niet "sociaal beroep" zijn, maar een "communicatief beroep".

---

RagingPenguin schreef op zondag 9 april 2023 @ 13:15:
[...]


Maar vind je het gebrek aan context dan niet juist een groot gebrek? Voor het beoordelen van syntax hebben we linters, als ik iets review dan gaat verre weg de meeste tijd zitten in nadenken over het grotere plaatje en alle potentiele gevolgen van de wijzigingen. Met een review tijd van 5 tot 10 minuten heb ik eerlijk gezegt wel mijn twijfels over de kwaliteit van een review, zelfs voor een dependabot MR ben ik flink meer tijd kwijt om het goed te doen.

Niet echt, om twee redenen:

1. Als een aanpassing extreem veel impact kan hebben dan zou dat al tijdens het aanmaken van de taak bekend moeten zijn (en dan gaat die 5~10 minuten ook niet meer op).
2. Als bij het beoordelen van een PR er veel context nodig is dan beschouw ik dat als een smell dat er ergens iets anders verkeerd zit.

Eigenlijk is de duur van een PR bij mij een code-smell.

De vergelijking met dependabot PR vind ik niet helemaal eerlijk, dat is namelijk een "onverwachte aanpassing".

---

Mugwump schreef op zondag 9 april 2023 @ 11:04:
In mijn ogen is het vooral lastig als je een forse diversiteit aan kennis en competentie in je team hebt. Ga je alles dusdanig uitwerken dat zelfs de meest junior persoon in je team het werk op kan pakken? Dat kan, maar dat gaat wel heel fors ten koste van de productiviteit van de meer senior mensen in je team.

Mijn eigen taken zijn vaak veel verder uitgewerkt dan anderen

offtopic:
Voor het tweede gedeelte hanteer ik het volgende:
Junior: Iemand aan wie ik niet zomaar een verantwoordelijkheid toevertrouw
Medior: Iemand aan wie ik de techniek kan toevertrouwen
Senior: Iemand aan wie ik de techniek en de aansturing van het team kan toevertrouwen

Het kan in mijn ogen nooit voorkomen dat juniors niks te doen hebben terwijl de "senior" het te druk heeft. Vaak zijn die "senioren" dan een medior in mijn ogen. Een senior volgens mijn definitie schrijft maar 10~20% van zijn tijd code. De rest is voorbereiding voor het team (keuzes maken, coaching, ondersteuning, etc). Een medior verdeelt zijn tijd tussen onderzoek (bugs, nieuwe tech, etc) en code tikken. En een junior is vooral bezig met code schrijven of wordt gecoacht door een medior/senior.

Daarom hoef je ook geen team te hebben met alleen maar senioren. Zelfs als zou je alleen maar senioren aannemen dan schakelt meestal het merendeel terug naar een medior rol.

En als je een team hebt met alleen medioren dan zal er vanzelf iemand een senior rol moeten nemen (en hopen dat die persoon het kan). Een team van junioren daar tegen is puur chaos

[Woy]

RobertMe schreef op vrijdag 7 april 2023 @ 17:00:
[...]
Why not both? De branch rebasen en waar nodig zaken squashen en daarna mergen.

Ik ben zeker geen purist, en er zijn genoeg gevallen waar squash merge niet perse het beste is. Maar een fijne historie met zinnige commits vind ik wel belangrijk. Ik probeer dan ook altijd te zorgen dat de default een squash merge is, dan krijg je ieder geval geen vervuilde historie vol met merge commits met een historie waar je niks aan hebt ( "Commit 1", "Another Commit", "Fix build", etc ). Sowieso is het fijn als je merges klein genoeg zijn dat een enkele commit een logische unit is. Maar ik zie zeker dat het soms fijn kan zijn om soms meerdere commits te hebben. Zelf zou ik dan vaak voor een rebase met fast forward merge kiezen, maar een merge commit is op zich geen probleem, als de branch die gemerged is maar netjes gemaakt is.

Punt is sowieso dat het voor veel mensen blijkbaar erg lastig is om Git te snappen, en eigenlijk totaal niet weten wat ze aan het doen zijn. Ik probeer mensen altijd nog wel een beetje op te voeden, maar de Squash merge als default voorkomt IMHO al een hoop leed

[ Voor 12% gewijzigd door Woy op 11-04-2023 09:35 ]

[ThomasG]

Woy schreef op dinsdag 11 april 2023 @ 09:34:
[...]

Punt is sowieso dat het voor veel mensen blijkbaar erg lastig is om Git te snappen, en eigenlijk totaal niet weten wat ze aan het doen zijn. Ik probeer mensen altijd nog wel een beetje op te voeden, maar de Squash merge als default voorkomt IMHO al een hoop leed

Ik merk dat dát vooral het geval is bij mensen die een (vaak waardeloze) GUI gebruiken voor git. Die klikken gewoon op wat knopjes, want "zo doe ik het altijd en het werkt". Als ze leren via de cli te werken gaat het vaak direct een stuk beter.

[MatHack]

Zelf ook groot gebruiker van de git cli, mijn collega's lachen er altijd om, maar als ze dan weer eens iets verpest hebben (in hun eigen feature-branches) mag ik het oplossen in de cli... en dan zijn ze toch weer blij dat ik de cli kennis heb. Het enige waar ik GUI voor git (third party tool) voor gebruik is een beter overzicht van branches en waar/wanneer ze zijn afgetakt.

[Lethalis]

Ik zal iig proberen mijn collega's zoveel mogelijk te begeleiden met git. Eventueel met een beknopte A4 (cheat sheet) erbij.

Qua GUI clients zal het vooral een mix van Visual Studio 2022 en Git Extensions worden trouwens. Dat mensen de CLI duidelijker vinden begrijp ik op zich, maar hoef ik bij sommige collega's echt niet mee aan te komen

[ Voor 47% gewijzigd door Lethalis op 11-04-2023 14:35 ]

[.oisyn]

ThomasG schreef op dinsdag 11 april 2023 @ 09:40:
[...]
Ik merk dat dát vooral het geval is bij mensen die een (vaak waardeloze) GUI gebruiken voor git. Die klikken gewoon op wat knopjes, want "zo doe ik het altijd en het werkt". Als ze leren via de cli te werken gaat het vaak direct een stuk beter.

Nou, echt totaal niet mee eens . Met een CLI heb je geen idee waar je moet beginnen, en ik vind de standaard help van veel commando's veel te technisch en er wordt totaal niet uitgelegd waarom je daar iets mee zou doen. Bovendien kom je met de CLI al snel in een state waarvan je geen idee hebt wat je daar nou mee moet om het op te lossen, terwijl je daar met een GUI gewoon doorheen geleid wordt.

En wat git imho ook mist is een fundamentele beschrijving van wat het nou precies doet. Ik kom zelf dan af van 20 jaar werken met Perforce, en hoewel de concepten heel abstract gezien best wel overeen komen, zitten ze wel fundamenteel verschillend in elkaar. Maar misschien is dat ook weer niet voor iedereen nodig. Ik hou er zelf wel van om te snappen hoe iets onder water werkt om te kunnen begrijpen wat wel en wat niet mogelijk is.

[ Voor 7% gewijzigd door .oisyn op 11-04-2023 14:03 ]

[Kalentum]

.oisyn schreef op dinsdag 11 april 2023 @ 14:01:
[...]


Nou, echt totaal niet mee eens . Met een CLI heb je geen idee waar je moet beginnen, en ik vind de standaard help van veel commando's veel te technisch en er wordt totaal niet uitgelegd waarom je daar iets mee zou doen. Bovendien kom je met de CLI al snel in een state waarvan je geen idee hebt wat je daar nou mee moet om het op te lossen, terwijl je daar met een GUI gewoon doorheen geleid wordt.

Welke GUI voor git gebruik jij dan?

Ik realiseer me in eens dat ik vaak gebruik maak van de hints die git zelf geeft maar die kun je blijkbaar uitzetten.

En wat git imho ook mist is een fundamentele beschrijving van wat het nou precies doet. Ik kom zelf dan af van 20 jaar werken met Perforce, en hoewel de concepten heel abstract gezien best wel overeen komen, zitten ze wel fundamenteel verschillend in elkaar. Maar misschien is dat ook weer niet voor iedereen nodig. Ik hou er zelf wel van om te snappen hoe iets onder water werkt om te kunnen begrijpen wat wel en wat niet mogelijk is.

Ben je bekend met https://git-scm.com/book/en/v2 ? Daar staat zowel wat over de higher level concepten als ook de git internals.

[ Voor 10% gewijzigd door Kalentum op 11-04-2023 16:25 ]

[.oisyn]

Kalentum schreef op dinsdag 11 april 2023 @ 16:07:
[...]


Welke GUI voor git gebruik jij dan?

Ik gebruik vooral de CLI. Maar dat kostte veel Googlen en collega's buggen. Ik heb Github Desktop ernaast maar die is vrij gelimiteerd. Doe mij maar zoiets als een P4V.

Ben je bekend met https://git-scm.com/book/en/v2 ?

Nu wel

[ Voor 112% gewijzigd door .oisyn op 11-04-2023 17:16 ]

[Kalentum]

.oisyn schreef op dinsdag 11 april 2023 @ 17:11:
[...]

Ik gebruik vooral de CLI. Maar dat kostte veel Googlen en collega's buggen. Ik heb Github Desktop ernaast maar die is vrij gelimiteerd. Doe mij maar zoiets als een P4V.

Misschien kun je dan ook eens kijken naar Gitkraken of Sourcetree. Ik ben zelf een cli gebruiker maar om overzicht te hebben gebruik ik die tweede wel eens. En Gitkraken schijnt de meest professionale git gui te zijn.

[...]

Nu wel

Het is de officiele website, hopelijk heb je er wat aan.

[SPee]

Intellij heeft ook een redelijke git client. Maar ik doe alsnog veel via de cmd-line.
Bijvoorbeeld rebasen op master; via Intellij altijd weer de vraag "welke optie was het nou? Rebase X onto Y? of Y onto X?".
Via de commando veel makkelijker en zonder fouten.


Maar zijn hier mensen die doen aan Trunk Based Development?
Dus terug naar de oude tijd van SVN met een enkele branch waar iedereen op werkt.
Of gebruiken de meeste toch liever feature branches en PR's? Of langdurende feature branches?

[Caelorum]

Feature branches en PR. Meeste feature branches zullen 1 a 2 dagen bestaan. Heb er echter nog ook wel die om redenen twee maanden bestaan. Maar dat heb ik liever niet want die zit ik dan ook elke twee dagen ofzo te rebasen... We gebruiken overigens ook feature flags, dus er is niet echt een functionele reden om lange tijd een brwmch aan te houden.
We hebben ook epic branches die weken bestaan, maar wel heel zelden, want het levert alleen maar gedoe op.

[MatHack]

Wij gebruiken voor git de Gitflow als richtlijn. Het plaatje helpt ook om makkelijk met juniors erover te hebben.

[Caelorum]

Wij gebruiken tags op de main branch. Als er al een release niet goed is, dan kunnen we daarvandaan altijd nog een bugfix branch maken als we die los van alle andere changes willen releasen.
Komt bijna nooit voor, want nieuw werk op de main branch zit achter feature flags en kan dus in principe altijd mee met een release.

IMO scheelt dat ook overhead. Feature branches en een main branch geeft al genoeg ruis.

[RobertMe]

Branches die maar twee maanden open staan, daar kan ik alleen maar van dromen.

Ik ben rond oktober begonnen aan een project om in ons systeem de authenticatie te vervangen en daarnaast OpenID Connect te integreren (als zijnde provider). Alles opgesplitst in lossere tickets (categorie: paar weken max per ticket) en intussen ben ik 4 epics verder en is er door collega's een klein beetje getest en gereviewed. Dus 6 maanden later en buiten mijn code kloppen is er nog vrijwel niks mee gebeurt. Intussen al meermaals aangegeven dat dit echt niet kan en dat er intussen ~20 branches semi op elkaar gestapeld zijn. Maar dat deert ze echt helemaal niet. Als ik aangeef "ticket is afgerond" krijg ik daarna doodleuk te horen "als volgende kun je <ticketnr> doen". Terwijl ik ten eerste hier en daar nog wat dingen moet fixen in de oude tickets (op basis van dat kleine beetje test/review werk), ten tweede dus totaal niet amused ben van tickets/branches blijven stapelen, en ten derde tickets alleen maar over de muur worden gegooid. ("als volgende kun je ... oppakken ". Niks van even een ticket doornemen. Enige dat ik verneem van wat gemaakt moet worden komt uit, meestal de veel te summiere, tickets).

[Caelorum]

@RobertMe authenticatie vervangen door oidc nu al bij drie klanten gedaan. Leuke migratie trajecten altijd. Ook de authority kant implementeren overigens. Ook bij een bedrijf gedaan dat hier nog op de frontpage heeft gestaan (en ander nationaal nieuws) :-)

Maar dat soort situaties plaatsen ze me gelukkig niet in. Dat weiger ik ook gewoon. Ze betalen me niet voor inefficiëntie en niet opleveren van zaken. En heel eerlijk gezegd is dat soort administratieve wanorde en gebrek aan projectmatig werken niet mijn probleem (al zal ik ze wel helpen dat op te lossen).

[ Voor 10% gewijzigd door Caelorum op 11-04-2023 19:06 ]

[WernerL]

Compleet gebrek aan goede processen klinkt helaas erg herkenbaar. Ook het totaal ontbreken van fatsoenlijke requirement analyse komt te vaak voor. Een backlog vol met tickets die alleen een titel hebben maar geen of matige omschrijving en acceptatie criteria. En tijdens de implementatie blijkt dat er maar half over de functionaliteit is nagedacht en moeten er nog veel te veel dingen besproken worden waardoor alles vertraagd.

* WernerL vind dat nogal vermoeiend. Sowieso zonder analyst of UX designer werken is niet echt relaxed. Dat zorgt er alleen maar voor dat developers minder tijd besteden aan waar ze wel goed in zijn. En het zorgt voor meer meetings.

Gelukkig heb ik ook goede projectteams meegemaakt waar er op een efficiënte manier gewerkt wordt. Scrum teams die echt zelfsturend kunnen zijn zonder micro-management van een PM zijn het fijnste. En in mijn huidige project staan PRs niet langer dan 1 of 2 dagen open. 2 maanden vind ik echt absurd.

[ElkeBxl]

MatHack schreef op dinsdag 11 april 2023 @ 12:20:
Zelf ook groot gebruiker van de git cli, mijn collega's lachen er altijd om, maar als ze dan weer eens iets verpest hebben (in hun eigen feature-branches) mag ik het oplossen in de cli... en dan zijn ze toch weer blij dat ik de cli kennis heb. Het enige waar ik GUI voor git (third party tool) voor gebruik is een beter overzicht van branches en waar/wanneer ze zijn afgetakt.

Same, alles cli behalve voor eens overzicht van alle branches te hebben en heel af en toe om in 1 oogopslag te zien wat de diff is.

Caelorum schreef op dinsdag 11 april 2023 @ 18:17:
Feature branches en PR. Meeste feature branches zullen 1 a 2 dagen bestaan. Heb er echter nog ook wel die om redenen twee maanden bestaan. Maar dat heb ik liever niet want die zit ik dan ook elke twee dagen ofzo te rebasen... We gebruiken overigens ook feature flags, dus er is niet echt een functionele reden om lange tijd een brwmch aan te houden.
We hebben ook epic branches die weken bestaan, maar wel heel zelden, want het levert alleen maar gedoe op.

Hier ook zo kort mogelijk proberen die feature branches te laten openstaan. De keren dat het groter werk is, zit ik sowieso elke ochtend te rebasen. Maar dat is ook omdat we met 9 developers zaten en dan kan het nogal snel gaan qua achterstand als je niet af en toe rebased...

Binnekort heb ik een nieuw project, daar gaan we met pak minder developers zijn per team, dat gaat al deel van de overhead die ik nu ervaar weg nemen.

[BarôZZa]

WernerL schreef op dinsdag 11 april 2023 @ 19:39:
Compleet gebrek aan goede processen klinkt helaas erg herkenbaar. Ook het totaal ontbreken van fatsoenlijke requirement analyse komt te vaak voor. Een backlog vol met tickets die alleen een titel hebben maar geen of matige omschrijving en acceptatie criteria.

Heb je het over een sprint backlog of over de product backlog? Want bij de eerste is het inderdaad niet handig. Bij de product backlog is het echter heel normaal dat er ideeën en verbeteringen instaan die later verder uitgewerkt kunnen worden tijdens een backlog refinement.

En tijdens de implementatie blijkt dat er maar half over de functionaliteit is nagedacht en moeten er nog veel te veel dingen besproken worden waardoor alles vertraagd.

Acceptatiecriteria gaan natuurlijk wel vooral over wat er moet gemaakt en niet over hoe. Dus bespreken tijdens de sprint is heel normaal en gezond. Als je een goed bereikbare scrum master en PO hebt, dan hoeft dat ook geen grote drempel te zijn en dingen te vertragen. Niet alles hoeft in een meeting.

Gelukkig heb ik ook goede projectteams meegemaakt waar er op een efficiënte manier gewerkt wordt. Scrum teams die echt zelfsturend kunnen zijn zonder micro-management van een PM zijn het fijnste.

Er is geen PM in een scrumteam . Heb je er wel een, dan doe je geen scrum.

[WernerL]

BarôZZa schreef op woensdag 12 april 2023 @ 10:38:
[...]

Heb je het over een sprint backlog of over de product backlog? Want bij de eerste is het inderdaad niet handig. Bij de product backlog is het echter heel normaal dat er ideeën en verbeteringen instaan die later verder uitgewerkt kunnen worden tijdens een backlog refinement.

Sprint backlog. Als iets in een sprint staat is het wel fijn als het ver genoeg refined is en er een requirement analyse is uitgevoerd. (Duidelijke criteria wat er gebouwd moet worden, niet persee technische analyse) Als dat nog tijdens implementatiefase gedaan moet worden is er iets niet goed gegaan.

Acceptatiecriteria gaan natuurlijk wel vooral over wat er moet gemaakt en niet over hoe. Dus bespreken tijdens de sprint is heel normaal en gezond. Als je een goed bereikbare scrum master en PO hebt, dan hoeft dat ook geen grote drempel te zijn en dingen te vertragen. Niet alles hoeft in een meeting.

Eens. Maar zonder goed uitgewerkte tickets kun je niet goede inschattingen geven en vervolgens ook niet goed plannen. Ik vind refiment, analyse en development losse fases die los uitgevoerd moeten worden. Een goed bereikbare PO is inderdaad erg fijn en helpt heel veel.

En als er iets overlegt wordt zorgen dat afspraken in tickets worden gezet is ook belangrijk. Niet dat veel informatie alleen leeft in de hoofden van de meest senior mensen die wel in alle meetings zitten.

Er is geen PM in een scrumteam . Heb je er wel een, dan doe je geen scrum.

Meestal houden PMs van scrumteams zich alleen met budget en mensen bezig. Regelen dat er iemand aangenomen wordt als dat nodig is bijvoorbeeld. Maar heb ook micro-managers meegemaakt in "scrum"-teams.

[Caelorum]

BarôZZa schreef op woensdag 12 april 2023 @ 10:38:
[...]
Acceptatiecriteria gaan natuurlijk wel vooral over wat er moet gemaakt en niet over hoe. Dus bespreken tijdens de sprint is heel normaal en gezond. Als je een goed bereikbare scrum master en PO hebt, dan hoeft dat ook geen grote drempel te zijn en dingen te vertragen. Niet alles hoeft in een meeting. [...]

Ik vind dat wel wat laat eerlijk gezegd. Het is lastig committeren op werk waarvan niet duidelijk is wat er precies gedaan moet worden. IMO zou werk dus ook niet in een sprint getrokken moeten worden tenzij dit voldoende is uitgewerkt.

Ik vind het overigens een verademing om na jaren scrum weer in een kanban-achtige werkomgeving te zitten. Ik pak gewoon werk op en zorg dat het zo snel mogelijk af komt. Items kunnen variëren van goed uitgewerkt tot enkel een oneliner als titel en van 30min werk tot 4 weken intensief andere teams begeleiden. Heel variabel en geen enkele dag is hetzelfde, ook qua proces. Wel enorm onvoorspelbaar, waar scrum juist uitblinkt in voorspelbaarheid, maar dat is een probleem voor de mensen die de planning doen

[Mugwump]

Caelorum schreef op woensdag 12 april 2023 @ 10:54:
[...]

Ik vind dat wel wat laat eerlijk gezegd. Het is lastig committeren op werk waarvan niet duidelijk is wat er precies gedaan moet worden. IMO zou werk dus ook niet in een sprint getrokken moeten worden tenzij dit voldoende is uitgewerkt.

Ik vind het overigens een verademing om na jaren scrum weer in een kanban-achtige werkomgeving te zitten. Ik pak gewoon werk op en zorg dat het zo snel mogelijk af komt. Items kunnen variëren van goed uitgewerkt tot enkel een oneliner als titel en van 30min werk tot 4 weken intensief andere teams begeleiden. Heel variabel en geen enkele dag is hetzelfde, ook qua proces. Wel enorm onvoorspelbaar, waar scrum juist uitblinkt in voorspelbaarheid, maar dat is een probleem voor de mensen die de planning doen

Als ik dan even mag ranten...
Ik word in de corporate wereld steeds vaker geconfronteerd met SAFe. Mijn god, wat een drama is dat. Het wordt door een clubje met handige marketing verpakt als 'agile at scale', maar het is echt alles behalve Agile. Idiote planningen maken over meerdere kwartalen heen, alles centraal top-down blijven sturen vanuit je management en enterprise architectuur en ga zo maar door.
Zo ongeveer iedereen die heeft bijgedragen aan de Agile Manifesto heeft er ook wel een niet alle subtiele mening over. Een kleine greep:

Ken Schwaber: “A core premise of agile is that the people doing the work are the people who can best figure out how to do it. The job of management is to do anything to help them do so, not suffocate them with SAFe.”

Jeff Sutherland: “While frameworks like SAFe might be a starting place for companies who do not understand Agile, they are inconsistent with the Scrum guide and codify disfunction that can cripple teams for years.”

Ron Jeffries: “I don’t like it. SAFe isn’t really Agile in its heart. […] SAFe will be installed in a fashion that won’t just fail to support Agile, but that will suppress it.”

Arie van Bennekum: “I recently heard that a government organization proudly reported implementing SAFe without making any changes to the organization.”

Alistair Cockburn: “Wow. just heard, ‘our exec hates agile, so he will install SAFe’ eeek!!”.

Ward Cunningham: “my ideas get plugged into bigger frameworks and to me it looks diluted…”

Steve Denning: “SAFe destroys the very essence of Agile. it gives the management a mandate to call themselves agile and keep doing what they have always done. SAFe is the epitome of ‘fake Agile’.”

Martin Fowler: “SAFe — Shitty Agile For Enterprises, as my friend calls it”

Andrew (Andy) Hunt: “SAFe is auto-ironic” and “I have friends who have made great careers thanks to SAFe — going in afterwards and cleaning up disastrous, failed adoptions.”

John Kern: “The biggest challenge is what I call ‘agile in name only’. That is the usage of a process or a framework, but not really understanding that a tool or a process alone, while it may be necessary, may not be sufficient.”

(Uncle) Robert C. Martin: “Agile was never intended for this”.

Stefan Wolpers: “The nine most terrifying words for agile practitioners: ‘I practice SAFe®, and I am here to help.’”

Allen Holub: “SAFe violates basic agile principles: it’s not simple, it’s not flexible, it elevates process over people, it relies on plans, it discourages self organization and autonomy. It would be fine if they called it SFe”

Marty Cagan: “I would not want to work in a company using a process like this. I can’t imagine any of the strong tech product companies I know choosing to move to SAFe, and if for some reason they did, I’m pretty
certain their top talent would leave.”

[antitoon]

Ik heb de helft van mijn team op Fork gekregen. Die teamleden maken nu goede pull requests doordat interactive rebase in Fork heel simpel is. Iedereen kan nu lekker heel vaak committen en voordat de pull request gemaakt wordt, eerst alle commits bijelkaar zetten en fixuppen met een rebase.
Helaas is de app nu betaald, maar is zijn geld voor mij zeker waard.

[BarôZZa]

WernerL schreef op woensdag 12 april 2023 @ 10:52:
[...]


Sprint backlog. Als iets in een sprint staat is het wel fijn als het ver genoeg refined is en er een requirement analyse is uitgevoerd. (Duidelijke criteria wat er gebouwd moet worden, niet persee technische analyse) Als dat nog tijdens implementatiefase gedaan moet worden is er iets niet goed gegaan.

[...]


Eens. Maar zonder goed uitgewerkte tickets kun je niet goede inschattingen geven en vervolgens ook niet goed plannen. Ik vind refiment, analyse en development losse fases die los uitgevoerd moeten worden. Een goed bereikbare PO is inderdaad erg fijn en helpt heel veel.

En als er iets overlegt wordt zorgen dat afspraken in tickets worden gezet is ook belangrijk. Niet dat veel informatie alleen leeft in de hoofden van de meest senior mensen die wel in alle meetings zitten.

Vage issues krijgen veel storypoints of geen schatting, dan worden ze vanzelf wel verduidelijkt voordat ze meegenomen kunnen worden in een sprint. Maar voor de rest eens.

[...]


Meestal houden PMs van scrumteams zich alleen met budget en mensen bezig. Regelen dat er iemand aangenomen wordt als dat nodig is bijvoorbeeld. Maar heb ook micro-managers meegemaakt in "scrum"-teams.

Een scrumteam bestaat uit developers, Product Owner en Scrum Master. Die zijn allemaal gelijkwaardig. Er zijn geen andere rollen en al helemaal geen managers. Heb je dat wel, dan is het geen scrum en duidt het op hiërarchie en dat is ongewenst. Developers managen hun eigen werk (goed uitgangspunt is imo dat developers zichzelf assignen aan issues ipv dat 1 persoon dat doet zodat je helemaal geen manager-achtige rol hebt).

Maarja, je hebt veel bedrijven die zeggen dat ze scrum werken en dan blijken ze alleen sprints, daily standups en reviews te doen en het verder weinig met scrum te maken te hebben.

In m'n junior developer tijd ook meegemaakt. Bedrijf ging zogenaamd agile/scrummen: directeur werd PO want die bepaalde aan het begin wat er gebouwd moest worden, de scrum master assignde iedereen, hield alles dagelijks in de gaten(is dit al af?) en presenteerde aan het eind van de sprint presenteerde dan weer aan de PO wat er gebouwd was... Oftewel: er veranderde geen reet

Caelorum schreef op woensdag 12 april 2023 @ 10:54:
[...]

Ik vind dat wel wat laat eerlijk gezegd. Het is lastig committeren op werk waarvan niet duidelijk is wat er precies gedaan moet worden. IMO zou werk dus ook niet in een sprint getrokken moeten worden tenzij dit voldoende is uitgewerkt.

Je committeert aan de sprint goal, niet aan alle issues in de sprint backlog. Sprint backlog is meer een scope waaruit de developers werk kunnen oppakken.

En ja, bij development komen zaken soms gewoon laat. Afhankelijk van het bedrijf natuurlijk, maar in mijn geval gebeurde het dat je moest wachten op derde partijen. De grootste klant die roept dat iets over een paar weken af moest zijn om aan een wet te voldoen anders kunnen er geen sales gedraaid worden.... Details volgen hopelijk komende week als de sprint al loopt

Ik vind het overigens een verademing om na jaren scrum weer in een kanban-achtige werkomgeving te zitten. Ik pak gewoon werk op en zorg dat het zo snel mogelijk af komt. Items kunnen variëren van goed uitgewerkt tot enkel een oneliner als titel en van 30min werk tot 4 weken intensief andere teams begeleiden. Heel variabel en geen enkele dag is hetzelfde, ook qua proces. Wel enorm onvoorspelbaar, waar scrum juist uitblinkt in voorspelbaarheid, maar dat is een probleem voor de mensen die de planning doen

Zelf nooit met kanban gewerkt, ben wel geïnteresseerd. Wat zijn voor jou de voor en nadelen? En is het niet extra stressvol voor (sommige) developers? Bij scrum vond ik het als developer altijd wel relaxt dat je vaak een beetje kon multitasken qua issues. Dus aan meerdere zaken tegelijk werken, als het aan het eind van de sprint maar gefixt was.

Krijgen de items dan nog wel estimates trouwens?

[Caelorum]

BarôZZa schreef op woensdag 12 april 2023 @ 14:12:
[...]
Zelf nooit met kanban gewerkt, ben wel geïnteresseerd. Wat zijn voor jou de voor en nadelen? En is het niet extra stressvol voor (sommige) developers? Bij scrum vond ik het als developer altijd wel relaxt dat je vaak een beetje kon multitasken qua issues. Dus aan meerdere zaken tegelijk werken, als het aan het eind van de sprint maar gefixt was.

Krijgen de items dan nog wel estimates trouwens?

Ik zei een soort van kanban lees, kanban, maar geen limiet op WIP behalve dan wat de developer zelf fijn vind en kan handelen. Meerdere zaken tegelijkertijd probeert iedereen te voorkomen, maar omdat de zaken vaak veel externe afhankelijkheden hebben (andere teams, externe partijen of domweg volgordelijkheid) is dat een mooie ideale situatie om naartoe te werken en niet de dagelijkse realiteit. Ik heb meestal 1 tot 3 dingen actief onder handen.
Developers waarvoor dit werkproces niet werkt zitten ook niet lang in het team. Sowieso worden ze er op geselecteerd, maar het komt wel voor dat mensen in het team komen en na 3 maanden weer weg zijn. Het moet je liggen.
Voor mij (en eigenlijk het team) zitten de voordelen vooral in het enorm snel kunnen schakelen. We hebben een backlog die gesorteerd is op prioriteit, maar die is redelijk fluïde. We kunnen tot op de minuut ineens schakelen van prioriteit als het moet zonder dat een "sprint" in gevaar komt. We hebben verder twee keer per week een meeting waarin we de voortgang bespreken en of mensen ergens tegenaan lopen, korte ad-hoc designsessie enz., maar dat is het ook wel. Verder is het vooral heel veel ad-hoc communicatie onderling en met de scrum teams. Het komt voor mij ook best vaak voor dat ik 2-3 dagen niet aan mijn eigen werk toe kom (of het team goal). Dat was in scrum teams toch altijd wel wat lastiger. Hier is het gewoon part of the deal en ga ik gewoon met de flow van de afdeling mee

[Mugwump]

Alles beter dan vragen van het niveau: 'Hoi kun jij even op basis van 3 zinnen tekst aangeven hoeveel sprints het team daarmee bezig is?'.
Ik zeg tegenwoordig altijd maar: "Wat wil je horen? Mij boeit het geen reet want er is zit toch geen enkele consequentie aan dat soort loze schattingen."

[ocf81]

re: commits: Je wil graag je commit historie in tact laten om te zien hoe iets tot stand is gekomen. Om die reden heb ik wat moeite met het standaard gebruik van opties zoals --patch en ergens ook met rebase, omdat je ergens gewoon ook bezig bent met het editen van historie. Squash vind ik wel redelijk, maar onder voorwaarde dat de merge commit van een volledig commentaar wordt voorzien wat er met de commit wordt beoogd en welke motivatie er voor is. Er is in de basis niks mis met een grafische client, mits men wel begrijpt dat dit slechts een frontend is. Een GUI is prima voor standaardtaken. Dat gefriemel met add -p en rebase doe je maar als het echt niet anders kan, dus enkel in noodgevallen.

re: developmentmethode: Als iemand die veel aandacht heeft voor ontwikkelmethoden en ook wel eens de SM rol op zich heeft genomen heb ik inderdaad wel gezien dat scrum vaak zeer slecht geïmplementeerd wordt. Doch niet alleen door management, maar ook door developers. Management heeft er inderdaad vaak het handje van toch een grote vinger in de pap te willen en niet los te kunnen laten. Dit vertaalt zich vaak in het opvoeren van allerlei redenen om zich toch met de uitvoering van taken te bemoeien, het onderbreken van werkzaamheden "omdat het nu moet" al dan niet door de PO volledig onder curatele te stellen, maar soms ook door er op te staan dat ze bij allerlei scrum momenten aanwezig moeten zijn. Ik ben zelf van mening dat refinement een valkuil kan zijn. Je wil wél genoeg info om een beslissing te kunnen maken, maar eigenlijk wil je bij het oppakken van het item à la XP gewoon kunnen sparren met de verzoeker en/of SME, om zo de valkuilen te kunnen voorkomen. Als je alles zo ver gaat opschrijven dat je alles nul kans voor fouten hebt ben je terug bij requirements engineering zoals we dat van waterval kennen, en dan ben je stiekem dus iteratief aan het watervallen. Het liefst dus inderdaad behapbare brokken die risico beperken en waar de mogelijke inputs en outputs duidelijk worden omschreven. Helaas is het vaak zo dat verzoeker/SME dan niet beschikbaar is. Dit is denk ik iets dat je nooit echt kan perfectioneren, maar je moet altijd een balans proberen te vinden tussen details aanleggen (hoe meer, hoe kostbaarder) en zaken openlaten voor een developer. Dat gezegd hebbende zijn developers er ook zeer bedreven in om niet echt als team te willen werken. Het loopt toch vaak uit op: "geef mij mijn taakje maar waar ik mee bezig kan gaan", in plaats van als echt team aan de slag te gaan en samen aan SBI's te gaan werken. Nagenoeg nul samenwerken, lange gezichten als de uitdrukking pair programming door de lucht zweeft en elkaar affakkelen in plaats van opbouwende kritiek leveren bij code reviews is helaas veel vaker de praktijk dan dat men als team de taken voor een backlog item verdeeld en men elkaar op de hoogte houdt en ervoor zorgt dat men elkaar actief ondersteunt, wat eigenlijk de insteek van scrum is. Maar daar moet wel bij worden gezegd dat scrum eigenlijk bedoeld is voor complexe projecten. Lang niet elk project of product valt echt in die categorie.

Wat dan de meest geschikte methode is voor een organisatie hangt denk ik af van de aard van de werkzaamheden. Als je puur met productontwikkeling bezig bent en niet zo veel service hoeft te bieden is scrum denk ik de meest geëigende methode. Als je een dienst in de lucht moet houden is kanban meer geschikt.

[Caelorum]

ocf81 schreef op vrijdag 14 april 2023 @ 13:11:
re: commits: Je wil graag je commit historie in tact laten om te zien hoe iets tot stand is gekomen. Om die reden heb ik wat moeite met het standaard gebruik van opties zoals --patch en ergens ook met rebase, omdat je ergens gewoon ook bezig bent met het editen van historie. [...] Dat gefriemel met add -p en rebase doe je maar als het echt niet anders kan, dus enkel in noodgevallen.[...]

Rebase is prima als je je eigen branch rebased op de target branch. Ik vind het zelfs te prefereren boven een merge van de target naar de eigen branch, omdat de uiteindelijke PR naar de target niet vervuilt is met onzinnige merge commits en als het goed is alleen de daadwerkelijk nuttige commits nog overhouden. Ik rebase en squash er daarom op los in mijn eigen branches zodat elke commit een zinnige change bevat en eventueel los te beoordelen is in de PR. Zo heb ik vaak als ik iets van een refactor moet doen voordat ik aan mijn eigen daadwerkelijke change toekom een losse commit met die refactor en een losse commit met de change in de branch/PR zitten.
Maar dit gaat uiteraard uit van feature branches die lang genoeg leven om überhaupt merge conflicts te krijgen

[ocf81]

Caelorum schreef op vrijdag 14 april 2023 @ 13:57:
[...]

Rebase is prima als je je eigen branch rebased op de target branch. Ik vind het zelfs te prefereren boven een merge van de target naar de eigen branch, omdat de uiteindelijke PR naar de target niet vervuilt is met onzinnige merge commits en als het goed is alleen de daadwerkelijk nuttige commits nog overhouden. Ik rebase en squash er daarom op los in mijn eigen branches zodat elke commit een zinnige change bevat en eventueel los te beoordelen is in de PR. Zo heb ik vaak als ik iets van een refactor moet doen voordat ik aan mijn eigen daadwerkelijke change toekom een losse commit met die refactor en een losse commit met de change in de branch/PR zitten.
Maar dit gaat uiteraard uit van feature branches die lang genoeg leven om überhaupt merge conflicts te krijgen

Tja, het is waar dat met een gewone merge er veel veel rommel meekomt. Dan is dus een squash op zijn plaats. Rebase blijft in mijn ogen gewoon het herschrijven van historie. Met merge zijn er duidelijke momenten dat lijnen bij elkaar komen, dat is denk ik een essentieel stukje historie dat bij rebase er gewoon niet is. Procesgewijs is rebase dus een powertool die je alleen zou moeten gebruiken in noodgevallen. Standaardgebruik van rebase zie ik vooral als een symptoom van een developer die te eigenwijs is om een proces te kunnen volgen. analogie: "Waarom zou ik alles met regedit doen als ik het in settings kan instellen?".

[Caelorum]

@ocf81 Ik volg het echt niet. Wat je op bijv. een feature branch doet met rebasen enz. moet je IMO zelf weten. Zolang de merge naar de target branch (main/master ofzo) maar wel met een reguliere merge gebeurd. Dan heeft niemand er toch last van? Behalve dan dat de feature branch ook overzichtelijker blijft. en de historie als je hem grafisch rendered ook cleaner is met minder lijntjes tussen de branches.

[ocf81]

Caelorum schreef op vrijdag 14 april 2023 @ 14:10:
@ocf81 Ik volg het echt niet. Wat je op bijv. een feature branch doet met rebasen enz. moet je IMO zelf weten. Zolang de merge naar de target branch (main/master ofzo) maar wel met een reguliere merge gebeurd.

Ja, dat zei je er niet bij hè? Er zijn zat mensen die vrolijk alles rebasen naar meer upstream branches. Als het gaat om middels rebase uit master om bij te werken heb ik er nog niet zo veel moeite mee, hoewel ik zelf de workflow van een merge voor updaten van een feature branch veel netter vind als het om proces gaat.

Caelorum schreef op vrijdag 14 april 2023 @ 14:10:
Dan heeft niemand er toch last van? Behalve dan dat de feature branch ook overzichtelijker blijft. en de historie als je hem grafisch rendered ook cleaner is met minder lijntjes tussen de branches.

Ik kan die lijntjes wel waarderen, mede omdat je dan veel duidelijker ziet wanneer iets erbij is gekomen. soms moet je ook met meerdere collega's samenwerken op dezelfde feature, en dan is rebase een hel.

[RobertMe]

ocf81 schreef op vrijdag 14 april 2023 @ 14:15:
[...]

Ja, dat zei je er niet bij hè?

Of je hielt er zelf een andere procesmatige actie op aan dan de rest? De rebase discussie in het algemeen ging voornamelijk om de feature bramch clean te houden. Dus bv dat je nog eergens een typo tegen komt en die met een rebase fixt in de originele commit (zodat de typo nooit gebeurt is). Jij lijkt te duiden op het proces om een branch last minute te rebasen op master om vervolgens een fast-forward merge te doen (waardoor het "geen merge" (commit) is).

[...]

Ik kan die lijntjes wel waarderen, mede omdat je dan veel duidelijker ziet wanneer iets erbij is gekomen. soms moet je ook met meerdere collega's samenwerken op dezelfde feature, en dan is rebase een hel.

Ook hierbij, praten jullie over dezelfde lijntjes? Die lijntjes van "master is gemerged in feature branch" geven een enorme zooi (zekee als master ook weer merges bevat) omdat je dan ineens 10+ linntjes naast elkaar kunt hebben. Lijntjes v.w.b. "dit was een (feature) branch en is hier gemerged naar master" zijn wel handig.

[ocf81]

RobertMe schreef op vrijdag 14 april 2023 @ 14:21:
[...]

Of je hielt er zelf een andere procesmatige actie op aan dan de rest? De rebase discussie in het algemeen ging voornamelijk om de feature bramch clean te houden. Dus bv dat je nog eergens een typo tegen komt en die met een rebase fixt in de originele commit (zodat de typo nooit gebeurt is). Jij lijkt te duiden op het proces om een branch last minute te rebasen op master om vervolgens een fast-forward merge te doen (waardoor het "geen merge" (commit) is).


[...]

Ook hierbij, praten jullie over dezelfde lijntjes? Die lijntjes van "master is gemerged in feature branch" geven een enorme zooi (zekee als master ook weer merges bevat) omdat je dan ineens 10+ linntjes naast elkaar kunt hebben. Lijntjes v.w.b. "dit was een (feature) branch en is hier gemerged naar master" zijn wel handig.

Ja, proces is (super)belangrijk, helemaal als je in een team werkt. Dit is omdat productkwaliteit voorkomt uit proceskwaliteit. Je wil dit kunnen zien als er ooit iets fout gaat en je als team erachter moet komen wanneer iets is gebeurd. Het is het dus belangrijk om ook dat soort dingen te kunnen achterhalen, anders leer je er niks van. De definitieve merge naar master zou ik in dat geval met een goed omschreven squash doen en dan de rest in de feature branch laten staan. (die je in de meeste GUI's gewoon kan verbergen/inklappen)

Waarom zou je die procesinformatie willen verbergen of vernietigen? Wie is daar bij gebaat? (helemaal als je het kan filteren)

[ Voor 11% gewijzigd door ocf81 op 14-04-2023 14:43 ]

[RobertMe]

ocf81 schreef op vrijdag 14 april 2023 @ 14:29:
Waarom zou je die procesinformatie willen verbergen of vernietigen? Wie is daar bij gebaat? (helemaal als je het kan filteren)

Bugfixes op feature branches (in die feature, dus niet een bugfix voor iets op master natuurlijk) vind ik persoonlijk geen procesinformatie, tenzij het natuurlijk halve rewrites zijn omdat de gehele opzet niet klopte. En als de informatie hoe ik ergens gekomen ben wel belangrijk is dan wil ik dat ook in mijn historie hebben. Vervolgens een squash merge doen verbergt die informatie juist. En met bv een blame/annotate kom je in jou geval dus alleen maar op een enorme commit + commit message uit. En dat terwijl je "de lijntjes kunt waarderen", ga je vervolgens met een squash merge een grote commit er van maken en de historie weggooien verbergen.
En persoonlijk vind ik "feature branch na mergen laten bestaan" ook nogal raar. Als je geen squash doet zit alles gewoon in de historie van master. En je hebt dan "de lijntjes", en je kunt nog steeds op basis van de merge commit terug herleiden wat op de branch gedaan was mocht je dat later willen. Immers heeft een merge commit twee parents, die een git log/git show van de merge commit ook laat zien, en de tweede parent kun je ook weer een log op doen, of desnoods opnieuw een branch aanmaken op basis van die commit (immers is een branch niet meer of minder dan een verwijzing naar een commit hash die bij het committen van changes automatisch wordt bijgewerkt).

[Mugwump]

RobertMe schreef op vrijdag 14 april 2023 @ 14:59:
[...]

Bugfixes op feature branches (in die feature, dus niet een bugfix voor iets op master natuurlijk) vind ik persoonlijk geen procesinformatie, tenzij het natuurlijk halve rewrites zijn omdat de gehele opzet niet klopte. En als de informatie hoe ik ergens gekomen ben wel belangrijk is dan wil ik dat ook in mijn historie hebben. Vervolgens een squash merge doen verbergt die informatie juist. En met bv een blame/annotate kom je in jou geval dus alleen maar op een enorme commit + commit message uit. En dat terwijl je "de lijntjes kunt waarderen", ga je vervolgens met een squash merge een grote commit er van maken en de historie weggooien verbergen.
En persoonlijk vind ik "feature branch na mergen laten bestaan" ook nogal raar. Als je geen squash doet zit alles gewoon in de historie van master. En je hebt dan "de lijntjes", en je kunt nog steeds op basis van de merge commit terug herleiden wat op de branch gedaan was mocht je dat later willen. Immers heeft een merge commit twee parents, die een git log/git show van de merge commit ook laat zien, en de tweede parent kun je ook weer een log op doen, of desnoods opnieuw een branch aanmaken op basis van die commit (immers is een branch niet meer of minder dan een verwijzing naar een commit hash die bij het committen van changes automatisch wordt bijgewerkt).

Wij proberen serieuze rewrites indien mogelijk ook altijd te scheiden van functionele features als dat mogelijk is, met name ook vanwege de reviews. Als je een functionele feature moet reviewen, dan is het erg lastig om de relevante changes te zien in een brij aan refactorwerk.

[ZaZ]

Ik edit bijna altijd de history om dingen netjes te maken. Amend, patch, (interactive) rebase etc. Allemaal dikke prima! Er is maar 1 regel: Je verandert geen publieke history. Zodra iets de deur uit is, is het wat het is en ga je dat niet meer veranderen.
Verder leef je je maar lekker uit.

[Lethalis]

ZaZ schreef op vrijdag 14 april 2023 @ 15:35:
Ik edit bijna altijd de history om dingen netjes te maken. Amend, patch, (interactive) rebase etc. Allemaal dikke prima! Er is maar 1 regel: Je verandert geen publieke history. Zodra iets de deur uit is, is het wat het is en ga je dat niet meer veranderen.
Verder leef je je maar lekker uit.

Op dit moment commit en push ik van alles in mijn eigen feature branches. Als ik klaar ben, doe ik een squash merge naar de main zodat ik 1 nette commit krijg en verwijder ik de feature branch weer (zowel lokaal als remote).

Ik push mijn feature branches dus ook naar de server, zodat er een backup van wordt gemaakt (zolang het nog work in progress is).

Stel ik zou als alternatief interactive rebase gebruiken op mijn feature branch en bijvoorbeeld daardoor nette commits krijgen (bijvoorbeeld eentje voor refactor en eentje voor de feature), dan zou ik die ook as is kunnen mergen (ipv squash merge).

Waar ik dan mee zit, is mijn eigen feature branch die gepusht is. Force pushen jullie dan om die ook te rewriten? Of push je die helemaal niet?

Zeker als je ook nog op meerdere computers werkt, zie ik daar wat issues mee (snelle desktop pc op kantoor, maar ook een laptop voor onderweg of thuis bijvoorbeeld). Misschien moet ik het gewoon uitproberen, maar ben ff benieuwd Ik heb het even getest, maar er gebeuren dan funky dingen (in Visual Studio iig).

Het werkt uiteraard prima voordat ik mijn feature branch push. Dan kan ik wijzigen wat ik wil en het netjes mergen naar de main / master.

PS
Ik vraag dit ook omdat Visual Studio squash merge niet lijkt te ondersteunen (doe ik nu via de CLI of met Git Extensions), maar het squashen van commits (interactive rebase) wel.

[ Voor 12% gewijzigd door Lethalis op 14-04-2023 16:13 ]

[RobertMe]

Lethalis schreef op vrijdag 14 april 2023 @ 15:44:
Stel ik zou als alternatief interactive rebase gebruiken op mijn feature branch en bijvoorbeeld daardoor nette commits krijgen (bijvoorbeeld eentje voor refactor en eentje voor de feature), dan zou ik die ook as is kunnen mergen (ipv squash merge).

Zolang het ticket niet op resolved staat is het mijn branch en moeten anderen er vanaf blijven Uiteraard uitzondering als er over gecommuniceerd is dat iemand meekijkt naar de branch of zo. Als ik weet dat history rewriting anderen gaat bijten doe ik het uiteraard niet. Maar dan moet ik wel weten dat het anderen kan bijten (laatste punt daarop is dus ticket op resolved, eerder zou het gecommuniceerd moeten zijn).

[ZaZ]

Lethalis schreef op vrijdag 14 april 2023 @ 15:44:
[...]

Op dit moment commit en push ik van alles in mijn eigen feature branches. Als ik klaar ben, doe ik een squash merge naar de main zodat ik 1 nette commit krijg en verwijder ik de feature branch weer (zowel lokaal als remote).

Ik push mijn feature branches dus ook naar de server, zodat er een backup van wordt gemaakt (zolang het nog work in progress is).

Stel ik zou als alternatief interactive rebase gebruiken op mijn feature branch en bijvoorbeeld daardoor nette commits krijgen (bijvoorbeeld eentje voor refactor en eentje voor de feature), dan zou ik die ook as is kunnen mergen (ipv squash merge).

Waar ik dan mee zit, is mijn eigen feature branch die gepusht is. Force pushen jullie dan om die ook te rewriten? Of push je die helemaal niet?

Zeker als je ook nog op meerdere computers werkt, zie ik daar wat issues mee (snelle desktop pc op kantoor, maar ook een laptop voor onderweg of thuis bijvoorbeeld). Misschien moet ik het gewoon uitproberen, maar ben ff benieuwd Ik heb het even getest, maar er gebeuren dan funky dingen (in Visual Studio iig).

Het werkt uiteraard prima voordat ik mijn feature branch push. Dan kan ik wijzigen wat ik wil en het netjes mergen naar de main / master.

PS
Ik vraag dit ook omdat Visual Studio squash merge niet lijkt te ondersteunen (doe ik nu via de CLI of met Git Extensions), maar het squashen van commits (interactive rebase) wel.

Public/private onderscheid maak ik niet op basis van of een branch gepushed is of niet. Pushen is ook prima naar een 'private' branch.
Voor mij is een private branch eentje die niet protected is en waar je dus force push kan uitvoeren. Dat kan zijn op basis van naming convention bijvoorbeeld. Dan weet iedereen dus ook dat je alles in de 'subfolder' van die branch niet gebruiken moet om je werk op te baseren omdat die ondergrond mogelijk verandert in de toekomst. In de praktijk dus eigenlijk alleen branches waar je in je eentje aan werkt.
Of als uitzondering als je bijvoorbeeld met 2 man aan een branch werkt kan het ook nog wel, maar moet je het alleen effe beter communiceren. "Ik ga vanavond effe rebasen en history veranderen. Push je meuk effe als je klaar bent en morgen een reset en pull"
Met 1 of 2 man/vrouw aan zoiets werken is ook nog wel te doen. Nooit echt een probleem mee gehad.

[Lethalis]

@RobertMe @ZaZ Helemaal duidelijk

Ik heb er nog een beetje mee gespeeld in een test repo en de mogelijkheden ook maar meteen met het team gedeeld. En nu is het weekend!

[ocf81]

RobertMe schreef op vrijdag 14 april 2023 @ 14:59:
[...]

Bugfixes op feature branches (in die feature, dus niet een bugfix voor iets op master natuurlijk) vind ik persoonlijk geen procesinformatie, tenzij het natuurlijk halve rewrites zijn omdat de gehele opzet niet klopte. En als de informatie hoe ik ergens gekomen ben wel belangrijk is dan wil ik dat ook in mijn historie hebben. Vervolgens een squash merge doen verbergt die informatie juist. En met bv een blame/annotate kom je in jou geval dus alleen maar op een enorme commit + commit message uit. En dat terwijl je "de lijntjes kunt waarderen", ga je vervolgens met een squash merge een grote commit er van maken en de historie weggooien verbergen.
En persoonlijk vind ik "feature branch na mergen laten bestaan" ook nogal raar. Als je geen squash doet zit alles gewoon in de historie van master. En je hebt dan "de lijntjes", en je kunt nog steeds op basis van de merge commit terug herleiden wat op de branch gedaan was mocht je dat later willen. Immers heeft een merge commit twee parents, die een git log/git show van de merge commit ook laat zien, en de tweede parent kun je ook weer een log op doen, of desnoods opnieuw een branch aanmaken op basis van die commit (immers is een branch niet meer of minder dan een verwijzing naar een commit hash die bij het committen van changes automatisch wordt bijgewerkt).

Dat is leuk als je alleen werkt, maar werkt dit ook nog als je met 3 personen tegelijkertijd aan iets werkt? Uiteindelijk is dat namelijk hoe je complexe problemen het beste aanpakt: in een team. Maar goed, zoals ik al aangaf zijn er maar weinig bedrijven die echt in een team werken.* De meeste scrum teams zijn gewoon werkgroepen die enkel in naam een team zijn en waar niet of nauwelijks wordt samengewerkt. Als je alleen werkt kan wat jij beschrijft ook nog wel. Maar zoals ik in eerste instantie al zei: ik zou alleen een squash doen als het echt nodig is.

* uitleg verschil werkgroep en team: https://asana.com/resources/group-vs-team

[ Voor 4% gewijzigd door ocf81 op 14-04-2023 17:43 ]

[RagingPenguin]

ocf81 schreef op vrijdag 14 april 2023 @ 17:33:
[...]

Dat is leuk als je alleen werkt, maar werkt dit ook nog als je met 3 personen tegelijkertijd aan iets werkt? Uiteindelijk is dat namelijk hoe je complexe problemen het beste aanpakt: in een team. Maar goed, zoals ik al aangaf zijn er maar weinig bedrijven die echt in een team werken.* De meeste scrum teams zijn gewoon werkgroepen die enkel in naam een team zijn en waar niet of nauwelijks wordt samengewerkt. Als je alleen werkt kan wat jij beschrijft ook nog wel. Maar zoals ik in eerste instantie al zei: ik zou alleen een squash doen als het echt nodig is.

* uitleg verschil werkgroep en team: https://asana.com/resources/group-vs-team

Je kan prima een team zijn en allemaal aan je eigen tickets en in je eigen branches werken; dat zegt meer iets over hoe goed je bent in problemen onderverdelen en hoe flexibel je architectuur is. Als je echt alles in een keer en in een branch moet doen dat is het een sterke indicator dat dat laaste er wat minder goed voor staat.

[RobertMe]

ocf81 schreef op vrijdag 14 april 2023 @ 17:33:
[...]

Dat is leuk als je alleen werkt, maar werkt dit ook nog als je met 3 personen tegelijkertijd aan iets werkt? Uiteindelijk is dat namelijk hoe je complexe problemen het beste aanpakt: in een team. Maar goed, zoals ik al aangaf zijn er maar weinig bedrijven die echt in een team werken.* De meeste scrum teams zijn gewoon werkgroepen die enkel in naam een team zijn en waar niet of nauwelijks wordt samengewerkt. Als je alleen werkt kan wat jij beschrijft ook nog wel. Maar zoals ik in eerste instantie al zei: ik zou alleen een squash doen als het echt nodig is.

* uitleg verschil werkgroep en team: https://asana.com/resources/group-vs-team

Klopt in zoverre. En bij mij op het werk zijn het intussen allemaal individuen die door een ander individu een ticketnr te horen krijgen dat ze als volgende moeten oppakken. Dat is niet eens een groep (meer).
In any case: toch vind ik het raar als je echt continu met meerdere personen op een branch werkt. Dan vraag ik mij af of de tickets niet te groot zijn (of de beoogde doorlooptijd te kort) of dat het effectief een vorm van pair programming wordt waarbij de een meekijkt over de schouder van een ander. Immers kun je anders de taken ook weer wat meer opsplitsen en er een epic van maken met meerdere losse tickets rn iedereen op zijn eigen ticket branch werkt om vervolgens wat af is te mergen naar een branch behorende tot de epic.
Maar als je met meerdere mensen echt aan een ticket op een branch werkt spreekt het ook wel weer voor zich dat je dan niet gaat rebasen. Omdat dat de zaken onnodig moeilijk maakt.

[ocf81]

RagingPenguin schreef op vrijdag 14 april 2023 @ 17:58:
[...]


Je kan prima een team zijn en allemaal aan je eigen tickets en in je eigen branches werken; dat zegt meer iets over hoe goed je bent in problemen onderverdelen en hoe flexibel je architectuur is. Als je echt alles in een keer en in een branch moet doen dat is het een sterke indicator dat dat laaste er wat minder goed voor staat.

Sorry, maar je laat nu perfect zien dat je niet snapt wat een team is. De centrale definitie van een team is dat men samen aan hetzelfde doel werkt. Dat zal bij een complexe taak betekenen dat je aan hetzelfde backlog item werkt, waarbij onderlinge afhankelijkheden bestaan. De meeste 'teams' zijn in feite werkgroepen.

[ocf81]

RobertMe schreef op vrijdag 14 april 2023 @ 18:02:
[...]

Klopt in zoverre. En bij mij op het werk zijn het intussen allemaal individuen die door een ander individu een ticketnr te horen krijgen dat ze als volgende moeten oppakken. Dat is niet eens een groep (meer).

Ik ben benieuwd welke naam het dan heeft.

RobertMe schreef op vrijdag 14 april 2023 @ 18:02:
In any case: toch vind ik het raar als je echt continu met meerdere personen op een branch werkt. Dan vraag ik mij af of de tickets niet te groot zijn (of de beoogde doorlooptijd te kort) of dat het effectief een vorm van pair programming wordt waarbij de een meekijkt over de schouder van een ander. Immers kun je anders de taken ook weer wat meer opsplitsen en er een epic van maken met meerdere losse tickets rn iedereen op zijn eigen ticket branch werkt om vervolgens wat af is te mergen naar een branch behorende tot de epic.
Maar als je met meerdere mensen echt aan een ticket op een branch werkt spreekt het ook wel weer voor zich dat je dan niet gaat rebasen. Omdat dat de zaken onnodig moeilijk maakt.

Op zich een terechte vraag waar je dan mee bezig bent. Wat ik vaak zie is dat men in scrum teams maar wat werk bij elkaar gooit om iedereen maar aan de bak te houden. Meestal heeft men lak aan sprint goals die echt één thema bedienen. Als je dat wel doet heb je soms inderdaad backlog items welke elkaar aanvullen en welke allen ten doel hebben een increment tot stand te laten komen waarin dat thema volledig wordt uitgewerkt. Soms kan dat echter niet. Op zo'n moment moet je niet iets een x aantal sprints door laten etteren, maar samen de boel oppakken. Dat is inderdaad complex, maar als je echt samen leert werken is dat wel de manier om complexe zaken sneller en beter op te pakken.

Het is dus wel puur vanuit het scrum perspectief gezien.

[ Voor 3% gewijzigd door ocf81 op 14-04-2023 19:07 ]

[RobertMe]

ocf81 schreef op vrijdag 14 april 2023 @ 19:04:
[...]

Ik ben benieuwd welke naam het dan heeft.

Chaos? Puinzooi? You catch my drift

Scrum is ooit geprobeerd, maar dan natuurlijk sowieso al een aftreksel van. Vervolgens lukte dat toch allemaal niet, en ooit is toen voor uhm, Scrumban gekozen "van bovenaf" (lees: manager). Maar uiteindelijk is het gewoon "teamlead zegt wat te doen en voetjesvolk doet het en mag vooral niet te veel vragen stellen".

[OMX2000]

ocf81 schreef op vrijdag 14 april 2023 @ 19:00:
[...]

Sorry, maar je laat nu perfect zien dat je niet snapt wat een team is. De centrale definitie van een team is dat men samen aan hetzelfde doel werkt. Dat zal bij een complexe taak betekenen dat je aan hetzelfde backlog item werkt. De meeste 'teams' zijn in feite werkgroepen.

Volgens mij is je het enige waar de meeste mensen het over eens zijn dat een team een gemeenschappelijk doel heeft.

Of je samen aan een backlog item werkt is niet zomaar een gegeven. Da’s afhankelijk van hoe het team het wil werken.

Ik vind het “swarmen” bijvoorbeeld niet per se fijn en efficient. Het is fijn om af en toe samen een issue op te pakken. Maar laat mij me maar even een paar uur alleen ergens in vastbijten. En dan ala ik klaar ben met een story, de oplossing en de redenen waarom ik ergens voor gekozen heb met iemand bespreken die de review kan doen.

[ocf81]

RobertMe schreef op vrijdag 14 april 2023 @ 19:07:
[...]

Chaos? Puinzooi? You catch my drift

Scrum is ooit geprobeerd, maar dan natuurlijk sowieso al een aftreksel van. Vervolgens lukte dat toch allemaal niet, en ooit is toen voor uhm, Scrumban gekozen "van bovenaf" (lees: manager). Maar uiteindelijk is het gewoon "teamlead zegt wat te doen en voetjesvolk doet het en mag vooral niet te veel vragen stellen".

Werk jij toevallig in Houten bij een toko die iets met taxaties doet?

[RobertMe]

ocf81 schreef op vrijdag 14 april 2023 @ 19:09:
[...]

Werk jij toevallig in Houten bij een toko die iets met taxaties doet?

Nope en nope.

[ocf81]

OMX2000 schreef op vrijdag 14 april 2023 @ 19:09:
[...]


Volgens mij is je het enige waar de meeste mensen het over eens zijn dat een team een gemeenschappelijk doel heeft.

In een echt team zou dat niet zo moeten zijn, maar helaas zijn de meeste 'teams' dus geen echte teams.

OMX2000 schreef op vrijdag 14 april 2023 @ 19:09:
Of je samen aan een backlog item werkt is niet zomaar een gegeven. Da’s afhankelijk van hoe het team het wil werken.

Het zou geen kwestie van willen moeten zijn. Als je echt een team bent werk je gewoon samen als dat nodig is.

OMX2000 schreef op vrijdag 14 april 2023 @ 19:09:
Ik vind het “swarmen” bijvoorbeeld niet per se fijn en efficient. Het is fijn om af en toe samen een issue op te pakken. Maar laat mij me maar even een paar uur alleen ergens in vastbijten. En dan ala ik klaar ben met een story, de oplossing en de redenen waarom ik ergens voor gekozen heb met iemand bespreken die de review kan doen.

Maar je geeft hier dus eigenlijk aan geen teamplayer te kunnen of willen zijn.

Overigen is swarmen is ook niet altijd nodig, maar men moet het niet afwijzen of ontwijken. Daar moet je dus ook je processen op afstemmen.

[ Voor 5% gewijzigd door ocf81 op 14-04-2023 19:21 ]

[ocf81]

RobertMe schreef op vrijdag 14 april 2023 @ 19:12:
[...]

Nope en nope.

Oh god. Ik dacht dat ik wel de ergste toko van Nederland had gehad, maar er zijn dus nog meer van dat soort toko's.

[Caelorum]

Wat een gatekeeping zeg.

Ik heb in echte teams gewerkt waar dus echt een gezamenlijk doel was en we met 5 man 1 feature aan het opleveren waren. Netjes allemaal een deel in een eigen branch. Kon prima gemerged worden aan het eind met een werkende feature.

En dat is het verschil tussen een 'echt' team dat werkt in een goed opgezet stuk software en een 'echt' team dat werkt aan een puinzooi.

Mijn huidige team is overigens 1 waarvan jij zegt dat het geen echt team is. Ook al hebben we een gezamenlijk doel en kan in theorie iedereen elk werk oppakken. En werken we doorgaans niet eens aan dezelfde codebase. Maarja..

[ Voor 22% gewijzigd door Caelorum op 14-04-2023 19:27 ]

[Mugwump]

Caelorum schreef op vrijdag 14 april 2023 @ 19:25:
Wat een gatekeeping zeg.

Ik heb in echte teams gewerkt waar dus echt een gezamenlijk doel was en we met 5 man 1 feature aan het opleveren waren. Netjes allemaal een deel in een eigen branch. Kon prima gemerged worden aan het eind met een werkende feature.

En dat is het verschil tussen een 'echt' team dat werkt in een goed opgezet stuk software en een 'echt' team dat werkt aan een puinzooi.

Mja, ligt ook aan de competentie van teamleden. Wij hebben nu eigenlijk een veel te groot team met heel wat dor hout erin. Deze week echt twee keer kunnen voorkomen dat iemand iets totaal verklootte met enorme impact en één keer de gevolgen mogen ondervinden van iets dat langs mij heen was geglipt, leidende tot een poison messages met impact op miljoenen mensen.

[RagingPenguin]

ocf81 schreef op vrijdag 14 april 2023 @ 19:00:
[...]

Sorry, maar je laat nu perfect zien dat je niet snapt wat een team is. De centrale definitie van een team is dat men samen aan hetzelfde doel werkt. Dat zal bij een complexe taak betekenen dat je aan hetzelfde backlog item werkt, waarbij onderlinge afhankelijkheden bestaan. De meeste 'teams' zijn in feite werkgroepen.

En een doel kan niet groter dan zijn een enkel ticket? Definieer je dan elke 2 dagen een nieuw doel ofzo? Of je heb je alleen maar tickets waar minstens honderd manuren in gaan? Voor mij klinkt dit eerlijk gezegt nogal als abstract mangement geneuzel zonder enige realiteit. Bij een doel stel ik mij op z'n minst een epic voor, en eigenlijk nog wel iets groters wat een redelijk significante impact heeft op het product. Je gaat niet een heel team vormen omdat je ergens een 'export to CSV' knopje wilt in een overzicht...

Je kan ook prima samenwerken en tegelijkertijd aan verschillende tickets op verschillende branches werken. Tickets en branches zijn puur uitvoerende tools, je kan als team nog steeds gezamelijk werken aan de belangrijke zaken zoals architectuur, Q&A etc. Ik zie dit eerder andersom: als je de pracktische uitvoering niet efficient kan opsplitsen in redelijk kleine en losstaande taken dan is er 9 van de 10 iets goeds mis in die overkoepelende zaken.

[ocf81]

Caelorum schreef op vrijdag 14 april 2023 @ 19:25:
Wat een gatekeeping zeg.

Ik heb in echte teams gewerkt waar dus echt een gezamenlijk doel was en we met 5 man 1 feature aan het opleveren waren. Netjes allemaal een deel in een eigen branch. Kon prima gemerged worden aan het eind met een werkende feature.

En dat is het verschil tussen een 'echt' team dat werkt in een goed opgezet stuk software en een 'echt' team dat werkt aan een puinzooi.

Mijn huidige team is overigens 1 waarvan jij zegt dat het geen echt team is. Ook al hebben we een gezamenlijk doel en kan in theorie iedereen elk werk oppakken. En werken we doorgaans niet eens aan dezelfde codebase. Maarja..

Ja en nee. Ik zie in de laatste paar posts van sommigen hier toch wel doorsijpelen dat men het wel oké vind om solo te werken en het dan toch een team te noemen. Een definitie welke aan die notie invulling geeft is gewoon niet wat je een team kan noemen. De beslissende factor is of men onderling afhankelijk is. Dus in welke mate werk je aan iets waar je teamleden van afhankelijk zijn in dezelfde sprint? Als die afhankelijkheid zo beperkt is dat men at random mensen weg kan halen en het weinig tot niks uitmaakt, en dat de structuur daar ook volledig is op ingesteld, dan is het de facto geen echt team. Ik irriteer mij altijd aan de notie dat als je mensen bij elkaar stopt, het gelijk een 'team' is. Bedrijven die dat doen en dan daarbij ook eens zo maar even een teamlid naar een ander team dirigeren is denk ik het voorbeeld bij uitstek van bedrijven die geen idee hebben wat een team is en wat de omstandigheden zijn waar een team tot zijn recht kan komen.

[ Voor 5% gewijzigd door ocf81 op 14-04-2023 19:41 ]

[ocf81]

RagingPenguin schreef op vrijdag 14 april 2023 @ 19:31:
[...]


En een doel kan niet groter dan zijn een enkel ticket? Definieer je dan elke 2 dagen een nieuw doel ofzo? Of je heb je alleen maar tickets waar minstens honderd manuren in gaan? Voor mij klinkt dit eerlijk gezegt nogal als abstract mangement geneuzel zonder enige realiteit. Bij een doel stel ik mij op z'n minst een epic voor, en eigenlijk nog wel iets groters wat een redelijk significante impact heeft op het product. Je gaat niet een heel team vormen omdat je ergens een 'export to CSV' knopje wilt in een overzicht...

Je kan ook prima samenwerken en tegelijkertijd aan verschillende tickets op verschillende branches werken. Tickets en branches zijn puur uitvoerende tools, je kan als team nog steeds gezamelijk werken aan de belangrijke zaken zoals architectuur, Q&A etc. Ik zie dit eerder andersom: als je de pracktische uitvoering niet efficient kan opsplitsen in redelijk kleine en losstaande taken dan is er 9 van de 10 iets goeds mis in die overkoepelende zaken.

Je had het over opdelen en uitwerken. Zoals ik al uitlegde ligt het eraan in welke mate je dan onderling afhankelijk bent. Op zich is het wel zo dat je een architectuur zo kan maken dat het werk atomair gemaakt kan worden. Maar dat zegt nog niks over het onderling afhankelijk zijn. Ik heb vaak genoeg meegemaakt dat men bij complexere taken ervoor kiest om dan maar een of twee mensen meerdere sprints te laten werken aan zo'n taak. Dat is dus wat je niet wil. Dan is het tijd om de koppen bij elkaar te steken.

[OMX2000]

ocf81 schreef op vrijdag 14 april 2023 @ 19:13:
[...]

In een echt team zou dat niet zo moeten zijn, maar helaas zijn de meeste 'teams' dus geen echte teams.


[...]

Het zou geen kwestie van willen moeten zijn. Als je echt een team bent werk je gewoon samen als dat nodig is.


[...]

Maar je geeft hier dus eigenlijk aan geen teamplayer te kunnen of willen zijn.

Overigen is swarmen is ook niet altijd nodig, maar men moet het niet afwijzen of ontwijken. Daar moet je dus ook je processen op afstemmen.

Ik volg je even niet. Er zijn verschillende type teams. De manier hoe het team het liefst en efficiënts werkt stemt het team samen af. Het uiteindelijke doel is goed werkende software opleveren.

Of je dan je WIP laag houdt ala LEAN/Kanban, en dus met meerdere mensen aan een item werkt. Of dat samen werkt aan meerdere user stories tegelijk is iets wat het team bepaalt door vast te stellen wat voor hun het meest efficient werkt.

Als 1 teamlid, laten we zeggen de teamlead, dat iedereen samen aan een item moet werken. En het team wordt er doodongelukkig van werkt suboptimaal, dan mag jij raden wie er dan GEEN teamspeler is.

[CodeCaster]

ocf81 schreef op vrijdag 14 april 2023 @ 19:39:
[...]

Ja en nee. Ik zie in de laatste paar posts van sommigen hier toch wel doorsijpelen dat men het wel oké vind om solo te werken en het dan toch een team te noemen. Een definitie welke aan die notie invulling geeft is gewoon niet wat je een team kan noemen. De beslissende factor is of men onderling afhankelijk is. Dus in welke mate werk je aan iets waar je teamleden van afhankelijk zijn in dezelfde sprint? Als die afhankelijkheid zo beperkt is dat men at random mensen weg kan halen en het weinig tot niks uitmaakt, en dat de structuur daar ook volledig is op ingesteld, dan is het de facto geen echt team. Ik irriteer mij altijd aan de notie dat als je mensen bij elkaar stopt, het gelijk een 'team' is. Bedrijven die dat doen en dan daarbij ook eens zo maar even een teamlid naar een ander team dirigeren is denk ik het voorbeeld bij uitstek van bedrijven die geen idee hebben wat een team is en wat de omstandigheden zijn waar een team tot zijn recht kan komen.

Ik vind het ook een wat aparte, strakke afkadering. Jij doet alsof je het pas een team mag noemen als je elke deelnemer ervan elk moment nodig hebt? Zoals een operatieteam?

Als er niemand is om de scalpels aan te geven, heeft de chirurg weinig te snijden. Dat is allemaal vrij serieel en onderling afhankelijk werk.

Maar als je werkt met een architect, DBA, developer, tester, UX'er, dan kan er voor één feature prima parallel worden gewerkt, zelfs tijdens afwezigheid van een ervan.

Als je werkt met een aantal developers die allemaal aan losse features voor hetzelfde stuk software werken, die dus niet onderling afhankelijk werken, is het geen team? Is er dan geen gezamenlijk doel?

[OMX2000]

ocf81 schreef op vrijdag 14 april 2023 @ 19:39:
[...]

Ja en nee. Ik zie in de laatste paar posts van sommigen hier toch wel doorsijpelen dat men het wel oké vind om solo te werken en het dan toch een team te noemen. Een definitie welke aan die notie invulling geeft is gewoon niet wat je een team kan noemen. De beslissende factor is of men onderling afhankelijk is. Dus in welke mate werk je aan iets waar je teamleden van afhankelijk zijn in dezelfde sprint? Als die afhankelijkheid zo beperkt is dat men at random mensen weg kan halen en het weinig tot niks uitmaakt, en dat de structuur daar ook volledig is op ingesteld, dan is het de facto geen echt team. Ik irriteer mij altijd aan de notie dat als je mensen bij elkaar stopt, het gelijk een 'team' is. Bedrijven die dat doen en dan daarbij ook eens zo maar even een teamlid naar een ander team dirigeren is denk ik het voorbeeld bij uitstek van bedrijven die geen idee hebben wat een team is en wat de omstandigheden zijn waar een team tot zijn recht kan komen.

Ik blijf je niet volgen hier. Dus ik zal maar een vraag stellen.

Vind jij dat wanneer er gewerkt wordt volgens Scrum, er meerdere stories op het sprint bord en in progress kunnen staan?

[ocf81]

OMX2000 schreef op vrijdag 14 april 2023 @ 19:48:
[...]


Ik volg je even niet. Er zijn verschillende type teams. De manier hoe het team het liefst en efficiënts werkt stemt het team samen af. Het uiteindelijke doel is goed werkende software opleveren.

Of je dan je WIP laag houdt ala LEAN/Kanban, en dus met meerdere mensen aan een item werkt. Of dat samen werkt aan meerdere user stories tegelijk is iets wat het team bepaalt door vast te stellen wat voor hun het meest efficient werkt.

Als 1 teamlid, laten we zeggen de teamlead, dat iedereen samen aan een item moet werken. En het team wordt er doodongelukkig van werkt suboptimaal, dan mag jij raden wie er dan GEEN teamspeler is.

Sorry om je teleur te stellen, maar dat is dan iedereen die daar niet mee om kan gaan. En ja, de term team wordt vaak en hevig misbruikt.

[Caelorum]

@ocf81 afhankelijkheid van elkaars werk is een plannings en architectuurissue. Zo heb ik ook in een scrum team gewerkt waar we de afhankelijkheid juist over meerdere sprints heen trokken en niet in een sprint. Daarmee borg je namelijk voorspelbaarheid en continuïteit. Elke ontwikkelaar kom gewoon plots uitvallen zonder een planningsissue te creëren. Werk werd netjes opgedeeld en verspreid over sprints zodat er geen of nauwelijk afhankelijkheid was van elkaars werk. Werk en voortgang werd netjes bij de items en in git vastgelegd, juist zodat we gezamenlijk de commitment konden maken op het op te leveren werk en elkaar konden helpen/controleren en voorspelbaar konden leveren aan het bedrijf.

Dat is overigens nadrukkelijk niet hoe het team waar ik nu in zit werkt, maar OK. Volgens jouw zijn beide teams geen teams maar werkgroepen. Een mening die ik totaal niet deel.

[ocf81]

CodeCaster schreef op vrijdag 14 april 2023 @ 19:49:
[...]

Ik vind het ook een wat aparte, strakke afkadering. Jij doet alsof je het pas een team mag noemen als je elke deelnemer ervan elk moment nodig hebt? Zoals een operatieteam?

Dat is inderdaad de definitie van een echt team, ja.

CodeCaster schreef op vrijdag 14 april 2023 @ 19:49:
Als er niemand is om de scalpels aan te geven, heeft de chirurg weinig te snijden. Dat is allemaal vrij serieel en onderling afhankelijk werk.

Maar als je werkt met een architect, DBA, developer, tester, UX'er, dan kan er voor één feature prima parallel worden gewerkt, zelfs tijdens afwezigheid van een ervan.

Soms wel inderdaad. Maar als je dan samen moet werken aan een feature moet je wel ervoor zorgen dat je werk op erlkaar aansluit. Dat gaat toch wel erg vaak fout bij het maken van software. Je ziet dat ook vaak als de stront aan de knikker is. Op zulke momenten zullen de werkgroepen die teams worden genoemd door de mand vallen.

CodeCaster schreef op vrijdag 14 april 2023 @ 19:49:
Als je werkt met een aantal developers die allemaal aan losse features voor hetzelfde stuk software werken, die dus niet onderling afhankelijk werken, is het geen team? Is er dan geen gezamenlijk doel?

Niet in de zin van scrum. Als de onderlinge koppeling ontbreekt is het groepswerk.

[ocf81]

OMX2000 schreef op vrijdag 14 april 2023 @ 19:52:
[...]


Ik blijf je niet volgen hier. Dus ik zal maar een vraag stellen.

Vind jij dat wanneer er gewerkt wordt volgens Scrum, er meerdere stories op het sprint bord en in progress kunnen staan?

Alleen als die samen tot een sprint goal toewerken waarbij het sprint goal natuurlijk een echt sprint goal is dat naar één groter centraal doel werkt, en niet een een of ander allegaartje van random zaken zoals je dat in 90% van de gevallen terugziet.

[Caelorum]

Dus als een team gezamenlijk besluit dat het werk beter zo kan worden opgeknipt en ingedeeld dat er geen afhankelijkheden onderling zijn in elk gegeven tweewekelijkse periode, dan is het geen team meer volgens jouw? Ondanks dat er geen aansturing is behalve gezamenlijke beslissingen en de middellange en langetermijn doelen nog steeds een gezamenlijke inspanning en verantwoordelijkheid hebben?

[ocf81]

Caelorum schreef op vrijdag 14 april 2023 @ 19:54:
@ocf81 afhankelijkheid van elkaars werk is een plannings en architectuurissue. Zo heb ik ook in een scrum team gewerkt waar we de afhankelijkheid juist over meerdere sprints heen trokken en niet in een sprint. Daarmee borg je namelijk voorspelbaarheid en continuïteit. Elke ontwikkelaar kom gewoon plots uitvallen zonder een planningsissue te creëren. Werk werd netjes opgedeeld en verspreid over sprints zodat er geen of nauwelijk afhankelijkheid was van elkaars werk. Werk en voortgang werd netjes bij de items en in git vastgelegd, juist zodat we gezamenlijk de commitment konden maken op het op te leveren werk en elkaar konden helpen/controleren en voorspelbaar konden leveren aan het bedrijf.

Dat is overigens nadrukkelijk niet hoe het team waar ik nu in zit werkt, maar OK. Volgens jouw zijn beide teams geen teams maar werkgroepen. Een mening die ik totaal niet deel.

Sorry, maar dat is gewoon geen scrum. Je bent dan bezig om het team om zeep te helpen om zo de manager tevreden te stellen. Dat kan prima werken voor applicaties zonder complexiteit, maar dat is dus expliciet geen teamwork. En wat ik een team noem is gewoon een textbook definitie uit de organisatiepsychologie, en geen een of ander uit de lucht gegrepen idee.

[RagingPenguin]

ocf81 schreef op vrijdag 14 april 2023 @ 19:45:
[...]

Op zich is het wel zo dat je een architectuur zo kan maken dat het werk atomair gemaakt kan worden. Maar dat zegt nog niks over het onderling afhankelijk zijn.

Dat is dus juist mijn punt: op je verschillende tickets of op verschillende branches werkt zegt niets over de samenwerken, maar het is wel een sterke indicator voor de kwaliteit van de architectuur en refinement processen.

Ik heb vaak genoeg meegemaakt dat men bij complexere taken ervoor kiest om dan maar een of twee mensen meerdere sprints te laten werken aan zo'n taak. Dat is dus wat je niet wil. Dan is het tijd om de koppen bij elkaar te steken.

Dat je "koppen bij elkaar steekt" voor de aanpak, technisch ontwerk en allerlij abstracte zaken is denk ik best logisch. Maar met meer dan twee mensen aan dezelde feature werken? Ik heb oprecht moeite om mij voor te stellen hoe dat zou werken zonder dat je elkaar constant voor de voeten loopt/constant aanstaart.

[OMX2000]

ocf81 schreef op vrijdag 14 april 2023 @ 19:52:
[...]

Sorry om je teleur te stellen, maar dat is dan iedereen die daar niet mee om kan gaan. En ja, de term team wordt vaak en hevig misbruikt.

Mij teleurstellen zou best een achievement zijn

Jij hanteert een definitie. En dan moet ik je helaas ook teleurstellen, als we toch bezig zijn, die definitie is niet de enige.

Of software projecten beter verlopen door teams te organiseren en laten werken volgens jouw definitie kan ik niet bewijzen, want ik heb daar geen data voor.

Een definitie van een team zoals die in Scrum gebruikt wordt is als volgt:

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.

Scrum hebben we als tak van sport inmiddels best veel ervaring mee. En wordt over het algemeen gezien als een methode die de kans tot succes vergroot.

[ocf81]

@OMX2000 drie keer raden waarom 80% van de scrum transities niet brengt wat men er van hoopte. Dat is dus omdat men het team niet de autonomie wil geven die nodig is en omdat het team geen echt team wordt.

[ Voor 9% gewijzigd door ocf81 op 14-04-2023 20:05 ]

[OMX2000]

ocf81 schreef op vrijdag 14 april 2023 @ 19:57:
[...]

Alleen als die samen tot een sprint goal toewerken waarbij het sprint goal natuurlijk een echt sprint goal is dat naar één groter centraal doel werkt, en niet een een of ander allegaartje van random zaken zoals je dat in 90% van de gevallen terugziet.

Ah! Dus waar ontstaat het probleem dat mensen aan verschillende zaken werken om die Sprint goal te behalen?

Die 90% is als je niet aan Scrum doet. Dat durf ik wel te stellen.

Dus als je onderschrijft dan Scrum best wel een goede aanpak is, kunnen we weer vriendjes zijn.

[CodeCaster]

ocf81 schreef op vrijdag 14 april 2023 @ 19:56:
[...]

Dat is inderdaad de definitie van een echt team, ja.


[...]

Soms wel inderdaad. Maar als je dan samen moet werken aan een feature moet je wel ervoor zorgen dat je werk op erlkaar aansluit. Dat gaat toch wel erg vaak fout bij het maken van software. Je ziet dat ook vaak als de stront aan de knikker is. Op zulke momenten zullen de werkgroepen die teams worden genoemd door de mand vallen.


[...]

Niet in de zin van scrum. Als de onderlinge koppeling ontbreekt is het groepswerk.

Bedankt, weer wat geleerd. Ik vind het jammer om te ontdekken dat ik de laatste pakweg 15 jaar bij zo'n 8 verschillende softwareclubs nooit in een team heb gewerkt.

In mijn ervaring (vaak MKB, groepen van hooguit 20 developers, meestal 5-10) wordt er in die zin nooit samen gewerkt aan doelen, anders dan "de volgende versie".

Dit komt door verschillende anciënniteit (niet iedereen weet alles van alle systemen/projecten, en die kennis wordt ook absoluut niet gedeeld), verschillen in disciplines (front-end, back-end, databaseontwerp, CI/CD, rapportages, testen), verschillen in ervaring, concurrentie qua projecten binnen een werk/opdrachtgever (een persoon kan zomaar worden weggetrokken voor een andere klus).

Ik denk zeker dat je dat kunt samenvatten als "chaos". En ik ben het ook eens met de uitspraak dat je aan code vaak kunt zien hoe communicatie tussen de bouwers loopt. Eilandjes? Spaghetti.

Ik denk ook dat er binnen veel bedrijven niet de ruimte is om dan daadwerkelijke teams in te richten. Hoe zou jij dat aanpakken?

[ocf81]

OMX2000 schreef op vrijdag 14 april 2023 @ 20:05:
[...]


Ah! Dus waar ontstaat het probleem dat mensen aan verschillende zaken werken om die Sprint goal te behalen?

Ik denk dat dit in de basis begint bij een gebrek aan eenheid in het team. Dat men al bij voorbaat in eigen blokken denkt. Dat mag best een uitkomst zijn, maar moet niet het doel op zich zijn.

OMX2000 schreef op vrijdag 14 april 2023 @ 20:05:
Die 90% is als je niet aan Scrum doet. Dat durf ik wel te stellen.

Dus als je onderschrijft dan Scrum best wel een goede aanpak is, kunnen we weer vriendjes zijn.

Echt scrummen is hemels

Ik ben alleen zo vaak zo erg teleurgesteld

[ Voor 23% gewijzigd door ocf81 op 14-04-2023 20:10 ]

[OMX2000]

ocf81 schreef op vrijdag 14 april 2023 @ 20:04:
@OMX2000 drie keer raden waarom 80% van de scrum transities niet brengt wat men er van hoopte. Dat is dus omdat men het team niet de autonomie wil geven die nodig is en omdat het team geen echt team wordt.

Dan is het GEEN scrum team nee. Dat kan zowel aan het management liggen, als de teamleden die te makkelijk ja en amen overal op zeggen.

Eerlijk is eerlijk. Ik heb vaak genoeg concessies gedaan, en gemerkt dat dat gewoon niet goed uitpakt.

[Caelorum]

ocf81 schreef op vrijdag 14 april 2023 @ 20:01:
[...]

Sorry, maar dat is gewoon geen scrum. Je bent dan bezig om het team om zeep te helpen om zo de manager tevreden te stellen. Dat kan prima werken voor applicaties zonder complexiteit, maar dat is dus expliciet geen teamwork. En wat ik een team noem is gewoon een textbook definitie uit de organisatiepsychologie, en geen een of ander uit de lucht gegrepen idee.

Welke manager heb jij het over?

Misschien dat je nog geen tijd hebt gehad om op deze reactie te reageren dus

Caelorum schreef op vrijdag 14 april 2023 @ 20:00:
Dus als een team gezamenlijk besluit dat het werk beter zo kan worden opgeknipt en ingedeeld dat er geen afhankelijkheden onderling zijn in elk gegeven tweewekelijkse periode, dan is het geen team meer volgens jou? Ondanks dat er geen aansturing is behalve gezamenlijke beslissingen en de middellange en langetermijn doelen nog steeds een gezamenlijke inspanning en verantwoordelijkheid hebben?

Dasr wil ik wel een antwoord op :-) als je zegt nee, kunnen we scrum wel overboord gooien denk ik. En zo ja, dan wil ik wel weten waarom dat team waar ik in heb gewerkt geen team is.

[ Voor 42% gewijzigd door Caelorum op 14-04-2023 20:13 ]

[ocf81]

CodeCaster schreef op vrijdag 14 april 2023 @ 20:06:
[...]

Bedankt, weer wat geleerd. Ik vind het jammer om te ontdekken dat ik de laatste pakweg 15 jaar bij zo'n 8 verschillende softwareclubs nooit in een team heb gewerkt.

In mijn ervaring (vaak MKB, groepen van hooguit 20 developers, meestal 5-10) wordt er in die zin nooit samen gewerkt aan doelen, anders dan "de volgende versie".

Dit komt door verschillende anciënniteit (niet iedereen weet alles van alle systemen/projecten, en die kennis wordt ook absoluut niet gedeeld), verschillen in disciplines (front-end, back-end, databaseontwerp, CI/CD, rapportages, testen), verschillen in ervaring, concurrentie qua projecten binnen een werk/opdrachtgever (een persoon kan zomaar worden weggetrokken voor een andere klus).

Ik denk zeker dat je dat kunt samenvatten als "chaos". En ik ben het ook eens met de uitspraak dat je aan code vaak kunt zien hoe communicatie tussen de bouwers loopt. Eilandjes? Spaghetti.

Herkenbaar. En overigens is echt teamwork ook niet altijd per se nodig. Maar als je gaat scrummen is dat wel de essentie van wat je moet gaan doen. Als het niet past, doe dan iets anders. Maar ga niet doen alsof je een team bent en alsof men samenwerkt. Dat is dan gewoon niet zo. Mijn irritatie zit hem inderdaad ook in het solistische ervan.

CodeCaster schreef op vrijdag 14 april 2023 @ 20:06:
Ik denk ook dat er binnen veel bedrijven niet de ruimte is om dan daadwerkelijke teams in te richten. Hoe zou jij dat aanpakken?

Ik vrees dat je gelijk hebt. Bij MKB-bedrijven is de cultuur er vaak ook een van de grote baas die de lijnen uitzet en de rest die volgt. (Althans, volgens onderzoek dat ik gelezen heb over bedrijfscultuur) In zo'n omgeving een autonoom team opzetten is een duivels karwij, tenzij de baas echt weet wat scrum is. Maar daar zou ik beginnen. De randvoorwaarden voor een autonoom team met de vrijheid om zelf de aangegeven doelen in te vullen. Pas als dat er is kan je gaan beginnen met de werknemers. Die moeten zorgvuldig geselecteerd worden. Niet op kennis, maar op bereidheid om samen te werken in een team. De rest kan eventueel nog geleerd worden dan wel worden ingepast als SME's die geen onderdeel zijn van het team. Teamwork vereist echt een bepaalde mindset.

[RagingPenguin]

ocf81 schreef op vrijdag 14 april 2023 @ 20:01:
[...]

Sorry, maar dat is gewoon geen scrum. Je bent dan bezig om het team om zeep te helpen om zo de manager tevreden te stellen. Dat kan prima werken voor applicaties zonder complexiteit, maar dat is dus expliciet geen teamwork. En wat ik een team noem is gewoon een textbook definitie uit de organisatiepsychologie, en geen een of ander uit de lucht gegrepen idee.

Sorry, maar dit is toch wel meer jouw hele exteme interpretatie van een definitie. Zowel "doel" als "onderlinge afhandelijkheden" zijn best losse termen, die voor een development team op veel meer kunnen slaan dan een "ticket". Ik werk in een Big Tech met ruim duizend developers op een product (en in een mono-repro), en dit zga wij werken:

Caelorum schreef op vrijdag 14 april 2023 @ 19:54:
@ocf81 afhankelijkheid van elkaars werk is een plannings en architectuurissue. Zo heb ik ook in een scrum team gewerkt waar we de afhankelijkheid juist over meerdere sprints heen trokken en niet in een sprint. Daarmee borg je namelijk voorspelbaarheid en continuïteit. Elke ontwikkelaar kom gewoon plots uitvallen zonder een planningsissue te creëren. Werk werd netjes opgedeeld en verspreid over sprints zodat er geen of nauwelijk afhankelijkheid was van elkaars werk. Werk en voortgang werd netjes bij de items en in git vastgelegd, juist zodat we gezamenlijk de commitment konden maken op het op te leveren werk en elkaar konden helpen/controleren en voorspelbaar konden leveren aan het bedrijf.

ocf81 schreef op vrijdag 14 april 2023 @ 19:56:
Soms wel inderdaad. Maar als je dan samen moet werken aan een feature moet je wel ervoor zorgen dat je werk op erlkaar aansluit. Dat gaat toch wel erg vaak fout bij het maken van software. Je ziet dat ook vaak als de stront aan de knikker is. Op zulke momenten zullen de werkgroepen die teams worden genoemd door de mand vallen.

Als je moeite hebt om werk van verschillende developers op elkaar aan te laten sluiten dan heb je waarschijnlijk het probleem dat of de requirements of de architectuur niet helder is geformuleerd en je te veel ad hoc interpretaties maakt. Dat kan je inderdaad 'oplossen' door geen parallelle ontwikkeling te doen waarin je onafhankelijk verschillende keuzes kan maken, maar ik denk toch dat je verder komt om beter als een team samen te werken aan je fundamentele processen.

[ocf81]

Caelorum schreef op vrijdag 14 april 2023 @ 20:09:
[...]

Welke manager heb jij het over?

Dat verschilt natuurlijk per bedrijf. Bij een MKB-bedrijf zal dat de directeur zin of degene die softwareontwikkeling in zijn managementportefeuille heeft. Bij grote bedrijven meestal het afdelingshoofd dat zijn doorgaans top-down geformuleerde doelenlijstje heeft.

Caelorum schreef op vrijdag 14 april 2023 @ 20:09:
Misschien dat je nog geen tijd hebt gehad om op deze reactie te reageren dus
[...]

Dasr wil ik wel een antwoord op :-) als je zegt nee, kunnen we scrum wel overboord gooien denk ik. En zo ja, dan wil ik wel weten waarom dat team waar ik in heb gewerkt geen team is.

Als een team beter werkt door onderling op te delen, dan kan dat de oplossing zijn. Wel moet je rekening houden met het feit dat dan de teamdynamiek verandert en dat expertise kan missen. Bij een echt eerlijke introspectie zal dat zeker ook een rol moeten spelen.