Агиле Вс Ватерфалл: Која је најбоља методологија за ваш пројекат?

agile vs waterfall which is best methodology

како пронаћи подразумевану маску подмреже

Научите све о агилним и водопадним методологијама, различитим типовима СДЛЦ модела и разликама између водопадних и окретних развојних модела, као и тестирања:

Прочитајте овај информативни чланак да бисте на основу предности и недостатака сваког од њих одлучили који је најпогоднији модел за ваш пројекат.

Модел водопада и агилни модел су врсте животног циклуса развоја софтвера (СДЛЦ). То су процеси које софтверска индустрија користи за дизајнирање, развој и тестирање софтвера.

Пратећи СДЛЦ, можемо постићи очекивања купаца, завршити пројекат у задатим временским оквирима и проценити трошкове.

Шта ћете научити:

• Ток посла водопада и агилног модела
  • Шта је животни циклус развоја софтвера?
  • Врсте животног циклуса развоја софтвера
    • # 1) Модел водопада
    • # 2) окретан модел
    • # 3) Спирални модел
    • # 4) Модел прототипа
    • # 5) В и В модел
• Модел водопада
• Агиле Воркфлов
  • Кључне терминологије које се користе у агилности
  • Кључни фактори за усвајање агилне методологије
  • Врсте агилних методологија
• Разлика између агилних Вс модела водопада
• Разлике између агилног тестирања и тестирања водопада
• Закључак
  • Препоручено читање

Ток посла водопада и агилног модела

На једноставном енглеском, Агиле значи „способан за брзо и лако кретање“ и отуда то и значи када је реч о Агилна методологија развоја .

Агиле је метода управљања пројектима која је представљена поделом задатака на краће сегменте рада са честим прегледима и прилагођавањем планова.

Слично томе, реч водопад означава вертикални ток воде или проток воде кроз низ стрмих падова. Модел водопада је линеарни секвенцијални модел у коме напредак тече углавном у једном смеру надоле кроз фазе прикупљања захтева, анализе, дизајна, развоја, испитивања, примене и одржавања.

Иста илустрација односи се на концепт управљања пројектима када је реч о модел водопада . То је метода управљања пројектом која је представљена серијским фазама и фиксним планом рада.

(слика извор )

Пре него што разговарамо о току слапа и агилном току рада, погледајмо дефиницију животног циклуса развоја софтвера и његове захтеве.

Шта је животни циклус развоја софтвера?

Поступни је поступак системског развоја софтвера. За ово бирамо између различитих врста животних циклуса развоја софтвера у различитим компанијама. На основу захтева бира се одговарајући животни циклус.

Модел водопада један је од СДЛЦ типова и стари је процес развоја софтвера. Агилан модел је најновији и напредни. Агиле је изведен из другог животног циклуса развоја софтвера.

Други СДЛЦ укључује спирални модел, В и В модел, модел Прототипа. На основу потребе и компатибилности пословних захтева, изабраћемо најбољи модел за развој софтверске апликације.

(слика извор )

Зашто је потребан животни циклус развоја софтвера?

СДЛЦ је потребан да структурирано управља пројектом. Пружа одређени ниво контроле и дефинише улоге и одговорности чланова тима. Пружа обим и рок за сваку фазу СДЛЦ-а.

То је помало попут корисничког водича за чланове тима да прате све кораке за развој и испоруку квалитетног производа. Помаже менаџменту тима да дефинише и процени циљеве и захтеве. Такође помаже у заказивању и процени задатака. Чини линију комуникације између клијента и развојног тима и ствара улоге и одговорности за сваког од њих.

Врсте животног циклуса развоја софтвера

Погледајмо кратки увод у врсте СДЛЦ-а који се користе у процесу развоја софтвера.

# 1) Модел водопада

Као што је раније речено, модел водопада први је представљени животни циклус развоја софтвера. То је секвенцијални начин развоја софтвера. Веома мало компанија следи овај приступ. Када је пројекат врло једноставан и не буде даље промена захтева, ми ћемо следити овај приступ.

О овом моделу водостаја разговараћемо више у овом водичу.

