Ontwikkelen doe je in een straat

In Agile (web-)softwareontwikkeling wordt vaak gebruik gemaakt van een ontwikkelstraat. Deze bestaat uit meerdere omgevingen waarheen het product gepubliceerd wordt voordat het live gezet wordt. Je kunt hierbij denken aan een omgeving waar ontwikkelaars hun code ontwikkelen, een omgeving waar testers het product kunnen testen, een omgeving waar de klant haar acceptatietesten kan uitvoeren en natuurlijk een productieomgeving waar het uiteindelijke product zal staan. Zo’n straat wordt vaak aangeduid met de afkorting OTAP, waar de letters staan voor het type omgeving: Ontwikkeling, Test, Acceptatie en Productie
Dit principe bestaat al tijden en is erg sequentieel en lijkt op eerste opzicht totaal niet Agile. Het kan echter erg goed werken in een Agile-scrum omgeving. Als je een aantal dingen in acht neemt, zal het je ontwikkelproces zeker ten goede komen.

OTAP en Scrum

Binnen de ‘scrum’ project methode wordt er iteratief ontwikkeld, de uiteindelijke functionaliteit van het op te leveren product wordt in stukjes gehakt en in iedere iteratie (of Sprint) wordt een stuk functionaliteit opgeleverd en gepresenteerd aan de klant. 
Elke werkdag begint met een stand-up, waar elk teamlid vertelt wat hem of haar bezig houdt die dag. Aan het einde van elke sprint volgt een sprint demo waar ontwikkelaars de nieuwe functionaliteit laten zien aan de klant. 
Een scrum-team is multidisciplinair, en bevat naast ontwikkelaars (vaak) ook testers, welke continu werken aan integratie- en regressietesten en ervoor zorgen dat wat ontwikkeld is eerst goed getest is voordat het aan de klant gepresenteerd wordt.
Scrum past dus eigenlijk erg goed in de OTAP-straat, ontwikkelaars zijn bezig op Ontwikkeling, testers zijn bezig op Test, de demo aan de klant wordt gegeven op Acceptatie en het uiteindelijke product wordt op Productie gezet:

blog_otap_scrum.png

Ontwikkelaars publiceren hun stuk code naar de Test omgeving wanneer zij menen dat het testbaar is en geven een seintje aan de testers dat zij dit kunnen testen. Zij geven op hun beurt feedback met hun testresultaten tijdens de dagelijkse stand-up en daar wordt besloten of het ‘goed’ is of terug moet naar Ontwikkeling. Dit proces herhaalt zich elke dag tot aan het einde van de sprint. Op dat moment wordt alle code op Test, welke dus werkt en getest is, gepubliceerd naar Acceptatie waar de demo aan de klant gedaan zal worden. De klant heeft nu de mogelijkheid om bepaalde functionaliteit te accepteren of te weigeren. In dat laatste geval gaat deze terug naar Ontwikkeling en begint het proces weer van voor af aan in een nieuwe sprint.

Wat tips

Scrum en de klassieke ontwikkelstraat gaan dus goed samen. Echter gaat het vaak fout omdat het opzetten van de complete ontwikkelstraat vaak niet voor de start van een project geregeld is. Hier volgen wat aanbevelingen voor het opzetten van een productieve ontwikkelstraat:

  • Zorg dat de hele ontwikkelstraat aanwezig is voordat je project begint
    Dit betekent dat behalve de ontwikkel-omgeving ook de andere drie omgevingen opgezet zijn. Dit gaat initieel veel tijd en middelen kosten om op te zetten. Wel ga je er tijdens de rest van het project enorm veel profijt van hebben.
  • Focus op testen
    Zorg dat er meteen testers aan de slag gaan met het opzetten van testen op de Test-omgeving, zodat zodra de ontwikkelaars code gaan publiceren dit meteen getest kan worden. Dit zorgt voor minder vertraging in het ontwikkelproces en zorgt er ook voor dat er minder stukken functionaliteit afgekeurd worden door de klant. 
  • Beknibbel niet op servers
    Een productie omgeving bestaat vaak uit meerdere machines, wat aardig in de papieren kan lopen. De Acceptatie-omgeving moet bijvoorbeeld zo veel mogelijk gelijk zijn aan de Productie-omgeving om de prestaties en schaalbaarheid van je applicatie te kunnen testen. Voor de klant is het vaak niet evident dat dit een business-value heeft. Vandaar is het van belang dat je dit vooraf bespreekt zodat dit niet achteraf voor verrassingen zorgt.
  • Migreer regelmatig content vanaf Productie
    Om de testen zo representatief mogelijk te maken moet er getest worden met ‘echte’ content. Om dit te vereenvoudigen is het slim om met regelmaat de content van Productie terug te migreren door de straat. Dit heeft als resultaat dat de testers op de Test omgeving met actuele data testen kunnen uitvoeren.
  • Betrek de klant bij het testproces
    Laat regelmatig de voortgang zien, ook tijdens de sprint en bespreek testresultaten met de klant. Dit resulteert in minder fouten op de Acceptatie omgeving en in een betere demo iedere sprint.

Conclusie

Agile scrum in combinatie met de OTAP-straat levert erg veel voordelen op en resulteert in kortere ontwikkeltijden en beter geteste producten. Pas wel op voor de valkuilen, zorg dat je alles meteen goed opzet en je niet laat afschrikken door de initiële moeite die het kost. 

Hoe pak jij dit aan binnen je projecten? Laat het ons weten in de comments.