Share
Poveștile utilizatorilor reprezintă o parte esențială a gestionării echipelor interdisciplinare pe proiecte complexe și pot fi, de asemenea, utile pentru dezvoltatorii soloși care doresc să se asigure că livrează un produs de calitate. Citiți mai departe și aflați cum pot îmbunătăți fluxurile de lucru ale proiectului!
Vezi harta? Proiectele enorme arată la fel. Există multe echipe diferite care lucrează împreună, încercând să livreze un produs minunat. Puteți compara aceste echipe cu diferitele rute de pe hartă. Fiecare echipă are propriile scopuri în minte și numai la anumite puncte de trecere echipele se recuperează între ele. Comunicarea este esențială orice dar și mai important în proiectele mari. Cum comunicați eficient în astfel de proiecte??
Lucrez la o firmă de proiectare și dezvoltare de aplicații din New York City. Deseori, diferite proiecte trec prin birou și nu este întotdeauna clar cum să se realizeze proiecte cu diferiți actori implicați. De aceea, în orice colaborare trebuie să vă puteți înțelege reciproc. Am optat pentru un sistem care este foarte flexibil și scalabil, pentru a aborda atât proiectele mici, cât și cele uriașe. Iată câteva informații despre procesul nostru.
Poveștile utilizatorilor ne unifică echipele atunci când creează un produs. Ele conectează fiecare echipă și îmbunătățesc fluxul de lucru.
Echipele care le echipează sunt o provocare. Desigur, echipele comunică. Dacă se întâmplă acest lucru în mod eficient, este discutabil. A avea un sistem care să îmbunătățească comunicarea, făcând mai ușor să vorbească despre un produs tehnic, îmbunătățește modul în care echipele colaborează. Acestea sunt exact povestile despre utilizatori.
La Fueled credem că suntem capabili să realizăm mai mult printr-un proces agil. Aceasta înseamnă că toate echipele noastre sunt implicate din prima zi când un client dorește să lucreze cu noi. Când aveți echipe diferite implicate cu un proiect din prima zi, vor exista conflicte și neînțelegeri privind așteptările și rezultatele dorite ale unui proiect. La urma urmei, cum să planificați cu succes anumite limitări tehnice unui designer sau să explicați unui dezvoltator cum va funcționa un machet? Persoanele cu medii diferite din industrie au adesea așteptări diferite. Pentru persoanele care lucrează împreună pentru totdeauna, este mult mai ușor să știm ce se așteaptă de la celălalt, dar pentru întreprinderi noi sau noi este adesea mai dificil de comunicat eficient la începutul unui proiect.
Cu toții știm că, în medii multidisciplinare, colaborarea nu este întotdeauna ușoară. Aici intră în joc poveștile utilizatorilor. Conceptul din spatele utilizatorilor este simplu. Ce se întâmplă dacă folosim limbajul nostru comun, scris în limba engleză, pentru a conecta echipele și pentru a realiza realizarea unui produs? Povestirile utilizatorilor sunt gândurile scrise ale utilizatorului. Acesta ar putea fi un exemplu de poveste a unui utilizator:
Poveștile utilizatorilor sunt întotdeauna scrise din perspectiva utilizatorului.
Însoțite de povestirile utilizatorilor sunt criterii de acceptare. Acestea sunt în esență o listă de cerințe care permit povestea utilizatorului să se întâmple. Iată criteriile de acceptare pentru povestea precedentă a utilizatorului:
Pe lângă criteriile de acceptare, povestile utilizatorilor sunt, de obicei, însoțite de o rețea wireframe, o prioritate și starea actuală. Iată câteva exemple de posibile criterii de acceptare care pot fi găsite însoțind o poveste a utilizatorului:
Poveștile utilizatorilor și criteriile de acceptare însoțitoare sunt scurte și detaliate informații care sunt capabile să explice funcționalitatea unei anumite caracteristici dintr-o aplicație. În același timp, atât designerii cât și dezvoltatorii înțeleg ce se așteaptă de la ei. Hai să folosim exemplul povestei utilizatorilor de pe butonul din spate: odată ce designerii au văzut schema și au citit criteriile de acceptare, ei știu că trebuie să proiecteze două stări ale butonului, iar dezvoltatorii știu ce fel de funcționalitate specifică trebuie să le pună în aplicare.
Aș dori să precizez diferența dintre povestirile utilizatorilor și criteriile de acceptare. Poveștile utilizatorilor sunt întotdeauna scrise din perspectiva utilizatorului. Criteriile de acceptare există pentru a clarifica poveștile utilizatorilor: ceea ce este necesar pentru a face o poveste a utilizatorului să funcționeze?
Ca designer sau dezvoltator individual, este posibil să fiți tentați să credeți că acest lucru nu este relevant pentru dvs. Știți deja tot ce trebuie să facă aplicația dvs., nu? Din păcate, este puțin probabil să fie adevărat. Criteriile de acceptare sunt încă extrem de utile pentru asigurarea calității și identificarea problemelor în cadrul propriului cod sau design.
Poveștile utilizatorilor sunt, de asemenea, un instrument util pentru gestionarea proiectelor în general. Puteți să urmăriți diferite povestiri ale utilizatorilor și să raportați erori sau probleme. La urma urmei, povestile utilizatorilor enumeră în mod specific așteptările privind funcționalitatea aplicației pe care lucrați.
În cele din urmă, în timp ce este posibil să nu lucrați cu un alt membru al echipei astăzi, ce se întâmplă dacă se va schimba mâine? V-ați putea extinde povestile astfel încât să puteți oferi instrucțiuni de proiectare sau dezvoltare pentru a oferi mai multe îndrumări colaboratorilor.
Desigur, există o mulțime de software acolo care face gestionarea povestilor utilizatorilor un proces simplu și accesibil. De exemplu, există Mingle, Pivotal Tracker, ScrumDo și multe altele. Pentru proiectele noastre, preferăm să folosim Jira.
Captură de ecran a lui Jira Nu sunteți dependent de software-ul cum ar fi Jira să folosească conceptul de povestiri ale utilizatorilor în timp ce creează o aplicație. Puteți să vă lipiți de uneltele gratuite sau să creați propriul mod de a urmări poveștile utilizatorilor.
De obicei, există o persoană care gestionează proiectul. Adesea, etichetăm acei oameni ca manageri de proiect deoarece au o imagine generală a proiectului. Proiectanții și dezvoltatorii nu sunt obligați să se gândească în mod constant la domeniul mai larg, putând să se concentreze exclusiv asupra realizării povestirilor utilizatorilor. Când este folosit corect, acesta este un sistem care funcționează destul de bine. O persoană se concentrează pe imaginea mai mare, oferă povestiri despre utilizatori și se gândește la ce ar trebui să arate produsul și cum ar trebui să funcționeze produsul. În același timp, acești oameni se asigură că așteptările clienților sunt îndeplinite în timp ce îi conduc echipa. Este o modalitate de a asigura o calitate eficientă.
Acest lucru îi permite proiectanților și dezvoltatorilor să se concentreze asupra unor funcționalități și probleme specifice, fără a ne îngrijora în mod constant imaginea mai largă. Poveștile utilizatorilor și criteriile de acceptare fac acest lucru fezabil și este ușor să urmăriți progresul produsului final.
Unelte precum Jira includ funcționalități integrate pentru urmărirea acestui proces. Aveți libertatea de a lucra în mod flexibil cu sistemul. Puteți conecta anumite probleme sau erori cu anumite povestiri ale utilizatorilor. Dacă nu sunteți mulțumit de un anumit aspect al designului, vă puteți referi la povestea respectivă a utilizatorului. Aici, la birou, ne place să lucrăm cu "epice". Un epic este în esență un grup de povestiri despre utilizatori. De exemplu, anumite aplicații au un episod pentru fiecare ecran. În acest fel, puteți grupa funcționalitățile unui ecran într-un singur grup, oferindu-vă o imagine mai bună a cât de repede este finalizat proiectul dvs. sau ce grup de povesti de utilizator este responsabil pentru majoritatea bug-urilor. În plus, designerii și dezvoltatorii pot să-și aloce resursele între diferitele povestiri ale utilizatorilor, oferind mai multe informații despre timpul sau complexitatea funcționalității implicate. De asemenea, este posibil să planificați anumite povestiri ale utilizatorilor sau epopee într-un calendar și să micromanageți progresul unui proiect.
În cele din urmă, succesul de a lucra cu povestirile utilizatorilor în propriul proiect este probabil să depindă de flexibilitatea sistemului pe care l-ați implementat și de libertatea pe care sistemul o oferă pentru a lucra în cadrul acestuia, fie ca persoană fizică, fie ca o echipă. Un sistem bun de povestire a utilizatorilor ar trebui să vă permită, de asemenea, să păstrați o imagine de ansamblu a proiectului în ansamblu în viziunea periferică, chiar dacă vă concentrați asupra anumitor sarcini sau caracteristici.
Sperăm că acest articol oferă o perspectivă asupra modului în care abordăm proiectele mari și asigurăm calitatea produselor pe care le creăm. Poveștile utilizatorilor vă asigură că gândiți prin funcționalitatea aplicației dvs. și păstrați în minte dorințele clientului. Poveștile utilizatorilor sunt excelente pentru produs, pentru client și pentru echipa dvs.!
Accentsconagua