Lucrul cu Scrum

Povestea utilizatorului

Poveștile utilizatorilor sunt o modalitate eficientă de a stabili cerințele pentru software în dezvoltare. Astfel de povești conțin sfaturi scurte din partea utilizatorului software-ului.

Deoarece în metodologia Scrum, stabilirea obiectivelor este de obicei apanajul clientului sau proprietarului de software, acestea sunt considerate principala modalitate de a influența procesul de dezvoltare. Fiecare User Story are o limitare în ceea ce privește cantitatea de text și complexitatea prezentării. Istoria este scrisă cel mai adesea pe o foaie mică, care în sine limitează volumul.

Datorită poveștilor utilizatorilor, puteți documenta dorințele clientului și puteți răspunde rapid cerințelor pieței.

Povestea utilizatorului ar trebui considerată o măsură simplistă a cerințelor, deoarece nu include o procedură de testare a acceptării. Compilarea poveștii utilizatorului trebuie să respecte procedura de admitere. Acest lucru va asigura că Povestea utilizatorului își atinge scopul.

Structura poveștii arată astfel: „Ca utilizator <tip de utilizator>, vreau să efectuez <acțiune> pentru a obține <rezultat>” (Ca proprietar de produs vreau...). O astfel de structură nu este doar simplă, ci și de înțeles pentru toată lumea.

Beneficiile utilizării User Stories:

• Poveștile sunt mici și ușor de creat.
• Ajutați toate părțile interesate să discute despre activitatea proiectului și sprijinul acestuia.
• Nu necesită întreținere constantă.
• Relevant doar atunci când este utilizat.
• Îmbunătățiți interacțiunea cu clientul.
• Datorită lor, puteți împărți proiectul în etape mici.
• Facilitează munca la proiecte cu cerințe prost înțelese.
• Simplificați evaluarea sarcinilor.

Dezavantajele User Stories:

• Fără un acord prealabil, procedurile pot face dificilă utilizarea ca bază pentru un acord.
• Utilizarea lor necesită un contact strâns cu clientul pe parcursul întregului proiect, ceea ce îngreunează uneori fluxul de lucru.
• Ele au dezavantaje atunci când scalați pe proiecte mari.
• Direct legat de nivelul profesional al dezvoltatorilor.
• Folosit pentru a începe o discuție, dar poate să nu încheie o discuție și nu sunt utilizate pentru documentația sistemului.

Restante

Backlog-ul de produse reprezintă sarcinile curente sub forma unei liste, compilate în ordinea priorităților. Lista se formează pe baza foii de parcurs (foaia de parcurs) a proiectului și a punctelor prevăzute în acesta. Cele mai importante sarcini sunt de obicei în fruntea listei. Acest lucru este necesar pentru a înțelege ce lucru ar trebui făcut mai întâi.

Echipa de dezvoltare alege viteza de finalizare a sarcinilor de backlog indiferent de dorințele clientului, dar pe baza calificărilor și experienței sale din sprinturile trecute. Este extrem de nedorit să „ajustezi” programatorii. Echipa în sine alege sarcinile din stoc în funcție de propriile considerații și capacități. Execuția are loc fără întrerupere (Kanban) sau mai multe iterații (Scrum).

Două condiții importante de întârziere

Nucleul unui backlog de produse constă dintr-o foaie de parcurs, propuneri și condiții de execuție. Epopeele conțin condiții și Povestea utilizatorului. Să aruncăm o privire atentă la un exemplu tipic de foaie de parcurs.

Crearea site-ului „Teams in Space” este prima propunere din foaia de parcurs. Trebuie împărțit în epopee (în figură sunt afișate în culorile verde, albastru și turcoaz) și o poveste de utilizator pentru fiecare epopee.

Clientul software formează o listă din mai multe povești de utilizator. Dacă este necesar, poate schimba ordinea în care sunt executate poveștile, astfel încât dezvoltatorii să se ocupe mai întâi de una dintre cele mai importante epopee (stânga) sau să verifice cum funcționează rezervarea biletelor cu reducere. Pentru a face acest lucru, trebuie să implementați povești din epopee (dreapta). Ambele opțiuni pot fi văzute mai jos.

Pe baza ce factori ar trebui să acorde prioritate clientului?

