Agile Vs Waterfall: Коя е най-добрата методология за вашия проект?

agile vs waterfall which is best methodology

как да отпечатате съдържанието на масива

Научете всичко за методологиите Agile и Waterfall, различните видове SDLC модели и разликите между моделите Waterfall срещу Agile Development, както и тестването:

Прочетете тази информативна статия, за да решите кой е най-подходящият модел за вашия проект въз основа на плюсовете и минусите на всеки.

Моделът на водопада и пъргавият модел са видовете жизнен цикъл на разработка на софтуер (SDLC). Това са процесите, използвани от софтуерната индустрия за проектиране, разработване и тестване на софтуера.

Следвайки SDLC, можем да постигнем очакванията на клиентите, да завършим проекта в рамките на зададени срокове и да изчислим разходите.

Какво ще научите:

• Водопад и пъргави модели работни потоци
  • Какво представлява жизненият цикъл на разработката на софтуер?
  • Видове жизнен цикъл на разработка на софтуер
    • # 1) Модел на водопад
    • # 2) пъргав модел
    • # 3) Спирален модел
    • # 4) Прототип модел
    • # 5) V и V модел
• Модел на водопад
• Agile Workflow
  • Основни терминологии, използвани в Agile
  • Основни фактори за възприемане на гъвкава методология
  • Видове гъвкави методологии
• Разлика между моделите Agile Vs Waterfall
• Разлики между пъргавото тестване срещу тестването на водопад
• Заключение
  • Препоръчително четене

Водопад и пъргави модели работни потоци

На прост английски Agile означава „способен да се движи бързо и лесно“ и следователно това означава, когато става въпрос за Agile методология за развитие .

Agile е метод за управление на проекти, който се представя чрез разделяне на задачите на по-кратки сегменти от работата с чести прегледи и адаптиране на плановете.

По същия начин думата водопад означава вертикален поток на водата или потокът на водата през поредица от стръмни капки. Моделът на водопада е линеен последователен модел, при който напредъкът тече основно в една посока надолу през фазите на събиране на изисквания, анализ, проектиране, разработване, тестване, внедряване и поддръжка.

Същата илюстрация се отнася за концепцията за управление на проекти, когато става въпрос за модел водопад . Това е метод за управление на проекти, който е представен от последователни етапи и фиксиран работен план.

(изображение източник )

Преди да обсъдим работния процес на водопада и работния процес Agile, нека разгледаме определението за жизнения цикъл на разработката на софтуер и неговите изисквания.

Какво представлява жизненият цикъл на разработката на софтуер?

Процедурата е стъпка по стъпка за системно разработване на софтуера. За целта избираме измежду различни видове жизнен цикъл на разработка на софтуер в различни компании. Въз основа на изискването се избира подходящ жизнен цикъл.

Моделът водопад е един от типовете SDLC и е стар процес на разработване на софтуер. Пъргавият модел е най-новият и усъвършенстван. Agile произлиза от жизнения цикъл на други софтуерни разработки.

Други SDLC включват спирален модел, V и V модел, прототип модел. Въз основа на необходимостта и съвместимостта на бизнес изискванията, ние ще изберем най-добрия модел за разработване на софтуерното приложение.

(изображение източник )

Защо се изисква жизнен цикъл на разработка на софтуер?

SDLC се изисква да управлява проекта по структуриран начин. Той осигурява определено ниво на контрол и определя ролите и отговорностите на членовете на екипа. Той предоставя обхвата и крайния срок за всяка фаза в SDLC.

Това е донякъде като ръководство на потребителя за членовете на екипа да следват всички стъпки за разработване и доставяне на качествения продукт. Помага на ръководството на екипа да дефинира и оцени целите и изискванията. Той също така помага при планиране и оценка на задачите. Той прави комуникационната линия между клиента и екипа за разработка и създава ролите и отговорностите за всеки от тях.

Видове жизнен цикъл на разработка на софтуер

Нека видим кратко въведение в типовете SDLC, използвани в процеса на разработване на софтуер.

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

Както беше обсъдено по-рано, моделът водопад е първият въведен жизнен цикъл на разработка на софтуер. Това е последователният начин за разработване на софтуер. Много малко компании следват този подход. Когато проектът е много прост и няма допълнителни промени в изискванията, ние ще следваме този подход.