# 2) окретан модел

Агилан ток рада је напредни приступ процесу развоја софтвера, који се користи у већини компанија. Агиле је дефинисан као животни циклус развоја софтвера заснован на спринту.

У наредним одељцима можемо више разговарати о агилном току рада.

# 3) Спирални модел

То је начин изградње и тестирања софтвера раздвајањем и додавањем захтева у инкременталном редоследу. Овај модел ће помоћи у пројектима у којима се захтеви непрестано мењају. Овај спирални модел комбинација је итеративног процеса развоја и секвенцијалног линеарног процеса развоја.

Овај приступ ће нам омогућити поступна издања производа. Овде није потребно чекати завршетак свих модула софтвера за издање.

Линеарни секвенцијални модел значи да је то систематски секвенцијални приступ развоју софтвера који започиње на нивоу система и напредује анализом, дизајном, кодирањем, тестирањем и подршком.

Итеративни модел значи да је то посебна примена животног циклуса развоја софтвера која се фокусира на почетну, поједностављену имплементацију, која затим постепено добија све већу сложеност и поставља се шира карактеристика док коначни систем не буде завршен.

# 4) Модел прототипа

Овај модел укључује процес израде и тестирања софтвера на такав начин да прво развијемо лажни модел, а ако је изводљив и достигне све пословне захтеве, имплементирамо стварни радни модел.

Овде смо прво направили и тестирали прототип, а затим изградили стварни модел са тачним системским спецификацијама. Израда прототипа софтвера је активност стварања прототипова софтверских апликација.

# 5) В и В модел

То је модел верификације и валидације. Ево, док смо развијали софтвер, користили смо да верификујемо и потврдимо све у свакој фази СДЛЦ-а. В-модел се сматра продужетком модела водопада.

Дакле, сви типови СДЛЦ имају своје карактеристике и карактеристике. На основу захтева пројекта, потреба, изводљивости, трајања, можемо одабрати одређени животни циклус развоја софтвера за развој софтверске апликације.

Сада ћемо детаљно разговарати о животним циклусима развоја водопада и агилног софтвера.

Модел водопада

У моделу Водопада, сваку фазу треба завршити пре започињања друге фазе. Не можемо истовремено радити са више фаза. Ово је 1970. представио Винстон Роице. Модел водопада подељен је у различите фазе.

(слика извор )

Модел водопада укључује следеће фазе:

1. Прикупљање захтева
2. Студија изводљивости
3. Дизајн
4. Кодирање
5. Тестирање
6. Одржавање

# 1) Анализа захтева

Овде ће пословни аналитичар добити спецификацију захтева. Захтев ће бити у формату ЦРС (спецификација захтева корисника). ЦРС објашњава како треба да иде пословни ток и како апликација треба да ради према наведеном захтеву. Пословни аналитичари претвориће ЦРС у СРС (спецификација софтверског захтева).

Тада пословни аналитичар детаљно разговара о спецификацијама захтева са тимом за развој и тестирање и разуме захтев са становишта развоја и тестирања. Ово је фаза расправе и анализе захтева за изградњу апликативног софтвера заснованог на стварним захтевима.

Овде би све требало документовати у документу о спецификацији софтверских захтева. У моделу водопада, испорука / резултат / излаз сваке фазе је улазни извор за следеће фазе.

У индустрији која се заснива на услугама, пословни аналитичар може донети тај захтев.
У компанији заснованој на производу, Продуцт Аналист доноси захтев.

# 2) Студија изводљивости

Управни тим ће израдити студију изводљивости. То значи да ће тим анализирати параметре попут тога, да ли се овај захтев / апликација може развити у нашем окружењу или не, да ли је доступан ресурс довољан или не, да ли су трошкови и многи други фактори изводљиви или не и да бисмо проверили да ли смо у стању да покријемо сви послови точе или не.

На овом састанку / анализи, менаџер пројекта, пословни аналитичар, менаџер финансија, ХР, вођа пројекта биће део дискусије.

# 3) Дизајн система

