Een catchy naam en een intern wiki-artikel. Meer heb je natuurlijk niet nodig voor een eigen methodologie. Maar wat is nu precies de reden dat we dit nodig hadden? Als internetbureau lopen wij tegen andere problemen aan dan productteams. De doorlooptijden zijn kort, het aantal projecten waar je aan werkt is hoog en het resultaat moet minstens zo goed zijn als het ontwerp.
Dit wil dus zeggen dat we projecten zo moeten insteken dat:
- We zo snel mogelijk parallel aan elkaar kunnen werken, om zo de doorloopsnelheid te verhogen.
- We individuele componenten kunnen laten reviewen door ontwerpers, zodat we de workload over verschillende disciplines gelijkmatig over de looptijd van het project spreiden.
- We zo min mogelijk aannames maken over de onderliggende technologie. Denk hierbij aan programmeertalen, frameworks, template syntax, etc.
Inmiddels hebben we Component Storming toegepast bij het realiseren van complete single-page JavaScript applicaties, frontend component libraries en op corporate websites, ontwikkeld op basis van een traditionele template taal zoals Twig.
Niet meer helemaal scherp wat componenten ook alweer zijn? Lees ons artikel over component-based werken.
Hoe Component Storming werkt
Samenwerken vereist communicatie. Hoewel onze ontwerpcollega’s snappen hoe je in (design-)systemen moet denken, is de eerste stap dat onze frontenders samen bepalen wat wat is én wat een component is. Samen doorlopen we één voor één de individuele paginatemplates én beantwoorden we de volgende vragen:
- Wat zijn de individuele componenten op de pagina?
- Bestaat het component uit meerdere subcomponenten, of is er een parent component dat het component insluit?
- Maken we een nieuw component, of hergebruiken we een bestaand component?
- Hoe gaat het individuele component heten?
- (Optioneel) Wat zijn de argumenten die het component verwacht? Het is niet altijd noodzakelijk om deze discussie direct te voeren, maar wel wanneer er onduidelijkheid is over de interactie tussen componenten.
Hoewel dit ongelofelijk basaal klinkt, is het vroegtijdig hebben van deze discussie cruciaal. Er is namelijk geen harde regel wat precies een component is. Vraag twee frontenders een component op een pagina de definiëren, en je krijgt drie verschillende antwoorden. De keuze om een component te hergebruiken, of een nieuw component te maken is subtiel, maar kan grote gevolgen hebben. Ook bouw je direct een gemeenschappelijk taal; nu weten we allemaal wat er bedoeld wordt met het “ContractProgressBar” en hoe deze anders is van het “ProgressBar” component.
Maar dit is niet waar Component Storming stopt. Wanneer het eerste paginatemplate is besproken, worden de individuele componenten direct aangemaakt. Wanneer je een frontend framework gebruikt, beschik je vaak over een command-line-tool om snel componenten aan te maken. Met een simpele copy-paste kom je natuurlijk ook een eind. Vervolgens “nesten” we de verschillende componenten zoals net besproken. Op die manier leg je direct vast wat je zojuist besproken hebt. Niet in documentatie, maar in de daadwerkelijk codebase.
Voor single-page applications gaan we nog een stapje verder. We bouwen niet alleen de individuele pagina’s op, maar definiëren ook direct de “routes”–zeg maar de URLs die er voor zorgen dat er daadwerkelijk wat weergegeven wordt wanneer je een pagina in de browser bezoekt. Nog zo’n ding waar ontwikkelaars eeuwig over kunnen discussiëren, maar ook dit schept direct duidelijkheid.
Wanneer de Component Storming sessie is afgerond, zorgt één frontender voor het vastleggen wat er tijdens de sessie is besproken. Dit zijn concrete resultaten van de Component Storming sessie en zorgen voor een solide basis voor de rest van het frontend ontwikkelproces.
- De aangemaakte componenten (en routes) worden toegevoegd in versiebeheer (vaak pakken we even een uurtje voor de sessie om een startproject klaar te zetten).
- Elk component krijgt een eigen issue in onze issue tracker, met een referentie naar het ontwerp en Storybook.
Op dit moment heb je dus een hele basale structuur van het frontend staan, plus een duidelijk overzicht met de uitstaande taken. Wanneer we daadwerkelijk aan de frontend implementatie beginnen, zien we stukje-bij-beetje het project tot leven komen. De focus ligt dan voornamelijk op een goede implementatie van het ontwerp. Discussies over naamgeving en structuur zijn bijna niet meer nodig.
Waarom Component Storming werkt
Component Storming is dus zeker geen hersenchirurgie, maar deze manier van werken levert ons wel veel op. Laten we nog even teruggrijpen naar onze originele problemen:
- Parallel werken - Doordat componenten per definitie geïsoleerde stukken functionaliteit zijn, zit je elkaar minder in de weg. Door samen te bepalen wat een component is, bespreek je van tevoren waar de grenzen tussen verschillende taken liggen. Wanneer je Component Storming combineert met Tailwind, gaat het helemaal snel. Dit omdat je nog minder hoeft na te denken over onnodige naamgeving én geen gemeenschappelijke codebase hoeft te onderhouden (voor bijvoorbeeld een grid of typografie); anders dan je Tailwind configuratie.
- Overzicht - Starten kan een probleem zijn omdat je de hele architectuur niet kan overzien. Doordat het raamwerk klaarstaat, kan elke betrokken frontender ergens “tegenaan” werken. Dat zorgt ervoor dat je lekker kan knallen en niet tegen een schrijversblok (writers block) aanloopt.
- Vroegtijdig reviewen - Voorheen stelden wij het reviewen van de geïmplementeerde ontwerpen uit totdat de volledige paginatemplates af waren. Wanneer je met componenten werkt, is dit niet langer nodig. Daarnaast is het een stuk makkelijker om componenten in een vroeg stadium te delen door gebruik te maken van tools zoals Storybook.
- Weinig technische aannames - Wanneer je aan een groot aantal websites en applicaties werkt, heb je het niet altijd voor het zeggen. Daardoor was het voor ons belangrijk dat we een methodiek ontwikkelden die we altijd kunnen toepassen, ongeacht van de gebruikte technologie. Idealiter maak je gebruik van Web Components, of componenten in een frontend framework zoals React. Maar Component Storming is ook prima toe te passen wanneer je wat traditionelere template-talen gebruikt, die gerenderd worden op het backend. Denk hierbij aan Twig, Haml of Jinja.
Toch is het naar voren halen van mogelijke discussies het belangrijkste speerpunt van Component Storming. Door het vastleggen van deze discussie in de codebase creëer je geen “paper tiger”, maar een solide basis om op door te bouwen–zonder “waste”.
Wil je meer weten over Component Storming, en weten wat het jouw organisatie kan opleveren? Spar dan een keer vrijblijvend met een van onze experts. We denken graag mee!
Keertje sparren? Plan een afspraak in
Component Storming is tot stand gekomen door het werk van onze frontend experts Arjen en Rick.
