samenwerking
Pairing en theoriebouwen
Waarom zou je aan pair programming doen? Dan doen twee mensen het werk van één, dat is toch vreselijk inefficiënt! – Die zienswijze veronderstelt dat het doel van programmeren is om een werkend programma te produceren. Maar een werkend programma maakt nog geen goede software. Goede software is soft: eenvoudig aan te passen naar veranderende eisen en wensen.
De vergeten tester
Testen is cruciaal voor softwarekwaliteit. En toch, toen ik de kans kreeg een nieuw agile softwareteam samen te stellen, “vergat” ik de tester. Hoe verklaren we deze paradox? Hoe kan een tester tegelijkertijd zó belangrijk en toch ongewenst zijn?
Voorbeeldarchitectuur
Een collega in een ander team is bezig een oude applicatie te vernieuwen. Hij vroeg een andere senior en ik om zijn opzetje voor een nieuwe structuur te reviewen. Zelf had ik, merkte ik, geen sterke meningen over de code – of liever: de implementatie. Zit er een goed vangnet omheen? Dan geloof ik het wel. Ik had tegen het eind van de sessie één vraag: “Is de complexiteit van de code in verhouding met de complexiteit van het probleem?”
Bug, hoge prio (een retrospectief)
Ze zeggen, elk probleem is ook een communicatieprobleem. Dit is een communicatieprobleem. De ontwikkelaar communiceert niet. De tester communiceert niet. De ops’er communiceert niet. De enige die communiceert is de ontwikkelaar die, vanuit het bevindingenoverleg, trouw de bugs meldt. – Maar: hoe communiceert de teamleider?
Hoe commit messages ons helpen samenwerken
Wie met PR’s werkt, werkt met elk groen vinkje zijn administratie bij: die ontwikkelaar heeft de code geschreven en deze ontwikkelaar heeft die code gereviewd. De rolverdeling wordt automatisch in een systeem vastgelegd. Zoiets hadden wij niet – niet automatisch.
PR's vs. pairs
Je maakt een branch, je wijzigt de code. Je maakt een pull request (PR) aan om deze te integreren in de main branch. Voordat die code toegestaan wordt, moet deze eerst door een collega worden bekeken. Pas als deze zijn zegening heeft gegeven, mag de code worden geïntegreerd. – Vanwaar deze opzet?
De edele kunst van het pull request, Redux
Het praatje dat ik in 2024 op T-DOSE gaf, The art of the pull request, is onlangs op YouTube verschenen. Gezien mijn houding naar pull requests de afgelopen twee jaar is veranderd, leek het me een mooie gelegenheid om die ideeën nog eens te overdenken.
Twee doelen van een ontwikkelteam
Een softwareontwikkelteam heeft, in abstracto, twee doelen: vernieuwing en veiligheid. Een team bestaat daarom, zou je kunnen stellen, uit twee delen: ontwikkelaars en testers. Deze conceptualisatie van een ontwikkelteam is het gevolg van een vorm van reductionisme. Maar een team valt niet te reduceren tot haar samenstellende delen. Ze bestaat uit haar samenstellende delen plus hun vormen van interactie.
Een tester of praten
Wij hebben geen tester in ons team. Niet omdat ik niet van testers hou (ik hou van testers), maar omdat het verkeerd gebruik van een tester dysfunctionele patronen in een team verbergt en in stand houdt.
Behoefte aan een testlane
Als we met z’n allen met één ding bezig zijn, dan is onmiddellijk, voor iedereen, zichtbaar wat er al getest is en wat niet. Een testlane is een lapmiddel voor het eigenlijke probleem: dat we onvoldoende samenwerken. Daardoor weten we niet wie wat al heeft gedaan. Dáárom heb je behoefte aan een middel om daar inzicht in te verkrijgen.