Menu

Případová studie: Jak eliminovat nedostatky vodopádu a agilní vývojové procesy pomocí hybridního modelu

  • Hlavní
  • Agilní Testování
  • Případová studie: Jak eliminovat nedostatky vodopádu a agilní vývojové procesy pomocí hybridního modelu

case study how eliminate flaws waterfall

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Hybridní model Agile Waterfall

Model Waterfall byl ideální volbou pro vývoj softwaru. V tomto modelu se myšlenka stává použitelným softwarem v sekvenčním procesu, který kaskádovitě přechází do fází zahájení, analýzy, implementace, testování a údržby.

Model Waterfall má ale některé nevýhody.

Agilní vývoj softwaru se vyvinul, aby eliminoval problémy, které model Waterfall má. Má zcela nový rámec. Zatímco model Waterfall má sekvenční design, model Agile se řídil přírůstkovým přístupem.

Když klienti, kteří sledovali model Waterfall, přešli na Agile, přechod s sebou přinesl mnoho problémů. Důvodem je nepřizpůsobivost jinému přístupu k vývoji softwaru. Konečný produkt se ukázal být katastrofou.

Hybridní model Agile Waterfall

Vyvinula se tak nová metodika, kterou lze nazvat „hybridní“, která zajistí robustní konečný produkt výběrem výhod modelů Agile i Waterfall.

Nejprve si povíme o vývojových modelech Waterfall a Agile a poté přejděte na „Agile Waterfall Hybrid Model“ s klady a zápory každého z nich.

Co se naučíte:

Model vodopádu

Waterfall model je přístup k vývoji softwaru, který rozděluje projekt na konečné fáze. Jeden by měl přejít do další fáze, pouze když je zkontrolována a ověřena předchozí fáze.

V modelu vodopádu se fáze nepřekrývají.

=> Přečtěte si více o modelu vodopádu zde.

Obrázek 1 ukazuje model Waterfall:

zadaná IP adresa brány není platná

Model vodopádu

Výhody modelu Waterfall:

  • Jednoduché a snadno pochopitelné a použitelné.
  • Pevný model - každá fáze má konkrétní výstupy a kontrolní procesy.
  • Dokumentace a artefakty jsou pečlivě udržovány.
  • Vhodné pro projekty, kde jsou dobře pochopeny požadavky.

Nevýhody modelu Waterfall:

  • Nevhodné pro projekty, u nichž hrozí, že se požadavky změní.
  • Náklady na opravu vad jsou velmi vysoké, jsou-li zjištěny později.
  • Není to dobrý model pro složité a dlouhé projekty.
  • Do konce životního cyklu se nevyrábí žádný funkční software.

Agilní model

Wikipedia definuje Agilní model jako „skupinu metod vývoje softwaru založenou na iterativním a přírůstkovém vývoji, kde se požadavky a řešení vyvíjejí ve spolupráci mezi samoorganizujícími se mezifunkčními týmy.“

Model má své vlastní principy, které mají tendenci přivádět procesy na zadní sedadlo.

=> Přečtěte si více článků o agilní metodice zde.

(Klikněte na obrázek pro zvětšení)

Agilní model

Výhody agilního modelu:

  • Zapojení zákazníků do procesu.
  • Vysoká návratnost investic jako pracovní software se dodává často.
  • I pozdní změny v požadavcích lze snadno přizpůsobit.
  • Neustálé zlepšování produktu i procesu.

Nevýhody agilního modelu:

formát testovacího případu v testování softwaru
  • Nedostatečný důraz na projektování a dokumentaci.
  • Tým by měl být stabilní a kvalifikovaný.

Kolaborativní (hybridní) model

Kolaborativní model si klade za cíl spojit oba modely - Waterfall a Agile. Využití přístupu Waterfall a Agile zajišťuje úspěch projektu. Odstraňuje nevýhody obou modelů; a zároveň spojuje výhody obou.

Kolaborativní model lze v projektu implementovat provedením:

Kolaborativní (hybridní) model

Kolaborativní model lze tedy znázornit schematicky, jak je uvedeno níže:

Kolaborativní (hybridní) model 2

Výhody modelu Hybrid

  • Kombinuje výhody agilních i vodopádových procesů.
  • Návrh na vysoké úrovni je připraven aplikovat principy vodopádu.
  • Kódování a testování se provádí pomocí agilní metodiky.

Hybridní model Agile Waterfall - učit se příkladem -Případová studie

Softwarová firma „ABC Software Service“ poskytuje služby klientovi, univerzitě s názvem „XYZ University“, za účelem vývoje, testování a údržby jejich softwaru (podpora živé produkce).

Hlavní funkce účtu jsou:

  1. ABC Software Services musí upgradovat aplikace XYZ University. Databázi je třeba upgradovat a všechny aplikace je třeba znovu vyvinout na nejnovější technologii dostupnou na trhu.
  2. Až dosud byly všechny projekty zpracovávané společností ABC Software prováděny v modelu Waterfall.
  3. Dvě z aplikací s velkým provozem a vysokou prioritou byly nyní naplánovány na nový vývoj. První je „Online registrace“, druhou „Online zkoušky“.
  4. Klientská univerzita XYZ nyní chtěla, aby se na těchto aplikacích pracovalo pomocí agilního modelu vývoje softwaru.

Prvním projektem v agilním modelu pro ABC Software byly online registrace. Po provedení tohoto projektu bylo v sérii retrospektiv realizováno, že v postupech bylo mnoho nedostatků.

O tyto nedostatky bylo postaráno při provádění druhého projektu „online vyšetření“, a byl proto proveden v hybridním modelu.

Jak eliminovat nedostatky vodopádu a agilní vývojové procesy pomocí hybridního modelu:

Pojďme si o nich podrobně promluvit jeden po druhém.

# 1. Žádná dokumentace:

Jeden z agilních principů agilního manifestu uvádí, že: Agile dává větší hodnotu „Working Software over Comprehensive Documentation“. Agilní metodologie se domnívá, že dokumentace by měla být „jen sotva dost dobrá“ a větší důraz je kladen na dodání funkčního softwaru. Dokumentace nevyvíjí příliš mnoho úsilí, ale u účtů, jako je XYZ University, se specializovaným týmem podpory pro práci na defektech nalezených na živých projektech, se tento zvyk může ukázat jako překážka, pokud ji budeme analyzovat dlouhodobě.

V průběhu let, kdy byly projekty prováděny v modelu Waterfall, byly dokumenty udržovány a aktualizovány, aby tým podpory porozuměl a podle toho pracoval. Některé z připravených dokumentů byly návrh řešení, technický design, průchozí dokumenty atd. Po skončení projektu bylo totéž převedeno do týmu podpory.

V případě projektu „online registrace“ však žádné takové dokumenty nebyly připraveny, což se ukázalo jako nákladné. Když byl projekt spuštěn, koncoví uživatelé vyzvedli mnoho lístků a tým podpory neměl ponětí, jak na nich pracovat. Tým neměl žádný referenční dokument.

To byla hlavní poučení a pro další projekt byly „online zkoušky“ dokumenty sepsány a efektivně převedeny.

=> Přečtěte si více zde, proč je dokumentace důležitá.

#dva. Žádné UAT / end-to-end testování:

V agilním režimu vývoje softwaru dostávají testeři sestavy k testování v přírůstcích. Tyto sestavení pokračují v integraci, dokud není zcela sestaveno konečné sestavení. Testeři testují požadavky obsažené v každém sprintu a pokračují v regresním testování sestavení, které se neustále zvyšuje.

Ale poté, co jsou všechny sprinty hotové a finální sestavení je připravené a vše integrované, by měl tester otestovat celý systém a měl by provést end-to-end testování. To by mělo být provedeno ve zcela novém prostředí.

=> End-to-end testování na živém projektu.

To má své vlastní výhody:

  • Celý systém je nasazen do nového prostředí a tester testuje celý tok.
  • Vytváří důvěru, protože v konečném důsledku je nutné sestavení nasadit jako celek v živém prostředí.

Když byl testován projekt Online registrace, byl proveden v testovacím prostředí. Po testování systému a opětovném testování všech defektů byl deklarován pro odhlášení. V ideálním případě to nebylo povýšeno do jiného prostředí pro další cyklus testování systému. (Ideálně, UAT se stane po testování systému , ale v tomto případě byli členové týmu UAT zapojeni do prvního cyklu testování, takže nebyl naplánován žádný druhý cyklus)

Když byl zahájen projekt online zkoušek, byl proveden test SIT (System Integration Testing) a kód byl povýšen do prostředí UAT, kde byl proveden druhý cyklus testování. Výsledek: Všechny vady s vysokou prioritou byly zachyceny a vyřešeny. Sestavení bylo stabilní před vydáním naživo.

# 3. No Scrum Master:

The Scrum Master odpovídá za to, že tým bude žít podle hodnot a postupů Scrumu. Scrum Master je považován za kouče týmu, protože pomáhá týmu dělat tu nejlepší práci, jakou může. Scrum Master lze také považovat za vlastník procesu pro tým.

nejlepší bezplatný měnič hlasu pro svár

Tým online registrace byl vytvořen bez Scrum Master. Důležitost mít vyhrazeného Scrum Master se nepovažovala za důležitou. To vedlo k tomu, že mnoho problémů nebylo vyřešeno včas a čas na dokončení projektu pak často překročil termín.

Do projektu Online zkoušky však byl zapojen specializovaný Scrum Master. O problémy a výzvy projektu se postaral Scrum Master. Byly připraveny zprávy o projektu / sprintu a tým mohl vidět jejich pokrok.

U každého sprintu také proběhly správné schůzky pro plánování sprintu a retrospektivní schůzky sprintu, které zlepšily výkonnost týmu. Tým se soustředil pouze na svou práci a plnění úkolů určených pro tento sprint. Veškeré další úklid zajišťoval Scrum Master.

# 4. Převod projektových dokumentů na nevyřízené položky produktu:

Počáteční projektové dokumenty, které jsou připraveny v modelu vodopádu, jsou specifikace obchodních požadavků (BRS), design na vysoké úrovni, funkční design atd. Tyto dokumenty je třeba převést na nevyřízené položky produktu, aby bylo možné provést fáze kódování, testování a implementace v agilním režimu. Toto je velmi důležitý krok.

Nevyřízené položky produktu jsou výchozím bodem agilního projektu. Nevyřízené položky produktu jsou prioritním seznamem požadavků, které jsou pro produkt udržovány. Skládá se z funkcí, oprav chyb, nefunkčních požadavků atd. Jedná se o rostoucí dokument, který se zvětšuje a zlepšuje na základě zpětné vazby od zákazníků, měnících se požadavků atd.

Jako první artefakt jakéhokoli projektu je nejdůležitější vyjmenovat požadavky a přiřadit jim priority. Konverze dokumentů projektu Waterfall na nevyřízené produkty je sama o sobě velkým úkolem a vyžaduje brainstorming celého týmu spolu se zákazníkem / zúčastněnou stranou.

Jakmile jsou všechny požadavky uvedeny a odsouhlaseny zákazníkem, dalším úkolem je upřednostnit je, aby je bylo možné vyzvednout ve sprintech.

# 5. Matice sledovatelnosti:

Dalším důležitým artefaktem, který je obvykle udržován v modelu vodopádu, je matice sledovatelnosti. Aby se zajistilo, že nebudou přijaty žádné požadavky; měla by být rovněž navržena a udržována matice sledovatelnosti . Obvykle v agilní není taková matice navržena.

Toto je nejlepší praxe v každém projektu. Matrice sledovatelnosti by měla být připravena souběžně s nevyřízenými položkami produktu. Mělo by se to porovnat s testovacími případy provedenými během uživatelského akceptačního testování / end-to-end testování (tato fáze je vysvětlena v mém dalším bodě). I když se některý požadavek zmešká, lze jej snadno začlenit i v pozdních fázích vývoje, protože agilnost poskytuje mimořádnou flexibilitu a přizpůsobivost.

Po spuštění projektu Online registrace se do aplikace dostali koncoví uživatelé (studenti, kteří se chtěli zaregistrovat). V aplikaci čelili mnoha problémům. To vyústilo v spoustu lístků získaných pro tým podpory produkce. Získané vstupenky lze klasifikovat jako incidenty, problémy nebo změny. Bylo vyřešeno mnoho problémů a předpokládalo se, že aplikace bude stabilní. Ale i tehdy bylo v následujících verzích naplánováno více než tucet požadavků / vylepšení na změnu. Tato vylepšení měla stabilizovat aplikaci a zlepšit zážitek koncového uživatele.

Nakonec tedy náklady na projekt vzrostly mnohokrát. Pokud tedy projekt není správně převeden na agilní, může to způsobit překročení rozpočtu. To je velmi nutné k plánování důkladného přechodu projektu na Agile. Plánování by se mělo provádět v rozsahu, který projekt potřebuje, aby mohl být proveden v agilním režimu. Správné hybridní modely by měly být navrženy pro konkrétní projekt.

Před zahájením projektu Exam Entry byl o tento aspekt dobře postaráno. Byl uvažován hybridní model a bylo rozhodnuto, že fáze analýzy požadavků a fáze návrhu na vysoké úrovni budou provedeny v modelu vodopádu a zbytek fází v agilním modelu.

Přijatý hybridní model lze názorně znázornit níže:

Kolaborativní (hybridní) model 3

Závěr:

Je zřejmé, že jak model Waterfall, tak model Agile mají své vlastní nevýhody. Je tedy docela realistické zvolit si hybridní model, což je přístup to nejlepší z obou světů.

Nejdůležitějším aspektem zahájení každého projektu je rozhodnout o modelu, který tým přijme. To vyžaduje rozsáhlé plánování. Při přijímání softwarového modelu je třeba vzít v úvahu faktory, jako je rozpočet, čas, využití zdrojů, složitost požadavků atd.

Hybridní model je stále v rodící se fázi. Jak si jej bude osvojovat stále více společností, dozvíme se více o tomto konceptu.

Agilní manifest nás žádá, abychom si cenili:

  • Jednotlivci a interakce nad procesy a nástroji
  • Pracovní software přes komplexní dokumentaci
  • Spolupráce se zákazníky nad vyjednáváním smlouvy
  • Reakce na změnu nad dodržováním plánu

Hybridní model to 100% nedodržuje. Naznačuje, že všechny aspekty mají stejnou důležitost. Je na klientech / projektových manažerech, aby se rozhodli, které aspekty si budou více vážit a které bezcenné.

O autorovi: Toto je hostující článek Harshpala Singha. Má více než 7 let zkušeností s manuálním, databázovým, automatizačním a výkonovým testováním a v současné době pracuje jako vedoucí týmu v předním MNC. Pracoval na mnoha projektech QA v návaznosti na vývojové modely Waterfall, Agile a hybrid.

Máte nějaké zkušenosti s prací na tomto modelu vývoje a testování hybridů? Pojďme diskutovat v komentářích.

Doporučené čtení

^