Menu

Prípadová štúdia: Ako eliminovať chyby vodopádu a procesy agilného vývoja pomocou hybridného modelu

  • Hlavná
  • Agilné Testovanie
  • Prípadová štúdia: Ako eliminovať chyby vodopádu a procesy agilného vývoja pomocou hybridného modelu

case study how eliminate flaws waterfall

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

Hybridný model Agile Waterfall

Model Waterfall bol ideálnou voľbou pre vývoj softvéru. V tomto modeli sa myšlienka stáva použiteľným softvérom v postupnom procese, ktorý kaskádovito prechádza fázami inicializácie, analýzy, implementácie, testovania a údržby.

Model Waterfall má ale určité nevýhody.

Agilný vývoj softvéru sa vyvinul s cieľom eliminovať problémy, ktoré má model Waterfall. Má úplne nový rámec. Zatiaľ čo model Waterfall má sekvenčný dizajn, model Agile postupoval postupne.

Keď klienti, ktorí sa predtým riadili vodopádovým modelom, prešli na Agile, prechod so sebou priniesol veľa problémov. Dôvodom je neprispôsobivosť odlišnému prístupu k vývoju softvéru. Konečný produkt sa ukázal ako katastrofa.

Hybridný model Agile Waterfall

Vyvinula sa tak nová metodika, ktorú možno nazvať „hybridná“, ktorá zaisťuje robustný konečný produkt výberom výhod modelov Agile aj Waterfall.

Najprv sa dozvieme o vývojových modeloch Waterfall a Agile a potom prejdime k „Agile Waterfall Hybrid Model“ s výhodami a nevýhodami každého z nich.

Čo sa dozviete:

Model vodopádu

Waterfall model je prístup k vývoju softvéru, ktorý rozdeľuje projekt na konečné fázy. Do ďalšej fázy by sa malo ísť, len keď sa preverí a overí jej predchádzajúca fáza.

V modeli vodopádu sa fázy neprekrývajú.

=> Prečítajte si viac o modeli vodopádu tu.

Obrázok 1 ukazuje model vodopádu:

Model vodopádu

Výhody modelu Waterfall:

  • Jednoduché a ľahko pochopiteľné a použiteľné.
  • Pevný model - každá fáza má konkrétne výsledky a kontrolné procesy.
  • Dokumentácia a artefakty sú starostlivo udržiavané.
  • Vhodné pre projekty, kde sú dobre pochopené požiadavky.

Nevýhody modelu Waterfall:

  • Nevhodné pre projekty, pri ktorých existuje riziko zmeny požiadaviek.
  • Náklady na odstránenie chýb sú veľmi vysoké, ak sa zistia v neskoršej fáze.
  • Nie je to dobrý model pre zložité a dlhé projekty.
  • Až do konca životného cyklu sa nevyrába žiadny funkčný softvér.

Agilný model

Wikipedia definuje Agilný model ako „skupinu metód vývoja softvéru založených na iteratívnom a prírastkovom vývoji, kde sa požiadavky a riešenia vyvíjajú prostredníctvom spolupráce medzi samoorganizujúcimi sa a krížovo funkčnými tímami.“

Model má svoje vlastné princípy, ktoré majú tendenciu posúvať procesy dozadu.

=> Prečítajte si viac článkov o metodike Agile tu.

(Kliknutím na obrázok ho zväčšíte)

Agilný model

Výhody agilného modelu:

  • Zapojenie zákazníka do procesu.
  • Vysoká návratnosť investícií ako pracovný softvér sa dodáva často.
  • Aj neskoré zmeny v požiadavkách sa dajú ľahko prispôsobiť.
  • Neustále zlepšovanie produktu aj procesu.

Nevýhody agilného modelu:

  • Nedostatočný dôraz na projektovanie a dokumentáciu.
  • Tím by mal byť stabilný a zručný.

Kolaboratívny (hybridný) model

Cieľom modelu spolupráce je spojiť obidva modely - Waterfall a Agile. Využitie vodopádového a agilného prístupu zaisťuje úspech projektu. Odstraňuje nevýhody oboch modelov; pričom spája výhody oboch.

Kolaboratívny model je možné implementovať do projektu vykonaním:

