Agile Vs Waterfall: Koja je najbolja metodologija za vaš projekt?

agile vs waterfall which is best methodology

funkcija vremena () c ++

Saznajte sve o agilnim i vodopadnim metodologijama, različitim vrstama SDLC modela i razlikama između vodopadnih i okretnih razvojnih modela, kao i testiranja:

Pročitajte ovaj informativni članak da biste na temelju prednosti i nedostataka svakog od njih odlučili koji je najprikladniji model za vaš projekt.

Model vodopada i agilni model su vrste životnog ciklusa razvoja softvera (SDLC). To su procesi koje softverska industrija koristi za dizajn, razvoj i testiranje softvera.

Slijedeći SDLC, možemo postići očekivanja kupaca, dovršiti projekt u zadanim vremenskim okvirima i procijeniti trošak.

Što ćete naučiti:

• Tijek posla vodopada i agilnog modela
  • Što je životni ciklus razvoja softvera?
  • Vrste životnog ciklusa razvoja softvera
    • # 1) Model vodopada
    • # 2) okretan model
    • # 3) Spiralni model
    • # 4) Model prototipa
    • # 5) V i V model
• Model slapa
• Agilan tijek rada
  • Ključne terminologije korištene u agilnosti
  • Ključni čimbenici za usvajanje agilne metodologije
  • Vrste agilnih metodologija
• Razlika između agilnih Vs modela vodopada
• Razlike između agilnog testiranja i testiranja vodopada
• Zaključak
  • Preporučena literatura

Tijek posla vodopada i agilnog modela

Na jednostavnom engleskom jeziku, Agile znači 'sposoban se kretati brzo i lako' i stoga to znači kada je riječ o Agilna metodologija razvoja .

Agile je metoda upravljanja projektima koja je predstavljena dijeljenjem zadataka na kraće segmente rada s čestim pregledima i prilagođavanjem planova.

Slično tome, riječ vodopad označava vertikalni tok vode ili protok vode kroz niz strmih padova. Model slapa linearni je sekvencijalni model u kojem napredak teče uglavnom u jednom smjeru prema dolje kroz faze prikupljanja zahtjeva, analize, dizajna, razvoja, ispitivanja, postavljanja i održavanja.

Ista ilustracija odnosi se na koncept upravljanja projektima kada je u pitanju model vodopada . To je metoda upravljanja projektom koja je predstavljena serijskim fazama i fiksnim planom rada.

(slika izvor )

Prije rasprave o tijeku vodopada i agilnom tijeku rada, pogledajmo definiciju životnog ciklusa razvoja softvera i njegove zahtjeve.

Što je životni ciklus razvoja softvera?

Postupni je postupak sustavnog razvoja softvera. Za to biramo između različitih vrsta životnih ciklusa razvoja softvera u različitim tvrtkama. Na temelju zahtjeva odabire se odgovarajući životni ciklus.

Model slapa jedna je od SDLC vrsta i stari je proces razvoja softvera. Agilan model je najnoviji i napredni. Agile je izveden iz drugog životnog ciklusa razvoja softvera.

Ostali SDLC uključuje spiralni model, V i V model, model Prototype. Na temelju nužnosti i kompatibilnosti poslovnih zahtjeva, odabrat ćemo najbolji model za razvoj softverske aplikacije.

(slika izvor )

Zašto je potreban životni ciklus razvoja softvera?

SDLC je potreban za strukturirano upravljanje projektom. Pruža određenu razinu kontrole i definira uloge i odgovornosti članova tima. Pruža opseg i rok za svaku fazu u SDLC-u.

To je pomalo poput korisničkog vodiča za članove tima da slijede sve korake za razvoj i isporuku kvalitetnog proizvoda. Pomaže menadžmentu tima da definira i procijeni ciljeve i zahtjeve. Također pomaže u raspoređivanju i procjeni zadataka. Čini komunikacijsku liniju između klijenta i razvojnog tima i stvara uloge i odgovornosti za svakog od njih.

Vrste životnog ciklusa razvoja softvera

Pogledajmo kratki uvod u vrste SDLC-a koji se koriste u procesu razvoja softvera.

# 1) Model vodopada

Kao što je ranije spomenuto, model vodopada prvi je predstavljeni životni ciklus razvoja softvera. To je sekvencijalni način razvoja softvera. Vrlo malo tvrtki slijedi ovaj pristup. Kad je projekt vrlo jednostavan i ne bude daljnjih promjena zahtjeva, slijedit ćemo ovaj pristup.

O ovom modelu voditelja razgovarat ćemo više u ovom vodiču.

# 2) okretan model

Agilan tijek rada napredni je pristup procesu razvoja softvera koji se koristi u većini tvrtki. Agile se definira kao životni ciklus razvoja softvera temeljenog na sprintu.

