Meni

Agilna metodologija: Vodič za agilnu metodu i scrum za početnike

agile methodology beginner s guide agile method

Isprobajte Naš Instrument Za Uklanjanje Problema

Cjelovit vodič za agilnu metodologiju: (20+ detaljnih vodiča za agilnu Scrum metodologiju)

Ovo je vodič za programere i testere softvera da razumiju i počnu raditi na vrlo poznatom Agile SCRUM metodologija za razvoj i testiranje softvera . Naučite osnovne, ali važne terminologije korištene u procesu Agile Scrum, zajedno sa stvarnim primjerom cjelovitog postupka.

Za vašu smo udobnost naveli sve Agile tutorijale u ovoj seriji. Nadam se da će vam biti od ogromne pomoći.

Tema završena: Što je Agile, Što je Scrum, Agile metodologija u razvoju i testiranju softvera, Agile testiranje, Agile Scrum proces, Scrum metodologija sa Scrum timom i Scrum Masterom.

uvod u okretan razvoj

Što ćete naučiti:

Popis tutorijala za agilnu metodologiju

Vodič br. 1: Agile Scrum metodologije (Ovaj vodič)
Vodič br. 2: Agile Manifest
Vodič br. 3: Scrum tim i njihove uloge i odgovornosti
Vodič br. 4: Scrum Artefakti
Vodič br. 5: Scrum događaji
Vodič br. 6: Triaging nedostataka u skrupu
Vodič br. 7: Samodostatni Scrum timovi
Vodič br. 8: Tri principa Amigo
Vodič br. 9: SAFe - Skalirani agilni okvir
Vodič br. 10: Agile Scrum Quiz

JOŠ preporučenih Agile Scrum vodiča:

Vodič br. 11: Vrhunske agilne tehnike procjene
Vodič br. 12: Agile Hybrid Model vodopada
Vodič br. 13: Kanban vs Scrum vs Agile
Vodič br. 14: JIRA Agile Tutorial
Vodič br. 15: Agile retrospektivni sastanci
Vodič br. 16: Uloga poslovnih analitičara u SCRUM-u
Vodič # 17: QA’s Role in Scrum

Alati i pitanja za intervju:

Vodič br. 18: Agilan alat za testiranje
Vodič br. 19: Najbolji agilni alati za upravljanje projektima
Vodič br. 20: Najpopularnija pitanja o agilnom intervjuu
Vodič br. 21: Najpopularnija pitanja za Scrum intervju

Počnimo s prvim tutorijalom u nizu - Agile Scrum Introduction.

Uvod u agilni razvoj

Agilan u razvoju softvera:

Agile je jedan od najčešće korištenih i najpriznatijih okvira za razvoj softvera na svijetu.

Većina organizacija prihvatila ga je u jednom ili drugom obliku, ali još uvijek je dug put do zrelosti njihovih programa usvajanja. Jedini cilj ove serije tutorijala je usmjeriti profesionalce koji se bave tehnologijom i netehnologijom u Agile World.

Provest ćemo vas kroz agilno putovanje korak po korak dok ne shvatite filozofiju upotrebe Agilea, njegove prednosti i kako to prakticirati. Ova serija ima za cilj opremiti i omogućiti čitateljima da primijene Agile i Scrum učenje u svom radu.

Ovaj je vodič posvećen objašnjavanju zašto je postojala potreba za Agileom i kako je stvoren. Ovdje je osnovno kako biste razumjeli koncept agilnog usvajanja u industrijama za razvoj softvera.

Povijest Agilea

Agile je rođen kada se jednog lijepog dana kada se 17 ljudi s različitim pozadinama razvojnih metodologija okupilo kako bi razmislili postoji li moguće alternativno rješenje za razvoj softvera koje bi moglo dovesti do bržeg razvoja i manje dokumentacije.

U to se vrijeme razvoj softvera dogodio toliko dugo da je posao, dok su projekti bili spremni za isporuku, krenuo naprijed i zahtjevi se promijenili. Stoga projekt nije mogao udovoljiti poslovnim potrebama čak i ako je uspio ispuniti svoje definirane ciljeve.

Tako su se ovi prvaci različitih tehnika softverskog inženjerstva okupili, a krajnji rezultat njihovog sastanka bio je ono što su nazvali „agilni manifest“ o kojem ćemo detaljno raspravljati u sljedećem vodiču ove serije.

Ali agilni koji se rodio tog dana nije ono što danas vidimo u organizacijama. Metodologija oko koje su se stručnjaci složili opisana je kao 'lagana' i brza. No glavna pobjeda na ovom sastanku bila je misao da su brža isporuka proizvoda i stalne povratne informacije ključ postizanja uspjeha u razvoju softvera.

Postojeće tehnike slapova bile su previše glomazne i nisu imale povratnih informacija dok konačni proizvod nije bio spreman za isporuku. To je značilo da nije bilo mogućnosti za korekciju tečaja, a kupac nije imao pogled na napredak dok cijeli proizvod nije bio spreman. I to je ono što su ti stručnjaci željeli izbjeći.

Željeli su rješenje koje će imati prostor za stalne povratne informacije kako bi se izbjegli troškovi prerade u kasnijoj fazi.

Agilni izazovi

Postojeće tehnike slapova u to su vrijeme bile previše glomazne i nisu imale mogućnost povratnih informacija dok konačni proizvod nije bio spreman za isporuku. Nazvan je vodopadnim modelom razvoja jer su timovi prvo završili jedan korak u potpunosti, a tek nakon toga prešli su na sljedeći korak.

To je značilo da nije bilo mogućnosti za korekciju tečaja, a kupac nije imao pogled na napredak dok cijeli proizvod nije bio spreman. I to je ono što su ti stručnjaci željeli izbjeći. Željeli su rješenje koje će imati prostor za stalne povratne informacije kako bi se izbjegli troškovi prerade u kasnijoj fazi.

I zato je agilnost također prilagodljivo i kontinuirano usavršavanje, jednako kao i stalne povratne informacije i brzina isporuke.

Što su agilna obećanja?

Agile Promises

Agile nije samo primjena postavljenih praksi u razvoju softvera. To također donosi promjenu u načinu razmišljanja Tima što ih vodi prema izgradnji boljeg softvera, zajedničkom radu i na kraju donošenju sretnog kupca.

Agilne vrijednosti i principi omogućuju timu da promijeni fokus i promijeni svoj misaoni proces izgradnje boljeg softvera.

Što je zapravo agilno?

Agile nije skup pravila. Agile nije skup smjernica. Agile nije ni metodologija. Umjesto toga, Agile je skup principa koji potiču fleksibilnost, prilagodljivost, komunikaciju i radni softver u odnosu na planove i procese. Vrlo je kratko sažet u onome što se naziva agilnim manifestom.

Agilan razvoj softvera omogućuje timu učinkovitiji i učinkovitiji rad u razvoju složenih projekata. Sastoji se od praksi koje koriste iterativne i inkrementalne tehnike koje se lako usvajaju i daju izvrsne rezultate.

Da bismo primijenili Agile u akciju, imamo razne metode i metodologije utemeljene na Agileu. Ove metode i metodologije udovoljavaju svim potrebama industrije softverskog razvoja, od dizajna i arhitekture softvera, razvoja i testiranja do upravljanja projektima i isporuka.

I ne samo to, agilne metode i metodologije također otvaraju prostor za poboljšanje procesa kao sastavni dio svake isporuke.

Agile je pristup razvoju softvera gdje samodostatan i višefunkcionalan tim radi na kontinuiranim isporukama kroz iteracije i razvija se tijekom procesa prikupljanjem povratnih informacija od krajnjih korisnika.

Kako vježbati agilno?

Postoje razne agilne metodologije koje su u praksi u raznim raznolikim industrijama.

agilne metodologije

Međutim, najpopularnije metodologije među svima njima su:

  • Ološ
  • Kanban
  • Ekstremno programiranje

Sve ove metodologije usredotočene su na lean razvoj softvera i pomažu u izgradnji boljeg softvera učinkovito i djelotvorno.

To je sve s Agile Uvodom. Dio je strukturiran tako da vam pomogne razumjeti osnovne vrijednosti i principe koji će se usvojiti za tim koji će raditi u agilnom načinu i načinu razmišljanja.

Okretan Metodologija

Uvod u agilne modele:

Agilna metodologija

što statička analiza ne može naći

Kao što svi znamo, Agile je metodologija razvoja softvera.

Također smo naučili o vrijednostima i načelima koje su osnivači agilnog spomenuli u agilnom manifestu. U našim početnim raspravama također smo se osvrnuli na razlike između okretnih i tradicionalnih modela vodopada.

U ovom uputstvu upoznat ćemo se s prednostima i nedostacima agilne metodologije.

Vidjet ćemo što je scrum? i po čemu se razlikuje od okretnog. Tada ćemo razumjeti razne agilne metodologije koje se koriste u različitim organizacijama i kako možemo primijeniti agilne koristeći ih.

Također ćete moći uvidjeti razliku, a također i prednosti / nedostatke ovih metodologija.

Prednosti agilne metodologije

Slijede razne prednosti Agile metodologije:

  • Kupci kontinuirano dobivaju uvid u napredak projekta na kraju svake iteracije / sprinta.
  • Svaki sprint pruža kupcu radni softver koji udovoljava njihovim očekivanjima prema definiciji gotovog posla.
  • Razvojni timovi prilično reagiraju na promjenjive zahtjeve i mogu prilagoditi promjene čak i u naprednim fazama razvoja.
  • Stalna je dvosmjerna komunikacija koja uključuje kupce, tako da svi dionici - poslovni i tehnički - imaju jasnu vidljivost napretka projekta.
  • Dizajn proizvoda je učinkovit i udovoljava poslovnim zahtjevima.

Mane agilne metodologije

Iako postoji nekoliko prednosti Agile metodologije, postoje i određeni nedostaci.

Oni su:

# 1) Nije poželjna sveobuhvatna dokumentacija što može dovesti do toga da agilni timovi pogrešno interpretiraju ovo jer agilni ne zahtijeva dokumentaciju. Tako se strogost gubi na dokumentaciji. To bi trebalo izbjegavati neprestanim pitanjem jesu li ovo dovoljne informacije za nastavak ili ne.

#dva) Ponekad, na početku projekata, zahtjevi nisu kristalno jasni. Timovi bi mogli nastaviti i otkriti da se vizija kupaca preoblikovala i u takvim situacijama timovi moraju ugraditi mnoge promjene, a teško je izmjeriti i krajnji rezultat.

Vrste agilnih metodologija

U praksi postoji nekoliko agilnih metodologija u svijetu. Detaljnije ćemo saznati o četiri najpopularnija.

Vrste agilnih metodologija

# 1) Scrum

Scrum se lako može smatrati najpopularnijim agilnim okvirom. Većina praktičara izraz 'okršaj' smatra sinonimom za 'okretan'. Ali to je zabluda. Scrum je samo jedan od okvira pomoću kojih možete implementirati agilnost.

Riječ scrum dolazi od sportskog ragbija. Gdje se igrači skupljaju u međusobno povezanom položaju gurajući protiv protivnika. Svaki igrač ima definiranu ulogu u svom položaju i može igrati i ofenzivu i defenzivu prema zahtjevu situacije.

Slično tome, prepirka u IT-u vjeruje u osnažene samoupravne razvojne timove s tri specifične i jasno definirane uloge. Te uloge uključuju - Vlasnik proizvoda (PO), Scrum Master (SM) i razvojni tim koji se sastoji od programera i testera . Zajedno rade u iterativnim vremenskim okvirima koji se nazivaju sprinti.

Prvi korak je stvaranje zaostalih proizvoda od strane tužilaštva. To je popis obveza koje mora obaviti scrum tim. Tada scrum tim odabire stavke s najvišim prioritetom i pokušava ih dovršiti u roku koji se naziva sprint.

Jednostavniji način pamćenja svega ovoga je pamćenje okvira 3-3-5. To znači da scrum projekt ima 3 uloge, 3 artefakta i 5 događaja.

Ovi su -

Uloge: PO, Scrum majstor i razvojni tim.

Artefakti: Zaostatak proizvoda, Sprint zaostatakiPrirast proizvoda.

Događaji: Sprint, planiranje sprinta, dnevni skrum, pregled sprinta i retrospektiva sprinta.

3-3-5 okvir

O svakom od njih detaljnije ćemo se upoznati u našim sljedećim vodičima.

# 2) Kanban

Kanban je japanski izraz koji znači karta. Te kartice sadrže detalje o radu na softveru. Svrha je vizualizacija. Svaki član tima svjestan je posla koji treba obaviti putem ovih vizualnih pomagala.

Timovi koriste ove Kanban kartice za kontinuiranu isporuku. Baš kao i Scrum, Kanban također pomaže timovima da rade učinkovito i promovira samoupravne i suradničke timove.

Ali postoje razlike i između ove dvije - kao tijekom sprint sprinta, predmeti na kojima radi tim su fiksni i ne možemo dodavati stavke u sprint, dok u Kanbanu možemo dodavati stavke ako ima slobodnih kapaciteta. To je osobito korisno kada se zahtjevi često mijenjaju.

Slično tome, druga je razlika u tome što iako scrum ima definirane uloge PO-a, master scruma i razvojnih timova, u Kanbanu nema takvih unaprijed definiranih uloga.

Druga je razlika u tome što iako scrum sugerira prioritet zaostataka proizvoda, Kanban nema takav zahtjev i potpuno je neobavezan. Stoga Kanban zahtijeva manje organizacije i izbjegava aktivnosti bez dodavanja vrijednosti te je pogodan za procese koji zahtijevaju reakciju na promjene.

# 3) mršav

Lean je filozofija koja se fokusira na smanjenje otpada. Kako to čini?

U lean-u proces dijelite na aktivnosti s dodanom vrijednošću, aktivnosti bez dodavanja vrijednosti i osnovne aktivnosti bez dodavanja vrijednosti. Svaka aktivnost koja se može klasificirati kao aktivnost bez dodavanja vrijednosti otpad je i trebali bismo pokušati ukloniti taj otpad u procesu kako bismo ga učinili vitkijim.

Laganiji postupak znači bržu isporuku i manje truda koji se troši na zadatke koji ne pomažu u postizanju ciljeva tima. To pomaže optimizirati svaki korak u ciklusu razvoja softvera. Zbog toga su principi vitkosti prilagođeni od lean proizvodnje u razvoj softvera.

Lean razvoj softvera može se koristiti u bilo kojem IT projektu primjenom sedam lean principa koji su prikazani u nastavku:

sedam vitkih principa

To su sasvim razumljivo kako sugeriraju njihova imena. Eliminiranje rasipanja prvo je i najvažnije vitko načelo i vidjeli smo kako to učiniti, samo klasificiramo aktivnosti kao dodatak vrijednosti i ne-vrijednosti.

Aktivnost bez dodavanja vrijednosti može biti bilo koji dio koda koji ga može učiniti manje robusnim, povećati napor i oduzeti puno vremena, a pritom ne dodaje opravdanu poslovnu vrijednost. To također mogu biti nejasne korisničke priče ili loše testiranje ili dodavanje značajki koje nisu potrebne u širokoj slici.

