Proprietarul produsului este un fel de legătură între client și echipa de dezvoltare. Autoritatea finală de luare a deciziilor în echipa Scrum este doar proprietarul de produse
Cea mai importantă responsabilitate a proprietarului de produse este crearea și controlul Produsului de backlog
Principalele îndatoriri și responsabilități ale Proprietarului de Produse în gestionarea Produsului Backlog:
- Definiția backlog elements;
- Aranjarea corectă a elementelor pentru optimizarea realizării scopului;
- Asigurarea clarității și a transparenței Încărcarea produsului;
- Asigurarea transparenței și clarității cerințelor, asupra cărora va funcționa întreaga echipă Scrum;
- Optimizarea generală pentru a obține cea mai mare valoare a activității echipei de dezvoltare;
- Responsabilitatea pentru înțelegerea restanțelor de către echipa de dezvoltare.
Este demn de remarcat faptul că Proprietarul de Produs poate efectua el însuși toate sarcinile de mai sus și le poate da echipei de Dezvoltare, dar rămâne mereu responsabil.
Soluții Proprietarul de produse pentru îndeplinirea anumitor sarcini trebuie să fie executat. Toate deciziile lor, proprietarul de produse se traduce prin acel produs de backlog care este obținut. Este important să ne amintim că, pentru a influența activitatea echipei de dezvoltare, ea nu poate și, uneori, nu există nici măcar în planificarea, de exemplu, în cadrul întâlnirii de planificare Scrum. Cu toate acestea, ar trebui să fie mereu aproape, astfel încât, în caz de întrebări, acestea să poată fi rezolvate rapid.
Proprietarul de produse de viață din cadrul echipei Scrum
Pentru proprietarul de produse este important să scrieți sarcini nu din partea aceleiași programări, ci din cerințele clientului - "Wishlist". De exemplu, sistemul de eșantionare a revistelor este lent, mi-ar plăcea mai repede. Dacă proprietarul produsului scrie - Face o optimizare a bazei de date, atunci aceasta este abordarea greșită. Problema, de fapt, poate fi și nu într-o bază de date sau nu numai în ea. Prin urmare, descrierea tuturor sarcinilor este într-un limbaj simplu, de exemplu, pentru a accelera emiterea unui jurnal. Pentru problemele de rezolvare a problemelor, Proprietarul de produse (și orice altul) are un câmp de comentarii în Product Backlog.
Proprietarul produsului nu se poate limita doar la elaborarea unei liste de ceea ce are nevoie, deoarece interacțiunea cu echipa conduce la o muncă mai bună și mai eficientă.
Revenind la aceeași întâlnire de planificare, observi adesea că, indiferent de modul în care proprietarul produsului încearcă să completeze Product Backlog, există întotdeauna puncte controversate. Problema cea mai importantă este reevaluarea punctelor de poveste. Produs Proprietarul, uneori, nu poate furniza toate aspectele tehnice ale unei acțiuni (și nu ar trebui), și dând problema, el nu poate prevedea ce că interacțiunile complexe îndepărtate care măresc timpul de răspuns este de mai multe ori. În acest caz, estimările acestei sarcini sunt revizuite și acest lucru poate afecta rezultatul numărului total de Puncte Story dincolo de capacitățile echipei, estimate de Velocity.
Proprietarul de produse este necesar nu numai în stadiul inițial, așa cum pare, dar și în Sprint. Relația cu echipa este adevărată doar unilateral - echipa, în măsura în care apar problemele, are dreptul de a implica proprietarul produsului. Se întâmplă adesea că timpul necesar atragerii unui Proprietar de Produse depinde de timpul total petrecut împreună cu echipa. Despre acest lucru se spune: "Echipa se maturizeaza pentru intrebari pentru proprietarul produsului"
De asemenea, o datorie importantă a proprietarului de produse este de a opri sprintul. În articolul Terminare anormală, acțiunea este descrisă în detaliu.
Echipa Scrum
Organismul unic care acționează în principal, care încearcă, cu toate mijloacele, să prevină apariția unei astfel de situații neplăcute, cum ar fi Terminarea anormală și efectuarea tuturor lucrărilor.
Înapoi la produs
Lista principală a tuturor sarcinilor, în care totul este colectat, pe care echipa trebuie să o facă pentru mai multe sprinturi. Din aceasta, sarcinile sunt transferate către Sprint Backlog.
Echipa de dezvoltare
Echipa Scrum a motorului. Echipa de dezvoltare lucrează ca o echipă de fotbal bine coordonată sau orice altă echipă. Pe câmpul lor de joc (bătălia) - ele nu sunt niciodată împiedicate de nimeni, ci doar ajută. Asistentul lor principal este Scrum Master.
Sprint Planning Meeting
Este un eveniment foarte important și responsabil în metodologia Scrum, care va afecta în mod direct toate lucrările în viitor. Părțile interesate pot participa la acest eveniment.
Puncte de poveste
Pentru a înțelege în mod clar cum se formează Velocity în Scrum, trebuie să înțelegeți cum să evaluați corect punctele de poveste. Această înțelegere duce la dezvoltarea celei mai productive echipe.
Punctul de estimare Punctele, sau mai degrabă numărul lor, la scară globală are loc cu ajutorul Velocity. Viteza pe care o dezvoltă echipa în conformitate cu formula este calculată în această diagramă.
Sprint Backlog
Acest lucru este oribil din Product Backlog în Sprint Backlog și va fi un set de sarcini pentru actualul Sprint. Sprint Backlog - un lucru extrem de grijuliu care vă permite să efectuați exact acele sarcini pentru repetare, ceea ce va crea un produs de lucru.
Scrum Sprint
Poate că procesul principal al metodologiei Scrum, oprirea căruia se poate întâmpla. În timpul Sprint, are loc toată munca echipei de dezvoltare, Master Scrum și proprietar de produs.
Articole similare
Trimiteți-le prietenilor: