Menu

Agilná metodológia: Sprievodca agilnou metódou a skrumážou pre začiatočníkov

agile methodology beginner s guide agile method

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Kompletný sprievodca po agilnej metodike: (20 a viac podrobných návodov na metodiku agilnej skrumáže)

Toto je sprievodca pre vývojárov a testerov softvéru, aby pochopili a začali pracovať na veľmi slávnych Agilná metodika SCRUM pre vývoj a testovanie softvéru . Naučte sa základné, ale dôležité terminológie používané v procese Agile Scrum spolu so skutočným príkladom celého procesu.

Pre vaše pohodlie sme vymenovali všetky agilné výukové programy v tejto sérii. Dúfam, že vám budú nesmierne pomáhať.

Pokryté témy: Čo je to Agile, čo je Scrum, agilná metodika vývoja a testovania softvéru, agilné testovanie, agilný proces scrumu, metodika scrumu so Scrum tímom a Scrum Masterom.

úvod do agilného vývoja

Čo sa dozviete:

Zoznam agilných metodických návodov

Výukový program č. 1: Metódy agilného skrumáže (Tento návod)
Výukový program č. 2: Agilný manifest
Výukový program č. 3: Scrum tím a ich úlohy a zodpovednosti
Výukový program č. 4: Scrum artefakty
Výukový program č. 5: Scrum udalosti
Výukový program č. 6: Porucha triafania v skrumáži
Výukový program č. 7: Sebestačné tímy pre skrumáž
Výukový program č. 8: Princíp troch Amigo
Výukový program č. 9: SAFe - zmenšený agilný rámec
Výukový program č. 10: Agilný kvíz o skrumáži

ĎALŠIE odporúčané výukové programy pre agilné skrumáže:

Výukový program č. 11: Najlepšie 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é retrospektívne stretnutia
Výukový program č. 16: Úloha obchodných analytikov v SCRUM
Výukový program č. 17: Úloha QA v skrumáži

Nástroje a otázky na pohovor:

Výukový program č. 18: Agilné testovacie nástroje
Výukový program č. 19: Najlepšie nástroje na agilné riadenie projektu
Výukový program č. 20: Najlepšie otázky týkajúce sa agilného rozhovoru
Výukový program č. 21: Najlepšie otázky týkajúce sa rozhovorov so skrumážou

Začnime prvým tutoriálom v sérii - Agile Scrum Introduction.

Úvod do agilného rozvoja

Agilný vo vývoji softvéru:

Agile je jedným z najbežnejšie používaného a uznávaného rámca pre vývoj softvéru na svete.

Väčšina organizácií to prijala v nejakej forme alebo v inej, ale ešte zostáva ešte dlhá cesta, pokiaľ ide o zrelosť ich programov adopcie. Jediným cieľom tejto série návodov je zapojiť technologických a netechnologických odborníkov do sveta Agile World.

Prevedieme vás agilnou cestou krok za krokom, až kým nepochopíte filozofiu používania Agile, jej výhody a spôsob, ako ju praktizovať. Táto séria si kladie za cieľ vybaviť a umožniť čitateľom aplikovať Agile a Scrum učenie do svojej práce.

Tento konkrétny tutoriál je venovaný vysvetleniu, prečo bol Agile potrebný a ako bol vytvorený. Základom je, aby ste pochopili koncept agilnej adopcie v softvérovom vývojovom priemysle.

Dejiny agilu

Agile sa narodil, keď sa v jeden pekný deň stretlo 17 ľudí s rôznymi vývojovými metodikami, aby spoločne prediskutovali, či existuje možné alternatívne riešenie vývoja softvéru, ktoré by mohlo viesť k rýchlejšej dobe vývoja a bolo menej náročné na dokumentáciu.

V tom čase prebiehal vývoj softvéru tak dlho, že v čase, keď boli projekty pripravené na dodanie, sa obchod posunul vpred a zmenili sa požiadavky. Projekt teda nebol schopný uspokojiť obchodné potreby, aj keď bol schopný splniť svoje definované ciele.

Tak sa títo šampióni v rôznych technikách softvérového inžinierstva dali dokopy a konečným výsledkom ich stretnutia bolo to, čo nazvali „agilný manifest“, o čom sa budeme podrobne rozprávať v ďalšom návode tejto série.

Avšak agilita, ktorá sa v ten deň zrodila, nie je to, čo dnes vidíme v organizáciách. Metodika, na ktorej sa odborníci zhodli, bola označená ako „ľahká“ a rýchla. Hlavnou výhrou na tomto stretnutí bola však myšlienka, že rýchlejšie dodanie produktu a neustále spätné väzby sú kľúčom k dosiahnutiu úspechu vo vývoji softvéru.

Existujúce techniky vodopádov boli príliš ťažkopádne a neobsahovali nijaké opatrenia na spätnú väzbu, kým nebol konečný produkt pripravený na dodanie. To znamenalo, že neexistoval priestor na korekciu kurzu a zákazník nemal žiadny prehľad o pokroku, kým nebude pripravený celý produkt. A tomu sa chceli títo odborníci vyhnúť.

Hľadali riešenie, ktoré by malo priestor na neustálu spätnú väzbu, aby sa v neskoršej fáze zabránilo nákladom na prepracovanie.

Agilné výzvy

Existujúce techniky vodopádov boli v tom čase príliš ťažkopádne a nemali spätnú väzbu, kým nebol hotový produkt pripravený na dodanie. Nazýval sa vodopádový model rozvoja, pretože tímy najskôr dokončili jeden krok úplne a až potom prešli k ďalšiemu kroku.

To znamenalo, že neexistoval priestor na korekciu kurzu a zákazník nemal žiadny prehľad o pokroku, kým nebude pripravený celý produkt. A tomu sa chceli títo odborníci vyhnúť. Hľadali riešenie, ktoré by malo priestor pre neustálu spätnú väzbu, aby sa v neskoršej fáze zabránilo nákladom na prepracovanie.

A preto je agilný tiež o adaptívnosti a neustálom zlepšovaní, rovnako ako o neustálej spätnej väzbe a rýchlosti dodania.

Čo sú to agilné sľuby?

Agilné sľuby

Agile nie je len o uplatňovaní stanovených postupov pri vývoji softvéru. Prináša tiež zmenu v myslení tímu, ktorá ich vedie k vytváraniu lepšieho softvéru, k spolupráci a nakoniec k spokojnému zákazníkovi.

Agilné hodnoty a princípy umožňujú tímu zmeniť zameranie a zmeniť myšlienkový proces budovania lepšieho softvéru.

Čo presne je agilný?

Agilný nie je súborom pravidiel. Agile nie je súborom pokynov. Agile nie je ani metodika. Agile je skôr súborom princípov, ktoré povzbudzujú flexibilitu, adaptabilitu, komunikáciu a pracovný softvér nad plánmi a procesmi. Je veľmi výstižne zachytený v tzv. Agilnom manifeste.

Agilný vývoj softvéru umožňuje tímu efektívnejšie a efektívnejšie spolupracovať na vývoji komplexných projektov. Skladá sa z postupov, ktoré využívajú iteračné a prírastkové techniky, ktoré sa dajú ľahko prijať a vykazujú vynikajúce výsledky.

Pri aplikácii Agile do akcie máme rôzne metódy a metodiky založené na agile. Tieto metódy a metodiky uspokojujú všetky potreby odvetvia vývoja softvéru od návrhu a architektúry softvéru, vývoja a testovania až po riadenie a dodávky projektov.

Agilné metódy a metodiky nielenže otvárajú priestor pre zlepšovanie procesov ako neoddeliteľnú súčasť každej dodávky.

Agile je prístup k vývoju softvéru, pri ktorom sebestačný a krížovo funkčný tím pracuje na uskutočňovaní nepretržitých dodávok prostredníctvom iterácií a v priebehu procesu sa vyvíja zhromažďovaním spätnej väzby od koncových používateľov.

Ako cvičiť agilne?

Existujú rôzne agilné metodiky, ktoré sa v praxi uplatňujú v rôznych diverzifikovaných odvetviach.

agilné metodiky

Najobľúbenejšie metodiky spomedzi všetkých sú však:

  • Skrumáž
  • Kanban
  • Extrémne programovanie

Všetky tieto metodiky sa zameriavajú na štíhly vývoj softvéru a pomáhajú pri efektívnom a efektívnom vytváraní lepšieho softvéru.

To je všetko s Agilným úvodom. Táto časť je štruktúrovaná tak, aby vám pomohla pochopiť základné hodnoty a princípy, ktoré sa musia prijať, aby tím pracoval v agilnom režime a myslení.

Agilný Metodika

Úvod do agilných modelov:

Agilná metodológia

Angularjs rozhovor otázky a odpovede pre skúsených pdf

Ako všetci vieme, Agile je metodika vývoja softvéru.

Dozvedeli sme sa tiež o hodnotách a princípoch, ktoré boli spomenutí v agilnom manifeste zakladateľmi agile. V úvodných diskusiách sme sa tiež zamerali na rozdiely medzi agilnými a tradičnými modelmi vodopádov.

V tomto návode sa dozvieme o výhodách a nevýhodách agilnej metodiky.

Uvidíme, čo je skrumáž? a čím sa líši od agilného. Potom pochopíme rôzne agilné metodiky, ktoré používajú rôzne organizácie, a ako môžeme agilnú implementovať pomocou nich.

Budete tiež schopní oceniť rozdiel a tiež výhody / nevýhody týchto metodík.

Výhody agilnej metodiky

Ďalej uvádzame rôzne výhody agilnej metodiky:

  • Na konci každej iterácie / šprintu majú zákazníci neustále k dispozícii prehľad o priebehu projektu.
  • Každý sprint poskytuje zákazníkovi funkčný softvér, ktorý spĺňa jeho očakávania podľa ním stanovenej definície vykonaného.
  • Vývojové tímy celkom dobre reagujú na meniace sa požiadavky a dokážu vyhovieť zmenám aj v pokročilých štádiách vývoja.
  • Existuje neustále obojsmerná komunikácia, ktorá udržuje zákazníkov zapojených, takže všetky zúčastnené strany - obchodné aj technické - majú jasný prehľad o postupe projektu.
  • Dizajn produktu je efektívny a spĺňa obchodné požiadavky.

Nevýhody agilnej metodiky

Aj keď má agilná metodológia niekoľko výhod, sú v nej zahrnuté aj určité nevýhody.

Oni sú:

# 1) Nepreferuje sa komplexná dokumentácia, ktorá môže viesť k tomu, že agilné tímy to budú nesprávne interpretovať, pretože agilný nevyžaduje dokumentáciu. Prísnosť sa teda stratí v dokumentácii. Tomuto by ste sa mali vyhnúť tým, že si budete neustále klásť otázku, či je to dostatočná informácia, aby ste mohli pokračovať.

#dva) Niekedy na začiatku projektov nie sú požiadavky úplne jasné. Tímy môžu pokračovať a zistiť, že vízia zákazníkov sa zmenila. V takýchto situáciách musia tímy zahrnúť veľa zmien a je ťažké odhadnúť aj konečný výsledok.

Typy agilných metodík

Po celom svete existuje v praxi niekoľko agilných metodík. Budeme sa podrobnejšie učiť o štyroch najobľúbenejších.

Typy agilných metodík

# 1) Scrum

Scrum možno ľahko považovať za najpopulárnejší agilný rámec. Väčšina odborníkov v praxi považuje termín „scrum“ za synonymum „agilného“. Ale to je mylná predstava. Scrum je iba jedným z rámcov, pomocou ktorého môžete agilnú implementovať.

Slovo skrumáž pochádza zo športového ragby. Kde sa hráči schúlia k sebe v blokovanej polohe a tlačia proti súperom. Každý hráč má na svojej pozícii vymedzenú úlohu a môže hrať útočne aj obranne podľa potreby situácie.

Podobne skrumáž v IT verí v oprávnené samosprávne vývojové tímy s tromi konkrétnymi a jasne definovanými úlohami. Tieto úlohy zahŕňajú - Produktový vlastník (PO), Scrum Master (SM) a vývojový tím zložený z programátorov a testerov . Pracujú spoločne v iteratívnom čase vymedzenom ako šprinty.

Prvým krokom je vytvorenie backlogu produktu PO. Je to zoznam úloh, ktoré má urobiť tím pre skrumáže. Potom skrumážny tím vyberie položky s najvyššou prioritou a pokúsi sa ich dokončiť v časovom okienku zvanom šprint.

Ľahší spôsob, ako si to všetko zapamätať, je zapamätať si rámec 3-3-5. To znamená, že projekt skrumáže má 3 roly, 3 artefakty a 5 udalostí.

Toto sú -

Úlohy: PO, Scrum master a vývojový tím.

Artefakty: Nevybavené položky produktu, nevybavené položky sprintuaPrírastok produktu.

Diania: Sprint, plánovanie sprintu, denný Scrum, kontrola sprintu a retrospektíva sprintu.

Rámec 3-3-5

O každej z nich sa podrobnejšie dozvieme v našich ďalších tutoriáloch.

# 2) Kanban

Kanban je japonský výraz, ktorý znamená karta. Tieto karty obsahujú podrobnosti o práci, ktorú je potrebné vykonať v softvéri. Účelom je vizualizácia. Každý člen tímu si je vedomý práce, ktorá sa má vykonať prostredníctvom týchto vizuálnych pomôcok.

Tímy používajú tieto karty Kanban na nepretržité doručovanie. Rovnako ako Scrum, aj Kanban slúži na pomoc tímom pri efektívnej práci a podporuje samosprávne a spolupracujúce tímy.

Ale aj medzi týmito dvoma existujú rozdiely - rovnako ako pri skrumážovom šprinte sú položky, na ktorých pracuje tím, pevné a do šprintu nemôžeme pridávať položky, zatiaľ čo v kanbane môžeme pridávať položky, ak je k dispozícii kapacita. To je obzvlášť užitočné, keď sa požiadavky často menia.

Ďalším rozdielom je tiež to, že zatiaľ čo skrumáž má definované úlohy PO, scrum master a vývojové tímy, v Kanbane neexistujú také vopred definované roly.

Ďalším rozdielom je, že aj keď skrumáž navrhuje uprednostňovanie nevybavených produktov, Kanban nemá takúto požiadavku a je úplne voliteľný. Kanban teda vyžaduje menšiu organizáciu a vyhýba sa činnostiam, ktoré nepridávajú pridanú hodnotu, a je vhodný pre procesy, ktoré si vyžadujú reakciu na zmeny.

# 3) Štíhla

Lean je filozofia zameraná na znižovanie odpadu. Ako to robí?

V štíhlosti rozdelíte proces na činnosti s pridanou hodnotou, činnosti bez pridania hodnoty a základné činnosti bez pridania hodnoty. Akákoľvek činnosť, ktorú možno klasifikovať ako činnosť bez pridanej hodnoty, je plytvaním a mali by sme sa pokúsiť tento odpad v procese odstrániť, aby bol štíhlejší.

Štíhlejší proces znamená rýchlejšie dodanie a menej vynaloženého úsilia pri úlohách, ktoré nepomáhajú dosiahnuť tímové ciele. To pomáha optimalizovať každý krok v cykle vývoja softvéru. Preto sa štíhlé princípy prispôsobili od štíhlej výroby k vývoju softvéru.

Vývoj štíhleho softvéru je možné použiť v akomkoľvek projekte IT uplatnením siedmich princípov štíhlosti, ktoré sú uvedené nižšie:

sedem štíhlych zásad

Sú dosť samozrejmé, ako napovedajú ich názvy. Eliminácia plytvania je prvý a najdôležitejší štíhly princíp a videli sme, ako to urobiť, len činnosti klasifikujeme ako pridanú hodnotu a nehodnotnú hodnotu.

Činnosťou bez pridanej hodnoty môže byť ktorákoľvek časť kódu, ktorá by mohla spôsobiť, že bude menej robustný, zvýši vynaložené úsilie a zaberie veľa času bez pridania oprávnenej obchodnej hodnoty. Môžu to byť tiež nejasné príbehy používateľov alebo zlé testovanie alebo pridávanie funkcií, ktoré nie sú potrebné.

Druhý princíp zosilňujúci učenie je opäť ľahko pochopiteľný, pretože tím potrebuje rôzne zručnosti na doručovanie produktov v rýchlo sa meniacom prostredí s novými technológiami, ktoré sa rýchlo rozvíjajú.

Neskoré rozhodovanie sa môže vyplatiť za okolností, keď to zníži potrebu prepracovania, ako keby sa očakávali nejaké zmeny, potom to radšej odložte, aby tím nemusel prácu opakovať, pretože sa menia obchodné potreby.

Vždy tu však existuje kompromis, pretože tímy to musia vyvážiť štvrtým princípom rýchlejšej dodávky. Oneskorenie rozhodnutí by nemalo mať vplyv na celkový výkon a nesmie znížiť pracovné tempo. Jedno oko by malo byť vždy na úplnom obrázku.

V dnešnej dobe je tiež veľmi časté mať splnomocnené tímy, čo naznačuje aj agilný. Posilnené tímy sú zodpovednejšie a môžu prijímať rozhodnutia rýchlejšie. Pocit vlastníctva v posilnenom tíme vedie k lepším výsledkom. Na posilnenie postavenia tímu by sa im malo umožniť organizovať sa a rozhodovať samostatne.

Vidíme teda, že štíhli a agilní majú veľa spoločného s jedným ostrým rozdielom - zatiaľ čo štíhlé tímy môžu pomôcť vylepšiť produkt, agilné tímy produkt zostavujú.

# 4) Extrémne programovanie (XP)

Extrémne programovanie je ďalšou najpopulárnejšou agilnou technikou. Podľa stránky extremeprogramming.org bol prvý projekt XP zahájený 6. marca 1996. Tiež spomínajú, že XP ovplyvňuje vývoj softvérových projektov piatimi rôznymi spôsobmi - komunikáciou, jednoduchosťou, spätnou väzbou, rešpektom a odvahou. Hovorí sa im hodnoty XP.

Z toho všetko začína komunikáciou. Tímy XP pravidelne spolupracujú s obchodnými tímami a kolegami programátormi a vytvárajú kód od prvého dňa. Dôraz sa kladie na komunikáciu tvárou v tvár, pokiaľ je to možné, pomocou ďalších vizuálnych pomôcok.

Extrémni programátori tiež zostavia jednoduchý kód a začnú od neho dostávať spätnú väzbu už od prvého dňa. Dôraz sa kladie na to, aby sme neprekračovali rámec alebo predpovedali požiadavky, ktoré neboli zdieľané. Vďaka tomu je dizajn jednoduchý a produkuje len minimum produktu, ktorý splní požiadavky.

Spätná väzba pomáha tímu zlepšovať sa a produkovať lepšiu kvalitu práce. To im pomáha budovať si navzájom úctu, keď sa učia jeden od druhého a učia sa, ako zdieľať svoje názory.

To im tiež dodáva odvahu, pretože vedia, že zhromaždili najlepšie nápady všetkých a vytvorili dobrý produkt so spätnou väzbou od ostatných. Preto sa neboja zahrnúť zmeny alebo získať ďalšiu spätnú väzbu o svojej práci.

To je obzvlášť užitočné v projektoch, kde sa požiadavky často menia. Neustála spätná väzba pomôže tímom začleniť tieto zmeny s odvahou.

Tak sme videli rôzne agilné metodiky ako Scrum, XP, Kanban a Lean spolu s ich príslušnými výhodami a nevýhodami.

Teraz ich môžeme ľahko rozlíšiť a oceniť aj jemné rozdiely medzi nimi. Osvojili sme si tiež základy každej z týchto metodík a zistili sme, ako ich v prípade potreby použiť v našich projektoch.

V ďalšej časti si ukážeme všetko o Scrume.

Metodika skrumáže

SCRUM je proces v agilnej metodike, ktorý je kombináciou iteračného modelu a prírastkového modelu.

Jeden z hlavných handicapov tradičného Model vodopádu bolo to - kým nebude dokončená prvá fáza, aplikácia sa nepresunie do druhej fázy. A náhodou, ak dôjde v neskoršej fáze cyklu k nejakým zmenám, je implementácia týchto zmien veľmi náročná, pretože by to znamenalo prehodnotenie predchádzajúcich fáz a opätovné vykonanie zmien.

Agilné testovanie skrumáže

Medzi kľúčové vlastnosti SCRUM patria:

  • Samostatne organizovaný a zameraný tím.
  • Žiadne náročné dokumenty, majú skôr veľmi presné a vecné príbehy.
  • Cross-funkčné tímy spolupracujú ako jeden celok.
  • Aby ste pochopili funkcie, úzko komunikujte so zástupcom používateľa.
  • Má jednoznačný časový rozvrh maximálne jedného mesiaca.
  • Namiesto toho, aby robil celú „vec“ naraz, Scrum robí v danom intervale všetko zo všetkého.
  • Pred spáchaním čohokoľvek sa zváži schopnosť a dostupnosť zdrojov.

Aby ste tejto metodike dobre porozumeli, je dôležité pochopiť kľúčové terminológie v SCRUM.

Prečítajte si tiež => Ako dodávať vysoko kvalitné softvérové ​​funkcie v krátkom časovom období pomocou agilného procesu skrumáže

Dôležité terminológie SCRUM

1) Scrum tím

Tím skrumáže je tím pozostávajúci zo 7 členov s + alebo - dvoma členmi. Títo členovia sú zmesou kompetencií a pozostávajú z vývojárov, testerov, pracovníkov v databáze, podporných pracovníkov atď., Spolu s vlastníkom produktu a skrumážnym majstrom.

Všetci títo členovia úzko spolupracujú na rekurzívnom a určitom intervale na vývoji a implementácii uvedených funkcií. Usporiadanie tímového sedenia SCRUM hrá v ich interakcii veľmi dôležitú úlohu, nikdy nesedia v kabínach alebo kajutách, ale na obrovskom stole.

Scrum tím

2) Sprint

Sprint je preddefinovaný interval alebo časový rámec, v ktorom musí byť práca dokončená a pripravená na kontrolu alebo pripravená na produkčné nasadenie. Táto lehota zvyčajne trvá 2 týždne až 1 mesiac.

dobré webové stránky na pozeranie anime zadarmo

V každodennom živote, keď hovoríme, že sledujeme 1-mesačný Sprintov cyklus, to jednoducho znamená, že na úlohách pracujeme jeden mesiac a do konca tohto mesiaca sme pripravení na kontrolu.

3) Vlastník produktu

Vlastník produktu je kľúčovým účastníkom alebo hlavným používateľom vyvíjanej aplikácie. Produktový vlastník je osoba, ktorá zastupuje stranu zákazníka. Má konečnú autoritu a mal by byť tímu kedykoľvek k dispozícii.

Mal by byť zastihnuteľný, keď má niekto pochybnosti, ktoré si vyžadujú objasnenie. Je dôležité, aby produktový vlastník pochopil a nepriradil žiadne nové požiadavky uprostred šprintu alebo keď už šprint začal.

4) Scrum Master

Scrum Master je facilitátorom scrum tímu. Zaisťuje, aby bol skrumážny tím produktívny a progresívny. V prípade akýchkoľvek prekážok následuje scrum master a vyrieši ich za tím. SCRUM Master je sprostredkovateľom medzi PO a tímom.

Neustále informuje PO o pokroku v šprinte. Ak tímu nejaké prekážky alebo prekážky bránia, diskutuje s PO a dá ich vyriešiť. Rovnako ako denný standup tímu, aj standup SCRUM Master s PO sa deje každý deň.

Odporúčané čítanie => Ako byť dobrým mentorom tímu, trénerom a skutočným obrancom tímu v agilnom testovacom svete?

5) Obchodný analytik (BA)

Obchodný analytik hrá v SCRUM veľmi dôležitú úlohu. Táto osoba je zodpovedná za dokončenie a vypracovanie požiadavky v dokumentoch k požiadavkám (na základe ktorých sa vytvárajú príbehy používateľov).

Ak existujú nejaké nejasnosti v kritériách Príbehy používateľa / Akceptácia, je to ten, koho osloví technický tím (SCRUM) a potom to postúpi PO, alebo ak je to možné, vyrieši sám. Vo veľkých projektoch môže byť viac ako 1 BA, ale v malých projektoch môže pôsobiť ako SC aj SCRUM Master.

Keď sa spustí projekt, vždy je dobré mať bakalársky titul.

6) Príbeh používateľa

Príbehy používateľov nie sú nič iné ako požiadavky alebo funkcie, ktoré je potrebné implementovať.

V skrumáži nemáme tieto dokumenty s obrovskými požiadavkami, ale požiadavky sú definované v jednom odseku, ktorý má zvyčajne tento formát:

Ako
chcem
Dosiahnuť

Napríklad :

Ako správca chcem mať uzamknutie hesla v prípade, že používateľ zadá nesprávne heslo trikrát za sebou, aby obmedzil neoprávnený prístup.

Existuje niekoľko charakteristík užívateľských príbehov, ktoré by sa mali dodržiavať. Príbehy používateľov by mali byť krátke, realistické, dali by sa odhadnúť, byť úplné, vyjednávateľné a testovateľné. Príbeh používateľa sa nikdy nezmení ani nezmení uprostred Sprintu.

Je zodpovednosťou SCRUM Master a BA (ak sú uplatniteľné), aby sa ubezpečil, že PO zostavila Príbehy používateľov správne s náležitým súborom Kritérii prijatia. “ Ak sa majú vykonať nejaké zmeny, ktoré budú mať vplyv na uvoľnenie sprintu, potom sa tieto príbehy vytiahnu zo sprintu alebo sa vykonajú podľa dostupných hodín.

Každý príbeh používateľa má kritérium prijatia, ktoré by malo byť tímu dobre definované a pochopené.

Kritériá prijatia podrobne popisujú príbeh používateľa, ktorý poskytuje podporné dokumenty. Pomáha to ďalej vylepšovať užívateľský príbeh. Kritériá prijatia si môže zapísať ktokoľvek z tímu. Testovací tím vychádza zo svojich testovacích prípadov / podmienok na týchto kritériách prijatia.

7) Eposy

Eposy sú nejednoznačné príbehy používateľov, alebo môžeme povedať, že ide o príbehy používateľov, ktoré nie sú definované a sú uchovávané pre budúce šprinty.

Skúste to spojiť so životom, predstavte si, že idete na dovolenku. Keď pôjdete budúci týždeň, máte všetko pripravené, ako sú rezervácie hotelov, prehliadky mesta, cestovné šeky atď. Ale čo plán vašej dovolenky na budúci rok? Máte iba hmlistú predstavu, že môžete ísť na miesto XYZ, ale nemáte žiadny podrobný plán.

Epic je ako vy na budúcoročný dovolenkový plán, kde viete, že možno budete chcieť ísť, ale kde, kedy, s kým, o všetkých týchto detailoch v tejto chvíli netušíte.

Podobným spôsobom existujú aj funkcie, ktoré sa v budúcnosti budú musieť implementovať a ktorých podrobnosti zatiaľ nie sú známe. Funkcia väčšinou začína epikou a potom je rozdelená na príbehy, ktoré je možné implementovať.

8) Nevybavené položky produktu

Nevybavené položky produktu sú druhom segmentu alebo zdroja, kde sú uchovávané všetky príbehy používateľov. Toto je udržiavané vlastníkom produktu. Nevybavené položky produktu si možno predstaviť ako zoznam želaní vlastníka produktu, ktorý ich uprednostňuje podľa obchodných potrieb.

Počas plánovacej schôdzky (pozri nasledujúcu časť) je jeden príbeh používateľa prevzatý z produktového backlogu, potom tím urobí brainstorming, porozumie mu a zdokonalí ho a spoločne rozhoduje o tom, ktoré užívateľské príbehy zaujme, so zásahom vlastníka produktu.

9) Sprint Backlog

Na základe priority sa príbehy používateľov preberajú z produktového backlogu ako jeden po druhom. Tím Scrumu o ňom bude debatovať, určuje uskutočniteľnosť a rozhoduje o tom, že príbehy budú pracovať na konkrétnom šprinte. Súhrnný zoznam všetkých používateľských príbehov, ktoré scrum tím pracuje na konkrétnom šprinte, sa nazýva Sprint backlog.

Sprint Backlog

10) Body príbehu

Body príbehu sú kvantitatívnou indikáciou zložitosti príbehu používateľa. Na základe bodu príbehu sa určuje odhad a úsilie o príbeh.

Bod príbehu je relatívny a nie absolútny. Aby sme sa ubezpečili, že náš odhad a úsilie sú správne, je dôležité skontrolovať, či príbehy používateľov nie sú veľké. Čím presnejší a menší je príbeh používateľa, tým presnejší bude odhad.

Každý príbeh používateľa je priradený k bodu príbehu na základe série Fibonacci (1, 2, 3, 5, 8, 13 a 21). Vyššie číslo, zložitejšie príbeh.

Byť presný

  • Ak dáte 1/2/3 príbehový bod, znamená to, že príbeh je malý a málo zložitý.
  • Ak dáte body 5/8, je to stredne zložitý a
  • 13 a 21 sú veľmi zložité.

Tu sa zložitosť skladá z vývoja a testovacieho úsilia.

Pri rozhodovaní o bode príbehu sa brainstorming odohráva v rámci skrumážneho tímu a tím spoločne rozhoduje o bode príbehu.

Môže sa stať, že vývojový tím dá konkrétnemu príbehu bod 3, pretože pre nich to môžu byť 3 riadky zmeny kódu, ale testovací tím 8 bodov, pretože má pocit, že táto zmena kódu ovplyvní väčšie moduly, takže testovacie úsilie by bolo väčšie. Nech už dávate akýkoľvek bod z príbehu, musíte to odôvodniť.

Takže v tejto situácii dôjde k brainstormingu a tím kolektívne súhlasí s jedným bodom príbehu.

Kedykoľvek sa rozhodujete o bode príbehu, nezabudnite na nasledujúce faktory:

  • Závislosť príbehu od inej aplikácie / modulu.
  • Zručnosť zdroja.
  • Zložitosť príbehu.
  • Historické učenie.
  • Kritériá prijatia užívateľského príbehu.

Ak neviete o konkrétnom príbehu, nemerajte ho veľkosťou.

Kedykoľvek má príbeh = alebo> 8 bodov, je rozdelený do dvoch alebo viacerých príbehov.

11) Spáliť graf

Vypáliť graf je graf, ktorý zobrazuje odhadované skutočné úsilie v scrum úlohách v / s.

Je to sledovací mechanizmus, pomocou ktorého sa pri konkrétnom šprinte sledujú každodenné úlohy, aby sa skontrolovalo, či príbehy postupujú k dokončeniu záväzných bodov príbehu alebo nie.

Príklad : Aby ste tomu porozumeli, pozrite sa na nasledujúci obrázok:

Vypáliť graf 1

Predpokladal som:

  • 2 týždne Sprint (10 dní)
  • 2 zdroje skutočne pracujúce na šprinte.

„Príbeh“ -> Tento stĺpec zobrazuje príbehy používateľov prijaté pre šprint.

„Úloha“ -> Tento stĺpec zobrazuje zoznam úloh spojených s príbehom používateľa.

„Úsilie“ -> Tento stĺpec zobrazuje úsilie. Týmto opatrením je teraz celkové úsilie na dokončenie úlohy. Neznázorňuje úsilie vynaložené žiadnym konkrétnym jednotlivcom.

„Deň 1 - deň 10“ -> V tomto stĺpci sú zobrazené hodiny, ktoré zostávajú na dokončenie príbehu. Upozorňujeme, že hodina NIE JE hodina, ktorá už je urobená, ale hodiny, ktoré ešte zostávajú.

„Odhadované úsilie“ -> Je celková námaha. Pre „Štart“ je to jednoducho súčet celej individuálnej úlohy: SUMA (C5: C15)

Celkový počet snáh, ktoré je potrebné dokončiť za 1 deň, je 70/10 = 7. Takže na konci prvého dňa by sa úsilie malo znížiť na 70 - 7 = 63. Podobným spôsobom sa počíta pre všetky dni do 10. dňa, kedy by odhadované úsilie malo byť 0 (riadok 16)

„Skutočné úsilie vľavo“ -> Ako už názov napovedá, zostáva skutočne úsilie potrebné na dokončenie príbehu. Môže sa tiež stať, že skutočné úsilie sa zvýši alebo zníži ako odhadované úsilie.

Na vytvorenie tohto podrobného grafu môžete použiť vstavané funkcie a graf v programe Excel.

Kroky vypálenia grafu by boli:

  1. Zadajte všetky príbehy (stĺpec A5 - A15).
  2. Zadajte všetky úlohy (stĺpec B5 - B15).
  3. Zadajte Dni (1. deň - 10. deň).
  4. Zadajte počiatočné úsilie (sčítajte úlohy C5 - C15).
  5. Pomocou vzorca vypočítajte „odhadované úsilie“ pre každý deň (1. až 10. deň). Zadajte vzorec na D15 (C16 - $ C 16 $ / 10) a ťahajte ho všetky dni.
  6. Pre každý deň zadajte skutočné úsilie. Zadajte vzorec na D17 (SUM (D5: D15)) pre sčítanie skutočného zvyšného úsilia a ťahajte ho za všetky ostatné dni.
  7. Vyberte ho a vytvorte graf nasledovne:

Vypáliť graf 2

12) Rýchlosť

Celkový počet bodov príbehu, ktoré skrumážny tím archivuje v šprinte, sa nazýva Velocity. Tím Scrum je posudzovaný alebo odkazovaný podľa jeho rýchlosti. Je však potrebné mať na pamäti, že cieľom NIE JE dosiahnutie maximálneho počtu bodov príbehu, ale dosiahnutie kvalitného výsledku pri rešpektovaní úrovne pohodlia tímu skrumáže.

Napríklad : Pre konkrétny šprint: celkový počet príbehov používateľov je 8, ktoré majú body príbehu, ako je uvedené nižšie.

Rýchlosť skrumáže

Takže tu bude rýchlosť súčtom bodov príbehu = 30

Definícia Hotovo:

Sprint je označený ako Hotový, keď sú všetky príbehy dokončené, všetky úlohy spojené s vývojom, výskumom a QA sú označené ako „Dokončené“, všetky chyby sú pevne zatvorené, okrem tých, ktoré je možné vykonať neskôr (napríklad nie úplne súvisiace alebo sú menej dôležité) sú vytiahnuté a pridané do nevybavených položiek, je dokončená kontrola kódu a testovanie jednotiek, odhadované hodiny zodpovedajú skutočným hodinám uvedeným v úlohách a najdôležitejšie je, že OV a zúčastnené strany dostali úspešné demo.

Činnosti vykonané v metodike SCRUM

# 1) Plánovanie stretnutia

Plánovacie stretnutie je východiskovým bodom Sprintu. Je to stretnutie, na ktorom sa zhromaždí celý tím skrumáží. SCRUM Master vyberie príbeh používateľa na základe priority z nevybavených produktov a tímových brainstormingov.

Na základe diskusie rozhoduje tím skrumáže o zložitosti príbehu a jeho veľkosti podľa série Fibonacci. Tím identifikuje úlohy spolu so snahou (v hodinách), ktorá by bola vykonaná na dokončenie implementácie užívateľského príbehu.

Mnohokrát predchádza plánovaciemu stretnutiu „Predbežné plánovacie stretnutie“. Je to ako domáca úloha, ktorú tím pre skrumáže robí predtým, ako sa stretne na formálnom stretnutí. Tím sa snaží zapísať závislosti alebo iné faktory, o ktorých by chcel diskutovať na plánovacom stretnutí.

# 2) Vykonávanie úloh sprintu

Ako už názov napovedá, jedná sa o skutočnú prácu vykonanú tímom skrumáže na splnenie ich úlohy a uvedenie užívateľského príbehu do stavu „Hotovo“.

# 3) Denný standup

Počas šprintérskeho cyklu sa každý deň stretáva skrumážny tím, nie dlhšie ako 15 minút (môže to byť stand-up hovor, ktorý sa odporúča mať na začiatku dňa) a uveďte 3 body:

  1. Čo včera urobil člen tímu?
  2. Čo plánoval člen tímu dnes?
  3. Nejaké prekážky (prekážky)?

Toto stretnutie uľahčuje práve Scrum master. V prípade, že sa ktorýkoľvek člen tímu stretne s akýmikoľvek problémami, následuje majster scrumu, aby to vyriešil. V Stand upoch sa tiež kontroluje nástenka, ktorá sama ukazuje pokrok tímu.

# 4) Hodnotiaca schôdza

Na konci každého šprintovacieho cyklu sa tím SCRUM opäť stretáva a predvádza implementované užívateľské príbehy vlastníkovi produktu. Produktový vlastník môže príbehy krížovo overiť podľa svojich kritérií prijatia. Za vedenie tohto stretnutia je opäť zodpovedný majster Scrumu.

Aj v nástroji SCRUM je Sprint uzavretý a úlohy sú označené ako splnené.

# 5) Spätné stretnutie

Spätné stretnutie sa koná po hodnotiacom stretnutí.

Tím SCRUM sa stretáva, diskutuje a dokumentuje nasledujúce body:

  • Čo prebehlo dobre počas Sprintu (osvedčené postupy)?
  • Čo v Sprinte nedopadlo dobre?
  • Ponaučenie
  • Akčné položky.

