Achter de schermen deel 4: Ontwikkelen, testen & reviewen

De development cycles en feedbackrondes

Hoe de ontwikkelfase eruit ziet wordt bepaald door de vorm van de opdracht. Bij Four Digits werken we met twee projectvormen: Agile scrum en waterval. In het geval van agile scrum werken we in development cycles. Coen vertelt:

“Bij agile scrum werken we in een cyclus van twee weken coderen, met daarna een tussenweek voor het ontvangen van feedback en het opstellen van een nieuwe sprint.”

Het aantal development cycles dat we inzetten is afhankelijk van de grootte van het budget. Bevat een project meerdere cycles? Dan houden we keer op keer dezelfde cyclusvorm aan.

In het geval van de waterval projectvorm is er geen duidelijke structuur van ontwikkelen. Bij deze vorm blijven we continu door ontwikkelen, waarbij we feedback ontvangen op de meetings die we met vaste tussenperiodes inplannen. Iedere week á 2 weken plannen we een contactmoment met onze klanten in, waarin we ze exact laten zien wat de updates zijn en hoe het ontwikkeltraject er voor staat. Dit geeft onze klant de gelegenheid om feedback te geven, waardoor we er zeker van zijn dat het eindproduct altijd naar wens is.

Het risico bestaat altijd dat een klant iedere feedbacksessie van mening blijft wijzigen. Dit is de reden dat we juist in de orïentatiefase alle afspraken al vast willen leggen. Coen vertelt:

“We proberen alle discussies aan de voorkant te hebben gehad, zodat we geen re-work hebben in de laatste fase. Het design is gemaakt, de afspraken zijn gemaakt. Dus als het met voortschrijdend inzicht toch anders moet, dan hebben we een nieuw budget nodig.”

Op het moment dat er tijdens een contactmoment in de ontwikkelfase toch een nieuwe wens is vanuit de klant, brengen we dan ook een nieuwe offerte uit. Zo weten we zeker dat we de oorspronkelijke opdracht binnen het budget kunnen uitvoeren en dat onze klant niet achteraf met extra kosten wordt opgezadeld.

Het testen en reviewen van onze software

Bij Four Digits stellen we hoge eisen aan onze software. Het moet veilig zijn, vloeiend werken en naadloos integreren met eventuele andere software. Om dit te garanderen is testen essentieel. Daarom is het testen en laten reviewen van onze code door andere collega’s een vast onderdeel in ons ontwikkelproces. We laten je aan de hand van een voorbeeld zien hoe we het testen en reviewen verwerken in het proces. Stel dat ons gevraagd wordt om een nieuwe feature te ontwikkelen, dan nemen we de volgende stappen:

1. We creëren een ticket in ons projectmanagement software met daarin een omschrijving van de hulpvraag.
2. Tijdens de sprint kiezen we in overleg met de klant welke van de tickets we gaan uitvoeren.
3. Het ticket wordt binnen de sprint geactiveerd en toegewezen aan een van onze collega’s.
4. Als er onduidelijkheden zijn, laten we deze door onze klant verduidelijken. Zodat we precies weten wat er van ons verwacht wordt.
5. Op basis hiervan beschrijven we de eind requirements, zodat we kunnen toetsen of de nieuwe feature voldoet aan wat het moet doen.
6. We schrijven de code en testcode, die de feature automatisch test.
7. We laten de geschreven code reviewen door een collega die hier feedback op geeft.
8. Als het goedgekeurd is wordt de code geïmplementeerd en nogmaals getest door een derde collega op functionaliteit.
9. Als laatste test de klant de feature op functionaliteit, waarna hij de software kan goedkeuren.
10. Bij goedkeuring leveren we de feature op naar de productieomgeving.

Siemen vertelt waarom we zo’n uitvoerig testproces in het ontwikkeltraject integreren:

“Door dit proces te volgens sluiten we veel problemen uit voordat de feature uiteindelijk bij de klant komt. Voor sommige klanten klinkt dit misschien als veel overhead, maar uit ervaring levert dit juist de beste resultaten voor de klant.”

In het geval van projecten waarin onze klant zelf ook een actieve rol speelt in het ontwikkelproces, testen zij vaak met ons mee. Door deze dubbele kwaliteitscheck vanuit twee verschillende organisaties wordt de uiteindelijke kwaliteit nog meer gegarandeerd.

Op naar de afrondingsfase

Voor de buitenwereld kan het lijken alsof software ontwikkeling een kwestie is van code schrijven. In deze reeks hebben we je het tegendeel laten zien. Het daadwerkelijke coderen omvat slechts een klein deel van het totale traject, maar is tegelijkertijd essentieel om het ontwikkeltraject goed te laten verlopen.

Nu je kennis hebt gemaakt met de orïentatiefase, modelleringsfase en ontwikkelfase, is het tijd om het ontwikkeltraject langzaam af te gaan ronden. Hoe? Dat lees je in onze volgende blog!

Eerst onze eerdere blogs uit deze reeks lezen? Lees ze hier terug:

1. Hoe start een nieuw software project? Getting ready.
2. Het voorbereiden van een nieuwe software project.
3. De modelleringsfase van een software project.