In mijn vorige blog vertelde ik over hoe Appstorming zich verhoudt tot de meest voorkomende knelpunten in ICT projecten. De meest voorkomende knelpunten heb ik toegelicht in mijn tweede blog. In deze blog, tevens mijn laatste, zal ik toelichten hoe reguliere software ontwikkelmethoden, de Scrum- en watervalmethode, zich verhouden tot deze knelpunten. Wat de Scrum- en watervalmethode precies zijn heb ik toegelicht in mijn eerste blog.

Geen alternatieve tekst opgegeven voor deze afbeelding

Scrum

Gebrek aan gebruikersinput – Het verzamelen van de vereisten en specificaties wordt bij Scrum door de Product Owner met de stakeholders gedaan. Systeembeperkingen, grenzen en identificatie van problemen worden in dit stadium vermeld. Daarnaast wordt er elke Sprint een werkend deelproduct opgeleverd. De Product Owner vertaalt deze vereisten en specificaties vervolgens naar requirements. Deze draagt hij vervolgens over naar het ontwikkelteam. 

Door frequent op te leveren is er ook sprake van frequente feedback vanuit de Product Owner. Hierdoor blijft de kwaliteit gewaarborgd en worden de risico’s geminimaliseerd. Deze feedback kan de volgende Sprint meegenomen worden. Bij Scrum zou er dus sprake zijn van een hoge gebruikersinput, echter de gebruikersinput is wel indirect via de Product Owner. Dit knelpunt wordt daarom deels weggenomen door Scrum.

Onvolledige vereisten en specificaties – De Scrum methodiek beschrijft niet hoe de requirements in kaart gebracht moeten worden. Uit onderzoek blijkt dat de meest gebruikte techniek die gebruikt wordt het houden van interviews is. Wat wel vast staat bij Scrum, is dat de requirements iteratief in kaart worden gebracht door de Product Owner samen met de stakeholders. Een van de redenen hiervan werd geformuleerd door von Neumann “Het heeft geen zin ergens precies over te zijn als je niet weet waar je het over hebt.” 

Wanneer deze requirements zijn opgehaald zal de Product Owner een Product Backlog opstellen. Aan het begin van het project wordt het Product Backlog gevuld met alles wat er in de PO opkomt. Dit zijn meestal globale ideeën die later nog specifiek gemaakt moeten worden, dit worden Epics genoemd. Epics vormen de roadmap van de applicatie en geven de productvisie weer. Echter is een Epic niet specifiek genoeg voor het ontwikkelteam om mee aan de slag te gaan. De Epic zal eerst opgesplitst moeten worden door de PO in User Stories: korte, specifieke beschrijvingen van functionele vereisten. Doordat de requirements per Sprint in kaart worden gebracht is het eindproduct bij aanvang van het project nog niet helder. Dit wordt gedurende elke nieuwe Sprint steeds duidelijker.

Conclusie: Scrum voorziet wel degelijk in het voorkomen van onvolledige vereisten en specificaties, maar wel indirect door de Product Owner. De Product Owner moet ook die vereisten en specificaties vertalen in Epics en User Stories en daar is een risico op verlies van kwaliteit. Dit knelpunt wordt daarom deels weggenomen.

Geen alternatieve tekst opgegeven voor deze afbeelding

Wijzigende vereisten en specificaties – Bij Scrum is het niet erg als niet alle eisen van de gebruiker in het begin naar voren komen. De vereisten kunnen op elk moment tijdens de ontwikkeling veranderen: er kunnen nieuwe functies toegevoegd worden, bestaande functies verwijderen of bijwerken. Verandering zorgt voor meer creativiteit en een snellere waarde voor de klant. Echter kan het voorkomen dat het Scrum Team functionaliteit X heeft ontwikkeld maar tijdens de Sprint Review blijkt dat de stakeholder liever functionaliteit Y heeft. Dit leidt tot dubbel werk. Door het toestaan van frequente wijzigingen in de requirements, wordt de inschatting van projecttijd- en kosten bemoeilijkt. Ook neemt hierdoor de kans op scope creep toe. Doordat de vereisten constant kunnen wijzigen neemt Scrum dit knelpunt niet weg.

Bekwaamheid in technologie – Scrum schrijft niet voor welke technologie er gebruikt moet worden. Dit is aan het Scrum team om zelf te bepalen. Hoe Scrum zich verhoudt tot dit knelpunt is daarom moeilijk te zeggen. Dit ligt aan de organisatie, het project en het Scrum team.

Waterval

Gebrek aan gebruikersinput – De watervalmethode beschrijft niet wat de rol van de gebruikers is in een ICT-project. Het enige wat vast staat is dat de vereisten en specificaties in kaart gebracht worden met de klant. De vereisten worden vervolgens gedocumenteerd. De klant dient deze specificaties goed te keuren voordat er verder wordt gegaan naar de volgende fase.  Bij de watervalmethode is de gebruikersinput wel formeel geregeld in de Functionele Specificaties. Echter, in de praktijk blijkt dat Functionele Specificaties moeilijk te maken zijn en moeilijk te begrijpen zijn door de gebruikers. Dit knelpunt wordt daarom deels weggenomen.

Onvolledige vereisten en specificaties – Bij de waterval methodiek worden alle vereisten en specificaties in de definitie en design opgehaald. Alle vereisten en specificaties moeten helder zijn voordat er overgegaan kan worden tot de volgende fase: het bouwen van de software. Wederom, formeel vereist de watervalmethode dat de Functionele Specificaties compleet zijn. Door het formele karakter zijn de Functionele Specificaties een vaste mijlpaal in het proces, dus de gebruikers moeten ze wel goedkeuren, anders gaat het proces niet door. Door het formele karakter van de waterval methode worden alle vereisten dus in kaart gebracht, dit knelpunt wordt dus weggenomen door de watervalmethode.

Wijzigende vereisten en specificaties – De waterval methode gaat ervan uit dat de vereisten en specificaties gedurende het project niet veranderen. Wanneer er toch vereiste veranderen, zal een groot aantal fases opnieuw doorlopen moeten worden. Daarnaast staat de watervalmethode bekend om zijn lange doorlooptijd. Het is waarschijnlijker dat de gebruikerseisen veranderen in de loop van de tijd, of dat de gebruikerswensen niet duidelijk of niet goed geformuleerd waren in de Functionele Specificaties. Dit kan er toe leiden dat er veel wijzigingen doorgevoerd moeten worden of dat de software niet aansluit bij de gebruikerswensen. Ook dit knelpunt wordt daarom niet weggenomen.

Bekwaamheid in technologie – De watervalmethode schrijft niet voor welke technologie er gebruikt moet worden. Dit is aan het ontwikkelteam om zelf te bepalen. Hoe de watervalmethode zich verhoudt tot dit knelpunt is daarom moeilijk te zeggen. Dit ligt aan de organisatie, het project en het ontwikkelteam.

Geen alternatieve tekst opgegeven voor deze afbeelding

Hoe verhouden deze methoden zich tot de Appstorming methode?

In mijn vorige blog heb ik toegelicht hoe Appstorming zich verhoudt tot bovengenoemde knelpunten. Deze drie methoden heb ik met elkaar vergeleken, dit is weergegeven in onderstaande tabel:

Geen alternatieve tekst opgegeven voor deze afbeelding

Hieruit kan geconcludeerd worden dat Appstorming de meeste knelpunten wegneemt in vergelijking met de Scrum- en watervalmethode. Appstorming neemt namelijk de knelpunten weg op het gebied van gebruikersinput, volledigheid van vereisten & specificaties en wijzigingen van vereisten en specificaties. Op het gebied van onbekwaamheid van technologie is echter nog ruimte voor verbetering.