Slap Agile Vs: Katera je najboljša metodologija za vaš projekt?

agile vs waterfall which is best methodology

implementacija binarnega drevesa v izvorni kodi c ++

Naučite se vse o agilnih in slapovskih metodologijah, različnih vrstah SDLC modelov in razlikah med slapovskimi in gibčnimi razvojnimi modeli ter preskušanjem:

V tem informativnem članku se lahko odločite, kateri najprimernejši model za vaš projekt temelji na prednostih in slabostih vsakega.

Model slapa in agilni model sta vrsti življenjskega cikla razvoja programske opreme (SDLC). To so postopki, ki jih industrija programske opreme uporablja za načrtovanje, razvoj in preizkušanje programske opreme.

Z upoštevanjem SDLC lahko dosežemo pričakovanja kupcev, izvedemo projekt v določenih časovnih okvirih in ocenimo stroške.

Kaj se boste naučili:

• Potoki slapov in gibčnih modelov
  • Kaj je življenjski cikel razvoja programske opreme?
  • Vrste življenjskega cikla razvoja programske opreme
    • # 1) Model slapa
    • # 2) gibčen model
    • # 3) Spiralni model
    • # 4) Model prototipa
    • # 5) V in V model
• Model slapa
• Agilen potek dela
  • Ključne terminologije, ki se uporabljajo v agilnosti
  • Ključni dejavniki za sprejetje agilne metodologije
  • Vrste agilnih metodologij
• Razlika med modeli Agile Vs Waterfall
• Razlike med agilnim testiranjem in testiranjem slapa
• Zaključek
  • Priporočeno branje

Potoki slapov in gibčnih modelov

V preprosti angleščini Agile pomeni 'zmožen hitro in enostavno premikanje' in zato to pomeni, ko gre za Agilna razvojna metodologija .

Agile je metoda vodenja projektov, ki jo predstavlja razdelitev nalog na krajše segmente dela s pogostimi pregledi in prilagajanjem načrtov.

Podobno beseda slap označuje navpični tok vode ali tok vode skozi vrsto strmih kapljic. Model slapa je linearni zaporedni model, pri katerem napredek pretežno teče v eno smer navzdol skozi faze zbiranja potreb, analize, načrtovanja, razvoja, testiranja, uvajanja in vzdrževanja.

Ista ilustracija velja za koncept vodenja projektov, ko gre za model slapa . Gre za metodo vodenja projektov, ki jo predstavljajo serijske faze in določen načrt dela.

(slika vir )

Preden razpravljamo o delovnem toku Slap in Agile, si oglejmo definicijo življenjskega cikla razvoja programske opreme in njene zahteve.

Kaj je življenjski cikel razvoja programske opreme?

Postopni postopek je sistematičen razvoj programske opreme. Za to izbiramo med različnimi vrstami življenjskih ciklov razvoja programske opreme v različnih podjetjih. Na podlagi zahteve je izbran ustrezen življenjski cikel.

Model slapa je ena od vrst SDLC in je star postopek razvoja programske opreme. Agilen model je najnovejši in napreden. Agile izhaja iz življenjskega cikla razvoja druge programske opreme.

Drugi SDLC vključujejo spiralni model, model V in V, model prototipa. Glede na nujnost in združljivost poslovnih zahtev bomo izbrali najboljši model za razvoj programske aplikacije.

(slika vir )

Zakaj je potreben življenjski cikel razvoja programske opreme?

SDLC mora strukturirano voditi projekt. Zagotavlja določeno raven nadzora in opredeljuje vloge in odgovornosti članov ekipe. Zagotavlja obseg in rok za vsako fazo v SDLC.

Nekoliko je kot uporabniški priročnik za člane ekipe, da sledijo vsem korakom za razvoj in dostavo kakovostnega izdelka. Vodstvu ekipe pomaga opredeliti in ovrednotiti cilje in zahteve. Pomaga tudi pri razporejanju in ocenjevanju nalog. Vzpostavlja komunikacijsko linijo med stranko in razvojno skupino ter ustvarja vloge in odgovornosti vsakega od njih.

Vrste življenjskega cikla razvoja programske opreme

Oglejmo si kratek uvod v vrste SDLC, ki se uporabljajo v procesu razvoja programske opreme.

# 1) Model slapa

Kot smo že omenili, je model slapa prvi uvedeni življenjski cikel razvoja programske opreme. Je zaporedni način razvoja programske opreme. Le malo podjetij se drži tega pristopa. Ko bo projekt zelo preprost in ne bo nadaljnjih sprememb zahtev, bomo sledili temu pristopu.

Več o modelu slapa bomo obravnavali v tej vadnici.

# 2) gibčen model

Agilen potek dela je napreden pristop k procesu razvoja programske opreme, ki se uporablja v večini podjetij. Agile je opredeljen kot življenjski cikel razvoja programske opreme, ki temelji na sprintu.

V naslednjih razdelkih lahko več razpravljamo o delovnem toku Agile.

# 3) Spiralni model

To je način gradnje in preizkušanja programske opreme z razdelitvijo in dodajanjem zahtev po korakih. Ta model bo pomagal pri projektih, kjer se zahteve nenehno spreminjajo. Ta spiralni model je kombinacija iterativnega razvojnega procesa in zaporednega linearnega razvojnega procesa.

Ta pristop nam bo omogočil postopne izdaje izdelka. Tu ni treba čakati na dokončanje vseh modulov programske opreme za izdajo.

Linearni sekvenčni model pomeni, da gre za sistematičen sekvenčni pristop k razvoju programske opreme, ki se začne na sistemski ravni in napreduje z analizo, načrtovanjem, kodiranjem, testiranjem in podporo.

Ponavljajoči se model pomeni, da gre za določeno izvajanje življenjskega cikla razvoja programske opreme, ki se osredotoča na začetno, poenostavljeno izvedbo, ki nato postopoma pridobiva na večji zapletenosti in postavi širšo funkcijo, dokler končni sistem ni dokončan.

# 4) Model prototipa

Ta model vključuje postopek izdelave in preizkušanja programske opreme na tak način, da najprej razvijemo model lutke in če je izvedljiv ter doseže vse poslovne zahteve, nato implementiramo dejanski delovni model.

Tu smo najprej izdelali in preizkusili prototip, nato pa dejanski model z natančnimi sistemskimi specifikacijami. Izdelava prototipov programske opreme je dejavnost ustvarjanja prototipov programskih aplikacij.

# 5) V in V model

Je model preverjanja in potrjevanja. Tu smo med razvojem programske opreme preverjali in potrjevali vse v vsaki fazi SDLC. Model V velja za podaljšek modela slapa.

Torej imajo vse vrste SDLC svoje značilnosti in značilnosti. Glede na zahteve projekta, potrebe, izvedljivost, trajanje lahko izberemo določen življenjski cikel razvoja programske opreme za razvoj programske aplikacije.

Zdaj bomo podrobno razpravljali o življenjskih ciklih razvoja programske opreme Waterfall in Agile.

Model slapa

V modelu Slap je treba vsako fazo zaključiti pred začetkom druge faze. Ne moremo delovati več faz hkrati. To je leta 1970 predstavil Winston Royce. Model Slap je razdeljen na različne faze.

(slika vir )

Model slapa vključuje naslednje faze:

1. Zbiranje zahtev
2. Študija izvedljivosti
3. Oblikovanje
4. Kodiranje
5. Testiranje
6. Vzdrževanje

# 1) Analiza zahtev

Tu bo poslovni analitik dobil specifikacijo zahteve. Zahteva bo v obliki CRS (specifikacija zahteve kupca). CRS pojasnjuje, kako naj poteka poslovni tok in kako mora aplikacija delovati v skladu z določeno zahtevo. Poslovni analitiki bodo CRS pretvorili v SRS (specifikacija programske zahteve).

Nato poslovni analitik podrobno razpravlja o specifikacijah zahtev z ekipo za razvoj in testiranje in jo razume z vidika razvoja in testiranja. To je faza razprave in analize zahtev za izdelavo programske opreme, ki temelji na dejanskih zahtevah.

Tu bi moralo biti vse dokumentirano v dokumentu s specifikacijami za programsko opremo. V modelu slapa je rezultat / rezultat / izhod vsake faze vhodni vir za naslednje faze.

V storitveni industriji lahko poslovni analitik to zahteva.
V podjetju, ki temelji na izdelku, Product Analyst prinaša zahtevo.

# 2) Študija izvedljivosti

Vodstvena skupina bo izvedla študijo izvedljivosti. To pomeni, da bo skupina analizirala parametre, na primer, ali je to zahtevo / aplikacijo mogoče razviti v našem okolju ali ne, ali je razpoložljiv vir dovolj ali ne, stroški in številni drugi dejavniki so izvedljivi ali ne in preverimo, ali lahko pokrijemo vsi poslovni tokovi ali ne.

Na tem sestanku / analizi bo del razprave vodja projekta, poslovni analitik, finančni vodja, kadrovska služba, vodja projekta.

# 3) Oblikovanje sistema

Tu bo Project Architect pripravil zasnovo sistema. Določil bo strojno opremo, sistemske zahteve in oblikoval arhitekturo aplikacije. V zasnovi sistema sta dva dela: zasnova na visoki ravni in zasnova na nizki ravni. Pri oblikovanju na visoki ravni oblikujemo različne bloke aplikacije. Pri nizkem nivoju pišemo psevdo-kodo.

# 4) Kodiranje

Tu razvijalci začnejo natančno kodirati vsako funkcijo in uporabniški vmesnik aplikacije z različnimi metodami in različnimi logikami. Za izdelavo aplikacije lahko uporabijo kateri koli programski jezik, kot so Java, Python ali kateri koli drug jezik.

Ko je kodiranje končano za vsako funkcionalnost določenega modula aplikacije, bo razvijalec opravil enotno testiranje. Če koda deluje v redu, bo razvijalec uvedel kodo v preskusno okolje in gradnjo dal preizkuševalcu.

# 5) Testiranje

Od tu se začne testiranje. Do te faze v modelu Slap ne bomo imeli nobene naloge. V tej fazi izvajamo vse vrste testiranja. Te vrste testiranja vključujejo testiranje dima, funkcionalno testiranje, integracijsko testiranje, sistemsko testiranje, sprejemno testiranje, regresijsko testiranje, ad hoc testiranje, raziskovalno testiranje in testiranje med brskalniki.

Ko začnemo graditi, bomo začeli preizkušati aplikacijo. Najprej bomo začeli s testiranjem dima. Če ne opazimo težav z blokatorjem, bomo nadaljevali s podrobnim testiranjem.

Pri funkcionalnem testiranju bomo začeli preizkušati vsako komponento aplikacije. Tu preverimo različne komponente, kot so besedilna polja, gumbi, povezave, izbirni gumbi, gumbi za nalaganje, spustni meni in navigacijske povezave.

Nato bomo preverili uporabniški vmesnik, videz in občutek ter pozitivno in negativno testiranje vhodnih podatkov.

Nato bomo začeli z integracijskim testiranjem. Tu bomo preverili integracijo podatkov. Preverili bomo, ali se isti podatki odražajo na različnih straneh ali ne, preverili bomo krmarjenje po e-poštni povezavi do posameznih strani. Preverili bomo integracijo podatkov s programi tretjih oseb in spremembe v zbirki podatkov v aplikaciji.

Nato bomo opravili sistemsko testiranje. Celotno aplikacijo bomo preverili kot eno samo enoto. Preverili bomo funkcionalnost, integracijo strani, preverjanje polj, sporočila o napakah, potrditvena sporočila in še veliko več.

Med testiranjem aplikacije bomo težave zabeležili v orodju za sledenje napakam. Napako bomo dali prednost glede na težave. Po izdelavi napake jo dodelimo ustreznemu razvijalcu, da odpravi težavo. Napake bomo preverili, ko jih bodo razvijalci dodelili preizkuševalcem, potem ko so jih odpravili. Če tester deluje dobro, bo napako zaprl, sicer pa bodo preizkuševalci vrnili razvijalca, da odpravi težavo. Tako se nadaljuje življenjski cikel hroščev.

Nato preidemo na sprejemni preizkus. Tu preizkušamo aplikacijo v različnih okoljih, kot sta uprizoritev in UAT (User Acceptance Testing). To je najpomembnejša faza za temeljito preizkušanje aplikacije, preden kodo premaknemo v produkcijsko okolje.

Ko bo testiranje sprejemljivosti izvedeno brez napak, bo odjemalec načrtoval namestitev kode na strežnik za produkcijo in načrt za izdajo.

# 6) Vzdrževanje

Ko aplikacijsko kodo razmestimo na produkcijski strežnik, moramo odjemalski aplikaciji zagotoviti podporo / vzdrževanje. V tej fazi vzdrževanja je treba opazovati in odpraviti težave s proizvodnjo v realnem času, preveriti težave s pomnilnikom, izboljšati aplikacijo in razviti nove spremembe zahtev.

V katerih primerih se lahko odločimo za model slapa?

• Ko ni potrebnih sprememb.
• Ko je projekt majhen in preprost.
• Ko v tehnologiji ni zapletenosti.
• Ko je na voljo več virov.

Slapovi Pros:

• Naprej in nazaj načrtovanje in izvajanje je enostavno .
• Model slapa je preprost za uporabo in enostaven za razumevanje. Ne zahteva posebnega usposabljanja za vodje projektov ali zaposlene. Ima enostavna krivulja učenja .
• Ker je toge narave, je enostaven za upravljanje cikel slapa. Vsaka faza ima določene rezultate in postopek pregleda.
• Manj zapletenosti saj se faze ne prekrivajo. Faze sledijo ena za drugo. V primerjavi z drugimi metodologijami za razvoj programske opreme uporablja jasno strukturo. Projekt gre skozi določene zaporedne korake, začenši od zbiranja zahtev in končno pristane pri vzdrževanju.
• Zaradi faznega razvoja, disciplina se izvaja , roke pa lahko enostavno obdržite.
• Deluje dobro za majhne projekte kjer imamo fiksne in kristalno jasne zahteve.
• Procesi in rezultati so dobro dokumentirano .
• Urejanje nalog je enostavno.
• je enostavno meriti napredek saj sta začetna in končna točka vsake faze vnaprej določena.
• V celotnem projektu se zahteve skoraj ne spreminjajo, zato naloge ostajajo stabilne za razvijalce. Prav tako je enostavno za vsakogar nov razvijalec za hitro učenje in začnite z delom.
• Obstajajo brez finančnih presenečenj . Ko so zahteve določene, je mogoče končni strošek izračunati pred začetkom razvoja.
• Služi za a model zaporednega financiranja .
• Svoje podrobna zasnova končni pričakovani izid vsem zelo jasno pokaže.
• Specifikacija funkcionalnih zahtev, dokumentirana v fazi zbiranja zahtev, daje preskuševalcem dovolj podrobnosti za načrtovanje preskusnih scenarijev in testnih primerov. Zato je postopek testiranja postane enostaven v modelu slapa.

Slapovi Proti:

• Ker morajo biti vse zahteve pred začetkom razvoja jasno znane, to zamuja s projektom .
• Zahteva obsežne raziskave potrebe uporabnikov.
• V začetni fazi projekta je za kupca izziv, da jasno opredeli in konceptualizira svoje zahteve v obliki funkcionalnih specifikacij. Zato obstaja velika možnost, da si po ogledu končnega izdelka premislijo. Do te spremembe lahko pride tudi zaradi poslovnega načrta ali vpliva trga. Nizka prilagodljivost tega modela omogoča težko sprejeti takšne spremembe , zlasti kadar je treba izdelek v veliki meri preoblikovati.
• Brez delujočega modela se proizvaja do kasneje stopnjo v življenjskem ciklu slapa.
• Počasni dobavni roki . Kupec si izdelka ne more ogledati, dokler ni popolnoma dokončan.
• Stranka nima možnosti, da se s sistemom vnaprej seznani. Model slapa je bolj kot notranji postopek in izključuje končnega uporabnika .
• The stranka ni obveščena tudi o zdravju projekta.
• Roke lahko zamudite če se ne upošteva strogo upravljanje in redno spremljanje.
• Tukaj je ni prostora za spremembe tudi če je viden med razvojem, saj izdelek ne bo ustrezal zahtevam trga.
• Zamude pri testiranju do konca. Tudi velike revizije so v tem trenutku zelo drage.
• Veliko tveganje in negotovost so vključeni v model slapa, saj je preveč vprašanj, da ostanejo neopažene, dokler se projekt ne zaključi.
• Ni primeren model za dolge, zapletene in tekoče projekte.
• Težko je meriti napredek v vsaki fazi.
• Preizkuševalci bodo v številnih fazah projekta sedeli brez dela.

Agilen potek dela

Zdaj bomo videli življenjski cikel razvoja agilne programske opreme. Agile je postopek hitrega in enostavnega opravljanja dela z večjo natančnostjo.

Ta model je povezan z metodo upravljanja projektov, ki se uporablja zlasti za razvoj programske opreme. Zanj je značilna delitev nalog na kratke faze dela ter pogosta ponovna presoja in prilagajanje načrtov. Vsak član ekipe bi moral imeti predstavo o osnovnih poslovnih tokovih.

(slika vir )

V programu Agile razvijalci in preizkuševalci vzporedno sodelujejo pri razvoju in testiranju aplikacijske programske opreme. Razvoj poteka v iterativnem načinu. Vsaka ponovitev uporabniških zgodb zahteva analizo, oblikovanje, kodiranje in testiranje.

Zahtevo natančno preizkusimo, da preverimo, ali je zahteva brez napak in izvedljiva ali ne. Po koncu vsake ponovitve preklopite na naslednjo ponovitev in po istem postopku sledimo novim / drugim zahtevam.

Tako se ta postopek razvoja in preizkušanja programske opreme izvede v kratkem času z večjo natančnostjo in prilagodljivostjo. Torej več industrij sledi in sprejme ta postopek.

Najprej bo lastnik izdelka dodal vse zahteve v zaostanek izdelka. Zaostanek izdelkov vsebuje vse uporabniške zgodbe. Recimo, 100 do 150 uporabniških zgodb je povezanih s celotnim projektom. Zdaj dodajte posebne uporabniške zgodbe v zaostanek v sprintu, ki ga moramo izvesti. Nato bodo vsi razvijalci, QA, BA delali na sprinterskih postavkah. Tako deluje Agile flow.

Ključne terminologije, ki se uporabljajo v agilnosti

Kakšen je zaostanek v sprintu?

najboljše storitve spletnega gostovanja v Indiji

To je seznam uporabniških zgodb, ki jih moramo uporabiti v trenutni ponovitvi ali sprintu.

Na primer, v zaostanku sprinta je od 20 do 30 uporabniških zgodb. Potem so to uporabniške zgodbe, ki jih moramo izvesti v trenutnem sprintu.

(slika vir )

Kaj je Sprint?

Sprint je majhno trajanje, v katerem moramo izbrane uporabniške zgodbe implementirati v določenem trajanju. Trajanje šprinta bo približno 2 do 3 tedne. Njegovo trajanje se razlikuje od podjetja do podjetja.

V tem trajanju sprinta mora ekipa analizirati zahtevo, oblikovati zahteve, izvesti kodiranje, testiranje, odpravljanje težave, ponovno testiranje, regresijsko testiranje, predstavitev in še veliko drugih dejavnosti.

Vsakodnevno srečanje Standup Scrum

Poslovni analitik, razvijalec, preizkuševalec, vodja projekta so del vsakodnevnih stand up scrum sestankov. To se naredi vsak dan. Ne sme trajati več kot 15 do 30 minut.

Tu bodo vsi člani ekipe delili vsakodnevno stanje dela. Glavne stvari, o katerih tukaj razpravljamo, so: kaj so včeraj končane stvari, načrt za današnje delo in morebitni izzivi ali odvisnosti, s katerimi se srečujejo v projektu.

Če se kateri koli član ekipe med projektom sooči s kakršnimi koli izzivi ali ovirami, ga zadevna oseba naredi, da ga opravi.

Grafikon Burndown

Je slikovni grafični prikaz časa in dela. Os x predstavlja preostalo delo, os y predstavlja preostali čas sprinta. Ekipa mora ustvariti delovne naloge glede časa, ki je na voljo v določenem sprintu. Ekipa bo vsakodnevno sežgala ure nalog glede na delo, ki ga je opravila in opravila.

(slika vir )

Kanban Chart

To je shema / orodje za upravljanje projektov. S tem lahko upravljamo naloge celotnega projekta. Lahko preverimo stanje napredka projekta in status dela posameznikov. Prikazuje slikovno digitalno predstavitev naprednih postavk, čakajočih predmetov in končnih predmetov.

(slika vir )

odprtokodna orodja za analitiko velikih podatkov

Načrtovanje poker dejavnosti

To je igra med člani ekipe sprinta, da ocenijo zgodbe uporabnikov. Tu bo celotna ekipa igrala poker. Vsak član ekipe poda oceno na podlagi uporabniške zgodbe. Na podlagi večine ocenjevalnih glasov se bo ekipa odločila in dodelila časovno obdobje.

Na primer , bo en član uporabniške zgodbe podal oceno, na primer 3, 5, 8, 3, 1, 3. Nato bo skupina za oceno izbrala 3. Kartica za poker vsebuje 0, 1, 3, 5, 8, 13, 20, 100, odmor, dvomi? kartice. Glede na to bodo člani ekipe predlagali kakršno koli oceno. Tako bomo ocenili vse uporabniške zgodbe, ki so povezane s posameznim sprintom.

(slika vir )

• 0 poker številka predstavlja: v tej postavki / uporabniški zgodbi ni nobene naloge
• 1, 3 številke predstavljajo: naloga je manjša
• 5, 8 številk predstavlja: naloge na srednji ravni
• Število 13, 20 predstavlja: velike naloge
• Številka 100 predstavlja: zelo velike naloge
• Neskončnost predstavlja: Nalog je ogromno, razdeliti jih je treba na več nalog in uporabniške zgodbe
• Odmor predstavlja: potrebujejo odmor
• ? Predstavlja: Dvomi

Scrum mojster

Je oseba, ki ekipi pomaga, da sledi agilnemu procesu in izpolnjuje zahteve projekta. Sestanek bo vodil, kadar koli bo to potrebno, in bo pomagal razpravljati o potrebi projekta.

Scrum mojster deluje kot most do vseh članov ekipe za reševanje izzivov in odvisnosti, ki naletijo na projekt. Spremljal bo napredek projekta glede vsakega sprinta.

Sodeluje v standup sestanku, retrospektivnem sestanku, pregledu, pregledu, predstavitvi. On je tisti, ki vodi dnevne stand-up sestanke in posodablja člane ekipe.

Lastnik izdelka

Je oseba, ki vozi / spremlja izdelek / projekt s poslovnega vidika. Nadaljuje z gledanjem, kot da je izdelek razvit v skladu s poslovnimi zahtevami ali ne. On je tisti, ki daje prednost zgodbam uporabnikov in je zahteve iz zaostankov izdelkov premaknil v zaostanke sprintov. Ocenil bo roke projekta.

Na izdelek vedno gleda z vidika uporabnika. Lastnik izdelka ima popolno znanje o tem, kako mora delovati aplikacija.

Zgodba uporabnika

To je blok zahtev. Vsebuje nabor primerov / zahtev uporabe, ki so povezani z istim modulom. Tu določimo, kako naj deluje vsaka komponenta aplikacije in kako mora izgledati uporabniški vmesnik. Obseg vsake komponente je opredeljen v zgodbi uporabnika.

Naloge

Člani ekipe bodo ustvarili nalogo za uporabniško zgodbo, ki jim je dodeljena. Nalogo morajo ustvariti na podlagi različnih nalog, kot so razvojna naloga, naloga testiranja, naloga analize uporabniške zgodbe. Trajanje naloge mora biti odvisno od uporabniških zgodb.

Kot preizkuševalec bomo ustvarili naloge za analizo zgodbe uporabnika, pripravo testnih primerov, izvedbo, regresijsko testiranje in še veliko več.

Negovanje zaostankov

Ta del vključuje upravljanje zaostankov. Dejavnosti, ki jih tukaj opravljamo, so dajanje prednosti zaostankom, razbijanje na manjše predmete, ustvarjanje naloge in posodabljanje meril za sprejem.

Ponavljanje

Ponavljanje je razvoj in preizkušanje nekaterih modulov / delov programske aplikacije. Vsaka ponovitev je sestavljena iz analize izdelka, oblikovanja izdelka, razvoja izdelka, testiranja izdelka in predstavitve izdelka.

Ključni dejavniki za sprejetje agilne metodologije

• Opazovanje: Redno pregledujte delo in izdelek ter v skladu s tem načrtujte dejavnosti. Torej bo postopek razvoja izdelka in kakovost izdelka dobra.
• Spremembe dobrodošlice: Spremembe se obdelujejo zelo enostavno. Na izdelek ne vpliva veliko, ker se moduli programske opreme razvijajo ločeno in se kasneje integrirajo. Torej ne bo nobene predelave, če se bo zahteva v prihodnosti spremenila.
• Časovni okvir: Dobili smo časovni okvir za vsako enoto aplikacije. Torej bo ocena natančna glede na ocene časa projekta.
• Zadovoljstvo kupcev: Zadovoljstvo kupcev je večje, ker med projektom komuniciramo s stranko in delničarjem in na vsaki stopnji razvoja izdelka bomo predstavili predstavitev. S tem redno dobivamo povratne informacije strank / strank o poslovnih potekih in napredku dela. Tako se delo in razvoj aplikacije opravita v skladu s tem.

Vrste agilnih metodologij

• Agile Scrum metodologija
• Lean razvoj programske opreme
• Kanban
• Ekstremno programiranje (XP)
• Kristal
• Metoda razvoja dinamičnih sistemov (DSDM)
• Razvoj, usmerjen v funkcije (FDD)

Okretni profesionalci:

• Ena največjih prednosti agilnega modela je njegova velika prilagodljivost . Prilagodljivost pomeni 'odziv na spremembe'. Agile se zelo prilagodljivo spopada s spremembami potreb in prednostnih nalog kupcev.
• Omogoča nenehno izboljšujte in ponovno dajte prednost celotnemu zaostanku izdelkov brez vpliva na trenutno ponovitev, v kateri je ekipa osredotočena na zagotavljanje MVP. Spremembe je mogoče načrtovati za naslednjo ponovitev in tako ponuditi priložnost, da spremembe vnesete le v nekaj tednih.
• Agilna metodologija ponuja veliko mero sodelovanje zainteresiranih strani . Naročnik in projektna skupina se srečata pred, med in po vsakem sprintu. Ker je kupec ves čas vključen v projekt, ima ekipa več priložnosti, da jasno razume kupčevo vizijo.
• Delovna programska oprema je dostavljena zgodaj in pogosto. To poveča zaupanje zainteresiranih strani v ekipi in spodbuja ekipo, da ostanite zelo predani projektu.
• Ta model daje preglednost . Tako zainteresirane strani kot tudi ekipa dobro vedo, kaj se dogaja. Naročnik si lahko ogleda delo, ki poteka.
• Dovoljeni šprinti po fiksnem urniku od enega do štirih tednov zgodnja in predvidljiva dostava . Nove funkcije se sprostijo hitro in pogosto v časovnem okviru.
• Agile je usmerjena na kupca . Ne zagotavlja samo funkcionalnosti, temveč se osredotoča tudi na zagotavljanje funkcije, ki je za uporabnika nekaj koristnega. Vsaka uporabniška zgodba ima poslovno usmerjeno merilo sprejemljivosti.
• Dragoceno povratne informacije strank je pridobljeno zgodaj v projektu in po potrebi lahko spremenite izdelek.
• Poudarek je na poslovni vrednosti . Najprej prinese tisto, kar je za stranko najpomembnejše.
• Izboljša kakovost končnih rezultatov . V nasprotju s slapom se v projektu Agile neprestano in pogosto izvaja testiranje, kar pa pomaga pri zgodnjem odkrivanju in odpravljanju težav.
• Okretna podpira pristop TDD (Test Driven Development) ki zagotavlja dovolj časa za izdelavo preskusov enot za funkcije, ki bodo izdane prek MVP.
• Tudi s proizvodnjo pogoste gradnje , vsako neusklajenost z zahtevami kupcev je mogoče tudi odkriti in odpraviti zgodaj.
• Ko pridemo takojšnje povratne informacije uporabnikov po vsaki izdaji MVP se tveganje za neuspeh projekta je majhno, ko delate na gibčen način.
• Okretna spodbuja timsko delo . Med člani ekipe Agile vlada odlično sodelovanje, interakcija, harmonija in navdušenje.
• Ocene stroškov in urnika vsakega sprinta se stranki sporočijo pred začetkom sprinta. To izboljša odločanje saj lahko uporabnik razume stroške posamezne funkcije in temu ustrezno določi prednostne naloge.
• V agilnem projektu je prostora za stalno izboljševanje . Lekcije, pridobljene v preteklih šprintih, lahko uporabimo v prihajajočih šprintih.
• Osredotoča se na določeno nalogo v vsaki fazi projekta.

Okretne slabosti:

• Pogosto je videti, da imajo agilne ekipe a težnja k zanemarjanju dokumentacije . Razlog za to je, da se manifest Agile osredotoča bolj na delujočo programsko opremo kot na obsežno dokumentacijo. Vendar pa bi morale ekipe vzdrževati pravo ravnovesje med kodo in dokumentacijo.
• Ker zahteva visoko stopnjo vključenosti strank, lahko za stranke včasih problematična ki nimajo veliko časa in interesa za sodelovanje v projektu.
• Ne deluje dobro, če ekipi primanjkuje zavzetosti in predanosti. Slap zahteva sodelovanje, Agile pa zahteva zavzetost.
• Če sta začetna arhitektura in zasnova šibka, potem pogosto preoblikovanje je potrebno.
• V primerjavi s slapom je Agile težko vaditi . Člani ekipe morajo biti dobro seznanjeni z agilnimi koncepti. Zahteva veliko discipline in zavzetosti za gibanje Agile.
• Zaradi ponovne določitve prioritet je manj predvidljiv kot tisto, kar bo dostavljeno na koncu šprinta.
• Zaradi časovno omejene dostave in pogostega ponovnega določanja prednostnih nalog obstaja možnost, da nekaj funkcij ne bo dostavljenih v dodeljenem časovnem traku. To lahko pripelje do dodatni sprinti in dodatni stroški . To lahko privede tudi do problema meglene časovnice .
• Pomanjkanje strukture v primerjavi s slapom zahteva samodisciplinirane, visoko usposobljene in medkvalificirane ekipe . Brez tega je projekt res lahko izziv.
• Razpoložljivost je manj načrta končnega rezultata .
• Včasih zunanja zainteresirana stran se ne more upreti pristopu Agile . V takih primerih je za široko občinstvo potrebno usposabljanje in izobraževanje o Agileu.
• Vsi člani ekipe morajo biti vključeni v upravljanje projekta.
• Dokumentacija je manj podrobna.

Razlika med modeli Agile Vs Waterfall

Spodaj so navedene razlike med življenjskim ciklom slapa in agilnega razvoja programske opreme.

