Камп'ютэрная індустрыя багата неадназначнай мовай, грубым жаргонам і складанымі ідэямі, якія цяжка зразумець і могуць прывесці ваш розум да вар'яцтва вылічальнай буферызацыі.
Вадаспад? Scrum? Спрытны?
Калі гэтыя фразы вам зусім чужыя, не хвалюйцеся; ваша паслужлівая каманда тэхналогіяў HashDork тут, каб дапамагчы вам зразумець адрозненні паміж гэтымі важнымі этапамі працэсу распрацоўкі, каб вы маглі стаць дасведчанымі.
Тэхнікі аджыву, схваткі і вадаспаду будуць разгледжаны ў гэтым паведамленні ў блогу разам з тым, як кожны з іх можа дапамагчы вашай камандзе ў цэлым.
Пачнем з аджылі, а астатняе працягнем.
Што такое Agile?
Спрытная распрацоўка праграмнага забеспячэння прытрымліваецца ітэрацыйнага, паступовага падыходу. Замест шырокай падрыхтоўкі ў пачатку праекта метады Agile гнуткія ў адпаведнасці з патрэбамі, якія змяняюцца з цягам часу, і спрыяюць пастаяннай зваротнай сувязі з канчатковымі карыстальнікамі.
Міжфункцыянальныя групы працуюць над ітэрацыямі прадукту з цягам часу, і гэтая праца класіфікуецца ў адставанні і расстаўляецца па прыярытэтах у залежнасці ад каштоўнасці для бізнесу або кліента. Мэта кожнай ітэрацыі - стварыць карысны прадукт.
Лідэрства спрыяе супрацоўніцтву, адказнасці і зносінам тварам да твару ў метадалогіях Agile.
Зацікаўленыя бакі бізнесу і распрацоўшчыкі павінны супрацоўнічаць, каб пераканацца, што прадукт адпавядае патрабаванням спажыўцоў і мэтам кампаніі.
Фраза «спрытная распрацоўка» адносіцца да мноства метадаў і структур, заснаваных на ідэалах і прынцыпах, выкладзеных у Спрытны маніфест.
Эксперты раяць прытрымлівацца гнуткіх прынцыпаў і каштоўнасцей і выкарыстоўваць іх у якасці кіраўніцтва для вызначэння правільных дзеянняў у пэўным асяроддзі пры падыходзе да распрацоўкі праграмнага забеспячэння.
Сумесная і самаарганізаваная каманда з'яўляюцца асноўнымі сферамі ўвагі супольнасці гнуткіх распрацоўшчыкаў праграмнага забеспячэння.
Камандам дазваляецца самастойна вырашаць, як яны будуць займацца тым ці іншым праектам, але гэта не значыць, што наглядчыкаў не існуе. Такім чынам, спрытныя каманды шматфункцыянальныя.
У гнуткай парадыгме менеджэры па-ранейшаму неабходныя. Яны сочаць за тым, каб кожны член каманды меў або набываў неабходныя здольнасці для праекта.
Менеджэры ў гнуткай структуры працуюць, спрыяючы атмасферы, якая прыносіць лепшае ў камандзе. Але замест таго, каб браць на сябе ініцыятыву, яны часта адыходзяць на другі план і дазваляюць камандзе вырашаць, як яны будуць выконваць задачы.
Менеджэры ўцягваюцца толькі тады, калі каманды беспаспяхова спрабуюць вырашыць праблемы.
Спрытны цыкл распрацоўкі
Этапы цыкла распрацоўкі Agile пералічаны ніжэй. Вельмі важна памятаць, што гэтыя этапы не павінны адбывацца па парадку, таму што яны гнуткія і пастаянна мяняюцца. Многія з гэтых этапаў адбываюцца адначасова.
- Планаванне: Пасля таго як каманда праекта вырашыла, што ідэя практычная і працаздольная, яны пачынаюць шукаць асаблівасці. Гэты этап накіраваны на расстаноўку прыярытэтаў кожнай функцыі і прызначэнне яе для ітэрацыі пасля разбіцця ідэі на больш дробныя часткі (функцыі).
- Аналіз патрабаванняў: Каб вызначыць бізнес-патрабаванні, гэты крок цягне за сабой некалькі абмеркаванняў з кіраўнікамі, зацікаўленымі бакамі і карыстальнікамі. Хто будзе выкарыстоўваць прадукт і як яны будуць ім карыстацца, адносяцца да дэталяў, якія каманда павінна сабраць. Гэтыя стандарты павінны быць канкрэтнымі, прыдатнымі і колькаснымі.
- дызайн: Патрабаванні, знойдзеныя на папярэднім этапе, выкарыстоўваюцца для падрыхтоўкі сістэмы і дызайну праграмнага забеспячэння. Меркаванні для знешняга выгляду прадукту або рашэння павінны быць зроблены камандай. Стратэгія або план тэсту таксама распрацоўваецца камандай тэсціравання.
- Укараненне, кадзіраванне або распрацоўка: У цэнтры ўвагі гэтага этапу - стварэнне і ацэнка функцый і планаванне разгортвання ітэрацый (прытрымліваючыся падыходу ітэратыўнай і паступовай распрацоўкі [IID]). Паколькі функцый не прадастаўляецца, пачынаецца ітэрацыя 0 перыяду распрацоўкі. Завяршаючы такія мерапрыемствы, як заключэнне кантрактаў, наладжванне налад і фінансаванне, гэтая ітэрацыя забяспечвае аснову для будучага росту.
- Тэставанне: Пасля таго, як код быў створаны, ён тэстуецца на адпаведнасць патрабаванням, каб гарантаваць, што прадукт сапраўды задавальняе патрабаванні карыстальнікаў і адпавядае бізнес-мэтам. На гэтым этапе праводзяцца модульныя, інтэграцыйныя, сістэмныя і прымальныя тэсты.
- разгортванне: Пасля тэсціравання прадукт адпраўляецца кліентам, каб яны маглі яго выкарыстоўваць. Аднак пасля разгортвання праект не завершаны. Кліенты могуць сутыкнуцца з дадатковымі праблемамі пасля таго, як яны пачнуць выкарыстоўваць прадукт, для вырашэння якіх спатрэбіцца група праекта.
перавагі
- Больш хуткая і якасная дастаўка: Разбіўшы праект на ітэрацыі (кіраваныя адзінкі), каманда можа засяродзіцца на больш якасным супрацоўніцтве, распрацоўцы і тэсціраванні. Калі тэставанне праводзіцца з кожнай ітэрацыяй, праблемы выяўляюцца і выпраўляюцца хутчэй. Акрамя таго, пры пастаянных наступных пераглядах гэта высакаякаснае праграмнае забеспячэнне можа быць пастаўлена хутчэй.
- Змены вітаюцца: Нягледзячы на тое, што цыклы планавання карацейшыя, лёгка прыняць і ўнесці змены ў любы момант праекта. Бэклог заўсёды можна палепшыць і змяніць прыярытэты, дазваляючы камандам уносіць змены ў праект за пару тыдняў.
- Канчатковая мэта можа быць невядомая: Agile выдатна падыходзіць для праектаў, калі канчатковая мэта дакладна не вызначана. Па меры прасоўвання праекта мэты стануць яснымі, і распрацоўка зможа лёгка задаволіць гэтыя зменлівыя патрэбы.
- Пастаяннае ўдасканаленне: Праграмы Agile спрыяюць уводу карыстальнікаў і каманд на ўсіх этапах праекта, дазваляючы прымяняць тое, што вывучана, для лепшай наступнай ітэрацыі.
- Меркаванне кліентаў цэніцца: Ёсць некалькі магчымасцей для кліентаў назіраць за выкананнем працы, прапаноўваць зваротную сувязь і сапраўды ўплываць на канчатковы вынік. Так цесна ўзаемадзейнічаючы з камандай праекта, яны могуць развіць пачуццё ўласнасці.
- Моцная камандная праца: Agile падкрэслівае важнасць рэгулярнага зносін і асабістых сустрэч. Людзі могуць браць на сябе адказнасць і валодаць пэўнымі кампанентамі праекта пры працы ў камандзе.
недахопы
- Члены каманды павінны мець ведыe: Каманды Agile часта невялікія. Такім чынам, члены каманды павінны валодаць шырокім спектрам навыкаў. Акрамя таго, яны павінны разумець і адчуваць сябе нязмушана, выкарыстоўваючы выбраную тэхніку Agile.
- Планаванне можа быць менш дакладным: час ад часу можа быць складана вызначыць дакладную дату дастаўкі. Agile заснаваны на дастаўцы ў абмежаванні па часе, і кіраўнікі праектаў часта перастаўляюць прыярытэты задач. Такім чынам, ёсць верагоднасць таго, што некаторыя з першапачаткова запланаваных да пастаўкі вынікаў не будуць выкананы своечасова. Акрамя таго, больш спрынтаў можа быць дададзена ў любы момант на працягу ўсяго праекта, падаўжаючы ўвесь графік.
- Дакументацыю можна не ўлічваць: Некаторыя члены каманды могуць паверыць, што канцэнтрацыя на дакументацыі менш важная, паколькі Agile Manifesto аддае перавагу працоўнаму праграмнаму забеспячэнню, а не грунтоўнай дакументацыі. Спрытныя каманды павінны знайсці ідэальны баланс паміж дакументацыяй і дыялогам, нават калі дбайная дакументацыя сама па сабе не можа гарантаваць поспех праекта.
- Канчатковы вынік можа моцна адрознівацца: Магчыма, не было дакладнай стратэгіі для першапачатковага Agile-праекта, і таму канчатковы вынік можа значна адрознівацца ад таго, што першапачаткова чакалася. Істотна іншы канчатковы вынік можа быць атрыманы ў выніку дадання новых ітэрацый на аснове змены ўводу кліента, паколькі Agile вельмі адаптыўны.
- Часовыя абавязацельствы распрацоўшчыкаў: Каманда распрацоўшчыкаў павінна быць цалкам адданая праекту, каб agile быў эфектыўным. Метад Agile, які займае больш часу, чым звычайны падыход, патрабуе пастаяннага актыўнага ўдзелу і супрацоўніцтва. Акрамя таго, гэта азначае, што распрацоўшчыкі павінны ўзяць на сябе абавязацельствы па поўнай працягласці праекта.
Што такое вадаспад?
Самая папулярная ітэрацыя жыццёвага цыкла распрацоўкі сістэмы (SDLC) для распрацоўкі праграмнага забеспячэння і ІТ-праектаў вядомая як "падыход вадаспаду", які прытрымліваецца паслядоўнай лінейнай працэдуры.
Дыяграма Ганта, форма гістаграмы, якая адлюстроўвае даты пачатку і заканчэння кожнай працы, часам выкарыстоўваецца для яе планавання.
Каманда распрацоўшчыкаў пераходзіць на наступны ўзровень пасля завяршэння адной з васьмі фаз. Каманда не можа вярнуцца да папярэдняй стадыі без перазапуску ўсёй працэдуры.
Акрамя таго, кліенту можа спатрэбіцца ацаніць і прыняць патрабаванні, перш чым каманда зможа перайсці на наступны ўзровень.
Мадэль вадаспаду была распрацавана ў высокаарганізаваных умовах прамысловага і будаўнічага сектараў, дзе карэкціроўкі могуць быць занадта дарагімі ці нават немагчымымі.
Тэхніка вадаспаду названа так таму, што яна павінна цячы толькі ў адным кірунку - уніз - гэтак жа, як вадаспад. Яго этапы ўключаюць аналіз, пачатак, тэставанне, праектаванне, будаўніцтва, разгортванне, тэхнічнае абслугоўванне і тэсціраванне.
Тэхніка вадаспаду мае некалькі пераваг, як і любая іншая стратэгія. Адным з іх з'яўляецца тое, што этапы планавання і праектавання праекта з'яўляюцца больш устоянымі.
Заказчыкі і каманда распрацоўшчыкаў больш узгодненыя, калі справа даходзіць да вынікаў праекта пры выкарыстанні каскаднай распрацоўкі праграмнага забеспячэння. Паколькі вы з самага пачатку ведаеце аб'ём праекта, распрацоўка вадаспаду таксама палягчае маніторынг прагрэсу.
Працэс вадаспаду выкарыстоўвае спецыялістаў, распрацоўшчыкаў, аналітыкаў і тэсціроўшчыкаў, каб засяродзіцца на сваёй працы ў праекце, а не ўся каманда падкрэслівае адзін крок.
Этапы вадаспаду
Усе шэсць этапаў вадаспаду павінны адбывацца адзін за адным:
- Патрабаванні да збору і захоўвання: Вы павінны назапасіць грунтоўныя веды аб тым, што гэты праект патрабуе ў гэты час. Ёсць некалькі метадаў збору гэтых даных, у тым ліку інтэрв'ю, апытанні і сумесныя мазгавыя штурмы. Патрэбы праекта павінны быць відавочныя да моманту завяршэння гэтага этапу, і ваша каманда павінна атрымаць копію дакумента з патрабаваннямі.
- Дызайн сістэмы: Сістэма распрацавана вашай камандай з выкарыстаннем загадзя вызначаных спецыфікацый. На гэтым этапе кадзіраванне не праводзіцца, але каманда ўсталёўвае патрабаванні да апаратнага забеспячэння або мовы праграмавання.
- Рэалізацыя: Гэты этап уключае кадзіраванне. Дадзеныя папярэдняга этапу выкарыстоўваюцца праграмістамі для стварэння карыснага прадукту. Код часта рэалізуецца невялікімі часткамі, якія аб'ядноўваюцца ў канцы адной фазы або ў пачатку другой.
- Тэставанне: Прадукт можна пачынаць тэсціраваць пасля завяршэння кода. Усе праблемы старанна выяўляюцца і паведамляюцца тэсціроўшчыкамі. Магчыма, вашаму праекту спатрэбіцца вярнуцца да першай фазы для пераацэнкі, калі выявяцца сур'ёзныя праблемы.
- Дастаўка/разгортванне: Прадукт на дадзены момант скончаны, і ваша каманда адпраўляе вынікі для разгортвання або выпуску.
- тэхнічнае абслугоўванне: Кліент атрымаў прадукт і выкарыстоўвае яго. Вашай камандзе можа спатрэбіцца распрацаваць выпраўленні і абнаўленні, калі выяўляюцца праблемы, каб іх выправіць. Зноў жа, значныя праблемы могуць запатрабаваць вяртання да першага кроку.
перавагі
- Просты ў эксплуатацыі і кіраванні: Падыход Waterfall просты ў выкарыстанні і разуменні, паколькі кожны праект апрацоўваецца аднолькава паслядоўна. Перш чым пачаць праект Waterfall, каманда не абавязана мець ніякіх папярэдніх ведаў або падрыхтоўкі. Вадаспад падыход вельмі строгі; кожны этап мае набор вынікаў і агляд, што робіць яго простым у адміністраванні і абслугоўванні.
- Патрабуецца добра задакументаваная метадалогія: Дакументацыя, неабходная метадалогіяй вадаспаду, дапамагае растлумачыць аргументацыю тэстаў і кода. Акрамя таго, ён стварае папяровы след на выпадак, калі зацікаўленым бакам спатрэбіцца дадатковая інфармацыя аб пэўным этапе або для любых будучых ініцыятыў.
- Захаванне дысцыпліны: Кожны крок у праекце вадаспаду мае пачатак і канец, што дазваляе лёгка паведамляць пра прагрэс зацікаўленым бакам і кліентам. Каманда можа знізіць верагоднасць пропуску дэдлайну, паставіўшы на першае месца патрабаванні і дызайн перад стварэннем кода.
недахопы
- Можа быць цяжка сабраць дакладныя патрабаванні: Размова са спажыўцамі і зацікаўленымі бакамі, каб вызначыць іх патрэбы, з'яўляецца адным з пачатковых этапаў праекта Waterfall. На гэтай ранняй стадыі праекта можа быць складана высветліць іх канкрэтныя патрабаванні. Кліенты часта даведваюцца пра іх патрабаванні па ходзе развіцця праекта, а не выказваюць іх загадзя.
- Змены цяжка прыняць: Экіпаж не можа аднавіць працу пасля завяршэння этапу. Гэта вельмі цяжка і дорага, каб вярнуцца і адрамантаваць яго, калі яны даведаюцца на этапе тэсціравання, што функцыянальнасць адсутнічала ў працэсе патрабаванняў.
- Праграмнае забеспячэнне прадастаўляецца пасля заканчэння тэрміну: Ад двух да чатырох этапаў праекта неабходна завяршыць, перш чым можна будзе пачаць сапраўднае кадзіраванне. У выніку зацікаўленыя бакі не ўбачаць функцыянальнае праграмнае забеспячэнне да канца жыццёвага цыкла.
Што такое Scrum?
Адной з найбольш папулярных структур працэсаў для прымянення Agile на практыцы з'яўляецца Scrum, які з'яўляецца падмноствам Agile.
Гэта ітэрацыйная парадыгма для кіравання стварэннем складанага праграмнага забеспячэння і прадуктаў. Спрынты, якія ўяўляюць сабой ітэрацыі фіксаванай даўжыні, якія працягваюцца ад аднаго да двух тыдняў, дазваляюць камандзе выпускаць праграмнае забеспячэнне па рэгулярным графіку.
Зацікаўленыя бакі і члены каманды збіраюцца разам, каб абмеркаваць наступныя крокі пасля кожнага спрынту. Ролі, абавязкі і сустрэчы ў Scrum застаюцца нязменнымі.
Напрыклад, Scrum вызначае планаванне спрынту, штодзённае ўставанне, дэманстрацыю спрынту і рэтраспектыву спрынту ў якасці чатырох рытуалаў, якія забяспечваюць кожную структуру спрынту.
Падчас кожнага спрынту каманда будзе выкарыстоўваць візуальныя артэфакты, такія як дошкі задач або дыяграмы выгарання, каб дэманстраваць прагрэс і атрымліваць паступовую зваротную сувязь.
У scrum каманда і ўладальнік прадукту цесна супрацоўнічаюць, каб вызначыць і расставіць прыярытэты функцыянальнасці сістэмы. Яны дасягаюць гэтага, ствараючы бэклог прадукту, які змяшчае ўсе задачы, неабходныя для стварэння праграмнага забеспячэння, якое працуе належным чынам.
Выпраўленні памылак, нефункцыянальныя патрабаванні і функцыі павінны быць уключаны ў чаргу. Міжфункцыянальныя каманды павінны зрабіць ацэнку і зарэгістравацца для забеспячэння павелічэння праграмнага забеспячэння на працягу бесперапынных спрынтаў, якія звычайна доўжацца 30 дзён, пасля таго, як мэты будуць устаноўлены.
Толькі каманда можа дадаць функцыянальнасць у спрынт пасля таго, як зафіксуе адставанне для гэтага спрынту.
Наступная пастаўка спрынту, адставанне прадукту ацэньваецца і, пры неабходнасці, змяняецца прыярытэтнасць, і наступны набор вынікаў выбіраецца для ўдзелу ў наступным спрынце.
Працэс Scrum
- Адставанне прадукту: Каб заказаць элементы ў бэклоге прадукту, уладальнік прадукту і каманда Scrum сустракаюцца (праца над бэклогам прадукту грунтуецца на гісторыях і патрабаваннях карыстальнікаў). Бэклог прадукту - гэта спіс усіх неабходных функцый для прадукту, а не спіс задач, якія неабходна выканаць. Пасля гэтага каманда распрацоўшчыкаў выбірае задачы з бэклогу прадукту для выканання на працягу кожнага спрынту.
- Планаванне спрынту: Перад кожным спрынтам уладальнік прадукту дастаўляе камандзе асноўныя элементы ў адставанні на нарадзе па планаванні спрынту. Затым група выбірае элементы з бэклога прадукту, якія яны могуць скончыць падчас спрынту, і перамяшчае іх у бэклог спрынту (гэта спіс задач, якія трэба выканаць у спрынце).
- Дапрацоўка/дагляд адставання: Каб пераканацца, што адставанне падрыхтавана да наступнага спрынту, каманда і ўладальнік прадукту сустракаюцца па заканчэнні аднаго спрынту. Каманда можа адхіляць гісторыі карыстальнікаў, якія больш не падыходзяць, дадаваць новыя, перагледзець парадак, у якім яны павінны разглядацца, або падзяліць гісторыі карыстальнікаў на больш дробныя задачы. Падчас гэтай «даглядальнай» сустрэчы будзе пераканацца, што бэклог змяшчае толькі рэчы, якія з'яўляюцца дарэчнымі, глыбокімі і адпавядаюць мэтам праекта.
- Сустрэчы Scrum кожны дзень: На 15-хвіліннай сустрэчы, якая называецца "Daily Scrum", кожны член каманды абмяркоўвае свае мэты і праблемы, якія ўзніклі. Кожны дзень на працягу ўсяго спрынту каманда ўдзельнічае ў штодзённым Scrum, у якім усе выконваюць заданні.
- Сустрэча па ацэнцы спрынтуt: Каманда прадстаўляе сваю працу на сустрэчы па аглядзе спрынту ў канцы кожнага спрынту. Замест справаздачы або прэзентацыі PowerPoint гэтая сустрэча павінна ўключаць рэальную дэманстрацыю.
- Рэтраспектыўная спрынтарская сустрэча: Каманда абмяркоўвае любыя мадыфікацыі, якія неабходна зрабіць у наступным спрынце, а таксама тое, наколькі добра Scrum працуе для іх у канцы кожнага спрынту. Каманда можа абмеркаваць станоўчыя аспекты спрынту, адмоўныя аспекты і вобласці для паляпшэння.
перавагі
- Больш адказнасці ад каманды: Няма кіраўніка праекта, які інструктуе каманду Scrum, што і калі рабіць. Праца, якую можна выканаць у кожным спрынце, вызначаецца камандай у цэлым. Усе яны супрацоўнічаюць і дапамагаюць адзін аднаму, паляпшаючы камандную працу і выхоўваючы індывідуальнасць кожнага члена каманды.
- Палепшаная бачнасць і празрыстасць праекта: Менш непаразуменняў і няўпэўненасці, бо кожны ў камандзе ўсведамляе сваю адказнасць дзякуючы частым сустрэчам. Каманда можа справіцца з праблемамі, перш чым яны выйдуць з-пад кантролю, паколькі праблемы выяўляюцца загадзя.
- Палепшанае скарачэнне выдаткаў: Пастаянная сувязь інфармуе каманду аб любых праблемах або зменах, як толькі яны адбываюцца, што дапамагае зэканоміць выдаткі і палепшыць якасць. Меншыя фрагменты функцый забяспечваюць бесперапынную зваротную сувязь і дазваляюць ранняе выпраўленне памылак, перш чым больш буйныя памылкі стануць занадта дарагімі для выпраўлення.
- Проста адаптавацца да зменаў: Лягчэй спраўляцца са зменамі і адаптавацца да іх, калі ёсць частыя цыклы зваротнай сувязі і кароткія спрынты. У якасці ілюстрацыі, калі падчас аднаго спрынту каманда сутыкнецца з абсалютна новай гісторыяй карыстальніка, яны могуць хутка дадаць гэтую функцыю ў наступны спрынт на сустрэчы па ўдакладненні невыкананых спраў.
недахопы
- Небяспека паўзучага прыцэла: З-за адсутнасці ўстаноўленай даты завяршэння некаторыя праекты Scrum могуць сутыкнуцца са змяншэннем аб'ёму. Зацікаўленыя бакі могуць працягваць патрабаваць больш функцый, калі няма тэрміну завяршэння.
- Дрэнны Scrum Master можа ўсё сапсаваць: Менеджэр праекта - гэта не тое ж самае, што майстар схваткі. Scrum Master павінен давяраць камандзе, якую ён кантралюе, і ніколі не даваць ім інструкцый. Scrum Master не мае ўлады над камандай. Праект праваліцца, калі скрам-майстар паспрабуе кіраваць камандай.
- Праблемы з дакладнасцю могуць быць вынікам дрэнна сфармуляваных задач: Калі задачы не вызначаны дакладна, выдаткі і графікі праекта не будуць дакладнымі. Планаванне становіцца складаным, і спрынты могуць заняць больш часу, чым чакалася, калі першапачатковыя мэты не вызначаны.
- Вопыт і самаадданасць неабходны камандзе: Каб каманда была паспяховай, ролі і абавязкі павінны быць дакладна вызначаны. Каманда Scrum патрабуе членаў каманды з тэхнічнымі навыкамі, таму што няма дакладна вызначаных роляў (кожны робіць усё). Каманда таксама павінна прыняць удзел у штодзённых сесіях Scrum і трымацца разам на працягу ўсяго жыцця праекта.
Agile супраць Scrum
Нягледзячы на тое, што Agile і Scrum выкарыстоўваюць адну і тую ж метадалогію, паміж імі ёсць некаторыя адрозненні. Agile Manifesto выкладае набор прынцыпаў для стварэння праграмнага забеспячэння праз ітэрацыйную распрацоўку.
З іншага боку, Scrum - гэта набор рэкамендацый, якіх неабходна прытрымлівацца падчас распрацоўкі праграмнага забеспячэння Agile. Agile - гэта канцэпцыя, а Scrum - гэта тэхніка яе прымянення на практыцы.
Scrum - гэта метад рэалізацыі Agile, таму яны абодва маюць шмат агульных рыс. Абодва падыходы з'яўляюцца ітэрацыйнымі, аддаюць прыярытэт ранняй і частай пастаўцы праграмнага забеспячэння і прымаюць змены. Яны таксама падтрымліваюць адкрытасць і пастаяннае развіццё.
Спрытны супраць вадаспаду
Жорсткі супраць гнуткага лепш за ўсё апісвае адрозненні паміж працэсам Waterfall і Agile. У той час як Agile плыўная і пастаянна змяняецца, Waterfall - гэта значна больш жорсткая і жорсткая метадалогія.
Гэтыя дадатковыя адрозненні паміж імі наступныя:
- Agile не патрабуе лінейнага падыходу, тады як Waterfall з'яўляецца паслядоўным.
- У той час як у праектах Waterfall патрэбы часта прадвызначаны, чакаецца, што яны будуць змяняцца і адаптавацца ў ініцыятывах Agile.
- У адрозненне ад Agile, праекты Waterfall не дазваляюць уносіць змены ў працу, якая была завершана на папярэднім этапе.
- Вадаспад - гэта арганізаваная працэдура, у якой вы павінны завяршыць кожны крок, перш чым перайсці да наступнага. Аднак Agile - гэта гнуткая метадалогія, якая дазваляе вам працягваць праект у сваім уласным тэмпе.
Agile Vs Waterfall Vs Scrum
- Вадаспад павялічвае давер да таго, што будзе прадастаўлена вельмі хутка пасля таго, як гэта было запланавана. Agile абапіраецца на лепшыя практыкі асяроддзя распрацоўкі. Тут можна добра кіраваць шэрагам рызык праекта, паколькі вынікі пастаянна ацэньваюцца.
- Waterfall не мяркуе, што каманда і праект будуць знаходзіцца ў адным месцы. У той час як scrum і agile патрабуюць сумеснага размяшчэння супрацоўнікаў.
- Agile факусуюць на скарачэнні перапрацоўкі праекта і заахвочваюць уносіць змены значна раней. У адрозненне ад вадаспаду, які рэагуе па-рознаму, сутычка таксама дазваляе ранняе выяўленне змяненняў.
- Больш кампактны план для канчатковага прадукту забяспечваецца agile і scrum. Гэта стварае праблему з абяцаннямі, дадзенымі пакупніку. Наадварот, графіка вадаспаду дае кліентам і распрацоўшчыкам лепшае ўражанне аб гатовым выніку.
- Кожны з гэтых метадаў мае набор інструментаў для арганізацыі і мадэлявання задач, якія ўдзельнічаюць у іх стварэнні.
заключэнне
Калі вы прытрымліваліся дагэтуль і ўпэўнены ў сваіх ведах аб адрозненнях паміж працэсамі Waterfall, Agile і Scrum, вы ўжо павінны ведаць, якая стратэгія лепш за ўсё падыдзе вам і вашай камандзе.
Тэхніка "Вадаспад", якая прызначана для праектаў з пэўным аб'ёмам, тэрмінамі і бюджэтам, можа стаць лепшым варыянтам, калі вам падабаюцца жорсткія правілы і працэдуры і вы лічыце, што яны ўносяць яснасць.
З іншага боку, калі свабода і адаптыўнасць, якія прапануе Agile, натхняюць вас, вам варта звярнуць увагу на гэта.
Аднак Scrum - гэта правільны шлях, калі вы жадаеце крыху дысцыпліны ўнутры гнуткай структуры.
Аднак вы павінны разглядаць гэтыя падыходы ў святле праекта, над якім вы працуеце, і вашага канчатковага выніку.
Пакінуць каментар