ako hrať súbory mkv na pc

Kolaboratívny (hybridný) model

Takže model spolupráce je možné znázorniť schematicky nižšie:

Kolaboratívny (hybridný) model 2

Výhody modelu Hybrid

  • Spája výhody agilných aj vodopádových procesov.
  • Dizajn na vysokej úrovni je pripravený aplikovať vodopádové princípy.
  • Kódovanie a testovanie sa vykonáva pomocou svižnej metodológie.

Hybridný model Agile Waterfall - naučte sa príkladom -Prípadová štúdia

Softvérová firma „ABC Software Service“ poskytuje služby klientovi, univerzite s názvom „XYZ University“, s cieľom vyvíjať, testovať a udržiavať ich softvér (podpora živej produkcie).

Hlavné funkcie účtu sú:

  1. Softvérové ​​služby ABC musia aktualizovať aplikácie univerzity XYZ. Databázu je potrebné inovovať a všetky aplikácie je potrebné znova vyvinúť podľa najnovšej technológie dostupnej na trhu.
  2. Doteraz boli všetky projekty riešené spoločnosťou ABC Software realizované v modeli Waterfall.
  3. Dve z aplikácií s vysokou premávkou a vysokou prioritou boli teraz naplánované na opätovný vývoj. Prvý je „Online registrácie“ a druhý je „Online skúšky“.
  4. Klient XYZ University teraz chcel, aby sa na týchto aplikáciách pracovalo pomocou agilného modelu vývoja softvéru.

Prvým projektom v agilnom modeli spoločnosti ABC Software boli online registrácie. Po realizácii tohto projektu sa v sérii retrospektív realizovalo to, že v postupoch bolo veľa nedostatkov.

O tieto chyby sa postaralo pri realizácii druhého projektu „online preskúmanie“, a preto sa vykonal v hybridnom modeli.

Ako eliminovať chyby vodopádov a agilných vývojových procesov pomocou hybridného modelu:

Poďme si ich podrobne rozobrať po jednom.

# 1. Žiadna dokumentácia:

Jeden z agilných princípov agilného manifestu uvádza, že: Agile dáva väčšiu hodnotu „Pracovnému softvéru nad komplexnou dokumentáciou“. Agilná metodológia sa domnieva, že dokumentácia by mala byť „len sotva dosť dobrá“ a väčší dôraz sa kladie na dodanie funkčného softvéru. S dokumentáciou sa nevynaloží veľa úsilia, ale pre účty ako Univerzita XYZ, so špecializovaným podporným tímom, ktorý pracuje na chybách zistených pri živých projektoch, sa tento zvyk môže javiť ako prekážka, pokiaľ ho budeme analyzovať z dlhodobého hľadiska.

V priebehu rokov, keď sa projekty realizovali v modeli Waterfall, sa udržali a aktualizovali dokumenty, aby tím podpory porozumel a zodpovedajúcim spôsobom pracoval. Niektoré z pripravených dokumentov boli návrh riešenia, technický dizajn, podrobné dokumenty atď. Po ukončení projektu bolo to isté prevedené do podporného tímu.

Ale v prípade projektu „online registrácie“ neboli pripravené žiadne takéto dokumenty, čo sa ukázalo ako nákladné. Keď bol projekt uvedený do života, koncoví používatelia zhromaždili veľa lístkov a tím podpory nemal potuchy, ako na nich pracovať. Tím nemal žiadny dokument, na ktorý by sa mohol odvolávať.

Toto bola veľká lekcia a pre ďalší projekt boli „online skúšky“ vypracované a efektívne prevedené dokumenty.

=> Prečítajte si viac tu, prečo je dokumentácia dôležitá.

#dva. Žiadne UAT / end-to-end testovanie:

V agilnom režime vývoja softvéru dostávajú testeri zostavy testované po krokoch. Tieto zostavy sa neustále integrujú, až kým sa nedokončí úplné zostavenie. Testéri testujú požiadavky obsiahnuté v každom šprinte a pokračujú v regresnom testovaní zostavy, ktorá sa neustále zvyšuje.

