‘Kun je Agile ook toepassen in een erp-implementatie?’ is een veel gestelde vraag aan mij nadat ik een presentatie over agile heb gegeven. Yes, you can. De ‘out-of-the-box’ functionaliteit van het pakket fungeert min of meer als de stabiele set aan unit- en integratietests: de basiswerking van het systeem is gewaarborgd. Vervolgens kan er iteratief ontwikkeld worden aan de nieuwe functionaliteit. Dit kan ook bij grotere erp-implementaties toegepast worden.
Veelal wordt een erp-implementatie vanuit het traditionele V-model ingestoken: in een ontwerpfase worden alle noodzakelijke aanpassingen aan het standaard systeem vastgelegd. Vervolgens wordt in een of meerdere releases dit ontwikkeld, getest en in productie genomen. Wat echter inherent is aan deze aanpak, is dat in de testfases veel bevindingen worden geconstateerd die betrekking hebben op het ontwerp of de bouw en dus met terugwerkende kracht hersteld moeten worden. Dat is relatief duur. Daarnaast gebeurt het ook frequent dat de gebruikers het systeem niet kunnen of willen accepteren omdat de geleverde functionaliteit niet de gewenste functionaliteit is.
Bij een agile aanpak van een erp-implementatie kun je diverse agile practices toepassen om bovenstaande problematiek te tackelen. De eerste stap in het project is het opdelen van iedere release in korte iteraties. Binnen de iteraties kan zowel ontworpen, geconfigureerd, getest als geaccepteerd worden. Meerdere iteraties vormen dan samen een release. Om de goede uitgangssituatie voor de iteraties te creëren kan er voorafgaand aan de iteratie al wat voorwerk verricht worden door middel van protytyping van het erp-systeem, bijvoorbeeld in een sandbox omgeving. Daarmee kan getoetst worden hoe de beoogde functionaliteit werkt, en kan de klant al de eerste feedback geven. Het ontwerp hoeft echter nog geen technische uitwerking te bevatten, dat wordt binnen de iteraties gedaan.
Bij het opdelen in iteraties hoort ook het indelen in multidisciplinaire teams: ieder team krijgt een of meerdere bedrijfsprocessen onder zijn hoede en is verantwoordelijk voor de realisatie ervan tot en met de productieomgeving. In ieder team zijn minimaal de rollen business analist, ontwerper, ontwikkelaar, tester en gebruiker verdeeld. Een teamlid kan een of meerdere rollen invullen, gebaseerd op zijn kennis, ervaring en competenties. Op deze manier kunnen beslissingen altijd door alle disciplines beoordeeld worden en dit voorkomt dure herstelwerkzaamheden. De gebruiker kan een apart lid zijn wat vanuit de gebruikersorganisatie (deels) is vrijgesteld voor het medebeslissen in het team.
De in de agile werkwijze bekende korte feedback loops kunnen ook bij een erp-systeem van toepassing zijn binnen de iteratie: het configureren kan in kleine onderdelen gebeuren en gedeployed worden. De tester kan dit meteen – al dan niet geautomatiseerd – testen en vervolgens kan de gebruiker er direct naar kijken en het beoordelen. Dit kan dan op fijnmaziger niveau dan voorafgaand aan de iteratie en niet vanuit de zandbakomgeving, maar vanuit de ontwikkel- of testomgeving.
De interactie met de klant kan uiteraard ook agile ingevuld worden: hij is verantwoordelijk voor het juist prioriteren van de verschillende functionaliteit die in de iteratie ontwikkeld worden. Wanneer er meerdere stakeholders zijn die allemaal hun invloed willen hebben op de scope van de iteratie, dan zal deze 'Product Owner' separate sessies moeten beleggen waarin de belangen worden afgewogen. Hiermee moet het configuratieteam niet belast worden.
De iteratieve agile werkwijze zorgt voor meer transparantie en zekerheid omtrent de waarde van de geleverde functionaliteit. Waar grootschalige erp-implementaties nog al eens verzanden in mist en veel correctiewerk, kan de agile aanpak fors bijdragen aan betere resultaten. De klassieke bij-effecten van traditionele softwareontwikkeling kunnen dus ook in deze context sterk genivelleerd worden.
Mee eens.
Voor complexere releases wil ik wel opmerken dat intensief geautomatiseerd regressietesten op de release bijna onontkoombaar is.
De kans dat een kleine aanpassing in de laatste iteratie bestaande functionaliteit breekt is niet ondenkbaar. In kleine eenvoudige releases wordt dat snel opgemerkt, maar in complexere releases is de kans aanwezig dat dat over het hoofd wordt gezien, met als gevolg dat deze ‘fout’ pas in de eindfase aan het licht komt en de kosten van herstel wederom de pan uit rijzen.
Ander punt van aandacht is om na te gaan in hoeverre de non-functional requirements (lees: performance) met Agile en prototyping te testen zijn.
Henk-Jan,
Juist in die complexere situaties moet je dus goed blijven testen. De hele agile aanpak draait er juist om dat je de software in iedere iteratie test op alle eindcriteria. Dus t/m acceptatietest. In de laatste iteratie voor releasing vind je dus alleen de “dure” fouten uit die laatste iteratie, en niet die van maanden daarvoor. Als jij stelt dat je pas in een laat stadium fouten vindt, dan heb je dus in de stadia daarvoor niet voldoende getest.
Idem dito met de non-functionele requirements als performance, security, onderhoudbaarheid etc. Als je die integraal meeneemt in je ontwikkelafspraken van de iteratie, dan kom je achteraf niet tot vervelende ontdekkingen.
Als je mijn comment nog eens leest, zie je dat we het eens zijn.