Овде ће Пројецт Арцхитецт припремити дизајн система. Одредиће хардвер, системске захтеве и дизајнирати архитектуру апликације. Постоје 2 дела у дизајну система: дизајн на високом нивоу и дизајн на ниском нивоу. У дизајну на високом нивоу, дизајнирамо различите блокове апликације. У дизајну на ниском нивоу, ми пишемо псеудо-код.

# 4) Кодирање

Овде програмери започињу тачно кодирање сваке функције и корисничког интерфејса апликације користећи различите методе и различите логике. За изградњу апликације могу користити било који програмски језик као што су Јава, Питхон или било који други језик.

Када се кодирање заврши за сваку функционалност одређеног модула апликације, програмер ће извршити јединствено тестирање. Ако код добро функционише, програмер ће применити код у окружење за тестирање и дати израду испитивачу на тестирање.

# 5) Тестирање

Одавде започиње активност тестирања. До ове фазе нећемо имати задатак у моделу Водопад. У овој фази вршимо све врсте испитивања. Ови типови тестирања укључују тестирање дима, функционално тестирање, тестирање интеграције, тестирање система, испитивање прихватљивости, регресијско тестирање, ад хоц тестирање, истраживачко тестирање и испитивање у више прегледача.

Почећемо да тестирамо апликацију када добијемо грађу. Прво ћемо почети са тестирањем дима. Ако се не примете проблеми са блокадом, наставићемо са детаљним тестирањем.

У функционалном тестирању започињемо са тестирањем сваке компоненте апликације. Овде проверавамо различите компоненте као што су текстуална поља, дугмад, везе, радио дугмад, дугмад за отпремање, падајуће меније и везе за навигацију.

Затим ћемо проверити кориснички интерфејс, изглед и осећај и позитивно и негативно тестирање улазних података.

Тада ћемо започети са интеграционим тестирањем. Овде ћемо проверити интеграцију података. Проверићемо да ли се исти подаци одражавају на различитим одговарајућим страницама или не, проверићемо навигацију путем е-поште до одговарајућих страница. Проверићемо интеграцију података са независним апликацијама и промене у бази података у апликацији.

Даље, урадићемо системско тестирање. Проверићемо целу апликацију као јединствену целину. Проверићемо функционалност, интеграцију страница, проверу поља, поруке о грешкама, поруке о потврди и још много тога.

Током тестирања апликације евидентираћемо проблеме у алату за праћење грешака. Даћемо приоритет грешци на основу проблема. Након креирања грешке, доделићемо је одговарајућем програмеру да реши проблем. Проверићемо грешке када их програмери доделе тестерима након што их исправе. Ако буде добро функционисало, тестер ће затворити грешку, у супротном ће тестери доделити програмеру да реши проблем. Тако се одвија животни циклус грешке.

Затим прелазимо на испитивање прихватљивости. Овде тестирамо апликацију у различитим окружењима као што су инсценација и УАТ (Усер Аццептанце Тестинг). Ово је најважнија фаза за темељно тестирање апликације пре него што код преместимо у производно окружење.

Једном када се изврши тестирање прихватања без грешака, тада ће клијент планирати да примени код на производни сервер и планира издање.

# 6) Одржавање

Једном када применимо код апликације на производни сервер, требали бисмо пружити подршку / одржавање клијентској апликацији. Ова фаза одржавања треба да посматра и решава проблеме са производњом у реалном времену, проверава проблеме са меморијом, побољшава апликацију и развија нове промене захтева.

У којим случајевима се можемо одлучити за модел водопада?

• Када нема потребних промена.
• Када је пројекат мали и једноставан.
• Када у технологији нема сложености.
• Када је доступно више ресурса.

Прослави за водопад:

• Напред назад планирање и спровођење је једноставно .
• Модел водопада је једноставан за употребу и лак за разумевање. Не захтева никакву посебну обуку за руководиоце пројеката или запослене. Има лагана крива учења .
• Будући да је круте природе, јесте лако за управљање циклус водопада. Свака фаза има фиксне испоруке и поступак прегледа.
• Мање сложености како се фазе не преклапају. Фазе се прате једна за другом. Користи јасну структуру у поређењу са другим методологијама развоја софтвера. Пројекат пролази кроз фиксне секвенцијалне кораке почев од прикупљања захтева и коначно стаје на одржавање.
• Због фазног развоја, дисциплина се спроводи , а рокови се могу лако чувати.
• Извођење радова добро за мале пројекте где имамо фиксне и кристално јасне захтеве.
• Процеси и резултати су добро забележено .
• Распоређивање задатака је једноставно.
• То је лако измерити напредак пошто су почетне и крајње тачке сваке фазе унапред одређене.
• Готово да се не мењају захтеви током целог пројекта, па отуда и задаци остају стабилни за програмере. Такође, лако је за било кога нови програмер за брзо учење и започети посао.
• Постоје без финансијских изненађења . Једном када су захтеви фиксни, коначни трошак се може израчунати пре почетка развоја.
• Цатерс за а модел секвенцијалног финансирања .
• Његово дизајн са детаљима чини крајњи очекивани исход свима врло јасним.
• Спецификација функционалних захтева документована у фази прикупљања захтева даје испитивачима довољно детаља да осмисле сценарије испитивања и случајеве испитивања. Отуда процес тестирања постаје лак у моделу водопада.

Ватерфалл Цонс:

• Како сви захтеви морају бити јасно познати пре започињања развоја, то одлаже пројекат .
• Захтева опсежно истраживање у потребе корисника.
• У почетној фази пројекта изазов је за купца да јасно дефинише и концептуализира своје захтеве у облику функционалних спецификација. Отуда постоји велика могућност да се предомисле након што виде крајњи производ. До ове промене може доћи и због пословног плана или утицаја на тржиште. Чини га мала флексибилност овог модела тешко прихватити било какве такве промене , посебно када је потребно у великој мери прерадити производ.
• Нема радног модела производи се до касније етапа током животног циклуса водопада.
• Споро време испоруке . Купац није у могућности да види производ док није у потпуности завршен.
• Купац нема могућност да се унапред упозна са системом. Модел водопада је више ан унутрашњи процес и задржава крајњег корисника искљученим .
• Тхе клијент није обавештен добро о здрављу пројекта.
• Рокови се могу пропустити ако се не поштује строго управљање и редовно праћење.
• Постоји нема места за промене чак и ако је видљив током развоја јер производ неће удовољити захтевима тржишта.
• Одлагање тестирања до по завршетку. Такође, велике ревизије су у овом тренутку веома скупе.
• Висок ризик и неизвесност су укључени у модел водопада, јер има превише простора да питања остану непримећена док се пројекат не приведе крају.
• Није погодан модел за дуге, сложене и текуће пројекте.
• Тешко је измери напредак у оквиру сваке фазе.
• Испитивачи ће седети беспослено током многих фаза пројекта.

Агиле Воркфлов

Сада ћемо видети животни циклус развоја агилног софтвера. Агиле је процес брзог и лаког обављања посла са више тачности.

Овај модел је повезан са методом управљања пројектима, која се посебно користи за развој софтвера. Карактерише га подела задатака на кратке фазе рада и честа поновна процена и прилагођавање планова. Сваки члан тима треба да има представу о основним токовима пословања.

(слика извор )

У Агилеу програмери и тестери паралелно раде на развоју и тестирању апликативног софтвера. Развој се врши у итеративном режиму. Свака корисничка прича о итерацији захтева анализу, дизајн, кодирање и тестирање.

Детаљно тестирамо захтев како бисмо верификовали да ли је захтев без грешака и да ли је применљив. Пређите на следећу итерацију по завршетку сваке итерације и ми следимо исти поступак према новим / другим захтевима.

Дакле, овај процес развоја и тестирања софтверског блока изводи се у кратком временском периоду са више тачности и флексибилности. Дакле, више индустрија прати и усваја овај процес.

Прво ће власник производа додати све захтеве заостатку производа. Заостатак производа садржи све корисничке приче. Рецимо, 100 до 150 корисничких прича повезане су са комплетним пројектом. Сада додајте посебне корисничке приче у заостатак у спринту који морамо да применимо. Тада ће сви програмери, КА, БА радити на спринт ставкама. Тако функционише Агиле флов.

