Toepassing van iteratieve ontwikkelmethode
5 dec 2012 - Remco Dijkxhoorn

Verschenen in OGh Visie december 2012
De iteratieve ontwikkelmethode Agile wordt in het algemeen toegepast in organisaties die object-georiƫnteerd werken op middleware platformen en software ontwikkelen op Java. Klassieke Oracle omgevingen worden niet snel geassocieerd met Agile. Toch kunnen organisaties die werken in deze omgevingen ook gebruik maken van deze manier van ontwikkelen.
Toepassing van iteratieve ontwikkelmethode

Toepassing van iteratieve ontwikkelmethode
Agile in klassieke Oracle-omgevingen

 

De iteratieve ontwikkelmethode Agile wordt in het algemeen toegepast in organisaties die object-georiënteerd werken op middleware platformen en software ontwikkelen op Java. Klassieke Oracle omgevingen worden niet snel geassocieerd met Agile. Tochkunnen organisaties die werken in deze omgevingen ook gebruik maken van dezemanier van ontwikkelen. Remco Dijkxhoorn, senior consultant bij Xenia legt uit hoe en waarom.

 

In klassieke Oracle omgevingen wordt vaak direct op de database gewerkt. Er wordt gebruik gemaakt van PL/SQL, APEX en Oracle Forms met pakketten als Oracle E-business Suite. Het IT-landschap is vaak complex en software in productie brengen niet eenvoudig. Dit soort omgevingen is niet erg flexibel. Hierdoor wordt software voornamelijk ontwikkeld via de traditionele watervalmethode waar van te voren planmatig het doel van de toepassing wordt vastgelegd en waarmee de business naar deIT-afdeling stapt. Deze IT-afdeling schrijft lange documenten en requirementsen alles wordt tot in detail vastgelegd. Dit zorgt ervoor dat je als organisatie maar beperkt kan inspelen op veranderingen in de markt en de time-to-market te wensen over laat.

 

Iteratief ontwikkelproces

Agile is een effectieve en flexibele methode die uitgaat van een iteratief ontwikkelproces (in de meeste gevallen de Scrum-methode), waarbij de betrokkenheid van ontwikkelaars en gebruikers groot is. Business en IT werken nauw samen om de projecten te realiseren. De methode focust zich op de realisatie van waarde (businessvalue). Flexibiliteit en voorspelbaarheid leiden tot een verkorte time-to-market, de kosten worden verlaagd en beter beheersbaar. De kort-cyclische manier van werken helpt bedrijven om sneller in te spelen op de klantbehoefte en de actualiteit.

 

Waarom Agile

Agile kan bedrijven helpen sneller in te spelen op veranderingen in de markt en in de klantbeleving. Dit vergt een continue her-prioritering, iets wat bij de watervalmethode niet mogelijk is omdat daar wordt vastgehoudenaan strakke procedures. Agile biedt duidelijke voordelen, maar vraagt wel een flinke verandering van de organisatie. Als je als bedrijf gewend bent om meteen strak, vooraf gedefinieerd plan ontwikkeltrajecten te starten met een duidelijk doel, vergt de Agile-methode een heel andere werkwijze. Alles wordt opgedeeld in ‘sprints’ en van sprint naar sprint ontstaat er een eindproduct. Dit eindproduct kan er anders uit gaan zien door bijvoorbeeld nieuwe behoeftes vanuit de business of feedback van klanten.
Ik snap daarom heel goed dat bedrijven om deze reden soms wat huiverig zijn te starten met de Agile werkwijze. Een zogenaamd pilot project is dan aan te raden. Zo is bij een bedrijf, dat voor zijn dienstverlening volledig afhankelijk is van zijn Oracle database en Oracle E-business Suite, met een zelf samengesteld Scrumteam een architectuur vernieuwingstraject doorgevoerd, terwijlde ‘winkel’ gewoon open bleef. Dit was een afwijkend startproject, omdat een eerste Agile project vaak begint met de front-end, met features die veel gebruikersinteractie en functionaliteit bevatten. Toch werd dit ongebruikelijke project een succes en gaf het voldoende draagkracht bij het bedrijf om verder te gaan met Agile. Inmiddels werkt dat bedrijf met vijf Scrumteams, met positieveresultaten.

 

Team staat centraal

De Product Owner, de belangrijkste stakeholder uit de business is samen met een Scrumteam verantwoordelijk voor een project. Niet de methode staat centraal, zoals bij de traditionele waterval methode, maar het team. Naast kwaliteitsverbeteringen zie ik in de praktijk dat het werkplezier in de teams sterk toeneemt. De teams staan dichter bij de (eind)klant en weten daarom precies waar ze het voor doen. Daarnaast bepalen de Scrumteams zelf hoeveelw erk ze naar zichzelf toetrekken in een sprint, in tegenstelling tot klassiek projectmanagement. Er wordt toegewerkt naar realistische doelen, elke twee of drie weken wordt een doel gesteld. Dit werkt veel plezieriger dan één doel aan het einde van een project en leidt tot betere resultaten. Met Agile weet je niet van te voren hoe een product er precies uit komt te zien. Wat je wel weet is dat je elke drie weken een stukje afrond, een werkend product ‘an sich’. Hierdoor is bijsturen veel eenvoudiger en uiteindelijk ook sneller.

