Menu

Agile Methodology: A Beginner's Guide To Agile Method and Scrum

agile methodology beginner s guide agile method

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Kompletní průvodce po agilní metodice: (20+ podrobných výukových programů pro agilní scrum)

Toto je průvodce pro vývojáře softwaru a testery, jak porozumět a začít pracovat na velmi slavných Agilní metodika SCRUM pro vývoj a testování softwaru . Naučte se základní, ale důležité terminologie používané v procesu Agile Scrum spolu se skutečným příkladem celého procesu.

Pro vaše pohodlí jsme uvedli všechny agilní výukové programy v této sérii. Doufám, že vám budou nesmírně nápomocni.

Pokrytá témata: Co je to Agile, Co je Scrum, Agilní metodika ve vývoji a testování softwaru, Agilní testování, Agilní proces ve Scrumu, Metoda ve Scrumu se Scrum Teamem a Scrum Masterem.

úvod do agilního vývoje

Co se naučíte:

Seznam výukových programů pro agilní metodiku

Výukový program č. 1: Agilní metodiky scrumu (Tento návod)
Výukový program č. 2: Agilní manifest
Výukový program č. 3: Scrum Team a jejich role a odpovědnosti
Výukový program č. 4: Scrum artefakty
Výukový program č. 5: Scrum události
Výukový program č. 6: Porucha třídění ve skrumáži
Výukový program č. 7: Soběstačné Scrum týmy
Výukový program č. 8: Princip tří Amigo
Výukový program č. 9: SAFe - Škálovaný agilní rámec
Výukový program č. 10: Agilní scrum kvíz

DALŠÍ Doporučené výukové programy pro agilní scrum:

Výukový program č. 11: Nejlepší techniky agilního odhadu
Výukový program č. 12: Hybridní model Agile Waterfall
Výukový program č. 13: Kanban vs Scrum vs Agile
Výukový program č. 14: Výukový program JIRA Agile
Výukový program č. 15: Agilní retrospektivní setkání
Výukový program č. 16: Role obchodních analytiků ve SCRUM
Výukový program č. 17: Role QA ve skrumáži

Nástroje a otázky k rozhovoru:

Výukový program č. 18: Agilní testovací nástroje
Výukový program č. 19: Nejlepší agilní nástroje pro správu projektů
Výukový program č. 20: Nejlepší otázky týkající se agilního rozhovoru
Výukový program č. 21: Nejlepší otázky týkající se rozhovoru se skrumáží

Začněme prvním tutoriálem v sérii - Agile Scrum Introduction.

Úvod do agilního rozvoje

Agilní vývoj softwaru:

Agile je jedním z nejpoužívanějších a nejuznávanějších frameworků pro vývoj softwaru na světě.

Většina organizací ji přijala v nějaké formě, ale do vyspělosti svých programů adopce zbývá ještě dlouhá cesta. Jediným cílem této série výukových programů je zapojit technologické a netechnologické profesionály do světa Agile World.

Provedeme vás agilní cestou krok za krokem, dokud nepochopíte filozofii používání Agile, její výhody a jak ji procvičovat. Tato série si klade za cíl vybavit a umožnit čtenářům aplikovat Agile a Scrum učení do své práce.

Tento konkrétní tutoriál je věnován vysvětlení, proč byl Agile potřeba a jak byl vytvořen. Základem je porozumět konceptu Agile Adoption v Software Development Industries.

Historie agile

Agile se narodil, když se jednoho krásného dne, kdy 17 lidí s odlišnými vývojovými metodologickými znalostmi, dalo dohromady brainstorming, pokud by existovalo možné alternativní řešení vývoje softwaru, které by mohlo vést k rychlejší době vývoje a bylo méně náročné na dokumentaci.

V té době k vývoji softwaru docházelo tak dlouho, že v době, kdy byly projekty připraveny k dodání, se podnikání posunulo kupředu a požadavky se změnily. Projekt tedy nebyl schopen splnit obchodní potřeby, i když byl schopen splnit stanovené cíle.

Tito šampióni v různých technikách softwarového inženýrství se tedy dali dohromady a konečným výsledkem jejich setkání bylo to, čemu říkali „agilní manifest“, o kterém budeme podrobně diskutovat v dalším tutoriálu této série.

Agilita, která se toho dne zrodila, však není to, co dnes vidíme v organizacích. Metodika, na které se odborníci shodli, byla popsána jako „lehká“ a rychlá. Hlavním úspěchem tohoto setkání však byla myšlenka, že rychlejší dodání produktu a neustálá zpětná vazba jsou klíčem k dosažení úspěchu ve vývoji softwaru.

Stávající techniky vodopádů byly příliš těžkopádné a neměly žádné opatření pro zpětnou vazbu, dokud nebyl konečný produkt připraven k dodání. To znamenalo, že neexistoval prostor pro korekci kurzu a zákazník neměl žádný přehled o pokroku, dokud nebyl připraven celý produkt. A tomu se tito odborníci chtěli vyhnout.

Chtěli řešení, které by mělo prostor pro neustálou zpětnou vazbu, aby se zabránilo nákladům na přepracování v pozdější fázi.