Ще обсъдим повече за модела на водопада в този урок.

# 2) пъргав модел

Подвижният работен процес е усъвършенстван подход към процеса на разработване на софтуер, който се използва в повечето компании. Agile се определя като жизнен цикъл на разработка на софтуер, базиран на спринт.

В предстоящите раздели можем да обсъдим повече за работния процес Agile.

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

Това е начинът за изграждане и тестване на софтуера чрез разделяне и добавяне на изискването в нарастващ ред. Този модел ще помогне в проекти, при които изискванията продължават да се променят. Този спирален модел е комбинацията от итеративен процес на развитие и последователен линеен процес на развитие.

Този подход ще ни позволи в постепенно освобождаване на продукта. Тук не е необходимо да чакате завършването на всички модули на софтуера за изданието.

Линейният последователен модел означава, че това е систематичен последователен подход за разработване на софтуер, който започва на системно ниво и напредва чрез анализ, проектиране, кодиране, тестване и поддръжка.

Итеративният модел означава, че това е конкретна реализация на жизнения цикъл на разработка на софтуер, който се фокусира върху първоначално, опростено изпълнение, което след това постепенно придобива все по-голяма сложност и се задава по-широка характеристика, докато окончателната система не бъде завършена.

# 4) Прототип модел

Този модел включва процеса на изграждане и тестване на софтуера по такъв начин, че първо да разработим фиктивния модел и ако е осъществимо и да достигне всички бизнес изисквания, тогава ние прилагаме действителния работещ модел.

Тук първо изградихме и тествахме прототипа, след което изградихме реалния модел с точните спецификации на системата. Прототипирането на софтуер е дейността по създаване на прототипи на софтуерни приложения.

# 5) V и V модел

Това е моделът за проверка и валидиране. Тук, докато разработвахме софтуера, използвахме за проверка и валидиране на всичко във всяка фаза на SDLC. V-моделът се разглежда като продължение на модела на водопада.

И така, всички SDLC типове имат своите характеристики и характеристики. Въз основа на изискванията на проекта, нуждите, осъществимостта, продължителността на времето, ние можем да изберем конкретния жизнен цикъл на разработване на софтуер, за да разработим софтуерното приложение.

Сега ще обсъдим подробно жизнения цикъл на разработката на софтуер Waterfall и Agile.

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

В модела на водопада всяка фаза трябва да бъде завършена, преди да започне друга фаза. Не можем да работим по няколко фази едновременно. Това беше представено през 1970 г. от Уинстън Ройс. Моделът на водопада е разделен на различни фази.

(изображение източник )

Моделът на водопада включва следните фази:

1. Събиране на изисквания
2. Предпроектно проучване
3. Дизайн
4. Кодиране
5. Тестване
6. Поддръжка

# 1) Анализ на изискванията

Тук бизнес анализаторът ще получи спецификацията на изискванията. Изискването ще бъде във формат CRS (Спецификация на изискванията на клиента). CRS обяснява как трябва да протича бизнес потокът и как приложението трябва да работи съгласно определеното изискване. Бизнес анализаторите ще преобразуват CRS в SRS (Спецификация на софтуерните изисквания).

Тогава бизнес анализаторът обсъжда подробно спецификациите на изискванията с екипа за разработка и тестване и разбира изискването от гледна точка на разработката и тестването. Това е фазата на обсъждане и анализ на изискванията за изграждане на приложен софтуер въз основа на действителните изисквания.

Тук всичко трябва да бъде документирано в документа за спецификация на софтуерните изисквания. В модела на водопада всяка доставка на фаза / резултат / изход е входният източник за следващите фази.

В индустрия, базирана на услуги, бизнес анализатор може да внесе изискването.
В базирана на продукти компания Product Analyst носи изискването.

# 2) Предпроектно проучване

Мениджърският екип ще направи предпроектното проучване. Това означава, че екипът ще анализира параметри като, може ли това изискване / приложение да бъде разработено в нашата среда или не, наличният ресурс е достатъчен или не, разходите и много други фактори са осъществими или не и за да провери дали сме в състояние да покрием всички бизнес потоци или не.

В тази среща / анализ ръководител на проекти, бизнес анализатор, финансов мениджър, HR, ръководител на проекта ще бъде част от дискусията.

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

