Leestijd 8 min

Dorien Jorissen

Bij de ontwikkeling van software kunnen aannames ernstige gevolgen hebben en we moeten altijd op onze hoede zijn. In deze blogpost bespreken we hoe je omgaat met aannames bij het ontwikkelen van software. Stel je voor... je rijdt naar een bepaalde plaats Een plek waar je al 5 jaar lang elke dag naartoe rijdt, dezelfde route neemt, langs dezelfde verlaten straat rijdt, waar je nog nooit een andere auto hebt gezien. Langzamerhand begin je je vertrouwd te voelen met deze route en ga je ervan uit dat je zoals altijd de enige auto op deze weg zult zijn. Maar op een gegeven moment duikt er een auto vlak voor je op... er was al die tijd al een zijstraat, maar je had hem nooit opgemerkt, of misschien was je hem helemaal vergeten. Je trapt op de rem en komt gelukkig net op tijd tot stilstand. Aannames werden je bijna fataal. Gelukkig zijn de veronderstellingen die we in ons werk maken nooit zo gevaarlijk voor ons leven als de veronderstellingen die we in het verkeer maken. Toch kunnen veronderstellingen ernstige gevolgen hebben en moeten we altijd op onze hoede zijn. Stel je voor... je maakt websites Je laatste klant is op zoek naar een nieuwe site voor zijn bejaardentehuis omdat zijn huidige site verouderd en niet zo fancy is. Dus u bouwt een fancy nieuwe website in de veronderstelling dat fancy betekent: modern ontwerp, sociale functies, dynamische inhoud. De site is niet het succes dat hij had verwacht ... vreemd ... je hebt precies gebouwd wat je klant wil. Maar heeft u gebouwd wat de bezoekers van de site willen? De gemiddelde gebruiker is tussen de 50 - 65 jaar oud, op zoek naar een nieuw huis voor hun vader en moeder. Ze zijn geen digital natives en voelen zich misschien niet thuis op een mooie, dynamische website vol twitterfeeds en sociale knoppen. Het enige wat ze willen is een goede indruk krijgen van het bejaardentehuis en gerustgesteld worden over het feit dat er goed voor hun ouders zal worden gezorgd. Hoe meer ervaring je krijgt, hoe harder je moet oppassen geen aannames te doen en dubbel te checken met je klant EN de doelgroep . Een ander bekend gevaar van ervaring is " de vloek van de kennis ". Hoewel het klinkt als de volgende Pirates of the Caribbean sequel, is de vloek van kennis een cognitieve bias die bijna iedereen met expertkennis in een specifieke sector overheerst. Het betekent dat beter geïnformeerde partijen het extreem moeilijk vinden om over problemen na te denken vanuit het perspectief van minder goed geïnformeerde partijen. Je kunt je afvragen waarom economen er niet altijd in slagen om de juiste beursvoorspellingen te doen. Iedereen die wat geld over heeft, kan aandelen kopen. Je hoeft geen expert te zijn of zelfs maar verstand te hebben van economie. En dat is de belangrijkste reden waarom economen er vaak naast zitten. Omdat ze expertkennis hebben, kunnen ze niet voorbij deze expertise kijken en kunnen ze zich moeilijk voorstellen hoe minder geïnformeerde mensen zullen reageren op veranderingen in de markt. Hetzelfde geldt voor IT. Daarom moeten we altijd een oogje in het zeil houden en blijven we in de huid kruipen van onze klanten. Inzicht krijgen in hun ervaring en standpunt is de sleutel tot het creëren van de perfecte oplossing voor de eindgebruiker. Dus hoe pakken we aannames aan ...? Ik zou graag zeggen "Eenvoudig" en je een prachtige oneliner geven ... maar zoals gewoonlijk ... is eenvoudig nooit het juiste antwoord. Om de drang om over te schakelen op de automatische piloot en de vloek van de kennis te laten werken, hebben we een methodologie ontwikkeld op basis van verschillende Agile-principes die ons dwingt om onze eindgebruiker te betrekken bij elke fase van het project, te beginnen wanneer onze klanten nadenken over een project, maar de oplossing nog niet hebben gedefinieerd. En eindigt... nou eigenlijk nooit. De eindgebruiker zal nieuwe inzichten opdoen door met uw oplossing te werken, wat kan leiden tot nieuwe verbeteringen. In de watervalmethode wordt aan het begin van een project een analyse gemaakt door een business analist. Soms wordt de gebruiker betrokken bij deze voorafgaande analyse, maar dit is niet altijd het geval. Dan maakt een conclaaf van ontwikkelaars iets in eenzaamheid en na de witte rook ... begint het gebruikersacceptatietesten (UAT) . Het moet pijnlijk voor ze zijn om zich na deze tests te realiseren dat het product dat ze zorgvuldig hebben gemaakt niet de oplossing is die de gebruikers ervan verwachtten. Het is te laat om ingrijpende veranderingen door te voeren zonder dat daar veel meer tijd en budget voor nodig is. Met een Agile projectmethodologie kom je een heel eind. Door elke 2 tot 3 weken testbare versies uit te brengen, kunnen gebruikers geleidelijk functionaliteit testen en hun feedback geven tijdens de ontwikkeling van het project. Deze aanpak houdt rekening met de inzichten van de gebruiker, die tijdens het project zijn opgedaan, en garandeert een betere match tussen de behoeften van de gebruiker en de oplossing die je voor hun behoeften creëert. Agile beoefenaars zijn voorstander van 'continuous deployment'; een praktijk waarbij nieuw ontwikkelde functies onmiddellijk worden uitgerold naar een productieomgeving in plaats van in batches om de 2 tot 3 weken. Dit stelt ons in staat om het systeem (en in essentie de aannames) in het wild te valideren, waardevolle feedback van echte gebruikers te krijgen en gerichte experimenten uit te voeren om te valideren welke aanpak het beste werkt. Door onze methodologie te combineren met constante betrokkenheid van gebruikers, elimineer je de ergste aanname in IT: we weten hoe de werknemers hun werk doen en wat ze nodig hebben ... het gevaar van ervaring! Elimineren we altijd aannames? Laat me het iets ingewikkelder maken: Nogmaals... stel je voor: je gaat al 10 jaar naar dezelfde supermarkt, het is vrij veilig om aan te nemen dat de cornflakes nog steeds in hetzelfde gangpad liggen, zelfs op hetzelfde schap als gisteren. Als je niet meer zou aannemen waar de cornflakes liggen... dan zou je enorm veel tijd verliezen door de hele winkel door te lopen. Niet één keer, maar steeds opnieuw. Hetzelfde geldt voor ons werk. Als we ons werk zouden doen zonder te vertrouwen op onze ervaring, zouden we geen inschattingen kunnen maken over budget en tijd. Elke schatting is gebaseerd op aannames. Hoe meer ervaring je hebt, hoe nauwkeuriger deze aannames worden. Maar leiden ze ook tot goede en betrouwbare schattingen? Niet noodzakelijk ... Terug naar mijn metafoor ... We nemen elke dag dezelfde weg naar het werk. Op basis van ervaring kan ik inschatten dat ik er 30 minuten over zal doen om naar mijn werk te rijden. Maar wat als ze files aankondigen op de radio en ik de aankondiging niet heb gehoord ... dan is mijn schatting niet juist. Bij ACA Group gebruiken we een aantal belangrijke werkwijzen bij het maken van schattingen. Ten eerste is het een teamsport. We maken nooit schattingen in ons eentje en hoewel schatten een serieuze zaak is, doen we het terwijl we een spelletje spelen: Planningspoker. Laat me je dit uitleggen; planning poker is gebaseerd op het principe dat we beter kunnen inschatten in een groep. Dus we lezen het verhaal (stuk functionaliteit) hardop voor, iedereen pakt een kaart (die een indicatie geeft van de complexiteit) en legt deze open op tafel. Als iedereen een kaart heeft gekozen, worden ze allemaal tegelijk omgedraaid. Als er verschillende getallen worden getoond, ontstaat er een discussie over het waarom en hoe. Veronderstellingen die de basis vormen voor iemands schatting komen naar boven en worden besproken en gevalideerd. Er volgt nog een schattingsronde en het proces gaat door tot er consensus is bereikt. Het eindresultaat: een betere schatting en een grondig begrip van de aannames die aan de schatting ten grondslag liggen. Deze expliciete aannames zijn er om gevalideerd te worden door onze belanghebbenden; een geweldig eerste hulpmiddel om ons begrip van de scope te valideren.Dus elimineren we altijd aannames? Nou, dat zou bijna onmogelijk zijn, maar door aannames expliciet te maken elimineren we een hoop verspilling. Wil je meer weten over deze Agile Estimation? Bekijk dan dit boek van Mike Cohn . Hé, dit is een tegenstrijdigheid... Hoe zit het dan met die aannames? Moeten we ze proberen te vermijden? Of moeten we erop vertrouwen? Als je ervan uitgaat dat je alles weet... zul je nooit meer verbazing ervaren. Zoals Aristoteles al zei: "Het was hun verwondering, verbazing, die de mensen ertoe bracht om te filosoferen". Welnu, een proces dat de gemaakte veronderstellingen valideert door middel van goed uitgevoerde experimenten en snelle feedback heeft bewezen geweldige resultaten op te leveren. Dus in essentie zal het goed beheren van je aannames prachtige dingen opleveren. Wees je er wel van bewust dat de vloek van kennis om de hoek loert, wachtend op een onbewaakt moment om het over te nemen. Geïnteresseerd in deelname aan ons team? Wil je een van onze teamleden ontmoeten? Geïnteresseerd om deel uit te maken van ons team? We zijn altijd op zoek naar nieuwe gemotiveerde professionals om het ACA-team te versterken! {% module_block module "widget_3ad3ade5-e860-4db4-8d00-d7df4f7343a4" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"View career opportunities"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":{"content_id":229022099665,"href":"https://25145356.hs-sites-eu1.com/en/jobs","href_with_scheme":null,"type":"CONTENT"},"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}

Leestijd 4 min

Dorien Jorissen

ACA doet veel projecten. In het laatste kwartaal van 2017 deden we een vrij klein project voor een klant in de financiële sector. De deadline voor het project was eind november en onze klant werd eind september ongerust. We hadden er echter alle vertrouwen in dat we de klus op tijd konden klaren en besloten een experiment uit te proberen. We brachten het team samen in één kamer en begonnen met mob-programmering . Maffia wat? We hadden een artikel gelezen waarin het concept van mob programming werd uitgelegd. In het kort komt mob programming erop neer dat het hele team samen in één ruimte zit en aan één user story tegelijk werkt. Eén persoon is de 'bestuurder' en doet het coderen voor een bepaalde tijd. Als die tijd voorbij is, gaat het toetsenbord over naar een ander teamlid. We probeerden het experiment met de volgende opzet: Ons team was relatief klein en had slechts 4 teamleden. Omdat het project waaraan we werkten relatief klein was, konden we maar 4 mensen aannemen. De user stories die we behandelden waren slechts een deel van het project. Omdat dit een experiment was, wilden we niet dat het project - zo klein als het was - volledig zou worden overspoeld. Daarom kozen we één specifieke epic en implementeerden we die user stories in de mob. We werkten niet op dezelfde computer. We hadden elk een aparte laptop en checkten onze code in op een centraal versiebeheersysteem in plaats van het toetsenbord te verwisselen. Dit was niet echt een keuze die we maakten, gewoon iets dat gebeurde. We wisselden elke 20 minuten. Het artikel waarnaar we verwezen heeft het over 12, maar we vonden dat te kort en besloten om in plaats daarvan 20 minuten te nemen. Klaar, af, af! We brachten meer dan een week door in een vergaderruimte waar we om de beurt onze laptops konden aansluiten op één groot scherm. De eerste dag van het experiment ontwierpen we. Urenlang stonden we achter het whiteboard om te beslissen over de architectuur van de component die we gingen bouwen. Op dezelfde dag begon onze groep met de implementatie van het eerste verhaal. We gingen er echt vandoor! We vlogen door de user story en riepen naar onze klantproxy als sommige vereisten niet duidelijk waren. Tegen het einde van de dag waren we uitgeput. Ons experiment was nog maar net begonnen en het was al zo intens. De volgende dagen gingen we verder met het implementeren van de user stories. In minder dan een week hadden we werkende software die we aan onze klant konden laten zien. Hoewel het nog niet perfect was en niet alle vereisten dekte, was onze software al na 3 dagen in staat om een volledige, gelukkige path flow uit te voeren. Twee dagen later implementeerden we verbeteringen en uitzonderingsgevallen die via andere user stories waren besproken. Er was nog maar een week verstreken sinds onze klant zich zorgen begon te maken en we hadden al zoveel geïmplementeerd dat we hem konden laten zien. De laatste hand leggen Tegen het einde van het project moesten we alleen nog wat technische zaken regelen. Een daarvan was het agnostisch maken van onze nieuw gebouwde softwareomgeving. Als we deze user story hadden afgewerkt met pair programming, zou één paar alle technische details van de software kennen. Met pair programming hoefden we het niet aan de rest van het team te laten zien. Het team wist het al. Omdat we laptops gebruikten in plaats van toetsenborden, had iedereen de setup op zijn eigen machine gedaan. Iedereen kende de commando's en de configuratie. Het was kennis delen op zijn best! Andere technische aspecten waren het correct configureren van onze software. Dit bleek een saaie taak te zijn voor de meeste navigators. Op dit punt besloten we dat het maffia-experiment ver genoeg was gegaan. We hadden het gevoel dat het niet de bedoeling was om dit soort taken met 4 mensen tegelijk te doen. Tenminste, dat is onze mening. Vlak voordat de groep uiteenviel, planden we een evaluatiebijeenkomst. We waren enthousiast en wilden dit opnieuw doen, misschien zelfs op grotere schaal. Onze ervaring met mob-programmering Het resultaat van ons experiment was erg positief. We ervoeren kennisdeling op verschillende niveaus. Alle betrokkenen kenden de volledige functionaliteit van de applicatie en we kenden allemaal de details van de implementatie. We waren in staat om snel een nieuw teamlid te integreren wanneer dat nodig was, terwijl we toch op een constante snelheid bleven werken. We hadden al gezegd dat we erg enthousiast waren voor, tijdens en na het experiment. Dit had een positieve invloed op onze teamgeest. We waren allemaal meer betrokken bij het project. Het nadeel was dat we mob-programmeren als vermoeiender ervoeren. We voelden ons uitgeput na een dag samenzijn, zij het op een goede manier! Volgende stappen Andere collega's zagen ons in onze vergaderruimte programmeren op een groot scherm. Er ontstonden gesprekken over het experiment. Onze opwinding werkte aanstekelijk: mensen waren meteen geïnteresseerd. We begonnen te praten over meer experimenten. Misschien zouden we mob-programmering kunnen doen in verschillende teams op verschillende projecten. En zo begint het... Heb jij ooit al eens mob-programmering geprobeerd? Of sta je te popelen om het te proberen? Laten we tips of trucs uitwisselen! We horen graag van je !

Leestijd 4 min

Gregory Van Dorpe

OutSystems: een katalysator voor bedrijfsinnovatie In het snelle zakelijke landschap van vandaag de dag moeten organisaties innovatieve oplossingen omarmen om voorop te blijven lopen. Er zijn veel strategische technologische trends die cruciale bedrijfsprioriteiten aanpakken, zoals digitale immuniteit, composability, AI, platform engineering, Low-Code en duurzaamheid. OutSystems , het toonaangevende Low-Code ontwikkelplatform , is een game-changer geworden in het ondersteunen van organisaties om deze trends efficiënt en duurzaam te implementeren. OutSystems verbetert cyberbeveiliging Omdat organisaties steeds meer vertrouwen op digitale systemen, vormen cyberbedreigingen een aanzienlijk risico. Daarnaast speelt de digitale interactie met klanten, medewerkers en partners een vitale rol in het welzijn van een bedrijf. De immuniteit en veerkracht van een organisatie is nu net zo sterk en stabiel als de digitale kernsystemen. Elke onbeschikbaarheid kan leiden tot een slechte gebruikerservaring, inkomstenverlies, veiligheidsproblemen en meer. OutSystems biedt een robuust en veilig platform dat helpt bij het opbouwen van digitale immuunsystemen die bescherming bieden tegen evoluerende cyberbeveiligingsuitdagingen. Met geavanceerde detectie van bedreigingen, continue monitoring, veilige codeerpraktijken en AI-code-scanning zorgt OutSystems ervoor dat applicaties veerkrachtig en beschermd zijn. Bovendien dekt het platform de meeste beveiligingsaspecten voor projectteams, zodat zij zich kunnen richten op het leveren van hoge waarde aan eindklanten, terwijl best practices door het platform worden aanbevolen door middel van codeanalyse met behulp van ingebouwde patronen. OutSystems vereenvoudigt het beheer van cloud-native infrastructuur Cloud-native architectuur is een essentieel onderdeel geworden voor moderne applicatieontwikkeling. Het OutSystems Developer Cloud Platform stelt teams in staat om eenvoudig cloud-native applicaties te maken en in te zetten, waarbij gebruik wordt gemaakt van de schaalbaarheid en flexibiliteit van cloud-infrastructuur via Kubernetes . Het stelt bedrijven in staat om: Het gebruik van resources te optimaliseren Applicatieruntimes automatisch schalen Operationele kosten verlagen Duurzame praktijken toe te passen (serverless computing, automatisch schalen, ...) Dit alles zonder de noodzaak om vooraf te investeren in infrastructuur of de diepgaande technische kennis die nodig is om het te bedienen en de typische lasten die daarmee gepaard gaan. OutSystems: toegangspoort tot AI en automatisering AI en hyperautomatisering zijn essentiële zakelijke hulpmiddelen geworden voor hulp bij het maken van content, virtuele assistenten, snellere codering, documentanalyse en nog veel meer. OutSystems stelt professionele ontwikkelaars in staat productiever te zijn door AI in te bouwen in de gehele levenscyclus van applicaties. Ontwikkelaars profiteren van AI-ondersteunde ontwikkeling, query's in natuurlijke taal en zelfs generatieve AI. Als je eenmaal klaar bent met je ontwikkeling, is het transporteren van een app naar de test- of productieomgeving slechts een kwestie van een paar klikken. Het platform automatiseert het proces in hoge mate en voert zelfs alle noodzakelijke validaties en afhankelijkheidscontroles uit om onbreekbare implementaties te garanderen. OutSystems integreert naadloos met AI-mogelijkheden van grote cloudproviders zoals Amazon, Azure (OpenAI) en Google, waardoor projectteams gebruik kunnen maken van generatieve AI, machine learning, natuurlijke taalverwerking en computervisie . Door geavanceerde technologieën toegankelijker te maken, versnelt OutSystems digitale transformatie en creëert het duurzame concurrentievoordelen. OutSystems maakt samengestelde architectuur voor flexibiliteit mogelijk Composable architectuur en business apps, gekenmerkt door modulaire componenten, maken snelle aanpassing aan veranderende bedrijfsbehoeften mogelijk. OutSystems omarmt deze trend door een cloud-native Low-Code platform te bieden dat dit type architectuur gebruikt en ondersteunt. Het stelt teams in staat om eenvoudig samenstelbare technische en zakelijke componenten te bouwen. Met de visuele modelleerbenadering van Low-Code, een uitgebreide bibliotheek van aanpasbare vooraf gebouwde componenten en een microservice-gebaseerd applicatieleveringsmodel, bevordert OutSystems hoge herbruikbaarheid en flexibiliteit. Deze samengestelde aanpak stelt organisaties in staat om: Snel te reageren op veranderende bedrijfsbehoeften Te experimenteren met nieuwe ideeën Duurzame, schaalbare en veerkrachtige oplossingen te creëren OutSystems maakt de creatie van bedrijfsapps mogelijk die eenvoudig kunnen worden geïntegreerd, vervangen of uitgebreid, en ondersteunt bedrijven op hun reis naar combineerbaarheid en flexibiliteit. OutSystems vergemakkelijkt self-service en nauwe samenwerking Platform engineering, dat de nadruk legt op samenwerking tussen ontwikkelings- en operationele teams, zorgt voor efficiëntie en schaalbaarheid. OutSystems biedt een gecentraliseerd Low-Code platform dat dit concept in de kern omarmt door voortdurend te worden uitgebreid met nieuwe functies, tools en versnellers. Bovendien faciliteert het platform de gehele levenscyclus van applicatieontwikkeling tot aan operations . Inclusief functies zoals Versiebeheer Geautomatiseerde implementatie Continue integratie en levering (CI/CD) Registratie Bewaking Organisaties in staat stellen om agile DevOps-praktijken toe te passen. Met OutSystems kunnen cross-functionele teams naadloos samenwerken, waardoor een snellere time-to-market en een betere softwarekwaliteit mogelijk worden. Door platform engineering principes te ondersteunen, helpt OutSystems organisaties om duurzame softwarelevering en operationele uitmuntendheid te bereiken. OutSystems stimuleert duurzaamheid in IT OutSystems leidt de weg in het stimuleren van duurzaamheid in IT door middel van zijn groene IT Low-Code applicatie-ontwikkelplatform en strategische initiatieven. Door energie-efficiënte ontwikkeling mogelijk te maken , het beheer van de levenscyclus van applicaties te stroomlijnen , gebruik te maken van een cloud-native infrastructuur en herbruikbaarheid te bevorderen, stelt OutSystems een voorbeeld voor de branche. Organisaties kunnen papierloze processen ontwikkelen, taken automatiseren, legacy-systemen moderniseren en IT-landschappen vereenvoudigen met behulp van OutSystems 3 tot 4 keer sneller, waardoor de totale kosten en ecologische voetafdruk afnemen. Door OutSystems te omarmen, kunnen bedrijven hun IT-activiteiten afstemmen op een groenere toekomst, bijdragen aan duurzaamheid en bouwen aan een veerkrachtigere planeet. Inpakken In het tijdperk van digitale transformatie en duurzaamheid is OutSystems een krachtige bondgenoot voor organisaties, die essentiële bedrijfsinnovaties levert, zoals ... High-performance Low-Code ontwikkeling Cloud-native architectuur AI en automatisering Robuuste beveiligingsmaatregelen Samenwerkende DevOps-praktijken Neem de OutSystems-reis om je aan te passen aan IT-trends, uitzonderlijke resultaten te leveren en bij te dragen aan een duurzame en veerkrachtige toekomst. Sta je te popelen om met OutSystems te beginnen? Laat ons helpen

Leestijd 10 min

Dorien Jorissen

Stel, je bent een Product Owner in een Agile delivery team, klaar om aan de slag te gaan met je product. Om dat te kunnen doen, moet je je ontwikkelteam een doel geven en een lijst met dingen om aan te werken. Als je SCRUM als raamwerk gebruikt, noem je die lijst met dingen om aan te werken een Product Backlog . Uit de SCRUM-gids: De Product Backlog is een geordende lijst van alles waarvan bekend is dat het nodig is in het product. Het is de enige bron van vereisten voor alle wijzigingen die in het product worden aangebracht. De Product Backlog geeft een lijst van alle features, functies, vereisten, verbeteringen en fixes die de veranderingen vormen die in toekomstige releases in het product moeten worden aangebracht. Product Backlog items hebben de kenmerken van een beschrijving, volgorde, schatting en waarde. Product Backlog items bevatten vaak testbeschrijvingen die de volledigheid aantonen als ze "Done" zijn. Oké, je moet dus beginnen met een backlog, prioriteiten stellen en dan de items met de hoogste prioriteit eerst bouwen. SCRUM - en Agile ontwikkeling in het algemeen - is zowel incrementeel als iteratief (zie hier of hier voor een goede uitleg van die termen). Laten we dit illustreren met een voorbeeld: als een klant een auto bestelt - en we gebruiken SCRUM om hem te implementeren - kunnen we itereren op het chassis en de auto incrementeel bouwen, zoals dit: Als Product Owner (de rol die je inneemt als Product Manager) zit je echter met een paar vragen: Waar komt de backlog vandaan? Hoe weet ik zeker dat het een behoefte van de eindgebruiker oplost? Hoe weet ik zeker dat het ontwikkelteam mijn interpretatie van de behoefte ook daadwerkelijk levert? Hoe kan ik er zeker van zijn dat ik me aanpas aan veranderingen en mijn architect toch een duidelijke (minder evoluerende) set parameters geef om aan te werken? In deze blogpost proberen we die vragen geleidelijk te beantwoorden. Focus op de onderliggende behoefte van de klant Laten we beginnen met de tweede vraag op onze lijst: hoe kan ik er zeker van zijn dat het een behoefte van de eindgebruiker oplost? Henrik Kniberg wijst er terecht op: We beginnen met dezelfde context - de klant heeft een auto besteld. Maar deze keer bouwen we niet gewoon een auto. In plaats daarvan richten we ons op de onderliggende behoefte die de klant vervuld wil zien . Blijkt dat zijn onderliggende behoefte is "Ik moet sneller van A naar B", en een auto is slechts één mogelijke oplossing daarvoor. Vergeleken met ons vorige voorbeeld van een klant die een auto bestelt, zou het er nu zo uitzien: Simpel gezegd betekent dit dat je eerst het echte probleem moet ontrafelen en naar eigen inzicht moet aanpassen . Het ontrafelen van het probleem is iteratief van aard: zolang je geen bevestiging krijgt dat je een echte behoefte aan het oplossen bent, moet je veranderen en aanpassen. Je presenteert de eindgebruiker een beste schatting van hoe een oplossing eruit zou kunnen zien. Zolang de gebruiker niet tevreden is, moet je dieper graven en met alternatieven komen. Uiteindelijk raak je de 'sweet spot' en krijg je de bevestiging dat je het probleem hebt begrepen. Deze bevestiging kan gebaseerd zijn op echte gebruiksgegevens, kwalitatieve inzichten of een combinatie van beide. SCRUM geeft niet aan hoe je Henriks idee moet implementeren. Ik heb begrepen dat er een voorkeur is voor het ontwikkelen van software en het richten van de sprint op het eindigen met een increment . Dit betekent dat werkende software wordt gebruikt als artefact tijdens de iteratie om het probleem te definiëren. Het nadeel is echter dat het team reeds geïmplementeerde incrementen opnieuw moet bewerken, omdat ze moeten worden aangepast aan nieuwe inzichten. Ik heb de verspillingen van softwareontwikkeling gecontroleerd en de potentiële versp illingen geïdentificeerd: Schatting niet mogelijk door slechte analyse/informatieverzameling (Partially Done Work). Technische complexiteit niet goed geanalyseerd (Partially Done Work), omdat het geen zin heeft om dit tijdens een iteratie te doen. Verkeerde keuze van technologie of oplossing (Defects), omdat de niet-functionele eisen een bewegend doel zijn. Herontwerpen vanwege gemiste requirements (Defecten). Dit zijn nog steeds aandachtspunten die kunnen worden opgelost door een goede productontdekkingsstap . Laten we eerst nog eens kijken naar de vragen waar een Product Owner mee kan zitten en aangeven welke we hebben opgelost: Waar komt deze backlog vandaan? Hoe weet ik zeker dat het een behoefte van de eindgebruiker oplost? ✅ We beginnen met een idee en itereren tot we een oplossing vinden die een behoefte vervult. Dit blijven we doen tot we een bevestiging krijgen. Hoe kan ik er zeker van zijn dat het ontwikkelteam mijn interpretatie van de behoefte ook daadwerkelijk levert? Hoe kan ik er zeker van zijn dat ik me aanpas aan veranderingen en mijn architect toch een duidelijke (minder evoluerende) set parameters geef om mee te werken? ❌ Dit maakt het probleem groter: het ontwikkelteam moet nu (ten minste wat) meer werk verzetten om alle wijzigingen te verdoezelen. Ontdek de behoeften van je gebruiker Om de potentiële verspilling in het voorbeeld van Henrik te elimineren, moet je het iteratieve deel (uitzoeken wat de gebruiker nodig heeft) en het bouwen van de software (een oplossing voor het probleem maken) opsplitsen. Uitzoeken wat de gebruiker nodig heeft, houdt een zogenaamde ontdekkingsstap in . Marty Cagan , de "meest invloedrijke persoon in de productruimte", is het hiermee eens : In Henriks voorbeeld is het team bezig om tegelijkertijd te bepalen wat het juiste product is om te bouwen en om dat product te bouwen. En ze hebben één belangrijk hulpmiddel tot hun beschikking om dat te doen: de ingenieurs. Dus wat je ziet is een progressief ontwikkeld product, met een belangrijke nadruk op iets dat we bij elke iteratie kunnen testen op echte gebruikers. Henrik benadrukt dat ze bouwen om te leren, maar ze doen dit met het enige gereedschap dat ze denken te hebben: ingenieurs die code schrijven. Als je goed leest, vermeldt Henrik dat de ingenieurs eigenlijk geen producten hoeven te bouwen - ze zouden prototypes kunnen bouwen, maar bij de meeste teams die ik ontmoet, gaat dit punt verloren omdat ze niet begrijpen dat er veel vormen van prototypes zijn , waarvan de meeste niet bedoeld zijn om door ingenieurs te worden gemaakt. Dat klopt: het schrijven van software kan een goede oplossing zijn om erachter te komen wat de gebruiker wil, maar meestal is het de duurste manier om er te komen. Met een ontdekkingsstap kun je je richten op de doelstellingen van een product: is het waardevol, bruikbaar, haalbaar en levensvatbaar? Deze stap is meestal iteratief. Het eindresultaat is een duidelijke probleemdefinitie en dus een mogelijke oplossing voor dat probleem; een oplossing met een hoge waarschijnlijkheid om de behoefte van een gebruiker op te lossen. Omdat je een ontdekkingsstap hebt genomen, betekent dit dat je het echte probleem kunt beschrijven aan het engineeringteam. Je kunt het probleem ook gedetailleerder beschrijven en ook beschrijven wat voor eigenschappen je verwacht van de eindoplossing, bijvoorbeeld een fitnessfunctie die de oplossing in context plaatst. De ontwikkelteams zoeken dan uit hoe ze die oplossing moeten bouwen. Dit is de opleveringsstap en deze is meestal incrementeel. Productontdekkingsspoor versus leveringsspoor Bij de productontdekkings- en leveringsstappen zijn er twee sporen die het team moet overwegen: een productontdekkingsspoor en een leveringsspoor . Laten we de vragen van de Product Owner een derde keer opnieuw bekijken en aangeven welke we hebben opgelost: Waar komt deze backlog vandaan? Hoe weet ik zeker dat het een behoefte van de eindgebruiker oplost? ✅ ✅ We beginnen met een idee en itereren totdat we een oplossing hebben gevonden die een behoefte vervult. We zouden echt meer tijd moeten besteden aan onze eindgebruikers om hun probleem echt te begrijpen. We moeten proberen dit zo snel mogelijk te doen, zodat de engineeringtijd niet opraakt. Hoe kan ik er zeker van zijn dat het ontwikkelteam mijn interpretatie van de behoefte ook echt levert? Wat betreft de probleemomschrijving kan ik meer details en context geven. Hoe kan ik er zeker van zijn dat ik me aanpas aan veranderingen en mijn architect toch een duidelijke (minder evoluerende) set parameters geef om mee te werken? De engineers weten echt wel dat het een auto gaat worden voordat ze een geschikte architectuur kunnen bedenken die geschikt is voor de taak, en ze kunnen er in feite voor kiezen om deze architectuur te implementeren met een andere opleveringsstrategie dan een die ontworpen is om snel te leren. Naarmate de risico's tijdens het ontdekken worden aangepakt en het noodzakelijke opleverwerk duidelijk wordt, gaat dat opleverwerk veel sneller dan anders het geval zou zijn. Dubbel spoor: product ontdekken en opleveren gebeuren tegelijkertijd Ontdekkingswerk richt zich op snel leren en valideren. Maar hoe koppel je dat aan het opleveringswerk? Als een project begint , doe je misschien eerst discovery en laat je - iets later - het engineeringteam beginnen. Het wordt dan zo : Dat lijkt veel op Waterfall ! Maar zo hoeft het niet te zijn. Jeff Patton , een veteraan Product Manager en schrijver van het boek User Story Mapping , zegt dat het allemaal tegelijk gebeurt (Dual Track). In plaats van een waterval krijgen we een loop. Een lus voor ontdekkend leren ziet er ongeveer zo uit: Het begint met het beschrijven van wat we denken dat het probleem is dat we proberen op te lossen en voor wie, de oplossing om het probleem op te lossen, en hoe we het succes ervan meten. Productontdekkingssessies lopen als volgt in elkaar over: Ontdekkingswerk maakt gebruik van onregelmatige cycli. Het is 'lean' in de zin dat we proberen de ontdekkingscyclus zo kort mogelijk te maken. Ontdekideeën muteren en worden vaak verlaten, wat de beste stap is naar meer doelbewuste ontwikkelingscycli. Takeaway Om potentiële risico's te elimineren, moet je je bewust zijn van zowel de ontdekkingsstap als de opleveringsstap . De ontdekkingsstap richt zich op de doelstellingen van een product: waarde, bruikbaarheid, haalbaarheid en levensvatbaarheid en is meestal iteratief. De opleveringsstap richt zich op hoe je een product bouwt en is meestal incrementeel. Hoewel de stappen gescheiden zijn, vinden de sporen tegelijkertijd plaats, wat we Dual Track noemen. Het artikel van Jeff Patton over Dual Track noemt ook een paar belangrijke punten. Deze twee sporen zijn twee soorten werk die door hetzelfde team worden uitgevoerd. Discovery moet regelmatig met het team controleren op haalbaarheid, juiste implementatie en technische beperkingen die van invloed zijn op de ontwerpbeslissing. Delivery gebruikt inzichten uit discovery tijdens de ontwikkeling. Discovery richt zich eerst op de meest riskante aannames, d.w.z. gebruikersproblemen waarvan we weinig vertrouwen hebben dat ze een echte gebruikersbehoefte oplossen (of de behoefte is onbekend). Oplevering richt zich op oplossingen waarvan we een hoog vertrouwen hebben dat ze het probleem van een gebruiker oplossen. Het vertrouwen kan voortkomen uit gevalideerd leren tijdens het ontdekken. Of we beginnen - bijvoorbeeld aan het begin van een cyclus - met backlog items waarvan we denken dat er geen discovery nodig is, zoals technisch werk of features waarvan we al een hoog vertrouwen hebben dat ze een gebruikersprobleem oplossen. De twee sporen worden parallel uitgevoerd: Discovery / Iteration : focus op de meest riskante aannames (problemen waarvan we de minste kennis hebben) en probeer deze met zo min mogelijk inspanning te definiëren. Oplevering / Increment : focus op een goed gedefinieerde oplossing (we hebben een hoog vertrouwen dat de eindgebruiker het nodig heeft) en pak de oplossingen met de hoogste waarde het eerst aan. Het spoor stopt niet zodra je een probleem hebt ontdekt om op te lossen. Het volgende probleem loert al om de hoek. In ons voorbeeld met de klant die een auto bestelt ("Ik moet sneller van A naar B"), zouden we ook kunnen denken dat de gebruiker onderdak nodig heeft, wat kan variëren van een eenvoudige hut tot een kasteel. Een laatste opmerking: deze blogpost begon met SCRUM als het raamwerk voor oplevering, maar de methodologie doet er niet echt toe: het zou Kanban, Crystal XP en zelfs Waterval kunnen zijn, zolang het team maar in staat is om gelijke tred te houden met de twee sporen. Maar omdat het ontdekkingsgedeelte gericht is op snel leren , past een Agile methodologie natuurlijk beter. Resterende vragen Laten we de vragen van de Product Owner nog een laatste keer bekijken en aangeven welke nu zijn opgelost. Waar komt deze backlog vandaan? ✅ De backlog komt voort uit aannames die tijdens discovery zijn gevalideerd. Er is echter een nieuwe vraag: hoe identificeren we de lijst met veronderstellingen waarop we ons moeten richten? Waar komt de lijst van Opportunities vandaan? ❓ Hoe weet ik zeker dat het een behoefte van de eindgebruiker oplost? ✅✅✅✅ We beginnen met een idee en itereren tot we een oplossing hebben gevonden die een behoefte vervult. Ik zou echt meer tijd moeten besteden aan mijn eindgebruikers en hun probleem echt moeten begrijpen. Ik zou moeten proberen om dit zo snel mogelijk te doen, zodat de engineering niet zonder werk komt te zitten. Doe dit parallel, met het hele team. Hoe kan ik er zeker van zijn dat het ontwikkelteam mijn interpretatie van de vereisten ook echt levert? ✅ In termen van probleemomschrijving kan ik meer details en context geven. Betrek (ten minste een deel) van je engineeringteam bij discovery. Op deze manier komen ze in contact met de echte eindgebruiker en krijgen ze een beter begrip van de echte wereld van de gebruiker. Hoe kan ik er zeker van zijn dat ik me aanpas aan veranderingen en mijn architect toch een duidelijke (minder evoluerende) set parameters geef om mee te werken? ✅ De ingenieurs weten echt wel dat het een auto wordt voordat ze een geschikte architectuur kunnen bedenken. Ze kunnen er zelfs voor kiezen om deze architectuur te implementeren met een andere leveringsstrategie dan een die ontworpen is om snel te leren. De risico's worden in discovery aangepakt en het noodzakelijke opleverwerk wordt duidelijk. Het opleveringswerk kan nu veel sneller gaan dan anders het geval zou zijn .

Leestijd 4 min

Dorien Jorissen

Het inschatten van de inspanning die nodig is om bepaalde functionaliteiten te ontwikkelen bij het schrijven van software geeft je klanten enige zekerheid en voorspelbaarheid. Dat gezegd hebbende: het maken van schattingen voor softwareontwikkeling is meestal niet het populairste deel van het werk van een ontwikkelaar. We hebben echter een manier gevonden om schattingen te gamificeren en ze een stuk leuker te maken, zonder aan nauwkeurigheid in te boeten. In deze blogpost leren we je hoe je schattingen voor softwareontwikkeling leuk kunt maken met rockstar planning poker. Schattingen maken voor voorspelbaarheid Wanneer een functie duidelijk gedefinieerd is, wordt deze opgesplitst in user stories . Hier is een voorbeeld van zo'n user story: "Als gebruiker van deze dienst wil ik mijn vrienden uitnodigen zodat we samen van de dienst kunnen genieten." Voordat we beginnen met de ontwikkeling van een user story, schatten we de inspanning in die we denken dat het gaat kosten. Op deze manier kunnen we de complexiteit vrij gedetailleerd inschatten en onze klanten vooraf een zekere mate van voorspelbaarheid geven. Om dit te kunnen doen, meten we hoeveel dagen het ons kost om één story point te voltooien. Story points zijn een meeteenheid voor het uitdrukken van een schatting van de totale inspanning die nodig is om een user story volledig te implementeren. De inspanning is het gemiddelde aantal dagen dat een teamlid nodig heeft om een story punt te voltooien in een bepaalde tijdsperiode. De inspanning vermenigvuldigd met de capaciteit van ons team geeft ons een idee van de story throughput van het team, de hoeveelheid story points die een team kan ontwikkelen in een bepaalde periode. Als je de story throughput extrapoleert, kun je een duidelijke voorspelbaarheid krijgen van het bereik dat je met een team in de loop van de tijd kunt realiseren. In dit stadium van het ontwikkelproces kennen we de ingewikkelde details van een user story nog niet helemaal. Maar we hebben ons 'huiswerk' al gedaan en weten genoeg om de complexiteit van de ontwikkeling van de user story nauwkeurig in te schatten. Schatten met planningspoker Planning poker is een ideale manier om tot gedetailleerde schattingen te komen. Deze manier van schatten werd beschreven door Mike Cohn in zijn boek Agile Estimating and Planning . Tijdens een planningspooksessie wordt een user story geschat door het team dat eraan gaat werken. Eerst legt de productmanager uit wat we willen bereiken met de user story. Daarna bespreekt het team wat er precies gedaan moet worden om dat te bereiken, totdat ze een consensus bereiken over de story. Daarna gebruikt elk teamlid 'planningskaarten' om individueel in te schatten hoeveel moeite het kost om de story af te ronden. Na drie tellen draait elk teamlid tegelijkertijd zijn planningskaart om en onthult zijn schatting in story points. Als er grote verschillen zijn, gaat het team door met het bespreken van de complexiteit van het verhaal totdat er een nieuwe consensus is bereikt. Bij ACA gebruiken we een aantal speciale kaarten om de complexiteit van een verhaal in story points aan te geven. We hebben kaarten met de nummers 0,5 - 1 - 1,5 - 2,5 en 4. Na verloop van tijd hebben we echter gemerkt dat verhalen die worden geschat op 2,5 of 4 story points meer werkbelasting en onzekerheid met zich meebrengen, wat weer ten koste gaat van de voorspelbaarheid voor de klant. Nu worden alle stories die worden geschat op meer dan 1,5 story points opgesplitst in kleinere delen. Daarom hebben we de getallen op onze kaarten beperkt tot slechts 0,5 - 1 en 1,5. Hoe zit het dan met rockstar planningspoker? De meeste technische mensen houden niet zo van schattingen maken. Schattingssessies zijn vermoeiend en vergen veel energie, zelfs als je planningspoker gebruikt om het planningsproces te gamificeren. Om die sessies te verlevendigen, gebruiken we nu al een paar jaar iets dat we rockstar planningspoker noemen. In plaats van kaarten te gebruiken om verhaalpunten aan te geven, gebruiken we onze handen. Net als bij 'steen, papier, schaar' tellen we allemaal tot drie en laten dan onze handen zien om een van de volgende tekens te maken. Pinkie Het universele rockstarsignaal om een biertje te bestellen, vooral in de mooie studentenstad Leuven in België. Dit teken staat voor 0,5 verhaalpunt. Wijsvinger De rockster manier om hallo te zeggen! Dit signaal geeft 1 story point aan. Vinger en wijsvinger De universele manier om iedereen te laten weten dat ze moeten rocken. Wordt gebruikt om een complexiteit van 1,5 story point aan te geven. Middelvinger Het universele signaal voor ... Dit signaal wordt gebruikt om aan te geven dat het user story verdere verduidelijking behoeft of opgesplitst moet worden in kleinere delen. Takeaway Rockstar planningspoker is een ideale manier om dingen leuk te houden, en dingen leuk houden zorgt voor meer betrokkenheid en werk van hoge kwaliteit. Rockstar planningspoker levert niet per se betere resultaten op als het gaat om het schatten van de inspanning, maar het heeft de schattingssessies van onze teams wel verlevendigd. Je hebt alleen je handen nodig! Dus als je die vermoeiende schattingssessies zat bent, waarom probeer je dan geen rockstar planning poker om er wat meer pit in te krijgen? Veel succes, veel plezier en laat ons weten hoe je het hebt gedaan!

Leestijd 5 min

Kris Vandebroek

Complexiteit vernietigen, Epic per Epic Herinner je je de Atari-klassieker Asteroids nog? Als je die kent, voel je misschien al een vleugje nostalgie. Zo niet, dan is dit het plaatje: Je bent in de ruimte en bestuurt een schip omringd door enorme, langzaam bewegende asteroïden. Makkelijke doelwitten, toch? Maar elke keer dat je er eentje neerschiet, valt hij uiteen in kleinere, snellere brokstukken die veel moeilijker te raken en te ontwijken zijn. Als je voor het eerst begint, kies je misschien voor een strategie waarbij je je eerst richt op het neerschieten van de grootste asteroïden. Die zijn langzamer en gemakkelijker te raken. Maar al snel moet je overal kleine, chaotische rotsblokken ontwijken. Je verliest de controle en dan 💥 BOEM! Game over. Klinkt dat bekend? Het lijkt veel op het verliezen van controle bij het managen van complexe projecten. Er is een betere manier! En het is een strategie die net zo goed werkt bij softwareontwikkeling als bij het spel Asteroids. Bij softwareontwikkeling noemen we het Progressive Elaboration . Grote problemen afbreken: de Asteroids-benadering van agile Om een hoge score te halen in Asteroids, concentreer je je op één grote asteroïde. Je breekt het systematisch op in kleinere delen en probeert ze weg te spelen. Dit zorgt ervoor dat je altijd de controle houdt. Het totale aantal asteroïden dat om je heen vliegt, wordt tot een minimum beperkt en de andere grote asteroïden zijn gemakkelijk te volgen en te ontwijken. Als je de eerste asteroïde volledig hebt uitgeschakeld, kun je je richten op de volgende grote asteroïde. Dit is ook de manier waarop we grote, complexe uitdagingen in softwareontwikkeling benaderen. Als je te maken krijgt met meerdere Epics (een groot, complex probleem), kan het aanpakken van meerdere Epics tegelijk leiden tot chaos en een hoge Cognitieve belasting . Door Progressive Elaboration te gebruiken , focussen we op één item dat de hoogste waarde biedt, breken we het op in hanteerbare stukken (Features of User Stories) en prioriteren we ze. Vervolgens kunnen we ons richten op het stuk met de hoogste prioriteit. Op deze manier houden we alles beheersbaar en voorkomen we dat 'Game Over'-gevoel wanneer een project uit de hand loopt. Hoe Progressive Elaboration toepassen: 3 technieken Hier zijn drie voorbeelden van hoe je Progressive Elaboration - of, zoals wij het hier noemen, de Asteroids-benadering - kunt toepassen om complexiteit af te breken en je te richten op het leveren van waarde: 1. Gebruikersverhaal in kaart brengen Gebruik deze techniek ( referentiekaart ) wanneer je een nieuw product of een grotere end-to-end dienst lanceert. Stap 1: Breng het klanttraject in kaart. Definieer elke stap van het klanttraject en identificeer alle betrokken persona's. Stap 2: Maak een lijst van mogelijke kenmerken. Maak voor elke stap een lijst van de mogelijke functies die de gebruiker in die stap van het klanttraject kan gebruiken. Stap 3: Identificeer de kleinste haalbare features. Focus op de kleinst mogelijke set functies om de E2E-workflow te bouwen. Het moet waarde leveren aan de klant, inzichten bieden aan de Product Owner of ontwikkelingsrisico's verminderen. Stap 4: Richten en aanpakken. Je hebt de eerste asteroïden geïdentificeerd om je op te richten. Pak ze één voor één aan en splits ze indien nodig op tot je het niveau van de User Story hebt bereikt. Stap 5: Opleveren, leren en herhalen. Evalueer consequent opnieuw, houd het grote geheel in gedachten en breek af en concentreer je op één asteroïde per keer. 2. Stroomopwaarts Kanban Deze techniek is vooral nuttig als de E2E-kernworkflow van je product al geïmplementeerd is en het Product Team deze wil verbeteren of uitbreiden. Het Upstream Kanban-bord is je visualisatie van alle "asteroïden" die rond je project vliegen. Op elk moment hebben we een heleboel mogelijke functies die we kunnen bouwen. We noemen deze "Opties". Deze Opties moeten worden geprioriteerd. Wanneer het team de beschikbare capaciteit heeft om de volgende Asteroïde op te nemen, gaat het naar "Ontdekken". Hier gebruiken we de Progressieve Uitwerkingstechniek. We splitsen de optie op in kleinere onderdelen en stellen prioriteiten. Dan kunnen we één voor één, afgestemd op de prioriteit, de eigenlijke levering doen (= gedetailleerde analyse en ontwikkeling). Stap 1: Visualiseer "asteroïden" op een Kanban-bord. Maak een lijst van de opties die het bedrijf of de gebruikers willen onderzoeken. Stap 2: Prioriteit toekennen aan opties op basis van waarde. Sorteer op resultaat of potentiële waarde. Stap 3: Trek items aan wanneer de capaciteit het toelaat. Als je er klaar voor bent, ga je met een item naar Discovery, waar het wordt geanalyseerd en uitgesplitst. Stap 4: Ga naar levering zodra het duidelijk is. Als een item goed gedefinieerd is, stuur het dan naar de ontwikkelingsafdeling. 3. Mindmapping Deze techniek is flexibel en effectief, zelfs voor kleinere taken zoals het maken van een blogpost. Stap 1: Gebruik een mindmapping tool of papier. Schrijf de grote "asteroïde" op die je wilt aanpakken, verdeel het in kleinere delen en stel prioriteiten. Stap 2: Concentreer je op één onderdeel tegelijk. Herhaal het opsplitsingsproces tot je duidelijke, bruikbare punten hebt. Stap 3: Volg het grote geheel. De mindmap houdt u geaard in het grotere doel terwijl u onmiddellijke taken afhandelt. Houd complexiteit onder controle en lever waarde Door deze technieken toe te passen, heb je minder last van "game-over" momenten in je projecten. Je houdt de complexiteit onder controle en levert waarde in beheersbare brokken per keer - net als het afbreken van asteroïden voordat ze je schip overweldigen. Wat is je volgende grote asteroïde? Hoe ga je deze technieken toepassen om je projecten beter beheersbaar te maken en meer waarde op te leveren? Ben je geïnteresseerd in meer informatie? We bieden 5 gratis brainstormsessies met een Agile Coach. Claim nu je plek! En als je een pauze nodig hebt, speel dan hier een remake van het originele Asteroids-spel !

Leestijd 8 min

Peter Claassen

In juni 2023 namen vier ACA-collega's deel aan de Foundations Day van het meerdaagse evenement van Domain-Driven Design Europe (DDD Europe). In het Meervaarttheater in Amsterdam woonden ze verschillende lezingen bij die een praktisch perspectief boden op DDD-concepten. Het volledige verslag staat hieronder. Na een verfrissende koffie voor de vroege vogels en de welkomstwoorden van de organisatoren, volgde een vol programma van acht lezingen met live codering. Deze blogpost biedt een beknopt overzicht van alle presentaties, gevolgd door een evaluatie op verschillende gebieden: inspiratie van de spreker, relevantie voor Domain-Driven Design (DDD), gebruikte analysetechnieken en technische bruikbaarheid van de informatie. Beoordelingen Domeinconcepten omzetten in code Deze sessie werd geleid door Paul Rayner, een Australiër die in de Verenigde Staten woont. Hij gaf een gestructureerde en boeiende sessie met nieuwe inzichten in Domain-Driven Design en codering, met een sterke voorkeur voor Test-Driven Design. Hij verdiepte zich in het concept van uitgebreide garanties en demonstreerde dit stap voor stap in Ruby code met behulp van Event Storming. Naarmate zijn verhaal vorderde en de complexiteit toenam, pakte hij vragen die voortkwamen uit Event Storming vakkundig aan met een Test-Driven aanpak. Zijn afsluitende boodschap was duidelijk: "Wees niet bang om code te refactoren als je start vanuit een fundamentele Test-Driven methode!". Zelfs voor degenen met beperkte kennis van DDD was de logica in zijn redenering tijdens het live coderen gemakkelijk te volgen. Hoewel hij niet gepland staat als spreker voor de komende editie van DDD Europe, als je ooit de kans krijgt om een sessie van Paul Rayner bij te wonen, aarzel dan niet: het is een echte aanrader. Link naar de video Scorekaart (1-5): Inspiratie: 3 Relevantie voor DDD: 5 Analysetechnieken: 4 Technische bruikbaarheid: 4 Model Mitose: Een dynamisch patroon om met modelspanning om te gaan Deze onderhoudende sessie werd gegeven door Julien Topçu en Josian Chevalier. Ze presenteerden een sessie binnen de context van de Mandalorian uit de Star Wars saga, waarin ze verschillende typische valkuilen in een ontwikkelproces demonstreerden. Het was een volledig gescripte sessie waarbij de live codering zogenaamd werd gedaan door een AI genaamd Chat3PO. Ze gebruikten echter wel een aantal interessante concepten zoals een Shared Kernel en een Anti-Corruption Layer. Omdat het een scriptsessie was, werd er weinig tijd verspild aan het schrijven van code. Hierdoor konden ze gemakkelijk overschakelen naar domeinoverzichten, waardoor het verhaal coherent bleef. Deze sessie is zeker een aanrader omdat het een interessante evolutie binnen een domein belicht. In de laatste vijf minuten gaven ze ook een goede samenvatting van de evolutie die ze doormaakten in hun scenario en verwezen ze naar het Hive Pattern waarin dit concept verder wordt uitgewerkt. Link naar de video Scorekaart (1-5): Inspiratie: 5 Relevantie voor DDD: 4 Analysetechnieken: 4 Technische bruikbaarheid: 3 TDD DDD vanaf de basis - Chris Simon Tijdens de sessie "TDD DDD from the Ground Up" werden verschillende principes van Domain-Driven Design (DDD) belicht aan de hand van een live codeervoorbeeld van Test-Driven Development (TDD). De ervaren spreker, Chris Simon, deelde zijn uitgebreide kennis over dit onderwerp. Dankzij zijn grondige voorbereiding, diepgaande kennis van het onderwerp en aangename tempo was deze sessie geschikt voor een publiek van ontwikkelaars en analisten die de basisprincipes van TDD wilden verkennen. Hoewel het TDD-gedeelte goed werd uitgevoerd, ontbrak er een duidelijk verband met DDD. Daardoor voelde de sessie meer aan als een TDD-demo, met slechts beperkte aandacht voor DDD-principes. Bovendien werd de kijkervaring negatief beïnvloed door de lage kwaliteit van de geprojecteerde code, in combinatie met de aanwezigheid van veel zonlicht in de zaal. Voor degenen die een solide basis in Test-Driven Development willen leggen, was deze sessie zeker een aanrader. Als je echter meer geïnteresseerd bent in Domain-Driven Design, zijn er betere sessies beschikbaar die meer diepgang bieden. Link naar de video Scorekaart (1-5): Inspiratie: 4 Relevantie voor DDD: 2 Analysetechnieken: 1 Technische bruikbaarheid: 4 De school van Escher: Modelleren met functies Tijdens "De Escherschool: Modelleren met functies" demonstreerde Einar Høst het concept van functiemodellering door middel van live codering in de functionele programmeertaal Elm. Het voorbeeld toonde talloze vectortransformaties om afbeeldingen te manipuleren. De presentatie sprak ontwikkelaars zeker aan. Het was fascinerend om getuige te zijn van de indrukwekkende resultaten die bereikt kunnen worden met relatief eenvoudige vectortransformaties. Voor analisten had de sessie echter waarschijnlijk minder onmiddellijke waarde. Omdat de presentatie erg technisch was, misten we een duidelijke link naar Domain-Driven Design. Ondanks de visueel verbluffende resultaten leek de sessie af te dwalen van de context van een DDD-conferentie. Link naar de video Scorekaart (1-5): Inspiratie: 2 Relevantie voor DDD: 1 Analysetechnieken: 1 Technische bruikbaarheid: 3 TDD: voorbij de intro deel één twee De tweedelige talk "TDD: Beyond the Intro" van Romeu Moura suggereerde een diepere duik in Test-Driven Development, en dat is precies wat we kregen. Moura begon met de basis van TDD, maar ging al snel verder dan de "red-green-refactor" cyclus. Hij zag TDD als een Socratische dialoog, een methode van redeneren met tests als "veldnotities". Zijn verhaal was diepgaand en duidelijk, hoewel het tempo soms wat laag lag, waardoor het een uitdaging was om volledig betrokken te blijven. Ondanks de DDD-context van de conferentie besteedde Moura weinig tot geen aandacht aan Domain-Driven Design. De focus lag meer op de algemene principes van TDD en hoe die in de praktijk kunnen worden toegepast. De lezing bevatte ook een live codeersegment, waarbij Moura een eenvoudige fizzbuzz applicatie bouwde met behulp van TDD. Hoewel dit een nuttige illustratie was van de besproken principes, was het niet noodzakelijk essentieel om de lezing te begrijpen. Over het algemeen was dit een waardevolle lezing voor mensen met een technische achtergrond die meer willen leren over TDD: diepgaand, duidelijk en praktisch toepasbaar. Ondanks de beperkte verwijzingen naar DDD, deed dit niets af aan de kwaliteit van de presentatie. Link naar de video (deel één) Link naar de video (deel twee) Scorekaart (1-5): Inspiratie: 4 Relevantie voor DDD: 1 Analysetechnieken: 1 Technische bruikbaarheid: 4 Refactoring naar een echt klein maar bruikbaar modeleiland De spreker van deze sessie, Yves Lorphelin, is een ervaren software engineer met een passie voor Domain-Driven Design. Hij deelde zijn enthousiasme en expertise op een inspirerende manier. De lezing was helder en goed gestructureerd, met concrete voorbeelden en illustraties. Lorphelin beantwoordde vragen van het publiek met kennis en humor. De lezing was duidelijk geworteld in de principes van Domain-Driven Design. Lorphelin liet zien hoe refactoring naar een klein modeleiland kan helpen om de complexiteit van een softwareproject te verminderen en de code beter te organiseren rond kerndomeinen. Lorphelin besprak verschillende analysetechnieken die kunnen worden gebruikt om kerndomeinmodellen te identificeren. Deze technieken omvatten: Afgebakende contextanalyse: Identificeren van gebieden van de applicatie met hun eigen domeinlogica. Alomtegenwoordige taal: Het ontwikkelen van een gemeenschappelijke taal die door alle belanghebbenden wordt gedeeld. Event storming: Domeinlogica modelleren via gebeurtenissen. De lezing was gericht op softwareontwikkelaars en architecten met een basiskennis van Domain-Driven Design. Lorphelin ging in op de technische details van refactoring naar een klein modeleiland, maar hij hield ook een abstract niveau aan om de lezing toegankelijk te houden voor een breed publiek. Scorekaart (1-5): Inspiratie: 3 Relevantie voor DDD: 3 Analysetechnieken: 4 Technische bruikbaarheid: 3 Leven in je eigen bubbel - Jacob Duijzer: Van legacy naar Domain Driven Design In deze sessie legde agile coach Jacob Duijzer uit hoe hij legacy code heeft aangepakt voor een project binnen het landbouwdomein. Hij gaf diepere inzichten in het domein met behulp van de Domain Storytelling techniek. Hij schetste de nieuwe richtlijnen die van toepassing waren op het bestaande systeem, dat niet alleen complex en verouderd was, maar ook documentatie, unit tests en ervaren domeinexperts miste. Jacob Duijzer liet zien hoe hij domeinexperts het domein liet uitleggen aan de hand van voorbeelden (bekend als 'specificeren aan de hand van voorbeelden'). Vervolgens legde hij uit wat 'de bubbelcontext' is en hoe deze kan worden gebruikt om nieuwe bedrijfsregels te implementeren zonder het bestaande systeem te beïnvloeden. Tot slot schetste hij de voor- en nadelen van een bubble context. 🎥 Link naar de video Scorekaart (1-5): Inspiratie: 3 Relevantie voor DDD: 5 Analysetechnieken: 4 Technische bruikbaarheid: 3 Functionele domeinmodellering - Marco Emrich en Ferdinand Ade Deze presentatie bracht een vleugje theater naar DDD 2023, met Marco (als de ontwikkelaar) en Ferdi (als de klant/Product Owner) in de hoofdrol. Het verhaal ontvouwde zich als volgt... Ferdi, actief in de wijnsector, wilde een applicatie bouwen om zijn klanten de beste wijn aan te bevelen, afgestemd op hun smaak. Het was heerlijk om Ferdi hardop te zien nadenken over zijn verwachtingen. Marco probeerde dit meteen te vertalen in code met behulp van 'types'. Terwijl Ferdi stap voor stap beschreef hoe een 'proeverij' verloopt, codeerde Marco dit meteen in Ferdi's taal. Zo koos Marco in eerste instantie voor de term 'wijnselectie', om deze later te veranderen in 'wijnkelder'. Ferdi bleef immers verwijzen naar hun wijnkelder, niet naar hun selectie. Ferdi keek voortdurend over Marco's schouder mee. Samen voegden ze elementen toe, verwijderden ze en hernoemden ze elementen. Alles wat onduidelijk was werd uitgesteld. Gaandeweg ontstond er een gedeelde taal tussen de ontwikkelaar en de klant. Uit deze vermakelijke sessie hebben we geleerd dat het nuttig is om samen met de klant te modelleren met behulp van event storming of domain storytelling, hoewel de uitkomst abstract kan zijn. Functional Domain Modeling' kan de kers op de taart zijn. Het resultaat is expliciet, specifiek en biedt een solide startpunt voor implementatie. 🎥 Link naar de video Scorekaart (1-5): Inspiratie: 3 Relevantie voor DDD: 3 Analysetechnieken: 4 Technische bruikbaarheid: 3 Conclusie Na het bijwonen van de Foundations Day van DDD Europe 2023 keerden onze vier collega's huiswaarts met een schat aan nieuwe inzichten die ze in de praktijk zullen toepassen. Het thema live coding bood ontwikkelaars een uitstekende gelegenheid om dieper inzicht te krijgen in DDD-principes. Daarnaast kwamen veel verwante technieken aan bod, zoals Test-Driven Development. Niet elke sessie had een duidelijke link met DDD, wat een beetje een nadeel was voor analisten. Desondanks was de sfeer gedurende de dag bijzonder positief en inspirerend. Het Meervaart theater bleek de perfecte setting voor aanwezigen om te netwerken en ervaringen uit te wisselen voor en na de sessies. We kijken nu al uit naar de volgende editie van DDD Europe!

Leestijd 8 min

Dorien Jorissen

Een bloemlezing van pijnlijke waarheden (en hoe ermee om te gaan) Beginnersfouten Zoals bij veel Product Managers die ik ken, werd de baan me aangereikt als een hete aardappel op een brandend presenteerblaadje. Bij gebrek aan andere vrijwilligers. Per ongeluk. En met weinig context. Bovendien was ik op dat moment net de technische wereld ingerold. Ik had dus duidelijk geen aanknopingspunten voor wat ik moest denken, voelen en doen. En toen stuitte ik op het artikel Good Product Manager/Bad Product Manager van Horowitz. De beruchte uitspraak van de CEO, " een goede productmanager is de CEO van het product" , greep me meteen aan. Ik herinner me nog levendig een plotseling gevoel van trots en empowerment dat door mijn aderen gierde toen ik het las... Ik ging de wereld veranderen! Als ik mezelf "vroeger" nu zou kunnen ontmoeten, zou ik haar een klap in haar gezicht geven. Want het duurde niet lang voordat ik begon te worstelen met mondigheid, verantwoordelijkheid, autoriteit en besluitvorming (of het gebrek daaraan). En zo kwam de onvermijdelijke zwarte dag waarop ik erachter kwam dat... Product Managers niet de CEO van iets zijn . Ik voelde me erg verloren toen ik dit hoorde. Voorgelogen. Verloren. Hoe moest ik de wereld veranderen als ik niet het mandaat had om dat ook echt te doen? Dit komt net binnen: het is niet makkelijk en er is niet één antwoord. Helemaal niet. Ik heb geleerd dat er gewoon altijd dagen zullen zijn waarop het lijkt alsof je een grote berg p00p van links naar rechts aan het scheppen bent. Maar er is ook altijd een lichtpuntje. Ik heb een lijst samengesteld van pijnlijke feiten over empowerment in Product Management die zich voor mijn vermoeide ogen ontrafelden. Om de klap te verzachten, heb ik een paar zilveren sprankjes hoop toegevoegd. Om er zeker van te zijn dat je niet in tranen naar huis pendelt met je ontslagbrief in je handen nadat je dit gelezen hebt. Het huis wint altijd Als Product Manager ben je de hele tijd bezig met Very Important Stuff. Praten met klanten, briljante (of niet zo briljante) nieuwe ideeën onderzoeken en valideren, cijfers kraken in analyserapporten, proberen te vertalen wat de ontwikkelaars je vertellen, enz... Al deze kennis die je dagelijks verzamelt, plaatst je in de perfecte positie om de besluitvormers in het gebouw te adviseren. En gelukkig erkennen de mensen dit. Daarom nodigen ze je uit aan de beslissingstafel om je gewaardeerde aanbevelingen te presenteren. Dus als de uitnodiging binnenkomt, ga je aan de slag en stort je je op het maken van een inspirerende en overtuigende uiteenzetting. Je werkt er dagen en nachten aan. Totdat eindelijk de dag komt dat je dit meesterwerk mag laten zien. Je grijpt het moment. Je spreekt met vurige passie. Je straalt trots, vertrouwen en visie uit en je schildert meeslepende beelden. En als je klaar bent, kijkt iedereen je aan alsof je doorzichtig bent. Een ongemakkelijke stilte vult de kamer. Na een paar lastige vragen en dito antwoorden gaat de vergadering verder. Aan het eind zijn de C*O, VP Ninja en Something Director het allemaal eens. We gaan precies het tegenovergestelde doen van wat jullie net hebben voorgesteld. High fives worden gegeven, vuisten worden gebald, geweldige vergadering iedereen! Laten we ze pakken. Wat is er in hemelsnaam gebeurd? Toen ik dit soort dwaasheid voor het eerst meemaakte, dacht ik dat het aan mij lag. Ik ben nogal tenger. Ik draag ook geen kokerrokken of tweedelige pakken. Sterker nog, een klant vroeg me ooit zelfs om hem koffie te serveren op een evenement waar ik de strategie van het product zou presenteren, omdat hij dacht dat ik de serveerster was. Het eerste wat ik dus deed was mezelf in vraag stellen. Wat denk je? Ik was het niet. En jij bent het niet. Het is het systeem, domoor. Hoe hard we ook werken om de feiten op een rijtje te zetten; hoe goed we ons ook inleven in onze belanghebbenden en hoe goed we ook laten zien in plaats van vertellen... uiteindelijk hebben we er niets meer aan te doen. Het huis wint altijd. Sommige dagen belanden we precies waar we wilden zijn en andere dagen moeten we ons inhouden en in de rij gaan staan. Maar maak je geen zorgen. We kunnen (en moeten er onophoudelijk naar streven) het systeem van binnenuit veranderen. Blijf gewoon lezen. "Hij weet niets; en hij denkt dat hij alles weet. Dat wijst duidelijk op een politieke carrière." George B. Shaw had de spijker op z'n kop met dit citaat. Het duurde even voordat ik het toegaf, maar het slaat eigenlijk heel goed op Product Managers. Een van de definities van Product Management, zoals uitgelegd door Martin Eriksson, is "het snijpunt tussen de functies business, technologie en gebruikerservaring". Oftewel het Venn-diagram dat we allemaal wel eens hebben gebruikt om uit te leggen wat we doen. Dit diagram vertelt je niet dat we experts zijn in al die functies. Het vertelt je dat we veel om elk van deze functies geven. Dat we ons omringen met experts op de gebieden waar we minder ervaren in zijn. En dat we niet alle details kennen, maar wel het totaalplaatje zien. Dus... Weten we alles? Als we het letterlijk nemen, niet. Maar als ik voor mezelf spreek: Ik denk graag van wel, omdat ik het grotere plaatje zie... Daar heb je me, G. En dan de politiek. Oh, de politiek. Persoonlijk verafschuw ik bedrijfspolitiek. Ik word er gek van. Het is gekkenwerk. Overhead en gewoon lawaai als je het mij vraagt. Maar of je het nu leuk vindt of niet, het is hoe de wereld in elkaar zit. Hoewel ik mezelf altijd heb voorgehouden dat ik me er verre van houd, moet ik toegeven dat het mijn carrière niet ten goede zou komen als ik dat wel deed. Zoals we eerder hebben ontdekt, hebben wij Product Managers heel weinig autoriteit. Daarom moeten we vertrouwen op anderen om de beslissingen te nemen die wij willen dat ze nemen. We hebben dus echt geen andere keuze dan tot onze knieën in de kantoorpolitiek te duiken. We kunnen nooit mensen over het hoofd zien of omzeilen. Zelfs niet als we denken dat het incompetente rukkers zijn. We moeten het spel meespelen en de mensen in zowel de formele als informele organigrammen bewerken. Dit alles impliceert dat - of we het nu leuk vinden of niet - productmanagers in veel opzichten politici zijn. Diplomaten. Tactici. Bemiddelaars. Voor mij was dit een bittere pil om te slikken. Want laten we eerlijk zijn: niemand houdt van politici. Politiek (vooral op kantoor) is vermoeiend. Er is niets sexy aan. Dus om mezelf te verlossen van de ellende van het politicus zijn, probeer ik me aan een aantal basisregels te houden: Zet je geld in waar je mond is Draag geen pak (dat zou vies worden in de loopgraven wanneer je waardevolle tijd doorbrengt met de burgers) Noem je collega's, gebruikers of andere waardevolle mensen geen burgers. We zitten allemaal in hetzelfde schuitje Hou je vast aan je overtuigingen Noem jezelf een beïnvloeder. Het klinkt millenial, dus waarom niet? Bewolkt met 99,9% kans op te veel koks in de keuken Productmanagers zijn er in verschillende kleuren, smaken, rolbeschrijvingen en zelfs functietitels. Ongeacht het label hebben we één ding gemeen: we moeten 'onze stakeholders managen'. Er is veel goede informatie beschikbaar over wat dat inhoudt en hoe je het moet aanpakken . De waarheid is: als je een productrol hebt, is de kans groot dat je aan iets heel zichtbaars werkt. Iets waar iedereen om geeft. Stakeholders zijn degenen die je werk kunnen maken of breken. Zij zijn degenen op wie we ons moeten richten, intern. Laten we dus zeker niet stoppen met leren hoe je met en naast je stakeholders kunt werken. Anders zouden we misschien niet slagen als Product Managers. Echter. Echter. (Het is een GROTE echter, dus ik moest er gewoon een tweede bij zetten). Waar ik zelden over lees, zijn al die andere mensen. Degenen die geen belanghebbenden zijn, maar die allemaal vinden dat ze inspraak moeten hebben. Ik heb het over e-mail discussies over de kleur blauw van een knop waarin mensen worden toegevoegd en toegevoegd totdat het "aan:" veld meer tekst bevat dan de body. Ik heb het over mensen die vage productideeën (van zichzelf) als feiten verspreiden en zo verwarring, wanorde en verkeerde afstemming veroorzaken. Ik heb het over vergaderingen met 10 mensen in de zaal terwijl er 4 hadden moeten zijn... Op een gegeven moment had ik het gevoel dat zelfs de kantoorhond zich met mijn zaken bemoeide. En dat haar stinkende input relevanter was dan sommige e-mails die ik aan het verwijderen was. Ik bedoel ontvangen. Dit gebeurt bijna dagelijks en het is klote. Heel erg. Maar het is iets waar we mee om moeten gaan. Als je net als ik bent, zul je dagen hebben waarop je gewoon je jas wilt pakken en weggaan, omdat je niets met deze ellende te maken wilt hebben. Onthoud gewoon: Deze mensen, hoe vervelend ook, bedoelen het (meestal) goed. Kom af en toe eens tussenbeide en maak een einde aan de eindeloze e-maildraad of vergadergekte. We bevinden ons in een perfecte positie om op te merken wanneer chaos de day-to-business schaadt. Gebruik deze positie om een einde te maken aan de chaos. Iedereen, vooral jijzelf, zal zich beter voelen. Als mensen zich blijven bemoeien met jouw werk in plaats van hun werk, is er misschien iets anders aan de hand. Pak een kussen, leg het over je neus en mond en schreeuw wat vloeken. Begin dan een paar gesprekken om te kijken wat er aan de hand is en hoe je het samen kunt oplossen. Als al het bovenstaande mislukt: pak je jas en vertrek. Morgen is er weer een dag. Dus... wie maakt de dienst uit, vraag je je af? Dat hangt ervan af. Eén ding is zeker: sommige dagen draait het er bij Product Manager om dat je een paar grote ballen hebt. Op andere dagen moet je je ego in de koelkast zetten en meegaan met de stroom. Om een van mijn favoriete tv-programma's aller tijden aan te halen: "Welkom bij Product Management. Het is klote. Dit blogartikel is oorspronkelijk geschreven door Samia op Medium. Je kunt de post hier bekijken en Samia's profiel hier .

Leestijd 5 min

Peter Hardeel

Wat is Event Storming? Voordat we in detail treden, bespreken we eerst de rol van Event Storming in een agile context. Event Storming is de afgelopen jaren een zeer populaire methodologie geworden en heeft zijn plaats gevonden in de levenscyclus van softwareontwikkeling als techniek voor het verzamelen van vereisten. Event Storming werd in 2012 ontwikkeld door Alberto Brandolini als een alternatief voor nauwkeurige UML-diagrammen. Het is een workshopachtige techniek die projectstakeholders samenbrengt (zowel ontwikkelaars als niet-technische gebruikers) om complexe bedrijfsdomeinen te verkennen in domeingedreven ontwerparchitectuur . Een van de sterke punten van Event Storming is dat het zich kan richten op de zakelijke belanghebbenden en het hoge interactieniveau. De techniek is eenvoudig en vereist geen enkele technische training. Met Event Storming kun je verschillende doelen nastreven: verbeterpunten van een bestaande bedrijfsstroom identificeren; onderzoeken of een nieuw bedrijfsmodel levensvatbaar is; inzicht krijgen in een gedeeld begrip van hoe een bedrijf werkt; schone en onderhoudbare Event-Driven software ontwerpen. Er zijn drie primaire abstractieniveaus voor Event Storming: Big picture: wordt gebruikt voor het verkennen van het huidige begrip van het systeem door belangrijke mensen met verschillende achtergronden samen te brengen en een gedeeld begrip te creëren. Procesmodellering: op dit niveau modelleren we één bedrijfsproces van begin tot eind, verduidelijken we alle bedrijfsregels en zorgen we ervoor dat iedereen op één lijn zit. Softwareontwerp: in deze laatste stap beginnen we met het ontwerpen van de software op basis van bouwstenen uit Domain-Driven Design en een reactief programmeerparadigma. Elke sticky note kan tijdens de implementatiefase een softwareartefact worden. Bij het toepassen van Event Storming moet je eerst de Domain Events in het probleemdomein identificeren op een tijdlijn. De bron van een Domain Event kan het volgende zijn: Een gebruikersinteractie Een gebeurtenis die plaatsvindt Het gevolg van het verstrijken van de tijd Het gevolg van een andere Domain Event. Vervolgens schrijven we deze domeingebeurtenis op een oranje sticky note. Als alle domeingebeurtenissen gedefinieerd zijn, is de tweede stap het vinden van de opdracht die deze domeingebeurtenissen heeft veroorzaakt. Opdrachten worden op blauwe briefjes geschreven en direct voor de bijbehorende domeingebeurtenis geplaatst. Tenslotte moet je de aggregaten identificeren waarbinnen commando's worden uitgevoerd en waar gebeurtenissen plaatsvinden. Deze aggregaten worden op gele plakbriefjes geschreven. De Systeemmodeler gebruiken In de afgelopen jaren hebben we Event Storming omarmd als een techniek voor het verzamelen van vereisten binnen ACA-IT Solutions - zozeer zelfs, dat het nu een geïntegreerd onderdeel is van ons portfolio en de manier waarop we software ontwikkelen voor onze klanten. Als u daar meer over wilt weten of als u meer wilt weten over Event Storming, kunt u hier contact met ons opnemen . De System Modeler gebruikt EventStorming als inspiratie voor het documenteren (modelleren) van de gebeurtenissen die bedrijfsprocessen vertegenwoordigen, het configureren van high-level eigenschappen die aan deze gebeurtenissen zijn gekoppeld en vervolgens het automatisch genereren van Apps en Collaboration Types vanuit het model. Een System Modeler sessie omvat het gebruik van vijf virtuele sticky notes om te representeren: Gebeurtenis: iets dat gebeurt in het bedrijf Reactie: reacties op gebeurtenissen Opdracht: gebruikergestuurde acties die gebeurtenissen produceren Extern systeem: systemen die extern zijn aan het bedrijf Issue: documenteren van potentiële problemen of onbekenden over gebeurtenissen De System Modeler maakt ook gebruik van één container: Bounded Context: bevat notities die een gemeenschappelijk vocabulaire delen Hieronder ziet u het resultaat van een EventStorming-sessie in de System Modeler, die het melding- en volgsysteem voor gaten in het wegdek van een stad voorstelt. Het model vertegenwoordigt: een mobiele app waarmee stadsbewoners een pothole kunnen melden Aanmaken van nieuwe databaserecords om gemelde gaten te documenteren realtime melding van nieuwe meldingen van gaten aan stadsdiensten medewerkers kunnen de status van een gat bijwerken realtime melding aan de meldende bewoner wanneer de status is gewijzigd System Modeler is een geweldige manier om de kloof te overbruggen tussen het verzamelen van requirements voor een event-driven applicatie en de daadwerkelijke implementatie. In dit geval doen we dat elektronisch op het canvas. Bovendien is dit een samenwerkingsomgeving, waardoor meerdere mensen tegelijkertijd aan dit model kunnen werken. Met de System Modeler kunnen gebruikers samenwerken met meerdere personen, niet alleen in een bepaalde ruimte, maar op een willekeurig aantal geografische locaties. Dit is een geweldige manier om echt een soort gedistribueerde requirements gathering sessie te doen. Zeker nu de pandemie veel mensen ervan weerhoudt om naar kantoor te gaan! Van vereisten naar supersnelle POC's Op basis van deze sessie voor het verzamelen van vereisten kunnen we nu dit vereistenmodel gebruiken en een toepassing maken. Het enige wat gebruikers hoeven te doen is overschakelen van de 'modelmodus' naar de 'genereermodus' en de verschillende elementen groeperen. Nadat de onderwerpen en samenwerkingstaken zijn gedefinieerd, hoeft u alleen maar op de knop Genereren te klikken. Deze eenvoudige handeling alleen al genereert ongeveer 70% van de code van deze specifieke applicatie! Dit maakt System Modeler waarschijnlijk de eenvoudigste manier om zeer snel van het ontwerpen van applicatie-eisen over te gaan op de ontwikkeling van de applicatie zelf. Conclusie Moderne applicaties moeten in real-time werken, omdat ze worden aangestuurd door wat er op dat moment in de echte wereld gebeurt. Ze moeten gemakkelijk kunstmatige intelligentie en IoT-technologie integreren en de applicaties zelf moeten worden gedistribueerd bij de bron van de gebeurtenissen. De softwarelogica moet overal kunnen draaien (cloud, edge, on-premises). Voor deze toepassingen is het ook nodig om mensen in het proces te integreren wanneer een hoger niveau van intuïtie en redenering nodig is. Met System Modeler is het eenvoudig om snel een zeer groot deel van zo'n applicatie te genereren. De System Modeler heeft immers de mogelijkheid om requirements te verzamelen van zakelijke gebruikers, domeinexperts en ontwikkelaars en deze requirements zeer snel om te zetten in een draaiende event-driven applicatie. Het maken van deze supersnelle POC's is een koud kunstje! Als u meer wilt weten over hoe ACA Group en event-driven technologie uw digitale transformatie kunnen versnellen, neem dan contact met ons op! Onze diensten

Leestijd 9 min

Davy Steegen

In deze blogpost wil ik je een overzicht geven van de OAuth 2 specificatie. Toen ik me hierin begon te verdiepen, verdwaalde ik al snel in alle verschillende aspecten. Om ervoor te zorgen dat jij niet hetzelfde hoeft te doen, zal ik OAuth 2 uitleggen alsof je niet eens een technische achtergrond hebt. Omdat er veel te behandelen valt, laten we er meteen in springen! De kernconcepten van beveiliging Als het gaat om het beveiligen van een applicatie, zijn er 2 kernconcepten die je in gedachten moet houden: authenticatie en autorisatie . Authenticatie Met authenticatie probeer je de vraag "Wie is iemand?" of "Wie is deze gebruiker?" te beantwoorden. Je moet het bekijken vanuit het perspectief van je applicatie of je server. Ze hebben in principe vreemdelingengevaar. Ze weten niet wie je bent en er is geen manier voor hen om dat te weten tenzij je je identiteit aan hen bewijst. Authenticatie is dus het proces om aan de applicatie te bewijzen dat je bent wie je beweert te zijn . In een voorbeeld uit de echte wereld is dit het verstrekken van je ID of paspoort aan de politie wanneer ze je aan de kant zetten om jezelf te identificeren. Authenticatie is geen onderdeel van de standaard OAuth 2 specificatie. Er is echter een uitbreiding op de specificatie genaamd Open ID Connect die dit onderwerp behandelt. Autorisatie Autorisatie is de keerzijde van authenticatie. Zodra een gebruiker heeft bewezen wie hij is, moet de applicatie uitzoeken wat een gebruiker mag doen . Dat is in wezen wat het autorisatieproces doet. Een eenvoudige manier om hierover na te denken is het volgende voorbeeld. Als je een leraar bent op een school, heb je toegang tot informatie over de leerlingen in je klas. Als je echter de directeur van de school bent, heb je waarschijnlijk toegang tot de gegevens van alle leerlingen van de school. Je hebt een grotere toegang vanwege je functie. OAuth 2 Rollen Om OAuth 2 volledig te begrijpen, moet je je bewust zijn van de volgende 4 actoren die de specificatie vormen: Eigenaar van de bron Bronnen server Machtigingsserver Client / Toepassing Zoals eerder leggen we het uit met een heel eenvoudig voorbeeld om te zien hoe het echt werkt. Laten we zeggen dat je een jas hebt. Omdat je de eigenaar bent van die jas, ben je de eigenaar van de bron en de jas is de bron die je wilt beschermen. Je wilt het jasje opbergen in een kluisje om het veilig te bewaren. Het kastje zal fungeren als de Resource Server . Je bent geen eigenaar van de Resource Server, maar hij bewaart je spullen voor je. Omdat je wilt voorkomen dat het jasje door iemand anders wordt gestolen, moet je een slot op het kastje zetten. Dat slot is de autorisatieserver . Deze regelt de beveiligingsaspecten en zorgt ervoor dat alleen jij toegang hebt tot de jas of mogelijk iemand anders die jij toestemming geeft. Als je wilt dat je vriend je jasje uit het kastje haalt, dan kan die vriend gezien worden als de Client of Applicatie actor in de OAuth flow. De Client handelt altijd namens de gebruiker. Tokens Het volgende concept waar je veel over zult horen is tokens. Er zijn verschillende soorten tokens, maar ze zijn allemaal heel eenvoudig te begrijpen. De 2 soorten tokens die je het meest tegenkomt zijn access tokens en refresh tokens . Als het gaat om toegangsmunten, heb je misschien wel eens gehoord van JWT-tokens, tokens aan toonder of opake tokens. Dat zijn eigenlijk alleen maar implementatiedetails die ik in dit artikel niet ga behandelen. In essentie is een toegangstoken iets dat je aan de resource server geeft om toegang te krijgen tot de items die hij voor je bewaart. Je kunt toegangsmunten bijvoorbeeld zien als papieren kaartjes die je op de kermis koopt. Als je in een attractie wilt stappen, laat je je ticket zien aan de persoon in het hokje en die laat je instappen. Je maakt een ritje en na afloop verloopt je ticket. Belangrijk om te weten is dat wie het token heeft, eigenaar is van het token . Wees er dus heel voorzichtig mee. Als iemand anders je token in handen krijgt, kan hij of zij namens jou toegang krijgen tot je items! Refresh tokens lijken erg op access tokens. In wezen gebruik je ze om meer toegangsmunten te krijgen. Toegangsmunten hebben meestal een korte levensduur, maar verversingsmunten hebben vaak een langere vervaldatum. Om terug te komen op ons kermisvoorbeeld, een verversingstoken zou de creditcard van je ouders kunnen zijn die kan worden gebruikt om meer kermiskaartjes te kopen die je kunt uitgeven aan attracties. Scopes Het volgende concept dat we behandelen zijn scopes. Een scope is in feite een beschrijving van dingen die een persoon kan doen in een applicatie. Je kunt het zien als een functie in het echte leven (bijvoorbeeld een directeur of leraar op een middelbare school). Bepaalde scopes geven je meer rechten dan andere. Ik weet dat ik zei dat ik niet in technische details zou treden, maar als je bekend bent met Spring Security, dan kun je scopes vergelijken met wat Spring Security rollen noemt. Een scope komt één op één overeen met het concept van een rol. De OAuth specificatie specificeert niet hoe een scope eruit moet zien, maar vaak zijn het punt-gescheiden Strings zoals blog.write . Google daarentegen gebruikt URL's als scope. Als voorbeeld: om alleen-lezen toegang tot iemands agenda toe te staan, geven ze de scope https://www.googleapis.com/auth/calendar.readonly. Toelage types Types van toekenningen zijn typisch waar dingen verwarrend beginnen te worden voor mensen. Laten we beginnen met het tonen van de meest gebruikte grant types: Clientgegevens Machtigingscode Apparaatcode Vernieuwen Wachtwoord impliciet Client Credentials is een type toekenning dat vaak wordt gebruikt als 2 back-end diensten op een veilige manier met elkaar moeten communiceren. De volgende is het grant type Authorization Code , wat waarschijnlijk het moeilijkste grant type is om volledig te begrijpen. Je gebruikt dit type grant wanneer je gebruikers wilt laten inloggen via een browsergebaseerd aanmeldformulier. Als je ooit de knop 'Log in met Facebook ' of 'Log in met Google' op een website hebt gebruikt, dan heb je zonder het te weten al een autorisatiecodestroom ervaren! De volgende is het toestemmingscodetype , dat vrij nieuw is in de OAuth 2-scene. Het wordt meestal gebruikt op apparaten met beperkte invoermogelijkheden, zoals een TV. Als je bijvoorbeeld wilt inloggen op Netflix, in plaats van je gebruikersnaam en wachtwoord op te geven, verschijnt er een link met een code die je moet invullen met de mobiele app. Het Refresh grant type gaat meestal hand in hand met de Authorization Code flow. Omdat toegangstokens een korte levensduur hebben, wil je niet dat je gebruikers telkens moeten inloggen als het toegangstoken verloopt. Dus is er deze refresh flow die refresh tokens gebruikt om nieuwe access tokens te verkrijgen wanneer ze bijna verlopen zijn. De laatste 2 toekenningsvormen zijn Wachtwoord en Impliciet . Deze toekenningsvormen zijn minder veilige opties die niet worden aanbevolen bij het bouwen van nieuwe applicaties. We zullen ze kort behandelen in de volgende sectie, waarin de bovenstaande toekenningsvormen in meer detail worden uitgelegd. Autorisatie stromen Een autorisatiestroom bevat een of meer stappen die moeten worden uitgevoerd om een gebruiker te autoriseren door het systeem. Er zijn 4 autorisatiestromen die we zullen bespreken: Client Credentials stroom Wachtwoord stroom Autorisatie Code stroom Impliciete stroom Client Credentials stroom De Client Credentials stroom is de eenvoudigste stroom om te implementeren. Het werkt ongeveer hetzelfde als hoe een traditionele gebruikersnaam/wachtwoord login werkt. Gebruik deze flow alleen als je de client/applicatie kunt vertrouwen, omdat de client credentials worden opgeslagen binnen de applicatie. Gebruik dit niet voor single page apps (SPA's) of mobiele apps, omdat kwaadwillende gebruikers de app kunnen deconstrueren om de credentials te bemachtigen en deze te gebruiken om toegang te krijgen tot beveiligde bronnen. In de meeste use cases wordt deze flow gebruikt om veilig te communiceren tussen 2 back-end systemen. Hoe werkt de Client Credentials stroom? Elke applicatie heeft een client ID en secret die geregistreerd zijn op de autorisatieserver. De applicatie presenteert deze aan de autorisatieserver om een toegangstoken te krijgen en gebruikt het om de beveiligde bron van de resource server te krijgen. Als op een bepaald moment het toegangstoken verloopt, herhaalt hetzelfde proces zich om een nieuw token te krijgen. Wachtwoord stroom De Password flow lijkt erg op de Client Credentials flow, maar is erg onveilig omdat er een 3e actor bij betrokken is, namelijk een daadwerkelijke eindgebruiker. In plaats van een veilige client die we vertrouwen die een ID en geheim aan de autorisatie provider presenteert, hebben we nu een gebruiker die met een client 'praat'. In een Password flow geeft de gebruiker zijn persoonlijke gegevens aan de client. De client gebruikt deze gegevens om toegangstokens te krijgen van de autorisatieserver. Dit is de reden waarom een Password flow niet veilig is, omdat we er absoluut zeker van moeten zijn dat we kunnen vertrouwen dat de client de credentials niet misbruikt voor kwaadaardige redenen. Uitzonderingen waarbij deze flow nog steeds gebruikt zou kunnen worden zijn commandoregelapplicaties of bedrijfswebsites waarbij de eindgebruiker de client-apps moet vertrouwen die hij dagelijks gebruikt. Maar afgezien hiervan wordt het niet aanbevolen om deze flow te implementeren. Autorisatie Code Stroom Dit is de stroom die je zeker wilt begrijpen, omdat het de stroom is die het meest wordt gebruikt bij het beveiligen van applicaties met OAuth 2. Deze stroom is iets gecompliceerder dan de eerder besproken stromen. Het is belangrijk om te begrijpen dat deze flow vertrouwelijk, veilig en browsergebaseerd is . De flow werkt door veel HTTP redirects te maken, daarom is een browser een belangrijke speler in deze flow. Er is ook een back-channel verzoek (zo genoemd omdat de gebruiker niet betrokken is bij dit deel van de stroom) waarbij de client of applicatie rechtstreeks met de autorisatieserver praat. In deze flow moet de gebruiker meestal de scopes of rechten goedkeuren die aan de applicatie worden toegekend. Een voorbeeld hiervan is een applicatie van derden die vraagt of je toegang mag krijgen tot je Facebook-profielfoto nadat je bent ingelogd met de knop 'Aanmelden met Facebook'. Laten we de Autorisatiecode-flow toepassen op ons voorbeeld 'jas in de kast' om een beter begrip te krijgen. Onze jas ligt in de kast en we willen hem uitlenen aan een vriend. Onze vriend gaat naar het (hightech) kluisje. Het kastje belt ons, want wij zijn de Resource Owner. Deze oproep is een van die redirects waar we het eerder over hadden. Op dit punt maken we een beveiligde verbinding met het kastje, dat fungeert als een autorisatieserver. We kunnen nu veilig onze referenties geven om toestemming te geven om het slot te ontgrendelen. De autorisatieserver verstrekt vervolgens een tijdelijke code, de OAuth-code, aan onze vriend. De vriend gebruikt vervolgens die OAuth-code om een toegangscode te verkrijgen om het kastje te openen en mijn jas te pakken. Impliciete stroom De impliciete flow is in principe hetzelfde als de autorisatiecode flow, maar dan zonder de tijdelijke OAuth code. Dus na het inloggen stuurt de autorisatieserver direct een toegangstoken terug zonder dat er een back-channelverzoek nodig is. Dit is minder veilig, omdat het token onderschept kan worden via een man-in-the-middle aanval. Conclusie OAuth 2 kan er in eerste instantie ontmoedigend uitzien vanwege alle verschillende actoren die erbij betrokken zijn. Hopelijk begrijp je nu beter hoe ze met elkaar samenwerken. Met deze kennis in je achterhoofd is het veel gemakkelijker om de technische details te begrijpen als je je er eenmaal in begint te verdiepen.