Agilní výzvy

Stávající techniky vodopádů v té době byly příliš těžkopádné a neměly žádné ustanovení o zpětné vazbě, dokud nebyl konečný produkt připraven k dodání. Říkalo se tomu vodopádový model rozvoje, protože týmy nejprve dokončily jeden krok úplně a teprve poté přešly k dalšímu kroku.

To znamenalo, že neexistoval prostor pro korekci kurzu a zákazník neměl žádný přehled o pokroku, dokud nebyl připraven celý produkt. A tomu se tito odborníci chtěli vyhnout. Chtěli řešení, které by mělo prostor pro neustálou zpětnou vazbu, aby se zabránilo nákladům na přepracování v pozdější fázi.

A proto je agilní také o adaptivitě a neustálém zlepšování, stejně jako o neustálé zpětné vazbě a rychlosti doručení.

Co jsou agilní sliby?

Agilní sliby

Agile není jen o aplikaci stanovených postupů při vývoji softwaru. Přináší také změnu v myšlení týmu, která je vede k vytváření lepšího softwaru, spolupráci a nakonec jim přináší šťastného zákazníka.

Agilní hodnoty a principy umožňují týmu přesunout své zaměření a změnit svůj myšlenkový proces budování lepšího softwaru.

Co přesně je agilní?

Agile není soubor pravidel. Agile není soubor pokynů. Agile není ani metodika. Agile je spíše souborem principů, které podporují flexibilitu, přizpůsobivost, komunikaci a pracovní software nad plány a procesy. Je velmi stručně zachycen v tzv. Agilním manifestu.

Agilní vývoj softwaru umožňuje týmu efektivněji a efektivněji spolupracovat na vývoji složitých projektů. Skládá se z postupů, které provádějí iterační a přírůstkové techniky, které jsou snadno přijatelné a vykazují skvělé výsledky.

Při aplikaci Agile do akce máme různé metody a metodiky založené na Agile. Tyto metody a metodiky uspokojují všechny potřeby odvětví vývoje softwaru, od návrhu a architektury softwaru, vývoje a testování až po řízení projektů a dodávky.

Agilní metody a metodiky nejen otevírají prostor pro zlepšování procesů jako nedílnou součást každé dodávky.

Agile je přístup k vývoji softwaru, při kterém soběstačný a křížově funkční tým pracuje na neustálých dodávkách prostřednictvím iterací a v průběhu procesu se vyvíjí shromažďováním zpětné vazby od koncových uživatelů.

Jak cvičit agilní?

V různých diverzifikovaných průmyslových odvětvích existují v praxi různé agilní metodiky.

agilní metodiky

Mezi nejoblíbenější metodiky však patří:

  • Skrumáž
  • Kanban
  • Extrémní programování

Všechny tyto metodiky se zaměřují na vývoj štíhlého softwaru a pomáhají efektivně a efektivně vytvářet lepší software.

To je vše s Agilním úvodem. Část je strukturována tak, aby vám pomohla porozumět základním hodnotám a zásadám, které budou přijaty, aby tým pracoval v agilním režimu a myšlení.

Agilní Metodologie

Úvod do agilních modelů:

Agilní metodologie

java předává pole metodě

Jak všichni víme, Agile je metodika vývoje softwaru.

Dozvěděli jsme se také o hodnotách a principech, které uvedli v agilním manifestu zakladatelé agile. V našich počátečních diskusích jsme také obcházeli rozdíly mezi agilními a tradičními modely vodopádů.

V tomto tutoriálu se seznámíme s výhodami a nevýhodami agilní metodiky.

Uvidíme, co je skrumáž? a čím se liší od agility. Poté pochopíme různé agilní metodiky, které používají různé organizace, a jak můžeme agilní implementovat pomocí nich.

Budete také schopni ocenit rozdíl a také výhody / nevýhody těchto metodik.

Výhody agilní metodiky

Níže uvádíme různé výhody agilní metodiky:

  • Na konci každé iterace / sprintu získávají zákazníci průběžně přehled o průběhu projektu.
  • Každý sprint poskytuje zákazníkovi funkční software, který splňuje jeho očekávání podle definice jím poskytnuté.
  • Vývojové týmy velmi dobře reagují na měnící se požadavky a mohou přizpůsobit změny i v pokročilých fázích vývoje.
  • Existuje neustálá obousměrná komunikace, která udržuje zákazníky zapojené, takže všechny zúčastněné strany - obchodní i technické - mají jasný přehled o postupu projektu.
  • Design produktu je efektivní a splňuje obchodní požadavky.

Nevýhody agilní metodiky

Ačkoli má agilní metodologie několik výhod, jsou v ní také určité nevýhody.

Oni jsou:

# 1) Není upřednostňována komplexní dokumentace, což může vést k tomu, že agilní týmy tuto chybu nesprávně interpretují, protože agilní nevyžaduje dokumentaci. Přísnost se tedy ztratí v dokumentaci. Tomu by se mělo zabránit tím, že si budete neustále klást otázku, zda je to dostatečná informace k pokračování nebo ne.

