Un ghid Perfect pentru criteriile de acceptare a poveștii Utilizatorului cu scenarii din viața reală:
în industria de dezvoltare Software, Cuvântul „cerință” definește care este obiectivul nostru, de ce au nevoie exact clienții și ce va face compania noastră să-și crească afacerea.fie că este vorba de o companie de produse care produce produse software sau de o companie de servicii care oferă servicii în diverse domenii software, baza principală pentru toate acestea este cerința, iar succesul este definit de cât de bine sunt îndeplinite cerințele.,
termenul „cerință” are denumiri diferite în diferite metodologii de proiect.
În cascadă, este denumit „document cerință/ specificație”, în Agile sau SCRUM este denumit „Epic”, „poveste utilizator”.sub modelul cascadă, documentele de cerință sunt documente uriașe de 200 sau mai multe pagini, deoarece întregul produs este implementat într-o singură fază. Dar acest lucru nu este cazul cu Agile/SCRUM, deoarece în aceste metodologii cerințele sunt date pentru funcționalități mici sau caracteristici, deoarece produsul este pregătit într-o manieră pas cu pas.,în acest articol, am încercat tot posibilul să împărtășesc toți cei 4 ani de experiență în lucrul cu poveștile utilizatorilor și criteriile de acceptare aferente acestora, împreună cu scenarii simple și simple din viața reală pentru o mai bună înțelegere.
să ne re-vizita fundamentele primul.
ce este o poveste de utilizator?
o poveste de utilizator este o cerință pentru orice funcționalitate sau caracteristică care este scrisă în una sau două linii și max până la 5 linii. O poveste de utilizator este de obicei cea mai simplă cerință posibilă și este despre una și numai o singură funcționalitate (sau o caracteristică).,
Cele mai frecvent utilizate format standard pentru un Utilizator Povestea creației este precizat mai jos:
<rol de utilizator/client, Vreau să < scopul de a fi realizat> așa că nu pot <motiv de scopul>.ca utilizator WhatsApp, vreau o pictogramă a camerei în caseta de scriere a chatului pentru a captura și a trimite imagini, astfel încât să pot face clic și să împărtășesc fotografiile simultan cu toți prietenii mei.
ce este un criteriu de acceptare?,
un criteriu de acceptare este un set de condiții acceptate sau reguli de afaceri pe care funcționalitatea sau caracteristica ar trebui să le îndeplinească și să le îndeplinească, pentru a fi acceptate de proprietarul produsului/părțile interesate.aceasta este o parte foarte importantă a finalizării poveștii utilizatorului și ar trebui studiată foarte meticulos de către proprietarul produsului și analistul de afaceri, deoarece lipsa unui singur criteriu poate costa foarte mult. Aceasta este o listă simplă numerotată sau cu marcatori.
formatul său este după cum urmează:
„având în vedere o anumită condiție prealabilă atunci când fac o acțiune, atunci aștept rezultatul”.
exemplu (w.r.,să considerăm că eu sunt pe chat cu un prieten și ar trebui să fie capabil de a captura o imagine.
prin urmare, povestea utilizatorului definește cerința pentru orice funcționalitate sau caracteristică, în timp ce criteriile de acceptare definește „definiția done” pentru povestea utilizatorului sau cerința.,
ca AC, este foarte important să înțelegem profund povestea utilizatorului și criteriile sale de acceptare, fără ca măcar o singură îndoială să rămână la „începutul testării”. Mergând mai departe, să înțelegem de ce este extrem de important să săpăm „adânc” în poveștile utilizatorilor și criteriile de acceptare.pentru început, să înțelegem mai întâi importanța unui studiu „în profunzime” al unui lucru de bază și fundamental, adică povești de utilizator.următoarele cazuri sunt propriile mele experiențe reale.,
caz # 1:
înainte de 3 ani, am fost de lucru pe un proiect de aplicații Mobile și produsul a fost o aplicație care a fost proiectat pentru oamenii de livrare.
ați fi văzut o persoană de livrare venind la locul dvs. pentru livrare. Și au un telefon mobil pe care vă cer să vă dați semnătura după livrare. Această semnătură se reflectă pe portalul furnizorilor de servicii de curierat precum DTDC, FedEx etc.să ne imaginăm că aplicația mobilă este doar lansat și portalurile lor sunt deja existente și în sus.,
problemă: pentru un Sprint, proprietarul produsului dvs. are o poveste de utilizator pentru această aplicație mobilă care „ca administrator de Portal, ar trebui să pot vizualiza semnătura luată de persoana de livrare la momentul livrării”. Aici portalul (aplicația web) este modificat și actualizat în consecință pentru a reflecta semnătura.
în calitate de asigurare a calității, trebuie să verificați dacă semnătura capturată în aplicația mobilă reflectă conform așteptărilor din portal.,dacă te uiți la această poveste de utilizator, pare simplu, dar există o cerință ascunsă aici că ” pentru livrările istorice ,nu a existat nicio funcționalitate de reflecție a semnăturii, deci ce ar trebui să se întâmple dacă băieții portalului văd livrările istorice?”Ar trebui șterse datele istorice? Ar trebui să permitem blocări sau erori pentru astfel de date?desigur ,deloc, acest lucru ar trebui tratat cu grație.,
soluție: când tabelele DB respective sunt actualizate pentru a adăuga o nouă coloană pentru locația semnăturii, datele vechi ar trebui să aibă o valoare nulă sau 0 care ar trebui verificată și ar trebui să fie afișat un mesaj care să ateste „nu există nicio semnătură”.acest lucru poate fi numit ca o lipsă de la proprietarul produsului sau analistul de afaceri, dar acest lucru trebuie făcut. Implementarea cu succes a unei caracteristici, dar ruperea ceva împreună cu aceasta nu este de dorit de către clienți. Acest lucru trebuie făcut împreună cu aceeași poveste de utilizator și în același sprint.,
Cazul # 2
acum 6 ani, lucram la o aplicație de planificare a pensiilor (fără BA), care era o aplicație globală în care oameni de finanțe precum CA, consilierii financiari ar putea să o folosească pentru diferite valute pentru a proiecta planurile de investiții, economii etc., pe o perioadă mare pentru clienții lor.
problemă: Proprietarul Produsului vă oferă o poveste de utilizator care „în calitate de consilier, vreau să vizualizez raportul clientului meu pe baza detaliilor financiare furnizate”.,
Aici s-au 2 ascunse cerințele și aș numi-o ca pe o poveste incompletă pentru că:
o] rapoartele ar trebui să ia în considerare de zi cu zi valută rata de conversie și nu cel istoric ca și în ultima vizualizate raport și
b] Dacă moneda este schimbat după furnizarea clientului detalii financiare, rapoartele ar trebui să arate în a schimbat valută.
soluție: am ridicat această preocupare direct cu proprietarul produsului nostru și l-am conștientizat că ambele trebuie făcute cât mai curând posibil. El a fost de acord cu mine și a creat 2 povești diferite pentru sprinturile viitoare cu prioritate.,
Take Away: acestea au fost surprinse pentru că toți știam foarte bine produsele, designul, structura lor etc. Astfel de cunoștințe pot fi obținute numai prin înțelegerea completă a produsului, prin înțelegerea interoperabilității modulelor și prin studierea amănunțită a poveștii utilizatorului, chiar dacă este o linie 2.faceți notițe pentru a face lucrurile mai ușoare și discutați cu BA și dezvoltatorii despre gândirea lor.,
În Profunzime uita-te la Criteriile de Acceptare
Înțelegerea criteriile de acceptare și toate celelalte condiții& reguli exhaustiv este chiar mai important decât understating o poveste de utilizator. Deoarece dacă o cerință este incompletă sau vagă, ea poate fi preluată în următorul sprint, dar dacă un criteriu de acceptare este ratat, atunci povestea utilizatorului în sine nu poate fi eliberată.cred că toți am fi folosit net banking la un moment dat și majoritatea dintre noi îl folosim în fiecare zi și îmi descarc foarte mult declarațiile istorice., Dacă îl observați cu atenție, există anumite opțiuni specifice disponibile pentru descărcarea acestora.
există o opțiune pentru a selecta tipul de fișier pentru descărcarea declarației dvs. Există o opțiune de a alege dacă doriți să descărcați numai credite/Debit /ambele.acum imaginați-vă că proprietarul produsului vă oferă această poveste de utilizator „în calitate de client, vreau să descarc extrasul de cont pentru a putea vizualiza toate tranzacțiile efectuate pentru o anumită perioadă”.,
cu următoarele criterii de acceptare:
- având în vedere că sunt pe pagina de descărcare a Declarației istorice, ar trebui să selectez perioada pentru care vreau să descarc declarația.
- având în vedere că sunt pe pagina de descărcare a Declarației istorice, ar trebui să selectez contul pentru care vreau să descarc declarația.
- având în vedere că sunt pe pagina de descărcare a Declarației istorice, nu ar trebui să mi se permită să descarc declarația pentru data viitoare „la”.,
- având în vedere că sunt pe pagina de descărcare a Declarației istorice, nu ar trebui să mi se permită să selectez ” din ” data de 10 ani în trecut.
- având în vedere că îmi descarc declarația, ar trebui să pot vizualiza fișierul descărcat.
- având în vedere că sunt pe pagina de descărcare a Declarației istorice, ar trebui să pot descărca declarația mea în formate doc, excel și pdf.
dacă treceți prin această acceptare, lipsesc 3 lucruri aici:
- numele și formatul numelui fișierului care va fi descărcat.,
- ce informații (nume de coloane) trebuie afișate în fișier.
- lista de opțiuni pentru a selecta ce fel de tranzacție dorește clientul, adică numai debite sau numai credite sau ambele.astfel de cazuri se pot întâmpla din când în când, totuși studiați bine despre fiecare criteriu de acceptare și încercați să îl vizualizați cu referire la povestea utilizatorului. Cu cât studiați mai profund despre condițiile și regulile de afaceri, cu atât mai mult vor fi cunoștințele dvs. despre această caracteristică.
bug-urile găsite în stadiul inițial nu costă nimic în comparație cu ceea ce poate costa în stadiul de „testare”.,
importanța de a găsi discrepanțe în poveste de utilizator/criterii de acceptare
este întotdeauna important să se facă o scufundare profundă în povești de utilizator și criteriile de acceptare într-un stadiu incipient, chiar înainte de dezvoltare sau de testare începe.
deoarece implică:
#1) risipa de timp:
dacă discrepanțele sau greșelile din povestea utilizatorului / criteriile de acceptare se găsesc atunci când se desfășoară dezvoltarea sau testarea, atunci este posibil să fie nevoie să se facă o mulțime de reprelucrări în timpul sprint rămas.,
nu se întâmplă că, chiar dacă proprietarul produsului a ratat puține lucruri, ei vor muta povestea utilizatorului la sprintul care vine. 95% șanse sunt ca aceștia să ceară echipei să facă implementarea necesară și să o elibereze în același sprint.prin urmare, devine un coșmar pentru echipă, deoarece trebuie să petreacă timp suplimentar, să vină la sfârșit de săptămână sau să lucreze noaptea târziu. Acest lucru poate fi evitat prin studierea și discutarea criteriilor de poveste/acceptare a utilizatorului cât mai curând posibil.
#2) risipa de eforturi:
dezvoltatorii și QA trebuie să revizuiască Codul implementat și să testeze din nou cazurile., Actualizarea, adăugarea și eliminarea ca cerință per nu este o sarcină ușoară. Devine prea dureros, deoarece există deja o presiune de livrare la timp.într-o astfel de situație, există șanse de greșeli în stadiul de dezvoltare sau testare. Dacă întâlniți o astfel de situație, mergeți la „împerecherea DevQA”. Ca o glazură pe tort, este posibil să nu obțineți o compensație pentru munca suplimentară.
concluzie
înțelegerea profundă a poveștii utilizatorului și a criteriilor de acceptare poate fi realizată numai prin petrecerea unui timp imens pentru studierea acesteia.,nu există niciun instrument sau curs specific disponibil pe piață pentru a face acest lucru pentru dvs., deoarece este vorba despre gândirea logică, experiența și cunoștințele despre produs.participarea activă la întâlnirea Pre-plan, vorbind cu BA, studiind pe cont propriu nu vă poate ajuta decât să realizați acest lucru. Cu cât depuneți mai multe eforturi, cu atât învățați și creșteți mai mult.fie că este vorba de QA sau Dezvoltatori, toată lumea trebuie să fie pe aceeași pagină cu privire la poveștile utilizatorilor și criteriile lor de acceptare, numai atunci așteptările clientului pot fi atinse cu succes.,
aveți ceva nou de împărtășit cu noi despre experiențele dvs. în lucrul cu poveștile utilizatorilor? Vă rugăm să vă exprimați gândurile de mai jos!!
Ultima actualizare: Ianuarie 18, 2021 6: 33 am
Leave a Reply