agile vs waterfall which is best methodology
otázky a odpovede pre skúsených s využitím skriptovacieho skriptu
Dozviete sa všetko o metodikách Agile and Waterfall, rôznych druhoch SDLC modelov a rozdieloch medzi modelmi Waterfall vs. Agile Development a tiež o testovaní:
V tomto informačnom článku sa na základe výhod a nevýhod každého z nich rozhodnete, ktorý je najvhodnejším modelom pre váš projekt.
Waterfall Model a Agile Model sú typy životného cyklu vývoja softvéru (SDLC). Toto je proces, ktorý používa softvérový priemysel na navrhovanie, vývoj a testovanie softvéru.
Dodržiavaním SDLC môžeme dosiahnuť očakávania zákazníkov, dokončiť projekt v daných časových rámcoch a odhadnúť náklady.
Čo sa dozviete:
- Vodopád a agilné pracovné postupy
- Model vodopádu
- Agilný pracovný tok
- Rozdiel medzi modelmi Agile Vs Waterfall
- Rozdiely medzi agilným testovaním a testovaním vodopádov
- Záver
Vodopád a agilné pracovné postupy
V jednoduchej angličtine znamená Agile „schopnosť rýchlo a ľahko sa pohybovať“, a preto to znamená, keď ide o Metodika agilného rozvoja .
Agilná je metóda projektového riadenia, ktorá predstavuje rozdelenie úloh na kratšie segmenty práce s častým prehodnocovaním a prispôsobovaním plánov.
Podobne slovo vodopád označuje vertikálny tok vody alebo tok vody sériou strmých kvapiek. Model vodopádu je lineárny sekvenčný model, v ktorom postupuje hlavne jedným smerom nadol cez fázy zhromažďovania požiadaviek, analýzy, návrhu, vývoja, testovania, nasadenia a údržby.
Rovnaká ilustrácia sa týka koncepcie riadenia projektu, pokiaľ ide o model vodopádu . Jedná sa o metódu projektového riadenia, ktorú predstavujú sériové etapy a pevný plán práce.
[obrázok zdroj ]
Predtým, ako budeme diskutovať o pracovných postupoch Waterfall a Agile, pozrime sa na definíciu životného cyklu vývoja softvéru a jeho požiadavky.
Aký je životný cyklus vývoja softvéru?
Je to postupný postup, ako systematicky vyvíjať softvér. Z tohto dôvodu vyberáme z rôznych typov životných cyklov vývoja softvéru v rôznych spoločnostiach. Na základe požiadavky sa zvolí vhodný životný cyklus.
Model vodopádu je jedným z typov SDLC a je to starý proces vývoja softvéru. Agilný model je najnovší a pokročilý. Agilný je odvodený z iného životného cyklu vývoja softvéru.
Medzi ďalšie SDLC patrí špirálový model, model V a V, model prototypu. Na základe nevyhnutnosti a kompatibility obchodných požiadaviek vyberieme najlepší model pre vývoj softvérovej aplikácie.
[obrázok zdroj ]
Prečo je potrebný životný cyklus vývoja softvéru?
SDLC sa vyžaduje na štruktúrované riadenie projektu. Poskytuje určitú úroveň kontroly a definuje úlohy a zodpovednosti členov tímu. Poskytuje rozsah a termín pre každú fázu v SDLC.
Je to niečo ako užívateľská príručka pre členov tímu, aby nasledovali všetky kroky na vývoj a dodanie kvalitného produktu. Pomáha vedeniu tímu definovať a vyhodnotiť ciele a požiadavky. Pomáha tiež pri plánovaní a odhadovaní úloh. Vytvára komunikačnú líniu medzi klientom a vývojovým tímom a vytvára role a zodpovednosti pre každého z nich.
Druhy životného cyklu vývoja softvéru
Pozrime sa na krátke predstavenie typov SDLC používaných v procese vývoja softvéru.
# 1) Model vodopádu
Ako už bolo spomenuté, vodopádový model je prvým zavedeným životným cyklom vývoja softvéru. Je to postupný spôsob vývoja softvéru. Tento prístup uplatňuje veľmi málo spoločností. Ak je projekt veľmi jednoduchý a nedôjde k ďalším zmenám požiadaviek, budeme postupovať podľa tohto prístupu.
V tomto návode si povieme viac o modeli vodopádu.
# 2) Agilný model
Agilný pracovný tok je pokročilý prístup k procesu vývoja softvéru, ktorý sa používa vo väčšine spoločností. Agilný je definovaný ako životný cyklus vývoja softvéru založený na šprinte.
V nasledujúcich častiach môžeme diskutovať viac o agilnom pracovnom postupe.
# 3) Špirálový model
Jedná sa o spôsob budovania a testovania softvéru rozdelením a pridaním požiadavky v postupnom poradí. Tento model pomôže v projektoch, kde sa požiadavky neustále menia. Tento špirálový model je kombináciou procesu iteratívneho vývoja a procesu postupného lineárneho vývoja.
Tento prístup nám umožní postupné uvoľňovanie produktu. Tu nie je potrebné čakať na dokončenie všetkých modulov softvéru na vydanie.
Lineárny sekvenčný model znamená, že ide o systematický sekvenčný prístup vývoja softvéru, ktorý začína na úrovni systému a postupuje cez analýzu, návrh, kódovanie, testovanie a podporu.
Iteračný model znamená, že sa jedná o konkrétnu implementáciu životného cyklu vývoja softvéru, ktorá sa zameriava na počiatočnú zjednodušenú implementáciu, ktorá potom postupne získava na zložitosti a nastavuje sa širšia funkcia, kým nebude finálny systém dokončený.
# 4) Prototypový model
Tento model zahŕňa proces budovania a testovania softvéru takým spôsobom, že najskôr vyvinieme fiktívny model, a ak je to možné a splníme všetky obchodné požiadavky, implementujeme skutočný funkčný model.
Tu sme najskôr postavili a otestovali prototyp a potom zostrojili skutočný model s presnými špecifikáciami systému. Softvérové prototypovanie je činnosť vytvárania prototypov softvérových aplikácií.
# 5) Model V a V.
Je to model overovania a validácie. Pri vývoji softvéru sme tu používali na overenie a overenie všetkého v každej fáze SDLC. V-model sa považuje za rozšírenie modelu vodopádu.
Takže všetky typy SDLC majú svoje vlastnosti a vlastnosti. Na základe projektových požiadaviek, potrieb, uskutočniteľnosti, doby trvania si môžeme zvoliť konkrétny životný cyklus vývoja softvéru na vývoj softvérovej aplikácie.
Teraz si podrobne rozoberieme životné cykly vývoja softvéru Waterfall a Agile.
Model vodopádu
V modeli Waterfall by mala byť každá fáza dokončená pred začatím ďalšej fázy. Nemôžeme prevádzkovať viac fáz súčasne. Toto predstavil v roku 1970 Winston Royce. Vodopádový model je rozdelený do rôznych fáz.
[obrázok zdroj ]
Model vodopádu obsahuje nasledujúce fázy:
- Vyberanie požiadaviek
- Štúdie uskutočniteľnosti
- Dizajn
- Kódovanie
- Testovanie
- Údržba
# 1) Analýza požiadaviek
Tu dostane obchodný analytik špecifikáciu požiadavky. Požiadavka bude vo formáte CRS (Specification Customer Specification). CRS vysvetľuje, ako by mal prebiehať obchodný tok a ako by mala aplikácia fungovať podľa zadanej požiadavky. Podnikoví analytici prevedú CRS na SRS (špecifikácia softvérových požiadaviek).
Potom obchodný analytik podrobne prediskutuje špecifikácie požiadaviek s vývojovým a testovacím tímom a požiadavke porozumie z hľadiska vývoja a testovania. Toto je fáza na diskusiu a analýzu požiadaviek na zostavenie aplikačného softvéru na základe skutočných požiadaviek.
Tu by malo byť všetko zdokumentované v dokumente špecifikácie softvérových požiadaviek. V modeli vodopádu je výstup / výsledok / výstup každej fázy vstupným zdrojom pre ďalšie fázy.
V priemysle založenom na službách môže požiadavku priniesť obchodný analytik.
V produktovej spoločnosti prináša požiadavku produktový analytik.
# 2) Štúdia uskutočniteľnosti
Manažérsky tím vypracuje štúdiu uskutočniteľnosti. Znamená to, že tím bude analyzovať parametre, ako je, či je možné túto požiadavku / aplikáciu vyvinúť v našom prostredí alebo nie, dostupný zdroj je dostatočný alebo nie, náklady a mnoho ďalších faktorov sú realizovateľné alebo nie a je možné skontrolovať, či sme schopní pokryť ich. všetky obchodné toky alebo nie.
Na tomto stretnutí / analýze bude súčasťou diskusie projektový manažér, obchodný analytik, finančný manažér, HR, vedúci projektu.
# 3) Dizajn systému
Architekt projektu tu pripraví návrh systému. Upresní hardvér, systémové požiadavky a navrhne architektúru aplikácie. V dizajne systému sú 2 časti: dizajn na vysokej úrovni a dizajn na nízkej úrovni. V dizajne na vysokej úrovni navrhujeme rôzne bloky aplikácie. V nízkoúrovňovom dizajne píšeme pseudokód.
# 4) Kódovanie
Tu vývojári spustia presné kódovanie každej funkcie a používateľského rozhrania aplikácie pomocou rôznych metód a inej logiky. Na vytvorenie aplikácie môžu použiť akýkoľvek programovací jazyk ako Java, Python alebo akýkoľvek iný jazyk.
Po dokončení kódovania každej funkcie konkrétneho modulu aplikácie vykoná vývojár testovanie jednotky. Ak kód funguje dobre, vývojár ho nasadí do testovacieho prostredia a zostavenie dá testerovi na testovanie.
# 5) Testovanie
Od tejto chvíle začína testovacia činnosť. Do tejto fázy nebudeme mať v modeli Waterfall žiadnu úlohu. V tejto fáze robíme všetky typy testovania. Medzi tieto typy testovania patrí testovanie dymu, testovanie funkčnosti, testovanie integrácie, testovanie systému, akceptačné testovanie, regresné testovanie, testovanie ad-hoc, prieskumné testovanie a testovanie naprieč prehliadačmi.
Aplikáciu začneme testovať, akonáhle dostaneme zostavenie. Najskôr začneme s testovaním dymu. Ak nebudú zistené problémy s blokovaním, budeme pokračovať v podrobnom testovaní.
Pri funkčnom testovaní začneme testovať každú zložku aplikácie. Tu kontrolujeme rôzne komponenty, ako sú textové polia, tlačidlá, odkazy, prepínače, tlačidlá nahrávania, rozbaľovacie ponuky a navigačné odkazy.
Ďalej skontrolujeme používateľské rozhranie, vzhľad a dojem a testovanie pozitívnych a negatívnych vstupov.
Potom začneme s integračným testovaním. Tu skontrolujeme integráciu údajov. Overíme, či sa rovnaké údaje odrážajú na rôznych príslušných stránkach, alebo nie, overíme navigáciu e-mailových odkazov na príslušné stránky. Skontrolujeme dátovú integráciu s aplikáciami tretích strán a skontrolujeme zmeny databázy v aplikácii.
Ďalej urobíme testovanie systému. Celú aplikáciu skontrolujeme ako jeden celok. Skontrolujeme funkčnosť, integráciu stránok, validácie polí, chybové správy, potvrdzovacie správy a mnoho ďalších.
Počas testovania aplikácie zaznamenáme problémy do nástroja na sledovanie chýb. Na základe problémov dáme prednosť chybe. Po vytvorení chyby ju pridelíme príslušnému vývojárovi, aby problém napravil. Po opravení chyby ich overíme, keď ich vývojári priradia testerom. Ak to bude fungovať, tester chybu zavrie, v opačnom prípade ju testéri pridelia vývojárovi a opravia problém. Takto pokračuje životný cyklus chyby.
Potom prejdeme k prijímaciemu testovaniu. Tu testujeme aplikáciu v rôznych prostrediach, ako je inscenácia a UAT (User Acceptance Testing). Toto je najdôležitejšia fáza na dôkladné otestovanie aplikácie predtým, ako presunieme kód do produkčného prostredia.
Po vykonaní akceptačného testovania bez chýb bude klient plánovať nasadenie kódu na produkčný server a plán vydania.
# 6) Údržba
Po nasadení aplikačného kódu na produkčný server by sme mali klientskej aplikácii poskytnúť podporu / údržbu. Táto fáza údržby spočíva v pozorovaní a opravovaní problémov s produkciou v reálnom čase, kontrole problémov s pamäťou, na vylepšenie aplikácie a na vývoj nových zmien požiadaviek.
V ktorých prípadoch sa môžeme rozhodnúť pre model vodopádu?
- Ak nie sú potrebné zmeny.
- Keď je projekt malý a jednoduchý.
- Keď nie je zložitosť technológie.
- Keď bude k dispozícii viac zdrojov.
Vodopád Pros:
- Vpred a vzad plánovanie a implementácia je jednoduchá .
- Model vodopádu je ľahko použiteľný a ľahko pochopiteľný. Nevyžaduje žiadne špeciálne školenie pre projektových manažérov alebo zamestnancov. Má ľahká krivka učenia .
- Je strnulý v prírode, je ľahko spravovateľný vodopádový cyklus. Každá fáza má pevné výsledky a proces kontroly.
- Menej zložitosti pretože fázy sa neprekrývajú. Fázy nasledujú jeden za druhým. V porovnaní s ostatnými metodikami vývoja softvéru používa jasnú štruktúru. Projekt prechádza pevnými postupnými krokmi počnúc zhromažďovaním požiadaviek a nakoniec pristáva pri údržbe.
- Z dôvodu postupného vývoja disciplína sa presadzuje a časové harmonogramy je možné ľahko udržiavať.
- Tvorba pre malé projekty kde máme pevné a krištáľovo čisté požiadavky.
- Procesy a výsledky sú dobre zdokumentované .
- Vybavovanie úloh je jednoduché.
- to je ľahko merateľný pokrok pretože počiatočné a koncové body každej fázy sú vopred určené.
- V celom projekte sa takmer nijako nezmenia požiadavky, z tohto dôvodu úlohy zostávajú stabilné pre vývojárov. Je to ľahké pre všetkých nový vývojár, ktorý sa rýchlo učí a zahájiť prácu.
- Existujú žiadne finančné prekvapenia . Po stanovení požiadaviek je možné pred zahájením vývoja vypočítať konečné náklady.
- Zaoberá sa a model postupného financovania .
- Jeho podrobný návrh objasňuje konečný očakávaný výsledok všetkým.
- Špecifikácia funkčných požiadaviek zdokumentovaná vo fáze zhromažďovania požiadaviek poskytuje testerom dostatok podrobností na to, aby mohli navrhnúť testovacie scenáre a testovacie prípady. Preto je proces testovania je ľahký v modeli vodopádu.
Nevýhody vodopádu:
- Pretože všetky požiadavky musia byť jasne známe pred začatím vývoja, je to oneskoruje projekt .
- Vyžaduje rozsiahly výskum do užívateľských potrieb.
- V počiatočnej fáze projektu je pre zákazníka náročné jasne definovať a koncipovať svoje požiadavky vo forme funkčných špecifikácií. Preto pre nich existuje vysoká možnosť, aby po zhliadnutí konečného produktu zmenili názor. Táto zmena môže nastať aj v dôsledku obchodného plánu alebo vplyvu trhu. Nízka flexibilita v tomto modeli to umožňuje je ťažké prijať akékoľvek takéto zmeny , najmä keď je potrebné produkt do veľkej miery znova vyrobiť.
- Žiadny funkčný model sa vyrába až do neskôr etapa počas životného cyklu vodopádu.
- Pomalé dodacie lehoty . Zákazník nie je schopný vidieť produkt, kým nie je úplne dokončený.
- Zákazník nemá možnosť oboznámiť sa so systémom vopred. Model vodopádu je viac interný proces a udržuje vylúčeného koncového používateľa .
- The klient nie je informovaný o zdraví projektu.
- Termíny môžu byť premeškané ak sa nedodrží prísne riadenie a pravidelné sledovanie.
- Existuje žiadny priestor na zmeny aj keď je to počas vývoja viditeľné, pretože produkt nezodpovedá požiadavkám trhu.
- Oneskorenie testovania až po dokončení. V tomto okamihu sú tiež veľké revízie veľmi nákladné.
- Vysoké riziko a neistota sú zapojené do modelu vodopádu, pretože existuje príliš veľa priestoru na to, aby problémy zostali nepovšimnuté, kým sa projekt chýli ku koncu.
- Nie je vhodný model pre dlhé, zložité a prebiehajúce projekty.
- Je ťažké zmerať pokrok v rámci každej fázy.
- Počas mnohých fáz projektu budú testéri nečinní.
Agilný pracovný tok
Teraz uvidíme životný cyklus vývoja softvéru Agile Software. Agilný je proces, ktorý robí prácu rýchlo a ľahko a s vyššou presnosťou.
Tento model súvisí s metódou projektového riadenia, ktorá sa používa najmä pri vývoji softvéru. Vyznačuje sa rozdelením úloh na krátke fázy práce a častým prehodnocovaním a prispôsobovaním plánov. Každý člen tímu by mal mať predstavu o základných obchodných tokoch.
[obrázok zdroj ]
V spoločnosti Agile vývojári a testeri paralelne pracujú na vývoji a testovaní aplikačného softvéru. Vývoj sa vykonáva v iteračnom režime. Každá história používateľa s iteráciou vyžaduje analýzu, dizajn, kódovanie a testovanie.
Požiadavku podrobne testujeme, aby sme overili, či je bezchybná a implementovateľná alebo nie. Po ukončení každej iterácie prejdite na ďalšiu iteráciu a rovnakým postupom sledujeme nové / ďalšie požiadavky.
Tento proces vývoja a testovania bloku softvéru sa teda vykonáva v krátkom čase s väčšou presnosťou a flexibilitou. Tento proces teda sleduje a prijíma viac priemyselných odvetví.
Najskôr vlastník produktu pridá všetky požiadavky do nevybaveného produktu. Nevybavené položky produktu obsahujú všetky príbehy používateľov. Povedzme, že 100 až 150 užívateľských príbehov súvisí s kompletným projektom. Teraz pridajte konkrétne príbehy používateľov do nevybavených sprintov, ktoré musíme implementovať. Potom budú všetci vývojári, QA, BA, pracovať na položkách sprintu. Takto funguje Agile flow.
Kľúčové terminológie používané v agile
Čo je nevybavený sprint?
hlavné rozdiely medzi Java a C ++
Je to zoznam užívateľských príbehov, ktoré musíme implementovať v aktuálnej iterácii alebo šprinte.
Napríklad, v backlogu sprintu je 20 až 30 užívateľských príbehov. Potom sú to príbehy používateľov, ktoré musíme implementovať v súčasnom šprinte.
[obrázok zdroj ]
Čo je to šprint?
Sprint je malé trvanie, v ktorom musíme implementovať vybrané príbehy používateľov v rámci určitého obdobia. Trvanie sprintu bude približne 2 až 3 týždne. Jeho trvanie sa líši od spoločnosti k spoločnosti.
V tomto trvaní sprintu musí tím analyzovať požiadavku, navrhnúť požiadavky, vykonať kódovanie, testovanie, odstránenie problému, opätovné testovanie, regresné testovanie, ukážku a mnoho ďalších aktivít.
Denné stretnutie v stoji Scrum
Business Analyst, Developer, Tester, the Project Manager are part of daily stand up scrum meeting. Robí sa to každý deň. Nemalo by to trvať dlhšie ako 15 až 30 minút.
Tu budú všetci členovia tímu zdieľať stav dennej práce. Hlavné veci, o ktorých tu diskutujeme, sú: čo sú včera dokončené veci, plán dnešnej práce a všetky výzvy alebo závislosti, ktorým v rámci projektu čelia.
Ak ktorýkoľvek člen tímu čelí počas projektu akýmkoľvek výzvam alebo prekážkam, dotknutá osoba na tom bude pracovať, aby to zvládla.
Burndown graf
Je to obrazové grafické znázornenie času a práce. Os x predstavuje zostávajúcu prácu, os y predstavuje zostávajúci čas šprintu. Tím musí vytvoriť pracovné úlohy týkajúce sa času dostupného v konkrétnom šprinte. Tím bude denne vypaľovať hodiny úloh na základe práce, ktorú odpracovali a dokončili.
[obrázok zdroj ]
Kanbanový graf
Je to schéma / nástroj projektového riadenia. Vďaka tomu môžeme riadiť úlohy celého projektu. Môžeme skontrolovať stav priebehu projektu a stav práce jednotlivca. Zobrazuje obrazové digitálne znázornenie pokrokových položiek, čakajúcich položiek, hotových položiek.
[obrázok zdroj ]
príklad regulárneho výrazu v c ++
Plánovanie pokerovej aktivity
Je to hra medzi členmi šprintérskeho tímu na odhadnutie užívateľských príbehov. Celý tím bude hrať pokerovú aktivitu. Každý člen tímu dáva odhad založený na bode príbehu používateľa. Na základe väčšinových odhadov hlasov rozhodne tím a pridelí časový úsek.
Napríklad , jeden člen tímu používateľov s príbehom poskytne odhad ako 3, 5, 8, 3, 1, 3. Potom si tím vyberie ako odhad 3. Karta aktivity pokru obsahuje 0, 1, 3, 5, 8, 13, 20, 100, zlom, pochybnosti? karty. Na základe tohto navrhnú členovia tímu akúkoľvek kartu odhadu. Takto odhadneme všetky príbehy používateľov, ktoré súvisia s konkrétnym šprintom.
[obrázok zdroj ]
- 0 pokerových čísel predstavuje: v tomto príbehu používateľa / používateľa žiadna úloha
- 1, 3 čísla znamenajú: úloha je menšia
- 5, 8 čísel predstavuje: úlohy na strednej úrovni
- 13, 20 číslo predstavuje: úlohy na vysokej úrovni
- 100 číslo predstavuje: veľmi veľké úlohy
- Nekonečno predstavuje: Úloha je obrovská, treba ju rozdeliť na viac úloh a príbehy používateľov
- Prestávka predstavuje: potrebovať prestávku
- ? Predstavuje: Pochybnosti
Scrum Master
Je to osoba, ktorá pomáha tímu sledovať agilný proces a plniť požiadavky projektu. Stretnutie bude viesť vždy, keď je to potrebné, a pomôže prediskutovať potrebu projektu.
Scrum master slúži ako mostík pre všetkých členov tímu pri riešení výziev a závislostí, ktoré sa v rámci projektu vyskytujú. Bude sledovať priebeh projektu týkajúceho sa každého šprintu.
Zúčastňuje sa samostatného stretnutia, retrospektívneho stretnutia, kontroly, preskúmania, ukážky. Je to ten, kto vedie denné stand-upové stretnutia a informuje člena tímu.
Produktový vlastník
Je to osoba, ktorá riadi a monitoruje produkt / projekt z obchodného hľadiska. Neustále sleduje, či je produkt vyvíjaný podľa obchodných požiadaviek alebo nie. Je to ten, kto uprednostňuje príbehy používateľov a presunul požiadavky z nevybaveného produktu na nevybavený sprint. Odhadne termíny projektu.
Na produkt sa vždy pozerá z pohľadu používateľa. Produktový vlastník má úplné znalosti o tom, ako by aplikácia mala fungovať.
Príbeh používateľa
Je to blok požiadaviek. Obsahuje súbor prípadov / požiadaviek na použitie, ktoré sa týkajú rovnakého modulu. Tu definujeme, ako by mali jednotlivé komponenty aplikácie fungovať a ako by malo vyzerať používateľské rozhranie. Rozsah jednotlivých komponentov je definovaný v užívateľskom príbehu.
Úlohy
Členovia tímu vytvoria úlohu pre užívateľský príbeh, ktorý je im pridelený. Potrebujú vytvoriť úlohu na základe rôznych úloh, ako sú vývojová úloha, testovacia úloha, úloha analýzy príbehu používateľa. Trvanie úlohy by malo závisieť od bodov príbehu používateľa.
Ako tester budeme vytvárať úlohy pre analýzu užívateľských príbehov, prípravu testovacích prípadov, vykonávanie, regresné testovanie a mnoho ďalších.
Nevybavené zastrihávanie
Táto časť zahŕňa správu nevybavených položiek. Medzi aktivity, ktoré tu robíme, patrí uprednostňovanie nevybavených položiek, rozdelenie na menšie položky, vytvorenie úlohy a aktualizácia kritérií prijatia.
Iterácia
Iterácia je vývoj a testovanie niektorých modulov / častí softvérovej aplikácie. Každá iterácia pozostáva z analýzy produktu, návrhu produktu, vývoja produktu, testovania produktu a ukážky produktu.
Kľúčové faktory pre prijatie agilnej metodiky
- Pozorovanie: Pravidelne kontrolujte prácu a produkt a podľa toho naplánujte činnosti. Takže proces vývoja produktu a kvalita produktu budú dobré.
- Vitajte zmeny: Zmeny sa vybavujú veľmi ľahko. Na produkt to nemá veľký vplyv, pretože moduly softvéru sú vyvíjané samostatne a integrované neskôr. Ak sa v budúcnosti požiadavka zmení, nedôjde k žiadnym ďalším úpravám.
- Časový rámec: Dostávame časový rámec pre každú jednotku aplikácie. Takže odhad bude presný smerom k odhadom času projektu.
- Spokojnosť zákazníkov: Spokojnosť zákazníka spočíva skôr v tom, že počas celého projektu komunikujeme s klientom a akcionármi a poskytneme ukážku na každej úrovni vývoja produktu. Takto pravidelne dostávame spätnú väzbu od zákazníkov / klientov o obchodných tokoch a postupe práce. Podľa toho sa teda pracuje aj na vývoji aplikácie.
Typy agilných metodík
- Metodika agilného skrumáže
- Vývoj softvéru Lean
- Kanban
- Extrémne programovanie (XP)
- Krištáľ
- Metóda vývoja dynamických systémov (DSDM)
- Feature Driven Development (FDD)
Agilní klady:
- Jednou z najväčších výhod agilného modelu je jeho veľká prispôsobivosť . Adaptabilita znamená „reagovať na zmeny“. Spoločnosť Agile je veľmi flexibilná pri riešení zmien v potrebách a prioritách zákazníkov.
- Umožňuje neustále zdokonaľovať a opätovne uprednostňovať celkový nevybavený produkt bez toho, aby to malo vplyv na aktuálnu iteráciu, v ktorej je tím zameraný na poskytovanie MVP. Zmeny je možné naplánovať na nasledujúcu iteráciu, čím sa naskytne príležitosť zaviesť zmeny iba za niekoľko týždňov.
- Agilná metodológia ponúka veľkú mieru zapojenie zainteresovaných strán . Klient a projektový tím sa stretávajú pred, počas a po každom šprinte. Pretože je zákazník neustále zapojený do celého projektu, tím má viac príležitostí na jasné pochopenie jeho vízie.
- Pracovný softvér je dodávaný skoro a často. To zvyšuje dôvera zainteresovaných strán v tíme a nabáda tím k tomu zostaňte vysoko oddaní k projektu.
- Tento model dáva transparentnosť . Zainteresované strany aj tím dobre vedia o tom, čo sa deje. Klient môže vidieť prebiehajúce práce.
- Opravený harmonogram šprintov od jedného do štyroch týždňov umožňuje skoré a predvídateľné doručenie . Nové funkcie sú zverejňované rýchlo a často časovo obmedzeným spôsobom.
- Agilný je zameraný na zákazníka . Poskytuje nielen funkčnosť, ale zameriava sa aj na poskytovanie funkcií, ktoré majú pre používateľa určitú hodnotu. Každý príbeh používateľa má obchodné akceptačné kritérium.
- Cenné spätná väzba od zákazníka je získaný skoro v projekte a podľa potreby je možné vykonať zmeny na produkte.
- Dôraz sa kladie na obchodnú hodnotu . Najskôr prináša to, čo je pre klienta najdôležitejšie.
- Zvyšuje kvalitu výstupov . Na rozdiel od vodopádu sa testovanie neustále a často vykonáva v agilnom projekte, čo zase pomáha pri včasnom odhalení a odstránení problémov.
- Agilný podporuje prístup TDD (Test Driven Development) ktorý poskytuje dostatok času na vytvorenie jednotkových testov pre funkcie, ktoré sa majú vydať prostredníctvom MVP.
- Aj výrobou časté stavby , akékoľvek nesúlady s požiadavkami zákazníka možno tiež zistiť a opraviť včas.
- Ako sme sa dostali okamžitá spätná väzba od používateľov po každom vydaní MVP, riziko zlyhania projektu je nízke, keď pracujete svižne.
- Agilný podporuje tímovú prácu . Medzi členmi tímu Agile existuje veľká spolupráca, interakcia, harmónia a nadšenie.
- Náklady a harmonogramové odhady každého sprintu sú klientovi oznámené pred začiatkom sprintu. Toto zlepšuje rozhodovanie pretože používateľ dokáže pochopiť náklady na jednotlivé funkcie a podľa toho určiť priority.
- V agilnom projekte je priestor pre neustále zlepšovanie . Poznatky z minulých šprintov sa dajú uplatniť v nadchádzajúcich šprintoch.
- Zameriava sa na konkrétnu úlohu v každej fáze projektu.
Agilné zápory:
- Často sa ukazuje, že agilné tímy majú a tendencia zanedbávať dokumentáciu . Je to preto, že agilný manifest sa zameriava viac na funkčný softvér ako na komplexnú dokumentáciu. Tímy by však mali udržiavať správnu rovnováhu medzi kódom a dokumentáciou.
- Pretože to vyžaduje vysoký stupeň zapojenia zákazníka, môže pre zákazníkov niekedy problematické ktorí nemajú veľa času a záujmu podieľať sa na projekte.
- To nefunguje dobre, ak tímu chýba nasadenie a odhodlanie. Vodopád vyžaduje zapojenie, avšak Agile vyžaduje odhodlanie.
- Ak je pôvodná architektúra a dizajn slabý, potom časté refaktorovanie je požadované.
- V porovnaní s vodopádom je to Agile ťažko praktizovateľné . Členovia tímu musia dobre ovládať agilné koncepcie. Vyžaduje si veľa disciplíny a odhodlania trénovať Agile.
- Z dôvodu opätovného stanovenia priorít je menej predvídateľné než čo bude dodané na konci šprintu.
- Z dôvodu časovo ohraničeného doručenia a častého prehodnocovania priorít existuje šanca, že sa niekoľko funkcií nedostane doručených v alokovanej časovej osi. To môže viesť k ďalšie šprinty a ďalšie náklady . To môže tiež viesť k problému hmlisté časové osi .
- Nedostatok štruktúry v porovnaní s vodopádom vyžaduje sebadisciplinované, vysoko zdatné a kvalifikované tímy . Bez toho môže byť projekt skutočne náročný.
- Dostupnosť je menší plán konečného produktu .
- Niekedy externý účastník nemôže odolávať nasledovaniu agilného prístupu . V takýchto prípadoch je pre širokú verejnosť potrebné školenie a vzdelávanie o spoločnosti Agile.
- Všetci členovia tímu sú povinní byť zapojení do riadenia projektu.
- Dokumentácia je menej podrobná.
Rozdiel medzi modelmi Agile Vs Waterfall
Rozdiely medzi životnými cyklami vodopádu a agilného vývoja softvéru sú uvedené nižšie.
Vodopád | Agilný |
---|---|
Proces je považovaný za jeden projekt, ktorý je ďalej rozdelený do rôznych fáz. | Proces je rozdelený do niekoľkých projektov a každý projekt má iteráciu rôznych fáz. |
Metodika vodopádu je model, v ktorom každá etapa životného cyklu produktu prebieha postupne. Postup projektu tečie postupne nadol cez tieto fázy pripomínajúce vodopád. | Agilná metodológia je model, ktorý sa riadi iteračným prístupom. |
Tento model verí v jednorazové masívne doručenie celej dodávky. Produkt sa dodáva na konci SDLC. | Tento model verí v niekoľko malých častí doručenia v definovaných časových intervaloch. MVP (minimálny životaschopný produkt) sa dodáva na konci každého šprintu. |
Je to tradičný a staromódny prístup. | Je to nový a moderný prístup. |
Jeden jediný cyklus a jedno vydanie. | Opakujúci sa počet iterácií a viacerých vydaní. |
Rozdeľuje životný cyklus vývoja softvéru na rôzne fázy. | Rozdeľuje životný cyklus vývoja softvéru na šprinty. |
Štruktúrovaný a tuhý model. Je ťažké zmeniť popis, špecifikáciu a dizajn projektu. | Tento model je známy svojou flexibilitou. Zmeny môžeme vykonať v ktorejkoľvek fáze projektu kedykoľvek. |
Rozsah dlhodobého plánovania. | Rozsah krátkodobého plánovania. |
Medzi zákazníkom a vývojárom existuje veľká vzdialenosť. | Medzi zákazníkom a vývojárom existuje krátka vzdialenosť. |
Dlhý čas medzi špecifikáciou a implementáciou. Podnikový analytik zhromaždí a pripraví požiadavku pred začiatkom projektu. | Krátky čas medzi špecifikáciou a implementáciou. Produktový vlastník pripravuje požiadavky a aktualizácie pre tím v každom šprinte. |
Odhalenie problémov trvá dlho. | Problémy sa rýchlo odhalia. |
Vysoké riziko harmonogramu projektu. | Nízke riziko harmonogramu projektu. |
Menšia schopnosť rýchlo reagovať na zmeny. | Vysoká schopnosť rýchlo reagovať na zmeny. |
Fáza testovania nastáva až po ukončení fázy vývoja. | Testovanie sa zvyčajne vykonáva súbežne s vývojom, aby sa zaistila nepretržitá kvalita. |
Zákazník je zapojený až vo fáze zhromažďovania požiadaviek a potom už nedochádza k žiadnemu zapojeniu zákazníka. Do obrazu sa dostane až v okamihu dodania produktu. | Zákazník je zapojený do celého projektu a od zákazníka sa z času na čas odoberá spätná väzba, aby sa zaistila jeho spokojnosť. |
Vhodné pre projekty, ktoré majú jasne definované požiadavky a pre ktoré neočakávajú zmeny. | Vhodné pre projekty, ktoré sa musia vyvíjať a pre tie, ktoré zahŕňajú meniace sa požiadavky. |
Prísne postupný proces. | Proces vývoja softvéru na vysokej úrovni vedie k lepšiemu tímovému úsiliu a rýchlemu riešeniu problémov. |
Vykazuje projektové zmýšľanie. | Predstavuje produktové myslenie, a teda je viac zamerané na zákazníka. Súčasťou procesu sú požiadavky a zmeny |
Formálne a hierarchické. Projektový manažér je subjektom rozhodovania. | Je to neformálne. Za rozhodovanie je zodpovedný celý tím. |
Tento model predpokladá, že v priebehu projektu nedôjde k žiadnym zmenám v požiadavkách. | Tento model je založený na adaptácii a zahŕňa zmeny. |
Je potrebné vytvoriť manuálne dokumenty na overenie stavu práce a pokroku jednotlivca. | Sleduje Kanbanov diagram a Burn Down graf na overenie postupu projektu a stavu práce jednotlivca. |
Mali sme dostatok diskusií o rozdieloch medzi metodikami Agile & Waterfall a výhodách a výzvach každej z nich. Pozrime sa teraz na rozdiely medzi agilným testovaním a testom vodopádu.
Rozdiely medzi agilným testovaním a testovaním vodopádov
Z hľadiska testovania softvéru je pre nás dôležité mať nestranný názor na to, ako sa agilné testovanie líši od testovania Waterfall.
Testovanie vodopádu | Agilné testovanie |
---|---|
Testovacie tímy a vývojové tímy sú oddelené jasnou hranicou a vedie medzi nimi prísna a formálna komunikácia. | Testovací tím a vývojové tímy sú integrované ako jeden tím a je medzi nimi voľný tok komunikácie. |
Testovanie sa začína po dokončení vývoja a fáz budovania. | Testovanie sa začína súbežne s vývojovou fázou. |
Plánovanie sa vykonáva iba raz pred testovacou fázou. | Plánovanie sa robí pred začiatkom projektu a často sa robí počas projektu. |
Plán skúšok sa počas projektu kontroluje zriedka. | Plán testov sa kontroluje po každom šprinte. |
Pre testovací tím je tiché náročné navrhnúť akékoľvek zmeny v požiadavkách. | Testovací tím sa aktívne podieľa na procese zhromažďovania a zmeny požiadaviek. |
Testovacie prípady sú vytvorené raz pre všetky funkcie. | Testovacie prípady sa vytvárajú v šprinte po šprinte pre funkcionality, ktoré je potrebné uvoľniť v každom šprinte. |
Akceptačné testovanie sa vykoná klientom jednorazovo po vydaní. | Akceptačné testovanie je možné vykonať po každej iterácii a pred doručením obchodným analytikom alebo testovacím tímom. Neskôr to robí zákazník po každom vydaní. |
Podrobná a rozsiahla dokumentácia o testoch. | Dokumentácia o teste sa robí iba v nevyhnutnom rozsahu. |
Odhady a zadania testov sú často zodpovednosťou manažéra testov. | Odhady a zadania testov sú spoločnou zodpovednosťou tímu a testovacích inžinierov, ktorí sa podieľajú na poskytovaní odhadov a výbere úloh. |
Regresné testovanie sa robí zriedka a zahŕňa vykonanie všetkých testovacích prípadov. | Regresné testovanie sa vykonáva po každej iterácii a týka sa iba tých testovacích prípadov, ktoré sú povinné. |
Záver
V tomto článku sme sa dozvedeli presné rozdiely medzi moderným agilným prístupom a tradičnou Waterfallovou metódou vývoja a testovania softvéru pomocou porovnávacej tabuľky pokrývajúcej výhody a nevýhody každého modelu.
Zvážením všetkých faktorov uvedených v tomto článku môžeme zvoliť správny model životného cyklu vývoja softvéru na vývoj softvérovej aplikácie. Niet pochýb o tom, že sa dáva prednosť agilným metodikám pred vodopádovým modelom. 90% spoločností uprednostňuje a sleduje agilný pracovný tok pri vývoji softvérovej aplikácie.
Agilná metodika je dobrá pre všetky druhy projektov. Veľmi málo spoločností dodržiava metodiku vodopádu. Táto metodika je vhodná, iba ak je aplikácia malá, jednoduchá a v požiadavke nie sú žiadne zmeny.
V niektorých prípadoch sa na základe potrieb rozhodujeme aj pre iné prístupy zvané špirála, V a V a prototyp.
Dúfam, že vám tieto informácie pomôžu rozhodnúť sa, ktorý je najlepší model pre váš projekt. Môžete tiež ísť na stránku hybridný model odstraňujúci mínusy každej metódy - tu sa diskutuje.
Odporúčané čítanie
- Prípadová štúdia: Ako eliminovať chyby vodopádov a procesy agilného vývoja pomocou hybridného modelu
- Čo je model SDLC Waterfall?
- Recenzia nástroja na správu podnikových testov Zephyr - Ako používať aktíva modelu vodopádu v agilnom nástroji
- Výukový program VersionOne: Sprievodca nástrojom agilného riadenia projektu „všetko v jednom“
- Výukový program pre portfólio Jira: Doplnok Agile Project Portfolio Management pre JIRA (recenzia)
- TOP 10 najlepších nástrojov agilného riadenia projektov v roku 2021
- Techniky agilného odhadu: Skutočný odhad v agilnom projekte
- 4 kroky k vývoju agilného testovania myslenia pre úspešný prechod na agilný proces