Vodopád Agile Vs: Která je nejlepší metodika pro váš projekt?

agile vs waterfall which is best methodology

kdo je nejlepší poskytovatel e-mailu

Zjistěte vše o metodikách Agile and Waterfall, různých typech modelů SDLC a rozdílech mezi modely Waterfall vs Agile Development a také o testování:

Přečtěte si tento informativní článek a na základě výhod a nevýhod každého z nich se rozhodněte, který je nejvhodnějším modelem pro váš projekt.

Waterfall Model a Agile Model jsou typy životního cyklu vývoje softwaru (SDLC). Jedná se o proces používaný softwarovým průmyslem k navrhování, vývoji a testování softwaru.

Dodržováním SDLC můžeme dosáhnout očekávání zákazníků, dokončit projekt v daných časových rámcích a odhadnout náklady.

Co se naučíte:

• Vodopád a agilní pracovní postupy
  • Co je životní cyklus vývoje softwaru?
  • Druhy životního cyklu vývoje softwaru
    • # 1) Model vodopádu
    • # 2) Agilní model
    • # 3) Spirálový model
    • # 4) Prototypový model
    • # 5) Model V a V.
• Model vodopádu
• Agilní pracovní postup
  • Klíčové terminologie používané v agile
  • Klíčové faktory pro přijetí agilní metodiky
  • Druhy agilních metodik
• Rozdíl mezi modely Agile Vs Waterfall
• Rozdíly mezi agilním testováním a testováním vodopádů
• Závěr
  • Doporučené čtení

Vodopád a agilní pracovní postupy

V jednoduché angličtině znamená Agile „schopnost rychle a snadno se pohybovat“, a proto to znamená, když jde o Metodika agilního rozvoje .

Agilní je metoda projektového řízení, kterou představuje rozdělení úkolů na kratší segmenty práce s častými kontrolami a přizpůsobováním plánů.

Podobně slovo vodopád označuje vertikální tok vody nebo tok vody řadou strmých kapek. Model vodopádu je lineární sekvenční model, ve kterém postup plyne hlavně jedním směrem dolů fázemi shromažďování požadavků, analýzy, designu, vývoje, testování, nasazení a údržby.

Stejná ilustrace platí pro koncepci projektového řízení, pokud jde o model vodopádu . Jedná se o metodu projektového řízení, kterou představují sériové etapy a pevný plán práce.

(obraz zdroj )

Před diskusí o pracovním postupu Waterfall a agilním pracovním postupu se podívejme na definici životního cyklu vývoje softwaru a jeho požadavky.

Co je životní cyklus vývoje softwaru?

Jedná se o postupný postup systematického vývoje softwaru. Z tohoto důvodu vybíráme z různých typů životních cyklů vývoje softwaru v různých společnostech. Na základě požadavku je vybrán vhodný životní cyklus.

Model vodopádu je jedním z typů SDLC a jedná se o starý proces vývoje softwaru. Agilní model je nejnovější a pokročilý. Agile je odvozen z jiného životního cyklu vývoje softwaru.

Další SDLC zahrnuje spirálový model, model V a V, model prototypu. Na základě nezbytnosti a kompatibility obchodních požadavků vybereme nejlepší model pro vývoj softwarové aplikace.

(obraz zdroj )

Proč je vyžadován životní cyklus vývoje softwaru?

SDLC je vyžadováno ke strukturovanému řízení projektu. Poskytuje určitou úroveň kontroly a definuje role a odpovědnosti členů týmu. Poskytuje rozsah a termín pro každou fázi v SDLC.

Je to něco jako uživatelská příručka k členům týmu, aby následovali všechny kroky k vývoji a dodávce kvalitního produktu. Pomáhá vedení týmu definovat a hodnotit cíle a požadavky. Pomáhá také při plánování a odhadu úkolů. Vytváří komunikační linku mezi klientem a vývojovým týmem a vytváří role a odpovědnosti pro každého z nich.

Druhy životního cyklu vývoje softwaru

Podívejme se na krátký úvod k typům SDLC používaných v procesu vývoje softwaru.

# 1) Model vodopádu

Jak již bylo řečeno, model vodopádu je prvním zavedeným životním cyklem vývoje softwaru. Jedná se o sekvenční způsob vývoje softwaru. Tento přístup dodržuje jen velmi málo společností. Pokud je projekt velmi jednoduchý a nedojde k žádným dalším změnám požadavků, použijeme tento přístup.

V tomto tutoriálu budeme diskutovat více o modelu vodopádu.

