Naar Inhoud



De Agile Software Development filosofie

door Andre Heijstek

Ik ben de laatste maanden intensief bezig geweest met het boek Agile Software Development – The Cooperative Game van Alistair Cockburn. Vaak lees ik boeken veel sneller maar dit boek dwong me steeds om te reflecteren en gaf me continu ideeën voor toepassingen. Maar nu is het boek uit, en dus is het tijd voor een bespreking. In deze eerste blog de filosofische basis.

De Agile Software Development filosofie

Deel 0 - Wat kun je weten, communiceren en documenteren

Je kunt niet alles perfect weten

Deel 0 van het boek begint filosofisch: “wat kunnen we eigenlijk weten?”, wat is “knowable”, en wat kan je wel of niet communiceren en documenteren? Alistair’s antwoord is dat perfect weten en communiceren niet mogelijk is, maar dat dit niet betekent dat we helemaal niets meer kunnen doen. Het geeft tegelijkertijd wel aan dat we niet onze ‘ziel-en-zaligheid’ moeten koppelen aan een bepaalde methode of document, want het zal altijd beperkt zijn.

Shu-Ha-Ri

Het beschrijven en aanleren van methoden kan het beste gebeuren aan de hand van de Shu-Ha-Ri aanpak vanuit Aikido. In de Shu-fase, kopieert de leerling exact het voorbeeld van de leraar. De leraar geeft eenduidige instructies, alsof er maar één goede methode bestaat. In de Ha-fase neemt de leerling afstand van de leraar, reflecteert op het geleerde en komt zodoende tot een dieper begrip van het geleerde. Hier wordt duidelijk wat de beperkingen van de methoden zijn, en wordt helder dat er meerdere goede methoden zijn om een taak uit te voeren. Tenslotte in de Ri-fase gaat de leerling boven het geleerde uit. De leerling wordt ‘practitioner’. De leerling volgt de methode niet meer, maar weet intuïtief wat de juiste werkwijze is in iedere specifieke situatie.

Ik herken dat vanuit mijn eigen praktijk. Als ik een training geef, bijvoorbeeld mijn “Intro Agile/Scrum” dan laat ik heel veel weg, houd ik het heel simpel en beschrijf ik meestal maar 1 manier om het werk te doen. Terwijl ik, als ik als consultant een afdeling of project begeleid, veel meer variatie aangeef. “Je zou het zo kunnen doen, maar ook anders, probeer eens wat je het beste bevalt”.

Bijlage B - Software ontwikkeling volgens Descartes, Marx, Heidegger en Wittgenstein

Bijlage B wordt echt filosofisch, in een bespreking van het werk van Pelle Ehn wordt software ontwikkeling besproken in termen van het werk van achtereenvolgens Descartes, Marx, Heideggeren Wittgenstein.

Descartes, Marx en Heidegger

Software ontwikkeling volgens Descartes bouwt een zo exact mogelijk model van de externe werkelijkheid. Als we werken in de stijl van Marx stellen we allereerst de vraag naar wie profijt gaat hebben van het te bouwen systeem. In de lijn van Heidegger is het systeem een tool dat de gebruiker zo min mogelijk moet zien, maar dat hem zoveel mogelijk moet ondersteunen. Wittgenstein is bijna tegengesteld aan Descartes. De bouw van een design is een taalspel dat zich gedurende het ontwerpen ontwikkelt, er worden steeds nieuwe woorden/begrippen aan de taal toegevoegd.

Cockburn ziet software ontwikkeling als een spel (a cooperative game of invention and cooperation), en volgt daarin dus de lijn van Wittgenstein.

Wittgenstein

Wittgenstein ziet de taal die we gebruiken om een design of requirements vast te leggen als ‘reminders for our reflections’. Die uitspraak doet me sterk denken aan de definitie van een ‘user story‘; ook dat is geen definitieve beschrijving van het systeem maar een verhaaltje dat ons helpt herinneren aan de discussie die we daarover hadden met de gebruikers. Ook het gebruik van metaforen past prima in deze denkwijze.

(on)Mogelijkheden

Een prachtig voorbeeld van de (on)mogelijkheden van taal komt ook weer van Wittgenstein: “vergelijk eens wat je kan weten en zeggen over (1) hoe hoog de Mont Blanc is, (2) hoe we het woord ‘spel’ gebruiken en (3) hoe een klarinet klinkt”. Zeker dat laatste valt niet of nauwelijks in woorden uit te drukken! Zo zijn er ook veel aspecten van een ontwerp die niet of nauwelijks te documenteren zijn, zeker niet voordat er een concrete vraag gesteld wordt over hoe een systeem uitgebreid zou kunnen worden.

Volgende blog

De volgende blog bekijkt software ontwikkeling als game, in plaats van als ‘engineering’.

Reacties (0 totaal)

Er zijn nog geen reacties

Plaats een Reactie (Tijdelijk buiten gebruik)

Let op: Uw reactie wordt gepubliceerd. Voor privé-reacties kunt u rechtstreeks mailen met de auteur. Voor contact mogelijkheden bekijk het auteur profiel van Andre Heijstek

(Verplicht)

(Verplicht, wordt niet gepubliceerd)

Over de Auteur

Andre Heijstek André heeft de laatste 20 jaar in diverse functies binnen software ontwikkeling gewerkt, heeft de laatste jaren een passie voor Agile en Scrum ontwikkeld en is gecertificeerd CMMI Trainer en Lead Appraiser en Scrum Master.
Lees Meer in Profiel

Deel dit Artikel

Artikelen door Andre Heijstek

Andre Heijstek op Twitter

ImproveFocus: RT @andreheijstek: Diverse opleidingen toegevoegd op mijn website. Met name diverse opleidingen rond #verandermanagement #organiseren ht ...

ImproveFocus: My week on twitter: 2 new followers. Via: http://t.co/MX7tKxXS

ImproveFocus: Interesse in een #Scrum training? 30 en 31 oktober van 16:00 - 21:30. Laat even weten als het wat voor je is!

ImproveFocus: RT @jurgenappelo: Published... Nonviolent Communication (Stop It!) http://t.co/g2txBkYe #NVC #change

ImproveFocus: RT @NielsTalens: Dear people outside the team:Velocity is not for you. It is a tool for us to elim. waste. We use it to keep planning ju ...