Studija slučaja: Kako ukloniti nedostatke vodopada i agilnih razvojnih procesa pomoću hibridnog modela

case study how eliminate flaws waterfall

Agile Hybrid Model vodopada

Model vodopada idealan je izbor za razvoj softvera. U ovom modelu ideja postaje upotrebljiv softver u sekvencijalnom procesu koji se slaže kroz faze pokretanja, analize, primjene, ispitivanja i održavanja.

Ali model Waterfall ima neke nedostatke.

Agilni razvoj softvera razvio se kako bi se uklonili problemi koje model Waterfall ima. Ima potpuno novi okvir. Iako model Waterfall ima sekvencijalni dizajn, Agile model slijedio je inkrementalni pristup.

Kad su klijenti koji su slijedili model Vodopada prešli na Agile, prijelaz je sa sobom donio mnogo problema. Razlog je neprilagođenost drugačijem pristupu razvoju softvera. Ispostavilo se da je krajnji proizvod katastrofa.

Tako je razvijena nova metodologija, koja se može nazvati „hibridom“, kako bi se osigurao robusni krajnji proizvod odabirom prednosti i modela Agile i Waterfall.

Prvo saznajmo za razvojne modele Waterfall i Agile, a zatim prijeđimo na “Agile Waterfall Hybrid Model” sa prednostima i nedostacima svakog.

Što ćete naučiti:

• Model slapa
• Agile Model
• Suradnički (hibridni) model
• Hibridni model okretnog vodopada - naučite na primjeru - studija slučaja
• Kako ukloniti nedostatke vodopada i agilnih razvojnih procesa pomoću hibridnog modela:
• Zaključak:
• Preporučena literatura

Model slapa

Model Waterfall pristup je razvoju softvera koji projekt razdvaja u konačne faze. U sljedeću fazu treba prijeći tek kad se pregleda i provjeri prethodna faza.

U modelu vodopada faze se ne preklapaju.

=> Više o modelu vodopada pročitajte ovdje.

Slika 1 prikazuje model Vodopada:

Prednosti modela vodopada:

kako pokrenuti jar datoteku u sustavu Windows

• Jednostavno i lako za razumijevanje i upotrebu.
• Kruti model - Svaka faza ima određene rezultate i procese pregleda.
• Dokumentacija i artefakti pomno se održavaju.
• Pogodno za projekte u kojima se dobro razumiju zahtjevi.

Mane modela vodopada:

• Nije prikladno za projekte kod kojih postoji rizik da se zahtjevi promijene.
• Troškovi otklanjanja nedostataka vrlo su visoki kada se otkriju u kasnijoj fazi.
• Nije dobar model za složene i duge projekte.
• Nijedan radni softver ne proizvodi se kasno tijekom životnog ciklusa.

Agile Model

Wikipedia definira Agile model kao 'skup metoda razvoja softvera zasnovanih na iterativnom i inkrementalnom razvoju, gdje se zahtjevi i rješenja razvijaju suradnjom između samoorganizirajućih, višefunkcionalnih timova.'

Model ima svoja vlastita načela koja vode postupke na stražnje sjedalo.

=> Više članaka o agilnoj metodologiji pročitajte ovdje.

(Kliknite na sliku za uvećan prikaz)

Prednosti Agile modela:

• Uključivanje kupaca u proces.
• Visok ROI kao radni softver često se isporučuje.
• Čak se i kasne promjene u zahtjevima mogu lako prilagoditi.
• Stalno poboljšanje proizvoda i procesa.

Mane agilnog modela:

• Nedostatak naglaska na dizajniranju i dokumentaciji.
• Tim bi trebao biti stabilan i vješt.

Suradnički (hibridni) model

Cilj kolaborativnog modela je kombiniranje oba modela - vodopada i okretnosti. Iskorištavanjem pristupa Waterfall i Agile osigurava uspjeh projekta. Uklanja nedostatke oba modela; dok objedinjuje prednosti oba.

Model suradnje može se implementirati u projekt izvršavanjem:

Dakle, model suradnje može se shematski predstaviti na sljedeći način:

Prednosti hibridnog modela

• Kombinira blagodati i agilnih i slapovskih procesa.
• Dizajn visoke razine pripremljen je za primjenu principa vodopada.
• Kodiranje i testiranje vrši se agilnom metodologijom.

Agile Hybrid Model slapa - naučite na primjeru -Studija slučaja

Softverska tvrtka 'ABC Software Service's' pruža usluge klijentu, sveučilištu pod nazivom 'XYZ University' za razvoj, testiranje i održavanje njihovog softvera (podrška za produkciju uživo).

Glavne značajke računa su:

1. ABC softverske usluge moraju nadograditi aplikacije Sveučilišta XYZ. Bazu podataka treba nadograditi, a sve aplikacije treba ponovo razviti do najnovije tehnologije dostupne na tržištu.
2. Do sada su se svi projekti kojima se bavio ABC Software izvodili u modelu Waterfall.
3. Dvije od gustog prometa i visokoprioritetne aplikacije sada su trebale biti ponovno razvijene. Prvo je ‘mrežne registracije’, drugo je ‘mrežni pregledi’.
4. Klijent XYZ Sveučilište sada je želio da se na tim aplikacijama radi pomoću Agile modela razvoja softvera.

Prvi projekt u Agile modelu za ABC softver bile su mrežne registracije. Nakon izvršenja ovog projekta, u nizu retrospektiva uvidjelo se da je bilo puno nedostataka u slijeđenim procesima.

Te su se nedostatke riješile tijekom izvršavanja drugog projekta 'mrežni pregledi', pa je stoga izveden u hibridnom modelu.

Kako ukloniti nedostatke vodopada i agilnih razvojnih procesa pomoću hibridnog modela:

Razgovarajmo o njima detaljno jedan po jedan.

# 1. Nema dokumentacije:

Jedno od agilnih načela u agilnom manifestu navodi da: Agile daje veću vrijednost 'Radnom softveru preko sveobuhvatne dokumentacije'. Agile metodologija vjeruje da bi dokumentacija trebala biti 'jedva dovoljno dobra', a veći se naglasak daje na isporuci ispravnog softvera. Ne ulaže se puno truda u dokumentaciju, ali za račune poput Sveučilišta XYZ, s posebnim timom za podršku koji radi na nedostacima utvrđenim na projektima uživo, ova se navika može pokazati kao prepreka ako je dugoročno analiziramo.

Tijekom godina, kada su se projekti izvodili u modelu Waterfall, održavali su se i ažurirali dokumenti kako bi ih tim za podršku razumio i radio u skladu s tim. Dizajn rješenja, tehnički dizajn, priručnici itd. Bili su neki od pripremljenih dokumenata. Nakon završetka projekta, isti je prebačen u tim za podršku.

No, u slučaju projekta 'mrežne registracije' takvi dokumenti nisu pripremljeni i to se pokazalo skupim. Kad je projekt krenuo s radom, krajnji su korisnici podigli mnoge ulaznice i tim za podršku nije imao pojma kako na njima raditi. Tim nije imao referencu.

Ovo je bila velika naučena lekcija, a za sljedeći su projekt dokumenti 'mrežni pregledi' napisani i učinkovito prebačeni.

=> Ovdje pročitajte više zašto je dokumentacija važna.

#dva. Nema UAT / end-to-end testiranja:

U agilnom načinu razvoja softvera, testeri dobivaju građevine za testiranje u koracima. Te se gradnje nastavljaju integrirati sve dok konačna gradnja nije u potpunosti izgrađena. Ispitivači testiraju zahtjeve pokrivene svakim sprintom i nastavljaju s regresijskim testiranjem građe koja se neprestano zbraja.

Ali nakon što su svi sprinti dovršeni i konačna je verzija spremna i integrirana, ispitivač bi trebao testirati kompletni sustav i provesti testiranje od kraja do kraja. To bi trebalo učiniti u potpuno novom okruženju.

=> Testiranje od kraja do kraja na projektu uživo.

Ovo ima svoje prednosti:

• Kompletni sustav postavljen je u novo okruženje i tester testira kompletan protok.
• Gradi samopouzdanje, jer u konačnici, gradnju treba implementirati kao cjelinu u živo okruženje.

Kada je projekt Online registracije testiran, to je učinjeno u testnom okruženju. Nakon testiranja i ponovnog testiranja svih nedostataka, proglašen je za odjavu. Idealno je da ovo nije promovirano u drugo okruženje za novi ciklus testiranja sustava. (Idealno, UAT se događa nakon testiranja sustava , ali u ovom slučaju, članovi UAT tima bili su uključeni u prvi ciklus testiranja, tako da nije zakazan drugi ciklus)

Kada je započeo projekt mrežnih pregleda, provedeno je SIT (System Integration Testing) i kôd je promoviran u UAT okruženje gdje je proveden drugi ciklus testiranja. Rezultat: Svi nedostaci visokog prioriteta su zabilježeni i riješeni. Izgradnja je bila stabilna prije puštanja uživo.

# 3. Nema Scrum Master:

The Scrum Master odgovoran je za osiguravanje da tim živi u skladu s vrijednostima i praksom Scruma. Scrum Master se smatra trenerom tima pomažući timu da obavi najbolji posao koji je moguće. Scrum Master se također može smatrati a vlasnik procesa za tim.

Tim za mrežne registracije formiran je bez Scrum Master-a. Važnost posjedovanja posvećenog Scrum Mastera nije se smatrala važnom. To je rezultiralo mnogim problemima koji se nisu riješili na vrijeme, a vrijeme za završetak projekta često je prelazilo rok.

Međutim, posvećeni Scrum Master bio je uključen u projekt mrežnih pregleda. Za pitanja i izazove projekta pobrinuo se Scrum Master. Pripremljena su izvješća o projektu / sprintu i tim je mogao vidjeti njihov napredak.

Također, održani su pravilni sastanci za planiranje sprinta i retrospektivni sastanci sprinta za svaki sprint koji je poboljšao performanse ekipe. Tim se koncentrirao samo na svoj posao i izvršavao zadatke dodijeljene za taj sprint. Svim dodatnim domaćinstvom vodio se Scrum Master.

# 4. Pretvaranje projektnih dokumenata u zaostale proizvode:

Početni projektni dokumenti koji su pripremljeni u modelu slapa su Specifikacija poslovnih zahtjeva (BRS), Dizajn na visokoj razini, Funkcionalni dizajn, itd. Ovi dokumenti trebaju se transformirati u zaostatak proizvoda kako bi se izvršile faze kodiranja, ispitivanja i implementacije. u agilnom načinu. Ovo je vrlo važan korak.

Zaostatak proizvoda polazna je točka agilnog projekta. Zaostatak proizvoda prioritetni je popis zahtjeva koji se održava za proizvod. Sastoji se od značajki, ispravki programskih pogrešaka, nefunkcionalnih zahtjeva itd. To je dokument koji raste i postaje sve bolji i bolji na temelju povratnih informacija kupaca, promjena zahtjeva itd.

Budući da je prvi artefakt bilo kojeg projekta, najvažnije je navesti zahtjeve i dodijeliti im prioritete. Pretvaranje projektnih dokumenata vodopada u zaostale proizvode velik je zadatak sam po sebi i zahtijeva mozganje cijelog tima zajedno s kupcem / dionicima.

Nakon što su kupci navedeni i složeni sa svim zahtjevima, sljedeći je zadatak odrediti ih po prioritetu kako bi ih pokupio u sprintima.

# 5. Matrica sljedivosti:

Još jedan važan artefakt koji se obično održava u modelu vodopada je matrica sljedivosti. Dakle, kako bismo osigurali da se nikakvi zahtjevi ne propuste; treba dizajnirati i održavati i matricu sljedivosti . Obično u agilnom sustavu takva matrica nije dizajnirana.

Ovo je najbolja praksa u bilo kojem projektu. Matricu sljedivosti treba pripremiti paralelno s zaostatkom proizvoda. I to bi trebalo provjeriti u odnosu na test slučajeve izvršene tijekom testiranja prihvaćanja korisnika / testiranja od kraja do kraja (ova je faza objašnjena u mojoj sljedećoj točki). Čak i ako se bilo koji zahtjev propusti, lako se može ugraditi čak i u kasnim fazama razvoja jer okretnost pruža dodatnu fleksibilnost i prilagodljivost.

Nakon što je projekt mrežnih registracija objavljen, aplikaciji su pristupili krajnji korisnici (studenti koji su se željeli registrirati). U prijavi su se suočili s puno problema. To je rezultiralo puno ulaznica prikupljenih za tim za podršku produkciji. Podignute karte mogu se klasificirati kao incidenti, problemi ili promjene. Riješeno je puno problema, predviđajući da će aplikacija postati stabilna. No i tada je u sljedećim izdanjima planirano više od desetak zahtjeva / poboljšanja za promjenu. Ova poboljšanja trebala su stabilizirati aplikaciju i poboljšati iskustvo krajnjeg korisnika.

Dakle, na kraju su troškovi projekta porasli u mnogo navrata. Stoga, ako projekt nije pravilno prebačen na agilni, to može dovesti do prekoračenja proračuna. To je vrlo potrebno za planiranje temeljnog prijelaza projekta na agilni. Također, planiranje treba izvršiti u mjeri u kojoj projekt treba kako bi se izveo u agilnom načinu. Odgovarajući hibridni modeli trebali bi biti dizajnirani za određeni projekt.

Prije početka projekta za prijavu ispita, ovaj se aspekt dobro pazio. Razmišljalo se o hibridnom modelu i odlučeno je da se faza analize zahtjeva i faza projektiranja na visokoj razini izvrše u modelu slapa, a ostale faze u agilnom modelu.

Usvojeni hibridni model može se slikovito predstaviti na sljedeći način:

Zaključak:

Očito je da i model Waterfall i Agile model imaju svoje nedostatke. Dakle, sasvim je realno odlučiti se za hibridni model, što je pristup iskorištavajući najbolje iz oba svijeta.

Najvažniji aspekt početka bilo kojeg projekta je odlučiti model koji će tim usvojiti. To zahtijeva opsežno planiranje. Pri usvajanju softverskog modela treba uzeti u obzir čimbenike kao što su proračun, vrijeme, korištenje resursa, složenost zahtjeva itd.

Hibridni model je još uvijek u fazi uspona. Kako će ga sve više i više tvrtki usvajati, naučit ćemo više o ovom konceptu.

Agile manifest traži od nas da vrednujemo:

• Pojedinci i interakcije nad procesima i alatima
• Radni softver preko sveobuhvatne dokumentacije
• Suradnja s kupcima preko pregovora o ugovoru
• Reagiranje na promjene preko slijeđenja plana

Dok se hibridni model ne drži ovih 100%. Sugerira da su svi aspekti jednako važni. Na klijentima / voditeljima projekata je da odluče koje će aspekte više cijeniti, a koje bezvrijedne.

O autoru: Ovo je gostujući članak Harshpala Singha. Ima 7+ godina iskustva s ručnim rukovanjem, bazama podataka, automatizacijom i testiranjem performansi, a trenutno radi kao voditelj tima u vodećem MNC-u. Radio je na mnogim QA projektima slijedeći modele vodopada, agilnog i hibridnog razvoja.

Imate li iskustva s radom na ovom hibridnom modelu za razvoj i testiranje? Razgovarajmo u komentarima.

Preporučena literatura

• Agile Vs Waterfall: Koja je najbolja metodologija za vaš projekt?
• Što je SDLC model vodopada?
• Pregled alata za upravljanje testovima Zephyr Enterprise - Kako koristiti sredstva modela slapa u Agile Tool-u
• Spiralni model - što je SDLC spiralni model?
• 4 koraka prema razvoju agilnog načina testiranja za uspješan prijelaz na agilni proces
• JIRA Agile Tutorial: Kako učinkovito koristiti JIRA za upravljanje agilnim projektima
• SDLC (životni ciklus razvoja softvera) faze, metodologije, procesi i modeli
• Agile Manifesto: Razumijevanje agilnih vrijednosti i principa