Tag boeken
Beter testen in de Agile praktijk
Een twee weken durende Sprint is te kort voor het opstellen van gedetailleerde testplannen, en wie de testwerkzaamheden bewaart voor de laatste fase van de Sprint, komt onvermijdelijk in tijdnood. Hoe kan het beter? Dat antwoord wordt gegeven aan de hand van twintig praktijkcases in De karakteristieken van een modern testproces.
Leren leren op het werk
De mens is een lerend wezen. Wie zijn ogen ervoor openhoudt, ziet dat we haast elke dag wel een nieuw inzicht opdoen. Maar zodra men aan het werk gaat, lijkt een groot deel van de mensen die lerende houding thuis te laten. Sterker nog, goedbedoelde leerinitiatieven worden van tijd tot tijd zelfs met vijandigheid begroet. Waarom? Zijn we toch niet zo lerend als je op voorhand zou denken?
De vraag achter de vraag ontdekken
Requirements engineering is… moeilijk. Heel moeilijk. Het achterhalen van de systeemvereisten vraagt een enorme inspanning van requirementsanalisten. Het op te lossen probleem is immers altijd vager, minder gedefinieerd dan de absolute precisie die software verlangt. Analisten moeten belanghebbenden de juiste vragen weten te stellen om een vertaalslag te kunnen maken van business naar IT. Gelukkig hoeven ze dat niet alleen te doen. Handboek requirements van Nicole de Swart is een onmisbare gids in dit proces.
Aantekeningen over requirements - deel 2
Het opstellen van de juiste requirements is één van de moeilijkste onderdelen van softwareontwikkeling. In een eerdere blog beschreef ik de eerste acht lessen die Karl Wiegers of dit onderwerp formuleerde in Software Development Pearls. In deze blog volgen de tweede acht.
Aantekeningen over requirements - deel 1
Het moeilijkste onderdeel van softwareontwikkelen is niet het juist bouwen, maar het juiste bouwen. Vaak zwoegen programmeurs dagenlang op hun code en worstelen testers zich door het resultaat heen, om er pas helemaal op het eind van de ontwikkelcyclus achter te komen dat er iets is gebouwd waar eindgebruikers niet helemaal (of: helemaal niet!) op zaten te wachten. Het scheppen van een juist beeld van wat er gemaakt moet worden is misschien wel de belangrijkste stap in het ontwikkelen van software - en niet zelden de minst ontwikkelde.
Waarom ik een stapje terug doe
Het is het eind van het jaar, en dat is altijd een mooi moment om te reflecteren. - Een nog mooier moment, bedoel ik, want reflecteren doe ik aan de lopende band - onder andere middels mijn blogs. Het afgelopen jaar heb ik elke week twee blogs geschreven over alles wat mij interesseert aan softwareontwikkeling, en dat heb ik met veel plezier gedaan. Het komend jaar doe ik daarom logischerwijs een stapje terug en ga één keer per week bloggen.
De beste boeken over software ontwikkeling die ik in 2022 las
Eindejaarslijstjestijd! Net als vorig jaar en het jaar daarvoor heb ik dit jaar weer enkele fantastische boeken over softwareontwikkeling mogen lezen. Dit waren mijn vijf favorieten - en vijf eervolle vermeldingen.
Test third party code
Het updaten van third party code is net zozeer een risicovolle onderneming als het niet updaten ervan. In beide gevallen loop je kans op de introductie van bugs. Er is een uitweg uit dat probleem. En die uitweg is - zoals meestal in softwareontwikkeling - testen, testen, testen.
Van rader in het geheel naar bron van talent
Hoe ziet een bedrijf haar personeel? Een hint van een antwoord zit ‘m in de daaraan toegewijde afdeling: human resource management. Personeel is een resource, een hulpbron - net als het IT-systeem, maar dan menselijk - die gemanaged moet worden. Die metafoor heeft enkele interessante consequenties, die inderdaad regelmatig haar uitwerking vinden in de praktijk: medewerkers zijn raderen in het geheel, ze moeten op hun prestaties beoordeeld worden en kunnen eenvoudig vervangen worden wanneer ze een negatieve impact hebben op dat geheel. Die zienswijze is hopeloos achterhaald, betoogt Rob van den Berg in Futureproof talentmanagement.
Pull requests als documentatie
Hoe vaak denk je na over de titel en omschrijving van je pull request? Als je een beetje op mij lijkt, dan is het antwoord: veel te weinig. Het goede nieuws is: je hoeft er niet over na te denken, want dat hebben de vriendelijke ontwikkelaars van Google al voor je gedaan. Onlangs las ik hun Code Review Developer Guide door, en vond daar een schat aan informatie.