Тук Project Architect ще подготви дизайна на системата. Той ще уточни хардуера, системните изисквания и ще проектира архитектурата на приложението. В дизайна на системата има 2 части: дизайн на високо ниво и дизайн на ниско ниво. В дизайна на високо ниво ние проектираме различните блокове на приложението. В дизайна на ниско ниво ние пишем псевдокода.

# 4) Кодиране

Тук разработчиците започват точното кодиране на всяка функция и потребителския интерфейс на приложението, като използват различни методи и различни логики. Те могат да използват всеки език за програмиране като Java, Python или всеки друг език за изграждане на приложението.

След като кодирането завърши за всяка функционалност на конкретния модул на приложението, разработчикът ще направи модулното тестване. Ако кодът работи добре, разработчикът ще внедри кода в средата за тестване и ще даде компилацията на тестера за тестване.

# 5) Тестване

Оттук започва тестовата дейност. До тази фаза няма да имаме никаква задача в модела Waterfall. В тази фаза правим всички видове тестове. Тези видове тестване включват тестване на дим, функционално тестване, тестване на интеграция, тестване на системата, тестове за приемане, регресионно тестване, ad hoc тестване, изследователско тестване и тестване на различни браузъри.

Ще започнем да тестваме приложението, след като получим компилацията. Първо ще започнем с тестването на дим. Ако не се наблюдават проблеми с блокирането, ще продължим с подробното тестване.

При функционалното тестване ще започнем да тестваме всеки компонент на приложението. Тук проверяваме различните компоненти като текстови полета, бутони, връзки, радиобутони, бутони за качване, падащи менюта и навигационни връзки.

След това ще проверим потребителския интерфейс, външния вид и положителния и отрицателния входен тест.

След това ще започнем с теста за интеграция. Тук ще проверим интеграцията на данните. Ние ще проверим дали едни и същи данни се отразяват на различни съответни страници или не, ще проверим навигацията по имейл връзка към съответните страници. Ще проверим интеграцията на данни с приложения на трети страни и ще проверим промените в базата данни в приложението.

След това ще направим системно тестване. Ще проверим цялото приложение като една единица. Ще проверим функционалността, интеграцията на страниците, проверките на полетата, съобщенията за грешки, съобщенията за потвърждение и много други.

Докато тестваме приложението, ще регистрираме проблемите в инструмента за проследяване на грешки. Ще дадем приоритет на грешката въз основа на проблемите. След създаването на грешката ще я възложим на съответния разработчик, за да отстрани проблема. Ще проверим грешките, след като разработчиците ги възложат на тестери, след като ги поправят. Ако работи добре, тестерът ще затвори грешката, в противен случай тестерите ще възложат обратно на разработчика, за да отстранят проблема. Ето как продължава жизненият цикъл на бъговете.

След това преминаваме към теста за приемане. Тук тестваме приложението в различни среди като постановка и UAT (потребителско тестване за приемане). Това е най-важната фаза за цялостно тестване на приложението, преди да преместим кода в производствената среда.

След като тестването за приемане бъде направено без грешки, клиентът ще планира да разположи кода на производствения сървър и да планира изданието.

# 6) Поддръжка

След като разположим кода на приложението на производствения сървър, трябва да предоставим поддръжката / поддръжката на клиентското приложение. Тази фаза на поддръжка е да се наблюдават и отстраняват производствените проблеми в реално време, да се проверяват проблемите с паметта, да се подобрява приложението и да се разработват новите промени в изискванията.

В кои случаи можем да изберем модела на водопада?

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

Плюсове за водопад:

• Напред назад планирането и изпълнението е лесно .
• Моделът на водопада е лесен за използване и лесен за разбиране. Не се изисква специално обучение за ръководители на проекти или служители. Той има лесна крива на обучение .
• Тъй като е твърд по природа, това е така лесен за управление цикъла на водопада. Всяка фаза има фиксирани резултати и процес на преглед.
• По-малко сложност тъй като фазите не се припокриват. Фазите се следват една след друга. Той използва ясна структура в сравнение с другите методологии за разработване на софтуер. Проектът преминава през фиксирани последователни стъпки, започвайки от събирането на изискванията и накрая се приземява при поддръжка.
• Поради поетапното развитие, налага се дисциплина , и графиците могат да бъдат запазени лесно.
• Върши работа добре за малки проекти където имаме фиксирани и кристално ясни изисквания.
• Процесите и резултатите са добре документирани .
• Подреждането на задачите е лесно.
• то е лесно да се измери напредъка тъй като началните и крайните точки на всяка фаза са предварително определени.
• Почти няма промяна в изискванията по време на проекта, следователно задачите остават стабилни за разработчиците. Също така е лесно за всеки нов разработчик за бързо учене и започнете работата.
• Има без финансови изненади . След като изискванията са фиксирани, крайният разход може да бъде изчислен преди започване на разработката.
• Обслужва за модел на последователно финансиране .
• Неговата детайлен дизайн прави крайния очакван резултат много ясен за всички.
• Спецификацията на функционалните изисквания, документирана във фазата на събиране на изисквания, дава достатъчно подробности на тестерите за проектиране на сценарии за тестване и тестови случаи. Следователно, процесът на тестване става лесен в модела на водопада.

Водопад против:

• Тъй като всички изисквания трябва да бъдат ясно известни преди започване на разработката, то забавя проекта .
• Изисква задълбочени изследвания в нуждите на потребителя.
• В началната фаза на проекта за клиента е предизвикателство ясно да дефинира и концептуализира своите изисквания под формата на функционални спецификации. Следователно има голяма възможност те да променят мнението си, след като видят крайния продукт. Тази промяна може да възникне и поради бизнес план или пазарно влияние. Ниската гъвкавост в този модел го прави трудно е да се приемат такива промени , особено когато продуктът трябва да бъде преработен до голяма степен.
• Няма работещ модел се произвежда до по късно етап по време на жизнения цикъл на водопада.
• Бавни срокове за доставка . Клиентът не може да види продукта, докато не бъде напълно завършен.
• Клиентът няма възможност да се запознае предварително със системата. Моделът на водопада е по-скоро вътрешен процес и поддържа крайния потребител изключен .
• The клиентът не е информиран добре за здравето на проекта.
• Срокове могат да бъдат пропуснати ако не се спазва стриктно управление и редовен мониторинг.
• Има няма място за промени дори и да е видим по време на разработката, тъй като продуктът няма да отговори на изискванията на пазара.
• Забавяне на тестване до след приключване. Освен това в този момент големите ревизии са много скъпи.
• Висок риск и несигурност участват в модела на водопада, тъй като има твърде много място за проблеми, които да останат незабелязани, докато проектът не се приближи до завършване.
• Не е подходящ модел за дълги, сложни и текущи проекти.
• Трудно е измерване на напредъка във всяка фаза.
• Тестерите ще стоят без работа по време на много етапи от проекта.

Agile Workflow

Сега ще видим жизнения цикъл на разработката на Agile Software. Agile е процесът на бързо и лесно извършване на работа с по-голяма точност.

Този модел е свързан с метод за управление на проекти, използван специално за разработване на софтуер. Характеризира се с разделяне на задачите на кратки фази на работа и често преоценяване и адаптиране на плановете. Всеки член на екипа трябва да има представа за основните бизнес потоци.

(изображение източник )

В Agile разработчиците и тестерите работят паралелно за разработване и тестване на приложния софтуер. Разработката се извършва в итеративен режим. Всяка итерация на потребителски истории изисква анализ, проектиране, кодиране и тестване.

Тестваме изискването по подробен начин, за да проверим дали изискването е без грешки и изпълнимо или не. Преминете към следваща итерация след края на всяка итерация и ние следваме същия процес към новите / други изисквания.

По този начин този процес на разработване и тестване на софтуерния блок се извършва за кратък период от време с повече точност и гъвкавост. Така че повече индустрии следват и възприемат този процес.

Първо, собственикът на продукта ще добави всички изисквания към изоставането на продукта. Натрупването на продукти съдържа всички потребителски истории. Да кажем, 100 до 150 потребителски истории са свързани с цялостния проект. Сега добавете конкретните потребителски истории към изоставането в спринта, което трябва да бъде приложено. След това всички разработчици, QA, BA ще работят по спринт елементите. Ето как работи Agile flow.

Основни терминологии, използвани в Agile

Какво е изоставането в спринта?

sql въпроси и отговори за опитни

Това е списъкът с потребителски истории, които трябва да приложим в текущата итерация или спринт.