# 2) Agilní model

Agilní pracovní tok je pokročilý přístup k procesu vývoje softwaru, který se používá ve většině společností. Agile je definován jako životní cyklus vývoje softwaru založený na sprintu.

V nadcházejících částech můžeme probrat více o agilním pracovním postupu.

# 3) Spirálový model

Jedná se o způsob vytváření a testování softwaru rozdělením a přidáním požadavku v přírůstkovém pořadí. Tento model pomůže v projektech, kde se požadavky neustále mění. Tento spirálový model je kombinací procesu iteračního vývoje a procesu postupného lineárního vývoje.

Tento přístup nám umožní postupné uvolňování produktu. Zde není nutné čekat na dokončení všech modulů softwaru pro vydání.

Lineární sekvenční model znamená, že se jedná o systematický sekvenční přístup vývoje softwaru, který začíná na úrovni systému a postupuje analýzou, návrhem, kódováním, testováním a podporou.

Iterativní model znamená, že se jedná o konkrétní implementaci životního cyklu vývoje softwaru, která se zaměřuje na počáteční zjednodušenou implementaci, která pak postupně získává na složitosti a nastavuje se širší funkce, dokud nebude finální systém kompletní.

# 4) Prototypový model

Tento model zahrnuje proces vytváření a testování softwaru takovým způsobem, že nejprve vytvoříme fiktivní model a pokud je to proveditelné a splníme všechny obchodní požadavky, implementujeme skutečný funkční model.

Zde jsme nejprve postavili a otestovali prototyp, poté jsme postavili skutečný model s přesnými specifikacemi systému. Softwarové prototypování je činnost vytváření prototypů softwarových aplikací.

# 5) Model V a V.

Jedná se o model ověřování a ověřování. Zde jsme při vývoji softwaru používali k ověřování a ověřování všeho v každé fázi SDLC. V-model je považován za rozšíření modelu vodopádu.

Takže všechny typy SDLC mají své vlastnosti a vlastnosti. Na základě požadavků projektu, potřeb, proveditelnosti, doby trvání si můžeme vybrat konkrétní životní cyklus vývoje softwaru pro vývoj softwarové aplikace.

Nyní budeme podrobně diskutovat o životních cyklech vývoje softwaru Waterfall a Agile.

Model vodopádu

V modelu Waterfall by každá fáze měla být dokončena před zahájením další fáze. Nemůžeme provozovat více fází současně. Toto představil v roce 1970 Winston Royce. Model Waterfall je rozdělen do různých fází.

(obraz zdroj )

Waterfall Model zahrnuje následující fáze:

1. Sběr požadavků
2. Studie proveditelnosti
3. Design
4. Kódování
5. Testování
6. Údržba

# 1) Analýza požadavků

Zde dostane obchodní analytik specifikaci požadavků. Požadavek bude ve formátu CRS (Specifikace požadavku zákazníka). CRS vysvětluje, jak by měl obchodní tok probíhat a jak by aplikace měla fungovat podle zadaného požadavku. Obchodní analytici převedou CRS na SRS (Specifikace softwarových požadavků).

Poté obchodní analytik podrobně prodiskutuje specifikace požadavků s vývojovým a testovacím týmem a rozumí požadavku z hlediska vývoje a testování. V této fázi se diskutuje a analyzuje požadavky na sestavení aplikačního softwaru na základě skutečných požadavků.

Zde by mělo být vše zdokumentováno v dokumentu se specifikací softwarových požadavků. V modelu vodopádu je výstup / fáze / výstup každé fáze vstupním zdrojem pro další fáze.

V odvětví založeném na službách může požadavek přinést obchodní analytik.
V produktové společnosti přináší produktový analytik požadavek.

# 2) Studie proveditelnosti

Manažerský tým provede studii proveditelnosti. Znamená to, že tým bude analyzovat parametry jako: je tento požadavek / aplikaci možné vyvinout v našem prostředí nebo ne, dostupný zdroj je dostatečný nebo ne, náklady a mnoho dalších faktorů jsou proveditelné nebo ne a zkontrolovat, zda jsme schopni pokrýt všechny obchodní toky nebo ne.

Na této schůzce / analýze bude součástí diskuse projektový manažer, obchodní analytik, finanční manažer, HR, vedoucí projektu.

# 3) Návrh systému

Zde projektový architekt připraví návrh systému. Specifikuje hardware, systémové požadavky a navrhne architekturu aplikace. V návrhu systému jsou 2 části: design na vysoké úrovni a design na nízké úrovni. V designu na vysoké úrovni navrhujeme různé bloky aplikace. V nízkoúrovňovém designu píšeme pseudokód.

