Geschreven door Patrick van Haren

Patrick is mede-eigenaar en mede-oprichter van PinkWhale. Met technische expertise op gebied van cloud oplossingen i.c.m. brede ervaring op gebied van bedrijfsstrategiën, weet hij enterprise omgevingen voor de juiste doelen in te zetten. Patrick is van de rode draad, de structuur en het evenwicht binnen PinkWhale.

Maatwerk software al binnen enkele weken!

Een app ontwikkelen duurt lang, is intensief en de deadline loopt altijd uit? Niet nodig! Ik leg je uit hoe je succesvol software ontwikkelt en binnen de eerste vier weken al resultaat ziet.

Traditionele aanpak

De traditionele fasering van software trajecten wordt vaak de watervalmethode genoemd. In fases wordt met deze methode gewerkt van strategie naar eindproduct. Vergelijk het met het bouwen van een huis. Allereerst worden de bouwtekeningen gemaakt, vervolgens begint men met het fundament en vervolgens worden de verdiepingen gebouwd. De watervalmethode werkt exact op deze manier. De applicatie wordt strategisch uitgedacht, vervolgens wordt een functioneel ontwerp gemaakt, daarna volgt een grafisch ontwerp en uiteindelijk wordt het project gerealiseerd. Het openen van een nieuwe fase gaat gepaard met het definitief afsluiten van een vorige fase. Als klant ga je akkoord met de ontwikkelingen in een fase zodat deze kan worden afgesloten.

Waarom werkt de watervalmethode niet?

De watervalmethode kent zeker zijn voordelen. Door gefaseerd te werken, creëer je de gelegenheid over elke fase goed na te denken en met elkaar te discussiëren. Door de duidelijke scheiding in deze fases houd je de touwtjes goed in handen. Toch werkt de watervalmethode vaak minder goed bij softwareprojecten dan de hedendaags veel gebruikte Agile methodiek. Om die reden wordt deze theorie bijna niet meer gebruikt.

Nadelen watervalmethode

Zelden (misschien zelfs nooit) heb ik softwareprojecten voorbij zien komen waarbij inzichten en meningen gaandeweg niet veranderen. Inspelen op nieuwe feedback is onmogelijk met de traditionele watervalmethode. Een fase wordt namelijk definitief afgesloten en een ontwerpwijziging is niet meer mogelijk óf kost direct (veel) extra geld. Bovendien kan een technisch knelpunt in een later stadium een reden zijn om toch iets in een eerdere fase te wijzigen. Het testen van het product gebeurt pas aan het einde van het traject. Doordat er tussendoor niet wordt getest, komen eventuele problemen pas aan het einde boven drijven. Zie die maar te coördineren! Tot slot is de doorlooptijd langer. Het gehele traject moet volledig worden doorlopen en afgerond, om een software oplossing te kunnen lanceren. De eerste fases waarbij nog geen enkele code wordt getypt, is tijdrovend, intensief en erg kostbaar. Dit is de fase die de volgende fases moet indekken en dat betekent dat alles in detail moet worden voorbereid.

Agile, het beste alternatief!

Sinds begin jaren ’90 is Agile een alternatieve methode voor projectmanagement. Deze theorie werd ontwikkeld door een aantal programmeurs die met hoge werkdruk, budgetoverschrijdingen, spanningen en kwaliteitsproblemen rondliepen. Agile is een methode om op basis van korte iteraties aan updates te werken. Bij Agile zijn een aantal stromingen ontstaan in de loop der jaren. Enkele zijn DSDM, Chrystal Clear en Scrum. Deze laatste is de meest gebruikte methode voor huidige software projectteams. Ook andere branches waarbij in teamverband wordt gewerkt, zien steeds vaker de voordelen van Scrum.

Scrum board

Bij Scrum wordt dus in iteraties gewerkt. Voorafgaand worden user stories gemaakt. Dit is een lijst met alle wensen en eisen qua functionaliteiten. Voor een bepaalde functionaliteit zijn één of meerdere taken nodig. Deze worden issues genoemd, waarvan de benodigde tijd vervolgens wordt ingeschat. Dit bepaalt hoeveel issues in een Sprint passen. Bij het samenstellen van een Sprint kan op prioriteit worden gesorteerd. Een Sprint is een periode van meestal twee tot vier weken, waarbij op basis van vooraf gedefinieerde resources (dus fixed price) aan deze Sprint wordt gewerkt. Na de eerste Sprint kan al worden geëvalueerd over de issues in deze Sprint en kan de volgende worden samengesteld. Hierin wordt dus al na de eerste Sprint (max. 4 weken) een eerste release opgeleverd met de eerste functionaliteiten. Direct kunnen schakelen, inspelen op nieuwe wensen, weinig voorbereidingstijd en korte lijntjes zijn de grote voordelen van werken met de Scrum methodiek.

Budgettering

Bij Scrum weet je financieel niet waar je aan begint. Of beter gezegd, je weet niet waar het project eindigt. Er wordt namelijk op basis van resources een prijs bepaald, waarbij de scope variabel is. Je stopt veel tijd en geld in een project, terwijl je vooraf geen fixed price hebt. Scrum brengt dus onzekerheid met zich mee. Dat is toch niet interessant?

Bij Scrum wordt je continu betrokken bij de ontwikkelingen. Je hebt altijd direct toegang tot de huidige status van je software. Er zijn veel contactmomenten en in kleine stappen worden steeds nieuwe aanvullende functionaliteiten toegevoegd. Omdat je per Sprint een aantal issues (wensen) klaarzet, kan je flexibel omgaan met nieuwe ontwikkelingen en wensen. Ook na oplevering van software betekent dit dat je gebruikers actief kan betrekken. Door hen feedback in te laten sturen en eventueel zelfs te laten stemmen, ben je in de gelegenheid snel te anticiperen en prioriteiten te stellen voor de volgende iteratie. Pas wanneer een iteratie is gestart, kan daarin niet meer geschakeld en geschoven worden.

Money for Nothing and Your Change for Free

Een bekend begrip bij Scrum projecten, welke vaak terugkomt bij offertes en overeenkomsten. Kort gezegd houd deze contractuele afspraak in dat je flexibel bent en kosteloos issues in een Sprint kan wijzigen (Change for Free). In het contract is een langetermijn regeling opgenomen waarbij voor een bepaalde periode vaste resources worden geleverd. Je bent echter vrij om te besluiten dat de volgende Sprint de laatste is, waarbij je 20% van de resterende contractduur moet afbetalen (Money for Nothing). Deze regeling biedt je de vrijheid om het contract te ontbinden, waarbij de ontwikkelaars een vergoeding ontvangen om

Conclusie

Software ontwikkeling is een traject waarbij veel komt kijken. Alles tot in detail vooraf vastleggen geeft beperkingen, waarbij je het risico loopt dat het eindproduct niet is wat je hebt verwacht. Wel biedt dit het voordeel dat je bij het tekenen van de offerte precies weet wat je krijgt. Al met al is dit minder flexibel en onder de streep duurder. Om die reden wordt Scrum tegenwoordig vaak als methode gebruikt om software te ontwikkelen. Er wordt beter samengewerkt en in korte Sprints komen we in stappen steeds dichter bij het eindresultaat. Voordat je aan het avontuur begint weet je niet wat het onder de streep gaat kosten, maar je weet wél dat je de touwtjes in handen hebt, flexibel bent, continu kan bijsturen en na vier weken al een eerste release krijgt opgeleverd.