Например, има 20 до 30 потребителски истории в изоставането в спринта. Тогава това са потребителските истории, които трябва да приложим в текущия спринт.

(изображение източник )

Какво е спринт?

Sprint е малката продължителност, в която трябва да внедрим избраните потребителски истории в рамките на определена продължителност. Продължителността на спринта ще бъде около 2 до 3 седмици. Продължителността му варира от компания до компания.

В тази продължителност на спринта екипът трябва да анализира изискването, да проектира изискванията, да извърши кодиране, тестване, отстраняване на проблема, повторно тестване, регресивно тестване, демонстрация и много други дейности.

Ежедневна среща за скрап на Standup

Бизнес анализаторът, разработчикът, тестерът, ръководителят на проекта са част от ежедневните срещи за изправяне. Прави се ежедневно. Не трябва да се удължава повече от 15 до 30 минути.

Тук всички членове на екипа ще споделят ежедневния работен статус. Основните неща, които обсъждаме тук, са: кои са нещата, завършени вчера, план за днешната работа и всички предизвикателства или зависимости, с които се сблъскват в проекта.

Ако някой член на екипа се сблъска с някакви предизвикателства или пречки по време на проекта, съответното лице ще работи по него, за да го направи.

Chartdown Chart

Това е изобразително графично представяне на времето и работата. Оста x представлява оставащата работа, оста y представлява остатъка от времето на спринта. Екипът трябва да създаде работните задачи относно времето, налично в конкретния спринт. Екипът ще изгаря часовете за задачи ежедневно въз основа на работата, която е работил и завършил.

(изображение източник )

Диаграма на Канбан

Това е диаграма / инструмент за управление на проекти. С това можем да управляваме задачите на целия проект. Можем да проверим състоянието на проекта и състоянието на работата на отделните лица. Той показва изобразителното цифрово представяне на напредничави елементи, предстоящи елементи, готови елементи.

(изображение източник )

Въпроси и отговори за интервю за mysql за 3-годишен опит

Планиране на покер дейност

Това е игра между членовете на спринт екипа за оценка на потребителските истории. Тук целият отбор ще играе покер дейност. Всеки член на екипа дава оценка въз основа на историята на потребителя. Въз основа на мнозинството оценителни гласове екипът ще реши и разпредели времевия интервал.

Например , един член на екипа на потребителската история ще даде оценка като 3, 5, 8, 3, 1, 3. Тогава екипът ще избере 3 като оценка. Картата за покер активност съдържа 0, 1, 3, 5, 8, 13, 20, 100, почивка, съмнения? карти. Въз основа на това членовете на екипа ще предложат всяка карта за оценка. По този начин ще изчислим всички потребителски истории, свързани с конкретния спринт.

(изображение източник )

• 0 покер номер представлява: няма задача в този елемент / потребителска история
• 1, 3 числа представляват: задачата е по-малка
• 5, 8 числа представляват: задачи на средно ниво
• 13, 20 число представлява: задачи от голямо ниво
• 100 число представлява: много големи задачи
• Безкрайността представлява: Задачата е огромна, трябва да се раздели на множество задачи и потребителски истории
• Break представлява: нужда от почивка
• ? Представлява: Съмнения

Scrum Master

Той е човекът, който помага на екипа да следва гъвкавия процес и да отговаря на изискванията на проекта. Той ще проведе срещата, когато е необходимо, и ще помогне да се обсъдят нуждите на проекта.

Scrum master действа като мост към всички членове на екипа за разрешаване на предизвикателствата и зависимостите, които попадат в проекта. Той ще проследи напредъка на проекта по отношение на всеки спринт.

Той участва в срещата за измерване, ретроспективна среща, проверка, преглед, демонстрация. Той е този, който провежда ежедневните срещи за изправяне и прави актуализация на членовете на екипа.

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

Той е човекът, който управлява и наблюдава продукта / проекта от бизнес гледна точка. Той продължава да гледа така, както продуктът е разработен според бизнес изискванията или не. Той е този, който дава приоритет на потребителските истории и е преместил изискванията от изоставането на продукта към изоставането в спринта. Той ще прецени крайните срокове на проекта.

Той винаги гледа на продукта от гледна точка на потребителя. Собственикът на продукта има пълни познания за това как трябва да работи приложението.

Потребителска история

Това е блок от изисквания. Той съдържа набор от случаи / изисквания за употреба, които са свързани със същия модул. Тук дефинираме как трябва да работи всеки компонент на приложение и как трябва да изглежда потребителският интерфейс. Обхватът на всеки компонент е дефиниран в потребителската история.

Задачи

Членовете на екипа ще създадат задачата за потребителската история, която им е възложена. Те трябва да създадат задачата въз основа на различни задачи като задача за разработка, задача за тестване, задача за анализ на историята на потребителя. Продължителността на задачата трябва да зависи от историята на потребителя.

Като тестер ще създадем задачите за анализ на потребителски истории, подготовка на тестови случаи, изпълнение, регресионно тестване и много други.

Поддържане на изоставане

Тази част включва управление на изоставащи елементи. Дейностите, които правим тук, са даване на приоритет на изоставащите елементи, разбиване на по-малки елементи, създаване на задачата и актуализиране на критериите за приемане.

Повторение

Итерацията е разработване и тестване на някои модули / части на софтуерното приложение. Всяка итерация се състои от анализ на продукта, дизайн на продукта, разработване на продукта, тестване на продукта и демонстрация на продукта.

Основни фактори за възприемане на гъвкава методология

• Наблюдение: Преглеждайте редовно работата и продукта и планирайте съответно дейностите. Така че процесът на разработване на продукта и качеството на продукта ще бъдат добри.
• Добре дошли промени: Промените се обработват много лесно. Това не засяга много продукта, тъй като модулите на софтуера се разработват отделно и се интегрират по-късно. Така че няма да има преработка, ако изискването бъде променено в бъдеще.
• Времева рамка: Дадени са ни времеви рамки за всяка единица от приложението. Така че оценката ще бъде точна по отношение на прогнозите за времето на проекта.
• Удовлетвореността на клиентите: Удовлетвореността на клиентите е повече, защото ние взаимодействаме с клиента и акционера по време на проекта и ще дадем демонстрация за всяко ниво на разработване на продукта. По този начин получаваме редовно отзиви от клиенти / клиенти за бизнес потоците и напредъка в работата. По този начин работата и разработването на приложението се извършват по съответния начин.

Видове гъвкави методологии

• Метод Agile Scrum
• Lean Software Development
• Канбан
• Екстремно програмиране (XP)
• Кристал
• Метод за развитие на динамични системи (DSDM)
• Разработено от функции (FDD)

Пъргави професионалисти:

• Едно от най-големите предимства на пъргавия модел е неговото голяма адаптивност . Адаптивността означава „реагиране на промяната“. Agile е много гъвкав при справяне с промените в нуждите и приоритетите на клиентите.
• Позволява да постоянно усъвършенствайте и приоритизирайте цялостното изоставане на продуктите без да се засяга текущата итерация, в която екипът е фокусиран върху предоставянето на MVP. Промените могат да бъдат планирани за следващата итерация, като по този начин се предлага възможност за въвеждане на промените само в рамките на няколко седмици.
• Agile методологията предлага голяма степен на ангажиране на заинтересованите страни . Клиентът и екипът на проекта се срещат преди, по време и след всеки спринт. Тъй като клиентът е постоянно ангажиран по време на проекта, има повече възможности екипът ясно да разбере визията на клиента.
• Работещият софтуер се доставя рано и често. Това увеличава доверието на заинтересованите страни в екипа и насърчава екипа да останете силно ангажирани към проекта.
• Този модел дава прозрачност . Както заинтересованите страни, така и екипът знаят добре за случващото се. Клиентът може да види текущата работа.
• Спринтовете с фиксиран график от една до четири седмици позволяват ранна и предсказуема доставка . Новите функции се пускат бързо и често по времеви начин.
• Agile е с внимание към клиента . Той не само предоставя функционалността, но също така се фокусира върху предоставянето на функцията, която има някаква стойност за потребителя. Всяка потребителска история има ориентиран към бизнеса критерий за приемане.
• Ценно обратна връзка от клиента се придобива рано в проекта и промени в продукта могат да бъдат направени според изискванията.
• Фокусът е върху бизнес стойността . Първо предоставя най-важното за клиента.
• Подобрява качеството на резултатите . За разлика от водопада, тестването се извършва непрекъснато и често в Agile проект и това от своя страна помага за ранното откриване и отстраняване на проблемите.
• Пъргав поддържа TDD (Test Driven Development) подход което осигурява достатъчно време за създаване на модулни тестове за функциите, които ще бъдат пуснати чрез MVP.
• Също така, чрез производство чести компилации , всяко несъответствие с изискванията на клиента също може да бъде открито и отстранено по-рано.
• Както получаваме незабавна обратна връзка с потребителя след всяко освобождаване на MVP, рискът от провал на проекта е нисък, когато работите по пъргав начин.
• Пъргав насърчава работата в екип . Има голямо сътрудничество, взаимодействие, хармония и ентусиазъм сред членовете на Agile екипа.
• Оценките на разходите и графика на всеки спринт се съобщават на клиента преди началото на спринта. Това подобрява вземането на решения тъй като потребителят може да разбере цената на всяка функция и съответно да даде приоритет.
• В един пъргав проект има място за непрекъснато усъвършенстване . Уроците, научени от изминалите спринтове, могат да бъдат приложени в предстоящите спринтове.
• Той се фокусира върху конкретната задача на всеки етап от проекта.