# 4) Kódování

Zde vývojáři začínají přesné kódování každé funkce a uživatelského rozhraní aplikace pomocí různých metod a různých logik. K sestavení aplikace mohou použít libovolný programovací jazyk, jako je Java, Python nebo jiný jazyk.

Po dokončení kódování pro každou funkčnost konkrétního modulu aplikace provede vývojář testování jednotky. Pokud kód funguje dobře, vývojář nasadí kód do testovacího prostředí a dá sestavení testeru k testování.

# 5) Testování

Odtud začíná testovací aktivita. Do této fáze nebudeme mít v modelu Waterfall žádný úkol. V této fázi provádíme všechny typy testování. Mezi tyto typy testování patří kouřové testování, funkční testování, testování integrace, testování systému, akceptační testování, regresní testování, testování ad-hoc, průzkumné testování a testování napříč prohlížeči.

Jakmile aplikaci získáme, začneme ji testovat. Nejprve začneme kouřovými testy. Pokud nejsou pozorovány žádné problémy s blokováním, budeme pokračovat v podrobném testování.

Ve funkčním testování začneme testovat každou komponentu aplikace. Zde kontrolujeme různé komponenty, jako jsou textová pole, tlačítka, odkazy, přepínače, tlačítka pro nahrávání, rozbalovací nabídky a navigační odkazy.

Dále zkontrolujeme uživatelské rozhraní, vzhled a chování a testování pozitivních a negativních vstupů.

Pak začneme s integračním testováním. Zde zkontrolujeme integraci dat. Ověření, zda se stejná data odrážejí na různých příslušných stránkách, či nikoli, ověří navigaci e-mailového odkazu na příslušné stránky. Zkontrolujeme integraci dat s aplikacemi třetích stran a zkontrolujeme změny databáze v aplikaci.

Dále provedeme testování systému. Zkontrolujeme celou aplikaci jako jednu jednotku. Zkontrolujeme funkčnost, integraci stránek, ověření pole, chybové zprávy, potvrzovací zprávy a mnoho dalšího.

Během testování aplikace zaznamenáme problémy do nástroje pro sledování chyb. Na základě problémů dáme přednost chybě. Po vytvoření chyby ji přiřadíme příslušnému vývojáři, aby problém vyřešil. Jakmile je vývojáři po opravě přiřadíte testerům, chyby ověříme. Pokud to funguje dobře, tester chybu zavře, jinak testeři přiřadí zpět vývojáři, aby problém vyřešili. Takto pokračuje životní cyklus chyby.

Poté přejdeme k přejímacímu testování. Zde testujeme aplikaci v různých prostředích, jako je staging a UAT (User Acceptance Testing). Toto je nejdůležitější fáze pro důkladné otestování aplikace, než přesuneme kód do produkčního prostředí.

Jakmile je akceptační testování provedeno bez chyb, bude klient plánovat nasazení kódu na produkční server a plán vydání.

# 6) Údržba

Jakmile nasadíme kód aplikace na produkční server, měli bychom klientské aplikaci poskytnout podporu / údržbu. Tato fáze údržby je sledovat a opravit problémy s produkcí v reálném čase, zkontrolovat problémy s pamětí, vylepšit aplikaci a vyvinout nové změny požadavků.

V jakých případech se můžeme rozhodnout pro model vodopádu?

• Pokud neexistují žádné požadované změny.
• Když je projekt malý a jednoduchý.
• Když v technologii není složitost.
• Když je k dispozici více zdrojů.

Vodopád Pros:

