Tag samenwerking
De rol van user stories
Wie The Art of Agile Development van James Shore doorbladert, doet heel nieuwe opzichten op. Zijn hoofdstuk over stories (ook wel bekend als user stories) deed me wel opveren, in elk geval. Shores stelling - mening? inzicht? - is provocatief: een story moet op een index card passen. de volledige story zou dus uit niet meer dan een zin of een kreet hoeven bestaan.
Code reviews als leermiddel
Toen ik begon als softwareontwikkelaar, was ik eerlijk gezegd een beetje bang voor code reviews. Inmiddels zijn de rollen omgedraaid, en zijn mijn collega’s banger voor mijn code reviews dan ik voor die van hen. Feit is dat ik een stuk scheutiger ben met mijn opmerkingen dan mijn collega’s. Toch denk ik dat er in mijn commentaar maar weinig is om bang voor te zijn. Ik zie code reviews namelijk niet als middel en moment om kritiek te geven op andermans code. Of liever: niet alleen als middel en moment om kritiek te geven.
Zonde om weg te gooien?
Laatst kwam ik tijdens het refactoren een stuk code tegen dat alleen maar werd gebruikt in unittests. Dat maakt me erg verdrietig, en om dat verdriet niet te hoeven voelen, donderde ik dat stuk code weg zodat ik er nooit meer naar om zou hoeven kijken. Een collega van me maakte bezwaar toen hij mijn pull request bekeek. En, eerlijk is eerlijk, niet helemaal onterecht. Er was veel moeite in deze feature gestopt, zei hij. Was het niet zonde om deze code zonder omzien te verwijderen?
U vraagt, wij draaien
Een stakeholder zei laatst iets tijdens een Sprint Review wat me tegen het zere been stootte. Ze was nog niet zo lang aangesloten bij de ontwikkeling van de applicatie en gebruikte deze zelf alleen nog als pilot. We spraken over aansluiten van een nieuwe gebruikersgroep op onze applicatie. De stakeholder gaf aan dat het op korte termijn - anderhalve sprint - moest gebeuren, en somde daarna een lijst features op die tegen die tijd af moesten zijn, “anders heeft het geen zin.” Harde woorden, en dat voor iemand die nog maar net komt kijken!
Toevallige productieve ontmoetingen
Een collega van me omschreef de huidige, moderne functie van een kantoor als volgt: het faciliteren van toevallige productieve ontmoetingen. Ik viel bijna van mijn stoel toen ik dat hoorde (het was tijdens een borrel), zo’n mooie formulering vind ik het. Tegelijkertijd werpt het een licht op een gebeurtenis die voorheen zo alledaags en vanzelfsprekend was dat hij al die jaren aan mijn aandacht is ontsnapt: een collega tegen het lijf lopen bij de koffieautomaat.
Waarom we Developer Meet-ups organiseren
Sinds kort organiseren enkele enthousiaste collega’s en ik iets wat we een Developer Meet-up hebben genoemd. Dat is een informele bijeenkomst van geïnteresseerde softwareontwikkelaars binnen het bedrijf, die op een laagdrempelige manier ervaringen uitwisselen over een aan softwareonwtikkeling gerelateerd onderwerp. Waarom organiseren we Developer Meet-ups? In de intropraatjes dat ik als initiatiefnemer verzorg, onderscheid ik drie redenen.
Stap voor stap software testen
Software testen is een vak apart. Veel ontwikkelaars hebben wel een schetsmatige notie van hoe een goede test eruit dient te zien, maar ontberen een gedegen theoretisch fundament. Zulke ontwikkelaars zouden er goed aan doen om Essentials of Software Testing van Ralf Bierig, Stephen Brown, Edgar Galván en Joe Timoney te lezen.
De architect, het team en de business
Ik vind dat een softwarearchitect mee moet draaien in een ontwikkelteam. Mijn leiddingevende is daar minder van overtuigd. “Vind je dan ook dat een architect mee moet draaien met de business?” vroeg hij me tijdens een discussie - retorisch uiteraard. Maar toen ik erover nadacht, vroeg ik me af: waarom eigenlijk niet?