Software ontwikkel je als team
De meeste software trajecten zijn groot, bestaan uit veel modules en complexe integraties, of vragen veel onderhoud en zijn enorm aan verandering onderhevig. Dat betekent dat zo’n project niet door één developer ontwikkeld gaat worden, maar door een team. Werken in teamverband maakt een project complexer en zal dan ook volgens een solide methodiek uitgevoerd moeten worden. Zeker als het team op de lange termijn een kwalitatief product wil neerzetten terwijl ze binnen tijd en budget blijven.
Software ontwikkelingsmethode
Bij maatwerk software ontwikkeling via de Scrum methode wordt een project opgedeeld in stukken, zogenaamde “epics” en “issues”, waarbij er een aantal worden uitgekozen om tijdens een sprint (een ontwikkelperiode van één of twee weken) te ontwikkelen. Hoe groter een project, hoe meer dit er zullen zijn. Bij een groot project loopt het aantal issues vaak in de tientallen of zelfs honderdtallen op, wat complex kan worden om te managen en in goede banen te leiden. Hiervoor worden vaak één of meerdere tools gebruikt, hier kom ik later op terug.
Deze epics/issues worden ofwel in serie of parallel aan elkaar ontwikkeld tijdens de sprint, wat betekent dat er vaak meerdere teamleden en disciplines op korte termijn binnen dezelfde stukken code aan het werk zijn. Aangezien de code vaak meerdere (grote) veranderingen zal zien op dagelijkse basis en één bestand door meerdere developers aangepast moet kunnen worden, is een goed systeem nodig om dit te faciliteren. Honderden Google Drive documenten met steeds hoger optellende versienummers en het handmatig samenvoegen van de verschillende wijzigingen is voor software geen werkbare methode dus.
Dit gaat dus niet werken voor software.
Welke tools zijn er nodig voor software development?
Git
De ontwikkelaar van Linux, Linus Torvalds, dacht in 2005 dat het beter kon. Er waren wel andere versiebeheer systemen zoals BitKeeper maar Linus had hogere eisen en een beter idee. Dus hij ontwikkelde Git. Git is het versiebeheer systeem waar websites zoals GitHub, GitLab en Bitbucket allemaal op draaien. Zij bieden als het ware alleen een interface en hosting voor het systeem, maar alle achterliggende logica draait op Git.
Om Git volledig uit te leggen zou ik nog een hele post nodig hebben, dus ik ga het hier wat korter (en minder technisch) proberen te houden. Je kunt de Git structuur een beetje zien als een boom (Git tree/repository) met takken (branches). Een project heeft meerdere branches, bijvoorbeeld een hoofdbranch, test branch en module/feature/persoonlijke branches. Wanneer een developer aan de slag gaat voor een bepaalde module maakt hij vaak een nieuwe branch aan. Die branch is op dat moment een exacte kopie van een hoger liggende branch zoals de testbranch, een vertakking dus :).
Wanneer de developer klaar is met zijn werkzaamheden zal hij de wijzigingen opslaan naar hun favoriete Git cloud (wij kiezen voor GitLab!). Dit opslaan van wijzigingen gebeurt met een “commit”, vergelijkbaar met een “patch”. De reden waarom ik wijzigingen zeg, is omdat een bewerkt bestand geen volledig nieuwe versie krijgt. Alleen de regels/tekens die zijn aangepast worden opgeslagen en Git weet daarna hoe het complete bestand er uit ziet. De geschiedenis van een project ziet er voor Git dan dus uit als één lange lijst aan wijzigingen.
Een voorbeeld van een wijziging in een commit. Rood is weg, groen is nieuw.
Wanneer de developer klaar is met de functionaliteit, is het tijd om de test- en hoofdbranches te updaten met deze nieuwe wijzigingen. Dit gebeurt via een “merge”. Een andere developer controleert alle wijzigingen en wanneer deze zijn goedgekeurd vindt de merge plaats. Alle code wordt samengevoegd, inclusief deze nieuwe wijzigingen. Dit is iets wat Git volledig automatisch regelt. Als meerdere developers aan hetzelfde bestand hebben gewerkt zal dit allemaal super soepel verlopen. Als ze aan dezelfde regels code werken, zal het handmatig moeten! Tenslotte updatet de developer zijn eigen branch weer met de nieuwste code van de hoofdbranch, of maakt hij een nieuwe vertakking. Tijd voor de volgende functionaliteit!
Een grafische weergave van hoe verschillende branches in elkaar mergen, welke developer de commits maakte, en wat voor veranderingen er in die commits zitten.
Issuetracking
Om de ontwikkeling van een applicatie soepel te laten verlopen moet deze van tevoren gedefinieerd worden. Dat wil zeggen dat voor alle stakeholders en de developers duidelijk moet zijn wát er nu precies ontwikkeld gaat worden en dat iedereen er hetzelfde in staat. Dit wordt bereikt in een paar stappen:
- Het idee
Het “core” idee van de applicatie moet duidelijk gedefinieerd worden. Hierbij kun je denken aan vragen als wat moet de applicatie gaan doen? Wie gaat gebruik maken van de applicatie? Welk probleem lost de applicatie op? Op welke manier gaat de applicatie inkomsten genereren (of is het enkel voor intern gebruik)? Hier hebben wij een blogpost over geschreven. - Epics
Als voor iedereen duidelijk is wat de doelstelling is, kunnen we deze gaan opdelen in stukken, zogenoemde epics. Dit zijn meestal grote onderdelen die op logische wijze zijn gebaseerd op het idee. Dit kunnen bijvoorbeeld pagina’s zijn zoals een checkoutpagina of registratiepagina, of grote overkoepelende functionaliteiten zoals meertaligheid of een white-label structuur voor de applicatie. - Issues
Een epic kan vervolgens onderverdeeld worden in issues. Een issue wordt hier niet zozeer vertaald als “probleem” maar eerder als een “punt” of “kwestie”. Dit is meestal het niveau waarop samen met de product owner dieper ingedoken wordt op hoe de functionaliteit precies moet werken, om deze vervolgens in te delen in sprints. Als we de checkoutpagina als voorbeeld epic nemen, zou deze onderliggende issues kunnen hebben als het design van de pagina, het ontwikkelen van de front-end en een back-end koppeling met een boekhoudingspakket. - Subtasks
Als laatste niveau zijn er dan nog subtasks. Dit wordt meestal intern door de developers zelf gedaan, en is weer simpelweg een manier om de issues in kleine behapbare taken te definiëren. Voor het ontwikkelen van de de front-end van de checkoutpagina zou dit kunnen bestaan uit het implementeren van het design en de huisstijl, het opzetten van een formulier voor de betaalgegevens en het doorsturen van de formulier data naar de back-end en het verwerken van de antwoorden uit de back-end.
In een ideale wereld zouden deze lagen volledig van tevoren gedefinieerd zijn, maar dit is meestal niet zo omdat het onrealistisch is om van een opdrachtgever te verwachten dat hij of zij ieder detail heeft uitgedacht, daar heb je in de meeste gevallen namelijk een technische achtergrond voor nodig. Vaak is enkel het idee of tot het epic niveau bepaald hoe de applicatie eruit moet zien. Dat betekent dat de developers moeten uitwerken wat volgens hen de onderliggende issues en subtasks zijn om deze vervolgens weer te bespreken met de stakeholders zodat iedereen aligned is en iedereen met dezelfde visie aan het werk gaat. Alleen op de manier heb jij als stakeholder straks het eindproduct waar je naar op zoek was.
Resultaat: de scope of work en Jira
Wanneer dan de uiteindelijke lagenstructuur tot en met subtasks helemaal gedefinieerd is, zijn we aangekomen bij de “scope of work”. Dit beschrijft tot in de puntjes wat er wel- en niet ontwikkeld gaat worden, en hoe elke functionaliteit werkt en met elkaar gekoppeld is. De volgende stap is het inrichten van de tooling voor tijdens het project. Hiervoor zijn veel verschillende opties; Google Sheets, Trello, Post-It notes, Jira en meer. Jira is veruit de populairste en wordt door ons ook bij een aantal projecten gebruikt, voor de rest van deze uitleg zal ik de post dan ook richten op Jira.
Wat een issuetracking tool zoals Jira doet is het inzichtelijk maken van het project en de voortgang, het maakt het eenvoudig om issues onder te verdelen in sprints. Daarnaast biedt het nog mogelijkheden voor het plaatsen van opmerkingen, het bijhouden van een centraal data deelpunt (wiki) en meer. Dit maakt het voor de developers erg fijn om in te kunnen zien wat hun takenpakket is en hoe het project vordert. Ook voor de klant is het dan dus duidelijk! Het inrichten van Jira is een eitje: alle epics, issues en subtasks zijn op dit punt gedefiniëerd dus deze kunnen als het ware één op één overgekopieerd worden.
Een voorbeeld van het Scrum-board in Jira met verschillende epics/issues/subtasks. Hierin is meteen zichtbaar wie wat aan het doen is en wat de status is.
OTAP
Als laatste onderdeel van tooling wil ik nog even OTAP belichten. Dit staat voor Ontwikkel, Test, Acceptatie en Productie. In de basis is dit een werkmethode die staat voor een gefaseerde aanpak van het ontwikkelproces. Dit wordt niet bij ieder softwarebureau zo aangepakt maar wij zijn hier grote voorstanders van. Dit is ook waar de issuetracking en Git workflow mooi bijeen komen. In het kort:
- Ontwikkel: dit is de computer van de developer zelf. Hier wordt de functionaliteit ontwikkeld en getest voordat deze gemerged wordt naar de development Git branch. De developer update de issue/subtask in Jira naar IN PROGRESS/DOING.
- Test: wanneer de code is goedgekeurd en op de development branch staat, wordt deze “gedeployed” naar de testomgeving. Hier test de developer nog een keer zijn/haar functionaliteit en worden eventueel problemen iteratief gefixt totdat alles goed is. De developer zet de status in Jira op TESTING.
- Acceptatie: de code wordt nu gedeployed naar de acceptatie omgeving en de klant wordt ingelicht dat deze klaar staat om te controleren. Is de code niet goed, dan gaat de developer weer op zijn eigen omgeving aan de slag om de feedback te werken, anders kan de functionaliteit meteen opgeleverd worden. De bijbehorende status in Jira is REVIEW.
- Productie: de functionaliteit is afgerond, de code wordt gemerged naar de master branch, en wordt gedeployed naar de productie/live omgeving. De status in Jira is DONE.
Deze werkwijze zorgt ervoor dat de code en functionaliteiten in meerdere fases worden getest en door meerdere mensen geverifieerd. Uiteindelijk komt er altijd een compleet werkend plaatje op de live omgeving te staan. Mocht er ergens in het proces iets fout zijn gegaan, gaat de developer weer aan de slag om feedback of bugs te verwerken. Dit is dus net als Scrum een iteratief proces waarbij problemen vroeg geïdentificeerd worden en dat zorgt voor veel inzicht in de verloop van het project.
Succesvol software ontwikkelen
Deze tools zijn natuurlijk heel tof, maar bieden op zichzelf geen oplossingen voor alles wat nodig is om een project soepel te laten verlopen en succesvolle webapplicaties te ontwikkelen. De tools zijn enkel facilitatoren hiervoor. Het allerbelangrijkste blijft nog steeds het contact tussen de projectmanager, Scrum master, developers en de klant. De klant is uiteindelijk degene die het beste weet hoe het eindproduct er uit moet zien vanuit een zakelijk perspectief, en is degene met de domeinkennis van zijn/haar branche. Dit is waarom wij ervoor hebben gekozen om niet alles via email te doen, maar direct met al onze klanten (we noemen ze liever partners) in een Discord server zitten. Discord is vergelijkbaar met Slack, maar biedt volgens ons veel meer opties: calls, videocalls, eenvoudig aanmaken van groepsgesprekken en mogelijkheden zoals scherm delen. Op deze manier kunnen aan beide kanten vragen worden gestuurd die vaak binnen een paar minuten al beantwoord zijn.
“Hey @Stakeholder, ik heb de volgende punten in Jira op REVIEW gezet en bij deze staan ze op de acceptatie omgeving, zou je die kunnen checken?”.
“On it!”
