# Software Development Methodologieën
Doorheen de jaren zijn er meerdere soorten methodologieën ontstaan om apps te ontwikkelen. Er is niet éen beste methode die voor iedereen goed zal werken dus ontstaan er steeds nieuwe stromingen. In dit hoofdstuk behandelen we enkele populaire methodes waar jullie in de toekomst nog zeker en vast zullen horen.
# Wat?
Een software development methodologie is een gestructureerd proces dat men zal volgen bij het ontwikkelen van software. Het is een combinatie van design filosofieën, de fases van development en project management. Het doel van zo’n methodologie is een systematische aanpak hanteren bij doorheen verschillende projecten. Dankzij deze methodologieën kunnen developers onderling, maar ook developers, designers, project-managers etc. beter en efficiënter samen werken. Het bepaalt op welke manier en wanneer bepaalde informatie zal worden gedeeld binnen een team.
Doorheen de geschiedenis evolueren deze methodologieën natuurlijk omdat ze zich aanpassen aan de huidige technologieën. Je wil natuurlijk dat je aanpak zo efficient mogelijk is en nauw aansluit met je tech-stack. Hierdoor zijn er vele verschillende aanpakken met elk hun eigen voor- en nadelen. Welke methodologie een team zal gebruiken hangt volledig af van de samenstelling van dat team en zelf soms van het project, maar éen ding is wel zeker: een software development methodologie hanteren is cruciaal voor een goede samenwerking.
# Waarom?
Zonder een vaste structuur of work-flow kan er heel wat misgaan in een project. Developers lopen het risico dat er voortdurend nieuwe wijzigingen worden gevraagd door de klant, dat er miscommunicatie is tussen te designers en developers… Dit leidt tot inefficiënt development waar men niet vooruit geraakt, dit kost dus ook meer geld, kan architecturale fouten veroorzaken en gewoonweg een minder goed product opleveren. Daarom is het belangrijk dat we voor de aanvang van een project een bepaalde methodologie aannemen en deze ook strikt opvolgen.
Het aannemen van een van deze methodologieën kan aanvoelen als een karwei en neemt veel tijd in zeker bij de start van een project maar je plukt er sowieso de vruchten van later in het project, zowel voor jou als de klant is het dus een voordeel. Je kan namelijk accurater de ontwikkelingsduur inschatten en de volledige flow zal meer gestructureerd zijn.
# Modellen
Er zijn bijna oneindig veel methodologieën en er komen er ook nog elke dag bij, je zal echter de meeste methodologieën kunnen indelen drie modellen: een waterval, iteratief en continu model.
# Watervalmodel
Het watervalmodel is gebaseerd op het beeld van een waterval. Je kunt niet terugkomen op eenmaal genomen stappen. De stappen volgen op elkaar en het proces wordt van boven naar beneden doorlopen. Na elke stap wordt er doorgegaan met de volgende stap. Net als bij het bouwen van een huis wordt er na het bouwen van de muren niks meer gedaan aan de fundering. Als er geen iteratie in de planning is opgenomen kan er in principe niet meer teruggegaan worden naar een eerdere stap om fouten te verbeteren. Nadelen van deze methode is dat het lang duurt voor er resultaten zichtbaar zijn, en als ze dan zichtbaar zijn, zijn ze moeilijk te herstellen. Het is een goede methode als de (interne)klant / gebruiker in de analyse goed kan vertellen wat ze wil en was daarom vroeger populairder toen de scope van projecten beperkter was dan nu.
# Iteratief model
Dit model focust meer op het herhaaldelijk herzien van de code. Dankzij meerdere sprints zal men sneller features ontwikkelen en deze ook onmiddellijk testen. Op deze manier worden de problemen (zowel bugs als UX, UI…) sneller ervaren en dus ook vrij snel opgelost. Zo blijft de achterstand beperkt en kunnen teams zich houden aan de planning. Agile en Scrum zijn bekende voorbeelden van een iteratief model.
# Continu model
Het continu model is gebaseerd op het Toyota Production System. De insteek is dat er zo min mogelijk onderbroken wordt en er een vlotte transitie is tussen de verschillende fases van development. Het doel van dit model is zo min mogelijk overbodige code schrijven, niets ‘extra’ doen, zo min mogelijk ‘waste’ creëren en snel het eindproduct kunnen afleveren. Lean development is hier het meest bekende voorbeeld van.
# Populaire methodologieën
# Agile
Agile development is tot op heden de meest populaire methodologie, het is een van die buzz-words die je nog veel zal horen en waar kleine agencies en marketeers graag mee uitpakken. Deze methodologie wijkt af van de klassieke lineaire flow en zal de taken opdelen in verschillende sprints. Zo’n sprint duurt meestal tussen 1 en 4 weken, op het einde van een sprint wordt het resultaat uitvoerig getest. Tijdens een sprint werkt men nauw samen en vraagt men veel feedback.
Agile is een gepaste methode voor projecten met een snel wijzigende scope, perfect wanneer men iets voor het eerst moet doen, voor een nieuwe ‘niche’ met een onvoorspelbare scope.
‘Agile’ wordt meer en meer een filosofie en er zijn meer specifieke methodologieën ontstaan zoals FDD en SCRUM die zich gebaseerd hebben op deze filosofie.
# Voordelen
- Weinig bugs dankzij het iteratieve test proces en fine-tuning
- Transparantie en duidelijkheid tussen teamleden
- Wijzigingen in de scope of features zijn makkelijk aan te pakken en hebben weinig impact op de deadline
# Nadelen
- Risico op te veel wijzigingen waardoor men de essentie ‘vergeet’
- Documentatie is minder belangrijk waardoor men hier later in de problemen kan komen
- Agile werkt enkel indien er veel gecommuniceerd wordt, dit kan veel kostbare tijd innemen
- Binnen sprints moeten developers alleen kunnen werken en zelf beslissingen kunnen nemen
# Waterval methodologie
De waterval methodologie is nog steeds relevant ook al is dit een van de eerst ontwikkelde aanpakken. Het is namelijk makkelijker te begrijpen en dankzij de vaste structuur is het aangenamer voor een minder ervaren team (in tegenstelling tot Agile development). Iedere fase moet volledig afgerond zijn voor men verder gaat naar de volgende, zo zal men bijvoorbeeld niet beginnen designen zonder copy, en niet beginnen developen zonder design etc. Het is dus niet flexibel en ook niet gepast wanneer er veel wijzigingen gevraagd zullen worden.
Gebruik dus enkel deze methodologie voor projecten met een duidelijk afgebakende scope. Als er nog veel zaken onduidelijk zijn is dit niet de gepaste methodologie.
# Voordelen
- Makkelijk te begrijpen en naleven door minder ervaren developers
- Alle specificaties en assets zijn er voor de start waardoor het aangenaam werken is
- Geen ruimte tot miscommunicatie of onvoorspelbaarheden aangezien alles mooi is afgebakend voor iedere fase
# Nadelen
- Je kan de bal misslaan aangezien er geen customer feedback is de eerste fases
- Testing gebeurt pas op het einde, hierdoor kan het probleem moeilijker op te lossen zijn
- Er is geen of weinig ruimte voor aanpassingen, dit maakt het ongeschikt voor complexe projecten
- Documentatie en afbakening is heel belangrijk waardoor er minder focus is op echt development en problem-solving
# Lean development
Lean development focus zich op het vergroten van de productiviteit en zo min mogelijk ‘waste’ creëren. In het kort willen we met deze methodologie alles wat niet-productief is elimineren uit onze workflow en willen we automatiseren wat kan. Het is wel zo dat er tijd zal worden uitgetrokken om nieuwe zaken te leren en alle mogelijkheden te overwegen bij het maken van een keuze.
Voor de aanvang van een project moeten developers en andere team-leden bepalen wat voor hun ‘bottlenecks’ zijn die het proces vertragen en op zoek gaan naar een oplossing.
# Voordelen
- Minder verloren tijd door het minimaliseren van repetitieve zaken, overbodige code, onnodige documentatie
- Hierdoor is de kost ook minder aangezien het tijdbesparend is
- Door de verbeterde efficiëntie gaat het product sneller live
- Team leden hebben veel zeggenschap waardoor de motivatie groeit
# Nadelen
- Opdat dit zou werken heb je ervaren developers nodig
- Minder ervaren developers kunnen overweldigd worden door de verantwoordelijkheden en de focus verliezen op het project
- Gedetailleerde documentatie is vereist, dit kost ook veel tijd en moeite
- Tools voor automatisatie evolueren en zaken kunnen sneller verouderd zijn
# SCRUM
SCRUM is gebaseerd op Agile development en dankzij deze methodologie zal een team incrementeel en iteratief te werk gaan. Bij deze insteek gaan we de betrokkenen indelen als volgt:
- Product owner: communiceert met de klant en zorgt ervoor dat het team de wensen van de klant naleeft (tijdlijn, budget, scope, taken toelenen…)
- Scrum master: Volgt het scrum proces op en zorgt dat het team dit opvolgt (coachen, zorgt ervoor dat teamleden zelf werk uitkiezen en uitsplitsen tot taakniveau, faciliteert communicatie in development team)
- Development team
Dankzij de relatief korte sprints van maximaal 4 weken kan het team
# Voordelen
- Problemen geraken vlot opgelost door de vele iteraties
- Regelmatige feedback zorgt ervoor dat er features mogen wijzigen
- Regelmatige meetings zorgen er voor dat iedereen altijd weet wat er aan de hand is
- In deze scrum meetings worden individuele prestaties opgemerkt en beloond
# Nadelen
- Daily scrum meetings zijn vermoeiend
- Iedereen moet even gemotiveerd zijn en de scrum mentaliteit hebben
- Gaat moeilijk voor grote projecten
# DevOps
De DevOps methodologie slaat niet enkel op de Developmentfase maar ook de opeenvolgende Operations. Het schrijft een volledige organisatie voor en faciliteert de banden tussen verschillende teams die andere taken uitvoeren.
# Voordelen
- Sneller live
- Minder fouten bij nieuwe releases, fixes…
- Continuous integration (CI)
# Nadelen
- Sommige klanten willen geen voortdurende updates
- Sommige sectoren vereisen strenge testing voor we de stap zetten naar operations (bank-software)
- Kunnen problemen geven als er verschillende servers worden gebruikt
- Niet alles kan geautomatiseerd worden
# Rapid Application Development
RAD werd geïntroduceerd in 1991 en focust zich op het zo snel mogelijk afleveren van een product zonder in te boeten op de kwaliteit. Het baseert zich op 4 vaste stappen maar is wel niet lineair.
- Afbakenen van de project scope en assets verzamelen
- Prototyping
- Testing
- Implementatie
In tegenstelling tot een lineair proces zullen we deze stappen vaak herhalen en zo snel mogelijk laten testen door de klant. Dit herhalen we tot de klant tevreden is met het resultaat.
Om dit mogelijk te maken zetten we in op RAD tools, dit zijn low-code of no-code apps op sneller te ‘developen’.
# Voordelen
- Minder risico dankzij regelmatige feedback van de klant
- Klant is meer tevreden door nauwe samenwerking
- Goede flow voor kleine tot middelgrote projecten
- Product zal sneller live gaan
# Nadelen
- Zeer afhankelijk van de klant en zijn feedback
- Ervaren developers en teamleden vereist
- Gaat moeilijk als er een klein budget is aangezien het onvoorstelbaar is hoeveel iteraties er moeten zijn
# Feature driven development
FDD is een methodologie gebaseerd op Agile development. Het doel van deze methodologie is het vermijden van fouten en tijdverlies. We delen de applicatie op in een aantal features en verdelen deze onder de verschillende developers. Het is niet zozeer het opdelen in software features (zoals ‘Registreren’) maar eerder qua development (zoals ‘2 Factor Auth’, ‘Login Form Front-end’, ‘Auth Controller’, …). Een feature ontwikkelen mag niet erg lang duren, meestal wordt er een maxima van 2 weken gerekend maar het kan ook dat een feature maar een namiddag duurt.
Deze aanpak is perfect voor grote teams én grote applicaties, de communicatie verloopt vooral via de documentatie.
# Voordelen
- Complexe taken worden onderverdeeld in kleinere, simpelere subtaken. Dit is bevorderend voor de efficiëntie.
- Teamleden kunnen op hetzelfde moment aan verschillende taken werken, dit dankzij feature-branches (Git).
- Voorspelbaar dankzij afspraken onderling
# Nadelen
- Niet geschikt voor kleine projecten
- Project manager of lead developer zijn heel belangrijk
- Soms werken zaken minder goed samen doordat zaken afzonderlijk worden ontwikkeld