U sljedećim odjeljcima možemo više razgovarati o agilnom tijeku rada.

# 3) Spiralni model

To je način izgradnje i testiranja softvera dijeljenjem i dodavanjem zahtjeva u inkrementalnom redoslijedu. Ovaj model pomoći će u projektima u kojima se zahtjevi neprestano mijenjaju. Ovaj spiralni model kombinacija je iterativnog procesa razvoja i sekvencijalnog linearnog procesa razvoja.

Ovaj pristup omogućit će nam postupna izdanja proizvoda. Ovdje nije potrebno čekati završetak svih modula softvera za izdanje.

Linearni sekvencijalni model znači da je to sustavni sekvencijalni pristup razvoju softvera koji započinje na razini sustava i napreduje analizom, dizajnom, kodiranjem, testiranjem i podrškom.

Iterativni model znači da je to posebna primjena životnog ciklusa razvoja softvera koja se fokusira na početnu, pojednostavljenu implementaciju, koja zatim postupno dobiva sve veću složenost i postavlja se šira značajka dok konačni sustav ne bude dovršen.

# 4) Model prototipa

Ovaj model uključuje postupak izrade i testiranja softvera na takav način da prvo razvijemo lažni model, a ako je izvediv i dostigne sve poslovne zahtjeve, implementiramo stvarni radni model.

Ovdje smo prvo izgradili i testirali prototip, a zatim izgradili stvarni model s točnim specifikacijama sustava. Izrada prototipa softvera aktivnost je stvaranja prototipova softverskih aplikacija.

# 5) V i V model

To je model provjere i potvrde. Evo, dok smo razvijali softver, koristili smo se za provjeru i potvrdu svega u svakoj fazi SDLC-a. V-model se smatra produžetkom modela slapa.

Dakle, sve vrste SDLC imaju svoje značajke i karakteristike. Na temelju zahtjeva projekta, potreba, izvedivosti, vremenskog trajanja, možemo odabrati određeni životni ciklus razvoja softvera za razvoj softverske aplikacije.

Sada ćemo detaljno razgovarati o životnim ciklusima razvoja softvera Waterfall i Agile.

Model slapa

U modelu vodopada, svaku fazu treba završiti prije početka druge faze. Ne možemo istovremeno raditi s više faza. To je 1970. predstavio Winston Royce. Model vodopada podijeljen je u različite faze.

(slika izvor )

Model vodopada uključuje sljedeće faze:

1. Prikupljanje zahtjeva
2. Studija izvodljivosti
3. Oblikovati
4. Kodiranje
5. Testiranje
6. Održavanje

# 1) Analiza zahtjeva

Ovdje će poslovni analitičar dobiti specifikaciju zahtjeva. Zahtjev će biti u formatu CRS (specifikacija zahtjeva kupca). CRS objašnjava kako treba ići poslovni tok i kako aplikacija treba raditi prema navedenom zahtjevu. Poslovni analitičari pretvorit će CRS u SRS (specifikacija softverskog zahtjeva).

Tada poslovni analitičar detaljno razgovara o specifikacijama zahtjeva s timom za razvoj i testiranje i razumije zahtjev s gledišta razvoja i ispitivanja. Ovo je faza rasprave i analize zahtjeva za izgradnju aplikacijskog softvera na temelju stvarnih zahtjeva.

Ovdje bi sve trebalo biti dokumentirano u dokumentu sa specifikacijom softverskih zahtjeva. U modelu slapa, isporuka / rezultat / izlaz svake faze ulazni je izvor za sljedeće faze.

U industriji koja se temelji na uslugama, poslovni analitičar može donijeti zahtjev.
U tvrtki koja se temelji na proizvodu, Product Analyst donosi zahtjev.

# 2) Studija izvedivosti

Uprava će izraditi studiju izvedivosti. To znači da će tim analizirati parametre poput toga, može li se ovaj zahtjev / aplikacija razviti u našem okruženju ili ne, je li raspoloživi resurs dovoljan ili ne, troškovi i mnogi drugi čimbenici su izvedivi ili ne i provjeriti jesmo li u mogućnosti pokriti svi poslovi teku ili ne.

Na ovom sastanku / analizi voditelj projekta, poslovni analitičar, voditelj financija, HR, voditelj projekta bit će dio rasprave.

# 3) Dizajn sustava

Ovdje će Project Architect pripremiti dizajn sustava. Odredit će hardver, zahtjeve sustava i dizajnirati arhitekturu aplikacije. Postoje dva dijela u dizajnu sustava: dizajn na visokoj razini i dizajn na niskoj razini. U dizajnu na visokoj razini dizajniramo različite blokove aplikacije. U dizajnu na niskoj razini pišemo pseudo-kod.

# 4) Kodiranje

Ovdje programeri započinju točno kodiranje svake funkcije i korisničkog sučelja aplikacije pomoću različitih metoda i različitih logika. Za izradu aplikacije mogu koristiti bilo koji programski jezik poput Jave, Pythona ili bilo kojeg drugog jezika.

Nakon što je kodiranje završeno za svaku funkcionalnost određenog modula aplikacije, programer će izvršiti jedinstveno testiranje. Ako kôd radi u redu, programer će ga rasporediti u okruženje za testiranje i dati izradu ispitivaču na testiranje.

# 5) Testiranje

Odavde započinje aktivnost testiranja. Do ove faze nećemo imati nikakav zadatak u modelu Waterfall. U ovoj fazi radimo sve vrste ispitivanja. Te vrste testiranja uključuju testiranje dima, funkcionalno ispitivanje, testiranje integracije, testiranje sustava, ispitivanje prihvaćanja, regresijsko testiranje, ad hoc testiranje, istraživačko testiranje i testiranje u više preglednika.

Započet ćemo s testiranjem aplikacije nakon što dobijemo izradu. Prvo ćemo započeti s testiranjem dima. Ako se ne primijete problemi s blokerom, nastavit ćemo s detaljnim ispitivanjem.

U funkcionalnom testiranju započet ćemo testirati svaku komponentu aplikacije. Ovdje provjeravamo različite komponente poput tekstualnih polja, gumba, veza, radio gumba, gumba za prijenos, padajućih padajućih i navigacijskih veza.

Zatim ćemo provjeriti korisničko sučelje, izgled i dojam te pozitivno i negativno testiranje ulaznih podataka.

Tada ćemo započeti s integracijskim testiranjem. Ovdje ćemo provjeriti integraciju podataka. Provjerit ćemo odražavaju li se isti podaci na različitim odgovarajućim stranicama ili ne, provjerit ćemo navigaciju putem e-pošte na odgovarajuće stranice. Provjerit ćemo integraciju podataka s aplikacijama trećih strana i provjeriti promjene baze podataka u aplikaciji.

Dalje ćemo napraviti testiranje sustava. Provjerit ćemo cijelu aplikaciju kao jedinstvenu cjelinu. Provjerit ćemo funkcionalnost, integraciju stranica, provjere valjanosti polja, poruke pogreške, poruke potvrde i još mnogo toga.

Tijekom testiranja aplikacije evidentirat ćemo probleme u alatu za praćenje grešaka. Dati ćemo prednost programskoj pogrešci na temelju problema. Nakon stvaranja programske pogreške dodijelit ćemo je odgovarajućem programeru da riješi problem. Provjerit ćemo bugove nakon što ih programeri dodijele testerima nakon što ih isprave. Ako radi dobro, tester će zatvoriti pogrešku, u protivnom će testeri dodijeliti natrag programeru da riješi problem. Tako se odvija životni ciklus greške.

Zatim prelazimo na ispitivanje prihvatljivosti. Ovdje testiramo aplikaciju u različitim okruženjima, poput inscenacije i UAT (User Acceptance Testing). Ovo je najvažnija faza za temeljito testiranje aplikacije prije nego što kôd premjestimo u proizvodno okruženje.

Nakon što se izvrši testiranje prihvaćanja bez grešaka, tada će klijent planirati rasporediti kod na proizvodni poslužitelj i planirati izdanje.

# 6) Održavanje

Nakon što rasporedimo aplikacijski kod na proizvodni poslužitelj, trebali bismo pružiti podršku / održavanje klijentskoj aplikaciji. Ova faza održavanja treba promatrati i popraviti probleme s proizvodnjom u stvarnom vremenu, provjeriti probleme s memorijom, poboljšati aplikaciju i razviti nove promjene zahtjeva.

U kojim se slučajevima možemo odlučiti za model vodopada?

• Kad nema potrebnih promjena.
• Kad je projekt mali i jednostavan.
• Kad u tehnologiji nema složenosti.
• Kad je dostupno više resursa.

Proslavi za vodopad:

• Naprijed i natrag planiranje i provedba je jednostavna .
• Model vodopada jednostavan je za upotrebu i jednostavan za razumijevanje. Ne zahtijeva nikakvu posebnu obuku za voditelje projekata ili zaposlenike. Ima lagana krivulja učenja .
• Budući da je krute naravi, to je lako upravljati ciklus vodopada. Svaka faza ima fiksne isporuke i postupak pregleda.
• Manje složenosti jer se faze ne preklapaju. Faze se slijede jedna za drugom. Koristi jasnu strukturu u usporedbi s drugim metodologijama razvoja softvera. Projekt prolazi kroz fiksne sekvencijalne korake počevši od prikupljanja zahtjeva i konačno slijeće na održavanje.
• Zbog faznog razvoja, provodi se disciplina , a vremenski se rokovi mogu lako zadržati.
• Djela dobro za male projekte gdje imamo fiksne i kristalno jasne zahtjeve.
• Procesi i rezultati su dobro dokumentirano .
• Raspoređivanje zadataka je jednostavno.
• to je lako izmjeriti napredak jer su početne i krajnje točke svake faze unaprijed određene.
• Gotovo da se ne mijenjaju zahtjevi tijekom cijelog projekta, stoga zadaci ostaju stabilni za programere. Također, lako je za bilo koga novi programer za brzo učenje i započeti posao.
• Tamo su bez financijskih iznenađenja . Jednom kada su zahtjevi fiksni, konačni trošak može se izračunati prije početka razvoja.
• Nabavlja usluge za a sekvencijalni model financiranja .
• Njegova izvedbeni projekt čini konačni očekivani ishod svima vrlo jasnim.
• Specifikacija funkcionalnih zahtjeva dokumentirana u fazi prikupljanja zahtjeva daje ispitivačima dovoljno detalja za osmišljavanje scenarija ispitivanja i test slučajeva. Dakle, postupak testiranja postaje jednostavan u modelu vodopada.

Slapovi protiv:

• Kako svi zahtjevi moraju biti jasno poznati prije početka razvoja, to odgađa projekt .
• Zahtijeva opsežna istraživanja u potrebe korisnika.
• U početnoj fazi projekta izazov je za kupca da jasno definira i konceptualizira svoje zahtjeve u obliku funkcionalnih specifikacija. Stoga postoji velika mogućnost da se predomisle nakon što vide krajnji proizvod. Ta se promjena može dogoditi i zbog poslovnog plana ili utjecaja na tržište. Niska fleksibilnost u ovom modelu to čini teško prihvatiti bilo kakve takve promjene , pogotovo kada je proizvod potrebno u velikoj mjeri redizajnirati.
• Nema radnog modela proizvodi se do kasnije faza tijekom životnog ciklusa vodopada.
• Spora vremena isporuke . Kupac ne može vidjeti proizvod dok nije u potpunosti dovršen.
• Kupac nema priliku unaprijed se upoznati sa sustavom. Model slapa je više oblik unutarnji proces i isključuje krajnjeg korisnika .
• The klijent nije obaviješten dobro o zdravlju projekta.
• Rokovi se mogu propustiti ako se ne poštuje strogo upravljanje i redovito praćenje.
• Tamo je nema mjesta za promjene čak i ako je vidljiv tijekom razvoja jer proizvod neće udovoljiti zahtjevima tržišta.
• Odgađanje ispitivanja do nakon završetka. Također, velike revizije su u ovom trenutku vrlo skupe.
• Veliki rizik i neizvjesnost uključeni su u model vodopada, jer ima previše prostora da pitanja ostanu neprimijećena dok se projekt ne približi kraju.
• Nije prikladan model za duge, složene i tekuće projekte.
• Teško je izmjeriti napredak unutar svake faze.
• Ispitivači će sjediti besposleni tijekom mnogih faza projekta.

Agilan tijek rada

Sada ćemo vidjeti životni ciklus razvoja agilnog softvera. Agile je postupak brzog i jednostavnog obavljanja posla s više preciznosti.

Ovaj model povezan je s metodom upravljanja projektima, koja se posebno koristi za razvoj softvera. Karakterizira ga podjela zadataka na kratke faze rada i česta ponovna procjena i prilagodba planova. Svaki član tima trebao bi imati ideju o osnovnim poslovnim tokovima.

(slika izvor )

U Agileu programeri i testeri paralelno rade na razvoju i testiranju aplikacijskog softvera. Razvoj se vrši u iterativnom načinu. Svaka korisnička priča o iteraciji zahtijeva analizu, dizajn, kodiranje i testiranje.

Detaljno testiramo zahtjev kako bismo provjerili je li zahtjev bez pogrešaka i može li se implementirati. Prebacite se na sljedeću iteraciju nakon završetka svake iteracije i slijedimo isti postupak prema novim / drugim zahtjevima.

Stoga se ovaj proces razvoja i testiranja softverskog bloka izvodi u kratkom vremenskom razdoblju s više točnosti i fleksibilnosti. Dakle, više industrija prati i usvaja ovaj proces.

Prvo će vlasnik proizvoda dodati sve zahtjeve u zaostatak proizvoda. Zaostatak proizvoda sadrži sve korisničke priče. Recimo, 100 do 150 korisničkih priča povezane su s cjelovitim projektom. Sada dodajte posebne korisničke priče u zaostatak u sprintu koji trebamo implementirati. Tada će svi programeri, QA, BA raditi na sprint stavkama. Tako djeluje Agile flow.

Ključne terminologije korištene u agilnosti

Koji je zaostatak u sprintu?

najbolje knjige za učenje cyber sigurnosti

To je popis korisničkih priča koje moramo primijeniti u trenutnoj iteraciji ili sprintu.

Na primjer, u zaostatku sprinta ima 20 do 30 korisničkih priča. Tada su ovo korisničke priče koje moramo implementirati u trenutni sprint.

(slika izvor )

Što je Sprint?

Sprint je malo trajanje u kojem trebamo implementirati odabrane korisničke priče u određenom trajanju. Trajanje sprinta bit će oko 2 do 3 tjedna. Njegovo trajanje varira od tvrtke do tvrtke.

U ovom trajanju sprinta, tim mora analizirati zahtjev, dizajnirati zahtjeve, izvršiti kodiranje, testiranje, rješavanje problema, ponovno testiranje, regresijsko testiranje, demo i još mnogo aktivnosti.

Dnevni sastanak Standup Scrum

Poslovni analitičar, programer, ispitivač, voditelj projekta dio su svakodnevnih stand up scrum sastanaka. Radi se svakodnevno. Ne bi trebalo produljiti više od 15 do 30 minuta.

Ovdje će svi članovi tima dijeliti svakodnevni radni status. Glavne stvari o kojima ovdje raspravljamo su: koje su stvari dovršene jučer, plan za današnji rad i svi izazovi ili ovisnosti s kojima se suočavaju u projektu.

Ako se bilo koji član tima suoči s bilo kakvim izazovima ili preprekama tijekom projekta, dotična će osoba raditi na tome kako bi to učinila.

Grafikon Burndown

To je slikoviti grafički prikaz vremena i rada. Os x predstavlja preostali rad, a os y predstavlja preostalo vrijeme sprinta. Tim mora stvoriti radne zadatke koji se odnose na vrijeme dostupno u određenom sprintu. Tim će svakodnevno spaljivati ​​sate zadataka na temelju posla koji su odradili i obavili.

(slika izvor )

Karton Kanbana

To je shema / alat za upravljanje projektima. Ovim možemo upravljati zadacima cijelog projekta. Možemo provjeriti status napretka projekta i status rada pojedinaca. Prikazuje slikoviti digitalni prikaz naprednih stavki, stavki na čekanju i gotovih predmeta.

(slika izvor )

ba pitanja i odgovori za intervju pdf

Planiranje poker aktivnosti

To je igra između članova sprint tima kako bi procijenili korisničke priče. Ovdje će cijeli tim igrati poker aktivnost. Svaki član tima daje procjenu na temelju korisničke priče. Na temelju većine glasova za procjenu, tim će odlučiti i rasporediti vrijeme.

Na primjer , jedan član tima iz korisničke priče dat će procjenu poput 3, 5, 8, 3, 1, 3. Tada će tim odabrati 3 za procjenu. Kartica za poker aktivnosti sadrži 0, 1, 3, 5, 8, 13, 20, 100, break, sumnje? kartice. Na temelju ovog člana članovi će predložiti bilo koju karticu za procjenu. Tako ćemo procijeniti sve korisničke priče koje su povezane s određenim sprintom.

(slika izvor )

• 0 poker broj predstavlja: nema zadatka u toj stavci / korisničkoj priči
• 1, 3 broja predstavljaju: zadatak je manji
• 5, 8 brojeva predstavljaju: zadaci srednje razine
• Broj 13, 20 predstavlja: zadaci velike razine
• 100 broj predstavlja: vrlo veliki zadaci
• Beskonačnost predstavlja: Zadatak je ogroman, treba ga podijeliti na više zadataka i korisničkih priča
• Pauza predstavlja: trebam stanku
• ? Predstavlja: Sumnje

Scrum Master

On je osoba koja pomaže timu da slijedi agilni proces i ispuni zahtjeve projekta. Sastanak će voditi kad god je to potrebno i pomoći u raspravi o potrebama projekta.

Scrum master djeluje kao most za sve članove tima da riješe izazove i ovisnosti koje naiđu na projekt. Pratit će napredak projekta koji se odnosi na svaki sprint.

Uključen je u standup sastanak, retrospektivni sastanak, inspekciju, pregled, demonstraciju. On je taj koji provodi svakodnevne stand up sastanke i ažurira članove tima.

Vlasnik proizvoda

On je osoba koja upravlja i prati proizvod / projekt s poslovnog stajališta. Nastavlja gledati kako je proizvod razvijen prema poslovnom zahtjevu ili ne. On je taj koji daje prioritet korisničkim pričama i premješta zahtjeve iz zaostatka proizvoda u zaostatak u sprintu. Procijenit će rokove projekta.

Proizvod uvijek gleda s gledišta korisnika. Vlasnik proizvoda ima potpuno znanje o tome kako aplikacija treba raditi.

Korisnička priča

To je blok zahtjeva. Sadrži skup slučajeva / zahtjeva korištenja koji su povezani s istim modulom. Ovdje definiramo kako bi svaka komponenta aplikacije trebala raditi i kako bi trebalo izgledati korisničko sučelje. Opseg svake komponente definiran je u korisničkoj priči.

Zadaci

Članovi tima stvorit će zadatak za korisničku priču koji im je dodijeljen. Zadatak trebaju stvoriti na temelju različitih zadataka poput razvojnog zadatka, zadatka testiranja, zadatka analize korisničke priče. Trajanje zadatka treba ovisiti o bodovima korisničke priče.

Kao tester stvorit ćemo zadatke za analizu korisničkih priča, pripremu testnih slučajeva, izvršenje, regresijsko testiranje i mnoge druge.

Dotjerivanje zaostalih predmeta

Ovaj dio uključuje upravljanje zaostalim stavkama. Ovdje radimo davanje prioriteta zaostalim stavkama, razbijanje na manje predmete, stvaranje zadatka i ažuriranje kriterija prihvaćanja.

Iteracija

Iteracija je razvoj i testiranje nekih modula / dijelova softverske aplikacije. Svaka se iteracija sastoji od analize proizvoda, dizajniranja proizvoda, razvoja proizvoda, testiranja proizvoda i demonstracije proizvoda.

Ključni čimbenici za usvajanje agilne metodologije

• Promatranje: Redovito pregledavajte rad i proizvod i u skladu s tim planirajte aktivnosti. Dakle, postupak razvoja proizvoda i kvaliteta proizvoda bit će dobri.
• Promjene dobrodošlice: Promjene se rješavaju vrlo jednostavno. To ne utječe puno na proizvod jer se moduli softvera razvijaju odvojeno i integriraju kasnije. Dakle, neće biti prerade ako se zahtjev promijeni u budućnosti.
• Vremenski okvir: Dobivamo vremenski okvir za svaku jedinicu aplikacije. Tako će procjena biti točna prema procjenama vremena projekta.
• Zadovoljstvo kupaca: Zadovoljstvo kupaca je više jer u interakciji s klijentom i dioničarom tijekom cijelog projekta dat ćemo demo na svakoj razini razvoja proizvoda. Ovim redovito dobivamo povratne informacije kupaca / klijenata o tijekovima poslovanja i napretku rada. Stoga se rad i razvoj aplikacije obavljaju u skladu s tim.

Vrste agilnih metodologija

• Agile Scrum metodologija
• Lean razvoj softvera
• Kanban
• Ekstremno programiranje (XP)
• Kristal
• Metoda razvoja dinamičkih sustava (DSDM)
• Razvoj vođen značajkama (FDD)

Agilni profesionalci:

• Jedna od najvećih prednosti agilnog modela je njegova velika prilagodljivost . Prilagodljivost znači 'odgovaranje na promjene'. Agile je vrlo fleksibilan u rješavanju promjena u potrebama i prioritetima kupaca.
• Omogućuje neprestano pročišćavati i ponovno postavljati prioritete za ukupni zaostatak proizvoda bez utjecaja na trenutnu iteraciju u kojoj je tim usredotočen na isporuku MVP-a. Promjene se mogu planirati za sljedeću iteraciju, pružajući tako priliku da se promjene uvedu samo u roku od nekoliko tjedana.
• Agile metodologija nudi velik stupanj angažman dionika . Klijent i projektni tim sastaju se prije, tijekom i nakon svakog sprinta. Kako je kupac stalno uključen u projekt, timu je više prilika da jasno razumije kupčevu viziju.
• Radni softver isporučuje se rano i često. To povećava povjerenje dionika u timu i potiče tim da ostanite jako predani projektu.
• Ovaj model daje prozirnost . I dionici i tim dobro znaju što se događa. Klijent može vidjeti rad u tijeku.
• To omogućavaju sprintovi fiksnog rasporeda od jednog do četiri tjedna rana i predvidljiva isporuka . Nove značajke objavljuju se brzo i često na vremenski ograničen način.
• Agile je usmjeren na kupca . Ne isporučuje samo funkcionalnost, već se fokusira i na pružanje značajke koja za korisnika ima neku vrijednost. Svaka korisnička priča ima poslovni kriterij prihvaćanja.
• Vrijedno Povratne informacije korisnika se stječe rano u projektu i promjene proizvoda mogu se izvršiti prema potrebi.
• Fokus je na poslovnoj vrijednosti . Prvo isporučuje ono što je najvažnije za klijenta.
• Poboljšava kvalitetu isporučenih proizvoda . Za razliku od vodopada, testiranje se kontinuirano i često provodi u agilnom projektu, a to, pak, pomaže u ranom otkrivanju i rješavanju problema.
• Okretan podržava TDD (Test Driven Development) pristup što pruža dovoljno vremena za stvaranje jedinstvenih testova za značajke koje će biti objavljene putem MVP-a.
• Također, proizvodnjom česte gradnje , bilo kakva neusklađenost sa zahtjevima kupca također se može otkriti i ispraviti rano.
• Kao što smo dobili neposredne povratne informacije korisnika nakon svakog MVP izdanja, rizik od neuspjeha projekta je nizak, kada radite na okretan način.
• Okretan promiče timski rad . Među članovima Agile tima postoji izvrsna suradnja, interakcija, sklad i entuzijazam.
• Procjene troškova i rasporeda svakog sprinta priopćavaju se klijentu prije početka sprinta. Ovaj poboljšava donošenje odluka jer korisnik može razumjeti cijenu svake značajke i u skladu s tim odrediti prioritete.
• U agilnom projektu ima mjesta za stalno poboljšanje . Lekcije naučene iz prošlih sprinteva mogu se primijeniti u nadolazećim sprintima.
• Fokusira se na određeni zadatak u svakoj fazi projekta.