Drugi princip koji pojačava učenje opet je lako razumjeti jer timu trebaju razne vještine za isporuku proizvoda u brzo mijenjajućem okruženju s novim tehnologijama koje se brzo pojavljuju.

Donošenje kasnih odluka može biti korisno u okolnostima kada smanjuje preradu, na primjer ako se očekuju bilo kakve promjene, onda je bolje odgoditi tako da tim ne mora ponavljati posao jer se posao mijenja.

Ali ovdje uvijek postoji kompromis jer timovi to moraju uskladiti s četvrtim principom brže isporuke. Odgađanje odluka ne bi trebalo utjecati na cjelokupnu isporuku i ne smije smanjiti tempo rada. Jedno oko uvijek treba biti upereno u cjelovitu sliku.

Osnaživanje timova također je danas vrlo često, a to čak i agilni sugeriraju. Osnaženi timovi odgovorniji su i brže mogu donositi odluke. Osjećaj vlasništva u osnaženom timu dovodi do boljih rezultata. Da bi osnažili tim, treba im omogućiti da se sami organiziraju i samostalno donose odluke.

Stoga vidimo da vitki i okretni imaju mnogo toga zajedničkog s jednom oštrom razlikom - dok mršavi timovi mogu pomoći u pročišćavanju proizvoda, okretni timovi su ti koji zapravo proizvode proizvod.

# 4) Ekstremno programiranje (XP)

Ekstremno programiranje je još jedna od najpopularnijih agilnih tehnika. Kao i prema extremeprogramming.org, prvi XP projekt pokrenut je 6. ožujka 1996. Oni također spominju kako XP utječe na razvoj softverskih projekata na 5 različitih načina - komunikacijom, jednostavnošću, povratnom informacijom, poštovanjem i hrabrošću. To se nazivaju vrijednosti XP.

Od toga, sve započinje komunikacijom. XP timovi redovito surađuju s poslovnim timovima i kolegama programerima i započinju s izradom koda od prvog dana. Ovdje je fokus na komunikaciji licem u lice što je više moguće uz pomoć ostalih vizualnih pomagala.

Ekstremni programeri također grade jednostavan kôd i počinju dobivati ​​povratne informacije o njemu od prvog dana. Fokus je na ne pretjerivanju ili predviđanju zahtjeva koji nisu podijeljeni. To pojednostavljuje dizajn i daje samo minimalni proizvod koji će zadovoljiti zahtjeve.

Povratne informacije pomažu timu da poboljša i proizvede bolju kvalitetu rada. To im pomaže u izgradnji međusobnog poštovanja dok uče jedni od drugih i uče kako dijeliti svoje stavove.

To im također daje hrabrost jer znaju da su prikupili svačije najbolje ideje i proizveli dobar proizvod s povratnim informacijama drugih. Stoga se također ne boje uključiti promjene ili dobiti daljnje povratne informacije o svom radu.

To je osobito korisno u projektima u kojima će se zahtjevi često mijenjati. Stalne povratne informacije pomoći će timovima da hrabro uključe ove promjene.

Stoga smo vidjeli različite agilne metodologije poput Scrum, XP, Kanban i Lean, zajedno s njihovim prednostima i nedostacima.

Sada ih možemo lako razlikovati i uvažiti suptilnije razlike među njima. Također smo naučili osnove svake od ovih metodologija i vidjeli kako ih primijeniti u našim projektima prema potrebi i kada je to potrebno.

U sljedećem dijelu, shvatimo sve o Scrumu.

Scrum metodologija

SCRUM je postupak u agilnoj metodologiji koji je kombinacija iterativnog modela i inkrementalnog modela.

Jedan od glavnih hendikepa tradicionalnog Model slapa bilo je to - dok prva faza ne završi, aplikacija se ne prebacuje u drugu fazu. I slučajno, ako postoje neke promjene u kasnijoj fazi ciklusa, postaje vrlo izazovno provesti te promjene, jer bi to uključivalo ponovni pregled ranijih faza i ponovnu promjenu.

Agilno testiranje skruma

Neke od ključnih karakteristika SCRUM-a uključuju:

  • Samoorganizirani i fokusirani tim.
  • Nema ogromnih zahtjeva, već imaju vrlo precizne i precizne priče.
  • Višefunkcionalni timovi rade zajedno kao jedna cjelina.
  • Bliska komunikacija s predstavnikom korisnika radi razumijevanja značajki.
  • Ima određeni vremenski okvir od najviše mjesec dana.
  • Umjesto da radi cijelu 'stvar' odjednom, Scrum radi malo svega u zadanom intervalu.
  • Prije nego što počinite bilo što, uzimaju se u obzir sposobnost i dostupnost resursa.

Da biste dobro razumjeli ovu metodologiju, važno je razumjeti ključne terminologije u SCRUM-u.

Također pročitajte => Kako isporučiti značajke softvera visoke vrijednosti u kratkom vremenskom razdoblju pomoću Agile Scrum procesa

Važne SCRUM terminologije

1) Scrum tim

Scrum tim je tim koji se sastoji od 7 članova sa + ili - dva člana. Ti su članovi kombinacija kompetencija i sastoje se od programera, testera, ljudi iz baze podataka, ljudi koji podržavaju itd., Zajedno s vlasnikom proizvoda i scrum masterom.

Svi ti članovi rade u tijesnoj suradnji u rekurzivnom i određenom intervalu kako bi razvili i implementirali spomenute značajke. Raspored sjedenja u timu SCRUM-a igra vrlo važnu ulogu u njihovoj interakciji, oni nikad ne sjede u kabinama ili kabinama, već ogromnom stolu.

Scrum tim

2) Sprint

Sprint je unaprijed definirani interval ili vremenski okvir u kojem se posao mora dovršiti i pripremiti za pregled ili za proizvodnju. Ovaj vremenski okvir obično leži između 2 tjedna i 1 mjeseca.

web stranice koje omogućuju preuzimanje YouTube videozapisa

U našem svakodnevnom životu kada kažemo da slijedimo jednomjesečni Sprint ciklus, to jednostavno znači da radimo jedan mjesec na zadacima i pripremimo ga za pregled do kraja tog mjeseca.

3) Vlasnik proizvoda

Vlasnik proizvoda je ključni dionik ili vodeći korisnik aplikacije koju treba razviti. Vlasnik proizvoda je osoba koja zastupa kupca. On / ona ima konačni autoritet i uvijek bi trebao biti na raspolaganju timu.

Morao bi biti dostupan / a kad bilo tko sumnja u potrebno pojašnjenje. Vlasnik proizvoda važno je razumjeti i ne dodijeliti novi zahtjev usred sprinta ili kada je sprint već započeo.

4) Scrum majstor

Scrum Master je voditelj scrum tima. On / ona osigurava da scrum tim bude produktivan i napredan. U slučaju bilo kakvih prepreka, scrum master prati i rješava ih za tim. SCRUM Master je posrednik između OP-a i tima.

On / ona redovito izvještava PO o napretku sprinta. Ako postoje prepreke ili zabrinutost za tim, razgovara s PO-om i rješava ih. Kao i svakodnevni standup tima, standup SCRUM Master-a s PO događa se svaki dan.

Preporučeno čitanje => Kako biti dobar mentor, trener i istinski tim-branitelj u agilnom svijetu testiranja?

5) Poslovni analitičar (BA)

Poslovni analitičar igra vrlo važnu ulogu u SCRUM-u. Ova je osoba odgovorna za finaliziranje i izradu zahtjeva u dokumentima sa zahtjevima (na temelju kojih se kreiraju korisničke priče).

Ako postoje nejasnoće u korisničkim pričama / kriterijima prihvaćanja, on / ona je taj kojem se obraća tehnički (SCRUM) tim i on ga zatim prebacuje u narudžbenicu ili, ako je moguće, sam rješava. U velikim projektima može biti više od 1 BA, ali u malim projektima SCRUM Master može djelovati i kao BA.

Uvijek je dobra praksa imati BA kada započne projektni udarac.

6) Korisnička priča

Priče korisnika nisu ništa drugo do zahtjevi ili značajke koje se moraju implementirati.

U dosadašnjoj raspravi nemamo te ogromne dokumente sa zahtjevima, nego su zahtjevi definirani u jednom odlomku, koji obično ima oblik:

Kao
želim
Postići

Na primjer :

Kao administrator želim zaključavanje lozinkom u slučaju da korisnik tri puta uzastopno unese netočnu lozinku kako bi ograničio neovlašteni pristup.

Postoje neke karakteristike korisničkih priča kojih se treba pridržavati. Korisničke priče trebaju biti kratke, realne, mogu se procijeniti, cjelovite, dogovorene i provjerljive. Korisnička priča se nikada ne mijenja ili mijenja usred Sprinta.

Odgovornost je SCRUM Master-a i BA-a (ako je primjenjivo) osigurati da je PO ispravno izradio korisničke priče s odgovarajućim skupom kriterija prihvaćanja. ' Ako se naprave neke promjene koje će utjecati na izdanje sprinta, tada se takve priče izvlače iz sprinta ili se rade prema dostupnim satima.

Svaka korisnička priča ima kriterij prihvaćanja koji bi tim trebao dobro definirati i razumjeti.

Kriteriji prihvaćanja detaljno opisuju korisničku priču koja pruža prateću dokumentaciju. Pomaže u daljnjem pročišćavanju korisničke priče. Svatko iz tima može zapisati kriterije prihvaćanja. Ispitni tim zasniva svoje test slučajeve / uvjete na tim kriterijima prihvaćanja.

7) Epovi

Epovi su nedvosmislene korisničke priče ili možemo reći da su to korisničke priče koje nisu definirane i čuvaju se za buduće sprinteve.

Pokušajte to povezati sa životom, zamislite da idete na odmor. Kako idete sljedeći tjedan, sve je na vašem mjestu, kao što su hotelske rezervacije, razgledavanje grada, putnički ček itd. Ali što je s vašim planom odmora za sljedeću godinu? Imate samo nejasnu ideju da biste mogli otići do mjesta XYZ, ali nemate detaljan plan.

Epic je sličan vašem planu godišnjeg odmora za iduću godinu, gdje jednostavno znate da biste možda željeli ići, ali gdje, kada, s kim, sve ove detalje u ovom trenutku nemate pojma.

Na sličan način postoje značajke koje se trebaju implementirati u budućnosti čiji detalji još nisu poznati. Uglavnom neka značajka započinje s Epom, a zatim se raščlanjuje na priče koje bi se mogle provesti.

8) Zaostatak proizvoda

Zaostaci proizvoda svojevrsna su skupina ili izvor u kojem se čuvaju sve korisničke priče. To održava Vlasnik proizvoda. Zaostatak proizvoda može se zamisliti kao popis želja vlasnika proizvoda koji mu daje prednost prema poslovnim potrebama.

Tijekom sastanka o planiranju (vidi sljedeći odjeljak), jedna se korisnička priča preuzima iz zaostatka proizvoda, a zatim tim razmatra, razumije i dorađuje te zajednički odlučuje koje će korisničke priče poduzeti, uz intervenciju vlasnika proizvoda.

9) Sprint zaostatak

Na temelju prioriteta, korisničke su priče preuzete iz zaostataka proizvoda kao jedna po jedna. Scrum tim mozga na njemu određuje izvedivost i odlučuje o pričama koje će raditi na određenom sprintu. Skupni popis svih korisničkih priča koje scrum tim radi na određenom sprintu poznat je kao Sprint zaostatak.

Zaostatak u sprintu

10) bodovi u priči

Točke priče kvantitativni su pokazatelj složenosti korisničke priče. Na temelju točke priče utvrđuju se procjene i napori za priču.

Poanta priče je relativna, a ne apsolutna. Kako bismo bili sigurni da su naša procjena i napori točni, važno je provjeriti jesu li korisničke priče velike. Što je korisnička priča preciznija i manja, to će procjena biti točnija.

Svaka korisnička priča dodijeljena je točki priče temeljenoj na Fibonaccijevoj seriji (1, 2, 3, 5, 8, 13 i 21). Što je veći broj, kompleks je priča.

Biti precizan

  • Ako navedete 1/2/3 priče, znači da je priča mala i male složenosti.
  • Ako bodove dajete kao 5/8, to je srednje složen i
  • 13 i 21 vrlo su složeni.

Ovdje se složenost sastoji i od razvoja i od napora na testiranju.

Da bi se odlučilo o priči, mozga se događa unutar scrum tima i tim zajednički odlučuje o priči.

Može se dogoditi da razvojni tim daje priču od 3 određenoj priči, jer za njih to mogu biti 3 retka promjene koda, ali tim za testiranje daje 8 priča, jer smatraju da će ova promjena koda utjecati na veće module pa napor bi bio veći. Koju god priču izgovarate, morate je opravdati.

Dakle, u ovoj se situaciji događa moždana oluja i tim se kolektivno slaže s jednom pričom.

Kad god se odlučite za priču, imajte na umu sljedeće čimbenike:

  • Ovisnost priče s drugom aplikacijom / modulom.
  • Skup vještina resursa.
  • Složenost priče.
  • Povijesno učenje.
  • Kriteriji prihvaćanja korisničke priče.

Ako niste svjesni određene priče, nemojte je uvećavati.

Kad god je priča = ili> 8 bodova, ona se raščlanjuje na 2 ili više priča.

11) Spalite grafikon

Grafikon sagorijevanja grafikon je koji prikazuje procijenjeni v / s stvarni napor scrum zadataka.

To je mehanizam praćenja pomoću kojeg se za određeni sprint prate svakodnevni zadaci kako bi se provjerilo napreduju li priče prema završetku predanih točaka priče ili ne.

Primjer : Da biste to razumjeli, pogledajte donju sliku:

Burn Down grafikon 1

Pretpostavio sam:

  • 2 tjedna sprinta (10 dana)
  • 2 resursa koji stvarno rade na sprintu.

'Priča' -> Ovaj stupac prikazuje korisničke priče uzete za sprint.

'Zadatak' -> Ovaj stupac prikazuje popis zadatka povezanih s korisničkom pričom.

'Napor' -> Ovaj stupac prikazuje napor. Sada je ova mjera ukupan napor za izvršavanje zadatka. Ne prikazuje napor koji ulaže bilo koja određena osoba.

'1. dan - 10. dan' -> Ovaj stupac prikazuje sate koji su preostali za dovršavanje priče. Molimo pripazite da sat NIJE sat koji je već gotov, već sati koji su još preostali.

'Procijenjeni napor' -> Je li ukupan napor. Za 'Start' to je jednostavno zbroj cjelokupnog pojedinačnog zadatka: ZBOR (C5: C15)

Ukupan broj napora koji treba obaviti za jedan dan je 70/10 = 7. Dakle, na kraju dana 1, napor bi se trebao smanjiti na 70 - 7 = 63. Na sličan način, izračunava se za sve dana do 10. dana, kada bi procijenjeni napor trebao biti 0 (red 16)

'Stvarni napor lijevo' -> Kao što i samo ime govori, je li zapravo preostalo truda da se priča dovrši. Također se može dogoditi da se stvarni napori povećaju ili smanje od procijenjenog.

Možete koristiti ugrađene funkcije i Grafikon u Excelu za izradu ovog sažetog grafikona.

Koraci izgaranja grafikona bili bi:

  1. Unesite sve priče (Stupac A5 - A15).
  2. Unesite sve zadatke (stupac B5 - B15).
  3. Unesite dane (1. dan - 10. dan).
  4. Unesite početne napore (zbrojite zadatke C5 - C15).
  5. Primijenite formulu za izračun „Procijenjenih napora“ za svaki dan (1. do 10. dan). Unesite formulu na D15 (C16 - 16 C $ / 10) i povucite je za sve dane.
  6. Za svaki dan unesite stvarne napore. Unesite formulu na D17 (SUM (D5: D15)) za sažimanje stvarnih preostalih napora i povucite je za sve ostale dane.
  7. Odaberite ga i stvorite grafikon kako slijedi:

Burn Down grafikon 2

12) Brzina

Ukupan broj točaka priče koje scrum tim arhivira u sprintu naziva se brzina. Scrum tim ocjenjuje se ili se na njega referira prema njegovoj brzini. Imajući to u vidu, treba imati na umu da ovdje cilj NIJE postizanje maksimalnih bodova iz priče, već postizanje kvalitetne isporuke, poštujući razinu udobnosti scrum tima.

Na primjer : Za određeni sprint: ukupan broj korisničkih priča je 8 koji imaju bodove kao što je prikazano u nastavku.

Scrum brzina

Dakle, ovdje će brzina biti zbroj bodova priče = 30

Definicija Gotovo:

Sprint je označen kao Gotovo kada su sve priče dovršene, svi programi, zadaci za razvoj, QA označeni su kao 'Dovršeni', sve su pogreške fiksno zatvorene, a one koje se mogu kasnije (poput nisu u potpunosti povezane ili su manje važne) izvučeni su i dodani u zaostatke, pregled koda i testiranje jedinice su završeni, procijenjeni sati ispunili su stvarne sate postavljene u zadacima i što je najvažnije uspješan demo prikazan je organizacijskoj jedinici i dionicima.

Aktivnosti obavljene u SCRUM metodologiji

# 1) Sastanak za planiranje

Sastanak za planiranje polazna je točka Sprinta. To je sastanak na kojem se okuplja cijeli scrum tim, SCRUM Master odabire korisničku priču na temelju prioriteta iz zaostalih proizvoda i timskog mozga na njoj.

Na temelju rasprave, scrum tim odlučuje o složenosti priče i određuje je prema Fibonaccijevoj seriji. Tim identificira zadatke zajedno s naporima (u satima) koji bi se poduzeli kako bi se dovršila implementacija korisničke priče.

Često sastanku za planiranje prethodi „sastanak pred planiranje“. Baš je poput domaće zadaće koju scrum tim radi prije nego što sjedne na službeni sastanak za planiranje. Tim pokušava zapisati ovisnosti ili druge čimbenike o kojima bi želio razgovarati na sastanku o planiranju.

# 2) Izvršenje sprint zadataka

Kao što i samo ime govori, ovo je stvarni posao koji je scrum tim obavio kako bi izvršio svoj zadatak i odveo korisničku priču u stanje 'Gotovo'.

# 3) Dnevni standup

Tijekom sprint ciklusa, svaki dan scrum tim sastaje se, ne više od 15 minuta (može biti stand-up poziv, preporučuje se tijekom dana) i navodi 3 boda:

  1. Što je član tima radio jučer?
  2. Što je član tima planirao učiniti danas?
  3. Ima li zapreka (zapreka)?

Scrum majstor je taj koji vodi ovaj sastanak. U slučaju da se bilo koji član tima suoči s bilo kakvim poteškoćama, scrum master prati kako bi ga riješio. U Stand up-ima odbor se također pregledava i sam po sebi pokazuje napredak tima.

# 4) Pregled sastanka

Na kraju svakog sprint ciklusa, tim SCRUM-a ponovno se sastaje i demonstrira implementirane korisničke priče vlasniku proizvoda. Vlasnik proizvoda može unakrsno provjeriti priče prema kriterijima prihvaćanja. Ponovno je odgovornost gospodara Scruma da predsjeda ovim sastankom.

Također u alatu SCRUM, Sprint je zatvoren i zadaci su označeni kao gotovi.

# 5) Retrospektivni sastanak

Retrospektivni sastanak događa se nakon sastanka za reviziju.

Tim SCRUM-a sastaje se, raspravlja i dokumentira sljedeće točke:

  • Što je dobro prošlo tijekom Sprinta (Najbolji primjeri iz prakse)?
  • Što nije dobro prošlo u Sprintu?
  • Naučene lekcije
  • Akcijske stavke.

Scrum tim bi trebao nastaviti slijediti najbolju praksu, zanemariti 'ne najbolje prakse' i provoditi lekcije naučene tijekom sljedećih sprintova. Retrospektivni sastanak pomaže u provedbi kontinuiranog poboljšanja SCRUM postupka.

