Door de vele apps en platformen die we mochten ontwikkelen de afgelopen jaren, hebben we onze aanpak goed kunnen perfectioneren. Hieronder beschrijf ik de 3 fases bij het daadwerkelijk bouwen van een nieuw platform. Zodra je platform eenmaal staat en deze wil uitbreiden met nieuwe functionaliteit of zelfs met een compleet nieuwe app, dan herhalen de fases zich. Fases 1 en 2 kunnen dan vaak korter duren, omdat er op dat moment al een goede basis ligt.
Fase 1: De fundering voor frequente updates
Eén van onze belangrijkste hulpmiddelen om oplossingen te realiseren die precies zijn afgestemd op je wensen is de automatisering van software-releases. Dit zetten we op in de eerste fase van het bouwen. Zo kunnen we elke wijziging binnen enkele minuten automatisch valideren en beschikbaar maken op jouw eigen testomgeving. Dit betekent een kleine investering in het begin, maar deze betaalt zich daarna dubbel en dwars terug.
Met frequente releases kan je snel de laatste functionaliteit testen en er feedback op geven, zodat die feedback gebruikt kan worden om de oplossing beter te maken. Deze fundering noemen wij en anderen ook wel een CI/CD (continuous integration & continuous delivery) pipeline. Een soort robotstraat voor alle bedrijven die digitalisering en digitale dienstverlening serieus nemen.
Fase 2: Van ontwikkelplan naar versie 1.0
Zodra de fundering staat kunnen we echt aan de functionaliteit van je platform en app beginnen. Hiervoor pakken we het ontwikkelplan erbij dat samen met jou bedacht en opgesteld is. Hierin staan op volgorde van business value (lees: prioriteit) alle wensen en eisen van gebruikers als user stories. Hoe je ook zelf een ontwikkelplan kan maken op basis van een idee heb ik eerder beschreven in het artikel Van bierviltje tot ontwikkelplan.
Voor de eerste fase van ontwikkelplan tot de livegang van de eerste versie hanteren we vaak de Scrum-methode, een iteratieve (agile) manier van werken die alle partijen de flexibiliteit biedt die nodig is om tot het best resultaat te komen. Hierbij stellen we vooraf vast hoe lang elke iteratie (sprint) zal duren. In ons geval meestal 2 weken. Voor en na elke sprint nemen we dan met de opdrachtgever de resultaten van afgelopen sprint door en bepalen we samen de inhoud van de volgende sprint. Zo zie je elke 2 weken de oplossing completer worden, kan je tijdens de ontwikkeling al testen en werken we samen naar de livegang van versie 1.0.
Fase 3: Continu verbeteren met doorontwikkeling
Na de livegang gaat de ontwikkeling een andere fase in. Verbeteringen op basis van gebruikersfeedback moeten op dat moment sneller opgeleverd en live gezet kunnen worden dan wat gebruikelijk is bij Scrum. In dit stadium past een andere agile aanpak beter: Kanban. Hierbij werken we niet meer met vaste periodes, maar meer als een soort lopende band waar dingen opgezet kunnen worden.
Op elk willekeurig moment kunnen we samen met de opdrachtgever bepalen of de huidige stand van zaken live mag. Dit kan in de praktijk zelfs betekenen dat we meerdere verbeteringen per dag in productie zetten. Bij een handmatig release-proces zou zo’n aanpak teveel tijd kosten, maar door de CI/CD pipeline gaat dit makkelijk, met meer vertrouwen en in de meeste gevallen zonder dat gebruikers er iets van merken.
Grote uitbreidingen of nieuwe applicaties?
Een platform biedt de mogelijkheid om nieuwe applicaties of andere grote uitbreidingen ook later zonder problemen toe te voegen. Het bouwen daarvan kost misschien ook weken of soms maanden. In dat geval kan daarvoor weer het 2-wekelijkse ritme van Scrum gevolgd worden met na livegang de continue doorontwikkeling op basis van Kanban. Zo stemmen we continu het werkproces af op de actuele situatie om de snelheid waarmee jij kan innoveren hoog te houden.
(1e foto door Simon Kadula en 2e door Parabol, op Unsplash)