Share
Brukerhistorier er en viktig del av styring av tverrfaglige team på komplekse prosjekter, og de kan også være nyttige for solo-utviklere som ønsker å sikre at de leverer et kvalitetsprodukt. Les videre og lær hvordan brukerhistorier kan forbedre prosjektets arbeidsflyt!
Se kartet? Enorme prosjekter ser omtrent det samme ut. Det er mange forskjellige lag som jobber sammen, prøver å levere et fantastisk produkt. Du kan sammenligne de lagene med de forskjellige rutene på kartet. Hvert lag har sine egne mål i bakhodet, og bare ved enkelte kryssinger får lagene med på hverandre. Kommunikasjon er nøkkelen inn noen prosjektet, men enda viktigere i store prosjekter. Hvordan kommuniserer du effektivt i slike prosjekter?
Jeg jobber hos en app design og utvikling firma i New York City. Ofte går det forskjellige prosjekter gjennom kontoret, og det er ikke alltid klart hvordan man fullfører prosjekter med ulike involverte interessenter. Det er derfor i et samarbeid du trenger for å kunne forstå hverandre. Vi har valgt et system som er svært fleksibelt og skalerbart, for å takle både små og store prosjekter. Her er litt innsikt i prosessen vår.
Brukerhistorier hjelper forene våre lag når du lager et produkt. De forbinder hvert lag og forbedrer arbeidsflyten vår.
Koble lag er en utfordring. Selvfølgelig kommuniserer lagene. Enten det skjer effektivt er tvilsomt. Å ha et system på plass som forbedrer kommunikasjonen ved å gjøre det enklere å snakke om et teknisk produkt, forbedrer hvordan lagene samarbeider. Dette er akkurat hva brukerhistorier handler om.
På Fueled tror vi at vi er i stand til å oppnå mer med en smidig prosess. Dette betyr at alle våre lag er involvert fra dag ett når en klient ønsker å jobbe med oss. Når du har forskjellige lag involvert i et prosjekt fra den første dagen, vil det være konflikter og misforståelser på forventningene og de ønskede resultatene av et prosjekt. Når alt kommer til alt, hvordan planlegger du med suksess visse tekniske begrensninger for en designer eller forklarer en utvikler hvordan en mock up vil fungere? Folk med ulik bakgrunn i bransjen har ofte ulike forventninger. For folk som har jobbet sammen for alltid, er det mye lettere å vite hva som forventes av hverandre, men for oppstart eller nye medarbeidere er det ofte vanskeligere å kommunisere effektivt ved starten av et prosjekt.
Vi vet alle at samarbeid i tverrfaglige miljøer ikke alltid er lett. Dette er hvor brukerhistorier kommer inn i spill. Konseptet bak brukerhistorier er greit. Hva om vi bruker vårt felles språk, skrevet engelsk, for å koble sammen lag og oppnå realiseringen av et produkt? Brukerhistorier er brukerens skriftlige tanker. Dette kan være et eksempel på en brukerhistorie:
Brukerhistorier er alltid skrevet ut fra brukerens perspektiv.
Ledsaget av brukerhistorier er akseptkriterier. Disse er i utgangspunktet en liste over krav som gjør at brukerhistorien kan skje. Her er akseptkriteriene for den tidligere brukerhistorien:
Foruten godkjennelseskriteriene er brukerhistorier vanligvis ledsaget av en wireframe, en prioritet og gjeldende status. Her er noen flere eksempler på mulige akseptkriterier som kan bli funnet som følger med en brukerhistorie:
Brukerhistorier og tilhørende akseptkriterier er korte, detaljerte opplysninger som kan forklare funksjonaliteten til en bestemt funksjon i en applikasjon. Samtidig forstår både designere og utviklere hva som forventes av dem. La oss bruke eksemplet på brukerknappen til bakknappen: Når designere har sett wireframe og har lest akseptasjonskriteriene, vet de at de trenger å designe to tilstander på knappen og utviklerne vet hva slags spesifikk funksjonalitet de trenger for å implementere.
Jeg vil gjerne utdype forskjellen mellom brukerhistorier og akseptkriterier. Brukerhistorier er alltid skrevet ut fra brukerens perspektiv. Godkjenningskriterier er der for å avklare brukerhistorier: hva som kreves for å gjøre en brukerhistorie jobbig?
Som en individuell designer eller utvikler kan du bli fristet til å tro at dette ikke er relevant for deg. Du vet allerede alt som appen din burde gjøre, ikke sant? Dessverre er dette usannsynlig å være sant. Godkjenningskriterier er fortsatt svært nyttige for kvalitetssikring og å finne problemer i egen kode eller design.
Brukerhistorier er også et nyttig verktøy for prosjektledelse generelt. Du kan holde styr på ulike brukerhistorier og rapportere feil eller problemer. Tross alt viser brukerhistorier spesielt forventningene til funksjonaliteten til appen du jobber med.
Til slutt, mens du kanskje ikke jobber med et annet lagmedlem i dag, hva hvis det endres i morgen? Du kan forlenge historiene dine på en slik måte at du kan gi instruksjoner for design eller utvikling for å gi enda mer veiledning for samarbeidspartnere.
Selvfølgelig er det mye programvare der ute som gjør administrerende brukerhistorier en enkel og tilgjengelig prosess. For eksempel er det Mingle, Pivotal Tracker, ScrumDo og mange flere. For våre prosjekter, foretrekker vi å bruke Jira.
Skjermbilde av Jira Du er ikke avhengig av programvare som Jira for å bruke konseptet brukerhistorier mens du oppretter et program. Du kan holde deg til gratis verktøy eller lage din egen måte å holde oversikt over brukerhistorier.
Vanligvis er det en person som styrer prosjektet. Ofte merker vi de som prosjektleder som de har den generelle oversikten over prosjektet. Designere og utviklere er ikke pålagt å hele tiden tenke på det større omfanget, de kan rent fokusere på å gjøre brukerhistoriene skje. Når det brukes riktig, er dette et system som fungerer ganske bra. En person konsentrerer seg om det større bildet, gir brukerhistorier og tenker på hvordan produktet skal se ut og hvordan produktet skal fungere. Samtidig sørger disse menneskene for at forventningene til klientene blir møtt mens de styrer sitt lag. Det er en måte å sikre kvaliteten på effektivt.
Dette gjør det mulig for designere og utviklere å fokusere på svært spesifikke, definerte funksjoner og problemer uten å stadig bekymre seg for det større bildet. Brukerhistorier og akseptkriterier gjør dette mulig, og det er enkelt å følge fremdriften til sluttproduktet.
Verktøy som Jira inkluderer innebygd funksjonalitet for å følge denne prosessen. Du har frihet til å jobbe fleksibelt med systemet. Du kan knytte bestemte problemer eller feil med visse brukerhistorier. Hvis du ikke er fornøyd med ett bestemt aspekt av designet, kan du forholde seg til den spesifikke brukerhistorien. Her på kontoret, liker vi å jobbe med "epics". En episk er i utgangspunktet en gruppe brukerhistorier. For eksempel har enkelte applikasjoner en episk for hver skjerm. På denne måten kan du gruppere funksjonalitetene til en skjerm i en gruppe, og gi deg en enda bedre oversikt over hvor raskt prosjektet ditt blir fullført eller hvilken gruppe brukerhistorier som er ansvarlig for flertallet av feilene. I tillegg er designere og utviklere i stand til å tildele sine ressurser blant de ulike brukerhistoriene ved å gi mer informasjon om tid eller kompleksitet av funksjonaliteten som er involvert. Det er også mulig å planlegge visse brukerhistorier eller epikser i en kalender og mikromanage fremdriften av et prosjekt.
Til syvende og sist vil suksessen med å arbeide med brukerhistorier i ditt eget prosjekt trolig være avhengig av fleksibiliteten til systemet du har implementert, og den friheten systemet gir for å fungere i det som enten en person eller et lag. Et godt brukerhistoriesystem bør også gi deg oversikt over prosjektet som helhet i din perifere visjon, selv om du fokuserer på bestemte oppgaver eller funksjoner.
Forhåpentligvis gir denne artikkelen litt innsikt i hvordan vi takler store prosjekter og sikrer kvalitet for produktene vi lager. Brukerhistorier sørger for at du tenker gjennom funksjonen til appen din, og du beholder kundens ønsker i tankene. Brukerhistorier er gode for produktet, klienten og teamet ditt!
Accentsconagua