Tag verantwoordelijkheid
De ontdekking van strategische subdomeinen
Ik schreef één keer eerder over Domain-Driven Design - en in die blog gaf ik onmiddellijk toe niks van het onderwerp te weten. Precies daarom nam ik me voor om Learning Domain-Driven Design van Vlad Khononov op te pakken. En met succes, want al meteen in het eerste hoofdstuk leerde ik iets nieuws: het bestaan van strategische subdomeinen.
Incidentanalyse zonder schuldigen
Wat doet jouw team na een productieverstoring? En wat doet jouw team als een eindgebruiker een bug meldt? - Wat bij een grote bug? Wat bij een kleine? Neem je het ter kennisgeving aan, en ga je op dezelfde weg door? Ga je met vingers wijzen en mensen uitfoeteren voor hun nalatigheid? Of kijk je naar manieren waarop je de productieverstoring of bug in de toekomst kunt voorkomen? En waar kijk je dan naar - naar het individu, of het systeem?
Tevreden ontwikkelaars én stakeholders dankzij speelruimte
Dit is denk ik voor veel teams een herkenbare situatie: de ene Sprint verbranden jullie achttien effort points, de volgende twintig, de keer daarop vijftien. Wat is dan de capaciteit van het team? Hoe kun je voorspellen wat jullie de volgende Sprint gaan opleveren, als de capaciteit fluctueert van keer tot keer? Het antwoord is: dat kun je niet. Maar in The Art of Agile Development van James Shore vond ik hier een oplossing voor.
Wat je aanpakt weegt licht
De vloek van een goed functionerend team is dat de organisatie daarvan vindt: die kunnen dit en dat best erbij hebben. De zegening van een goed team is dat de organisatie daarin meestal wel een punt heeft. Dat gezegd hebbende, mijn team was niet blij toen we de opdracht in onze mik geschoven kregen om een bedrijfskritische legacy applicatie door te lichten. We hebben ons werk voor die applicatie lange tijd zo ver mogelijk naar achteren geschoven. Maar enkele Sprints terug was het dan toch zo ver. En eerlijk gezegd: het viel alleszins mee.
Twee sonnetten over software ontwikkelen
Stakeholder, u stijgt pas echt in achting / Als u - prijs de Heer voor dit geluk! - / Inziet wanneer niet de code de bug / Herbergt, maar uw eigen verwachting.
Blijven we dit ondersteunen?
Onze legacy-applicatie focust zich op de constructie van toetsen, niet op de afname. Om de afnameomgeving te kunnen bekijken, heeft de applicatie een integratiepunt met een externe tool. Maar de laatste tijd levert die functionaliteit vooral veel frustratie op. Problemen met de externe tool worden op onze applicatie geschoven, en het gedrag met de geïntegreerde versie is bij een grote load inconsistent met die van de externe tool. De klachten over de integratie vreten tijd van het ontwikkelteam, en zorgen bovendien voor frustraties over en weer naar de stakeholders.
Wie is verantwoordelijk voor jouw ontwikkeling?
Wie zijn vakinhoudelijke ontwikkeling afhankelijk maakt van zijn werkgever, zegt eigenlijk die ontwikkeling zelf niet zo belangrijk te vinden. Maar je persoonlijke ontwikkeling is wel belangrijk. Daarom is het essentieel dat je daar zelf de leiding in neemt. Als jij het niet belangrijk genoeg vindt om er tijd en geld in te steken, hoe kun je dan van je werkgever verwachten dat die dat wel doet?
Hoe technische schuld te monitoren én prioriteren
Software ontwikkelen is mensenwerk. Hoe goed de tooling tegenwoordig ook is, ze is niet meer dan een hulpmiddel voor ontwikkelaars om grip te krijgen op een codebase. De beste manier om technische schuld in beeld te krijgen, is dan ook niet door allerhande tools op je code los te laten, maar door erover te praten met je collega’s.
Schrijf PBI's - en doe het goed
Het is niemands favoriete klus: Product Backlog Items (PBI’s) aanmaken om de komende Sprints op te kunnen pakken. En toch, het is een onderdeel van je werk als ontwikkelaar. En een belangrijk onderdeel ook, want zonder goed opgezette PBI’s kan een team helemaal niets.