• Dopředu Dozadu plánování a implementace je snadná .
• Model vodopádu je snadno použitelný a snadno pochopitelný. Nevyžaduje žádné speciální školení pro projektové manažery nebo zaměstnance. Má snadná křivka učení .
• Být přísný v přírodě, to je snadno ovladatelný vodopádový cyklus. Každá fáze má pevné výsledky a proces kontroly.
• Méně složitosti protože fáze se nepřekrývají. Fáze jsou sledovány jedna po druhé. Ve srovnání s ostatními metodikami vývoje softwaru používá jasnou strukturu. Projekt prochází pevnými sekvenčními kroky počínaje shromažďováním požadavků a nakonec přistává při údržbě.
• Kvůli postupnému vývoji disciplína je prosazována a časové harmonogramy lze snadno udržovat.
• Funguje dobře pro malé projekty kde máme pevné a křišťálově čisté požadavky.
• Procesy a výsledky jsou dobře zdokumentované .
• Uspořádání úkolů je snadné.
• to je snadno měřit pokrok protože jsou předem určeny počáteční a koncové body každé fáze.
• V celém projektu nedochází téměř k žádné změně požadavků, proto úkoly zůstávají stabilní pro vývojáře. Je to pro každého snadné nový vývojář, který se rychle učí a začít pracovat.
• Existují žádná finanční překvapení . Jakmile jsou požadavky stanoveny, lze před zahájením vývoje vypočítat konečné náklady.
• Záleží na a model postupného financování .
• Své podrobný design dává všem konečný očekávaný výsledek velmi jasný.
• Specifikace funkčních požadavků zdokumentovaná ve fázi shromažďování požadavků poskytuje testerům dostatek podrobností, aby mohli navrhnout scénáře testování a testovací případy. Proto je proces testování se stává snadným v modelu vodopádu.

Nevýhody vodopádu:

• Protože před zahájením vývoje musí být jasně známy všechny požadavky zdržuje projekt .
• Vyžaduje rozsáhlý výzkum do potřeb uživatele.
• V počáteční fázi projektu je pro zákazníka náročné jasně definovat a koncipovat své požadavky ve formě funkčních specifikací. Proto pro ně existuje vysoká možnost změnit názor poté, co uviděli konečný produkt. K této změně může dojít také v důsledku obchodního plánu nebo vlivu trhu. Nízká flexibilita v tomto modelu to umožňuje je obtížné tyto změny přizpůsobit , zvláště když je třeba produkt do značné míry přepracovat.
• Žádný funkční model se vyrábí až do později etapa během životního cyklu vodopádu.
• Pomalé dodací lhůty . Zákazník není schopen produkt vidět, dokud není zcela dokončen.
• Zákazník nemá možnost se předem seznámit se systémem. Model vodopádu je více interní proces a udržuje vyloučeného koncového uživatele .
• The klient není informován o zdraví projektu.
• Lhůty lze zmeškat pokud není dodržováno přísné řízení a pravidelné monitorování.
• Tady je žádný prostor pro změny i když je to během vývoje viditelné, protože produkt nebude vyhovovat požadavkům trhu.
• Zpoždění testování až po dokončení. Velké revize jsou v tomto okamžiku také velmi nákladné.
• Vysoké riziko a nejistota jsou zapojeni do modelu vodopádu, protože existuje příliš mnoho prostoru pro to, aby problémy zůstaly bez povšimnutí, dokud se projekt blíží ke konci.
• Není vhodný model pro dlouhé, složité a probíhající projekty.
• Je to těžké změřit pokrok v každé fázi.
• Během mnoha fází projektu budou testeři nečinní.

Agilní pracovní postup

Nyní uvidíme životní cyklus vývoje softwaru Agile Software. Agilní je proces rychlé a snadné práce s vyšší přesností.

Tento model souvisí s metodou projektového řízení, používanou zejména pro vývoj softwaru. Vyznačuje se rozdělením úkolů na krátké pracovní fáze a častým přehodnocováním a přizpůsobováním plánů. Každý člen týmu by měl mít představu o základních obchodních tocích.

(obraz zdroj )

V Agile vývojáři a testeři paralelně pracují na vývoji a testování aplikačního softwaru. Vývoj probíhá v iteračním režimu. Každý příběh uživatele s iterací vyžaduje analýzu, design, kódování a testování.

Požadavek podrobně otestujeme, abychom ověřili, zda je požadavek bezchybný a implementovatelný či nikoli. Po skončení každé iterace přepněte na další iteraci a stejným postupem postupujeme podle nových / dalších požadavků.

Tento proces vývoje a testování bloku softwaru se tedy provádí v krátkém čase s větší přesností a flexibilitou. Tento proces tedy sleduje a osvojuje si více průmyslových odvětví.

Nejprve vlastník produktu přidá všechny požadavky do nevyřízeného produktu. Nevyřízené položky produktu obsahují všechny uživatelské příběhy. Řekněme, že 100 až 150 uživatelských příběhů souvisí s celým projektem. Nyní přidejte konkrétní uživatelské příběhy do nevyřízeného sprintu, který musíme implementovat. Poté budou všichni vývojáři, QA, BA, pracovat na položkách sprintu. Takto funguje agilní tok.

Klíčové terminologie používané v agile

Co je nevyřízený sprint?

jak otevřete soubor apk

Je to seznam uživatelských příběhů, které musíme implementovat v aktuální iteraci nebo sprintu.

Například, v backlogu sprintu je 20 až 30 uživatelských příběhů. Pak jsou to příběhy uživatelů, které musíme implementovat v aktuálním sprintu.

(obraz zdroj )

Co je to Sprint?

Sprint je malá doba, po kterou musíme implementovat vybrané uživatelské příběhy v určité době. Délka sprintu bude přibližně 2 až 3 týdny. Jeho trvání se u jednotlivých společností liší.

V tomto trvání sprintu musí tým analyzovat požadavek, navrhnout požadavky, provést kódování, testování, vyřešení problému, opětovné testování, regresní testování, ukázku a mnoho dalších aktivit.

Denní stand-up scrum setkání

Business Analyst, Developer, Tester, the Project Manager are part of daily stand up scrum meeting. Dělá se to denně. Nemělo by to trvat déle než 15 až 30 minut.

Zde budou všichni členové týmu sdílet denní stav práce. Hlavní věci, o kterých zde diskutujeme, jsou: jaké jsou věci dokončené včera, plán dnešní práce a jakékoli výzvy nebo závislosti, kterým v projektu čelí.

Pokud některý člen týmu čelí během projektu jakýmkoli výzvám nebo překážkám, dotyčná osoba na tom bude pracovat, aby to zvládla.

Burndown graf

Jedná se o obrazovou grafickou reprezentaci času a práce. Osa x představuje zbývající práci, osa y představuje zbývající čas sprintu. Tým musí vytvořit pracovní úkoly týkající se času dostupného v konkrétním sprintu. Tým bude denně spalovat pracovní hodiny na základě práce, kterou odpracovali a dokončili.

(obraz zdroj )

Kanbanový graf

Jedná se o graf / nástroj pro řízení projektů. Díky tomu dokážeme řídit úkoly celého projektu. Můžeme zkontrolovat stav postupu projektu a stav práce jednotlivců. Zobrazuje obrazovou digitální reprezentaci pokrokových položek, nevyřízených položek, hotových položek.

(obraz zdroj )

otázky na technickou podporu úrovně 1

Plánování pokerové aktivity

Je to hra mezi členy týmu sprintu, která odhaduje příběhy uživatelů. Zde bude celý tým hrát pokerovou aktivitu. Každý člen týmu dává odhad na základě bodu příběhu uživatele. Na základě většinového odhadu hlasů rozhodne tým a přidělí časový úsek.

Například , jeden člen týmu příběhu uživatele dá odhad jako 3, 5, 8, 3, 1, 3. Poté tým vybere jako odhad 3. Karta aktivity pokeru obsahuje 0, 1, 3, 5, 8, 13, 20, 100, zlomek, pochybnosti? karty. Na základě toho navrhnou členové týmu jakoukoli kartu odhadu. Takto odhadneme všechny uživatelské příběhy, které souvisejí s konkrétním sprintem.

(obraz zdroj )

• 0 pokerových čísel představuje: žádný příběh v této položce / příběhu uživatele
• 1, 3 čísla představují: úkol je menší
• 5, 8 čísel představuje: úkoly na střední úrovni
• 13, 20 číslo představuje: úkoly na velké úrovni
• 100 číslo představuje: velmi velké úkoly
• Nekonečno představuje: Úkol je obrovský, je třeba ho rozdělit na více úkolů a příběhy uživatelů
• Přestávka představuje: potřebovat přestávku
• ? Představuje: Pochybnosti

Scrum Master

Je to osoba, která pomáhá týmu sledovat agilní proces a splnit požadavky projektu. Setkání povede, kdykoli je to nutné, a pomáhá diskutovat o potřebách projektu.

Scrum master funguje jako most ke všem členům týmu, aby vyřešili výzvy a závislosti, které na projekt narážejí. Bude sledovat postup projektu týkající se každého sprintu.

Podílí se na samostatném setkání, retrospektivním setkání, kontrole, kontrole, ukázce. On je ten, kdo vede každodenní stand up meetingy a provádí aktualizaci členů týmu.

Vlastník produktu

Je osobou, která řídí a sleduje produkt / projekt z obchodního hlediska. Stále sleduje, zda je produkt vyvíjen podle obchodních požadavků nebo ne. Je to ten, kdo upřednostňuje příběhy uživatelů a přesunul požadavky z nevyřízeného produktu do nevyřízeného sprintu. Odhadne termíny projektu.

