dec
30
2008

Xrump

Na enkele jaren ervaring met agile software projecten heb ik me maar weer eens verdiept in het Agile manifesto en vervolgens specifiek in de details van XP en Scrum, de meest bekende agile methodologiën. Het viel me op dat er vanuit beide ‘kampen’ toenadering gezocht wordt. Op zich ook een logische keuze, aangezien XP zich van origine meer richt op de technische practices om tot een goed eindresultaat te komen en Scrum zich meer op de processen die een team in staat zouden moeten stellen om een goed eindresultaat op te leveren. Maar dat terzijde.

Ik heb gemerkt dat het in de praktijk best een uitdaging is om een aantal van de practices (b.v. TDD, Pair Programming) gaande te houden of zelfs te starten. Dit zijn voor veel ontwikkelaars nieuwe manieren van werken, die eerst een investering kosten voordat ze voordelen beginnen op te leveren. Daarom is het dan ook nodig dat iedereen die eraan mee moet gaan werken, bereid is om die investering te doen.

Daarvoor is het nodig dat iedereen in het team ze kent, weet waarom ze werken en bereid is om ze een eerlijke kans te geven. Helaas werkt het invoeren van slechts enkele practices waar overeenstemming over is niet zo goed, omdat ze op elkaar ingrijpen. Om die selectie te maken, moet je dan ook eerst goed begrijpen hoe ze op elkaar inwerken. Beter is om ze goed door te nemen met het hele team, te bespreken hoe ze bijdragen aan het eindresultaat en met zijn allen te besluiten om ervoor te gaan.

Belangrijk daarbij is dat alle bezwaren serieus genomen worden en er een unaniem besluit genomen wordt dat iedereen het een kans gaat geven, minstens voor een aantal maanden. Een expliciet review-moment met een aantal objectieve criteria om te beoordelen of de uitwerking positief is, kan de laatste sceptici over te streep trekken, omdat er zo ook voor hun gevoel niet iets in gang gezet wordt, dat later niet meer gestopt kan worden.

Overigens is het zeker ook zo dat voor een aantal zaken medewerking van management en klant nodig is. Soms is het dan nodig om bepaalde documenten op te leveren (fixed urenschatting, volledig functioneel ontwerp, work breakdown), die voor agile projecten niet van belang of niet fixed verondersteld worden. Hierbij is het het beste om ze zo goed mogelijk uit te onderhandelen.

Als klant en (hoger) management te overtuigen zijn om het een goede kans te geven, dan is dat de beste uitkomst natuurlijk. Goed belichten van de te verwachten voordelen (betere aansturing op resultaat, betere kwaliteit, hogere productiviteit) en het zoveel mogelijk wegnemen van de zorgen en (nogmaals) het afspreken van een bepaalde termijn kan hierbij helpen. Een duidelijk mindere uitgangspositie, maar soms het best haalbare, is het maken van duidelijke afspraken over ‘deliverables’, maar niet over de werkwijze waarop die geproduceerd worden. Zo is een gedetailleerd functioneel ontwerp vaak later in het project redelijk eenvoudig te produceren uit de reeds geproduceerde code en zelfs beter van kwaliteit dan dat men begint in het luchtledige te modelleren en documenten te schrijven (zoals in watervalprocessen).

Uiteraard ben ik geïnteresseerd naar ervaringen van anderen hiermee, dus reacties worden gewaardeerd. Je kunt het ook in-persoon doen op één van de AltDotNetherlands bijeenkomsten. Daar vind je een aantal ontwikkelaars, allemaal geinteresseerd in .NET, open source projecten en agile projecten. Surf even naar http://www.altdotnet.nl en je vindt daar meer info. Kom gewoon eens langs als je geïnteresseerd bent en daar ook iets mee doet of wilt doen.

Geschreven door Rick | Tags: , |

Reageren? - Geef een reactie »

Rss feed voor commentaar op deze post. TrackBack URL

Geef een reactie

Powered by WordPress | Aeros Theme | TheBuckmaker.com WordPress Themes

Better Tag Cloud