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 .