Cum si cand sa le utilizati, cum sa aplicati corect tehnicile si instrumentele

Povestile utilizatorilor nu sunt la fel ca un caz de utilizare. Da, ambii sunt termeni folositi in colectarea cerintelor de la clienti in dezvoltarea de software. Da, ambele identifica utilizatorii si obiectivele utilizatorilor, dar servesc in scopuri diferite.

Povestile utilizatorilor sunt o scurta descriere a ceea ce va face utilizatorul dvs.

Array

atunci cand vin pe site-ul dvs. web sau utilizeaza software-ul dvs. Folosesc limbajul natural al afacerii si nu spun intreaga poveste.

Array

BA scrie criterii de acceptare care definesc limitele unei povesti de utilizator si pot ajuta echipa de dezvoltare sa stie cand o poveste este intr-adevar completa.

O poveste de utilizator este de obicei scrisa in urmatorul format: Ca [actor] vreau [actiune] astfel incat [realizare].

„ Sunt un calator, vreau sa fac check-in pentru un zbor, astfel incat sa pot zbura la destinatie ”.

Array

„ In calitate de proprietar de intreprindere mica, vreau sa creez o factura, astfel incat sa pot factura un client ”. Sau „In calitate de client, vreau sa imi actualizez profilul de client, astfel incat achizitiile viitoare sa fie facturate catre un nou numar de card de credit”.

In Scrum, dezvoltarea produsului dvs.

este impartita intr-o serie de iteratii numite sprinturi, in care fiecare are de obicei intre 2 si 4 saptamani. De obicei, o poveste de utilizator este implementata intr-o singura iteratie a unui proiect agil, in timp ce este obisnuit sa impartiti un caz de utilizare pe mai multe iteratii. In timpul unui sprint, fiecare poveste va parcurge o serie de etape, cum ar fi: neinceput, inceput, in testare, terminat, livrat si acceptat.

Exista un acronim INVEST care este o lista de verificare pentru un set larg acceptat de criterii in care BA si echipa sa pot evalua calitatea povestii utilizatorului. Daca povestea utilizatorului nu indeplineste unul dintre aceste criterii, echipa ar putea lua in considerare rescrierea. Prin urmare, o poveste buna pentru utilizator ar trebui sa fie:

· Independent (de toate celelalte),

· Negociabil (nu este un contract specific pentru viitor),

· Pretuitor (este vorba despre utilizatorul final. Daca nu puteti descrie valoarea pe care un client o va scoate din povestea dvs., nu este o poveste buna),

· Estimabil (la o aproximare buna),

· Mic (pentru a se incadra intr-o iteratie) si

· Testabil (in principiu, chiar daca nu exista inca un test pentru acesta).

Pe de alta parte, cazul de utilizare este o descriere mai detaliata a unui set de interactiuni intre sistem si unul sau mai multi actori, in care un actor este fie un utilizator, fie un alt sistem. Cazul de utilizare este creat ca un document care include:

· Scurta descriere cu obiectivul,

· Declansatorul (eveniment sau secventa de evenimente care initiaza cazul de utilizare),

· Specificati actorii,

· Conditii prealabile (lucrurile care trebuie sa se intample in sistem),

· Debit normal, debit alternativ, exceptii (abateri de la debit normal) si

· Conditii de postare (ce sistem trebuie sa fi fost atins la sfarsitul etapelor de flux normale sau alternative).

Cu alte cuvinte, cazurile de utilizare se refera mai mult la comportamentul pe care echipa tehnica va trebui sa il integreze in software. Dupa cum se mentioneaza in punctele glont, acesta va contine o multime de detalii; descrierea clara a tot ceea ce un dezvoltator trebuie sa construiasca pentru a satisface nevoile utilizatorilor. Si dezvoltatorii vor avea un bun simt ce trebuie sa faca software-ul!

Exista o multime de instrumente agile de cartografiere a povestilor care ii ajuta pe BA sa vizualizeze imaginea de ansamblu, pastrand in acelasi timp toate povestile utilizatorilor si sa foloseasca elementele de caz in perspectiva. Ajuta partile interesate sa ramana la curent cu progresul proiectului lor. Unele dintre ele sunt Jira Agile, Lucidchart, Team Foundation Server, BoardThing, Stories on board, FeatureMap etc.

Pe baza experientei mele, Lucidchart (versiune de incercare gratuita) este destul de usor de utilizat, are sute de sabloane si exemple: Diagramele de flux, Harta mentala, ERD, Sute de forme cu functionalitate usoara de glisare si plasare – Export in PDF, PNG, JPG si Microsoft Visio . Cadrele metalice realizate pe Diagramele Lucide pot fi interactive pentru a afisa ferestre pop-up si diferite stari ale ecranului. Cu toate acestea, daca decideti sa va actualizati contul, exista integrari cu Slack, JIRA, BitBucket, Ofice365, AWS, Excel, Quip etc. Colaborare in timp real: exista mai multe moduri de a partaja diagramele clientilor dvs. si vizualizatorul dvs. poate adaugati cu usurinta comentarii si editati graficul. Software-ul are o functie de istoric al reviziilor, astfel incat sa puteti urmari ceea ce a fost actualizat pe diagrama.

La sfarsit, putem rezuma ca povestile utilizatorilor sunt centrate pe rezultat si pe beneficiul lucrului pe care il descrie clientul, in timp ce cazurile de utilizare sunt mai detaliate si descriu modul in care va functiona software-ul dvs. Ambele plaseaza utilizatorul in centrul eforturilor de dezvoltare, asigurandu-va ca proiectul dvs. software ofera un produs final pe care utilizatorii il doresc si care le satisface nevoile.

Referinta:

  1. International Institute of Business Analysis 2015, A Guide to Business Analyst’s Body of Knowledge® (BABOK® Guide), Versiunea 3.0, Toronto, Ontario, Canada.
  2. Cerinte 101: Povesti de utilizatori vs. cazuri de utilizare

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR