Cum să scrieți poveștile utilizatorului: un ghid complet

Poveștile utilizatorilor sunt o parte vitală a dezvoltării software agile adecvate: să ne uităm la rolul lor și să învățăm cum să scriem poveștile utilizatorilor.

Cadrele Agile sunt o modalitate populară și eficientă de a structura dezvoltarea de software și de a delega sarcini. Scrierea poveștilor utilizatorilor (a nu se confunda cu modul de a scrie o mărturie) este un instrument de dezvoltare agilă care permite dezvoltatorilor să înțeleagă ce trebuie făcut și cum să îndeplinească o cerință. Acest lucru le face un loc de plecare foarte important – dar înseamnă, de asemenea, că trebuie să fie construite cu grijă. Iată ce ar trebui să știți.

Ce este o poveste de utilizator?

Este un termen folosit în dezvoltarea de software într-un cadru agil. Povestea utilizatorului este de obicei considerată cea mai mică unitate din proiectul agil sau primul pas în îndeplinirea unei cerințe. Ele sunt create atunci când un proiect este pe deplin planificat.

Deci, ce înseamnă mai exact asta? Fiecare caracteristică software are (sau ar trebui să aibă) un anumit scop atunci când este adăugată unui proiect. Acest scop ar trebui să influențeze întreaga sa dezvoltare și modul în care este încorporat în cadrul general. Dezvoltatorii pot face referire la acest scop ori de câte ori este nevoie pentru a lua decizii, în special cu privire la modul de defalcare a obiectivelor și la ce să prioritizeze. „Povestea utilizatorului” este pur și simplu o modalitate de a descrie scopul unei caracteristici.

Poveștile utilizatorilor sunt scrise din perspectiva unui utilizator, de obicei doar într-o propoziție sau două. Acestea captează punctul de vedere al utilizatorului și ceea ce acesta dorește să facă. Când sunt finalizate, poveștile bune ale utilizatorilor sunt o modalitate ușoară de a vorbi despre obiectivele strategice, ce caracteristici pot fi eliminate în siguranță sau ar trebui adăugate și multe altele.

Cum se scrie o poveste de utilizator

Pasul 1. Obțineți intrare

Obțineți informații de la proprietari, potențiali utilizatori și manageri de proiect. O poveste de utilizator puternică are nevoie de multă contribuție pentru a fi exactă. Obțineți explicații clare de la aceste grupuri despre ceea ce doresc să facă. Rețineți că acest lucru nu ar trebui să se traducă direct în povestea utilizatorului, ci va oferi informațiile necesare. Un proprietar ar putea spune: „Am nevoie de oameni care să poată plăti cu PayPal în aplicația mea”, ceea ce este foarte util, dar nu povestea utilizatorului în sine.

Pasul 2. Decideți cum sunt create poveștile utilizatorilor

Acest lucru depinde de fluxul dvs. de lucru. În primele etape, poveștile utilizatorilor sunt capturate pe carduri index sau post-it în timp ce se planifică cadrul general. Ulterior, acestea sunt încorporate în software-ul de management al proiectelor. Unii membri ai echipei opresc etapa de post-it, în timp ce alții se bazează pe ea – oricare ar fi potrivit pentru tine.

Pasul 3. Definiți, definiți, definiți

Definiți utilizatorul: Cu intrare, acum puteți defini utilizatorul. Rețineți că acesta nu este întotdeauna utilizatorul final al caracteristicilor produsului; poate varia in functie de tipul de utilizator. Creați personaje de utilizator dacă este necesar. Definiți acțiunea pe care o întreprinde utilizatorul și definiți scopul utilizatorului în realizarea acestei acțiuni. Includeți aceste informații cheie atunci când vă creați povestea utilizatorului pentru a vorbi cu publicul țintă.

Pasul 4. Scrieți povestea

Începeți să scrieți povestea dvs. de utilizator, ar trebui să fie lungă doar de o propoziție sau două pentru a reține atenția cititorului. Este tentant să fii precis și tehnic aici, dar un limbaj larg, cum ar fi declarațiile de misiune, poate fi de ajutor. Faceți povestea clară și asigurați-vă că poate fi rezolvată sau finalizată, astfel încât să puteți privi înapoi și să confirmați „Da, utilizatorii pot face asta acum!”.

Pasul 5. Împărțiți-vă în pași suplimentari

Poveștile utilizatorilor pot avea nevoie de mai mulți pași pentru a atinge obiectivul final, ceea ce ar putea necesita puțină restructurare, în funcție de cadrul agil pe care îl utilizați. Amintiți-vă, povestea utilizatorului este întotdeauna cea mai mică unitate din cadru. La acest nivel granular, implementarea poveștilor utilizatorilor ar trebui să dureze câteva zile.

Dacă se pare că vor dura mult mai mult, acesta este un semn de revizuit și de a vedea dacă experiența utilizatorului trebuie defalcată în continuare și restructurată. Dacă se adaugă cerințe noi, acestea vor trebui, de asemenea, împărțite în povești de utilizator. Deși aceste câteva propoziții sunt nucleul poveștilor eficiente ale utilizatorilor, ele pot fi, de asemenea, extinse pe măsură ce dezvoltarea continuă. Să aruncăm o privire mai atentă la asta.

Care sunt cele 3 C din User Stories?