Agile Cons:

• Često se vidi da Agile timovi imaju a tendencija zanemarivanja dokumentacije . To je zato što se Agile manifest više fokusira na radni softver nego na sveobuhvatnu dokumentaciju. Međutim, timovi bi trebali održavati pravu ravnotežu između koda i dokumentacije.
• Budući da zahtijeva visok stupanj uključenosti kupaca, to može ponekad mogu biti problematični za kupce koji nemaju puno vremena i interesa za sudjelovanje u projektu.
• Ne funkcionira dobro ako momčadi nedostaje predanosti i predanosti. Vodopad zahtijeva sudjelovanje, međutim, Agile zahtijeva predanost.
• Ako su početna arhitektura i dizajn slabi, onda česta refaktorizacija je potrebno.
• U usporedbi sa slapom, Agile je teško vježbati . Članovi tima moraju biti dobro upućeni u agilne koncepte. Za vježbanje agilnosti potrebno je puno discipline i predanosti.
• Zbog ponovnog određivanja prioriteta, jest manje predvidljiv nego što će biti isporučeno na kraju sprinta.
• Zbog isporuke s vremenskim okvirom i čestog ponovnog određivanja prioriteta, postoji mogućnost da neke značajke ne budu isporučene u dodijeljenom vremenskom slijedu. To može dovesti do dodatni sprint i dodatni troškovi . To također može dovesti do problema nebulozne vremenske crte .
• Nedostatak strukture u usporedbi s vodopadom zahtijeva samodisciplinirane, visoko stručne i višestruko kvalificirane timove . Bez toga projekt zaista može biti izazovan.
• Dostupnost je manje nacrt konačnog rezultata .
• Ponekad vanjski dionik ne može odoljeti slijeđenju agilnog pristupa . U takvim slučajevima obuka i obrazovanje o agilnom potrebni su širokoj publici.
• Svi članovi tima moraju biti uključeni u upravljanje projektom.
• Dokumentacija je manje detaljna.

Razlika između agilnih Vs modela vodopada

Razlike između životnih ciklusa vodopada i agilnog razvoja softvera navedene su u nastavku.

