jak píšeme efektivní uživatelské příběhy?
k Dispozici je 5 hlavních zásad, které doporučuji následující:
- Každý by měl být šťastný,
Že všichni na palubě je důležité, takže si každý, kdo bude psát a používat vaše uživatelské příběhy, aby vstup jejich myšlenky a dohodnout se na formátu, který budete používat. - buďte konzistentní
jakmile máte dohodnutou strukturu, ujistěte se, že se jí držíte. - zaměřte se na to, co je důležité
když je píšete, vyhněte se nedůležitým podrobnostem., Udělejte si čas, aby byly stručné, odstraňte jakékoli vafle, protože se jen dostane do cesty. - žádné podrobnosti o implementaci
vždy se zaměřte na „Proč“ ne na „jak“. Proč uživatel něco chce, ne jak to budeme stavět. Pokud potřebujete poskytnout technické údaje, měly by být připojeny jako samostatný soubor spec. - Jasné, proveditelné & testovatelné
ujistěte Se, že každý může pochopit, každý příběh a že to je dosažitelné v časovém rámci jste spokojeni s tím. Pokud dodáváte 2 týdenní sprinty, nemělo by to trvat déle než ty 2 týdny.,
uživatel příběh anatomie
existují 3 povinné části příběhu uživatele, název, popis a kritéria přijetí. Váš tým může souhlasit s tím, že uživatelský příběh musí mít jiná pole, než na něm může začít práce. Můžete například vyžadovat Nabyvatele, příběhové body nebo obchodní dopad, ale považuji je za volitelné, protože ne každá organizace je bude vyžadovat.
Název
Tituly by měly být krátké, jedinečné a ne zavádějící.,
Některé dobré příklady:
- „Přidat, kontaktujte nás panel na domovskou stránku“
- „Přidat debetní kartu, podpora nákupní košík“
- „Aktualizovat e-mailové šablony, značkování,“
Některé méně dobré (bohužel reálný svět) příklady:
- „Provést dohodnuté změny“
- „32072 — Aktualizované Mapování – Upsell příběh Uživatele (27263)“
- „Odkazy — sledování řetězce dotazu pro billa spoušť a inteligentní příspěvek, instalace …“
Popis
popis drží skutečnou moc uživatelská příběh. Mělo by vytvořit empatii v týmu pro uživatele a pochopení problému, který má být vyřešen.,
velmi populární struktura popisu má podobu “ jako … chci … abych mohl…“.
tato struktura vyvolává otázku „jako kdo“? Kdo je uživatel čelí problému? Pokud je používáte, můžete zde odkazovat na osobu, případně dát uživateli jméno a přidat nějaký kontext k situaci uživatele. Snažte se vyhnout použití „jako zákazník“ nebo „jako uživatel“, protože je to méně efektivní při vytváření empatie pro skutečného uživatele.
popis by měl být napsán jednoduchým, jasným jazykem, bez technických termínů nebo zkratek., Měli byste se zeptat sami sebe „může to vaše Nan pochopit?“Nový člen týmu by měl být schopen přečíst popis a přesně pochopit, jaký problém je třeba vyřešit.
následující skutečné příklady jsou převzaty z projektu pro přidání funkčnosti do online účetního systému pro zákazníky Britské energetické společnosti.,
Některé dobré příklady:
- „Jako John, zákazník s tradiční elektroměr, chci pochopit, proč nemůžu vidět grafy mé využití energie v každém více detailů, než měsíc co měsíc, takže se můžu rozhodnout, jestli to chci změnit a získat chytrý měřič nainstalován.“
- “ jako Bart, proaktivní tradiční zákazník měřiče, který se chce ujistit, že můj další účet je přesný, chci vědět, zda již bylo dnes předloženo čtení měřiče a že nemusím předkládat další.,“
Některé méně dobré příklady:
- „Jako uživatel chci, aby se zabránilo trad zákazníky, aby byla schopna přejít pod nejvyšší úroveň tak, aby jejich zkušenosti zákazníků se podařilo“
- „Jako zákazník, který má buď za předpokladu, metr si dnes přečetl, nebo měl paliva číst odhaduje, dnes, Já by nemělo být dovoleno, aby předložily další metr dnes číst jako SAP nemůže přijmout více než jeden metr číst za paliva za den.“
méně dobré příklady byly ve skutečnosti přepsány jako dobré příklady výše, protože problémy, které nastínili, nebyly jasné., Tento proces zdokonalení by měl být proveden kdykoli žádná část uživatelského příběhu není jasná. Jen se ujistěte, že všichni v týmu jsou si vědomi a souhlasí se změnami.
kritéria pro přijetí
kritéria pro přijetí se používají k prokázání úplnosti příběhu uživatele. To je užitečné pro vývojáře a testery.
psaní kritérií přijetí je účinným způsobem, jak projít všemi detaily příběhu před zahájením jakékoli práce. Mnoho potenciálních úskalí nebo neočekávané práce může být“ objeveno “ brzy napsáním dobrých kritérií přijetí.,
velmi populární struktura kritérií pro přijetí má podobu “ dané … Když … pak…“, jak je vidět v níže uvedených příkladech.
pokud má uživatelský příběh více než 10 kritérií pro přijetí, může to znamenat, že příběh dělá příliš mnoho věcí. V tomto případě doporučuji zvážit rozdělení příběhu.
celý tým by měl být zapojen do psaní kritérií pro přijetí. Pokud to není možné, vřele doporučuji všem, čte a souhlasí s nimi, než pracovat na nich. To platí zejména pro každého, kdo se podílí na testování práce.,
číslování kritérií pro přijetí usnadňuje jejich odkaz.
Některé dobré příklady:
- Vzhledem k zákazníkovi s tradiční měřiče na spotřebu energie bar chart
Při kliknutí na nástroj-tip na měsíc,
Pak popup se zobrazí odpovídající zadané design. - s ohledem na dvojí palivo zákazníka sledování spotřeby energie sloupcový graf,
Když mají měsíce s odhadovanými hodnotami
Pak grafu legenda by měla jasně ukázat, odhadem elektřiny ikonu s světle červené bar
Pak grafu legenda by měla jasně ukázat, odhadem plynu ikonu s světle modrý pruh.,
když nepotřebujeme uživatelské příběhy
technické úkoly
někdy se zdá, že se technický úkol netýká zákazníka. Pokud tomu tak je, nepoužívejte příběh uživatele. Ale vždy stojí za zvážení, proč děláte technický úkol; upgradujete knihovnu, abyste zvýšili rychlost pro uživatele? Pokud ano, měl by to být uživatelský příběh.
chyby
Pokud je chyba nalezena během testování uživatelského příběhu, na kterém se právě pracuje, měla by být spojena s tímto uživatelským příběhem.,
Pokud chyba je našel za něco, co není aktuální uživatel příběh, pak by neměla být spojena s uživatelským příběh, ale přidal na zpoždění jako samostatný úkol.
Neustálé zlepšování
Uživatelské příběhy se bude vyvíjet další se dozvěděl o práci. To je dobré, pokračujte v jejich zlepšování až do okamžiku, kdy uvolníte práci uživatelům., Jen se ujistěte, že všichni ve vašem týmu jsou si vědomi a souhlasí s případnými změnami.
pokračujte v rafinaci procesu. Být agilní, přemýšlet o tom, jak vaše uživatelské příběhy pracují pro svůj tým, diskutovat o nich v brzdící rakety a nadále zlepšovat způsob, jakým je píšete.
Napsat komentář