agile methodology beginner s guide agile method
Un ghid complet de metodologie Agile: (20+ Tutoriale detaliate despre metodologia Agile Scrum)
Acesta este ghidul pentru dezvoltatorii și testerii de software pentru a înțelege și a începe să lucreze la faimosul Metodologie Agile SCRUM pentru dezvoltare și testare software . Aflați terminologiile de bază, dar importante utilizate în procesul Agile Scrum, împreună cu un exemplu real al procesului complet.
Am enumerat toate tutorialele Agile din această serie pentru confortul dvs. Sper că vă vor fi de un ajutor imens.
Subiecte acoperite: Ce este Agile, Ce este Scrum, Agile Methodology in Software Development and Testing, Agile Testing, Agile Scrum Process, Scrum Methodology with Scrum Team și Scrum Master.
Ce veți învăța:
- Listă de tutoriale Agile Methodology
- Introducere în dezvoltarea agilă
- Metodologie agilă
- Metodologia Scrum
Listă de tutoriale Agile Methodology
Tutorial nr. 1: Metodologii Agile Scrum (Acest tutorial)
Tutorial nr. 2: Manifest agil
Tutorial # 3: Echipa Scrum și rolurile și responsabilitățile acestora
Tutorial # 4: Artefacte Scrum
Tutorial # 5: Evenimente Scrum
Tutorial nr. 6: Defect Triaging In Scrum
Tutorial nr. 7: Echipe Scrum autosuficiente
Tutorial # 8: Principiul Trei Amigo
Tutorial # 9: SAFe - Cadru agil scalat
Tutorial # 10: Quiz Agrum Scrum
MAI MULT Tutoriale recomandate Agile Scrum:
Tutorial # 11: Cele mai bune tehnici de estimare agilă
Tutorial # 12: Model hibrid de cascadă agilă
Tutorial # 13: Kanban vs Scrum vs Agile
Tutorial # 14: JIRA Agile Tutorial
Tutorial # 15: Întâlniri retrospective agile
Tutorial # 16: Rolul analiștilor în afaceri în SCRUM
Tutorial # 17: Rolul QA în Scrum
Instrumente și întrebări pentru interviu:
Tutorial # 18: Instrumente de testare agile
Tutorial # 19: Cele mai bune instrumente de gestionare a proiectelor Agile
Tutorial # 20: Întrebări de top pentru interviuri agile
Tutorial # 21: Întrebări de top ale interviului Scrum
Să începem cu primul tutorial din serie - Introducere Agile Scrum.
Introducere în dezvoltarea agilă
Agil în dezvoltarea de software:
Agile este unul dintre cele mai utilizate și recunoscute cadre de dezvoltare software din lume.
Majoritatea organizațiilor l-au adoptat într-o formă sau alta, dar mai este un drum lung de parcurs în maturitatea programelor lor de adopție. Singurul scop al acestei serii de tutoriale este de a încorpora profesioniști în tehnologie și non-tehnologie în lumea agilă.
Vă vom duce prin călătoria agilă într-o manieră pas cu pas până când veți înțelege filosofia din spatele utilizării Agile, avantajele sale și cum să o practicați. Această serie își propune să echipeze și să permită cititorilor să aplice învățarea Agile și Scrum în munca lor.
Acest tutorial special este dedicat pentru a vă explica de ce era nevoie de Agile și cum a fost creat. Elementul fundamental aici este să vă faceți să înțelegeți conceptul de adopție agilă în industriile de dezvoltare software.
Istoria Agilei
Agile s-a născut atunci când într-o zi frumoasă, când 17 persoane cu diferite metodologii de dezvoltare, s-au reunit pentru a face brainstorming dacă a existat o posibilă soluție alternativă la dezvoltarea software-ului, care ar putea duce la un timp de dezvoltare mai rapid și ar fi mai puțin documentat.
În acea perioadă, dezvoltarea software-ului se întâmpla atât de mult, încât până când proiectele erau gata de livrare, afacerea continuase și cerințele se schimbaseră. Astfel, un proiect nu a reușit să răspundă nevoilor afacerii chiar dacă a reușit să își îndeplinească obiectivele definite.
Astfel, acești campioni ai diferitelor tehnici de inginerie software s-au reunit și rezultatul final al întâlnirii lor a fost ceea ce au numit „manifestul agil”, despre care vom discuta în detaliu în următorul tutorial al acestei serii.
Dar agilitatea care sa născut în acea zi nu este ceea ce vedem astăzi în organizații. Metodologia pe care au convenit-o experții a fost descrisă ca fiind „ușoară” și rapidă. Dar principala victorie a acestei întâlniri a fost gândul că livrarea mai rapidă a unui produs și feedback-ul constant au fost cheile pentru a obține succes în dezvoltarea de software.
Tehnicile de cascadă existente erau prea greoaie și nu aveau nicio prevedere pentru feedback până când produsul final nu era gata să fie livrat. Acest lucru a însemnat că nu există posibilități de corectare a cursului și clientul nu a avut nicio viziune asupra progresului până când întregul produs nu a fost gata. Și asta au vrut să evite acești experți.
Au dorit o soluție care să aibă posibilitate de feedback constant pentru a evita costul relucrării într-o etapă ulterioară.
Provocări agile
Tehnicile de cascadă existente în acel moment erau prea greoaie și nu aveau nicio prevedere pentru feedback până când produsul final nu era gata să fie livrat. A fost numit un model de dezvoltare a cascadei, deoarece echipele au terminat mai întâi un pas complet și abia după aceea au trecut la pasul următor.
Acest lucru a însemnat că nu există posibilități de corectare a cursului și clientul nu a avut nicio viziune asupra progresului până când întregul produs nu a fost gata. Și asta au vrut să evite acești experți. Au dorit o soluție care să aibă posibilitate de feedback constant pentru a evita costul relucrării într-o etapă ulterioară.
De aceea, agilitatea înseamnă, de asemenea, adaptarea și îmbunătățirea continuă, la fel de mult ca și feedback-ul constant și viteza de livrare.
Ce sunt promisiunile Agile?
Agile nu se referă doar la aplicarea practicilor stabilite în dezvoltarea de software. De asemenea, aduce o schimbare a mentalității echipei, care îi determină să construiască software mai bun, să lucreze împreună și, în cele din urmă, să devină un client fericit.
Valorile și principiile agile permit echipei să-și schimbe concentrarea și să-și schimbe procesul de gândire de a construi software mai bun.
Ce este exact Agile?
Agilitatea nu este un set de reguli. Agile nu sunt un set de linii directoare. Agilitatea nu este nici măcar o metodologie. Mai degrabă, Agile este un set de principii care încurajează flexibilitatea, adaptabilitatea, comunicarea și software-ul de lucru asupra planurilor și proceselor. Este surprins foarte succint în ceea ce se numește manifestul agil.
Dezvoltarea software agilă permite echipei să lucreze împreună mai eficient și mai eficient în dezvoltarea de proiecte complexe. Se compune din practici care exercită tehnici iterative și incrementale, care sunt ușor adoptate și prezintă rezultate excelente.
În aplicarea Agile în acțiune, avem diverse metode și metodologii bazate pe Agile. Aceste metode și metodologii răspund tuturor nevoilor unei industrii de dezvoltare software chiar de la proiectarea și arhitectura software, dezvoltarea și testarea până la gestionarea proiectelor și livrările.
Nu doar atât, metodele și metodologiile Agile deschid, de asemenea, posibilități de îmbunătățire a proceselor ca parte integrantă a fiecărei livrări.
Agile este o abordare de dezvoltare software în care o echipă autosuficientă și multifuncțională lucrează la realizarea livrărilor continue prin iterații și evoluează pe tot parcursul procesului prin colectarea de feedback de la utilizatorii finali.
Cum să exersezi Agile?
Există diverse metodologii Agile care sunt în practică în diverse industrii diversificate.
Cu toate acestea, cele mai populare metodologii dintre toate sunt:
- Scrum
- Kanban
- Programare extremă
Toate aceste metodologii se concentrează pe dezvoltarea software-ului lean și ajută la construirea unui software mai bun în mod eficient și eficient.
Asta este totul cu Introducere Agilă. Partea este structurată pentru a vă ajuta să înțelegeți valorile și principiile de bază care vor fi adoptate pentru ca o echipă să lucreze într-un mod Agile și mentalitate.
Agil Metodologie
Introducere în modelele Agile:
întrebări și răspunsuri de interviu de asistență tehnică de bază
După cum știm cu toții, Agile este o metodologie de dezvoltare software.
De asemenea, am aflat despre valorile și principiile care au fost menționate în manifestul agil de către fondatorii agilei. În discuțiile noastre inițiale, am abordat și diferențele dintre modelele de cascadă agile și cele tradiționale.
În acest tutorial, vom cunoaște avantajele și dezavantajele metodologiei agile.
Vom vedea ce este scrum? și în ce este diferit de agil. Apoi vom înțelege diferitele metodologii agile care sunt utilizate de diferite organizații și cum putem implementa agil folosindu-le.
De asemenea, veți putea aprecia diferența, precum și avantajele / dezavantajele acestor metodologii.
Avantajele metodologiei Agile
Mai jos sunt prezentate diferitele avantaje ale metodologiei Agile:
- Clienții obțin în mod continuu o privire asupra progresului proiectului la sfârșitul fiecărei iterații / sprinturi.
- Fiecare sprint oferă clientului un software de lucru care să răspundă așteptărilor lor, conform definiției de realizare oferită de ei.
- Echipele de dezvoltare răspund destul de mult la cerințele în schimbare și pot acomoda schimbările chiar și în etapele avansate de dezvoltare.
- Există o comunicare bidirecțională constantă care menține clienții implicați, astfel toate părțile interesate - de afaceri și tehnice - au o vizibilitate clară asupra progresului proiectului.
- Proiectarea produsului este eficientă și îndeplinește cerințele afacerii.
Dezavantaje ale metodologiei Agile
Deși există mai multe avantaje ale metodologiei Agile, există și anumite dezavantaje implicate în ea.
Sunt:
# 1) Nu este preferată documentarea cuprinzătoare, care poate duce la echipe agile care interpretează în mod incorect acest lucru, deoarece agile nu necesită documentare. Deci rigoarea se pierde în documentație. Acest lucru ar trebui evitat întrebându-vă continuu dacă sunt suficiente informații pentru a continua sau nu.
#Două) Uneori, la începutul proiectelor, cerințele nu sunt clare. Echipele ar putea continua și vor descoperi că viziunea clienților a fost realiniată și, în astfel de situații, echipele trebuie să includă multe schimbări și este dificil să se măsoare și rezultatul final.
Tipuri de metodologii Agile
Există mai multe metodologii agile în practică în întreaga lume. Vom afla mai multe în detaliu despre patru dintre cele mai populare.
# 1) Scrum
Scrum poate fi considerat cu ușurință a fi cel mai popular cadru agil. Termenul „scrum” este considerat mult sinonim cu „agil” de majoritatea practicienilor. Dar aceasta este o concepție greșită. Scrum este doar unul dintre cadrele prin care puteți implementa agil.
Cuvântul scrum provine de la rugby sportiv. Unde jucătorii se strâng împreună într-o poziție blocată împingând împotriva adversarilor. Fiecare jucător are un rol definit în poziția sa și poate juca atât ofensator, cât și defensiv, conform cerințelor situației.
În mod similar, scrum în IT crede în echipe de dezvoltare autogestionate abilitate, cu trei roluri specifice și clar definite. Aceste roluri includ - Product Owner (PO), Scrum Master (SM) și echipa de dezvoltare formată din programatori și testeri . Acestea lucrează împreună în durate iterative de timp numite sprinturi.
Primul pas este crearea restantei de produse de către OP. Este o listă de lucruri de făcut cu echipa scrum. Apoi, echipa scrum selectează elementele cu prioritate maximă și încearcă să le termine în intervalul de timp numit sprint.
O modalitate mai ușoară de a vă aminti toate acestea este să memorați cadrul 3-3-5. Înseamnă că un proiect scrum are 3 roluri, 3 artefacte și 5 evenimente.
Acestea sunt -
Roluri: PO, master Scrum și echipă de dezvoltare.
Artefacte: Product Backlog, Sprint BacklogșiIncrementarea produsului.
Evenimente: Sprint, planificare Sprint, Daily Scrum, recenzie Sprint și retrospectivă Sprint.
Vom afla mai multe în detaliu despre fiecare dintre acestea în tutorialele noastre ulterioare.
# 2) Kanban
Kanban este un termen japonez care înseamnă o carte. Aceste carduri conțin detalii despre munca de făcut pe software. Scopul este vizualizarea. Fiecare membru al echipei este conștient de munca care trebuie realizată prin intermediul acestor ajutoare vizuale.
Echipele folosesc aceste carduri Kanban pentru livrare continuă. La fel ca Scrum, Kanban este, de asemenea, pentru a ajuta echipele să lucreze eficient și promovează echipe auto-gestionate și de colaborare.
Dar există și diferențe între aceste două - cum ar fi în timpul unui sprint scrum, articolele lucrate de o echipă sunt fixe și nu putem adăuga articole la sprint, în timp ce, în Kanban, putem adăuga articole dacă există capacitate disponibilă. Acest lucru este util mai ales atunci când cerințele se schimbă frecvent.
În mod similar, o altă diferență este că, deși scrum are roluri definite de PO, master scrum și echipe de dezvoltare, nu există astfel de roluri predefinite în Kanban.
O altă diferență este că, în timp ce scrumul sugerează o prioritizare a restanțelor de produse, Kanban nu are o astfel de cerință și este complet opțional. Astfel, Kanban necesită mai puțină organizare și evită activitățile fără valoare adăugată și este potrivit pentru procesele care necesită reacție la schimbări.
# 3) Lean
Lean este o filozofie care se concentrează pe reducerea deșeurilor. Cum se face asta?
În lean, împărțiți un proces în activități cu valoare adăugată, activități fără valoare adăugată și activități esențiale fără valoare adăugată. Orice activitate care poate fi clasificată ca o activitate fără valoare adăugată este o risipă și ar trebui să încercăm să eliminăm risipa în acest proces pentru a o face mai slabă.
Un proces mai ușor înseamnă o livrare mai rapidă și mai puțin efort irosit în sarcini care nu ajută la atingerea obiectivelor echipei. Acest lucru ajută la optimizarea fiecărui pas din ciclul de dezvoltare software. De aceea, principiile lean au fost adaptate de la fabricarea lean la dezvoltarea de software.
Dezvoltarea software Lean poate fi utilizată în orice proiect IT prin aplicarea celor șapte principii lean care sunt prezentate mai jos:
Acestea se explică de la sine, așa cum sugerează și numele lor. Eliminarea risipei este primul și cel mai important principiu slab și am văzut cum să facem acest lucru, doar clasificăm activitățile ca valoare și fără valoare adăugată.
O activitate fără valoare adăugată poate fi orice parte a codului care ar putea să o facă mai puțin robustă, să crească efortul implicat și să ocupe mult timp, fără a adăuga o valoare justificată a afacerii. Poate fi, de asemenea, povești vagi de utilizator sau testări slabe sau adăugarea de funcții care nu sunt necesare în imaginea de ansamblu.
Al doilea principiu care amplifică învățarea este din nou ușor de înțeles, deoarece o echipă are nevoie de diverse abilități pentru a livra produse într-un mediu în schimbare rapidă, cu noile tehnologii care se dezvoltă în durate rapide.
Luarea deciziilor târzii poate fi plină de satisfacții în circumstanțele în care reduce relucrarea, cum ar fi dacă se așteaptă orice schimbări, mai bine întârziați-o, astfel încât echipa să nu fie nevoită să refacă lucrarea, deoarece afacerea are nevoie să se schimbe.
Dar există întotdeauna un compromis aici, deoarece echipele trebuie să echilibreze acest lucru cu al patrulea principiu de a oferi mai repede. Întârzierea deciziilor nu ar trebui să aibă impact asupra livrării generale și nu trebuie să reducă ritmul de lucru. Un singur ochi ar trebui să fie întotdeauna asupra imaginii complete.
A avea echipe împuternicite este, de asemenea, foarte obișnuit în zilele noastre și acest lucru sugerează chiar și agilitatea. Echipele abilitate sunt mai responsabile și pot lua decizii mai repede. Sentimentul de proprietate într-o echipă împuternicită duce la rezultate mai bune. Pentru a împuternici o echipă, ar trebui să li se permită să se organizeze și să ia decizii pe cont propriu.
Astfel vedem că slabul și agilul au multe în comun cu o diferență puternică - în timp ce echipele slabe pot ajuta la rafinarea unui produs, echipele agile sunt cele care construiesc efectiv produsul.
# 4) Programare extremă (XP)
Programarea extremă este o altă tehnică agilă cea mai populară. Conform extremeprogramming.org, primul proiect XP a fost început la 6 martie 1996. De asemenea, menționează că XP are impact asupra dezvoltării proiectelor software în 5 moduri diferite - comunicare, simplitate, feedback, respect și curaj. Acestea se numesc valorile XP.
Dintre acestea, totul începe cu comunicarea. Echipele XP colaborează în mod regulat cu echipele de afaceri și colegii programatori și încep să construiască coduri încă din prima zi. Accentul se pune aici pe comunicarea față în față, pe cât posibil, cu ajutorul celorlalte mijloace vizuale.
Programatorii extremi construiesc, de asemenea, un cod simplu și încep să primească feedback despre el încă din prima zi. Accentul este pe a nu trece peste bord sau a prevedea cerințe care nu au fost partajate. Acest lucru menține designul simplu și produce doar produsul minim care va satisface cerințele.
Feedback-ul ajută echipa să se îmbunătățească și să producă o calitate mai bună a muncii. Acest lucru îi ajută să își construiască respect unul pentru celălalt pe măsură ce învață unii de la alții și învață cum să își împărtășească opiniile.
Acest lucru le oferă, de asemenea, curajul, deoarece știu că au adunat cele mai bune idei ale tuturor și au produs un produs bun cu feedback de la alții. Astfel, ei nici nu se tem să includă modificări sau să primească feedback suplimentar cu privire la munca lor.
Acest lucru este deosebit de util în proiectele în care cerințele se vor schimba des. Feedbackul constant va ajuta echipele să includă aceste schimbări cu curaj.
Astfel am văzut diferitele metodologii agile precum Scrum, XP, Kanban și Lean, împreună cu avantajele și dezavantajele lor.
Acum, putem diferenția cu ușurință între ele și, de asemenea, putem aprecia diferențele mai subtile dintre ele. De asemenea, am învățat elementele fundamentale ale fiecăreia dintre aceste metodologii și am văzut cum să le aplicăm în proiectele noastre după cum este necesar.
În partea următoare, să înțelegem totul despre Scrum.
Metodologia Scrum
SCRUM este un proces în metodologie agilă, care este o combinație între modelul iterativ și modelul incremental.
Unul dintre handicapurile majore ale tradiționalului Model cascadă a fost că - până la finalizarea primei faze, aplicația nu trece la cealaltă fază. Și întâmplător, dacă există unele modificări în etapa ulterioară a ciclului, atunci devine foarte dificil să implementăm aceste modificări, deoarece ar presupune revizuirea fazelor anterioare și refacerea modificărilor.
Unele dintre caracteristicile cheie ale SCRUM includ:
- Echipa auto-organizată și concentrată.
- Nu există documente cu cerințe uriașe, mai degrabă au o poveste foarte precisă și la obiect.
- Echipele multifuncționale lucrează împreună ca o singură unitate.
- Comunicarea strânsă cu reprezentantul utilizatorului pentru a înțelege caracteristicile.
- Are un calendar definit de maximum o lună.
- În loc să facă întregul „lucru” la un moment dat, Scrum face puțin din toate la un anumit interval.
- Capacitatea și disponibilitatea resurselor sunt luate în considerare înainte de a comite ceva.
Pentru a înțelege bine această metodologie, este important să înțelegem terminologiile cheie din SCRUM.
Citește și => Cum să furnizați caracteristici software de înaltă valoare într-o perioadă scurtă de timp, utilizând procesul Agile Scrum
Terminologii importante SCRUM
1) Echipa Scrum
Echipa scrum este o echipă formată din 7 cu + sau - doi membri. Acești membri sunt un amestec de competențe și cuprind dezvoltatori, testeri, oameni din baza de date, oameni de asistență etc., împreună cu proprietarul produsului și un master de scrum.
Toți acești membri lucrează împreună în strânsă colaborare pentru un interval recursiv și definit, pentru a dezvolta și implementa caracteristicile menționate. Aranjamentul de ședere al echipei SCRUM joacă un rol foarte important în interacțiunea lor, nu stau niciodată în cabine sau cabine, ci pe o masă imensă.
2) Sprint
Sprint este un interval predefinit sau un interval de timp în care lucrarea trebuie să fie finalizată și să fie pregătită pentru revizuire sau pregătită pentru implementarea producției. Această casetă de timp se situează de obicei între 2 săptămâni și o lună.
cel mai bun software voce-text
În viața noastră de zi cu zi, când spunem că urmăm ciclul Sprint de o lună, înseamnă pur și simplu că lucrăm o lună la sarcini și îl pregătim pentru revizuire până la sfârșitul acelei luni.
3) Proprietar de produs
Proprietarul produsului este părțile interesate cheie sau utilizatorul principal al aplicației care urmează să fie dezvoltată. Proprietarul produsului este persoana care reprezintă partea clientului. El / ea are autoritatea finală și ar trebui să fie întotdeauna disponibil pentru echipă.
El / ea ar trebui să poată fi accesat atunci când cineva are îndoieli care necesită clarificări. Este important ca proprietarul produsului să înțeleagă și să nu atribuie nicio cerință nouă în mijlocul sprintului sau când sprintul a început deja.
4) Scrum Master
Scrum Master este facilitatorul echipei scrum. El / ea se asigură că echipa scrum este productivă și progresivă. În cazul unor impedimente, maestrul scrum urmărește și le rezolvă pentru echipă. SCRUM Master este mediatorul dintre PO și echipă.
El / ea ține PO-ul informat despre progresul Sprint-ului. Dacă există obstacole sau preocupări pentru echipă, discută cu OP și le rezolvă. La fel ca Standup-ul zilnic al echipei, în fiecare zi se întâmplă un stand-up al SCRUM Master cu PO.
Citire recomandată => Cum să fii un bun mentor al echipei, antrenor și un adevărat apărător al echipei într-o lume de testare agilă?
5) Analist de afaceri (BA)
Un analist de afaceri joacă un rol foarte important în SCRUM. Această persoană este responsabilă pentru finalizarea și redactarea cerințelor în documentele privind cerințele (pe baza cărora sunt create poveștile utilizatorilor).
Dacă există ambiguități în criteriile User Povestiri / Acceptare, el / ea este cel care este abordat de echipa tehnică (SCRUM) și apoi îl duce la PO sau, dacă este posibil, se soluționează de unul singur. În proiectele la scară largă, pot exista mai mult de 1 BA, dar în proiectele la scară mică, SCRUM Master poate acționa și ca BA.
Este întotdeauna o bună practică să ai un BA când începe proiectul.
6) Povestea utilizatorului
Poveștile utilizatorilor nu sunt altceva decât cerințele sau caracteristica care trebuie implementată.
În scrum, nu avem acele documente de cerințe uriașe, ci mai degrabă cerințele sunt definite într-un singur paragraf, având de obicei formatul ca:
Ca
Vreau să
Pentru a realiza
De exemplu :
În calitate de administrator vreau să am o blocare a parolei în cazul în care utilizatorul introduce o parolă incorectă de 3 ori consecutive pentru a restricționa accesul neautorizat.
Există câteva caracteristici ale poveștilor utilizatorilor care ar trebui respectate. Poveștile utilizatorilor trebuie să fie scurte, realiste, ar putea fi estimate, complete, negociabile și testabile. O poveste de utilizator nu este niciodată modificată sau modificată în mijlocul Sprint-ului.
Este responsabilitatea comandantului SCRUM și a BA (dacă este cazul) să se asigure că OP-ul a elaborat corect poveștile utilizatorilor cu un set adecvat de criterii de acceptare ”. Dacă se vor face modificări care vor avea impact asupra lansării sprintului, atunci aceste povești sunt scoase din sprint sau sunt realizate conform orelor disponibile.
Fiecare poveste a utilizatorului are un criteriu de acceptare care ar trebui să fie bine definit și înțeles de echipă.
Criteriile de acceptare detaliază povestea utilizatorului care furnizează documentele justificative. Vă ajută să rafinați în continuare povestea utilizatorului. Oricine din echipă poate nota criteriile de acceptare. Echipa de testare își bazează cazurile / condițiile de testare pe aceste criterii de acceptare.
7) Epopee
Epopeile sunt povești echivoce ale utilizatorilor sau putem spune că acestea sunt poveștile utilizatorilor care nu sunt definite și sunt păstrate pentru sprinturi viitoare.
Încercați doar să o raportați la viață, imaginați-vă că plecați într-o vacanță. Pe măsură ce plecați săptămâna viitoare, aveți totul la dispoziție, cum ar fi rezervările dvs. de hoteluri, vizitarea obiectivelor turistice, verificarea călătorilor etc. Dar cum rămâne cu planul dvs. de vacanță pentru anul viitor? Aveți doar o idee vagă că puteți merge la locul XYZ, dar nu aveți un plan detaliat.
O Epic este la fel ca planul tău de vacanță de anul viitor, unde știi doar că poate vrei să mergi, dar unde, când, cu cine, toate aceste detalii nu ai idee în acest moment.
În mod similar, există caracteristici care trebuie implementate în viitor ale căror detalii nu sunt încă cunoscute. În principal, o caracteristică începe cu un Epic și apoi este împărțită în povești care ar putea fi implementate.
8) Backlog de produse
Backlog-ul produsului este un fel de sursă sau sursă în care sunt păstrate toate poveștile utilizatorilor. Acest lucru este menținut de proprietarul produsului. Restanța produsului poate fi imaginată ca o listă de dorințe a proprietarului produsului care îl acordă prioritate în funcție de nevoile companiei.
În timpul ședinței de planificare (a se vedea secțiunea următoare), o poveste a utilizatorului este preluată din restanța produsului, apoi echipa face brainstorming-ul, îl înțelege și îl rafinează și decide colectiv ce povestiri ale utilizatorilor să ia, cu intervenția proprietarului produsului.
9) Sprint Backlog
Pe baza priorității, poveștile utilizatorilor sunt preluate din Backlog-ul produselor, una câte una. Echipa Scrum face brainstorming-uri asupra acesteia determină fezabilitatea și decide poveștile pentru a lucra la un anumit sprint. Lista colectivă a tuturor poveștilor utilizatorilor pe care echipa scrum le lucrează la un anumit sprint este cunoscută sub numele de Sprint backlog.
10) Puncte de poveste
Punctele de poveste sunt o indicație cantitativă a complexității unei povești de utilizator. Pe baza punctului de poveste, se determină estimarea și eforturile pentru o poveste.
Un punct de poveste este relativ și nu absolut. Pentru a ne asigura că estimarea și eforturile noastre sunt corecte, este important să verificăm dacă poveștile utilizatorilor nu sunt mari. Cu cât povestea utilizatorului este mai precisă și mai mică, cu atât estimarea va fi mai precisă.
Fiecare poveste a utilizatorului este alocată unui punct de poveste bazat pe seria Fibonacci (1, 2, 3, 5, 8, 13 și 21). Mai mare este numărul, complexul este povestea.
Mai exact
- Dacă dați 1/2/3 punct de poveste înseamnă că povestea este mică și de complexitate redusă.
- Dacă dați puncte ca 5/8, este un complex mediu și
- 13 și 21 sunt extrem de complexe.
Aici complexitatea constă atât din dezvoltare, cât și din efort de testare.
Pentru a decide un punct de poveste, brainstorming-ul are loc în cadrul echipei scrum și echipa decide colectiv un punct de poveste.
Se poate întâmpla ca echipa de dezvoltare să acorde un punct de poveste de 3 unei anumite povestiri, deoarece pentru ei poate fi vorba de 3 linii de modificare a codului, dar echipa de testare acordă 8 puncte de poveste, deoarece consideră că această modificare de cod va afecta modulele mai mari, astfel încât efortul de testare ar fi mai mare. Orice punct de poveste pe care îl oferiți, trebuie să-l justificați.
Deci, în această situație, se întâmplă brainstorming-urile și echipa este de acord în mod colectiv cu un singur punct de poveste.
Ori de câte ori decideți un punct de poveste, țineți cont de factorii de mai jos:
- Dependența poveștii de alte aplicații / module.
- Setul de abilități al resursei.
- Complexitatea poveștii.
- Învățarea istorică.
- Criterii de acceptare a poveștii utilizatorului.
Dacă nu cunoașteți o anumită poveste, nu o dimensionați.
Ori de câte ori o poveste are = sau> 8 puncte, aceasta este împărțită în 2 sau mai multe povești.
11) Ardeți graficul
Graficul Burn Burn este un grafic care arată efortul real estimat v / s al sarcinilor scrum.
Este un mecanism de urmărire prin care pentru un anumit sprint sunt urmărite sarcinile de zi cu zi pentru a verifica dacă poveștile progresează către finalizarea punctelor de poveste angajate sau nu.
Exemplu : Pentru a înțelege acest lucru, verificați figura de mai jos:
Am presupus:
- 2 saptamani Sprint (10 zile)
- 2 resurse care lucrează efectiv la sprint.
'Poveste' -> Această coloană prezintă poveștile utilizatorilor luate pentru sprint.
'Sarcină' -> Această coloană arată lista sarcinilor asociate cu povestea utilizatorului.
'Efort' -> Această coloană arată efortul. Acum, această măsură este efortul total de a finaliza sarcina. Nu descrie efortul depus de nicio persoană anume.
„Ziua 1 - Ziua 10” -> Această (aceste coloane) arată orele care mai rămân pentru finalizarea poveștii. Vă rugăm să vedeți că ora NU este ora care a fost deja făcută, ci orele care au mai rămas.
„Efort estimat” -> Este totalul efortului. Pentru „Start” este pur și simplu suma întregii sarcini individuale: SUM (C5: C15)
Un număr total de efort care trebuie finalizat în 1 zi este 70/10 = 7. Deci, la sfârșitul primei zile, efortul ar trebui să se reducă la 70 - 7 = 63. În mod similar, este calculat pentru toate zile până în ziua 10, când efortul estimat ar trebui să fie 0 (rândul 16)
„Efort efectiv rămas” -> După cum sugerează și numele, este efortul rămas efectiv pentru a finaliza povestea. De asemenea, se poate întâmpla ca eforturile efective să crească sau să scadă decât cele estimate.
Puteți utiliza funcțiile încorporate și Diagrama în Excel pentru a crea această diagramă de descompunere.
Pașii graficului ars ar fi:
- Introduceți toate poveștile (Coloana A5 - A15).
- Introduceți toate sarcinile (Coloana B5 - B15).
- Introduceți Zilele (Ziua 1 - Ziua 10).
- Introduceți eforturile inițiale (Sumați sarcinile C5 - C15).
- Aplicați formula pentru a calcula „Eforturile estimate” pentru fiecare zi (Ziua 1 până la Ziua 10). Introduceți formula la D15 (C16- $ C $ 16/10) și trageți-o pentru toate zilele.
- Pentru fiecare zi, introduceți eforturile efective. Introduceți formula la D17 (SUM (D5: D15)) pentru a însuma eforturile efective rămase și trageți-o pentru toate celelalte zile.
- Selectați-l și creați graficul după cum urmează:
12) Viteza
Numărul total de puncte de poveste pe care o echipă scrum le arhivează într-un sprint, se numește Velocity. Echipa Scrum este judecată sau menționată în funcție de viteza sa. Acestea fiind spuse, ar trebui să se țină cont de faptul că obiectivul de aici NU este de a atinge punctele maxime de poveste, ci de a avea un livrabil de calitate, respectând nivelul de confort al echipei scrum.
De exemplu : Pentru un anumit sprint: numărul total de povești ale utilizatorilor este de 8, având puncte de poveste, așa cum se arată mai jos.
Deci aici viteza va fi suma punctelor povestirii = 30
Definiția Gata:
Un Sprint este marcat ca Terminat atunci când toate poveștile sunt finalizate, toate sarcinile de dezvoltare, cercetare, QA sunt marcate ca „Finalizate”, toate erorile sunt fixate-închise altfel cele care pot fi realizate ulterior (cum ar fi nu sunt complet legate sau sunt mai puțin importante) sunt extrase și adăugate în restante, revizuirea codului și testarea unității sunt finalizate, orele estimate au îndeplinit orele reale prevăzute în sarcini și, cel mai important, a fost oferită o demonstrație de succes către OP și părțile interesate.
Activități desfășurate în metodologia SCRUM
# 1) Întâlnire de planificare
O întâlnire de planificare este punctul de plecare al Sprint. Este întâlnirea în care se întrunește întreaga echipă scrum, SCRUM Master selectează o poveste a utilizatorului pe baza priorității din restanța produsului și echipa de brainstormings pe ea.
Pe baza discuției, echipa scrum decide complexitatea poveștii și o dimensionează conform seriei Fibonacci. Echipa identifică sarcinile împreună cu eforturile (în ore) care ar fi făcute pentru a finaliza implementarea povestii utilizatorului.
De multe ori, întâlnirea de planificare este precedată de o „întâlnire de planificare prealabilă”. Este la fel ca temele pe care le face echipa scrum înainte de a participa la întâlnirea formală de planificare. Echipa încearcă să noteze dependențele sau alți factori pe care ar dori să-i discute în cadrul ședinței de planificare.
# 2) Executarea sarcinilor Sprint
După cum sugerează și numele, acestea sunt munca reală realizată de echipa scrum pentru a-și îndeplini sarcina și pentru a duce povestea utilizatorului în starea „Terminat”.
# 3) Standup zilnic
În timpul ciclului de sprint, în fiecare zi, echipa de scrum se întrunește, nu mai mult de 15 minute (ar putea fi un apel stand-up, recomandat să aibă la începutul zilei) și să precizeze 3 puncte:
- Ce a făcut ieri membrul echipei?
- Ce intenționa să facă azi echipa?
- Vreun impediment (blocaje)?
Maestrul Scrum este cel care facilitează această întâlnire. În cazul în care, orice membru al echipei se confruntă cu orice fel de dificultăți, maestrul scrum urmărește pentru a-l rezolva. În Stand up-uri, consiliul este, de asemenea, revizuit și arată în sine progresul echipei.
# 4) Reuniune de revizuire
La sfârșitul fiecărui ciclu de sprint, echipa SCRUM se reunește din nou și demonstrează proprietarului produsului poveștile utilizatorilor implementate. Proprietarul produsului poate verifica poveștile încrucișate conform criteriilor sale de acceptare. Este din nou responsabilitatea maestrului Scrum să prezideze această întâlnire.
De asemenea, în instrumentul SCRUM, Sprint-ul este închis și sarcinile sunt marcate ca fiind terminate.
# 5) Întâlnire retrospectivă
Reuniunea retrospectivă are loc după întâlnirea de revizuire.
Echipa SCRUM întrunește, discută și documentează următoarele puncte:
- Ce a mers bine în timpul Sprintului (Cele mai bune practici)?
- Ce nu a mers bine în Sprint?
- Lecții învățate
- Articole de acțiune.
Echipa Scrum ar trebui să continue să urmeze cele mai bune practici, să ignore „nu cele mai bune practici” și să implementeze lecțiile învățate în timpul sprinturilor consecvente. Reuniunea retrospectivă ajută la implementarea îmbunătățirii continue a procesului SCRUM.
Cum se face procesul? Un exemplu!
După ce ați citit despre jargoanele tehnice ale SCRUM. permiteți-mi să încerc să demonstrez întregul proces cu un exemplu.
Exemplu:
Pasul 1 : Să avem o echipă SCRUM formată din 9 persoane compuse din 1 proprietar de produs, 1 master Scrum, 2 testere, 4 dezvoltatori și 1 DBA.
Pasul 2 : Sprintul este decis să urmeze un ciclu de 4 săptămâni. Așadar, avem Sprint de o lună, începând cu 5 iunie până la 4adin iulie.
Pasul 3 : Proprietarul produsului are lista prioritară a poveștilor utilizatorilor din restanța produsului.
Pasul 4: Echipa decide să se întâlnească pe 4aIunie pentru întâlnirea „Pre Planificare”.
- Proprietarul produsului ia o poveste din restanța produsului, o descrie și o lasă echipei să facă o brainstorming pe ea.
- Întreaga echipă discută și comunică direct proprietarului produsului pentru a fi înțeles în mod clar povestea utilizatorului.
- În mod similar, sunt luate diverse alte povești ale utilizatorilor. Dacă este posibil, echipa poate continua și dimensiona poveștile, de asemenea.
După toată discuția, membrii echipei individuale se întorc la stațiile lor de lucru și
- Identificați sarcinile lor individuale pentru fiecare poveste.
- Calculați numărul exact de ore la care vor lucra. Să verificăm modul în care membrul încheie aceste ore.
Numărul total de ore de lucru = 9
Minus 1 oră pentru pauză, minus 1 oră pentru întâlniri, minus 1 oră pentru e-mailuri, discuții, depanare etc.
Deci, programul efectiv de lucru = 6.
Un număr total de zile lucrătoare în timpul Sprint = 21 zile.
Numărul total de ore disponibile = 21 * 6 = 126.
Membrul este în concediu timp de 2 zile = 12 ore (Acest lucru variază pentru fiecare membru, unii pot lua concediu, iar alții nu.)
Numărul de ore reale = 126 - 12 = 114 ore.
Aceasta înseamnă că membrul va fi de fapt disponibil timp de 114 ore pentru acest sprint. Așa că își va descompune sarcina individuală de sprint în așa fel încât să fie atins un total de 114 ore.
Pasul 5 : Pe 5adin iunie întreaga echipă Scrum se întrunește pentru „Planificarea întâlnirii”.
- Verdictul final al poveștii utilizatorului din restanța produsului este încheiat, iar povestea este mutată în Sprint Backlog.
- Pentru fiecare poveste, fiecare membru al echipei își declară sarcinile identificate, dacă este necesar, poate purta o discuție cu privire la acele sarcini, o poate dimensiona sau redimensiona (amintiți-vă seria Fibonacci !!).
- Maestrul Scrum sau echipa își introduc sarcinile individuale împreună cu orele lor pentru fiecare poveste într-un instrument.
- După ce toate poveștile sunt finalizate, maestrul Scrum notează viteza inițială și începe oficial Sprint-ul.
Pasul # 6 : Odată ce Sprint-ul a început, pe baza sarcinilor atribuite, fiecare membru al echipei începe să lucreze la acele sarcini.
Pasul 7 : Echipa se întrunește zilnic timp de 15 minute și discută 3 lucruri:
- Ce au făcut ieri?
- Ce intenționează să facă astăzi?
- Vreun impediment (blocaje)?
Pasul 8 : Masterul scrum urmărește progresul zilnic cu ajutorul „Burn down chart”.
Pasul # 9 : În cazul unor impedimente, masterul Scrum urmărește rezolvarea acestora.
Pasul 10 : Pe 4aIulie, echipa se întrunește din nou pentru reuniunea de revizuire. Un membru demonstrează proprietarului produsului povestea utilizatorului implementat.
Pasul 11 : La 5aIulie, echipa se întrunește din nou pentru Retrospectivă, unde discută
- Ce a mers bine?
- Ce nu a mers bine?
- Articole de acțiune.
Pasul 12 : La 6aIulie, echipa se întrunește din nou pentru pre-întâlnire de planificare pentru următorul sprint și ciclul continuă.
Instrumente de activitate SCRUM
Există mai multe instrumente care pot fi utilizate pe scară largă pentru urmărirea activităților scrum.
Unele dintre ele includ:
În viitorul tutorial, vom arunca lumina asupra Manifestului Agile, care este o noțiune care conduce echipe Agile eficiente.
Despre autori: Această serie este scrisă de următorii membri ai echipei STH: Shruti Shrivastava - Un profesionist Scrum Master cu 9 ani de experiență în domeniile BFSI, e-commerce și B2B. Shruti este un expert în testarea automatizării și în conducerea echipelor scrum.Anshul Kumar Srivastava - Un profesionist în managementul produselor orientat spre rezultate și practicant Agile, cu 7 ani de experiență în sectoarele BFSI și Telecom.
Lectură recomandată
- Test online Agile Scrum: testați-vă cunoștințele despre Agile Scrum
- Kanban vs Scrum vs Agile: o comparație detaliată pentru a găsi diferențe
- Cum să livrați caracteristici software de mare valoare într-o perioadă scurtă de timp, utilizând procesul Agile Scrum
- Manifest Agile: Înțelegerea valorilor și principiilor Agile
- Tutorial SAFe Agile: Ce este Scaled Agile Framework
- 30+ Întrebări și răspunsuri de top pentru interviurile Scrum [LISTA 2021]
- Agile Vs Waterfall: Care este cea mai bună metodologie pentru proiectul dvs.?
- Top 31 întrebări și răspunsuri la interviuri agile