Компјутерската индустрија е преполна со двосмислен јазик, груб жаргон и сложени идеи кои се тешко разбирливи и може да го испратат вашиот ум во бес на пресметковно баферирање.
Водопад? Scrum? Агилен?
Ако овие фрази ви се сосема туѓи, не грижете се; вашиот корисен тим од технолошки гикови од HashDork е тука да ви помогне да ги разберете разликите помеѓу овие клучни фази од процесот на развој за да можете да станете запознаени.
Техниките за агилни, скрум и водопад ќе бидат опфатени во овој блог пост, заедно со тоа како секоја може да му помогне на вашиот тим како целина.
Да почнеме со агилното, а останатите ќе ги носиме.
Што е агилно?
Агилниот развој на софтвер следи итеративен, постепен пристап. Наместо опсежна подготовка на почетокот на проектот, Agile техниките се флексибилни на променливите потреби со текот на времето и промовираат континуирани повратни информации од крајните корисници.
Вкрстените функционални тимови работат на повторувања на производи со текот на времето, а оваа работа е категоризирана во заостанати и приоритетни врз основа на вредноста на бизнисот или клиентот. Целта на секоја повторување е да создаде употреблив производ.
Лидерството промовира соработка, одговорност и комуникација лице в лице во методологиите Agile.
Деловните чинители и програмерите мора да соработуваат за да се осигураат дека производот ги задоволува барањата на потрошувачите и целите на компанијата.
Фразата „агилен развој“ се однесува на различни методи и рамки кои се засноваат на идеалите и начелата наведени во Агилен манифест.
Експертите советуваат да се придржувате до агилните принципи и вредности и да ги користите како водич за одлучување за правилните активности што треба да се преземат во одредена средина додека се приближувате до развој на софтвер.
Тимот за соработка и самоорганизирање се главните области на фокус на агилната заедница за развој на софтвер.
На тимовите им е дозволено самостојно да одлучуваат како ќе се справат со одреден проект, но тоа не значи дека супервизорите не постојат. Затоа, агилните тимови се вкрстено функционални.
Во агилна парадигма, менаџерите сè уште се неопходни. Тие се грижат секој член на тимот да ги има или да ги стекне потребните способности за проектот.
Менаџерите во агилна рамка работат така што негуваат атмосфера што го дава најдоброто во тимот. Но, наместо да го преземат водството, тие често застануваат на задното седиште и му дозволуваат на тимот да одлучи како ќе ги испорача работите.
Менаџерите се вклучуваат само кога тимовите постојано се обидуваат да ги решат проблемите без успех.
Циклус на агилен развој
Фазите на циклусот на развој на Agile се наведени подолу. Од клучно значење е да се запамети дека овие фази не треба да се одвиваат со ред бидејќи тие се флексибилни и постојано се менуваат. Многу од овие фази се одвиваат истовремено.
- Планирање: Откако проектниот тим одлучи дека идејата е практична и изводлива, тие почнуваат да бараат карактеристики. Оваа фаза има за цел да даде приоритет на секоја карактеристика и да ја додели на повторување откако ќе ја разложи идејата на помали работни парчиња (карактеристики).
- Анализа на барањата: За да се утврдат деловните барања, овој чекор повлекува неколку дискусии со менаџерите, засегнатите страни и корисниците. Кој ќе го користи производот и како ќе го користи се дел од деталите што тимот треба да ги собере. Овие стандарди мора да бидат специфични, применливи и квантитативни.
- дизајн: Барањата пронајдени во претходната фаза се користат за подготовка на дизајнот на системот и софтверот. Тимот мора да ги земе предвид изгледот на производот или решението. Стратегија или план за тестот исто така се развива од тимот за тестирање.
- Имплементација, кодирање или развој: Фокусот на оваа фаза е на градење и евалуација на карактеристиките и планирање на распоредувањето на повторувањата (следејќи го итеративниот и инкременталниот развојен пристап [IID]). Бидејќи нема обезбедени функции, започнува повторувањето 0 на периодот на развој. Со завршување на активности како склучување договори, поставување поставки и финансирање, оваа повторување ја обезбедува основата за идниот раст.
- Тестирање: Откако кодот е креиран, тој се тестира според барањата за да се осигура дека производот навистина ги задоволува барањата на корисниците и ги исполнува деловните цели. Тестирањето на единицата, интеграцијата, системот и прифатливоста се спроведуваат во оваа фаза.
- распоредување: По тестирањето, производот се испраќа до клиентите за да можат да го користат. Сепак, проектот не е завршен по распоредувањето. Клиентите може да наидат на дополнителни проблеми откако ќе почнат да го користат производот, за што ќе треба проектниот тим да најде решение.
Предности
- Побрза, поквалитетна испорака: Со разложување на проектот на повторувања (управливи единици), тимот може да се концентрира на поквалитетна соработка, развој и тестирање. Кога тестирањето се прави со секое повторување, проблемите се наоѓаат и поправаат побрзо. Дополнително, со постојани, последователни ревизии, овој висококвалитетен софтвер може да се испорачува побрзо.
- Промената е добредојдена: Иако циклусите на планирање се пократки, едноставно е да се прифатат и да се приспособат промените во која било точка од проектот. Заостанатиот заостаток секогаш може да се подобри и да се реприоритизира, дозволувајќи им на тимовите да направат промени во проектот за неколку недели.
- Може да не се знае крајната цел: Agile е одличен за проекти кога крајната цел не е јасно дефинирана. Како што проектот се движи понатаму, целите ќе станат јасни, а развојот ќе може лесно да ги задоволи овие променливи потреби.
- Континуирано подобрување: Агилните програми го промовираат внесувањето на корисникот и тимот во сите фази на проектот, овозможувајќи примена на наученото за подобро следно повторување.
- Мислењата на клиентите се ценети: Има неколку можности клиентите да гледаат како се завршува работата, да понудат повратни информации и навистина да влијаат на конечниот резултат. Со толку интимна интеракција со проектниот тим, тие би можеле да развијат чувство на сопственост.
- Силна тимска работа: Agile го нагласува значењето на редовната комуникација и средбите во лице. Луѓето можат да преземат одговорност и да поседуваат одредени компоненти на проектот кога работат во тимови.
Недостатоци
- Членовите на тимот мора да имаат знаењед: Агилните тимови често се мали. Така, членовите на тимот мора да имаат широк опсег на вештини. Дополнително, тие мора да разберат и да се чувствуваат удобно користејќи ја избраната Агилна техника.
- Планирањето може да биде помалку прецизно: Повремено може да биде предизвик да се одреди точниот датум на испорака. Agile е изграден на испорака во временски рамки, а проект менаџерите често ги преуредуваат приоритетите на задачите. Така, веројатно е дека некои од испораките кои првично беа планирани за испорака нема да бидат завршени навреме. Дополнително, може да се додадат повеќе спринтови во кој било момент во текот на проектот, со што се продолжува целиот распоред.
- Документацијата може да се занемари: Некои членови на тимот можеби веруваат дека концентрирањето на документацијата е помалку клучно бидејќи Agile Manifesto го фаворизира работниот софтвер над темелната документација. Агилните тимови треба да постигнат идеална рамнотежа помеѓу документацијата и дијалогот, иако темелната документација не може сама да гарантира успех на проектот.
- Конечниот излез може многу да се разликува: Можеби немаше јасна стратегија за почетниот проект Agile, и затоа готовиот исход може многу да се смени од она што прво се очекуваше. Значително различен финален излез може да произлезе од додавање нови повторувања засновани на промена на влезот на клиентот, бидејќи Agile е толку прилагодлив.
- Временска посветеност на програмерите: Развојниот тим мора да биде целосно посветен на проектот за агилен да биде ефективен. Агилниот метод, кој трае подолго од конвенционалниот пристап, бара постојано активно учество и соработка. Дополнително, тоа имплицира дека програмерите мора да се посветат на целата должина на проектот.
Што е водопад?
Најпопуларната итерација на животниот циклус на развојот на системот (SDLC) за софтверско инженерство и ИТ проекти е позната како „пристап на водопад“, кој следи секвенцијална, линеарна процедура.
Гант-табела, форма на столбест дијаграм што ги прикажува датумите на почеток и крај на секоја работа, повремено се користи за нејзино планирање.
Развојниот тим напредува на следното ниво откако ќе заврши една од осумте фази. Тимот не може да се врати во претходната фаза без да мора да ја рестартира целата процедура.
Дополнително, клиентот можеби ќе треба да ги оцени и прифати барањата пред тимот да оди на следното ниво.
Моделот на водопад беше развиен во високо организирани средини на производствениот и градежниот сектор, каде што прилагодувањата може да бидат премногу скапи или дури и невозможни.
Техниката на водопад е наречена така затоа што е наменета да тече во само една насока - надолу - исто како водопад. Неговите фази вклучуваат анализа, започнување, тестирање, проектирање, градење, распоредување, одржување и тестирање.
Техниката на водопад има неколку предности, исто како и секоја друга стратегија. Една од нив е дека фазите на планирање и дизајнирање на проекти се повеќе добро воспоставени.
Клиентите и тимот за развој се повеќе усогласени кога станува збор за испораките на проекти додека користат развој на софтвер водопад. Бидејќи сте свесни за опсегот на проектот од самиот почеток, развојот на водопади исто така го олеснува следењето на напредокот.
Процесот на водопад користи специјалисти, програмери, аналитичари и тестери за да се концентрираат на нивните работни места во проектот наместо целиот тим да нагласи еден чекор.
Фази на водопад
Шесте чекори на водопадот мора да се случат еден по друг:
- Барања за собирање и складирање: Треба да соберете темелно знаење за тоа што бара овој проект во овој момент. Постојат неколку техники за собирање на овие податоци, вклучувајќи интервјуа, анкети и заедничко бреинсторминг. Потребите на проектот треба да бидат очигледни до завршувањето на оваа фаза, а вашиот тим треба да добие копија од документот за барања.
- Дизајн на системот: Системот е дизајниран од вашиот тим користејќи однапред одредени спецификации. Во текот на оваа фаза, не се прави кодирање, но тимот поставува барања за хардвер или програмски јазик.
- Имплементација: Оваа фаза вклучува кодирање. Податоците од претходната фаза се користат од програмерите за да изградат употреблив производ. Кодот често се имплементира во мали делови кои се комбинираат на крајот на една фаза или на почетокот на друга.
- Тестирање: Производот може да почне да се тестира откако ќе се заврши кодот. Сите проблеми се прецизно пронајдени и пријавени од тестерите. Вашиот проект можеби ќе треба да се врати во првата фаза за реевалуација доколку се појават значителни проблеми.
- Испорака/распоредување: Производот е готов во овој момент, а вашиот тим ги доставува испораките за распоредување или ослободување.
- Одржување: Клиентот го добил производот и го користи. Вашиот тим можеби ќе треба да развие поправки и ажурирања кога ќе се појават проблеми за да ги поправи. Повторно, значителни проблеми може да бараат враќање на првиот чекор.
Предности
- Едноставен за ракување и управување: Пристапот Waterfall е едноставен за користење и разбирање бидејќи секој проект се постапува на ист последователен начин. Пред да започне проектот „Водопад“, од тимот не се бара претходна експертиза или обука. Пристапот на водопадот е многу строг; секоја фаза има збир на резултати и преглед, што го прави едноставно да се администрира и одржува.
- Потребна е добро документирана методологија: Документацијата што ја бара методологијата за водопад помага да се разјасни резонирањето зад тестовите и кодот. Дополнително, тој создава хартиена трага во случај засегнатите страни да сакаат дополнителни информации за одредена фаза или за какви било идни иницијативи.
- Спроведување на дисциплина: Секој чекор во проектот за водопад има почеток и крај, што го прави едноставно да се комуницира напредокот со засегнатите страни и клиентите. Тимот може да ја намали можноста за пропуштање на краен рок со ставање на барањата и дизајнот на прво место пред да произведе код.
Недостатоци
- Може да биде тешко да се соберат прецизни барања: Разговорот со потрошувачите и засегнатите страни за да се утврдат нивните потреби е една од почетните фази на проектот „Водопад“. Во оваа рана фаза на проектот, можеби е предизвик да се утврдат нивните посебни барања. Клиентите често учат за нивните барања додека се развива проектот, наместо да ги изразуваат однапред.
- Промените тешко се прифаќаат: Екипажот не може да продолжи со работа откако ќе заврши фаза. Многу е тешко и скапо да се вратите назад и да го поправите ако во фазата на тестирање дознаат дека функционалноста недостасувала за време на процесот на барања.
- Софтверот се обезбедува по датумот на доспевање: Мора да се завршат две до четири фази од проектот пред да започне вистинското кодирање. Како резултат, заинтересираните страни нема да видат функционален софтвер до доцна во животниот циклус.
Што е Scrum?
Една од најомилените процесни рамки за спроведување на Agile во пракса е Scrum, која е подгрупа на Agile.
Тоа е итеративна парадигма за управување со создавање комплексен софтвер и производи. Спринтовите, кои се повторувања со фиксна должина што траат една до две недели, му овозможуваат на тимот да објавува софтвер по редовен распоред.
Засегнатите страни и членовите на тимот се собираат за да разговараат за следните чекори по секој спринт. Улогите, одговорностите и состаноците во Scrum остануваат постојани.
На пример, Scrum го специфицира спринтското планирање, дневниот стенд-ап, спринт демо и спринт ретроспективата како четирите ритуали кои ја обезбедуваат секоја структура на спринт.
Тимот ќе користи визуелни артефакти како табли со задачи или табели за изгореници за време на секој спринт за да демонстрира напредок и да добива поединечни повратни информации.
Во scrum, тимот и сопственикот на производот тесно соработуваат за да ја идентификуваат и да им дадат приоритет на функционалноста на системот. Тие го постигнуваат ова со создавање на заостанат производ, кој ги содржи сите задачи неопходни за производство на софтвер кој функционира како што е планирано.
Закрпи за грешки, нефункционални барања и функции треба да бидат вклучени во редот. Крос-функционалните тимови мора да проценат и да се пријават за да испорачаат софтверски зголемувања во текот на континуираните спринтови, кои обично траат 30 дена, откако ќе се утврдат целите.
Само тимот може да додаде функционалност на Спринтот откако ќе го изврши заостанатото за тој спринт.
Следна испорака на Спринт, заостанатите производи се проценуваат и, доколку е потребно, се реприоритизираат, а следниот сет на испорака е избран да биде дел од следниот спринт.
Scrum процес
- Заостанати производи: За да ги нарачате ставките во заостанатиот производ, Сопственикот на производот и тимот на Scrum се среќаваат (работата на заостанатиот производ доаѓа од приказните и барањата на корисниците). Заостанатиот производ е список на сите посакувани карактеристики за производот наместо список на задачи што треба да се завршат. После тоа, тимот за развој избира задачи од заостанатите производи за извршување во текот на секој спринт.
- Планирање на спринт: Пред секој спринт, Сопственикот на производот му ги доставува на тимот главните ставки од заостанатите на состанок за планирање на спринт. Групата потоа избира ставки од заостанатиот производ што може да ги заврши за време на спринтот и ги преместува во заостанатиот спринт (што е листа на задачи што треба да се завршат во спринтот).
- Усовршување/средување на заостанатите: Со цел да се осигура дека заостанатиот дел е подготвен за следниот спринт, тимот и сопственикот на производот се среќаваат на крајот на еден спринт. Тимот може да ги отфрли корисничките приказни кои повеќе не се релевантни, да додава нови, да го ревидира редоследот по кој треба да се решаваат или да ги подели корисничките приказни на помали задачи. За време на овој состанок за „средување“, ќе се погрижи заостанатиот дел да содржи само работи што се релевантни, длабински и во согласност со целите на проектот.
- Scrum состаноци секој ден: На 15-минутниот стенд-ап состанок наречен Daily Scrum, секој член на тимот разговара за своите цели и за сите проблеми што се појавиле. Секој ден во текот на спринтот, тимот учествува во Daily Scrum, кој ги држи сите на задача.
- Состанок за проценка на спринотt: Тимот ја презентира својата работа на состанок за преглед на спринт на крајот од секој спринт. Наместо извештај или PowerPoint презентација, овој состанок треба да содржи вистинска демонстрација.
- Ретроспективна спринтерска средба: Тимот дискутира за какви било модификации што треба да се направат во следниот спринт, како и за тоа колку добро Scrum работи за нив на крајот на секој спринт. Тимот може да разговара за позитивните аспекти на спринтот, негативните аспекти и областите за подобрување.
Предности
- Повеќе одговорност од тимот: Не постои проектен менаџер кој му дава инструкции на тимот на scrum што да прави и кога. Работата што може да се заврши во секој спринт наместо тоа ја решава тимот како целина. Сите тие соработуваат и си пружаат рака еден на друг, подобрувајќи ја тимската работа и негувајќи ја индивидуалноста кај секој член на тимот.
- Подобрена видливост и транспарентност на проектот: Има помалку недоразбирања и несигурност бидејќи сите во тимот се свесни за своите одговорности благодарение на честите стенд-ап состаноци. Тимот може да се справи со проблемите пред тие да излезат од контрола бидејќи проблемите се забележани однапред.
- Засилени намалувања на трошоците: Постојаната комуникација го информира тимот за какви било проблеми или промени веднаш штом ќе се случат, што помага да се заштедат трошоци и да се подобри квалитетот. Помалите делови од функциите обезбедуваат постојана повратна информација и овозможуваат рана корекција на грешките пред поголемите грешки да станат прескапи за отстранување.
- Едноставно се прилагодува на промените: Поедноставно е да се справите и да се приспособите на промените кога има чести циклуси на повратни информации и кратки спринтови. Како илустрација, ако тимот наиде на сосема нова корисничка приказна за време на еден спринт, тие можат брзо да ја додадат таа карактеристика на следниот спринт на состанокот за префинетост на заостанатите работи.
Недостатоци
- Опсег лази опасност: Поради недостиг на одреден датум за завршување, одредени проекти на Scrum може да се соочат со лази на опсегот. Засегнатите страни би можеле да бидат наведени да продолжат да бараат повеќе функции доколку нема краен рок за завршување.
- Лошиот Scrum Master може да исфрли се од колосек: Проект менаџер не е исто што и scrum master. Scrum Master мора да му верува на тимот што го надгледуваат и никогаш да не им дава инструкции. Scrum Master нема моќ над тимот. Проектот ќе пропадне ако мајсторот за скрум се обиде да управува со тимот.
- Проблемите со точноста може да произлезат од лошо наведени задачи: Ако задачите не се јасно наведени, трошоците и распоредот на проектот нема да бидат точни. Планирањето станува предизвик и спринтовите може да траат подолго од предвиденото доколку не се дефинираат првичните цели.
- Искуството и посветеноста се неопходни за тимот: За тимот да биде успешен, улогите и должностите мора да бидат јасно дефинирани. Тимот на Scrum бара членови на тимот со технички вештини бидејќи нема јасно дефинирани улоги (сите прават сè). Тимот, исто така, мора да се обврзе да учествува во дневните сесии на Scrum и да се држи заедно до крајот на животот на проектот.
Agile Vs Scrum
Иако Agile и Scrum ја користат истата методологија, постојат некои варијации помеѓу двете. Agile Manifesto прикажува збир на принципи за создавање софтвер преку итеративен развој.
Scrum, од друга страна, е збир на насоки до кои мора да се придржувате додека правите развој на софтвер Agile. Agile е концепт, додека Scrum е техника за негово спроведување во пракса.
Scrum е метод за имплементација на Agile, затоа и двајцата имаат многу заеднички работи. И двата пристапа се повторувачки, даваат приоритет на раната и честа испорака на софтвер и прифаќаат промени. Тие исто така ја поддржуваат отвореноста и тековниот развој.
Агилен против водопад
Круто наспроти флексибилно најдобро ги опишува разликите помеѓу процесот на Водопад и Агил. Додека Agile е флуиден и постојано се менува, Waterfall е многу построга, поригидна методологија.
Овие понатамошни разлики меѓу нив се како што следува:
- Agile не бара линеарен пристап, додека Waterfall е секвенцијален.
- Додека потребите често се однапред дефинирани во проектите на Waterfall, тие се очекува да се променат и прилагодат во иницијативите Agile.
- За разлика од Agile, проектите на Waterfall не дозволуваат да се направат модификации на работата што е завршена во претходна фаза.
- Водопадот е организирана процедура во која мора да го завршите секој чекор пред да продолжите на следниот. Сепак, Agile е флексибилна методологија која ви овозможува да продолжите со проектот со свое темпо.
Agile Vs Waterfall Vs Scrum
- Водопадот ја зголемува довербата во она што ќе биде обезбедено многу брзо откако ќе биде планирано. Agile се потпира на најдобрите практики на развојната средина. Овде, голем број проектни ризици може добро да се менаџираат бидејќи резултатите постојано се оценуваат.
- Водопад не предвидува дека тимот и проектот ќе бидат со седиште на истата локација. Додека скрам и агилен имаат потреба од колокација на вработени.
- Agile се фокусира на намалување на преработката на проектот и охрабрува промените да се инкорпорираат многу порано. За разлика од водопадот, кој реагира различно, scrum исто така овозможува рано откривање на промените.
- Покомпактен план за финалниот производ е овозможен со агилен и скрум. Ова создава проблем со ветувањата дадени на купувачот. Спротивно на тоа, графиката за водопад им дава на клиентите и на програмерите подобар впечаток за готовиот резултат.
- Секоја од овие техники има збир на алатки за организирање и симулирање на задачите вклучени во нивното создавање.
Заклучок
Ако сте следеле досега и сте сигурни во вашето знаење за разликите помеѓу процесите Waterfall, Agile и Scrum, веќе треба да знаете која стратегија ќе работи најдобро за вас и вашиот тим.
Техниката „Водопад“, која е наменета за проекти со дефинитивен опсег, временска рамка и буџет, може да биде вашата најдобра опција ако сакате тешки правила и процедури и сметате дека тие даваат јасност.
Од друга страна, ако слободата и приспособливоста што ги нуди Agile ве инспирираат, тоа би можело да биде местото каде што треба да го посветите вашето внимание.
Scrum е начин да се оди, сепак, ако сакате малку дисциплина во флексибилна рамка.
Сепак, мора да ги земете предвид овие пристапи во светлината на проектот на кој работите и вашиот конечен исход.
Оставете Одговор