Share
User Stories zijn een cruciaal onderdeel van het beheer van interdisciplinaire teams over complexe projecten, en ze kunnen ook nuttig zijn voor solo-ontwikkelaars die willen zorgen dat ze een kwaliteitsproduct leveren. Lees verder en ontdek hoe gebruikersverhalen uw projectworkflow kunnen verbeteren!
Zie de kaart? Enorme projecten zien er ongeveer hetzelfde uit. Er zijn veel verschillende teams die samenwerken om een prachtig product te leveren. Je kunt die teams vergelijken met de verschillende routes op de kaart. Elk team heeft zijn eigen doelen voor ogen en alleen bij bepaalde overtochten halen teams elkaar in. Communicatie speelt een sleutelrol ieder project maar nog belangrijker in grote projecten. Hoe communiceer je effectief in dergelijke projecten?
Ik werk bij een ontwerp- en ontwikkelingsbureau voor apps in New York City. Vaak passeren verschillende projecten het kantoor en is het niet altijd duidelijk hoe projecten met verschillende betrokken partijen moeten worden voltooid. Daarom moet je in elke samenwerking elkaar kunnen begrijpen. We kozen voor een systeem dat zeer flexibel en schaalbaar is om zowel kleine als grote projecten aan te pakken. Hier is wat inzicht in ons proces.
Gebruikersverhalen helpen onze teams te verenigen bij het maken van een product. Ze verbinden elk team en verbeteren onze workflow.
Het verbinden van teams is een uitdaging. Uiteraard communiceren teams met elkaar. Of dat effectief gebeurt, is twijfelachtig. Het hebben van een systeem dat de communicatie verbetert door het gemakkelijker te maken om over een technisch product te praten, verbetert de manier waarop teams samenwerken. Dit is precies waar gebruikersverhalen over gaan.
Bij Fueled geloven we dat we meer kunnen bereiken met een agile proces. Dit betekent dat al onze teams vanaf de eerste dag betrokken zijn wanneer een klant met ons wil werken. Wanneer u vanaf de eerste dag verschillende teams bij een project betrekt, zullen er conflicten en misverstanden ontstaan over de verwachtingen en de gewenste resultaten van een project. Hoe ontwerp je bepaalde technische beperkingen met succes aan een ontwerper of leg je een ontwikkelaar uit hoe een mock-up zal werken? Mensen met verschillende achtergronden in de branche hebben vaak andere verwachtingen. Voor mensen die voor altijd hebben samengewerkt, is het een stuk eenvoudiger om te weten wat er van elkaar wordt verwacht, maar voor startups of nieuwe werknemers is het vaak moeilijker om effectief te communiceren aan het begin van een project.
We weten allemaal dat samenwerken in multidisciplinaire omgevingen niet altijd gemakkelijk is. Dit is waar gebruikersverhalen een rol gaan spelen. Het concept achter gebruikersverhalen is duidelijk. Wat als we onze gemeenschappelijke taal, geschreven Engels, gebruiken om teams te verbinden en de realisatie van een product te realiseren? Gebruikersverhalen zijn de geschreven gedachten van de gebruiker. Dit kan een voorbeeld zijn van een gebruikersverhaal:
Gebruikersverhalen worden altijd geschreven vanuit het perspectief van de gebruiker.
Vergezeld met gebruikersverhalen zijn acceptatiecriteria. Dit zijn in feite een lijst met vereisten die het gebruikersverhaal mogelijk maken. Dit zijn de acceptatiecriteria voor het vorige gebruikersverhaal:
Naast de acceptatiecriteria worden gebruikersverhalen meestal vergezeld van een draadframe, een prioriteit en de huidige status. Hier zijn enkele voorbeelden van mogelijke acceptatiecriteria die kunnen worden gevonden bij een gebruikersverhaal:
Gebruikersverhalen en de bijbehorende acceptatiecriteria zijn korte, gedetailleerde stukjes informatie die de functionaliteit van een bepaalde functie in een toepassing kunnen verklaren. Tegelijkertijd begrijpen zowel ontwerpers als ontwikkelaars wat van hen wordt verwacht. Laten we het voorbeeld van het gebruikersverhaal van de back-knop gebruiken: zodra ontwerpers het wireframe hebben gezien en de acceptatiecriteria hebben gelezen, weten ze dat ze twee toestanden van de knop moeten ontwerpen en weten de ontwikkelaars wat voor soort specifieke functionaliteit ze nodig hebben om te implementeren.
Ik wil graag nader ingaan op het verschil tussen gebruikersverhalen en acceptatiecriteria. Gebruikersverhalen worden altijd geschreven vanuit het perspectief van de gebruiker. Acceptatiecriteria zijn er om gebruikersverhalen te verduidelijken: wat nodig is om een gebruikersverhaal te laten werken?
Als individuele ontwerper of ontwikkelaar kom je misschien in de verleiding om te denken dat dit niet relevant voor je is. U weet al alles wat uw app moet doen, toch? Helaas is het onwaarschijnlijk dat dit waar is. Acceptatiecriteria zijn nog steeds uiterst nuttig voor kwaliteitsborging en het vinden van problemen binnen uw eigen code of ontwerp.
Gebruikersverhalen zijn ook een handig hulpmiddel voor projectbeheer in het algemeen. U kunt verschillende gebruikersverhalen bijhouden en bugs of problemen melden. Gebruikersverhalen geven immers met name een overzicht van de verwachtingen voor de functionaliteit van de app waaraan u werkt.
Tot slot, terwijl u vandaag misschien niet met een ander teamlid werkt, wat als dat morgen verandert? U kunt uw verhalen op zo'n manier uitbreiden dat u instructies voor ontwerp of ontwikkeling kunt geven om nog meer begeleiding te bieden aan medewerkers.
Natuurlijk is er heel wat software die het beheren van gebruikersverhalen een eenvoudig en toegankelijk proces maakt. Er zijn bijvoorbeeld Mingle, Pivotal Tracker, ScrumDo en nog veel meer. Voor onze projecten gebruiken we Jira het liefst.
Screenshot van Jira Je bent niet afhankelijk van software zoals Jira om het concept van gebruikersverhalen te gebruiken tijdens het maken van een applicatie. U kunt zich aan gratis tools houden of uw eigen manier creëren om gebruikersverhalen bij te houden.
Gewoonlijk is er één persoon die het project beheert. Vaak bestempelen we die mensen als projectmanagers omdat ze het algemene overzicht van het project hebben. Ontwerpers en ontwikkelaars hoeven niet voortdurend aan de grotere reikwijdte te denken, ze kunnen zich puur concentreren op het laten gebeuren van de gebruikersverhalen. Bij correct gebruik is dit een systeem dat vrij goed werkt. Eén persoon concentreert zich op het grotere geheel, biedt gebruikersverhalen en denkt na over hoe het product eruit zou moeten zien en hoe het product zou moeten functioneren. Tegelijkertijd zorgen deze mensen ervoor dat aan de verwachtingen van klanten wordt voldaan terwijl ze hun team leiden. Het is een manier om kwaliteit effectief te garanderen.
Hierdoor kunnen ontwerpers en ontwikkelaars zich concentreren op zeer specifieke, gedefinieerde functionaliteiten en problemen zonder zich voortdurend zorgen te maken over het grotere geheel. Gebruikersverhalen en acceptatiecriteria maken dit haalbaar en het is gemakkelijk om de voortgang van het eindproduct te volgen.
Tools zoals Jira bevatten ingebouwde functionaliteit voor het volgen van dit proces. Je hebt de vrijheid om flexibel met het systeem te werken. U kunt bepaalde problemen of fouten koppelen aan bepaalde gebruikersverhalen. Als u niet tevreden bent met een specifiek aspect van het ontwerp, kunt u zich verhouden tot dat specifieke gebruikersverhaal. Hier op kantoor werken we graag met "epics". Een epos is in feite een groep gebruikersverhalen. Bepaalde applicaties hebben bijvoorbeeld een epos voor elk scherm. Op deze manier kunt u de functies van een scherm in één groep groeperen, zodat u een nog beter overzicht krijgt van hoe snel uw project wordt voltooid of welke groep gebruikersverhalen verantwoordelijk is voor de meerderheid van de fouten. Daarnaast kunnen ontwerpers en ontwikkelaars hun middelen toewijzen aan de verschillende gebruikersverhalen door meer informatie te verstrekken over de tijd of de complexiteit van de betreffende functionaliteit. Het is ook mogelijk om bepaalde gebruikersverhalen of epics in een kalender te plannen en de voortgang van een project te micromanage.
Uiteindelijk is het succes van het werken met gebruikersverhalen in uw eigen project waarschijnlijk afhankelijk van de flexibiliteit van het systeem dat u hebt geïmplementeerd en de vrijheid die het systeem biedt om daarin te werken als een individu of een team. Een goed systeem voor gebruikersverhalen zou u ook in staat moeten stellen om een overzicht van het project als geheel in uw perifere visie te houden, zelfs wanneer u zich richt op specifieke taken of functies.
Hopelijk biedt dit artikel enig inzicht in hoe we grote projecten aanpakken en kwaliteit garanderen voor de producten die we maken. Gebruikersverhalen zorgen ervoor dat u nadenkt over de functionaliteit van uw app en dat u de wensen van de klant in gedachten houdt. Gebruikersverhalen zijn geweldig voor het product, uw klant en uw team!
Accentsconagua