Hoe Kapibara projecten realiseert komt niet uit de lucht vallen. We hebben veel ervaring in software ontwikkeling en maken gebruik van de ervaringen van anderen. Daarom werken wij Agile, wat zoveel wil zeggen als: ons proces van ontwikkelen van software is zo ingericht dat het makkelijk is om te sturen. Zowel door u, de opdrachtgever, als door ons, de aannemer.
Stap 1: Voorbereiden
In eerste instantie moeten we bepalen wat er gemaakt gaat worden. Dit doen we door samen uw businessplan, uw proces(sen) en alles wat komt kijken bij het drijven van uw onderneming te bespreken.
Daaruit volgt een beeld van de te ontwikkelen applicatie of website. Dat beeld leggen we vast door het opstellen van een zogenaamde back-log. Dat is niets anders dan een lijst met features die de applicatie zal bieden; wat de applicatie allemaal kan, plat gezegd.
U bent de baas over deze back-log! In Agile termen noemen we dat product owner. U bent de eigenaar van het product, de softwareapplicatie, die wij voor u gaan bouwen.
Stap 2: Realiseren
Stel u voor dat wij vervolgens alles in die back-log gaan bouwen. Dat duurt lang. En u kunt pas verder met uw onderneming als wij klaar zijn. Dat is niet handig.
Daarom bepaalt u welke features uit de back-log absoluut nodig zijn om tot een applicatie te komen waarmee u aan de slag kan. De features waar u niet zonder kan. Dat is lastig, want nu komen we op de kunst van het weglaten. Maar daar komen we samen uit.
De lijst die daaruit volgt, noemen we Minimal Viable Product (MVP). Het minimale wat u aan features in de applicatie nodig heeft om uw business te kunnen managen.
Sprinten
Nu is het tijd dat wij kunnen beginnen met waar wij enthousiast van worden, software bouwen. Dat doen we in periodes van één of twee weken, die we sprints noemen. We kunnen nu vrij goed inschatten hoeveel sprints het zal duren om het MVP te bouwen. Daarmee kunnen we dus ook een goede budgetindicatie afgeven.
Aan het eind van iedere sprint, leveren we op wat er tot dan toe is gemaakt, werkend en getest.
Aan het eind van de sprint evalueren we de samenwerking en hetgeen opgeleverd is. Daarnaast bepaalt u wat er in de volgende sprint wordt gebouwd uit de lijst met features. Op die manier kunt u nog tijdens de bouw reageren op veranderende omstandigheden.
Wordt vervolgd
Zo gaan we door tot het MVP gereed is en we samen een glas champagne drinken op het live gaan van uw applicatie. En als het glas leeg is, dan starten we met de volgende sprint, omdat er nog features in de back-log staan die ook heel belangrijk zijn voor het succesvol maken van uw onderneming.
We mixen dan in iedere sprint nieuwe features en aanpassingen op bestaande features tot we de sprint gevuld hebben.
Voordelen van deze methode
Zoals eerder gezegd, dit hebben we niet zelf verzonnen, maar deze werkwijze is het product van jarenlange ervaringen in de branche en wordt bij alle moderne en grote ondernemingen waar software wordt geproduceerd toegepast.
De voordelen voor u als opdrachtgever op een rijtje:
- snel resultaat (korte marktintroductietijd)
- veel controle op hetgeen er gebouwd wordt
- controle op budget
u krijgt na iedere sprint een factuur, dus u houdt greep op de kosten - hoge kwaliteit
geen haastwerk met bugs - het werken in sprints betekent dat er snel gereageerd kan worden op veranderingen in bijvoorbeeld de markt of wet- en regelgeving
Conclusie
Op het eerste gezicht lijkt het misschien of u ons een blanco cheque overhandigt, wij beloven immers niet het product te bouwen tegen een vast bedrag. Andere aannemers die het project wellicht fixed-price aanbieden zullen echter (als ze slim zijn) een marge in de prijs opnemen om met onvoorziene zaken en voortschreidend inzicht om te gaan.
Die marge kunt u bij ons gebruiken om features mee te ontwikkelen. En dat kunnen we doen, door de kort-cyclische aanpak. Na iedere sprint is er immers gelegenheid tot bijsturen.