Tag agile ontwikkeling
Bewuste technische schuld
Is technische schuld erg? Niet per se, zolang de keuze voor technische schuld maar een bewuste is. Als het team duidelijk maakt dat de oplossingsrichting technische schuld met zich meebrengt en afdwingt dat er op middellange termijn tijd wordt vrijgemaakt om die op te ruimen, hoeft die schuld geen probleem op te leveren. Integendeel: dankzij die schuld zijn we in staat om op korte termijn - vóór de deadline - waarde te leveren.
Agile zijn, niet Agile doen
Heeft Agile gefaald? Of heeft Agile nooit écht een voet aan de grond gekregen? In Clean Agile pleit Robert “Uncle Bob” Martin voor dat laatste. Het succes van Agile is zowel een vloek als een zegen geweest. Een zegen, omdat het het inefficiënte Waterval heeft verdreven, maar een vloek omdat de kerngedachte achter Agile zo vaak verkeerd begrepen is dat deze geheel verloren dreigt te gaan. Clean Agile is zijn poging de vele misverstanden recht te zetten.
Horizontale of verticale PBI's?
Een risico van horizontaal ontwikkelen is dat je veel tijd besteedt aan de back-end, om er vervolgens bij de implementatie van de front-end achter te komen dat je iets over het hoofd hebt gezien. Met als gevolg dat je alsnog verticaal aan het ontwikkelen slaat. Dat is niet alleen irritant, het is ook ontzettend inefficiënt!
Iteratieve verfijning
Dat software ontwikkelen - vandaag de dag in elk geval - een iteratief proces is, is een plattitude. Dat ook de voorbereidingswerkzaamheden van programmeren iteratief kunnen (of moeten?) worden vormgegeven, is iets wat ik misschien wel wist, maar me nooit helemaal beseft heb. Het interessante van Scrum (en van softwareontwikkeling in het algemeen) is dat je het jarenlang kunt doen, en toch steeds opnieuw best en better practices kunt ontdekken - of herontdekken.
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.
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.
De kwestie autorisatie
Onze Product Owner ging anderhalve week ondergronds met onze informatie-analist om een autorisatiematrix uit te tekenen. Toen hij het eindresultaat eindelijk presenteerde aan het team, leidde hij zijn verhaal in met de woorden: “We gaan jullie meenemen.” Dat was een slecht teken.
Incrementele versus iteratieve ontwikkeling
Als ik geen zin heb om over software ontwikkeling te lezen tijdens mijn ontbijt, zet ik een filmpje op YouTube op. Laatst keek ik er een van software architect George Fairbanks over de bijdrage van softwareontwikkelprocessen aan (het wegwerken van) technische schuld. Ik at die ochtend, als ik me het goed herinner, afbakbroodjes met jam. Het was dus in meerdere opzichten een prima begin van de dag.
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?