Leestijd 5 min

Kamen Zhekov

De webapplicaties en websites van tegenwoordig moeten 24/7 beschikbaar zijn vanaf elke plek ter wereld en moeten bruikbaar en prettig in gebruik zijn vanaf elk apparaat of schermformaat. Daarnaast moeten ze veilig, flexibel en schaalbaar zijn om pieken in de vraag op te vangen. In deze blog laten we u kennismaken met de architectuur van moderne webapplicaties en gaan we dieper in op verschillende back-end en front-end frameworks en hoe ze samenwerken. Wanneer mensen oplossingen vergelijken die worden gebruikt voor het bouwen van webapplicaties en websites, is er meestal sprake van een soort pitting tegen de ander. Hier gaan we tegen deze stroom in en proberen we de verschillen in kaart te brengen, zodat je kunt beslissen of de ene, de andere of beide passen bij de use case die je in gedachten hebt. Een essentieel concept dat moet worden opgemerkt is dat back-end frameworks, zoals Flask of FastAPI , en front-end frameworks, zoals React of Vue JS , twee fundamenteel verschillende technologieën zijn die verschillende, hoewel verwante, problemen oplossen. Ze tegen elkaar uitspelen is daarom geen goede aanpak. Tegenwoordig, als je een iets complexere webapplicatie of websiteoplossing wilt bouwen, heb je vaak solide frameworks nodig die stukjes van zowel de front-end als de back-end kant aanpakken om te bereiken wat je zoekt. De specifieke kenmerken van je applicatie zullen bepalen wat die onderdelen zijn en of het de moeite waard is om te investeren in het gebruik van slechts één van de twee technologieën, of beide in combinatie. Doel van een back-end framework Een back-end framework is het "brein" van je webapplicatie. Het moet zorgen voor de meeste, zo niet alle, taken op het gebied van berekeningen, gegevensbeheer en modelmanipulatie. Laten we het voorbeeld van FastAPI nemen. Hoewel dit back-end webframework voornamelijk wordt gebruikt voor het ontwikkelen van RESTful API's, kan het ook worden toegepast voor het ontwikkelen van complete webapplicaties als het wordt gekoppeld aan een front-end engine zoals Jinja2. Het gebruik van alleen FastAPI en wat templating zou ideaal zijn als je een standalone API wilt waar andere ontwikkelaars mee kunnen communiceren. Een ander goed doel zou een website of webapp zijn die dashboards en inzichten biedt over gegevensinvoer (grafieken gebaseerd op bestanden die je uploadt, etc.) zonder functionaliteiten die afhankelijk zijn van snelle gebruikersinteracties. Hieronder vind je een voorbeeld van een applicatie die volledig is gebouwd met een Python back-end en Jinja2 als templating engine. Klik hier voor meer informatie over het project, de broncode, enz. Het probleem dat je zou kunnen tegenkomen bij het maken van een complete web app of website met FastAPI is dat de hele logica van het programma naar de back-end wordt geduwd, en de enige taak voor de browser en het apparaat aan de kant van de client is het renderen van de HTML/CSS/JS respons die er naar toe wordt gestuurd. De tijd tussen het moment dat de browser het verzoek doet om iets weer te geven en het moment dat de gebruiker het ziet, kan dan enorm variëren op basis van een heleboel factoren. Denk aan de belasting van de server, de snelheid van het internet van de gebruiker, het geheugengebruik of de CPU-efficiëntie van de server, de complexiteit van de gevraagde taak, ... Doel van een front-end framework Tot nu toe kan de back-end zorgen voor alle operaties die we willen dat onze webapp heeft, maar er is geen manier om echt te interageren met de gebruiker. Een front-end framework zorgt voor de gebruikerservaring - UI-elementen zoals knoppen, een landingspagina, een interactieve tutorial, het uploaden van een bestand - in principe verloopt elke interactie met de gebruiker via het front-end framework. Als we kijken naar React of Vue JS - dit zijn front-end frameworks voor het ontwikkelen van dynamische websites en single page applicaties. Ze hebben echter een back-end technologie nodig (zoals FastAPI, Flask of NodeJS) om een RESTful API te bieden, zodat wat ze tonen dynamisch en interactief kan zijn. Alleen React gebruiken zou gebeuren in situaties waarin er al bestaande gegevensbronnen zijn waarmee je kunt interageren (openbare API's, externe gegevensleveranciers, cloudservices, enzovoort) en het enige wat je wilt creëren is de gebruikersinteractie met die services. Maar we kunnen hier al zien dat, in theorie, het combineren van de sterke punten van een solide back-end framework - zoals Flask, FastAPI, of NodeJS - met een goed front-end framework een optie is, en dan nog een hele goede ook. Voorbeelden van die combinatie zijn de BBC World Service News websites die worden gerenderd met behulp van een React-gebaseerde Single Page Application met een NodeJS back-end (Express). Klik hier voor een gedetailleerd overzicht op de GitHub-pagina van het project. In deze gevallen proberen front-end frameworks een deel (of veel) van de taken van de back-end te delegeren naar de client-side. Alleen de computationeel zware delen blijven op de server, terwijl alles wat overblijft en snel uit te voeren is in de browser op het apparaat van de client wordt gedaan. Dit zorgt voor een goede gebruikerservaring, "snappiness" en is in feite een soort decentralisatie van delen van de uitvoering van de webapplicatie, waardoor de belasting en verantwoordelijkheden van de server afnemen. De twee combineren 🤝 Tegenwoordig bestaat de architectuur van goed gebouwde en schaalbare webapplicaties uit een client-side framework dat een toestand bijhoudt, bestaande uit een toestand van de gebruikersinterface en een toestand van het datamodel. Deze toestanden vertegenwoordigen respectievelijk UI-elementen die de visuele ruggengraat van een applicatie vormen, en data-elementen die gekoppeld zijn aan wat voor soort gegevens of modellen (bijvoorbeeld een gebruiker) gebruikt worden doorheen de applicatie. Elke verandering in de toestand van het gegevensmodel veroorzaakt een verandering in de UI-toestand van de applicatie. Veranderingen in de datamodellen worden veroorzaakt door een gebeurtenis die direct van de gebruiker komt (zoals een muisklik) of een gebeurtenis aan de serverkant (zoals de server die zegt dat er een nieuwe melding voor de gebruiker is). De combinatie van al deze factoren zorgt voor een geweldige gebruikerservaring die dichter in de buurt komt van een desktopapplicatie in plaats van een ouderwetse, trage website. Klaar voor meer? In onze volgende blog leggen we de sterke punten van Python en NodeJS uit, en hoe je daartussen moet kiezen.

Leestijd 5 min

Pieter Swennen

Het ontwikkelen van applicaties wordt steeds eenvoudiger dankzij de opkomst van zaken als low-code platforms. Maar ook voor volwaardige ontwikkelaars is het eenvoudiger dan ooit om allerlei applicaties te maken dankzij platforms als Firebase. In deze blogpost geven we een korte introductie tot Firebase, welke functies het heeft en geven we enkele praktijkvoorbeelden van een applicatie die we met Firebase hebben gemaakt. Wat is Firebase? Ik zal de introductie tot Firebase beginnen door kort uit te leggen wat het precies is. Firebase is een platform, ontwikkeld door Google, voor het maken van mobiele en webapplicaties. Het platform biedt een serverloze ontwikkelervaring. Het is echt als een Zwitsers mes voor app-ontwikkelaars, omdat het alles biedt wat nodig is om iOS-, Android- of webapps te bouwen, zoals back-end infrastructuur, monitoring, gebruikersbetrokkenheid en nog veel meer. Het opzetten van een project in Firebase vergt slechts minimale inspanning, omdat het wat onnodige complexiteit wegneemt door een project op te zetten waarmee je kunt beginnen met ontwikkelen. Zo blijft er meer tijd over voor het bouwen van de eigenlijke applicatie! Een ander groot voordeel van het gebruik van Firebase is dat het in wezen een app-ontwikkelingsplatform is dat producten levert die feilloos samenwerken. Een voorbeeld: samen met een collega hebben we Firebase gebruikt om een eenvoudige webapplicatie te maken. We maakten een Angular-app die gegevens kon lezen en schrijven naar een database en e-mailmeldingen kon versturen. Normaal gesproken hadden we tijd moeten besteden aan het opzetten van servers voor het hosten van de applicatie, het maken van een API, het maken van een database en nog veel meer. Maar omdat we Firebase als ontwikkelplatform hadden gekozen, was het zo simpel als firebase init intypen in een console. In een mum van tijd konden we beginnen met het ontwikkelen van de eigenlijke webapplicatie zonder na te denken over alles wat daarbij kwam kijken. Cloud Firestore Cloud Firestore is een no-SQL, real-time database die is ontworpen om de zwaarste workloads van 's werelds populairste apps aan te kunnen. Cloud Firestore is gebouwd op de Google Cloud Platform Database-infrastructuur, die functies zoals multiregionale gegevensreplicatie en multidocumenttransacties mogelijk maakt. Het houdt je data in sync tussen client apps via realtime luisteraars en biedt offline ondersteuning voor mobiel en web, waardoor gebruikers responsieve apps kunnen bouwen die werken ongeacht de netwerklatentie. Bovendien integreert Cloud Firestore naadloos met andere Firebase- en Google Cloud Platform-producten. Bij het maken van onze eenvoudige webapplicatie gebruikten mijn collega en ik Cloud Firestore voor het opslaan, lezen en schrijven van gegevens. Om te communiceren met de Cloud Firestore van Firebase, gebruikten we AngularFireStore van AngularFire. AngularFireStore is een tool om de interactie tussen Firebase en Angular nog makkelijker te maken. Eén ding dat ons opviel toen we Cloud Firestore gebruikten, is dat het een real-time database is. Dat betekent dat zodra de database wordt bijgewerkt, alle apparaten die geïnteresseerd zijn hiervan op de hoogte worden gesteld. In ons geval hadden we een tabel die werd bijgewerkt zodra de database een nieuw of bijgewerkt veld had. En dat allemaal zonder dat je daar raketwetenschap voor nodig hebt! Een ander voordeel van het gebruik van Cloud Firestore is dat gebruikers de datastructuur maar één keer hoeven te definiëren. Laten we zeggen dat we een nieuw veld in ons data-object willen. Het volstaat om dit veld gewoon toe te voegen aan de interface van je objecten, zonder dat je dit veld op verschillende plaatsen hoeft toe te voegen. Cloudfuncties Om wat back-end functionaliteit te hebben, biedt Firebase iets dat Cloud Functions heet. Cloud Functions zijn JavaScript-functies die worden uitgevoerd op specifieke gebeurtenisemitters. We hebben bijvoorbeeld Cloud Functions gebruikt om mailfunctionaliteit toe te voegen aan onze eenvoudige webapp. De Cloud Function luisterde naar een specifiek http-verzoek. Wanneer een gebeurtenis dit verzoek activeerde, werd er een e-mail verzonden met behulp van nodemailer. We gebruikten een extra Cloud Function voor het afhandelen van captcha-verzoeken. Zoals je kunt zien, zijn er veel gebruiksmogelijkheden voor Cloud Functions. Ze kunnen niet alleen luisteren naar http-verzoeken, maar ook naar Firestore-triggers. Het is mogelijk om extra logica uit te voeren wanneer de gegevens worden aangemaakt, bijgewerkt of verwijderd, bijvoorbeeld om een teller te verhogen telkens wanneer een nieuw record wordt opgeslagen in de Firestore. Een ander voordeel is dat deze Cloud Functies volledig geïsoleerd zijn van de client, zodat ze niet reverse-engineered kunnen worden en dus een betere beveiliging bieden. Het is ook mogelijk om een API te bouwen met deze Cloud Functies, mocht je deze willen aanpassen, maar houd dan wel rekening met de quota's . Firebase Hosting Onze webapp moest ook gehost worden. We kozen Firebase Hosting voor een statische webhost. Het coole aan Firebase Hosting is dat het je webapp cached op SSD's over de hele wereld om iedereen een lage latency-ervaring te bieden, ongeacht hun locatie. Een ander voordeel is dat het gratis SSL-certificaten biedt zonder al te veel configuratie. Wat kost het? Firebase biedt 2 plannen: een Spark Plan (gratis) en een Blaze Plan (pay as you go). Voor sommige functies heb je een Blaze Plan nodig, zoals geplande Cloud Functies. Meer informatie en een gedetailleerd overzicht van de kosten vind je hier op de pagina met tariefplannen . Conclusie Ik hoop dat deze kennismaking met Firebase je iets nieuws heeft geleerd. Firebase biedt alles wat je nodig hebt om mobiele of webapps van hoge kwaliteit te bouwen. Firebase is meer dan alleen Cloud Functions, Firestore en hosting. Het biedt ook oplossingen voor authenticatie, bestandsopslag, geautomatiseerde tests, machine learning en nog veel meer. Al deze voordelen komen met één ding om in gedachten te houden: de infrastructuur is gebaseerd op Google (cloud). Dat gezegd hebbende, vonden we dit geen probleem. De tijd en moeite die je bespaart doordat je niet al deze functionaliteiten zelf hoeft in te stellen en een toekomstvaste oplossing biedt, maken het gebruik van Firebase voor veel mensen een no-brainer.