Hoe we software maken in sprints en toch van tevoren weten waar we aan toe zijn

-

Bij Luminis werken we op basis van een combinatie van Unified Process en Scrum. Hoewel we ons realiseren dat het hebben van zekerheid aan het begin van een project over tijd en scope nuttig is, weten we ook dat dit meestal niet realistisch is. We geloven in inschatten en dan die inschatting voortdurend toetsen om zo te komen tot een voorspelbaar en controleerbaar project.

We doorlopen in een project de volgende stappen:

Fase

Inhoud

Uitkomst

Voorbereiding

Eerste gesprekken, maken offerte

Offerte met eerste inschatting, eerste schets architectuur

Inception

Interactief scope verduidelijken

Functioneel overzicht, concept architectuur, betere inschatting

Elaboration

Oplossing bewijzen door functionaliteit te bouwen

Wegnemen projectrisico’s, bewijzen gekozen oplossing, verbeteren inschatting

Construction

Bouwen van het restant van de functionaliteit

Opgeleverd systeem

Transition

Randvoorwaarden realiseren zoals training, inrichten beheer

Werkbaar systeem

Elke stap leidt tot een duidelijk resultaat en na elke stap is er een go/no-go moment waarop besloten zou kunnen worden om een project te beëindigen als dat nodig mocht zijn. Denk bijvoorbeeld aan het naar boven komen van onacceptabele risico’s. Ook levert elke fase, en elke sprint, een werkend resultaat op en zou dus op elk moment de oplossing gebruikt kunnen worden, of verder kunnen worden ontwikkeld door een andere partij. Dit go/no-go moment dient er dus voor om de klant op elk moment de controle te laten houden over het project.

Voorbereiding

De Voorbereiding is het eerste verkennende deel van een project, dus de eerste gesprekken met een mogelijke klant tot en met de offerte en goedkeuring daarvan. Deel hiervan is een eerste grove inschatting van de scope, een eerste schets van de architectuur, en een eerste indicatie van het benodigde budget. 

Onze ontwerpers maken in dit vroege stadium ook een snel prototype, zodat we een beeld kunnen geven van de interface die mensen te zien krijgen. Dit doen we door de waarden en behoeften te onderzoeken van gebruikers en andere stakeholders. We betrekken deze gebruikers vroeg bij het proces en garanderen daarmee dat we bouwen wat nodig is, wat op de lange termijn ontwikkelkosten bespaart.

Inception

Tijdens de inceptionfase draait het om het verduidelijken van de initiële scope. We doen dat door middel van concepting workshops.  De inceptionfase levert een high level design, een inschatting van kosten en een architectuur op.

Concepting workshops

Tijdens de Concepting Workshops wordt in een periode van ongeveer een week een overzicht gemaakt van de reikwijdte van het project. In de workshops achterhalen we de wensen van gebruikers en andere stakeholders. Bij het herontwerpen van een bestaand systeem gaan we uit van de werking van het huidige systeem. In het huidige systeem is immers getest en bevat een schat aan kennis en ervaring. Voor concepting workshops nodigen we een brede groep mensen uit, denk aan een gebruiker, een architect, een developer, een analyst uit de business en een ontwerper.

We vragen de gebruiker om ons te vertellen hoe een werkdag eruit ziet. Ook kijken we hoe verschillende groepen gebruikers het systeem gebruiken. We achterhalen vervolgens de context waarin mensen het systeem gebruiken, bijvoorbeeld of gebruikers in moeilijke condities werken of de mate van training van de gebruikers. Ook bepalen we wat voor soort hardware mensen gebruiken. Kennis die we hiermee opdoen leggen we vast in design statements.

Er ontstaat zo een overzicht van wat mensen het systeem doen, een manier om dit operationele proces op te schrijven is een customer journey. Daarnaast tekent de ontwerper snel een eerste indruk van hoe de schermen voor de verschillende gebruikers er uit gaan zien en hoe ze gaan werken. De ontwerper maakt de interactie duidelijk in mock-ups. Parallel hieraan definiëren architect en developer de architectuur.