Ale potom, čo sú všetky šprinty hotové a finálna verzia je pripravená a integrovaná, mal by tester otestovať celý systém a mal by testovať end-to-end. Toto by sa malo diať v úplne novom prostredí.

=> Kompletné testovanie na živom projekte.

To má svoje vlastné výhody:

  • Celý systém je nasadený do nového prostredia a tester testuje celý tok.
  • Buduje dôveru, pretože v konečnom dôsledku je potrebné zostavenie nasadiť ako celok v živom prostredí.

Keď sa testoval projekt Online registrácie, robilo sa to v testovacom prostredí. Po otestovaní systému a opätovnom otestovaní všetkých chýb bol deklarovaný na odhlásenie. V ideálnom prípade to nebolo povýšené do iného prostredia pre ďalší cyklus testovania systému. (V ideálnom prípade UAT sa stane po testovaní systému , ale v tomto prípade boli členovia tímu UAT zapojení do prvého cyklu testovania, takže nebol naplánovaný žiadny druhý cyklus)

Keď sa začal projekt online skúšok, bol vykonaný SIT (Testovanie integrácie systému) a kód bol povýšený do prostredia UAT, kde bol vykonaný druhý cyklus testovania. Výsledok: Všetky chyby s vysokou prioritou boli zachytené a vyriešené. Zostavenie bolo stabilné pred vydaním naživo.

# 3. Žiadny Scrum Master:

The Scrum Master je zodpovedný za zabezpečenie toho, aby tím žil podľa hodnôt a postupov spoločnosti Scrum. Scrum Master je považovaný za kouča tímu tým, že pomáha tímu vykonávať čo najlepšiu prácu. Scrum Master možno tiež považovať za a vlastník procesu pre tím.

Tím online registrácie bol vytvorený bez Scrum Master. Dôležitosť mať špecializovaného Scrum Master sa nepovažovala za dôležitú. To viedlo k tomu, že veľa problémov sa nevyriešilo včas a čas na dokončenie projektu zase prekročil termín.

Do projektu Online skúšky však bol zapojený špecializovaný Scrum Master. O problémy a výzvy projektu sa postaral Scrum Master. Boli pripravené správy o projekte / šprinte a tím mohol vidieť ich pokrok.

ako spustiť súbor java jar

Pre každý šprint sa tiež uskutočnili správne stretnutia na plánovanie šprintu a retrospektívne stretnutia, ktoré zlepšili výkonnosť tímu. Tím sa sústredil iba na svoju prácu a plnenie svojich úloh pridelených pre tento šprint. Všetky ďalšie upratovacie práce riešil Scrum Master.

# 4. Prevod projektových dokumentov na nevybavené produkty:

Počiatočné projektové dokumenty, ktoré sa pripravujú v modeli vodopádu, sú špecifikácia obchodných požiadaviek (BRS), vysokoúrovňový dizajn, funkčný dizajn atď. Tieto dokumenty je potrebné transformovať na nevybavený produkt, aby bolo možné vykonať fázy kódovania, testovania a implementácie v agilnom režime. Toto je veľmi dôležitý krok.

Nevybavené položky produktu sú východiskovým bodom agilného projektu. Nevybavené položky produktu sú prioritným zoznamom požiadaviek, ktoré sa pre produkt zachovávajú. Skladá sa z funkcií, opráv chýb, nefunkčných požiadaviek atď. Je to rastúci dokument, ktorý sa zväčšuje a zlepšuje na základe spätnej väzby od zákazníkov, meniacich sa požiadaviek atď.

Ako prvý artefakt každého projektu je najdôležitejšie uviesť zoznam požiadaviek a priradiť im priority. Konverzia dokumentov vodopádového projektu na nevybavené produkty je sama o sebe veľkou úlohou a vyžaduje brainstorming celého tímu spolu so zákazníkom / zainteresovanou stranou.

Keď sú všetky požiadavky uvedené a odsúhlasené zákazníkom, ďalšou úlohou je určiť ich prioritu, aby ich bolo možné vyzdvihnúť v šprintoch.

# 5. Matica sledovateľnosti:

Ďalším dôležitým artefaktom, ktorý sa zvyčajne udržiava v modeli vodopádu, je matica vysledovateľnosti. Takže s cieľom zabezpečiť, aby sa nezmeškali žiadne požiadavky; mala by sa navrhnúť a udržiavať aj matica vysledovateľnosti . Zvyčajne v agilných nie je takáto matica navrhnutá.

Toto je najlepšia prax v každom projekte. Matrica vysledovateľnosti by sa mala pripraviť paralelne s nevybavenými položkami produktu. A malo by sa to porovnávať s testovacími prípadmi vykonanými počas užívateľského prijímacieho testovania / end-to-end testovania (táto fáza je vysvetlená v mojom ďalšom bode). Aj keď sa niektorá požiadavka minie, dá sa ľahko začleniť aj v neskorých štádiách vývoja, pretože agilnosť poskytuje mimoriadnu flexibilitu a prispôsobivosť.

Po spustení projektu Online registrácie bol k aplikácii prístupný koncovými používateľmi (študenti, ktorí sa chceli zaregistrovať). V aplikácii čelili mnohým problémom. To malo za následok veľa lístkov získaných pre tím podpory výroby. Vyzvednuté lístky je možné klasifikovať ako incidenty, problémy alebo zmeny. Mnoho problémov bolo vyriešených a predpokladalo sa, že aplikácia sa stane stabilnou. Ale aj potom bolo v nasledujúcich vydaniach naplánovaných viac ako tucet požiadaviek / vylepšení na zmenu. Cieľom týchto vylepšení bolo stabilizovať aplikáciu a zlepšiť dojem koncového používateľa.

Takže nakoniec cena projektu stúpla mnohokrát. Ak teda nebude projekt správne prevedený na agilný, môže to spôsobiť prekročenie rozpočtu. To je veľmi potrebné na naplánovanie dôkladného prechodu projektu na Agile. Plánovanie by sa tiež malo robiť v takom rozsahu, aký projekt vyžaduje, aby mohol byť vykonaný v agilnom režime. Správne hybridné modely by mali byť navrhnuté pre konkrétny projekt.

Pred začatím projektu Exam Entry bol o tento aspekt dobre postarané. Uvažovalo sa o hybridnom modeli a rozhodlo sa, že fáza analýzy požiadaviek a fáza návrhu na vysokej úrovni sa majú vykonať v modeli vodopádu a zvyšné fázy v agilnom modeli.

Prijatý hybridný model je možné názorne znázorniť takto:

Kolaboratívny (hybridný) model 3

Záver:

Je zrejmé, že model Waterfall aj Agile majú svoje vlastné nevýhody. Je teda celkom reálne zvoliť si hybridný model, čo je prístup to najlepšie z oboch svetov.

Najdôležitejším aspektom začiatku každého projektu je rozhodnutie o modeli, ktorý sa tím chystá prijať. To si vyžaduje rozsiahle plánovanie. Pri prijímaní softvérového modelu by sa mali brať do úvahy faktory ako rozpočet, čas, využitie zdrojov, zložitosť požiadaviek atď.

Model Hybrid je stále v štádiu zrodu. Keď si ho osvojí čoraz viac spoločností, dozvieme sa viac o tomto koncepte.

Agilný manifest nás žiada, aby sme si vážili:

  • Jednotlivci a interakcie nad procesmi a nástrojmi
  • Pracovný softvér komplexnú dokumentáciu
  • Spolupráca so zákazníkom nad rokovaním o zmluve
  • Reakcia na zmenu nad dodržiavaním plánu

Hybridný model to síce nedodržiava na 100%. Naznačuje, že všetky aspekty majú rovnakú dôležitosť. Je na klientoch / projektových manažéroch, aby sa rozhodli, ktoré aspekty si budú viac vážiť a ktoré bezcenné.

O autorovi: Toto je hosťovský článok Harshpala Singha. Má viac ako 7 rokov skúseností s manuálnym, databázovým, automatizačným a výkonnostným testovaním a v súčasnosti pracuje ako vedúci tímu v popredných MNC. Pracoval na mnohých QA projektoch podľa Waterfall, Agile a hybridných vývojových modelov.

Máte nejaké skúsenosti s prácou na tomto hybridnom modeli vývoja a testovania? Poďme diskutovať v komentároch.

Odporúčané čítanie

^