životní cyklus vývoje softwaru (SDLC). Scrum Model krok za krokem

0 Comments

Scrum framework umožňuje implementaci agilní metodiky vývoje. Na rozdíl od Vodopád modelu vývoje softwaru, Scrum umožňuje iterativní a inkrementální vývojový proces. Projekt se dělí do několika fází, z nichž každá má za následek produkt připravený k použití. Na konci každého kroku (nazývaného sprint v terminologii Scrum) je zákazníkovi dodán použitelný produkt., Zpětná vazba od zákazníků pomáhá odhalit možné problémy nebo v případě potřeby změnit počáteční plán rozvoje. Pokud chcete, aby váš projekt striktně dodržoval hlavní principy agilního manifestu, můžete použít model Scrum a být si jisti, že jste na správné cestě.

Zde jsou hlavní role podílející se v procesu vývoje, podle Scrum model:

  • vlastník produktu se stará o koncového uživatele zájmy;
  • Scrum master koordinuje celý proces vývoje., Dalším úkolem je zajistit správné používání Scrumu a pořádat pravidelné Scrum meetingy;
  • tým Scrum vyvíjí produkt. Jeho hlavními úkoly jsou Programování, Analýza, testování atd.

nyní se podívejme na hlavní kroky vývojového procesu, ze kterého se Scrum skládá.

Fáze Scrum modelu

Krok 1. Product Backlog Creation

a Product backlog je seznam, který obsahuje funkce, které mají být implementovány během procesu vývoje. Je objednán podle priority a každá položka se nazývá uživatelský příběh. Každý uživatel příběh dostane jedinečný ID., Uživatelské příběhy mají zpravidla následující formát :jako a, chci to tak. Tento seznam níže ukazuje, jak mohou tyto příběhy vypadat.,ange trvání a datum zahájení aktuálního ty, pomocí drag-and-drop tak, že můžu odhadnout celkovou dobu projektu

-003 Jako manažer, chci přiřadit dva typy úkolů zaměstnanců: částečný úvazek úkol, a to na plný úvazek úkol, takže můžu lépe řídit úkolu stanovení priorit

Kromě těchto povinná pole, volitelná ty mohou být přidány v případě potřeby.

  • skladba se používá k vybrat všechny uživatelské příběhy určitého typu změnit jejich prioritu., Lze jej použít ke zvýšení priority uživatelských příběhů, které se týkají ovládacího panelu, například; komponenty
  • tvoří seznam komponent, které budou během práce změněny. Aplikace má moduly, jako je například autentizace nebo vyhledávání, například;
  • žadatel je zákazník, který má zájem o realizaci některé konkrétní funkce;
  • Bug tracking ID obsahuje seznam zjištěných chyb, které se týkají správné uživatelské příběh.

Krok 2. Plánování sprintu a vytvoření backlogu sprintu

nejprve byste měli určit, jaká bude doba trvání sprintu., Krátký sprint vám umožní častěji uvolňovat pracovní verzi produktu. V důsledku toho bude zpětná vazba od zákazníků přijímána častěji a všechny možné chyby a chyby budou odhaleny včas.

jako alternativu můžete upřednostňovat delší dobu sprintu. Umožní vývojářům pracovat důkladněji. Optimální délka sprintu je definována jako průměr těchto dvou možností. V modelu Scrum zpravidla trvá sprint asi 2-4 týdny. V této fázi je důležitější cíl sprintu. Cíl je určen pro každý sprint., A v souladu s tím je sprint plný uživatelských příběhů. Další důležitou věcí je spolupráce mezi zúčastněnými stranami a členy týmu. Majitel produktu určuje důležitost správného uživatelského příběhu, zatímco tým Scrum definuje příslušné náklady na pracovní sílu.

poté může tým Scrum vybrat nejdůležitější uživatelské příběhy z nevyřízených produktů. Pak by se členové týmu měli rozhodnout, jak vyřeší tento nebo ten úkol. Tým také může rozdělit konkrétní uživatelské příběhy na ty nejmenší a poté je proměnit v řadu úkolů., Další by měl být vytvořen backlog sprintu. Skládá se z uživatelských příběhů, které budou dokončeny během aktuálního sprintu. Množství těchto příběhů závisí na jejich kapacitě v příběhových bodech přiřazených ke každému příběhu během fáze hodnocení. Tým Scrum by měl být schopen dokončit všechny tyto příběhy včas.

Krok 3. Pracuju na sprintu. Denní Scrum Meetings

po výběru skutečných uživatelských příběhů pro aktuální fázi začíná proces vývoje.

pro sledování aktuálního pracovního procesu se běžně používá deska úloh., Obvykle existují velké karty se jmény konkrétních uživatelských příběhů a svazek malých poznámek s popisem jednotlivých úkolů, které jsou potřebné pro implementaci tohoto nebo toho příběhu. Každá konkrétní deska je vyvinuta podle specifik projektu. Podívejme se na malý příklad.