• Relevanța pentru utilizatori.
• Prezența feedback-ului.
• Complexitatea dezvoltării.
• Relația dintre sarcini (pentru a finaliza „B”, mai întâi trebuie să faci „A”).

Prioritățile în muncă sunt stabilite de client, dar alte părți își pot exprima părerea în acest sens. Succesul restanțelor depinde, printre altele, de opiniile clienților și programatorilor. Împreună, pot obține rezultate mai bune și pot asigura livrarea la timp a produsului finit.

Cum să păstrezi un restanțe

Dacă întârzierea a fost deja creată, atunci trebuie să-l schimbați periodic în cursul lucrărilor ulterioare. Clientul de software ar trebui să se asigure că stocul este compilat corespunzător înainte de fiecare nouă planificare a iterației. Acest lucru va ajuta la clarificarea priorităților sau la schimbarea ceva după analiza ultimei iterații. Ajustarea restanțelor în Agile este uneori numită „îngrijire” sau „rafinare” sau „întreținere a restanțelor”.

Dacă acumularea este deja relativ mare, atunci clientul trebuie să grupeze sarcinile pe termen scurt și pe termen lung. Misiunile pe termen scurt trebuie analizate înainte de a li se acorda acest statut. Va trebui să compuneți o poveste de utilizator, să aflați toate nuanțele din cadrul echipei.

În ceea ce privește sarcinile pe termen lung, este foarte de dorit ca dezvoltatorii să le dea evaluarea lor. Acest lucru va facilita prioritizarea. Poate că ceva se va schimba, dar echipa își va îmbunătăți înțelegerea sarcinilor și va face treaba mai repede.

Restul este o componentă importantă între client și echipa de programare. Clientul poate schimba oricând prioritățile în funcție de feedback-ul clienților, previziuni sau cerințe noi.

Se recomandă evitarea modificărilor direct în timpul funcționării. Acest lucru are un efect negativ asupra fluxului de lucru și asupra stării emoționale a programatorilor.

Sprint

Un sprint este o perioadă scurtă în care trebuie finalizată o cantitate de muncă convenită anterior. Sprinturile se bazează pe metodologiile Scrum și Agile. Alegerea sprinturilor potrivite ajută o echipă agilă să dezvolte software de calitate.

„Folosind Scrum, poți dezvolta un produs în mai multe iterații cu o durată clară - sprinturi. Ajută la împărțirea proiectelor mari în sarcini mai mici”, spune Megan Cook, Jira Lead la Atlassian.

Cum planifică și execută Scrum sprinturile?

Potrivit autorilor metodologiei Scrum, pentru a planifica viitorul sprint, toată lumea trebuie să se întâlnească la o întâlnire separată. La acest eveniment, membrii echipei trebuie să găsească răspunsuri la două întrebări principale: ce trebuie făcut în acest sprint și cum se poate face cel mai bine?

Clientul software, Scrum Master și programatorii sunt implicați în stabilirea listei sarcinilor de lucru. Clientul explică scopul sprintului și sarcinile din backlog.

Apoi echipa elaborează un plan conform căruia sarcinile din sprint vor fi îndeplinite. Acest plan, împreună cu elementele de lucru selectate, se numește backlog de sprint. După întâlnirea de planificare, echipa se pune la treabă. Dezvoltatorii selectează sarcini din restanță, pe măsură ce munca este finalizată, starea fiecărei sarcini se schimbă de la „În desfășurare” la „Terminat”.

În timpul sprintului, echipa ține zilnic întâlniri Scrum (stand-up-uri) pentru a discuta problemele actuale și progresul. Astfel de întâlniri sunt necesare pentru identificarea dificultăților care pot afecta finalizarea sprintului.

Dacă sprintul este finalizat, atunci echipa arată rezultatele muncii lor la revizuirea rezultatelor (demo). Fiecare participant la proiect se poate familiariza cu rezultatele. Familiarizarea ar trebui făcută înainte ca codul finit să fie fuzionat în mediul de producție.

Retrospectiva completează ciclul sprinturilor. Pe el, echipa identifică zonele care trebuie îmbunătățite într-un sprint viitor.

La ce să fii atent și la ce să nu faci

