Tag Communicatie
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 DRY? Waarom DAMP?
Productiecode optimaliseer je voor onderhoudbaarheid; testcode voor leesbaarheid. Waarom? Omdat de context van productiecode en testcode verschilt. Beide dienen een ander doel, wat verschillende eisen aan de code stelt. Ze opereren in verschillende sferen, zogezegd.
Efficiënter overleg dankzij Loop-componenten
Hé jij. Ja, jij. Gebruik je Microsoft Teams voor het gros van de communicatie op je werk? Ja? - Open dan eens een chat met iemand, een collega waar je vaak nauw mee samenwerkt. Onderaan, onder die balk waar je je bericht in tikt, daar zie je een icoontje staan - tussen die van de bijlagen en de emoticons in. - Zie je ’m? Hij lijkt een beetje op een mislukt apenstaartje. Dat is nou het icoon om een Loop-component in die chat te smijten.
Tests zijn specs
Kleine (of liever: te kleine) tests geven weinig informatie over de werking van het systeem. Ze verlangen van de lezer om op de hoogte te zijn van implementatiedetails, en verliezen zo het grote geheel uit het zicht. Voor grotere unittests gaat die beperking niet op. Zulke tests doen geen aannames over de interne werking van het systeem. Ze beschrijven slechts de buitenkant ervan: wat de gebruiker - hoe we die dan ook mogen definiëren - invoert en wat deze terugkrijgt. Het gevolg daarvan is dat je tests leesbaar worden voor niet-ontwikkelaars.
In godsnaam, neem de tijd om je Sprint Review voor te bereiden
Een Sprint Review is geen one man show. (Al wordt het - terecht - “het feestje van de Product Owner” genoemd.) Een Sprint Review is geen PowerPoint-presentatie. (Al kan en mag er gerust PowerPoint gebruikt worden tijdens de Sprint Review.) Een Sprint Review is geen demo van de nieuwste functionaliteit. (Al wordt de nieuwste functionaliteit wel gedemonstreerd.) Een Sprint Review is een teamprestatie - maar niet alleen het team is aan het woord. Een Sprint Review is een gesprek - en in een gesprek vindt altijd plaats tussen meer mensen.
Een presentje voor presenters
Lieve collega’s, bedankt voor alle toffe presentaties die jullie (met een beetje druk van mijn kant) hebben willen verzorgen het afgelopen jaar, ik kan niet in woorden uitdrukken hoe zeer ik jullie waardeer! Ik hoop dat dit wijntje iets van die dankbaarheid over kan brengen. De volgende keer zal die blijk van waarderig een stuk minder lang op zich laten wachten, beloofd!
Zes dingen die ik leerde op Techorama
Een tijd geleden bezocht ik softwareconferentie Techorama in Utrecht. Ik hoorde een boel nieuwe ideeën, werd gesterkt in enkele van mijn al bestaande overtuigingen, en uitgedaagd sommige ingesleten gewoonten te herzien. Uit mijn stapel aantekeningen destilleer ik zes inzichten die ik alleen al de eerste dag opdeed.
Collegiale documentatie
Ik ken geen enkele ontwikkelaar die het leuk vindt om documentatie te schrijven - ik ook niet - en dat is omdat goede documentatie schrijven moeilijk is. Het is moeilijk, omdat je je vanuit een positie van iemand die snapt hoe iets werkt, je in moet leven in iemand die dat begrip nog niet heeft. Mijn belofte “even” documentatie te schrijven werd daarom al gauw “een uur” documentatie schrijven. Maar het resultaat is volgens mij wel de moeite waard, dus laten we er even (…een uur?) naar kijken.
Gedachten naar aanleiding van een PI-planning
Ik had onlangs het geluk aanwezig te mogen zijn bij een Program Increment-planning - kortweg: PI-planning. Het was de tweede die mijn werkgever ooit organiseerde, en de eerste waar ontwikkelaars bij aanschoven. Het was een hele ervaring. En ik zal in wat volgt kort reflecteren op die ervaring.