Een snellere time-to-market is te realiseren door features slim te groeperen en vroegtijdig te releasen, en het elimineren van de zogenaamde frozen period. Projecten vallen daardoor niet maanden stil, omdat dit een doorlopend proces is. In elke iteratie wordt de gemaakte software getest en vindt er een beperkte regressie en integratietest plaats. Bovendien levert het team werkende producten op waar de (interne) klant feedback op kan geven en voortgang aan afmeet. Deze continue succesjes die worden behaald, zorgen ervoor dat de motivatie en het plezier hoog blijft.

 

Samenwerking

De samenwerking van de IT en de business is in Agile-trajecten hoog. BijAgile-gebruikers zitten Product Owners, gebruikers en informatie-analisten vaakop dezelfde kamer als de Scrumteams, waardoor er gedurende een project veeldirect contact is. Ook het testen is beter geïntegreerd in het proces en is eengroepsverantwoordelijkheid geworden in plaats van alleen iets voor de tester. Washet voor veel organisaties ondenkbaar dat je als ontwikkelaar ging testen, doorAgile te werken wordt dat geaccepteerd en gezien als meerwaarde voor heteindproduct. Omdat de gebruikers elke drie weken zien wat de échte voortgangis, kunnen ze dat ook beter vertalen naar de verwachtingen van de eindklanten. Bovendienworden de eindklanten ook regelmatig in het proces betrokken en hun feedbackwordt gebruikt voor de verbetering van de producten.

 

Business Value

In Agile wordt de nadruk gelegd op het realiseren van business value. Bij de betreffende klant zijn we nog een stap verder gegaan: voorafgaand aan het project werd gedefinieerd wat de uitvoering van het project concreet moest opleveren – de beoogde waarde. Tevens werd daarbij vastgelegd hoe en wanneer die waarde gemeten kan worden. Er wordt daardoor scherper geprioriteerd wat er wel en niet moet gebeuren (door middel van story maps). De Product Owneris verantwoordelijk voor het bepalen en behalen van de business value.

Voor de toetsing wordt hij ondersteund door de afdeling Finance & Control voor de financiële analyse (en business case). Dit wordt vastgelegd in een project charter.Bedrijven hebben in het begin vaak moeite de business value van een project te kwantificeren. Dat vraagt oefening en anders leren denken, maar het is goed mogelijk. Extra voordeel van het kwantificeren is dat het vervolgens per sprintis te meten of je als team op de goede weg bent.

 

Tips

Agile is onafhankelijk van de techniek – of je nou werkt metOracle of Java. Het beste resultaat wordt bereikt als je naast de invoering van Agile ook verbeteringen realiseert met technische practices zoals geautomatiseerd testen, continuous delivery en automatic deployment. Die practices invoeren is inOracle-omgevingen wel een stuk ingewikkelder. Een dergelijk project in het begin van een Agile-traject is niet aan te raden. Toch is hier serieuze winst te behalen. Door het elimineren van de handmatige handelingen wordt veel tijd bespaard en wordt de kwaliteit verhoogd.

 

Het is belangrijk om de volgende tips in acht te nemenals je als Oracle-huis de stap wilt maken naar Agile:
 
  • Werk met multidisciplinaireteams (ontwikkelaars, testers, analisten, architecten) met voldoende gebruikers en(interne) klantvertegenwoordigers. Werk met vaste teams waar projectwerkheengebracht wordt in plaats van mensen bij een project zoeken. Teams rakeningespeeld met elkaar, kennen elkaars sterktes en zwaktes, wat de kwaliteitverhoogt. Vaste teams gaan ook makkelijker met onzekerheid om en starten bijnavloeiend met een volgend project.
  • Integreer testen volledigin het Scrumteam waardoor al het testwerk in de sprint plaatsvindt en niet naafloop van de sprint. Als de keten daar te lang of complex voor is, breid degrens tot waar je test dan stapje voor stapje uit.
  • Verlicht de taak van deProduct Owner door een team rondom hem of haar te vormen. Dit team kan de rolvan de Product Owner verlichten en lacunes in kennis of markt aanvullen. Hierdoorkan het Scrumteam continu de juiste dingen doen.
  • Kijk kritisch naar jeprojectportfolio en probeer dat verder onder te verdelen. Verbind vervolgensProduct Owners en vaste teams aan diedeelportfolio’s. Dat zorgt ervoor datteams hun kennis op één punt kunnen richten, want het is erg kostbaar om teamsop het volledige landschap inzetbaar te houden.

 

 Schematischoverzicht van het Scrum proces: