Într-o lume ideală, ca bază pentru crearea de povești de utilizatori, am locuri de muncă pentru clienți (cerere, cercetarea problemelor/oportunităților) sub forma poveștilor de locuri de muncă. Poveștile utilizatorilor sunt o definiție a unei soluții (ofertă).
Adresarea cererilor de afaceri sub forma unei povești de utilizator este metoda tranșei. Învățând să scriu bine poveștile utilizatorilor, doare puțin, dar merită, iar scopul meu este să păstrez evidențe în această formă, nu doar la un lucrător special (analist de afaceri sau proprietar de produs), ci să fiu un instrument pe care îl pot avea în mâinile tuturor (părțile interesate, utilizatorii, dezvoltatorii).
Cum se scrie o poveste de utilizator de calitate
Povestea utilizatorului
Scopul principal al scrierii povestilor utilizatorilor este de a răspunde la întrebări:
1) cui se referă nevoia
2) de ce are nevoie în mod specific
3) de ce are nevoie de ea
Această notație simplă este o modalitate eficientă de a transmite informații despre așteptările dvs. (ce ar trebui să dovedească software-ul).
Identificarea rolurilor și a relațiilor lor în nașterea proiectului mă ajută să pot scrie povestiri complete ale utilizatorilor, este piatra de temelie în jurul căreia este prezentată povestea utilizatorului. Am acoperit rolurile mai detaliat într-un articol separat.
Unul dintre ajutoarele mnemonice care ajută la notarea practică a unei povești de calitate a utilizatorului este acronimul INVEST, care reprezintă un set de atribute:
- Eu - independent
- N - negociabil
- V - valoros
- E - estimabil
- S - mic
- T - testabil
Povestea utilizatorului este o construcție, a cărei îndeplinire poate fi (distractivă) (N), atunci când o livrez încerc să minimizez alte dependențe (I), aduce valoare de afaceri clientului (V), este de preferat ca funcționalitatea din întrebarea este cât se poate de mică (S), astfel încât să poată fi estimată cât mai exact posibil (E) și să poată fi testată (T).
Am putea avea, probabil, discuții fructuoase, mai puțin fructuoase, dar fierbinți asupra acestui acronim. Oricum, este un instrument bun de reținut. De obicei, funcționează prin crearea mai întâi a unei versiuni brute a poveștii utilizatorului și trimiterea acesteia către INVEST.
Criteriul de acceptare
Criteriile de acceptare detaliază specificațiile și elimină ambiguitatea care poate rezulta din simplitatea de a scrie o poveste de utilizator. Criteriile de acceptare servesc ca o listă la îndemână pentru a verifica dacă așteptarea cerinței este îndeplinită.
Dacă criteriul de acceptare pare de complexitate excesivă, este necesar să se ia în considerare dacă valoarea livrată de acesta nu poate fi trasă într-o poveste separată a utilizatorului (divizarea, aplicația I, V și S din acronimul INVEST).
Criteriile de acceptare specifică mai detaliat care ar trebui să fie starea poveștii utilizatorului. Cu toate acestea, nu este nimic care să împiedice ceea ce povestea utilizatorului nu ar trebui să facă în criteriile de acceptare (acest lucru poate ghida de multe ori ambiția programatorului de a găuri în gaura de iepure).
Există o mulțime de teorii pe Internet despre INVEST, structura de bază a poveștii utilizatorului, roluri (oameni) sau criterii de acceptare. Aș adăuga câteva dintre mărturiile mele dovedite pe care mă obișnuiesc să le adaug la povestea utilizatorului. 🙂
Status-quo
Descrierea situației actuale, a problemei, a provocării. Contextualizând cât mai bine posibil. O descriere a soluției actuale la această nevoie, dacă există o soluție (de obicei da). Acest sos întreg oferă rezolvatorului contextul problemei cu care se confruntă. Deoarece suntem specializați în soluție, programatorul ar trebui, din tabelul verde, să se apropie cel mai bine de așteptările clientului, care vor fi formalizate în acest mod (notează).
Eu deja bat paie aici, dar dacă vreau să ajut clientul cu transformarea (el este undeva și vrea să fie altundeva, într-un loc mai bun decât este acum), atunci trebuie să știu de unde merge.
Apetit/ceas de timp
Pofta mea de a rezolva această cerință, sau căsuța de timp, ajută la indicarea cât de doresc să accept soluții (de exemplu, nu doresc în prezent o soluție perfectă, este o soluție temporară).
Materiale de referinta
Scrierea unor formule specifice sălbatice, conform cărora mă aștept ca aplicația să evalueze regula de afaceri (de exemplu, calculul numărului de zile de depozitare sau a valorii așteptate a deprecierii până la sfârșitul perioadei calendaristice), este mai eficientă pentru a ilustra în Excel auxiliar decât criteriile).
Întrebări deschise
În momentul în care se naște documentația viitoarei soluții, apar adesea întrebări fără răspuns, care sunt recomandabile să se consulte cu specialiștii din domeniu sau cu proprietarii proceselor pe care urmează să le automatizăm. Odată ce niște ambiguități au trecut prin cap, nu este o idee bună să le notăm și să găsim spațiu pentru a le răspunde. De asemenea, după ce ați răspuns la aceste întrebări, este bine să le păstrați cu răspunsurile pentru referință (din nou, acestea ajută la plasarea povestii utilizatorului într-un context mai larg).
Dacă știu de verificat ipotezele, conjecturile și numerele verificate verificate ale clientului și am opțiunea (date istorice), este o idee bună să fac acest lucru. Acest lucru poate ajuta la dezvăluirea severității (durerii) pe care clientul o indică. Uneori, severitatea problemei nu este confirmată sau datele sunt mai potrivite pentru a ghida soluția.
Cadru de sarma
O imagine mai bună decât o mie de cuvinte. Recomandarea este ca wireframe să încadreze doar ceea ce vreau să spun. Trebuie să minimalizăm în mod conștient căutarea detaliilor. Ar trebui să las detaliul soluției la persoana proiectantă/UX (dacă am astfel de formală sau informală).
Povestea utilizatorului este un mod eficient de a documenta cerințele afacerii. Lista poveștilor utilizatorilor (indexul poveștilor utilizatorilor) poate răspunde eficient la întrebări chiar și după ce software-ul servește deja utilizatorilor săi - devine o documentație la îndemână.
Ivan Krištof
ajutarea managerilor de proiecte software să îndeplinească așteptările afacerii (ROI)
Restanțe dietetice
Cum să îmblânzești monștrii digitali și unde ne așteaptă? O mică poveste despre ...
Acceptarea software-ului nu este gratuită
Acceptarea software-ului nu este gratuită, costă energia mentală considerabilă a celor care se înscriu la faptul că ceea ce le-a fost livrat (de multe ori pentru mulți bani) funcționează așa cum era de așteptat.