Share
Användarhistorier är en viktig del av hanteringen av tvärvetenskapliga team på komplexa projekt, och de kan också vara användbara för soloutvecklare som vill se till att de levererar en kvalitetsprodukt. Läs vidare och lär dig hur användarberättelser kan förbättra ditt arbetsflöde!
Se kartan? Enorma projekt ser ungefär ut. Det finns många olika grupper som arbetar tillsammans och försöker leverera en underbar produkt. Du kan jämföra dessa lag med olika rutter på kartan. Varje lag har sina egna mål i åtanke och endast vid vissa övergångar träffar lag ihop varandra. Kommunikation är nyckeln in några projekt men ännu viktigare vid stora projekt. Hur kommunicerar du effektivt i sådana projekt?
Jag jobbar hos en app design och utveckling företag i New York City. Ofta går olika projekt igenom kontoret och det är inte alltid klart hur man genomför projekt med olika berörda parter. Det är därför som du i något samarbete måste kunna förstå varandra. Vi valde ett system som är mycket flexibelt och skalbart för att ta itu med både små och stora projekt. Här är lite insikt i vår process.
Användarberättelser hjälper oss att förena våra team när du skapar en produkt. De ansluter varje lag och förbättrar vårt arbetsflöde.
Anslutande lag är en utmaning. Naturligtvis samtalar lag. Huruvida det händer effektivt är tvivelaktigt. Att ha ett system på plats som förbättrar kommunikationen genom att göra det lättare att prata om en teknisk produkt förbättrar hur team samarbetar. Det här är exakt vad användarhistorier handlar om.
Vid Fueled tror vi att vi kan uppnå mer med en smidig process. Det innebär att alla våra team är inblandade från dag ett när en klient vill arbeta med oss. När du har olika team involverade i ett projekt från första dagen kommer det att finnas konflikter och missförstånd om förväntningarna och de önskade resultaten av ett projekt. Hur lyckas du med att planera vissa tekniska begränsningar till en designer eller förklara för en utvecklare hur en mock up fungerar? Människor med olika bakgrund i branschen har ofta olika förväntningar. För människor som har arbetat tillsammans för alltid är det mycket lättare att veta vad som förväntas av varandra, men för nybörjare eller nya anställda är det ofta svårare att kommunicera effektivt i början av ett projekt.
Vi vet alla att det i multidisciplinära miljöer inte alltid är lätt att samarbeta. Det är här användarhistorierna kommer in i spel. Konceptet bakom användarberättelser är okomplicerat. Vad händer om vi använder vårt gemensamma språk, skrivet engelska, för att ansluta lag och uppnå en produkts realisering? Användarhistorier är användarens skriftliga tankar. Detta kan vara ett exempel på en användarhistoria:
Användarhistorier skrivs alltid ur användarens perspektiv.
Ledsagad med användarberättelser är acceptanskriterier. Dessa är i grund och botten en lista över krav som gör att användarhistoriken kan hända. Här är acceptkriterierna för den tidigare användarhistoriken:
Förutom acceptkriterierna följs användarhistorier oftast med en trådram, en prioritet och den aktuella statusen. Här är några fler exempel på möjliga acceptanskriterier som kan följas med en användarhistoria:
Användarberättelser och de medföljande acceptkriterierna är korta, detaljerade informationstyper som kan förklara funktionaliteten hos en viss funktion i en applikation. Samtidigt förstår både designers och utvecklare vad som förväntas av dem. Låt oss använda exemplet på användarhistoriken för bakåtknappen: när designare har sett wireframe och läst acceptanskriterierna vet de att de måste utforma två tillstånd på knappen och utvecklarna vet vilken typ av specifik funktionalitet de behöver för att genomföra.
Jag skulle vilja utarbeta skillnaden mellan användarberättelser och acceptanskriterier. Användarhistorier skrivs alltid ur användarens perspektiv. Godkännande kriterier finns för att klargöra användarberättelser: vad krävs för att en användarhistoria ska fungera?
Som enskild designer eller utvecklare kan du vara frestad att tro att det här inte är relevant för dig. Du vet redan allt som din app ska göra, eller hur? Tyvärr är det osannolikt att det är sant. Godkännande kriterier är fortfarande mycket användbara för kvalitetssäkring och att hitta problem inom din egen kod eller design.
Användarhistorier är också ett användbart verktyg för projektledning i allmänhet. Du kan hålla reda på olika användarberättelser och rapportera fel eller problem. Tillsammans listar användarhistorierna specifikt förväntningarna för funktionaliteten för appen du jobbar på.
Slutligen, om du kanske inte arbetar med en annan lagmedlem idag, vad händer om det ändras imorgon? Du kan förlänga dina berättelser på ett sådant sätt att du kan ge instruktioner för design eller utveckling för att ge ännu mer vägledning för samarbetare.
Det finns självklart mycket mjukvara där ute som gör hanteringen av användarberättelser en enkel och tillgänglig process. Det finns till exempel Mingle, Pivotal Tracker, ScrumDo och många fler. För våra projekt föredrar vi att använda Jira.
Skärmdump av Jira Du är inte beroende av programvara som Jira att använda begreppet användarberättelser när du skapar en applikation. Du kan hålla fast vid kostnadsfria verktyg eller skapa ditt eget sätt att hålla reda på användarberättelser.
Vanligtvis finns det en person som hanterar projektet. Ofta märker vi dessa personer som projektledare eftersom de har den allmänna översikten över projektet. Designers och utvecklare behöver inte ständigt tänka på det större räckviddet, de kan rent fokusera på att användarhistorierna ska hända. När det används korrekt är detta ett system som fungerar ganska bra. En person koncentrerar sig på den större bilden, ger användarberättelser och tänker på hur produkten ska se ut och hur produkten ska fungera. Samtidigt ser dessa människor på att kundernas förväntningar möts under ledning av deras lag. Det är ett sätt att säkerställa kvalitet effektivt.
Detta gör att designers och utvecklare kan fokusera på mycket specifika, definierade funktioner och problem utan att ständigt oroa sig för den större bilden. Användarberättelser och acceptkriterier gör det möjligt och det är enkelt att följa slutproduktens framsteg.
Verktyg som Jira innehåller inbyggd funktionalitet för att följa denna process. Du har friheten att arbeta flexibelt med systemet. Du kan länka vissa problem eller fel med vissa användarberättelser. Om du inte är nöjd med en specifik aspekt av designen kan du relatera till den specifika användarberättelsen. Här på kontoret njuter vi av att arbeta med "epics". En episk är i grunden en grupp användarberättelser. Till exempel har vissa applikationer en episk för varje skärm. På så sätt kan du gruppera funktionaliteterna på en skärm i en grupp, vilket ger dig en ännu bättre översikt över hur snabbt ditt projekt är färdigt eller vilken grupp användarberättelser som svarar för de flesta buggarna. Dessutom kan designers och utvecklare fördela sina resurser bland de olika användarberättelserna genom att ge mer information om tid eller komplexitet i den inblandade funktionaliteten. Det är också möjligt att planera vissa användarberättelser eller epics i en kalender och mikromanage projektets framsteg.
I slutändan är framgången med att arbeta med användarberättelser i ditt eget projekt troligen beroende av flexibiliteten i det system du har implementerat och den frihet som systemet ger att fungera inom det som antingen en individ eller ett lag. Ett bra användarberättelsessystem borde också ge dig möjlighet att hålla en översikt över projektet som helhet i din yttre vision, även om du fokuserar på specifika uppgifter eller funktioner.
Förhoppningsvis ger den här artikeln en inblick i hur vi hanterar stora projekt och säkerställer kvaliteten på de produkter vi skapar. Användarhistorier ser till att du tänker igenom appens funktionalitet och du behåller kundens önskemål. Användarhistorier är bra för produkten, din klient och ditt team!
Accentsconagua