Кључне терминологије које се користе у агилности

Шта је заостатак у спринту?

димензионално моделирање у складишту података са примером

То је листа корисничких прича које треба да применимо у тренутној итерацији или спринту.

На пример, има 20 до 30 корисничких прича у заостатку у спринту. Онда су ово корисничке приче које морамо да применимо у тренутном спринту.

(слика извор )

Шта је Спринт?

Спринт је мало трајање у којем треба да имплементирамо изабране корисничке приче у одређеном трајању. Трајање спринта биће око 2 до 3 недеље. Његово трајање варира од компаније до компаније.

У овом трајању спринта, тим мора да анализира захтев, дизајнира захтеве, изведе кодирање, тестирање, решавање проблема, поновно тестирање, регресијско тестирање, демо и још много других активности.

Свакодневни састанак Стандуп Сцрум

Пословни аналитичар, програмер, тестер, менаџер пројекта део су свакодневних станд уп сцрум састанака. Ради се свакодневно. Не би требало да траје дуже од 15 до 30 минута.

Овде ће сви чланови тима делити свакодневни радни статус. Главне ствари о којима овде разговарамо су: које су ствари завршене јуче, план данашњег рада и сви изазови или зависности са којима се суочавају у пројекту.

Ако се било који члан тима суочи са било каквим изазовима или препрекама током пројекта, дотична особа ће радити на томе да то уради.

Бурндовн Цхарт

То је сликовити графички приказ времена и рада. Оса к представља преостали рад, а оса и представља преостало време спринта. Тим мора да креира радне задатке који се односе на расположиво време у одређеном спринту. Тим ће свакодневно спаљивати сате задатака на основу посла који су радили и завршили.

(слика извор )

Канбан Цхарт

То је шема / алат за управљање пројектима. Овим можемо управљати задацима целог пројекта. Можемо проверити статус напредовања пројекта и статус посла појединаца. Приказује сликовити дигитални приказ напредних предмета, ставки на чекању и готових предмета.

(слика извор )

питања и одговори за испитивање соапуи тестирања

Планирање покер активности

То је игра између чланова спринт тима да би проценили корисничке приче. Овде ће цео тим играти покер активност. Сваки члан тима даје процену на основу корисничке приче. На основу већине гласова за процену, тим ће одлучити и доделити време.

На пример , један члан тима из корисничке приче даће процену попут 3, 5, 8, 3, 1, 3. Тада ће тим одабрати 3 за процену. Картица за покер активност садржи 0, 1, 3, 5, 8, 13, 20, 100, пауза, сумње? картице. На основу овог члана чланови ће предложити било коју карту за процену. Овако, проценићемо све корисничке приче које су повезане са одређеним спринтом.

(слика извор )

• 0 покер број представља: нема задатка у тој ставци / корисничкој причи
• 1, 3 броја представљају: задатак је мањи
• 5, 8 бројева представљају: задаци средњег нивоа
• 13, 20 број представља: задаци великог нивоа
• 100 број представља: врло велики задаци
• Бесконачност представља: Задатак је огроман, треба га поделити на више задатака и корисничких прича
• Пауза представља: Треба ми пауза
• ? Представља: Сумње

Сцрум Мастер

Он је особа која помаже тиму да следи агилни процес и испуни захтеве пројекта. Састанак ће одржати кад год је то потребно и помоћи да се разговара о потребама пројекта.

Сцрум мастер делује као мост за све чланове тима да реше изазове и зависности које наиђу на пројекат. Пратиће напредак пројекта у вези са сваким спринтом.

Укључен је у стандуп састанак, ретроспективни састанак, инспекцију, преглед, демонстрацију. Он је тај који води дневне станд уп састанке и ажурира чланове тима.

Власник производа

Он је особа која покреће и надгледа производ / пројекат са пословног становишта. И даље гледа како је производ развијен према пословним захтевима или не. Он је тај који даје приоритет корисничким причама и премешта захтеве из заосталих производа у заостале у спринту. Процениће рокове за пројекат.