Agile минуси:

• Често се вижда, че Agile екипите имат a тенденция към пренебрегване на документацията . Това е така, защото манифестът Agile се фокусира повече върху работещия софтуер, отколкото изчерпателната документация. Екипите обаче трябва да поддържат правилния баланс между кода и документацията.
• Тъй като изисква висока степен на участие на клиентите, може понякога е проблематично за клиентите които нямат много време и интерес да участват в проекта.
• Не работи добре, ако на екипа липсва ангажираност и отдаденост. Водопадът изисква участие, но Agile изисква ангажираност.
• Ако първоначалната архитектура и дизайн са слаби, тогава често рефакторинг изисква се.
• В сравнение с водопада, Agile е трудно на практика . Членовете на екипа трябва да са добре запознати с Agile концепциите. Изисква се много дисциплина и ангажираност, за да се упражнява Agile.
• Поради повторното определяне на приоритетите е така по-малко предсказуем отколкото това, което ще бъде доставено в края на спринта.
• Поради доставената във времето доставка и честото повторно определяне на приоритетите има вероятност няколко функции да не бъдат доставени в определения график. Това може да доведе до допълнителни спринтове и допълнителни разходи . Това също може да доведе до проблема с мъгляви срокове .
• Липса на структура в сравнение с водопада изисква самодисциплинирани, високо квалифицирани и кръстосано квалифицирани екипи . Без това проектът наистина може да бъде предизвикателен.
• Наличността е по-малко от план на крайния резултат .
• Понякога външната заинтересована страна не може да устои на подхода на Agile . В такива случаи обучението и обучението за Agile се изискват от широка аудитория.
• Всички членове на екипа трябва да участват в управлението на проекта.
• Документацията е по-малко подробна.

Разлика между моделите Agile Vs Waterfall

Разликите между жизнения цикъл на Waterfall и Agile Software Development са изброени по-долу.

