XrumP

 
12 december 2008

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 technieken 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; komende maandag de 15de is de tweede ALT.Netherlands meeting weer in Amsterdam. Vorige keer waren we met 6 enthousiastelingen. 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.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Development

Tags: , , ,


Reacties (6)

  • Rick schreef:

    Ter verduidelijking wat betreft het ‘contact zoeken’ voor het langskomen. Er vind geen selectie plaats; het gaat erom dat iemand toch even zal moeten weten waar we te vinden zijn en dat we daar niet ineens met veel teveel mensen in een cafe staat te dringen om iets te kunnen zien.

    Geplaatst op 15 december 2008 om 13:18 Permalink

  • My bad! Ik heb de datum inmiddels aangepast. Bedankt voor de opmerkzaamheid. :-) Gaat dus wel om maandag 15 dec..

    Geplaatst op 14 december 2008 om 18:31 Permalink

  • Gerard Braad schreef:

    Volgens mij hebben Rick en ik beide naar Januari 2009 gekeken.

    Geplaatst op 12 december 2008 om 21:34 Permalink

  • Arjan Zuidhof schreef:

    Leuk artikel, en inderdaad zit de weg naar Agile development vol met beren en leeuwen. Misschien een idee voor een alt.net avond?

    en nog even de moeite van het vermelden waard dat het de 15e is i.p.v. de 12e :-)

    Geplaatst op 12 december 2008 om 21:20 Permalink

  • Rick schreef:

    Ok, top, leuk dat je erbij bent. En ja, op zich wel handig die lokatie, maar ik wil toch eigenlijk dat mensen even contact zoeken voordat ze komen. Maar goed, dat staat er dus nu ook bij. :-)

    Geplaatst op 12 december 2008 om 19:32 Permalink

  • Gerard Braad schreef:

    Ik hoop van de partij te kunnen zijn op de 12de. Misschien wel handig om te melden dat het in
    Café Americain (Leidsekade, Amsterdam) zal plaatsvinden.

    Geplaatst op 12 december 2008 om 19:25 Permalink