Увек гледа на производ са становишта корисника. Власник производа има потпуно знање о томе како апликација треба да ради.

Прича о кориснику

То је блок захтева. Садржи скуп случајева употребе / захтева који се односе на исти модул. Овде дефинишемо како свака компонента апликације треба да ради и како треба да изгледа кориснички интерфејс. Опсег сваке компоненте дефинисан је у корисничкој причи.

Задаци

Чланови тима креираће задатак за корисничку причу који им је додељен. Морају да креирају задатак на основу различитих задатака као што су развојни задатак, задатак тестирања, задатак анализе корисничке приче. Трајање задатка треба да зависи од тачака корисничких прича.

Као тестер, креираћемо задатке за анализу корисничких прича, припрему тест случајева, извршење, регресијско тестирање и још много тога.

Дотјеривање заосталих предмета

Овај део укључује управљање заосталим ставкама. Овде радимо давање приоритета заосталим ставкама, разбијање на мање предмете, креирање задатка и ажурирање критеријума за прихватање.

Понављање

Итерација је развој и тестирање неких модула / делова софтверске апликације. Свака итерација се састоји од анализе производа, дизајнирања производа, развоја производа, тестирања производа и демонстрације производа.

Кључни фактори за усвајање агилне методологије

• Посматрање: Редовно прегледавајте рад и производ и сходно томе планирајте активности. Тако ће процес развоја производа и квалитет производа бити добри.
• Промјене добродошлице: Промене се обрађују врло лако. То не утиче много на производ, јер се модули софтвера развијају одвојено и интегришу касније. Дакле, неће бити прераде ако се захтев промени у будућности.
• Временски оквир: Дајемо временски оквир за сваку јединицу апликације. Дакле, процена ће бити тачна према проценама времена пројекта.
• Задовољство купаца: Задовољство купаца је веће јер у интеракцији са клијентом и акционаром имамо током целог пројекта и даћемо демонстрацију на сваком нивоу развоја производа. Овим редовно добијамо повратне информације купаца / клијената о пословним токовима и напретку у раду. Тако се рад и развој апликације обављају у складу с тим.

Врсте агилних методологија

• Агиле Сцрум методологија
• Леан развој софтвера
• Канбан
• Екстремно програмирање (КСП)
• Кристал
• Метода развоја динамичких система (ДСДМ)
• Развој вођен карактеристикама (ФДД)

Агиле Прос:

• Једна од највећих предности агилног модела је његова велика прилагодљивост . Прилагодљивост значи „одговарање на промене“. Агиле је врло флексибилан у суочавању са променама у потребама и приоритетима купаца.
• Омогућава да непрестано усавршавајте и поново постављајте приоритете за целокупан заостатак производа без утицаја на тренутну итерацију у којој је тим усмерен на испоруку МВП-а. Промене се могу планирати за следећу итерацију, пружајући тако могућност да се промене унесу само у року од неколико недеља.
• Агиле методологија нуди велики степен укључивања заинтересованих страна . Клијент и пројектни тим састају се пре, током и након сваког спринта. Како је купац непрекидно укључен у пројекат, тиму постоји више прилика да јасно разуме визију купца.
• Радни софтвер се испоручује рано и често. Ово повећава поверење заинтересованих страна у тиму и подстиче тим да останите веома посвећени пројекту.
• Овај модел даје транспарентност . И заинтересоване стране и тим добро знају шта се дешава. Клијент може видети рад у току.
• То омогућавају спринтови фиксног распореда од једне до четири недеље рана и предвидљива испорука . Нове функције се објављују брзо и често на временски ограничен начин.
• Агиле ис усмерен на купца . Не испоручује само функционалност, већ се фокусира и на пружање функције која има неку вредност за корисника. Свака корисничка прича има критеријум прихватања усмерен на пословање.
• Вредно повратне информације купаца се добија рано у пројекту и промене производа могу се вршити по потреби.
• Фокус је на пословној вредности . Прво испоручује оно што је најважније за клијента.
• Побољшава квалитет испоручених производа . За разлику од водопада, тестирање се континуирано и често обавља у Агиле пројекту, што заузврат помаже у раном откривању и решавању проблема.
• Окретан подржава ТДД (Тест Дривен Девелопмент) приступ што пружа довољно времена за стварање јединствених тестова за функције које ће бити објављене путем МВП-а.
• Такође, производњом честе градње , било каква неусклађеност са захтевима купца такође се може открити и отклонити рано.
• Како стижемо непосредне повратне информације корисника након сваког МВП издања, ризик од неуспеха пројекта је низак, када радите на окретан начин.
• Окретан промовише тимски рад . Међу члановима Агиле тима постоји сјајна сарадња, интеракција, хармонија и ентузијазам.
• Процене трошкова и распореда сваког спринта саопштавају се клијенту пре почетка спринта. Ово побољшава доношење одлука јер корисник може да разуме цену сваке функције и да јој у складу с тим постави приоритет.
• У агилном пројекту има места за континуирано побољшање . Лекције научене из прошлих спринтова могу се применити у наредним спринтима.
• Фокусира се на одређени задатак у свакој фази пројекта.