#dva) Někdy na začátku projektů nejsou požadavky křišťálově čisté. Týmy by mohly pokračovat a zjistit, že se vize zákazníků změnila, a v takových situacích musí týmy začlenit mnoho změn a je také obtížné odhadnout konečný výsledek.

Druhy agilních metodik

Po celém světě existuje v praxi několik agilních metodik. Budeme se podrobněji dozvědět o čtyřech nejoblíbenějších.

Typy agilních metodik

# 1) Scrum

Scrum lze snadno považovat za nejpopulárnější agilní framework. Pojem „skrumáž“ je většinou praktiků považován za synonymum k „agilnímu“. Ale to je mylná představa. Scrum je jen jedním z rámců, pomocí kterého můžete implementovat agilní.

Slovo scrum pochází ze sportovního ragby. Kde se hráči schoulí k sobě v blokované pozici a tlačí proti soupeřům. Každý hráč má ve své pozici definovanou roli a může hrát útočné i obranné podle požadavků situace.

Podobně scrum v IT věří v zmocněné samosprávné vývojové týmy se třemi konkrétními a jasně definovanými rolemi. Mezi tyto role patří - Vlastník produktu (PO), Scrum Master (SM) a vývojový tým složený z programátorů a testerů . Pracují společně v iterativním časovém intervalu, který se nazývá sprinty.

Prvním krokem je vytvoření nevyřízeného produktu produktem PO. Je to seznam úkolů, které má scrum tým udělat. Poté scrum tým vybere položky s nejvyšší prioritou a pokusí se je dokončit v časovém poli zvaném sprint.

Jednodušší způsob, jak si to všechno zapamatovat, je zapamatovat si rámec 3-3-5. To znamená, že scrum projekt má 3 role, 3 artefakty a 5 událostí.

Tyto jsou -

Role: PO, Scrum master a vývojový tým.

Artefakty: Nevyřízené položky produktu, nevyřízené položky sprintuaPřírůstek produktu.

Události: Sprint, plánování sprintu, denní scrum, kontrola sprintu a retrospektiva sprintu.

Rámec 3-3-5

O každém z nich se podrobněji seznámíme v našich dalších výukách.

# 2) Kanban

Kanban je japonský výraz, který znamená kartu. Tyto karty obsahují podrobnosti o práci na softwaru. Účelem je vizualizace. Každý člen týmu si je vědom práce, kterou je třeba provést prostřednictvím těchto vizuálních pomůcek.

Týmy používají tyto karty Kanban k nepřetržitému doručování. Stejně jako Scrum, i Kanban pomáhá týmům efektivně pracovat a podporuje samostatně spravované a spolupracující týmy.

Ale i mezi těmito dvěma existují rozdíly - podobně jako při skrumážovém sprintu jsou položky, na kterých tým pracuje, opraveny a nemůžeme do sprintu přidávat položky, zatímco v Kanbanu můžeme přidávat položky, pokud je k dispozici kapacita. To je zvláště užitečné, když se požadavky často mění.

Podobně dalším rozdílem je, že zatímco má scrum definované role PO, scrum master a vývojové týmy, v Kanbanu nejsou žádné takové předdefinované role.

Dalším rozdílem je, že zatímco scrum navrhuje prioritu nevyřízených produktů, Kanban takový požadavek nemá a je zcela volitelný. Kanban tedy vyžaduje méně organizace a vyhýbá se činnostem bez přidávání hodnoty a je vhodný pro procesy, které vyžadují reakci na změny.

# 3) Štíhlá

Lean je filozofie zaměřená na snižování odpadu. Jak to dělá?

Stručně řečeno, rozdělíte proces na činnosti s přidanou hodnotou, činnosti bez přidávání hodnoty a základní činnosti bez přidávání hodnoty. Jakákoli činnost, kterou lze klasifikovat jako činnost bez přidané hodnoty, je plýtváním a měli bychom se snažit tento odpad v procesu odstranit, aby byl štíhlejší.

Štíhlejší proces znamená rychlejší doručení a menší úsilí vynaložené na úkoly, které nepomáhají k dosažení cílů týmu. To pomáhá optimalizovat každý krok v cyklu vývoje softwaru. Proto byly štíhlé principy přizpůsobeny od štíhlé výroby k vývoji softwaru.

Vývoj štíhlého softwaru lze použít v jakémkoli IT projektu uplatněním sedmi principů lean, které jsou uvedeny níže:

sedm štíhlých principů

Jsou zcela vysvětlující, jak napovídají jejich jména. Eliminace plýtvání je prvním a nejdůležitějším principem štíhlosti a viděli jsme, jak to udělat, jen klasifikujeme činnosti jako přidanou hodnotu a nehodnotu.

Aktivitou bez přidané hodnoty může být jakákoli část kódu, která by mohla snížit její robustnost, zvýšit vynaložené úsilí a zabrat spoustu času bez přidání oprávněné obchodní hodnoty. Mohou to být také vágní uživatelské příběhy nebo špatné testování nebo přidávání funkcí, které ve velkém nejsou vyžadovány.

Druhý princip zesilující učení je opět snadno pochopitelný, protože tým potřebuje různé dovednosti, aby mohl dodávat produkty v rychle se měnícím prostředí s novými technologiemi, které se objevují v rychlých dobách.

Dělat pozdní rozhodnutí může být přínosné za okolností, kdy to snižuje přepracování, jako kdyby se očekávaly nějaké změny, pak to lépe odložte, aby tým nemusel práci opakovat, protože se mění obchodní potřeby.

Ale zde je vždy kompromis, protože týmy to musí vyvážit čtvrtým principem rychlejšího doručování. Zpoždění rozhodnutí by nemělo mít dopad na celkovou realizaci a nesmí snižovat pracovní tempo. Jedno oko by mělo být vždy na úplném obrázku.

Mít zmocněné týmy je v dnešní době také velmi běžné a to je něco, co dokonce agilní naznačuje. Zplnomocněné týmy jsou odpovědnější a mohou přijímat rozhodnutí rychleji. Pocit vlastnictví v zmocněném týmu vede k lepším výsledkům. Pro posílení postavení týmu by jim mělo být umožněno organizovat se a rozhodovat samostatně.

Vidíme tedy, že štíhlé a agilní mají mnoho společného s jedním výrazným rozdílem - zatímco štíhlé týmy mohou pomoci vylepšit produkt, agilní týmy jsou ty, které produkt skutečně vytvářejí.

# 4) Extrémní programování (XP)

Extrémní programování je další nejpopulárnější agilní technikou. Podle extremeprogramming.org byl první projekt XP zahájen 6. března 1996. Zmínili také, že XP ovlivňuje vývoj softwarového projektu 5 různými způsoby - komunikací, jednoduchostí, zpětnou vazbou, respektem a odvahou. Říká se jim hodnoty XP.

Z toho vše začíná komunikací. Týmy XP pravidelně spolupracují s obchodními týmy a ostatními programátory a vytvářejí kód od prvního dne. Důraz je zde zaměřen na komunikaci tváří v tvář, pokud je to možné, pomocí dalších vizuálních pomůcek.

Extrémní programátoři také vytvářejí jednoduchý kód a začínají na něj dostávat zpětnou vazbu od prvního dne samotného. Důraz je kladen na to, aby nedošlo k překročení hranice nebo předvídání požadavků, které nebyly sdíleny. Díky tomu je design jednoduchý a produkuje jen minimální produkt, který splní požadavky.

Zpětná vazba pomáhá týmu zlepšovat se a produkovat kvalitnější práci. To jim pomáhá budovat vzájemnou úctu, když se od sebe navzájem učí a naučit se sdílet své názory.

To jim také dává odvahu, protože vědí, že shromáždili nejlepší nápady všech a vytvořili dobrý produkt se zpětnou vazbou od ostatních. Nebojí se tedy zahrnout změny nebo získat další zpětnou vazbu o své práci.

To je zvláště užitečné v projektech, kde se požadavky často mění. Neustálá zpětná vazba pomůže týmům začlenit tyto změny s odvahou.

Tak jsme viděli různé agilní metodiky jako Scrum, XP, Kanban a Lean spolu s jejich příslušnými výhodami a nevýhodami.

Nyní je můžeme snadno rozlišit a také ocenit jemné rozdíly mezi nimi. Naučili jsme se také základy každé z těchto metodik a zjistili jsme, jak je v případě potřeby použít v našich projektech.

V další části pojďme pochopit vše o Scrumu.

Scrum metodologie

SCRUM je proces v agilní metodice, který je kombinací iteračního modelu a inkrementálního modelu.

Jeden z hlavních znevýhodnění tradičního Model vodopádu bylo to - dokud není dokončena první fáze, aplikace se nepřesune do druhé fáze. A náhodou, pokud v pozdější fázi cyklu dojde k nějakým změnám, je implementace těchto změn velmi náročná, protože by to znamenalo přehodnotit dřívější fáze a provést změny znovu.

Agilní testování skrumáže

Mezi klíčové vlastnosti SCRUM patří:

  • Samostatně organizovaný a soustředěný tým.
  • Žádné velké požadavky na dokumenty, spíše mají velmi přesné a věcné příběhy.
  • Cross-funkční týmy pracují společně jako jeden celek.
  • Abyste porozuměli funkcím, úzce komunikujte se zástupcem uživatele.
  • Má určitou časovou osu maximálně jeden měsíc.
  • Místo toho, aby dělal celou „věc“ najednou, Scrum dělá vše v daném intervalu.
  • Před spácháním čehokoli jsou zváženy možnosti a dostupnost zdrojů.

Abychom této metodologii dobře porozuměli, je důležité porozumět klíčovým terminologiím ve SCRUM.

Přečtěte si také => Jak dodávat vysoce kvalitní softwarové funkce v krátkém časovém období pomocí agilního procesu skrumáže

Důležité terminologie SCRUM

1) Scrum Team

Scrum tým je tým skládající se ze 7 s + nebo - dvěma členy. Tito členové jsou kombinací kompetencí a zahrnují vývojáře, testery, pracovníky databáze, pracovníky podpory atd., Spolu s vlastníkem produktu a mistrem scrumu.

Všichni tito členové spolupracují v úzké spolupráci po rekurzivní a určitý interval, aby vyvinuli a implementovali uvedené funkce. Uspořádání týmového sezení SCRUM hraje v jejich interakci velmi důležitou roli, nikdy nesedí ve skříňkách nebo chatkách, ale na obrovském stole.

Scrum tým

2) Sprint

Sprint je předdefinovaný interval nebo časový rámec, ve kterém musí být práce dokončena a připravena k revizi nebo připravena k produkčnímu nasazení. Tato lhůta obvykle leží mezi 2 týdny a 1 měsícem.

load balancing router dvě připojení k internetu

V našem každodenním životě, když říkáme, že sledujeme 1měsíční Sprintův cyklus, to jednoduše znamená, že na úkolech pracujeme po dobu jednoho měsíce a připravíme jej na kontrolu do konce tohoto měsíce.

3) Vlastník produktu

Vlastník produktu je klíčovým účastníkem nebo hlavním uživatelem aplikace, která má být vyvinuta. Vlastníkem produktu je osoba, která zastupuje stranu zákazníka. Má konečné oprávnění a měl by být týmu vždy k dispozici.

Měl by být dosažitelný, pokud má někdo jakékoli pochybnosti, které je třeba objasnit. Je důležité, aby vlastník produktu pochopil a nepřiřazoval žádné nové požadavky uprostřed sprintu nebo když již sprint začal.

4) Scrum Master

Scrum Master je facilitátorem scrum týmu. Zajišťuje, aby byl scrum tým produktivní a progresivní. V případě jakýchkoli překážek následuje scrum master a vyřeší je pro tým. SCRUM Master je prostředníkem mezi organizací producentů a týmem.

Průběžně informuje PO o průběhu Sprintu. Pokud pro tým existují překážky nebo obavy, projednejte to s PO a nechte je vyřešit. Stejně jako denní standup týmu se každý den děje standup SCRUM Master s PO.

Doporučené čtení => Jak být dobrým mentorem týmu, trenérem a skutečným týmovým obráncem v agilním testovacím světě?

5) Obchodní analytik (BA)

Obchodní analytik hraje ve SCRUM velmi důležitou roli. Tato osoba je odpovědná za dokončení požadavku a jeho vypracování v dokumentech požadavků (na základě kterých jsou vytvářeny uživatelské příběhy).

Pokud existují nějaké nejasnosti v kritériích Příběhy uživatele / Přijetí, je to ten, kdo je osloven technickým týmem (SCRUM) a ten je poté předá PO, nebo pokud je to možné, vyřeší sám. Ve velkých projektech může být více než 1 BA, ale v malých projektech může působit jako BA také SCRUM Master.

Při zahájení projektu je vždy dobrou praxí mít bakalářský titul.

6) Uživatelský příběh

Uživatelské příběhy nejsou nic jiného než požadavky nebo funkce, které je třeba implementovat.

Ve skrumáži tyto velké požadavky nemáme, spíše jsou požadavky definovány v jediném odstavci, obvykle ve formátu:

Jako
chci
Dosáhnout

Například :

Jako správce chci mít zámek hesla v případě, že uživatel zadá nesprávné heslo po dobu 3 po sobě jdoucích, aby omezil neoprávněný přístup.

Existuje několik charakteristik uživatelských příběhů, které je třeba dodržovat. Uživatelské příběhy by měly být krátké, realistické, mohly by být odhadnuty, úplné, vyjednávatelné a testovatelné. Příběh uživatele se uprostřed Sprintu nikdy nezmění ani nezmění.

Je odpovědností SCRUM Master a BA (je-li to relevantní), aby se ujistil, že organizace producentů vypracovala uživatelské příběhy správně se správnou sadou kritérií přijetí “. Pokud mají být provedeny nějaké změny, které budou mít dopad na vydání sprintu, jsou takové příběhy vytáhnuty ze sprintu nebo jsou provedeny podle dostupných hodin.

Každý příběh uživatele má kritérium přijetí, které by mělo být týmu dobře definováno a srozumitelné.

Kritéria přijetí podrobně popisují příběh uživatele, který poskytuje podpůrné dokumenty. Pomáhá dále vylepšovat příběh uživatele. Kritéria přijetí si může zapsat kdokoli z týmu. Testovací tým založí své testovací případy / podmínky na těchto kritériích přijetí.

7) Eposy

Eposy jsou nejednoznačné uživatelské příběhy, nebo můžeme říci, že se jedná o uživatelské příběhy, které nejsou definovány a jsou uchovávány pro budoucí sprinty.

Zkus to spojit se životem, představ si, že jdeš na dovolenou. Jak jedete příští týden, máte vše na svém místě, jako jsou vaše rezervace hotelů, prohlídky památek, cestovní šeky atd. Ale co váš plán dovolené na příští rok? Máte jen nejasnou představu, že můžete jít na místo XYZ, ale nemáte žádný podrobný plán.

Epic je stejně jako vy plán dovolené na příští rok, kde víte, že možná budete chtít jít, ale kde, kdy, s kým, o všech těchto detailech v tuto chvíli netušíte.

Podobným způsobem existují funkce, které je třeba v budoucnu implementovat, jejichž podrobnosti ještě nejsou známy. Funkce většinou začíná eposem a poté je rozdělena na příběhy, které lze implementovat.

8) Nevyřízené položky produktu

Nevyřízené položky produktu jsou jakýmsi segmentem nebo zdrojem, kde jsou uchovávány všechny příběhy uživatelů. To je udržováno vlastníkem produktu. Nevyřízené položky produktu lze představit jako seznam přání vlastníka produktu, který jej upřednostňuje podle obchodních potřeb.

Během plánovací schůzky (viz další část) je jeden uživatelský příběh převzat z nevyřízených položek produktu, poté tým provede brainstorming, porozumí mu a zdokonalí ho a společně rozhodne, které uživatelské příběhy si vezme, se zásahem vlastníka produktu.

9) Sprint Backlog

Na základě priority jsou příběhy uživatelů převzaty z produktového backlogu jako jeden po druhém. Tým Scrumu o něm brainstormuje, určuje proveditelnost a rozhoduje o tom, že příběhy budou pracovat na konkrétním sprintu. Souhrnný seznam všech příběhů uživatelů, které scrum tým pracuje na konkrétním sprintu, je známý jako nevyřízené sprinty.

Sprint Backlog

10) Body příběhu

Body příběhu jsou kvantitativní indikací složitosti příběhu uživatele. Na základě bodu příběhu se stanoví odhad a úsilí o příběh.

Bod příběhu je relativní a ne absolutní. Abychom se ujistili, že náš odhad a úsilí jsou správné, je důležité zkontrolovat, zda příběhy uživatelů nejsou velké. Čím přesnější a menší je uživatelský příběh, tím přesnější bude odhad.

Každý příběh uživatele je přiřazen k bodu příběhu na základě série Fibonacci (1, 2, 3, 5, 8, 13 a 21). Vyšší je číslo, komplex je příběh.

Být přesný

  • Pokud dáte 1/2/3 příběhový bod, znamená to, že příběh je malý a málo složitý.
  • Pokud dáte body jako 5/8, jedná se o střední komplex a
  • 13 a 21 jsou velmi složité.

Zde se složitost skládá jak z vývoje, tak z testování.

Při rozhodování o bodu příběhu probíhá brainstorming ve skrumážním týmu a tým společně rozhodne o bodu příběhu.

Může se stát, že vývojový tým dá konkrétnímu příběhu bod 3, protože pro něj to mohou být 3 řádky změny kódu, ale testovací tým dává 8 příběhů, protože mají pocit, že tato změna kódu ovlivní větší moduly, takže testovací úsilí by bylo větší. Ať už dáváte jakýkoli bod příběhu, musíte to zdůvodnit.

V této situaci tedy dochází k brainstormingu a tým kolektivně souhlasí s jedním bodem příběhu.

Kdykoli se rozhodujete pro příběh, mějte na paměti následující faktory:

  • Závislost příběhu na jiné aplikaci / modulu.
  • Sada dovedností zdroje.
  • Složitost příběhu.
  • Historické učení.
  • Kritéria přijetí příběhu uživatele.

Pokud si nejste vědomi konkrétního příběhu, neměňte jeho velikost.

Kdykoli je příběh = nebo> 8 bodů, je rozdělen na 2 nebo více příběhů.

11) Vypálit graf

Vypalovací graf je graf, který ukazuje odhadované skutečné v / s skutečné úsilí úkolů skrumáže.

Jedná se o sledovací mechanismus, pomocí kterého se u konkrétního sprintu sledují každodenní úkoly, aby se zkontrolovalo, zda příběhy postupují směrem k dokončení bodů spáchaného příběhu nebo ne.

Příklad : Chcete-li tomu porozumět, zkontrolujte níže uvedený obrázek:

Vypálit graf 1

Předpokládal jsem:

  • 2 týdny Sprint (10 dní)
  • 2 zdroje skutečné práce na sprintu.

'Příběh' -> Tento sloupec zobrazuje uživatelské příběhy pořízené pro sprint.

'Úkol' -> Tento sloupec zobrazuje seznam úkolů spojených s příběhem uživatele.

'Úsilí' -> Tento sloupec ukazuje úsilí. Toto opatření nyní představuje celkovou snahu o dokončení úkolu. Nezobrazuje úsilí vynaložené žádným konkrétním jednotlivcem.

„Den 1 - Den 10“ -> Tento sloupec ukazuje hodiny, které zbývají k dokončení příběhu. Mějte prosím na paměti, že hodina NENÍ hodina, která je již hotová, ale hodiny, které ještě zbývají.

„Odhadované úsilí“ -> Je celkové úsilí. Pro „Start“ je to jednoduše součet celého individuálního úkolu: SUMA (C5: C15)

Celkový počet úsilí, které musí být dokončeno za 1 den, je 70/10 = 7. Takže na konci dne 1 by se úsilí mělo snížit na 70 - 7 = 63. Podobným způsobem se počítá pro všechny dny do 10. dne, kdy by odhadované úsilí mělo být 0 (řádek 16)

„Skutečné úsilí zbývá“ -> Jak název napovídá, zbývá skutečně dokončit příběh. Může se také stát, že skutečné úsilí se zvýší nebo sníží než odhadované.

K vytvoření tohoto podrobného grafu můžete použít vestavěné funkce a graf v aplikaci Excel.

Kroky vypalování grafu by byly:

  1. Zadejte všechny příběhy (sloupec A5 - A15).
  2. Zadejte všechny úkoly (sloupec B5 - B15).
  3. Zadejte dny (1. den - 10. den).
  4. Zadejte počáteční úsilí (sečtěte úkoly C5 - C15).
  5. Použijte vzorec pro výpočet „Odhadovaného úsilí“ pro každý den (1. až 10. den). Zadejte vzorec na D15 (C16 - $ C $ 16/10) a přetáhněte jej po všechny dny.
  6. Pro každý den zadejte skutečné úsilí. Zadejte vzorec na D17 (SUM (D5: D15)) pro shrnutí zbývajícího úsilí a přetáhněte jej po všechny ostatní dny.
  7. Vyberte jej a vytvořte graf následujícím způsobem:

Vypálit graf 2

12) Rychlost

Celkový počet bodů příběhu, který skrumážní tým archivuje ve sprintu, se nazývá Velocity. Scrum tým je posuzován nebo odkazován podle jeho rychlosti. Přesto je třeba mít na paměti, že cílem zde NENÍ dosažení maximálních bodů příběhu, ale dosažení kvalitního výsledku při respektování úrovně pohodlí týmu skrumáže.

Například : Pro konkrétní sprint: celkový počet příběhů uživatelů je 8, které mají body příběhu, jak je uvedeno níže.

Rychlost skrumáže

Rychlost tedy bude součtem bodů příběhu = 30

Definice Hotovo:

Sprint je označen jako Hotovo, když jsou všechny příběhy dokončeny, všechny úkoly v oblasti vývoje, výzkumu a QA jsou označeny jako „Dokončeno“, všechny chyby jsou pevně uzavřeny, jinak mohou být provedeny později (například nejsou zcela příbuzné nebo jsou méně důležité) jsou vytaženy a přidány do nevyřízených položek, je dokončena kontrola kódu a testování jednotek, odhadované hodiny splnily skutečné hodiny zadané v úkolech a co je nejdůležitější, byla poskytnuta úspěšná ukázka PO a zúčastněným stranám.

Činnosti prováděné v metodice SCRUM

# 1) Plánování schůzky

Plánovací schůzka je výchozím bodem Sprintu. Jedná se o schůzku, kde se schází celý tým skrumáží, SCRUM Master vybere příběh uživatele na základě priority z nevyřízeného produktu a týmových brainstormů na něm.

Na základě diskuse rozhodne scrum tým o složitosti příběhu a jeho velikosti podle Fibonacciho série. Tým identifikuje úkoly spolu s úsilím (v hodinách), které by bylo provedeno k dokončení implementace příběhu uživatele.

Plánovací schůzce často předchází „Předplánovací schůzka“. Je to jako domácí úkol, který skrumážový tým dělá, než se sejde na formálním plánovacím setkání. Tým se snaží zapsat závislosti nebo jiné faktory, o kterých by rádi diskutovali na plánovací schůzce.

# 2) Provádění úkolů sprintu

Jak název napovídá, jedná se o skutečnou práci scrum týmu, aby splnil svůj úkol a vzal uživatelský příběh do stavu „Hotovo“.

# 3) Denní Standup

Během sprintového cyklu se každý den setkává scrum tým, ne déle než 15 minut (může to být stand-up call, doporučeno mít na začátku dne) a uveďte 3 body:

  1. Co včera udělal člen týmu?
  2. Co měl dnes v plánu člen týmu?
  3. Nějaké překážky (zátarasy)?

Je to mistr Scrumu, kdo toto setkání usnadňuje. V případě, že se kterýkoli člen týmu potýká s jakýmkoli druhem obtíží, následuje scrum master, aby to vyřešil. Ve Stand-upech se také kontroluje deska, která sama ukazuje pokrok týmu.

# 4) Zkontrolujte schůzku

Na konci každého sprintového cyklu se tým SCRUM znovu setkává a demonstruje implementované uživatelské příběhy vlastníkovi produktu. Vlastník produktu může ověřit příběhy podle svých kritérií přijetí. Je opět odpovědností mistra Scrumu předsedat tomuto setkání.

Také v nástroji SCRUM je Sprint uzavřen a úkoly jsou označeny jako splněné.

# 5) Retrospektivní setkání

K retrospektivní schůzce dochází po kontrolní schůzce.

Tým SCRUM splňuje, diskutuje a dokumentuje následující body:

  • Co proběhlo dobře během Sprintu (Osvědčené postupy)?
  • Co nešlo ve Sprintu dobře?
  • Ponaučení
  • Akční předměty.