High Level Design

De uitkomsten van de Concepting Workshops zetten we in deze stap om in een overzicht van de functionaliteit van het systeem. De mock-ups uit de concepting workshops krijgen nu meer detail.

De uitkomst van deze fase is een zogenoemde story map waarin alle functies zijn opgenomen. Voor elk van de elementen op deze story map, dus voor elke user story, maakt het team een inschatting. De story map geeft inzicht in bouwfases, zo wordt duidelijk welke functies behoren tot het MVP, het minimum viable product[1]. Het MVP dus wat de functionaliteit is die absoluut gebouwd moet worden om te komen tot een systeem dat (net aan) voldoet voor de gebruikers.

Uiteindelijk hebben we dus een nauwkeuriger overzicht van de scope, plus een schatting per stukje functionaliteit. Hiermee zijn we klaar om de eerste stukken van de applicatie te gaan realiseren.

Elaboration

De elaborationfase heeft tot doel om het systeem te bouwen, maar wel die functionaliteit die bijdraagt aan het beheersen van (veelal technische) projectrisico’s. We bouwen dus de delen die bewijzen dat de oplossing die gekozen is ook echt werkbaar gaat zijn voor de eindgebruikers.

Naast functionaliteit opleveren is het doel ook nadrukkelijk om door echte ervaring te krijgen binnen het project een verbetering aan te kunnen brengen aan de inschatting van de rest van het project.

Construction

Tijdens Elaboration wordt de eerste functionaliteit gerealiseerd. Daar gaan we in de constructionfase mee door. Het verschil is dat we tijdens Construction alle projectrisico’s al afgedekt hebben, dus kunnen we ons nu nog meer richten op het meters maken en het neerzetten van de uiteindelijke oplossing. We produceren zo snel mogelijk een werkende oplossing, die we meteen al kunnen testen.

Transition

De transitionfase loopt grotendeels parallel met een deel van Construction. Het bouwen van het systeem is maar een deel van de realisatie. We moeten ook zorgen voor goede documentatie, waar van toepassing voor opleiding van gebruikers, voor het inrichten van technisch- en functioneel beheer, voor omgevingen waar het systeem op gaat draaien, en andere belangrijke randvoorwaarden. Hier beginnen we al vroeg mee tijdens het project en we moeten dit alles hebben afgerond voor de uiteindelijke oplevering van het systeem.

Hoe we software maken in stappen

1.2      Elaboration en Construction: Scrum

Tijdens de bouwfasen (Elaboration en Construction) werken we met Scrum in brokken (sprints) van 2 weken. Aan het begin van elke sprint bepalen we samen wat er gedaan moet worden en aan het eind van die periode wordt geëvalueerd in hoeverre dat ook echt is gerealiseerd. Er is dus voortdurend de mogelijkheid voor de klant om exact te zien wat de status is, en om bij te sturen.

Elke sprint (mogelijk met uitzondering van de eerste paar), leveren we een werkende oplossing op die in principe gebruikt zou kunnen worden. Dus we leveren liever minder stukken functionaliteit op die echt af zijn dan heel veel stukken functionaliteit die nog net niet bruikbaar zijn.

Elke 2 sprints, dus elke 4 weken, doen we een financiële rapportage. Aan de hand van de gemaakte kosten en wat tot op heden is opgeleverd kan worden bepaald wat de verwachtte kosten voor het restant van het project zullen zijn, en dus ook wat de totale kosten zijn. Dit geeft extra inzicht en geeft de mogelijkheid om bij te sturen waar nodig.

Het doel van werken in korte sprints en het doen van de financiële rapportage is om volledige transparantie te geven. We geloven niet zo in “het is 80% klaar”, maar meer in laten zien wat we gedaan hebben en wat echt af is.


[1] Een Minimum Viable Product is een product dat zo klein is als maar kan terwijl het toch nog nuttig is. Dus wat is echt minimaal nodig om de waarde te leveren.