Агиле Цонс:

• Често се види да Агиле тимови имају а тенденција занемаривања документације . То је зато што се Агиле манифест више фокусира на радни софтвер него на свеобухватну документацију. Међутим, тимови би требали одржавати праву равнотежу између кода и документације.
• Како то захтева висок степен учешћа купаца, то може понекад могу бити проблематични за купце који немају много времена и интереса да учествују у пројекту.
• Не функционише добро ако тиму недостаје посвећености и посвећености. Водопад захтева ангажовање, међутим, Агиле захтева посвећеност.
• Ако су почетна архитектура и дизајн слаби, онда честа рефакторизација је потребно.
• У поређењу са водопадом, Агиле је тешко вежбати . Чланови тима морају бити добро упућени у агилне концепте. За вежбање агилности потребно је много дисциплине и посвећености.
• Због поновног одређивања приоритета, јесте мање предвидљив него оно што ће бити испоручено на крају спринта.
• Због испоруке са временским оквиром и честог поновног одређивања приоритета, постоји могућност да неколико функција не буде испоручено у додељеном временском оквиру. Ово може довести до додатни спринт и додатни трошкови . То такође може довести до проблема небулозне временске линије .
• Недостатак структуре у поређењу са водопадом захтева самодисциплиноване, високо стручне и укрштене тимове . Без овога, пројекат заиста може бити изазован.
• Доступност је мање нацрт коначног резултата .
• Понекад спољна заинтересована страна не може да се одупре следећи агилни приступ . У таквим случајевима, обука и образовање о Агиле-у су потребни широкој публици.
• Сви чланови тима морају бити укључени у управљање пројектом.
• Документација је мање детаљна.

Разлика између агилних Вс модела водопада

Разлике између животног циклуса водопада и агилног развоја софтвера наведене су у наставку.

