poveștile utilizatorilor sunt construcții simple, dar extrem de puternice: descriu bucăți de funcționalitate din punctul de vedere al utilizatorului, exprimate într-un mod solid și compact. Acestea reflectă ceea ce are nevoie o anumită clasă de utilizatori și valoarea care trebuie câștigată. Formatul este foarte simplu și ușor de utilizat. Există mai multe variante, inclusiv:
De ce povești de utilizator?poveștile utilizatorilor oferă o modalitate excelentă de a vă defini produsul cu claritate., Un set de povești de utilizator bine definite, prioritizate, vă poate ajuta să articulați funcționalitatea produsului dvs. folosind „limba engleză simplă” — fără detalii tehnice și de implementare.
abordarea „user story” permite discuții semnificative despre produse, atât în cadrul echipei de dezvoltare a produsului, cât și cu părțile interesate externe.povestirile scrise corect de utilizatori oferă o bază solidă pentru comunicare și colaborare — concentrându-se pe ceea ce contează cel mai mult pentru utilizator., În comparație cu alte mijloace de captare și Documentare a cerințelor utilizatorilor și a specificațiilor produsului, acestea au cel puțin următoarele avantaje:
- poveștile utilizatorilor ajută la obținerea clarității între echipe cu privire la ce să construiască, pentru cine, de ce și când. Deoarece sunt ușor de definit, înțeles și revizuit, ele pot deveni modalitatea standard de a comunica și de a rezuma funcționalitatea produsului atât de către membrii tehnici, cât și de cei non-tehnici. Ele sunt extrem de utile pentru discuții despre domeniul de aplicare al produsului sau ca puncte de intrare pentru scufundări tehnice profunde. Ele sunt elemente cheie ale ingineriei agile.,
- poveștile utilizatorilor încurajează participarea membrilor non-tehnici. Proiectele software moderne sunt de obicei complexe, implicând o gamă largă de tehnologii, acronime și opțiuni de implementare. În multe cazuri, terminologia sau limbajul tehnic nu sunt înțelese în mod obișnuit — chiar și în cadrul unei singure echipe — introducând astfel „zgomot” și riscuri pentru proiect. Poveștile utilizatorilor elimină această dimensiune tehnică, astfel încât orice membru al echipei poate contribui, pur și simplu gândindu-se „ca utilizator”., Echipa poate folosi un limbaj non-tehnic și poate colabora eficient la definirea, provocarea sau prioritizarea poveștilor utilizatorilor. Impactul asupra colaborării și dinamicii echipei poate fi semnificativ.
- ele ajută la definirea întregului produs — ca un set de povești solide, cu înțelepciune prioritizate. Echipa de dezvoltare a produsului poate gândi mare, poate defini super – setul de povești ale utilizatorilor și apoi poate atribui priorități (care reflectă valoarea așteptată pentru utilizator, complexitatea, dependențele și alte priorități de afaceri). Nu trebuie să luați decizii grele și să semnalizați elementele ca fiind „în afara domeniului de aplicare”., În schimb, puteți atribui o prioritate mai mică acelor idei „nebune”, în timp ce vă deplasați în sus poveștile utilizatorilor care reflectă funcționalitatea de bază a produsului dvs. Definirea „liniilor tăiate” care determină domeniul de aplicare pentru fiecare iterație, fază sau versiune, este apoi o chestiune de resurse disponibile și viteza echipei.
scrierea poveștilor excelente ale utilizatorilor
formatul este simplu, iar scrierea poveștilor este ușoară. Dar scris cele mari ar putea fi un pic dificil. Iată câteva reguli de luat în considerare:
povești utilizator ≠ SARCINI
poveștile utilizatorilor nu sunt SARCINI., De fapt, o singură poveste poate avea nevoie de sute de sarcini unice pentru a fi livrate cu succes. Sarcinile se referă la implementare; poveștile utilizatorilor se referă la definiție.
când compilați poveștile, concentrați — vă pe furnizarea de claritate cu privire la caracteristicile produsului dvs.-ce, nu cum.
rămâi la nivel înalt
trebuie să fii la nivel înalt, dar și precis și la punct. Poveștile trebuie să fie simple și solide. Acest lucru va ajuta membrii echipei și părțile interesate să înțeleagă profund nevoile utilizatorilor și să evite petrecerea timpului clarificând cuvintele cheie, terminologia și acronimele. Trebuie doar să folosiți un limbaj simplu și precis.,trebuie să descoperiți și să studiați utilizatorii reali ai produsului dvs. — capturați profilurile, punctele de vedere, așteptările și punctele de durere asociate.”Cercetarea utilizatorilor și alte tehnici pot genera informații pentru a vă ajuta să înțelegeți mai bine utilizatorii și nevoile lor.indiferent de tehnici, aveți nevoie de setul de utilizatori cheie — în mod ideal sub formă de personas — înainte de a începe compilarea poveștilor utilizatorilor.,
Cred ca un utilizator
<ca o anumită clasă de utilizator/ persona /rol> parte de o poveste de utilizator, definește unghiul, perspectiva — cum utilizatorului special percepe funcționalitatea cuprinse în poveste.acest lucru este de o importanță critică — proprietarul produsului și întreaga echipă trebuie să gândească din punctul de vedere al utilizatorului și să înțeleagă nevoile de bază și valoarea așteptată.,când descrieți un produs ca o întârziere a poveștilor utilizatorilor, nu există niciun motiv bun pentru a vă constrânge gândirea în funcție de buget, timp, fezabilitate sau cost.
o bună practică este să gândești mare și să lași poveștile „nebune” ale utilizatorilor să intre în întârziere. Cheltuielile administrative pentru menținerea unei întârzieri extinse a produselor sunt mici; valoarea care derivă din aceasta — în ceea ce privește claritatea, viziunea și oportunitățile produsului — este masivă.,epicele pot lua forma unor povești de nivel superior, care descriu bucăți mari de funcționalitate-de obicei necesită o cantitate semnificativă de muncă, pe mai multe sprinturi. Un alt mod de a gândi epopee este ca grupări/ Containere de povești conexe, mai mici, toate servind un scop comun. Epopeele sunt bune pentru organizarea poveștilor tale și pentru a oferi imaginea de ansamblu.,
nu aruncați — prioritate în loc
Având un eficient proces de prioritizare, este o bună practică pentru a menține îmbogățirea product backlog cu noi povești de utilizator, descriind noi de interacțiune cu utilizatorul scenarii, ‘idei aleatorii, sau producția de produs inovare.pentru a gestiona zgomotul potențial, trebuie să grupați și să acordați prioritate noilor intrări. În orice caz, nu filtrați/aruncați articolele din lista dvs. de așteptare: articolele de-scoped sunt de obicei uitate, în timp ce articolele de-prioritizate rămân descoperite și pot deveni relevante în condițiile potrivite.,
în funcție de context, prioritizarea poveștilor utilizatorilor poate fi un proces dificil. Trebuie să estimați valoarea fiecărei povești, pentru utilizator și pentru afacere. Trebuie să dimensionați complexitatea, să estimați fezabilitatea și costul / efortul necesar pentru a construi și elibera funcția. Trebuie să identificați dependențele încrucișate în lista dvs. de așteptare-impunând o comandă specifică între anumite intrări.
configurare pentru succes — nu doar acceptare
echipele definesc adesea testele de acceptare ale utilizatorilor și criteriile de acceptare aferente. Acceptarea, deși nu este suficientă-trebuie să vă configurați pentru succes., Ca manager de produs, aveți nevoie de mai mult decât o confirmare că „funcționează așa cum ar trebui” sau ” conform specificațiilor.’
aveți nevoie de valori care sunt, de asemenea, legate de feedback-ul direct al utilizatorilor, capturând cât de fericiți și implicați sunt utilizatorii dvs. reali. În timp ce acceptarea este bună pentru a controla ciclul de viață al dezvoltării caracteristicii, succesul se referă la impactul pe termen mediu/lung și la valoarea creată pentru utilizatorii reali ai produsului dvs. Trebuie să definiți ambele-la nivel de produs și/sau epic și/sau poveste.
etichetați poveștile, adăugați metadate
produsele complexe necesită sute de povești ale utilizatorilor., Pentru o navigare și o administrare mai ușoară, trebuie să denumiți, să clasificați și să etichetați în mod eficient poveștile. După primele câteva revizuiri ale unei povești, ar trebui să evitați redenumirea sau schimbarea drastică a descrierii, deoarece acest lucru ar putea introduce confuzie și lacune în echipă.
gestionarea corectă a metadatelor poveștilor dvs.—stare, progres, link-uri, priorități, resurse etc. – ajută la explorarea, monitorizarea și înțelegerea restanțelor.
nu se lipesc de note lipicioase!,
da, un perete plin de note lipicioase colorate arata fantezist si ajuta echipa ta sa para ocupata si productiva:) dar ai nevoie de un sistem serios si instrumente speciale care sa te ajute sa gestionezi, sa imbogatesti, sa prioritizezi si sa impartasesti povesti.,
În cazuri speciale, cum ar fi un brainstorming sau suicidare sesiune, este bine pentru a captura primul set de povești de utilizator prin utilizarea sticky note—cu condiția ca atunci document toate dintre ele într-un corespunzatoare produsului sistem de management. Dacă nu, și vă păstrați doar poveștile pe note lipicioase, sunt șanse să pierdeți oportunități în ceea ce privește claritatea, inovația, eficiența și colaborarea.,
încă mai aveți nevoie de specificații
având un set prioritizat de povești de utilizator bine definite este grozav, dar este doar începutul. Echipa trebuie să analizeze poveștile — din punct de vedere tehnic — și să creeze artefactele tehnice necesare.în mod ideal, poveștile sunt mapate la o documentație specifică care oferă toate detaliile tehnice necesare dintr-o perspectivă de inginerie software. Acestea oferă punctele de intrare pentru documente detaliate de specificație tehnică și alte artefacte detaliate.,
vizualizarea ajută
o vizualizare permanentă (digitală) a poveștilor utilizatorilor cu prioritate maximă pe categorii, teme sau epice ar putea fi extrem de utilă pentru colaborarea și alinierea între echipe și părțile interesate. Împreună cu statistici, probleme, blocante și indicatori de progres, o hartă a poveștii poate fi difuzată prin ecrane interactive în spațiul de colaborare.povestirile utilizatorilor oferă o modalitate excelentă de a descrie rapid și precis funcționalitatea unui produs sau sistem software., Ele sunt, de asemenea, foarte eficiente în captarea rezultatelor sesiunilor de brainstorming, sprinturi de design, hackathoane și alte procese conduse de inovație-unde un flux de idei trebuie capturat într — un mod compact, structurat.