Majoritatea echipelor tinere le este greu să introducă sprinturile în fluxul lor de lucru pentru prima dată. Pentru a evita problemele, vă recomandăm să revizuiți lista de acțiuni care necesită o atenție prioritară.

Ce trebuie sa facem:

• Verificați dacă echipa înțelege scopul sprintului și cum va reuși. Acest lucru este necesar pentru ca toată lumea să se îndrepte spre un rezultat de succes împreună.
• Ar trebui să aveți un întârziere clar și ușor de înțeles. Dacă întârzierea nu a fost menținută corect, aceasta poate deveni o problemă care poate deteriora fluxul de lucru.
• Asigurați-vă că estimarea dvs. a ritmului de lucru este corectă, ținând cont de vacanțele de vară și de alți factori.
• Participa activ la planificarea sprintului. Încurajați membrii echipei să extindă planul pentru povești, erori și sarcini.
• Refuzați sarcinile în timpul cărora dezvoltatorii nu vor putea rezolva problemele de dependență.
• După aprobarea planului, numiți un angajat care va fi responsabil cu introducerea datelor în programul de management al proiectului (carduri Jira etc.).

Ce trebuie evitat:

• Nu folosiți în exces un număr mare de povești, evaluați sobru ritmul de lucru și nu atribuiți sarcini care vor fi dificil de finalizat într-un sprint.
• Fii atent la calitatea muncii tale. Verificați dacă aveți suficient timp pentru controlul calității și remedierea erorilor din cod.
• Asigurați-vă că toți membrii echipei înțeleg în mod clar conținutul sprintului. Nu alunga viteza. Întreaga echipă trebuie să se miște împreună.
• Nu suprasolicitați dezvoltatorii cu muncă suplimentară. Un alt sprint vine în curând.
• Dacă echipa își exprimă îngrijorarea cu privire la volumul de muncă sau la termenul limită, ar trebui să țineți cont de opinia lor. Rezolvați problemele și corectați-le dacă este necesar.

tabla scrum

Scrum Board este un instrument care arată cum se desfășoară activitatea echipei Scrum. Puteți afișa informații pe o astfel de tablă pe hârtie, pe perete sau în formă electronică (JIRA, Trello).

O tablă Scrum are cel puțin trei coloane: De făcut, În curs și Terminat. Iată un exemplu de tablă:

Scrum board conține toate informațiile din backlog, aprobate anterior pentru planificare. De regulă, cărțile de activitate de vizită sunt fixate pe tablă prin prioritate de sus în jos. Le puteți împărți în tipuri specifice de lucru (lucrare la cod, design și altele).

După ce o parte a lucrării este finalizată, cardul este mutat pe tabelă în coloana următoare. Pentru a arăta vizibilitatea progresului muncii echipei, „munca rămasă” pe zi pe Burndown Chart ajută.

De asemenea, puteți utiliza o tablă cu flipchart. Pe ea, numele lucrărilor sunt scrise pe autocolante de hârtie și atașate pe tablă. Imediat ce lucrarea este finalizată, autocolantele sunt mutate într-o altă coloană.

diagramă de ardere

Diagrama de ardere arată cantitatea de muncă efectuată și cantitatea de muncă rămasă. Este actualizat în fiecare zi și este disponibil tuturor părților interesate. Graficul este necesar pentru a arăta progresul în lucru la sprint.

Există două tipuri de diagrame:

• Grafic Burndown care arată progresul muncii într-un sprint.
• Diagrama de ardere care arată progresul lucrării până la lansarea produsului (datele sunt rezumate din mai multe sprinturi).

Exemplu de diagramă:

Acest exemplu folosește psihologia: graficul nu arată numărul de sarcini finalizate, ci numărul de sarcini rămase (nerealizate).

Adică, dacă echipa a făcut 90 de sarcini din 100, atunci poate exista un sentiment fals că totul este gata. La urma urmei, progresul de la 90 la 100 de sarcini nu schimbă cu adevărat nimic.

Dacă afișați numărul de sarcini rămase, atunci nu puteți să nu observați cum de fiecare dată acestea devin din ce în ce mai puține. Acest lucru încurajează în mod subconștient participanții la proiect să atingă obiectivul mai repede - nu ar trebui să existe sarcini neterminate pe tablă.