Slap	Okretna
Postopek se obravnava kot en sam projekt, ki je nadalje razdeljen na različne faze.	Postopek je razdeljen na več projektov in vsak projekt ima ponovitev različnih stopenj.
Metodologija slapov je model, pri katerem se vsaka stopnja življenjskega cikla izdelka odvija v zaporedju. Napredek projekta skozi te faze, ki spominjajo na slap, teče postopoma navzdol.	Agilna metodologija je model, ki sledi iterativnemu pristopu.
Ta model verjame v enkratno množično dostavo. Izdelek je dostavljen na koncu SDLC.	Ta model verjame v več majhnih kosov dostave v določenih časovnih intervalih. Na koncu vsakega šprinta je na voljo MVP (Minimum Viable Product).
To je tradicionalen in staromoden pristop.	Njegov nov in sodoben pristop.
En sam cikel in ena izdaja.	Ponavljajoče se število ponovitev in več izdaj.
Življenjski cikel razvoja programske opreme deli v različne faze.	Življenjski cikel razvoja programske opreme deli na sprinte.
Strukturiran in tog model. Težko je spremeniti opis, specifikacijo in zasnovo projekta.	Ta model je znan po svoji prilagodljivosti. Kadar koli lahko spremenimo katero koli fazo projekta.
Lestvica dolgoročnega načrtovanja.	Lestvica kratkoročnega načrtovanja.
Med stranko in razvijalcem obstaja velika razdalja.	Obstaja kratka razdalja med stranko in razvijalcem.
Dolg čas med specifikacijo in izvedbo. Poslovni analitik zbere in pripravi zahtevo pred začetkom projekta.	Kratek čas med specifikacijo in izvedbo. Lastnik izdelka pripravi zahteve in posodobi ekipo v vsakem sprintu.
Dolgo časa odkriva težave.	Težave se hitro odkrijejo.
Visoko tveganje urnika projekta.	Nizko tveganje urnika projekta.
Manj sposobnosti hitrega odzivanja na spremembe.	Visoka sposobnost hitrega odzivanja na spremembe.
Preskusna faza nastopi šele po zaključku razvojne faze.	Testiranje se običajno izvaja vzporedno z razvojem, da se stalno zagotavlja kakovost.
Stranka je vključena samo v fazi zbiranja zahtev in po njej stranka ni več vključena. Na sliko pride samo ob dobavi izdelka.	Stranka je vključena v celoten projekt, stranka pa ji občasno vzame povratne informacije, da zagotovi zadovoljstvo kupca.
Primerno za projekte, ki imajo jasno opredeljene zahteve, in tiste, ki ne pričakujejo sprememb.	Primerno za projekte, ki se morajo razvijati, in tiste, ki vključujejo spreminjajoče se zahteve.
Strog zaporedni postopek.	Zelo sodelovalni postopek razvoja programske opreme vodi do boljših skupinskih prizadevanj in hitrega reševanja problemov.
Razstavlja projektno miselnost.	Predstavlja miselnost izdelka in je tako bolj osredotočen na kupca. Zahteve in spremembe so del procesa
Formalno in hierarhično. Vodja projekta je tisti, ki odloča.	Neformalno je. Za odločanje je odgovorna celotna ekipa.
Ta model predvideva, da zahteve v celotnem projektu ne bodo spremenjene.	Ta model temelji na prilagoditvi in ​​zajema spremembe.
Potrebno je ustvariti ročne dokumente za preverjanje statusa dela in napredka posameznika.	Upošteva Kanbanov diagram in Burn Down grafikon, da preveri potek projekta in posameznikovo delovno stanje.

Dovolj smo razpravljali o razlikah med metodologijami Agile & Waterfall ter koristih in izzivih vsake. Poglejmo zdaj razlike med agilnim testiranjem in testiranjem slapov.

Razlike med agilnim testiranjem in testiranjem slapa

Z vidika preskušanja programske opreme je za nas pomembno, da imamo dobro predstavo o tem, kako se agilno testiranje razlikuje od testiranja slapov.

Zaključek

V tem članku smo izvedeli natančne razlike med sodobnim pristopom Agile in tradicionalno metodo Waterfall pri razvoju in testiranju programske opreme s primerjalno tabelo, ki zajema prednosti in slabosti vsakega modela.

Z upoštevanjem vseh dejavnikov, naštetih v tem članku, lahko za razvoj programske aplikacije izberemo pravi model življenjskega cikla razvoja programske opreme. Nobenega dvoma ni, če rečemo, da imajo prednost agilne metodologije kot model slapa. 90% podjetij raje razvija in razvija Agile, da bi razvilo programsko aplikacijo.

Agilna metodologija je dobra za vse vrste projektov. Le redka podjetja sledijo slapovski metodologiji. Ta metodologija je primerna le, če je prijava majhna, preprosta in zahteva ne spreminja.

V nekaterih primerih se glede na potrebe odločimo tudi za druge pristope, imenovane Spiral, V in V ter Prototype.

Upam, da vam bodo te informacije pomagale pri odločitvi, kateri je najboljši model za vaš projekt. Lahko se odločite tudi za hibridni model, ki odstranjuje slabosti vsake metode - razpravljali tukaj.

Priporočeno branje

• Študija primera: Kako odpraviti pomanjkljivosti slapov in agilnih razvojnih procesov s pomočjo hibridnega modela
• Kaj je model slapa SDLC?
• Pregled orodja za upravljanje preizkusov podjetja Zephyr - Kako uporabiti sredstva modela slapa v orodju Agile
• Vadnica VersionOne: Vodič za orodje za vsestransko upravljanje agilnih projektov
• Vadnica za portfelj Jira: Vtičnik Agile Project Portfolio Management za JIRA (pregled)
• TOP 10 najboljših agilnih orodij za upravljanje projektov v letu 2021
• Tehnike agilne ocene: resnična ocena v agilnem projektu
• 4 koraki k razvoju agilnega miselnega načina testiranja za uspešen prehod na agilni postopek