Водопад	Окретан
Процес се третира као један једини пројекат који је даље подељен у различите фазе.	Процес је подељен на више пројеката и сваки пројекат има итерацију различитих фаза.
Методологија водопада је модел у којем се свака фаза животног циклуса производа дешава у низу. Напредак пројекта постепено тече надоле кроз ове фазе налик водопаду.	Агилна методологија је модел који следи итеративни приступ.
Овај модел верује у једнократну масовну испоруку у целини. Производ се испоручује на крају СДЛЦ.	Овај модел верује у више малих делова испоруке у дефинисаним временским интервалима. МВП (минимално одрживи производ) испоручује се на крају сваког спринта.
То је традиционални и старомодни приступ.	То је нов и модеран приступ.
Један једини циклус и једно издање.	Понављајући број понављања и више издања.
Животни циклус развоја софтвера дели у различите фазе.	Животни циклус развоја софтвера дели на спринтеве.
Структурирани и крути модел. Тешко је променити опис, спецификацију и дизајн пројекта.	Овај модел је познат по својој флексибилности. У било ком тренутку можемо извршити промене у било којој фази пројекта.
Размера дугорочног планирања.	Краткорочно планирање.
Између купца и програмера постоји велика удаљеност.	Постоји мала удаљеност између купца и програмера.
Дуго времена између спецификације и примене. Пословни аналитичар прикупља и припрема захтеве пре почетка пројекта.	Кратко време између спецификације и примене. Власник производа припрема захтеве и ажурира тим за сваки спринт.
Откривање проблема траје дуго.	Проблеми се брзо откривају.
Висок ризик распореда пројеката.	Низак ризик распореда пројеката.
Мање способност брзог реаговања на промене.	Висока способност брзог реаговања на промене.
Фаза тестирања наступа тек након завршетка развојне фазе.	Тестирање се обично врши паралелно са развојем како би се континуирано осигуравао квалитет.
Купац је укључен само у фази прикупљања захтева, а након тога није укључен. На слику долази само у тренутку испоруке производа.	Купац је укључен у цео пројекат и повремено се узима повратна информација како би се осигурало задовољство купца.
Погодно за пројекте који имају јасно дефинисане захтеве и оне који не очекују промене.	Погодно за пројекте који морају да се развијају и оне који укључују променљиве захтеве.
Строго секвенцијални процес.	Процес развоја софтвера који се веома сарадјује доводи до бољих тимских напора и брзог решавања проблема.
Излаже начин размишљања о пројекту.	Представља начин размишљања о производу и самим тим је више усмерен на купца. Захтеви и промене су део процеса
Формално и хијерархијски. Менаџер пројекта је доносилац одлуке.	Неформално је. Читав тим је одговоран за доношење одлука.
Овај модел предвиђа да неће бити промена у захтевима током целог пројекта.	Овај модел заснован је на адаптацији и обухвата промене.
Потребно је створити ручна документа како би се верификовао статус рада појединца и напредак пројекта.	Прати Канбанов графикон и Бурн Довн графикон да би потврдио напредак пројекта и радни статус појединца.

Имали смо довољно разговора о разликама између методологија Агиле & Ватерфалл и предностима и изазовима сваке од њих. Истражимо сада разлике између агилног тестирања и тестирања водопада.

Разлике између агилног тестирања и тестирања водопада

Из перспективе софтверског тестирања, важно нам је да имамо поштену представу о томе како се агилно тестирање разликује од тестирања водопада.

Закључак

У овом чланку сазнали смо тачне разлике између савременог агилног приступа и традиционалне методе водопада за развој и тестирање софтвера са упоредном табелом која покрива предности и недостатке сваког модела.

Узимајући у обзир све факторе наведене у овом чланку, можемо одабрати тачан модел животног циклуса развоја софтвера за развој софтверске апликације. Несумњиво је рећи да се агилним методологијама даје предност у односу на модел водопада. 90% компанија више воли и прати Агиле процес рада да би развило софтверску апликацију.

Агилна методологија је добра за све врсте пројеката. Веома мало компанија следи методологију водопада. Ова методологија је погодна само ако је апликација мала, једноставна и ако нема промена у захтеву.

У неким случајевима одлучујемо се и за друге приступе зване Спирала, В и В и Прототип, на основу потреба.

Надам се да ће вам ове информације помоћи да одлучите који је најбољи модел за ваш пројекат. Такође можете да се одлучите за хибридни модел уклањајући недостатке сваке методе - овде се дискутује.

Препоручено читање

• Студија случаја: Како елиминисати недостатке водопада и агилних развојних процеса користећи хибридни модел
• Шта је СДЛЦ модел водопада?
• Преглед алата за управљање тестовима предузећа Зепхир - Како користити имовину модела водопада у Агиле Тоол-у
• Водич за ВерсионОне: Водич за све агилан алат за управљање агилним пројектима
• Водич за Јира портфељ: Агиле додатак за управљање портфељем пројеката за ЈИРА (преглед)
• ТОП 10 најбољих агилних алата за управљање пројектима 2021
• Агиле технике процене: истинска процена у агилном пројекту
• 4 корака ка развоју агилног начина тестирања за успешан прелазак на агилни процес