Recept voor goede software

uit het Arlanet kookboek

Geschreven door: op

Goede scope, goede vragen
Het bouwen van software begint niet achter de computer. Allereerst moet het duidelijk zijn wat er precies gemaakt moet worden en dat gebeurt tijdens het definiëren van de scope van een project. Wanneer je deze scope opzet en verder vraagt, merk je al snel dat er veel vragen naar voren komen. Ga deze vooral niet uit de weg en beantwoord ze voordat je aan het project begint. Meer kennis van een probleem of gewenste oplossing kan namelijk leiden tot een andere architectuur.

To the drawing board
Wanneer de projectscope duidelijk is zal de oplossing bedacht moeten worden. Doe dit op zowel functioneel als technisch vlak en gebruik waar mogelijk alvast wat visuele voorbeelden. Veel mensen zijn visueel ingesteld en een grafische voorstelling heeft vaak meer impact meer dan een lap tekst.

Is het project groter, maak dan gebruik van wireframes. In een wireframe model wordt de oplossing in schetsvorm neergezet. Tijdens dat proces wordt er al nagedacht over de indeling, functionaliteit en interactie van een applicatie. Het design en de applicatie worden ontwikkeld n.a.v. de keuzes die in dit traject gemaakt zijn. Onderschat daarom niet het belang van deze oefening!

Strak proces, flexibele sprints
Er is nog steeds geen regel code geprogrammeerd en ook in deze stap zal hier nog niet aan begonnen worden. Een goede projectorganisatie is namelijk onmisbaar voor het juist samenwerken en sturen van het team. Zorg dat de scope wordt overgenomen als backlog zodat je deze kunt indelen in sprints. Hiermee stel je binnen een korte periode een duidelijk doel met verwachting neer voor zowel team als klant. Wanneer je hier meting bij gebruikt is het een krachtige tool. Dit kan door specifieke Agile software te gebruiken of simpelweg post-its op de muur te plakken.

Tip: Ontdek in 3 uurtjes de basis van de Agile Scrum methode in dit korte verhaal:"De kracht van Scrum" van Eelco Rustenburg.

Trunks, branches en shelvies
Niet alleen moet je het project vanuit een projectmethode inrichten, ook zul je het project in de techniek moeten opzetten. Wanneer je met een team werkt aan een applicatie ben je los van elkaar aan stukjes code aan het ontwikkelen, waarna deze code 'op een grote hoop' gegooid wordt. Programmeurs noemen dit inchecken.

De gemaakte afspraken voor ontwikkeling kunnen een grote invloed hebben op de flexibiliteit van oplevering en kwaliteit na oplevering van een sprint. Achter dat inchecken zit namelijk een bak met code die gestructureerd is als een boom, met een trunk (stam) en branches (takken). Iedere branche is een aparte ontwikkeling welke apart van de trunk ontwikkeld en gereleased kan worden. Ben je klaar met een branche, dan moet je deze weer mergen (samenvoegen) met de trunk. Hier kunnen natuurlijk verschillen ontstaan in bestaande code. Al met al is het leven van een programmeur ook niet altijd zo eenvoudig als het lijkt!

Proof of Concept
Ah, eindelijk zijn we in de code beland. Alle afspraken zijn gemaakt, de oplossing staat op papier en zowel binnen het project als de code zit structuur. Dan nog kan het voorkomen dat er technische knelpunten naar voren komen, bijvoorbeeld door het gebruik van nieuwe technieken of een combinatie hiervan. Wanneer je niet met zekerheid kunt zeggen of de technische oplossing goed gaat werken is het verstandig eerst een Proof of Concept (model) op te zetten. Hiermee kun je namelijk binnen een kleine, gecontroleerde omgeving alvast kijken hoe de techniek reageert. Als je weet dat de klant gemiddeld 10.000 producten heeft die in je applicatie terugkomen, test dan alvast de performance met 100.000 producten. Werkt dat, dan is de kans groot dan je uiteindelijke applicatie ook aan de eisen van de klant zal voldoen.

Testing en kwaliteit
Voor het gemak slaan we de lange dagen van code schrijven, bikkelen en ontwikkelen even over. Met focus achter de computer, de koptelefooon gevoed door Spotify en af en toe een sociale pauze (zoals de rokers het noemen) om even de gedachten op een rij te zetten. Hier gaat verreweg de meeste tijd in zitten. Maar voor nu gaan we even fast-forward richting de oplevering.

Wanneer de code is ingecheckt, de programmeurs hun code hebben afgetest en aangeven dat alles OK voor release is, moet je je zorgen gaan maken. Iemand die namelijk zijn eigen ontwikkeling test is geen goed recept voor kwaliteit. Het predikaat "het werkt" is niet waar de klant mee akkoord gaat, dus het is van belang dat iemand de release aftest vanuit de ogen van de klant. Hoe goed de code ook geschreven is en hoe foutloos het ook werkt, als het niet voldoet aan de verwachting van de klant is dat werk voor niets gedaan.

Tip: Mijn vorige blog "Testing in de praktijk" beschrijft dit proces in meer detail.

Kers op de slagroom
Het klinkt zo eenvoudig, maar is toch echt behoorlijk lastig om te realiseren: zorg dat je de klant verrast is met het resultaat. Dit hoeft niet altijd in de software te zitten. Begin dit jaar hebben we een project gedraaid welke we na een jaar hadden overgenomen van een andere partij. Binnen drie maanden stond de basis van de oplossing en kon de klant beginnen met invoer van haar eigen data. Afgezien van de techniek zorgde dit strakke ontwikkelproces voor een tevreden klant en basis voor vertrouwen.

Zolang je de verwachting overtreft kun je kudo's verwachten van de klant. Dit is helaas niet altijd mogelijk binnen de tijd en het budget, maar zodra je de kans hebt...

Conclusie
Het is bekend dat niet ieder project een scope heeft maar ook kan bestaan uit bijv. een Agile ontwikkelmethode waarbij de scope vooraf niet gedefinieerd is. Zo'n proces vereist een iets andere aanpak. Dit artikel is net als ieder ander advies; er is geen formule voor succes. Pak daarom vooral de onderdelen die voor jou van toepassing zijn en gebruik ze binnen je eigen organisatie.

Recept voor goede software Aantal keer bekeken: 4.055