Na produkt se vždy dívá z pohledu uživatele. Vlastník produktu má úplné znalosti o tom, jak by aplikace měla fungovat.

Příběh uživatele

Je to blok požadavků. Obsahuje sadu případů / požadavků, které se vztahují ke stejnému modulu. Zde definujeme, jak by měla fungovat každá součást aplikace a jak by mělo uživatelské rozhraní vypadat. Rozsah jednotlivých komponent je definován v uživatelském příběhu.

Úkoly

Členové týmu vytvoří úkol pro příběh uživatele, který je jim přiřazen. Musí vytvořit úkol na základě různých úkolů, jako je vývojový úkol, testovací úkol, úkol analýzy příběhu uživatele. Délka úkolu by měla záviset na bodech příběhu uživatele.

Jako tester vytvoříme úkoly pro analýzu příběhů uživatelů, přípravu testovacích případů, provádění, regresní testování a mnoho dalších.

Nevyřízené zastřihování

Tato část zahrnuje správu položek nevyřízených položek. Mezi činnosti, které zde děláme, patří upřednostňování nevyřízených položek, rozdělení na menší položky, vytvoření úkolu a aktualizace kritérií přijetí.

Opakování

Iterace je vývoj a testování některých modulů / částí softwarové aplikace. Každá iterace sestává z analýzy produktu, návrhu produktu, vývoje produktu, testování produktu a ukázky produktu.

Klíčové faktory pro přijetí agilní metodiky

• Pozorování: Pravidelně kontrolujte práci a produkt a podle toho naplánujte činnosti. Proces vývoje produktu a kvalita produktu budou tedy dobré.
• Uvítací změny: Změny jsou zpracovány velmi snadno. Na produkt to příliš neovlivní, protože moduly softwaru jsou vyvíjeny samostatně a integrovány později. Pokud se požadavek v budoucnu změní, nedojde k žádnému přepracování.
• Časové okno: Dostáváme časový rámec pro každou jednotku aplikace. Odhad bude tedy přesný k odhadům času projektu.
• Spokojenost zákazníků: Spokojenost zákazníků spočívá v tom, že během celého projektu spolupracujeme s klientem a akcionářem a poskytneme demo na každé úrovni vývoje produktu. Tím získáváme pravidelně zpětnou vazbu od zákazníka / klienta o obchodních tocích a postupu práce. Práce a vývoj aplikace jsou tedy prováděny odpovídajícím způsobem.

Druhy agilních metodik

• Metodika agilního skrumáže
• Štíhlý vývoj softwaru
• Kanban
• Extrémní programování (XP)
• Krystal
• Metoda vývoje dynamických systémů (DSDM)
• Feature Driven Development (FDD)

Agilní profesionálové:

• Jednou z největších výhod agilního modelu je jeho velká přizpůsobivost . Adaptabilita znamená „reagovat na změnu“. Agile je velmi flexibilní při řešení změn v potřebách a prioritách zákazníků.
• Umožňuje neustále vylepšovat a znovu upřednostňovat celkový nevyřízený produkt aniž by to ovlivnilo aktuální iteraci, ve které se tým zaměřuje na poskytování MVP. Změny lze naplánovat na další iteraci, což nabízí příležitost k provedení změn pouze během několika týdnů.
• Agilní metodologie nabízí velkou míru zapojení zúčastněných stran . Klient a projektový tým se setkávají před, během a po každém sprintu. Protože je zákazník do celého projektu neustále zapojen, má tým více příležitostí jasně pochopit jeho vizi.
• Pracovní software je dodáván brzy a často. Tím se zvyšuje důvěra zúčastněných stran v týmu a povzbuzuje tým k tomu zůstaňte velmi oddaní k projektu.
• Tento model dává průhlednost . Zainteresované strany i tým dobře vědí o tom, co se děje. Klient může vidět probíhající práci.
• Opravené plánované sprinty jednoho až čtyř týdnů umožňují včasné a předvídatelné doručení . Nové funkce jsou vydávány rychle a často časově omezeným způsobem.
• Agilní je zákaznicky orientovaný . Nejenže poskytuje funkčnost, ale také se zaměřuje na poskytování funkce, která má pro uživatele určitou hodnotu. Každý příběh uživatele má obchodní akceptační kritérium.
• Cenný zákaznická zpětná vazba je získán brzy v projektu a podle potřeby lze provést změny produktu.
• Důraz je kladen na obchodní hodnotu . Nejprve přináší to, co je pro klienta nejdůležitější.
• Zlepšuje kvalitu výstupů . Na rozdíl od vodopádu se testování průběžně a často provádí v agilním projektu, což zase pomáhá včas odhalit a opravit problémy.
• Agilní podporuje přístup TDD (Test Driven Development) což poskytuje dostatek času na vytvoření jednotkových testů pro funkce, které budou vydány prostřednictvím MVP.
• Také produkcí časté stavby , jakékoli nesoulad s požadavky zákazníka lze také zjistit a opravit včas.
• Jak jsme se dostali okamžitá zpětná vazba od uživatelů po každém vydání MVP se riziko selhání projektu je nízké, když pracujete svižně.
• Agilní podporuje týmovou práci . Mezi členy agilního týmu panuje skvělá spolupráce, interakce, harmonie a nadšení.
• Před začátkem sprintu jsou klientovi sděleny odhady nákladů a harmonogramu každého sprintu. Tento zlepšuje rozhodování protože uživatel může pochopit náklady na jednotlivé funkce a podle toho stanovit priority.
• V agilním projektu je prostor pro neustálé zlepšování . Poučení z minulých sprintů lze uplatnit v nadcházejících sprintech.
• Zaměřuje se na konkrétní úkol v každé fázi projektu.