karty mohou být uspořádány podle jejich důležitosti. Po spuštění práce na úkolu se odpovídající nálepka přesune z pole „udělat“ do pole „probíhající“., Po dokončení práce lze nálepku přesunout do pole“ testování „a po úspěšném testování se nálepka dostane do pole“ Hotovo“. Příklad, jak Scrum task board může vypadat jako je uvedeno níže:

k Dispozici je také možnost použít specializovaný software pro tento úkol.

například Atlassian JIRA.

Další důležitou funkcí Scrum je denní Scrum meetings., Tato setkání‘ hlavním cílem je získat úplný a věrohodný informace o aktuálním stavu projektu a ujistěte se, že všichni členové týmu jsou na stejné stránce. Během schůzek Scrum by měl každý člen týmu říct, co udělal pro cíl sprintu, který úkol bude další a jaké problémy členové týmu během práce čelili.

kromě toho je burndown chart dalším široce používaným nástrojem, který umožňuje efektivní sledování denních procesů. Ukazuje vám, kolik úkolů zůstává nedokončeno., Tento graf dává schopnost řídit proces vývoje a může být aktualizován po každém setkání.

každodenní Scrum meetingy pomáhají zvyšovat flexibilitu vývojového procesu. Umožňují také pochopit, jaké změny by měly být provedeny.

Osa X představuje zbývající dny práce, zatímco osa Y zobrazuje celkové množství příběhových bodů pro aktuální fázi. Po dokončení úkolu, který vyžaduje určitý počet příběhových bodů, je u konce, můžete přidat bod na diagramu a označit aktuální pokrok.,

JIRA umožňuje vytvořit tyto grafy i:

Tento graf pomáhá vyvodit závěry o aktuální rychlosti práce. V závislosti na těchto závěrech lze změnit počet uživatelských příběhů pro další sprint.

je důležité si uvědomit, že vzhledem k tomu, že ideálním výsledkem každého sprintu v modelu Scrum je pracovní produkt, je velmi důležitý celý proces testování životního cyklu. Existují různé způsoby, jak minimalizovat náklady na zkušební období. Můžete například snížit celkové množství uživatelských příběhů., V důsledku toho bude počet možných chyb minimalizován. Druhou cestou je zahrnout inženýry QA do týmu Scrum.

Přečtěte si Také, Proč QA Hraje Klíčovou Roli v High-Kvalitní Software, Vývoj Produktu

Krok 4. Product Increment and Sprint Review

výsledkem každého sprintu v Scrumu je potenciálně přenositelný přírůstek produktu, který může být prokázán zákazníkovi. Po každé iteraci vytvoří vývojový tým novou verzi Softwarového produktu se zvýšenou hodnotou., Během přezkumu sprintu, který je koncovou částí každého sprintu, lze celkové výsledky prokázat a analyzovat. Na základě všech těchto informací mohou zúčastněné strany rozhodnout o dalších změnách projektu a naplánovat další sprint.

Krok 5. Retrospektivní a další plánování sprintu

hlavním cílem retrospektivy je diskutovat o výsledcích a určit způsoby, jak zlepšit vývojový proces v dalším kroku., Důležitým rysem je, že v této fázi jsou diskutovány procesy práce a interakce, aby se zlepšila práce týmu Scrum jako celku. Tým by měl dospět k závěru, co šlo dobře během pracovního procesu a co lze během budoucí iterace udělat lépe. Když jsou definovány způsoby zlepšení, tým se může soustředit na další plánování sprintu.

závěr

hlavními charakteristickými rysy Scrumu jsou agilita a neustálý pokrok. Je poskytována převážně trvalou komunikací a úzkou spoluprací mezi zúčastněnými stranami na každém kroku., Scrum přístup znamená kontinuální iterativní a inkrementální vývojový proces. Cílem je zajistit možnost neustále zvyšovat hodnotu produktu a udržovat flexibilitu při výběru priorit pro další iterace.

Když sprint je dokončena, zákazník může hodnotit pracovní funkce produktu v aktuální iteraci a učinit informované rozhodnutí o tom, jak by měl projekt vyvíjet během příštích sprinty.,

přestože podle Agile manifesto byste měli upřednostňovat pracovní software Před komplexní dokumentací, nic nebrání vývojářům v používání specifikace požadavků na Software. SRS je dobré říkat, co by měl systém nebo produkt dělat. Navzdory tomu může SRS chybět některé agilní aspekty vývoje projektů, jako je spolupráce, může to být stále dobrý nástroj pro plánování a plánování.

Free Estimation Template + PERT
šablona pro odhad nákladů a trvání projektu., Vypočítejte všechna možná rizika a možné trvání projektu.


Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *