Una dintre cele mai mari provocări în dezvoltarea de software este aproape imposibilă, de a aduna cerințe clare și apoi obtinerea acestor cerințe să rămână neschimbate în timpul de dezvoltare cod. În abordarea cascadă a dezvoltării de software—în ciuda eforturilor de a defini, documenta și aproba orice situație de urgență posibilă înainte de începerea dezvoltării—produsul livrat este rareori ceea ce dorește clientul.
alternativa agilă? Crearea poveste utilizator.,unul dintre cele mai mari avantaje ale utilizării unei abordări agile a dezvoltării de software este că cerințele nu sunt stabilite în piatră, ci se așteaptă să se schimbe, cu feedback constant din partea părților interesate și a afacerii. Metodologii Agile, cum ar fi Scrum și extreme programming (XP) a înlocui tradiționale, de lungă durată cerințe documente cu o prioritate product backlog-ul format din concis povești de utilizator, detaliile care apar aproape de când povestea este gata pentru a fi puse în aplicare.,
deși crearea de povești de utilizator este mai mult artă decât știință, acest tutorial vă va oferi informațiile, exemplele și pașii de care veți avea nevoie pentru a crea povești de utilizator de înaltă calitate.
istoria poveștilor utilizatorilor
XP a introdus pentru prima dată conceptul de povești ale utilizatorilor în 1998, comparându-le cu cazurile de utilizare. În ingineria software orientată pe obiecte: o abordare bazată pe cazuri de Utilizare, Ivar Jacobson a introdus cazurile de utilizare ca o modalitate de a documenta cerințele prin definirea interacțiunilor dintre un rol (o persoană care utilizează sistemul) și sistemul însuși pentru a atinge un obiectiv folosind limbajul de modelare unificat (UML).,această abordare a fost populară în dezvoltarea orientată pe obiecte și este încă folosită ca un proces cheie în cadrele de dezvoltare software, cum ar fi procesul unificat (UP), IBM Rational Unified Process (RUP) și Oracle Unified Method (OUM). Utilizarea cazurilor de utilizare, mai degrabă decât a poveștilor utilizatorilor, permite dezvoltarea iterativă și incrementală și este considerată o abordare agilă a definirii cerințelor.,odată cu introducerea poveștilor de utilizator mult mai scurte și a popularității XP și Scrum, o listă de produse formată din povești de utilizator a devenit abordarea mai cunoscută a definiției cerințelor agile. Mulți practicanți încă mai cred că poveștile utilizatorilor sunt singura abordare agilă acceptabilă. Cu toate acestea, Alistair Cockburn, unul dintre semnatarii Manifestului Agile, preferă cazurile de utilizare pentru poveștile utilizatorilor.deși există o mulțime de opinii puternice despre semnificația „agile”, atât cazurile de utilizare, cât și poveștile utilizatorilor sunt compatibile cu această abordare., Unii spun că poveștile utilizatorilor devin în cele din urmă similare cu cazurile de utilizare odată ce echipa este de acord cu detaliile implementării. În primele etape, povestea utilizatorului este pur și simplu o propoziție scurtă, dar nu este completă până când nu sunt definite detaliile și criteriile de acceptare.
crearea poveștilor utilizatorilor
există opinii diferite cu privire la definirea unei povești de utilizator și la modul cel mai bun de a crea una., Unele linii directoare pentru o bună poveste de utilizator includ următoarele:
- ar trebui să fie scris de cineva care reprezintă utilizatorii de afaceri (de obicei proprietarul produsului)
- Acesta ar trebui să includă inițial scurte descrieri ale „cine, ce, și de ce,”dar nu „cum”
- ar trebui să producă o felie vertical de cod de lucru
- ar trebui să fie suficient de mică încât poate fi codificate și testat într-o singură iterație (de obicei o perioadă de patru săptămâni)
Diferite modele, tehnici, și acronime sunt folosite pentru a ajuta proprietarii de produs scrie povești de utilizator., Trei dintre cele mai comune tehnici sunt șablonul rol-caracteristică-motiv, cele trei C (card, conversație, confirmare) și investesc (independent, negociabil, valoros, estimabil, mic, testabil).
Exemple
spuneți că dezvoltați o aplicație care ar permite formatorilor să încarce cursuri și să atragă studenții care sunt interesați să ia o clasă. Iată cum ați aplica tehnicile de poveste ale utilizatorilor., după cum explică Mike Cohn de la Mountain Goat Software, șablonul rol-caracteristică-motiv sau RGB (rol, obiectiv, beneficiu) arată ceva de genul:
„ca vreau așa .deși există variații, această structură scurtă a propoziției păstrează accentul pe cine, ce și de ce. Acest lucru împiedică proprietarul produsului să ofere echipei de dezvoltare prea multe informații despre modul în care ar trebui să implementeze o soluție. Concentrându-se pe cine, ce și de ce, echipa de dezvoltare este împuternicită să găsească cea mai bună soluție tehnică.,exemplul 1: oferiți unui trainer posibilitatea de a adăuga un curs
ca trainer, aș dori să pot adăuga un curs nou, astfel încât să am potențialul de a atrage noi studenți.
Exemplul 2: oferiți unui student posibilitatea de a căuta un curs
ca student, aș dori să pot căuta ofertele cursului, astfel încât să pot găsi o ofertă care mă interesează cel mai mult.
rolul (OMS)
rolul descrie cine va beneficia de această funcție. Observați că rolul nu este pur și simplu ” utilizatorul.,”Există diferite tipuri de utilizatori și, prin urmare, dorim ca rolul să fie mai specific decât „utilizator”, dar să descriem tipul de utilizator care va beneficia de poveste. Proprietarii de produse sunt adesea însărcinați să intre în mintea utilizatorilor lor pentru a înțelege ce ar fi cel mai valoros pentru ei.
Exemplul 1 rol = trainer
Exemplul 2 rol = student
caracteristica (ce)
acest pas descrie foarte pe scurt ceea ce vrea utilizatorul. Aceasta reprezintă cel mai îndeaproape cerința pe care o descrieți în dezvoltarea software-ului tradițional., Cu toate acestea, doriți să aveți grijă să nu fiți prea specifici sau să descrieți cum să scrieți codul. Acest lucru va fi determinat în cele din urmă, dar nu atunci când creați pentru prima dată povestea utilizatorului. Povestea utilizatorului ar trebui să fie scrisă din perspectiva utilizatorului care va beneficia de funcție, nu din perspectiva dezvoltatorului care o va codifica.
Exemplul 1 Feature = adăugați un nou curs
Exemplul 2 Feature = căutați ofertele de curs
motivul (de ce)
În cele din urmă, dorim să precizăm de ce utilizatorul dorește această caracteristică. Ce valoare va primi utilizatorul de la acesta?, Acest lucru ajută proprietarul produsului să evalueze modul de prioritizare a poveștii utilizatorului pe lista de întârziere. Dacă valoarea sau beneficiul nu pot fi articulate, ar putea fi ceva care nu este necesar. Înțelegerea valorii ajută adesea echipa de dezvoltare să găsească modalități inovatoare de implementare a codului pentru a rezolva obiectivele—modalități care pot fi diferite de ceea ce are în minte proprietarul produsului.,
Exemplu 1 Motiv = atragerea de noi studenți
Exemplu 2 Motiv = a găsi o ofertă care interesează cel mai mult mă
Cei Trei „C”: Card, Conversatie, Confirmarea
Cele Trei C formula, dezvoltat de Ron Jeffries, ajută pentru a ajunge la un acord între afaceri și echipa tehnică, pe sensul de poveste de utilizator. Cei trei C îi ghidează prin elaborarea progresivă a unei povești, de la o scurtă declarație la o poveste de utilizator complet dezvoltată.,
carte
povestea utilizatorului începe în mod intenționat scurt, cu o declarație simplă care s-ar putea încadra pe un card de index 3×5, urmând de obicei formatul rol-caracteristică-beneficiu pe care tocmai l-am acoperit. De exemplu:
ca formator, aș dori să pot adăuga un nou curs, astfel încât să am potențialul de a atrage noi studenți.deși povestea utilizatorului începe ca o simplă declarație, detaliile trebuie să apară înainte ca echipa să înceapă să lucreze la poveste., În loc să descrie ceea ce este necesar în documentație, echipa va include 1) reprezentare din partea afacerii (de obicei proprietarul produsului) și 2) echipa de dezvoltare în sine, inclusiv dezvoltatori, testeri, analiști de afaceri sau oricine altcineva din echipă.această conversație permite echipei de dezvoltare să pună întrebări pentru a se asigura că au o înțelegere clară a ceea ce se cere și a valorii furnizate. De exemplu:
dezvoltator: va trebui trainerul să încarce programele de curs pe un site web?,proprietarul produsului: nu, formatorul va adăuga doar informații despre cursul care va fi oferit, iar funcția ar trebui să includă o modalitate prin care elevul să intre pe o listă de interese. Această poveste oferă formatorului posibilitatea de a face publicitate unui curs.
Dezvoltator: ce domenii ar trebui să fie incluse?proprietarul produsului: Titlul cursului, rezumatul, datele și orele, locația.
dezvoltator: va fi doar pentru clasele de publicitate față în față?
proprietar produs: da., Putem adăuga o opțiune de clasă virtuală mai târziu, dar această poveste va acoperi doar adăugarea de informații despre curs pentru ofertele de clasă față în față.
Dezvoltator: ce informații ar trebui colectate atunci când un potențial student cere să intre pe o listă de interese?
proprietarul produsului: numele, numărul de telefon și adresa de e-mail.
echipa va actualiza povestea utilizatorului cu informațiile pe care le—a adunat din conversație și va discuta despre implementare—sau „cum” – care creează adesea sarcini specifice care trebuie făcute pentru a finaliza povestea., Deși povestea utilizatorului este scrisă din perspectiva utilizatorului, echipa de dezvoltare scrie sarcinile pentru dezvoltatori și include detaliile de implementare tehnică.echipa de dezvoltare trebuie să aibă o înțelegere clară a modului în care funcția va funcționa în diferite situații, inclusiv în condiții de eroare. Ei trebuie să obțină confirmarea criteriilor de acceptare de la proprietarul produsului. Acestea sunt criteriile care trebuie îndeplinite pentru ca povestea să fie considerată făcută și acceptată., Iată un exemplu de criterii de acceptare:
- un instructor este capabil să adauge un nou curs introducând titlul cursului, rezumatul, datele și orele și locația într-un formular și apăsați un buton „Adăugați curs”.
- dacă lipsesc câmpuri sau datele sau orele sunt nevalide, vor apărea mesaje de eroare.
- odată ce cursul a fost adăugat în mod corespunzător, acesta va fi afișat public pe site-ul cursului și va exista un buton pentru ca un student să-și exprime interesul.,
- butonul de interes va permite unui utilizator să introducă numele, adresa de e-mail și numărul de telefon, iar aceste date vor fi stocate și asociate cu noul curs.
INVEST: atributele unei povești de utilizator solide
INVEST este un acronim care vă ajută să evaluați dacă aveți o poveste de utilizator de înaltă calitate. Iată cum se aplică atributele din acronim poveștii la care am lucrat. I = Independent-poate această poveste să fie completată de echipă? Vrem ca echipa să poată completa întreaga poveste, mai degrabă decât să depindă de o altă echipă pentru a face GUI, de exemplu.,
N = negociabil-povestea nu este atât de detaliată încât să descrie exact cât timp ar trebui să fie câmpurile sau să ofere detalii despre formatele de dată și altele asemenea. Cel mai probabil vor exista rutine sau biblioteci comune care vor permite echipei de dezvoltare să implementeze în modul în care are cel mai mult sens pentru ei.V = Valuable – proprietarul produsului descrie că valoarea căutată este capacitatea formatorului de a putea face publicitate cursurilor viitoare. Acest lucru este clar în „De ce” din declarația inițială și re-subliniat în conversație.,e = Estimable – echipa va pune suficiente întrebări și va aduna detaliile pentru a se simți încrezători în capacitatea lor de a estima povestea.
S = Small-echipa trebuie să se simtă încrezătoare că va fi capabilă să finalizeze povestea într-un sprint. Dacă nu, s-ar putea împărți povestea. De exemplu, în povestea noastră de probă, ei pot decide să facă abilitatea de a aduna informațiile elevilor să fie o poveste diferită și să afișeze pur și simplu informații despre clasă pentru această poveste.
T = testabil—cu criterii clare de acceptare, pot fi testate atât calea fericită, cât și condițiile de eroare.,
alinierea la o viziune
am acoperit elementele de bază ale creării unei povești de utilizator, dar trebuie să înțelegeți imaginea de ansamblu înainte de a crea propriile povești de utilizator. Există multă muncă pe care trebuie să o faceți în față, la un nivel superior, pentru a determina care sunt caracteristicile cu cea mai mare valoare care ar trebui livrate clienților. Acestea sunt în cele din urmă descompuse în povești de utilizator.
este important ca echipa să înțeleagă mai întâi viziunea la nivel înalt și să se asigure că caracteristicile și, în cele din urmă, poveștile utilizatorilor se aliniază la acea viziune la nivel înalt.,
De obicei, împărțiți produsul în grupări care au nume precum” teme „sau ” caracteristici”.”Deși etichetarea acestor elemente restante poate diferi în funcție de metoda și instrumentele agile pe care le utilizați pentru a le descrie, ideea este să vă asigurați că se aliniază astfel încât munca să poată fi urmărită până la viziunea dvs., ceea ce vă va asigura că îndepliniți obiectivele și valorile viziunii produsului.
Din nou, nu începe un proiect prin crearea poveștilor utilizatorilor; începe prin crearea unei viziuni., Pentru exemplul nostru, arăt pur și simplu o declarație de viziune a eșantionului, ceea ce duce la unele caracteristici ale eșantionului, care pot fi descompuse în continuare în povești ale utilizatorilor.
Vision
oferă un site web de înaltă calitate, care va permite formatorilor să facă publicitate cursurilor și să permită studenților să urmeze aceste cursuri.
caracteristici
- oferiți o pagină de ofertă de cursuri care va permite studenților să se înscrie la cursuri.
- oferiți o pagină de pornire care va spune utilizatorilor despre ce este vorba site-ul nostru.
- oferă un proces de înregistrare care permite utilizatorilor să se conecteze, să creeze un profil și să țină evidența claselor lor.,
- oferiți un blog care vă va ajuta să faceți publicitate ofertelor noastre și să obțineți publicitate pentru site-ul nostru web.
povești de utilizator
- oferă formatorului posibilitatea de a adăuga un curs pe pagina ofertei de curs.
- oferiți studenților posibilitatea de a căuta un curs.în exemplul de mai sus, puteți vedea cum au apărut poveștile utilizatorilor. Poveștile utilizatorilor au făcut parte dintr-o caracteristică de „a oferi o pagină de ofertă de curs” care se aliniază viziunii la nivel înalt.,
Impact mapping
deși alinierea la o viziune vă va ajuta să populați întârzierea inițială, nu este singura modalitate de a face acest lucru. Există numeroase instrumente și tehnici pe care managerii de produse le pot utiliza pentru a crea poveștile care intră într-un nou jurnal și care se aliniază cu viziunea.o tehnică de planificare strategică folosită pentru a ajuta la înțelegerea imaginii de ansamblu, impact mapping, a fost popularizată de Gojko Adzic, autorul a cincizeci de idei rapide pentru a îmbunătăți poveștile utilizatorilor și cartografierea impactului: realizarea unui impact mare cu produsele și proiectele software., Impact mapping este o hartă a minții care începe cu obiectivul, care ar trebui să abordeze problema valorii și de ce construiți produsul.
următorul nivel listează „actorii” sau persoanele care vor ajuta la atingerea obiectivului. Apoi, harta listează comportamentele sau” impacturile ” pe care actorii le vor efectua pentru a ajuta la atingerea acestui obiectiv. Nivelul final al hărții prezintă „livrabilele” pe care echipa le poate implementa. Acestea permit și sprijină actorii să creeze impactul dorit. Din aceste livrabile derivă caracteristicile și poveștile software-ului.,
- Scop: de a Face disponibile pe scară largă de cursuri care elevii vor dori să ia
- Actori: Formatori, studenți
- Efecte: Formatorii vor oferi de înaltă calitate clase care sunt de interes pentru elevi; elevii vor oferi recomandări și recomandări
- Livrabile: de Înaltă calitate, clase care sunt accesibile pentru studenți
- Potențial de povești:
- „Ca antrenor, nu vreau sa fac reclama clase, astfel încât să pot obține elevii.
- ” în calitate de antrenor, vreau să primesc feedback de la studenți, astfel încât să mă pot îmbunătăți continuu.,”
- ” în calitate de trainer, vreau să aflu ce își doresc elevii, astfel încât să pot adăuga la curriculum-ul meu.”
- ” ca student, vreau să găsesc clase care mă interesează cel mai mult.”
- ” ca student, vreau să găsesc cursuri pe care să le pot lua online, astfel încât să nu fie nevoie să călătoresc.”
- ” ca student, vreau să citesc recenzii de la alții, astfel încât să pot decide ce clase mi se potrivesc cel mai bine.maparea poveștilor utilizatorilor în acest mod permite trasabilitatea în procesul de gândire a modului în care poveștile creează în cele din urmă valoare și a modului în care le folosiți pentru a atinge obiectivul final., Ideea nu este să implementați totul, ci să găsiți cea mai scurtă cale prin hartă pentru a vă atinge obiectivul.una dintre cele mai frecvente probleme cu care se confruntă echipele agile este atunci când poveștile sunt prea mari și nu pot fi completate într-o iterație. Când echipa creează sarcinile asociate cu povestea, își dau seama că există prea multe necunoscute sau că sarcinile implicate vor dura mai mult timp decât echipa are la dispoziție într-o singură iterație. Echipele abordează uneori acest lucru împărțind o poveste mai mare în povești mai mici.,amintiți-vă, totuși, că doriți ca o poveste de utilizator să livreze software de lucru care să adauge valoare pentru utilizator. În loc să creeze o poveste de utilizator care va completa doar parțial o funcție, împărțiți poveștile în „felii verticale” care vor oferi funcționalitate end-to-end.
apelați la comunitate pentru o învățare mai profundă
soluțiile detaliate privind modul de rezolvare a celor mai dificile probleme legate de cerințe și poveștile utilizatorilor sunt unice pentru fiecare situație. Cu toate acestea, o trăsătură comună a practicanților agili de succes este aceea că sunt dornici să-i ajute pe ceilalți și să împărtășească ceea ce știu.,site-ul userStories Cohn permite celor care lucrează cu backlog-uri de produse și povești de utilizator pentru a partaja produse, resurse, și cunoștințe. Pagina de produse include o listă impresionantă de instrumente, multe disponibile gratuit, cu oportunități pentru recenzii și contribuții ale utilizatorilor. Cohn notează pe site că speră să extindă site-ul, astfel încât întârzierile produsului să poată fi partajate.
nu va exista niciodată un răspuns unic pentru a scrie povești perfecte pentru utilizatori., Cu toate acestea, în timp, cu o combinație sănătoasă de experiență, sfaturi de la experți și experimentare cu instrumente și tehnici sugerate, vă puteți îmbunătăți continuu.