Tím Scrumu by mal naďalej dodržiavať najlepšie postupy, ignorovať „nie najlepšie postupy“ a implementovať skúsenosti získané počas následných šprintov. Spätné stretnutie pomáha implementovať neustále zlepšovanie procesu SCRUM.

Ako sa postupuje? Príklad!

Po prečítaní o technických jargons SCRUM. pokúsim sa demonštrovať celý proces na príklade.

Príklad:

Krok 1 : Poďme mať tím SCRUM pozostávajúci z 9 ľudí, ktorý pozostáva z 1 produktového vlastníka, 1 majstra Scrumu, 2 testerov, 4 vývojárov a 1 DBA.

Krok 2 : Sprint sa rozhodol nasledovať 4 týždňový cyklus. Takže máme 1-mesačný Sprint od 5. júna do 4. júnathjúla.

Krok č : Vlastník produktu má v nevybavenom produkte zoznam prioritných používateľských príbehov.

Krok č. 4: Tím sa rozhodol stretnúť 4.thJúna na stretnutie „Predbežné plánovanie“.

  • Produktový vlastník vezme 1 príbeh z produktového backlogu, popíše ho a prenechá ho tímu, ktorý o ňom bude diskutovať.
  • Celý tím diskutuje a komunikuje priamo s vlastníkom produktu, aby jasne pochopil príbeh používateľa.
  • Podobným spôsobom sa preberajú rôzne ďalšie príbehy používateľov. Ak je to možné, tím môže pokračovať a veľkosť príbehov tiež.

Po celej diskusii sa jednotliví členovia tímu vrátia späť na svoje pracovné stanice a

  • Pre každý príbeh určte ich jednotlivé úlohy.
  • Vypočítajte presný počet hodín, na ktorých budú pracovať. Pozrime sa, ako člen uzatvára tieto hodiny.

Celkový počet pracovných hodín = 9
Mínus 1 hodina za prestávku, mínus 1 hodina za stretnutia, mínus 1 hodina za e-maily, diskusie, riešenie problémov atď.
Skutočná pracovná doba = 6.
Celkový počet pracovných dní počas Sprintu = 21 dní.
Celkový počet dostupných hodín = 21 * 6 = 126.
Člen má dovolenku 2 dni = 12 hodín (líši sa to pre každého člena, niekto môže čerpať dovolenku a niekto nie).
Počet skutočných hodín = 126 - 12 = 114 hodín.

To znamená, že člen bude pre tento šprint skutočne k dispozícii 114 hodín. Svoju individuálnu šprintérsku úlohu teda rozdelí tak, aby dosiahol celkovo 114 hodín.

Krok č : Na 5thjúna sa stretne celý tím Scrum na „plánovacom stretnutí“.

  • Konečný verdikt užívateľského príbehu z produktového backlogu je hotový a príbeh sa presunie do Sprint Backlogu.
  • Pre každý príbeh každý člen tímu deklaruje svoje identifikované úlohy, ak je to potrebné, môže o nich diskutovať, môže ich veľkosť alebo veľkosť zmeniť (nezabudnite na sériu Fibonacci !!).
  • Majster Scrumu alebo tím zadávajú do nástroja svoje jednotlivé úlohy spolu s hodinami pre jednotlivé príbehy.
  • Po dokončení všetkých príbehov si Scrum master zaznamená počiatočnú rýchlosť a formálne spustí Sprint.

Krok č. 6 : Po spustení Sprintu začne na základe zadaných úloh každý člen tímu pracovať na týchto úlohách.

Krok č. 7 : Tím sa stretáva každý deň po dobu 15 minút a diskutuje o 3 veciach:

  • Čo robili včera?
  • Čo plánujú urobiť dnes?
  • Nejaké prekážky (prekážky)?

Krok č. 8 : Scrum master sleduje pokrok na dennej báze pomocou „Burn down chart“.

Krok č. 9 : V prípade akýchkoľvek prekážok následuje majster Scrumu, aby ich vyriešil.

Krok č. 10 : 4.thJúla sa tím opäť stretáva na hodnotiacom stretnutí. Člen demonštruje implementovaný príbeh používateľa vlastníkovi produktu.

Krok č. 11 : 5. dňathJúla sa tím opäť stretáva pri retrospektíve, kde diskutujú

  • Čo dopadlo dobre?
  • Čo nedopadlo dobre?
  • Akčné položky.

Krok č. 12 : 6.thJúla sa tím opäť stretne na predbežnom stretnutí pre ďalší šprint a cyklus pokračuje.

skromný agilný metodický proces

SCRUM Activity Tools

Existuje niekoľko nástrojov, ktoré sa dajú vo veľkej miere použiť na sledovanie aktivít skrumáže.

Niektoré z nich zahŕňajú:

V nadchádzajúcom návode by sme objasnili Agilný manifest, čo je pojem, ktorý poháňa efektívne agilné tímy.

Ďalšia príručka

O autoroch: Túto sériu napísali títo členovia tímu STH: Shruti Shrivastava - profesionálny majster Scrumu s 9-ročnými skúsenosťami v doménach BFSI, E-commerce a B2B. Shruti je odborníkom na testovanie automatizácie a vedie skrumážne tímy.

Anshul Kumar Srivastava - profesionál v oblasti produktového manažmentu zameraný na výsledky a agilný pracovník so 7-ročnými skúsenosťami v sektoroch BFSI a Telecom.

Odporúčané čítanie

^