Card : Faza Card se referă la scrierea poveștilor utilizatorilor pentru echipa de dezvoltare într-o propoziție sau două. Se numește card pentru că poveștile utilizatorilor au fost scrise inițial pe carduri și multe echipe încă preferă să o facă așa. Cardul este nucleul cerințelor sale specifice de software și punctul de plecare pentru toate discuțiile. De asemenea, este ușor să verificați dacă povestea dvs. de utilizator este prea lungă – dacă nu poate încadra pe un card pe care toată lumea o poate citi, trebuie scurtată.

Conversație : Odată ce propozițiile Cardului au fost create, este timpul să dezvăluiți detaliile. Aceasta începe de obicei ca o serie de întrebări între dezvoltatori, cum ar fi „Cât timp va dura implementarea?” sau „Cum putem încorpora această acțiune?” sau „Este această poveste de utilizator esențială aici?” Și așa mai departe.

Această examinare atentă a poveștii utilizatorului va genera probabil întrebări suplimentare de adresat managerilor de proiect și proprietarilor de produse, care ar trebui să fie aduși în conversație dacă este necesar. Pe măsură ce conversația continuă, poveștile utilizatorilor pot fi modificate, rafinate, îmbinate sau eliminate până când toată lumea se află pe aceeași pagină. Pe măsură ce poveștile utilizatorilor sunt finalizate, acestea sunt mutate în implementare, un semn că conversația sa încheiat în esență.

Confirmare : Confirmarea se referă la testele de acceptare, adică criteriile de acceptare. Odată ce schimbarea a fost implementată, iar dezvoltatorii raportează că este gata – că povestea utilizatorului a fost satisfăcută – este timpul să o testăm.

Testele de acceptare ar trebui să fie create cu contribuția proprietarului produsului și să fie legate direct de povestea utilizatorului. În cel mai bun scenariu, este un utilizator care pur și simplu încearcă să facă ceea ce indică povestea utilizatorului și vede dacă poate. Dar testele de acceptare pot varia și nu sunt întotdeauna realizate având în vedere poveștile utilizatorilor așa cum ar trebui să fie. Dacă acest lucru creează o problemă, este timpul să reveniți la pasul Conversație până când testele de acceptare și poveștile utilizatorilor sunt aliniate corespunzător. Dacă toate testele de acceptare sunt finalizate, povestea utilizatorului este încântată. Acum este timpul fie să trecem la următorul pas în dezvoltarea produsului, fie să lansăm funcția.

Un al 4-lea C? : Interesant, unii susțin că există un al 4-lea C esențial: Context. În acest caz, povestea utilizatorului este vizualizată alături de celelalte povești de utilizator în cadrul mai mare al proiectului. Aici, dezvoltatorii întreabă dacă povestea utilizatorului completează fără probleme alte povești de utilizator sau dacă există lacune – lucruri pe care utilizatorul trebuie să le facă sau să înțeleagă care au fost omise între poveștile utilizatorului.

În mod ideal, acest lucru este observat în timpul fazei de conversație, dar asta nu se întâmplă întotdeauna. Unele echipe de dezvoltare ar putea dori o revizuire finală a modului în care povestea completată a utilizatorului se încadrează în întregul ansamblu și dacă este nevoie de muncă suplimentară.

Ce este un format bun pentru o poveste de utilizator?

Să trecem peste două tehnici de formatare care sunt foarte utile atunci când creați propoziții cu povestea utilizatorului. Primul este foarte simplu: „Cine, ce și de ce?” Într-un șablon de propoziție, acesta poate fi descris astfel:

Ca [Cine este utilizatorul], vreau să [Ce dorește utilizatorul] (astfel încât [De ce vrea utilizatorul]).

Acest șablon poate fi, de asemenea, încadrat ca: „Ca [rol], vreau să [acționez], (pentru ca [beneficia]),” pentru terminologie simplificată. Urmărirea acestui format de bază este suficientă pentru a crea majoritatea poveștilor utilizatorilor. De obicei, este tot ceea ce aveți nevoie și vă poate ajuta să economisiți mult timp atunci când este utilizat pentru fiecare poveste de utilizator.

Uneori, totuși, poveștile utilizatorilor sunt mai greu de definit în proiecte mai complexe. În acest caz, o a doua tehnică de șablon de poveste de utilizator poate fi utilă. Se numește INVEST, un acronim care înseamnă:

• Independente : poveștile ar trebui să fie complet independente unele de altele și, ca rezultat, poveștile ar trebui să poată fi lucrate în afara secvenței.
• Negociabil : poveștile ar trebui să fie concepute pentru a fi modificate în timpul părții de conversație a procesului.
• Valoros : Povestea utilizatorului ar trebui să demonstreze o valoare clară pentru proiect. Dacă nu se poate, poate fi o risipă de resurse.
• Estimabil : o poveste de utilizator trebuie măsurată în valoare și prioritizare pentru a ajuta la deciderea asupra cărora să lucreze în ordinea importanței.
• Mic : poveștile utilizatorilor trebuie să fie cea mai mică unitate de funcționalitate și, altfel, ar trebui să fie defalcate în continuare.
• Testabil : Povestea utilizatorului trebuie să fie declarată într-un mod care poate fi testat în timpul procesului de confirmare.

Întrebări frecvente despre cum să scrieți poveștile utilizatorilor

Ați putea fi, de asemenea, interesat de ghidul nostru despre cum să scrieți o recenzie a jocului.