Slap	Okretan
Proces se tretira kao jedan jedini projekt koji se dalje dijeli u različite faze.	Proces je podijeljen u više projekata, a svaki projekt ima iteraciju različitih faza.
Metodologija vodopada model je u kojem se svaka faza životnog ciklusa proizvoda odvija u nizu. Napredak projekta postupno teče prema dolje kroz ove faze nalik na vodopad.	Agilna metodologija model je koji slijedi iterativni pristup.
Ovaj model vjeruje u jednokratnu masovnu cijelu isporuku. Proizvod se isporučuje na kraju SDLC-a.	Ovaj model vjeruje u više malih dijelova isporuke u definiranim vremenskim intervalima. MVP (minimalno održivi proizvod) isporučuje se na kraju svakog sprinta.
To je tradicionalan i staromodan pristup.	To je nov i moderan pristup.
Jedan jedini ciklus i jedno izdanje.	Ponavljajući broj ponavljanja i više izdanja.
Životni ciklus razvoja softvera dijeli u različite faze.	Životni ciklus razvoja softvera dijeli na sprinteve.
Strukturirani i kruti model. Teško je izmijeniti opis, specifikaciju i dizajn projekta.	Ovaj je model poznat po svojoj fleksibilnosti. U bilo kojem trenutku možemo napraviti promjene u bilo kojoj fazi projekta.
Ljestvica dugoročnog planiranja.	Ljestvica kratkoročnog planiranja.
Između kupca i programera postoji velika udaljenost.	Postoji mala udaljenost između kupca i programera.
Dugo vremena između specifikacije i implementacije. Poslovni analitičar prikuplja i priprema zahtjev prije početka projekta.	Kratko vrijeme između specifikacije i implementacije. Vlasnik proizvoda priprema zahtjeve i ažurira tim za svaki sprint.
Otkrivanje problema traje dugo.	Problemi se brzo otkrivaju.
Visok rizik rasporeda projekata.	Nizak rizik rasporeda projekata.
Manje sposobnost brzog reagiranja na promjene.	Visoka sposobnost brzog reagiranja na promjene.
Faza ispitivanja nastupa tek nakon završetka razvojne faze.	Ispitivanje se obično provodi paralelno s razvojem kako bi se kontinuirano osiguravala kvaliteta.
Kupac je uključen samo u fazi prikupljanja zahtjeva, a nakon toga nije uključen. Na sliku dolazi tek u trenutku isporuke proizvoda.	Kupac je uključen u cijeli projekt, a povremeno se uzima povratna informacija kako bi se osiguralo zadovoljstvo kupca.
Pogodno za projekte koji imaju jasno definirane zahtjeve i one koji ne očekuju promjene.	Pogodno za projekte koji se moraju razvijati i one koji uključuju promjene zahtjeva.
Strogo sekvencijalni postupak.	Visoko suradnički proces razvoja softvera dovodi do boljih timskih napora i brzog rješavanja problema.
Izlaže način razmišljanja o projektu.	Predstavlja način razmišljanja o proizvodu i time je usmjereniji na kupca. Zahtjevi i promjene dio su procesa
Formalno i hijerarhijski. Voditelj projekta je osoba koja donosi odluke.	Neformalno je. Čitav tim odgovoran je za donošenje odluka.
Ovaj model predviđa da neće biti promjena u zahtjevima tijekom cijelog projekta.	Ovaj se model temelji na prilagodbi i obuhvaća promjene.
Treba stvoriti ručne dokumente za provjeru statusa rada pojedinca i napretka projekta.	Slijedi Kanbanov grafikon i Burn Down grafikon kako bi potvrdio napredak projekta i radni status pojedinca.

Imali smo dovoljno rasprava o razlikama između metodologija Agile & Waterfall i prednostima i izazovima svake od njih. Istražimo sada razlike između agilnog testiranja i testiranja vodopada.

Razlike između agilnog testiranja i testiranja vodopada

Iz perspektive testiranja softvera, važno nam je imati dobru ideju o tome kako se agilno testiranje razlikuje od testiranja vodopada.

Zaključak

U ovom smo članku saznali točne razlike između suvremenog agilnog pristupa i tradicionalne Waterfall metode razvoja i testiranja softvera s usporednom tablicom koja pokriva prednosti i nedostatke svakog modela.

Razmatrajući sve čimbenike navedene u ovom članku, možemo odabrati ispravan model životnog ciklusa razvoja softvera za razvoj softverske aplikacije. Nesumnjivo je reći da se agilnim metodologijama daje prednost u odnosu na model vodopada. 90% tvrtki preferira i slijedi Agile tijek rada za razvoj softverske aplikacije.

Agilna metodologija dobra je za sve vrste projekata. Vrlo malo tvrtki slijedi metodologiju vodopada. Ova je metodologija prikladna samo ako je aplikacija mala, jednostavna i ako nema promjena u zahtjevu.

U nekim se slučajevima odlučujemo i za druge pristupe nazvane Spirala, V i V i Prototip, na temelju potreba.

Nadam se da će vam ove informacije biti korisne pri odluci koji je najbolji model za vaš projekt. Također možete ići na hibridni model uklanjajući nedostatke svake metode - ovdje se raspravlja.

Preporučena literatura

• Studija slučaja: Kako ukloniti nedostatke vodopada i agilnih razvojnih procesa pomoću hibridnog modela
• Što je SDLC model vodopada?
• Pregled alata za upravljanje testovima Zephyr Enterprise - Kako koristiti sredstva modela slapa u Agile Tool-u
• Vodič za VersionOne: Vodič za sve agilan agilan alat za upravljanje projektima
• Vodič za portfelj Jira: Agile dodatak za upravljanje portfeljem projekata za JIRA (pregled)
• TOP 10 najboljih agilnih alata za upravljanje projektima 2021
• Agile tehnike procjene: istinska procjena u agilnom projektu
• 4 koraka prema razvoju agilnog načina testiranja za uspješan prijelaz na agilni proces