Wat is een succesvolle webapplicatie?
Het succes van een webapplicatie staat in onze ogen lineair met de kwaliteit van een webapplicatie. Maar wat is dan de kwaliteit van een webapplicatie hoor ik je zeggen. De definitie van Wikipedia is als volgt:
“In de context van software-engineering meet de softwarekwaliteit hoe goed software is ontworpen (kwaliteit van het ontwerp) en hoe goed de software voldoet aan dat ontwerp (conformiteitskwaliteit). Het wordt vaak omschreven als de ‘geschiktheid voor het doel’ van een stuk software.”
Met name ‘geschiktheid voor het doel’ is in ons opzicht enorm belangrijk. Bied je bijvoorbeeld hypothecair advies en is jouw huidige doel het verhogen van het aantal conversies op je website door een uitbreiding van je serviceaanbod. Dan zou bijvoorbeeld het toevoegen van een maatwerk software module waarmee bezoekers verschillende hypotheekverstrekkers kunnen vergelijken, een positief effect kunnen hebben op je conversieratio. Om het maximale resultaat te behalen moet deze module kwalitatief zo goed mogelijk in elkaar zitten. Een webapplicatie van hoge kwaliteit in dit geval moet o.a. gebruiksvriendelijk en overzichtelijk zijn, goed integreren met de huidige applicatie en duidelijk opgebouwd zijn voor toekomstige werkzaamheden.
Software constraints
De kwaliteit van webapplicaties kan gemeten worden op allerlei onderwerpen. Helaas is het zo dat er voor ieder project een balans of afstemming moet worden gezocht in scope, budget en tijd ofwel De ‘Iron Triangle’.
Project managers zullen erg bekend zijn met deze afbeelding. Scope zegt wat er ontwikkeld moet worden, Time zegt wanneer het ontwikkeld moet worden en Budget zegt wat het moet kosten.
Het probleem van deze traditionele benadering
Het fundamentele probleem van softwareprojecten is dat iedere stakeholder verschillende en vaak tegenstrijdige prioriteiten heeft. Software developers neigen naar het ontwikkelen van hoogwaardige systemen, accountants zijn meer geïnteresseerd in de totale kosten, het management in de planning en de eindgebruikers in de scope. Hoewel dit duidelijk stereotypen zijn, hebben we ons allemaal in situaties bevonden waarin iemand zich te veel focuste op ‘hun probleem’ met uitsluiting van de problemen van anderen.
“Het fundamentele probleem van softwareprojecten is dat iedere stakeholder verschillende en vaak tegenstrijdige prioriteiten heeft.”
Er zijn vier gevaren voor wanneer het team niet focust op de verhouding tussen deze ‘constraints’:
- Het project wordt te laat en/of over budget geleverd. Het komt regelmatig voor dat tijd niet goed wordt ingeschat, met name bij softwareprojecten. Dit komt doordat omstandigheden tijdens het project continu veranderen. Het team denkt de deadline te kunnen halen (ze willen bijv. het management niet teleurstellen) maar uiteindelijk lukt dit niet.
- Niet alle functionaliteiten worden opgeleverd. Door scope creep (het langzaam groter worden van de scope door het onjuist managen van verwachtingen of het niet goed afbakenen van de scope) lukt het development teams niet om alle functionaliteiten op te leveren.
- De software voldoet niet aan kwaliteitseisen. Wanneer een development team wordt gepusht om meer functionaliteiten te maken dan ze tijd of budget voor hebben, laten ze vaak kwaliteit liggen zodat ze deze functionaliteiten op kunnen leveren.
Het grootste risico van slechte verwachtingsmanagement is dat wanneer niemand flexibel is in zijn belangen, het project gedoemd is tot mislukking. Een combinatie van alle constraints resulteert mogelijk in een stopzetting van het project.
Dit wil je dus voorkomen
De invloed van teamdynamiek op de kwaliteit van software
De rollen van de product owner en de projectmanager of projectleider in dit verhaal, spelen een cruciale rol. Het is aan hen de stakeholders te overtuigen van deze constraints en ervoor te zorgen dat minimaal één van deze constraints variabel blijft of dat er voor de Minimum Viable Product (MVP) aanpak wordt gekozen, zodat aan alle eisen voldaan kan worden.
De dynamiek van een Scrum team
Oplossing: Minimum Viable Product (MVP)
MVP is onderdeel van het empirisch programmeren. In alle projecten streven wij ernaar de juiste functionaliteiten op te leveren en de verwachtingen van de klant te overstijgen. In ons opzicht zijn budget en tijd de twee constraints met de minste invloed op het eindresultaat. Waarom? Werkende software kan gemaakt worden met een minimum in beide. Het probleem kan stukje bij beetje worden opgelost, bijvoorbeeld door het selecteren van een aantal essentiële features; de MVP.
Door een MVP te definiëren is het mogelijk om key features van de applicatie uit te werken en aan kwaliteitseisen te laten voldoen. Doordat er een beperkte selectie wordt gemaakt kunnen budget en tijd benodigdheden ook beperkt worden. Een ander groot voordeel aan het maken van een MVP is dat het makkelijker wordt gebruikers deel te maken van jouw idee doordat je al snel een werkende applicatie hebt. Zij kunnen jou dan tevens van feedback voorzien waarop je kan itereren. Wellicht valt het product wel volledig anders uit dan je in eerste instantie dacht, maar voldoet dan wel aan de eisen van de uiteindelijke gebruiker.
En nu in plaatjes
Het mooie van de MVP benadering is dat het een positieve invloed heeft op de teamdynamiek. Zodra een eerste werkende versie wordt opgeleverd kan deze getest worden met eindgebruikers en zien belangrijke stakeholders het product waaraan gewerkt wordt in een tastbare vorm.
“Door een MVP te definiëren is het mogelijk om key features van de applicatie uit te werken en aan kwaliteitseisen te laten voldoen.”
Welke kwaliteitseisen zijn er en hoe prioriteren we die?
Om te voldoen aan kwaliteitseisen moet het development team analyseren welke kwaliteitsattributen bij het product het meest van toepassing zijn. Hieronder worden enkele kwaliteitsattributen omschreven:
- Bruikbaarheid
Software-bruikbaarheid kan worden beschreven als hoe effectief eindgebruikers het systeem kunnen gebruiken, leren of besturen. - Onderhoudbaarheid (of flexibiliteit / testbaarheid)
De definitie van onderhoudbaarheid impliceert hoe eenvoudig de code aan te passen is. Flexibiliteit en testbaarheid worden genoemd omdat deze een gekoppeld zijn aan de algehele onderhoudbaarheid van een project. - Schaalbaarheid
Schaalbaarheid is het vermogen van de webapplicatie om op elegante wijze te voldoen aan de vraag naar ‘stress’ veroorzaakt door een toename in gebruik. Ofwel, ervoor zorgen dat je applicatie niet crasht gaat wanneer er meer traffic is dan er aanvankelijk verwacht werd. - Beschikbaarheid (of betrouwbaarheid)
Hoe lang het systeem actief is en de beschikbaarheid van een programma. - Uitbreidbaarheid
Zijn er punten in het systeem waar uitbreidingen kunnen worden aangebracht zonder veel wijzigingen aan de codebase? - Beveiliging
De gradatie van veiligheid van het systeem; de mate waarin het systeem zich verzet tegen cyberaanvallen. - Overdraagbaarheid
Overdraagbaarheid is de mogelijkheid voor uw toepassing om op meerdere platforms te worden uitgevoerd. Dit kan onder meer de daadwerkelijke toepassing van hosting, weergave of dataportabiliteit zijn.
Het is duidelijk dat dit geen uitputtende lijst is. Er zijn er nog veel meer; backwards-compatibiliteit, interoperabiliteit, herbruikbaarheid, juistheid, geschiktheid, leerbaarheid, robuustheid, leesbaarheid en efficiëntie om er maar een aantal te noemen.
Om met de verschillende constraints en kwaliteitseisen een werkend product op te leveren, dient het development team samen met de product owner, eindgebruikers en stakeholders de belangrijkste onderdelen te prioriteren. Een goede onderlinge samenwerking is dus essentieel voor het ontwikkelen van een succesvolle webapplicatie.