Agilní nevýhody:

• Často je vidět, že agilní týmy mají tendence zanedbávat dokumentaci . Důvodem je, že agilní manifest se více zaměřuje na pracovní software než na komplexní dokumentaci. Týmy by však měly udržovat správnou rovnováhu mezi kódem a dokumentací.
• Protože to vyžaduje vysokou míru zapojení zákazníků, může pro zákazníky může být někdy problematické kteří nemají mnoho času a zájmu účastnit se projektu.
• To nefunguje dobře, pokud týmu chybí odhodlání a odhodlání. Vodopád vyžaduje zapojení, ale Agile vyžaduje odhodlání.
• Pokud je počáteční architektura a design slabý, pak časté refaktorování je požadováno.
• Ve srovnání s vodopádem je Agile obtížné procvičovat . Členové týmu musí být dobře obeznámeni s agilními koncepty. Procvičování Agile vyžaduje hodně disciplíny a odhodlání.
• Kvůli opětovnému stanovení priorit to je méně předvídatelné než to, co bude dodáno na konci sprintu.
• Z důvodu časově omezeného doručování a častého opětovného určování priorit existuje šance, že se několik funkcí nedostane na přidělenou časovou osu. To může vést k další sprinty a dodatečné náklady . To může také vést k problému mlhavé časové osy .
• Nedostatek struktury ve srovnání s vodopádem vyžaduje sebekázeň, vysoce kvalifikované a kvalifikované týmy . Bez toho může být projekt opravdu náročný.
• Dostupnost je méně plánu konečného produktu .
• Někdy externí účastník nemůže odolat dodržování agilního přístupu . V takových případech je školení a vzdělávání o Agile vyžadováno pro široké publikum.
• Všichni členové týmu musí být zapojeni do řízení projektu.
• Dokumentace je méně podrobná.

Rozdíl mezi modely Agile Vs Waterfall

Rozdíly mezi životními cykly Waterfall a Agile Software Development jsou uvedeny níže.