Kako se radi postupak? Primjer!

Pročitavši tehničke žargone SCRUM-a. dopustite mi da pokušam demonstrirati cijeli postupak na primjeru.

Primjer:

Korak 1 : Imajmo SCRUM tim od 9 ljudi koji se sastoji od 1 vlasnika proizvoda, 1 Scrum master, 2 testera, 4 programera i 1 DBA.

Korak 2 : Za Sprint je odlučeno da slijedi četverodjedni ciklus. Tako imamo 1-mjesečni Sprint od 5. lipnja do 4. godinethsrpnja.

Korak # 3 : Vlasnik proizvoda ima prioritetni popis korisničkih priča u zaostatku proizvoda.

Korak # 4: Tim se odlučuje sastati 4thLipnja za sastanak 'Predplaniranje'.

  • Vlasnik proizvoda uzima 1 priču iz zaostatka proizvoda, opisuje je i prepušta timu da o njoj razmišlja.
  • Cijeli tim razgovara i izravno komunicira s vlasnikom proizvoda kako bi jasno razumio korisničku priču.
  • Na sličan način uzimaju se i razne druge korisničke priče. Ako je moguće, tim može nastaviti i prilagođavati priče.

Nakon svih rasprava, pojedini se članovi tima vraćaju na svoje radne stanice i

  • Utvrdite njihove pojedinačne zadatke za svaku priču.
  • Izračunajte točan broj sati na kojima će raditi. Provjerimo kako član zaključuje ovo radno vrijeme.

Ukupan broj radnih sati = 9
Minus 1 sat za stanku, minus 1 sat za sastanke, minus 1 sat za e-poštu, rasprave, rješavanje problema itd.
Dakle, stvarno radno vrijeme = 6.
Ukupan broj radnih dana tijekom Sprinta = 21 dan.
Ukupan broj sati na raspolaganju = 21 * 6 = 126.
Član je na dopustu 2 dana = 12 sati (ovo se razlikuje za svakog člana, neki mogu uzeti dopust, a neki ne.)
Broj stvarnih sati = 126 - 12 = 114 sati.

To znači da će član zapravo biti dostupan 114 sati za ovaj sprint. Tako će razbiti svoj pojedinačni sprint zadatak na takav način da se postigne ukupno 114 sati.

Korak # 5 : 5.thlipnja cijeli Scrum tim sastaje se na „sastanku planiranja“.

  • Konačna je presuda o korisničkoj priči iz zaostalih proizvoda i priča je premještena u Sprint Backlog.
  • Za svaku priču svaki član tima izjavljuje svoje identificirane zadatke, ako je potrebno, može razgovarati o tim zadacima, može ih povećati ili promijeniti veličinu (sjetite se Fibonaccijeve serije !!).
  • Scrum majstor ili tim unose svoje pojedinačne zadatke zajedno sa svojim satima za svaku priču u alat.
  • Nakon što su sve priče dovršene, Scrum majstor bilježi početnu brzinu i formalno pokreće Sprint.

Korak # 6 : Nakon što je Sprint započeo, na temelju dodijeljenih zadataka, svaki član tima započinje s radom na tim zadacima.

Korak # 7 : Tim se sastaje svakodnevno po 15 minuta i razgovara o 3 stvari:

  • Što su učinili jučer?
  • Što planiraju učiniti danas?
  • Ima li zapreka (zapreka)?

Korak # 8 : Scrum master svakodnevno prati napredak uz pomoć 'Burn down chart'.

Korak # 9 : U slučaju bilo kakvih zapreka, Scrum master prati kako bi ih riješio.

Korak # 10 : Dana 4thSrpnja, tim se ponovno sastaje na sastanku za reviziju. Član demonstrira implementiranu korisničku priču vlasniku proizvoda.

Korak # 11 : Dana 5thSrpnja, Tim se ponovno sastaje na Retrospektivi, gdje razgovaraju

  • Što je dobro prošlo?
  • Što nije dobro prošlo?
  • Akcijske stavke.

Korak # 12 : Dana 6thSrpnja, tim se ponovno sastaje na sastanku prije planiranja za sljedeći sprint i ciklus se nastavlja.

scrum agilni postupak metodologije

SCRUM Alati aktivnosti

Postoji nekoliko alata koji se mogu opsežno koristiti za praćenje scrum aktivnosti.

Neki od njih uključuju:

U nadolazećem uputstvu rasvjetljavat ćemo Agile manifest koji je pojam koji pokreće učinkovite Agile timove.

Sljedeći vodič

O autorima: Ovu seriju napisali su sljedeći članovi STH tima: Shruti Shrivastava - profesionalni Scrum majstor s 9 godina iskustva u BFSI, e-trgovini i B2B domenama. Shruti je stručnjak za automatizaciju i vođenje scrum timova.

Anshul Kumar Srivastava - Stručnjak za upravljanje proizvodima usmjeren na rezultate i okretan praktičar sa 7 godina iskustva u BFSI i Telecom sektorima.

Preporučena literatura

^