Tag Procesverbetering
Aantekeningen over continuous deployment
De grootste uitdaging in het omarmen van continuous deployment ligt niet in het technische aspect. Deployment pipelines zijn anno 2026 alomtegenwoordig, unittesting is (bij de meeste teams) niet meer optioneel, en feature flags zijn in hun simpelste vorm niet meer dan eenvoudige booleans. Om continuous deployment een succes te kunnen maken, zullen de mensen hun vertrouwde manieren van werken moeten herzien.
(Overpeinzingen)
Je zegt: het is een kennisprobleem. Daar ben ik het niet mee oneens. Maar volgens mij heb ’m dan nog niet helemaal. Het gebrek aan kennis is een symptoom van een dieper liggend probleem. Vraag je af: hoe kan het dat iemand na zoveel jaar ervaring deze code schrijft, en op deze manier ook?
Hoe heb je het volgehouden?
Software ontwikkelen is niet makkelijk, het is van zichzelf al niet makkelijk en het wordt nog moeilijker omdat je met mensen werkt en mensen zijn nooit makkelijk.
Testen: Een filosofisch retrospectief
Eerst programmeren de programmeurs, dan testen de testers: het komt niet vaak voor dat zo’n voor de hand liggend idee zoveel misvattingen herbergt. Welk aannames liggen ten grondslag aan dat idee? En wat gebeurt er wanneer we die aannames kritisch tegen het licht houden?
Waarom testen testers?
Tijdens een Retrospective gaf onze tester aan dat hij omkwam in het werk. Eigenlijk verbaasde niemand dat. Ons team bestaat uit vijf ontwikkelaars en één tester, en die ene tester is verantwoordelijk voor het schrijven van geautomatiseerde tests voor de code van al die vijf ontwikkelaars. Je kunt op je vingers natellen dat die situatie niet houdbaar is. – Dus wat te doen?
Testen: een retrospectief in vijf fasen
Het leek me zinvol om te reflecteren op de ontwikkeling die mijn team en ik door hebben gemaakt op het gebied van testen. Want – en dat is goed nieuws – de manier waarop we het testen van onze software aanvliegen is radicaal veranderd sinds ik begon als ontwikkelaar.
Drie kernwaarden
Onlangs beschreef ik hoe het formuleren van kernwaarden zou kunnen helpen in het verbeteren van het softwareontwikkelproces. Als oefening heb ik, voor mezelf, drie van zulke waarden geformuleerd, drie zaken die ik persoonlijk belangrijk vind wanneer ik software ontwikkel.
Formuleer je kernwaarden
Hoe ziet softwareontwikkeling er – volgens jou – idealiter uit? Hoe functioneert een ontwikkelteam op de toppen van z’n kunnen? Wat is de verhouding tot hun stakeholders en collega’s? Hoe ondersteunt het management daarin? – Als je dat plaatje eenmaal scherp hebt, wat kun je dan concluderen over de kernwaarden van waaruit je software ontwikkelt?
Doe je wel écht aan continuous integration?
Clare Sudbery stelde een goede vraag op GOTO Amsterdam: doe je écht aan continuous integration (CI), of denk je dat alleen maar? Dat roept de vraag op: wat is “echte” CI?
De tester als code reviewer
Mijn team heeft onze tester onlangs tot verplichte reviewer gemaakt voor elk pull request (PR). Hij heeft een heel specifieke opdracht – drie, eigenlijk: 1. Ga na of het PR unit- of integratietests bevat. Zo nee, keur het PR dan af. 2. Ga na of je de unit- en/of integratietests kunt begrijpen. Zo nee, keur het PR dan af. 3. Ga op basis van de unit- en/of integratietests na of de code werkt zoals bedoeld. Zo nee, keur het PR dan af. Pas als aan alle drie voorwaarden is voldaan, is het PR klaar om naar de main branch te mergen.