Tým Scrumu by měl i nadále dodržovat osvědčené postupy, ignorovat „ne osvědčené postupy“ a implementovat poznatky získané během následných sprintů. Retrospektivní setkání pomáhá implementovat neustálé zlepšování procesu SCRUM.

Jak probíhá proces? Příklad!

Po přečtení o technických jargons SCRUM. pokusím se ukázat celý proces na příkladu.

Příklad:

Krok 1 : Pojďme mít tým SCRUM složený z 9 lidí složený z 1 produktového vlastníka, 1 Scrum master, 2 testerů, 4 vývojářů a 1 DBA.

Krok 2 : Sprint je rozhodnut následovat 4 týdenní cyklus. Máme tedy 1měsíční Sprint počínaje 5. červnem až 4. dnemthčervence.

Krok # 3 : Vlastník produktu má v backlogu produktu upřednostněný seznam uživatelských příběhů.

Krok č. 4: Tým se rozhodne setkat 4.thČervna na schůzku „Před plánováním“.

  • Vlastník produktu vezme 1 příběh z nevyřízené položky produktu, popíše jej a ponechá jej na týmu, aby na něm provedl brainstorming.
  • Celý tým diskutuje a komunikuje přímo s vlastníkem produktu, aby jasně porozuměl příběhu uživatele.
  • Podobným způsobem jsou převzaty různé další uživatelské příběhy. Pokud je to možné, tým může pokračovat a velikost příběhů také.

Po skončení celé diskuse se jednotliví členové týmu vrátí ke svým pracovním stanicím a

  • U každého příběhu identifikujte jejich jednotlivé úkoly.
  • Vypočítejte přesný počet hodin, na kterých budou pracovat. Podívejme se, jak člen tyto hodiny uzavírá.

Celkový počet pracovních hodin = 9
Mínus 1 hodina za přestávku, minus 1 hodina za schůzky, minus 1 hodina za e-maily, diskuse, řešení problémů atd.
Skutečná pracovní doba = 6.
Celkový počet pracovních dnů během sprintu = 21 dní.
Celkový počet dostupných hodin = 21 * 6 = 126.
Člen má dovolenou na 2 dny = 12 hodin (u každého člena se to liší, někteří mohou čerpat dovolenou a jiní ne).
Počet skutečných hodin = 126 - 12 = 114 hodin.

To znamená, že člen bude pro tento sprint ve skutečnosti k dispozici 114 hodin. Rozdělí tedy svůj individuální úkol sprintu tak, aby bylo dosaženo celkem 114 hodin.

Krok # 5 : Na 5thčervna se celý tým Scrum setká na „plánovací schůzce“.

  • Konečný verdikt uživatelského příběhu z nevyřízeného produktu je hotový a příběh je přesunut do nevyřízeného sprintu.
  • U každého příběhu každý člen týmu deklaruje své identifikované úkoly, v případě potřeby může o těchto úkolech diskutovat, může jej změnit nebo změnit jeho velikost (nezapomeňte na sérii Fibonacci !!).
  • Mistr Scrumu nebo tým zadávají své jednotlivé úkoly spolu s hodinami pro každý příběh v nástroji.
  • Poté, co jsou všechny příběhy dokončeny, Scrum master zaznamená počáteční rychlost a formálně spustí Sprint.

Krok # 6 : Jakmile je Sprint spuštěn, na základě přiřazených úkolů začne každý člen týmu na těchto úkolech pracovat.

Krok # 7 : Tým se schází denně po dobu 15 minut a diskutuje o 3 věcech:

  • Co dělali včera?
  • Co plánují dělat dnes?
  • Nějaké překážky (zátarasy)?

Krok # 8 : Scrum master sleduje pokrok na denní bázi pomocí „Burn down chart“.

Krok # 9 : V případě jakýchkoli překážek následuje mistr Scrumu, aby je vyřešil.

Krok # 10 : 4.thV červenci se tým znovu sejde na kontrolní schůzce. Člen demonstruje implementovaný uživatelský příběh vlastníkovi produktu.

Krok # 11 : 5. dnethV červenci se tým znovu setkává při retrospektivě, kde diskutují

  • Co šlo dobře?
  • Co nešlo dobře?
  • Akční předměty.

Krok # 12 : 6.thV červenci se tým znovu sejde na předběžné schůzce pro další sprint a cyklus pokračuje.

skromný agilní metodický proces

SCRUM Activity Tools

Existuje několik nástrojů, které lze značně použít ke sledování aktivit skrumáže.

Některé z nich zahrnují:

V nadcházejícím tutoriálu osvětlíme Agilní manifest, což je pojem, který řídí efektivní agilní týmy.

Další výuka

O autorech: Tato série je napsána následujícími členy týmu STH: Shruti Shrivastava - profesionální Scrum Master s 9 lety zkušeností v oblasti BFSI, elektronického obchodování a B2B domén. Shruti je odborníkem na testování automatizace a vede scrum týmy.

Anshul Kumar Srivastava - profesionální produktový management zaměřený na výsledky a agilní odborník se 7 lety zkušeností v odvětvích BFSI a Telecom.

Doporučené čtení

^