Водопад	Пъргав
Процесът се третира като един единствен проект, който допълнително се разделя на различни фази.	Процесът е разделен на множество проекти и всеки проект има итерация на различни етапи.
Методологията на водопада е модел, при който всеки етап от жизнения цикъл на продукта протича последователно. Напредъкът на проекта тече постепенно надолу през тези фази, наподобяващи водопад.	Agile методологията е модел, който следва итеративен подход.
Този модел вярва в еднократна масивна цялостна доставка. Продуктът се доставя в края на SDLC.	Този модел вярва в множество малки парчета доставка през определени интервали от време. В края на всеки спринт се доставя MVP (Минимален жизнеспособен продукт).
Това е традиционен и старомоден подход.	Това е нов и модерен подход.
Един единствен цикъл и едно издание.	Повтарящ се брой повторения и множество издания.
Той разделя жизнения цикъл на разработката на софтуер на различни фази.	Той разделя жизнения цикъл на разработката на софтуер на спринтове.
Структуриран и твърд модел. Трудно е да се променят описанието, спецификацията и дизайнът на проекта.	Този модел е известен със своята гъвкавост. Можем да правим промени във всяка фаза на проекта по всяко време.
Мащаб на дългосрочно планиране.	Мащаб на краткосрочното планиране.
Между клиента и предприемача съществува голямо разстояние.	Между клиента и предприемача съществува малко разстояние.
Дълго време между спецификация и изпълнение. Бизнес анализаторът събира и подготвя изискването преди началото на проекта.	Кратко време между спецификация и изпълнение. Собственикът на продукта подготвя изискванията и актуализира екипа във всеки спринт.
Отнема много време за откриване на проблеми.	Проблемите се откриват бързо.
Висок риск от графика на проекта.	Нисък риск от график на проекта.
По-малко способност за бързо реагиране на промените.	Висока способност за бързо реагиране на промените.
Фазата на тестване настъпва само след приключване на фазата на разработка.	Тестването обикновено се извършва паралелно с разработването, за да се гарантира непрекъснато качество.
Клиентът се включва само на фазата на събиране на изискванията и след това няма участие на клиента. Той се появява в картината само по време на доставката на продукта.	Клиентът е ангажиран по време на проекта и от клиента се получава обратна връзка от време на време, за да се гарантира удовлетвореността на клиента.
Подходящ за проекти, които имат ясно дефинирани изисквания и такива, които не очакват промени.	Подходящ за проекти, които трябва да се развият и такива, които включват променящи се изисквания.
Строго последователен процес.	Силно съвместният процес на разработка на софтуер води до по-добри усилия в екипа и бързо решаване на проблеми.
Излага мислене на проекта.	Въвежда продуктово мислене и по този начин е по-фокусиран върху клиентите. Изискванията и промените са част от процеса
Официално и йерархично. Ръководителят на проекта е този, който взема решения.	Това е неформално. Целият екип е отговорен за вземането на решения.
Този модел предвижда, че няма да има промени в изискванията по време на целия проект.	Този модел се основава на адаптация и обхваща промените.
Необходимо е да се създадат ръчни документи, за да се провери състоянието на работата на отделния човек и напредъка на проекта.	Следва диаграмата Kanban и Burn Down, за да провери напредъка на проекта и работния статус на индивида.

Имахме достатъчно дискусии за разликите между методологиите Agile & Waterfall и ползите и предизвикателствата на всяка от тях. Нека сега изследваме разликите между пъргавото тестване и тестването на водопад.

Разлики между пъргавото тестване срещу тестването на водопад

От гледна точка на софтуерното тестване, за нас е важно да имаме добра представа за това как Agile тестването се различава от тестването на водопад.

Заключение

В тази статия научихме точните разлики между съвременния Agile подход и традиционния метод Waterfall за разработване и тестване на софтуер с таблица за сравнение, обхващаща плюсовете и минусите на всеки модел.

Като разгледаме всички фактори, изброени в тази статия, можем да изберем правилния модел на жизнения цикъл на разработка на софтуер, за да разработим софтуерното приложение. Няма съмнение да се каже, че Agile методологиите са предпочитани пред модела Waterfall. 90% от компаниите предпочитат и следват Agile работния процес, за да разработят софтуерното приложение.

Agile методологията е добра за всякакви проекти. Много малко компании следват методологията на водопада. Тази методология е подходяща само ако приложението е малко, просто и няма промени в изискването.

В някои случаи избираме и други подходи, наречени Спирала, V и V и Прототип, въз основа на нуждите.

Надявам се, че тази информация ще ви бъде полезна, за да решите кой е най-добрият модел за вашия проект. Можете също така да изберете хибриден модел, премахващ минусите на всеки метод - обсъден тук.

Препоръчително четене

• Казус: Как да премахнем недостатъците на водопада и гъвкавите процеси на развитие с помощта на хибриден модел
• Какво е SDLC модел водопад?
• Преглед на инструмента за управление на тестове на Zephyr Enterprise - Как да използваме активите на модела на водопада в Agile Tool
• VersionOne Tutorial: Всичко в едно Agile Ръководство за инструменти за управление на проекти
• Урок за портфолио на Jira: Плъгин за управление на портфолио на Agile за JIRA (Преглед)
• ТОП 10 на най-добрите гъвкави инструменти за управление на проекти през 2021 г.
• Техники за пъргава оценка: Истинска оценка в гъвкав проект
• 4 стъпки към разработването на мисленето за гъвкаво тестване за успешен преход към гъвкав процес