Vodopád	Agilní
Proces je považován za jeden projekt, který je dále rozdělen do různých fází.	Proces je rozdělen do několika projektů a každý projekt má iteraci různých fází.
Metodika vodopádu je model, ve kterém každá fáze životního cyklu produktu probíhá postupně. Postup projektu plyne postupně dolů skrz tyto fáze připomínající vodopád.	Agilní metodologie je model, který sleduje iterativní přístup.
Tento model věří v jednorázovou masivní dodávku. Produkt je dodáván na konci SDLC.	Tento model věří ve více malých dodávek v definovaných časových intervalech. Na konci každého sprintu je doručen MVP (Minimum Viable Product).
Je to tradiční a staromódní přístup.	Je to nový a moderní přístup.
Jeden jediný cyklus a jedno vydání.	Opakovaný počet iterací a více verzí.
Rozděluje životní cyklus vývoje softwaru do různých fází.	Rozděluje životní cyklus vývoje softwaru na sprinty.
Strukturovaný a tuhý model. Je obtížné změnit popis, specifikaci a design projektu.	Tento model je známý svou flexibilitou. Můžeme kdykoli provést změny v jakékoli fázi projektu.
Rozsah dlouhodobého plánování.	Stupnice krátkodobého plánování.
Mezi zákazníkem a vývojářem existuje velká vzdálenost.	Mezi zákazníkem a vývojářem existuje krátká vzdálenost.
Dlouhá doba mezi specifikací a implementací. Obchodní analytik shromáždí a připraví požadavek před zahájením projektu.	Krátká doba mezi specifikací a implementací. Vlastník produktu připravuje požadavky a aktualizace týmu v každém sprintu.
Objevování problémů trvá dlouho.	Problémy jsou objeveny rychle.
Vysoké riziko harmonogramu projektu.	Nízké riziko harmonogramu projektu.
Menší schopnost rychle reagovat na změny.	Vysoká schopnost rychle reagovat na změny.
Fáze testování nastává až po dokončení fáze vývoje.	Testování se obecně provádí souběžně s vývojem, aby byla zajištěna kvalita nepřetržitě.
Zákazník je zapojen pouze ve fázi shromažďování požadavků a poté již nedochází k žádnému zapojení zákazníka. Do obrazu se dostane až v okamžiku dodání produktu.	Zákazník je zapojen do celého projektu a čas od času je od zákazníka převzata zpětná vazba, aby byla zajištěna spokojenost zákazníka.
Vhodné pro projekty, které mají jasně definované požadavky a pro které neočekávají změny.	Vhodné pro projekty, které se musí vyvíjet a pro ty, které vyžadují měnící se požadavky.
Přísně sekvenční proces.	Vysoce spolupracující proces vývoje softwaru vede k lepšímu týmovému úsilí a rychlému řešení problémů.
Vykazuje projektové myšlení.	Představuje produktové myšlení, a proto je více zaměřeno na zákazníka. Součástí procesu jsou požadavky a změny
Formální a hierarchické. Rozhodující je projektový manažer.	Je to neformální. Za rozhodování je odpovědný celý tým.
Tento model předpokládá, že v průběhu projektu nedojde k žádným změnám v požadavcích.	Tento model je založen na adaptaci a zahrnuje změny.
Je třeba vytvořit manuální dokumenty k ověření stavu práce jednotlivce a postupu projektu.	Postupuje podle grafu Kanban a Burn Down a ověřuje průběh projektu a pracovní stav jednotlivce.

Měli jsme dostatek diskuzí o rozdílech mezi metodikami Agile & Waterfall a výhodách a výzvách každé z nich. Pojďme nyní prozkoumat rozdíly mezi agilním testováním a testováním vodopádu.

Rozdíly mezi agilním testováním a testováním vodopádů

Z hlediska testování softwaru je pro nás důležité mít poctivou představu o tom, jak se agilní testování liší od testování Waterfall.

Závěr

V tomto článku jsme se dozvěděli přesné rozdíly mezi moderním agilním přístupem a tradiční metodou vývoje a testování softwaru Waterfall pomocí srovnávací tabulky pokrývající výhody a nevýhody každého modelu.

Zvažováním všech faktorů uvedených v tomto článku můžeme vybrat správný model životního cyklu vývoje softwaru pro vývoj softwarové aplikace. Není pochyb o tom, že před modelem Waterfall jsou upřednostňovány agilní metodiky. 90% společností upřednostňuje a sleduje agilní pracovní postup při vývoji softwarové aplikace.

Agilní metodika je dobrá pro všechny druhy projektů. Velmi málo společností dodržuje metodiku vodopádu. Tato metodika je vhodná, pouze pokud je aplikace malá, jednoduchá a v požadavku nedochází ke změnám.

V některých případech se na základě potřeb také rozhodneme pro jiné přístupy zvané Spirála, V a V a Prototyp.

Doufám, že vám tyto informace pomohou při rozhodování, který je nejlepší model pro váš projekt. Můžete také jít na hybridní model odstraňující nevýhody každé metody - diskutováno zde.

Doporučené čtení

• Případová studie: Jak eliminovat nedostatky vodopádu a agilní vývojové procesy pomocí hybridního modelu
• Co je model SDLC Waterfall?
• Recenze nástroje Zephyr Enterprise Test Management Tool - Jak používat aktiva modelu vodopádu v nástroji Agile Tool
• Výukový program VersionOne: Příručka nástroje Agile Project Management All-in-one
• Výukový program pro Jira Portfolio: Doplněk Agile Project Portfolio Management pro JIRA (recenze)
• TOP 10 nejlepších nástrojů pro agilní řízení projektů v roce 2021
• Agile Estimation Techniques: A True Estimation in an Agile Project
• 4 kroky k vývoji agilního testování myšlení pro úspěšný přechod na agilní proces