Како Агиле ИТ може трансформисати ИТ индустрију?

Садржај

• Зашто Агиле ИТ?
• Како се агилна методологија бави проблемима модела водопада?
• Како је Агиле утицао на ИТ индустрију?
• Без грешака, без стреса - Ваш корак по корак водич за креирање софтвера за промену живота без да вам уништи живот
• Разлози БТ прешли су на окретне праксе
• Лоше управљање захтевима
  
• Лош софтверски дизајн
• Ограничења развоја
• Шта је БТ урадио да реши горе наведене проблеме?
• Закључак

Извор: Дарковујић / Дреамстиме.цом

Одузети:

За многе је модел слапа развоја софтвера био деценијама стандард, али то је сада замењено много флексибилнијом Агиле методологијом.

Агиле методологија за развој софтвера може позитивно утицати на ИТ индустрију. Резултати усвајања Агиле методологије могу се мерити на више начина. Бржи заокрет у захтевима за променом софтвера, мање грешака, квантитативно мерење перформанси тима и уска грла све су одраз успешне примене Агиле-а. Да би успешно измерио утицај Агиле-а, организација мора да упореди различите метрике повезане са пре-агилним и пост-агилним развојем. Стварни утицај Агиле-а не може се мерити само повећањем прихода или повећаним бројем исправљених грешака. Неколико унутрашњих параметара треба узети у обзир да би се разумео стварни утицај. (За више информација о Агиле развоју, погледајте Агиле Софтваре Девелопмент 101.)

Зашто Агиле ИТ?

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

Једноставно речено, модел водопада је модел развоја софтвера у којем се посао врши на један на други начин - једна фаза за другом. Постоји пет фаза овог модела: захтеви, дизајн, примена, верификација и одржавање. Обично је након завршетка једне фазе тешко, ако не и немогуће, извршити промене у ранијој фази. Дакле, претпоставка је да су захтеви прилично фиксни. Главна разлика код Агиле модела је у претпоставци да неће бити промена захтева. Агиле претпоставља да ће се пословне ситуације променити, а исто тако и захтеви. Дакле, софтвер се испоручује у мањим комадима преко сс, док је код модела водопада прва испорука или пуштање направљено након дужег времена. (За више информација о развоју, погледајте како Апацхе Спарк помаже брзом развоју апликација.)

Најистакнутија критика против модела водопада била је његова претпоставка да неће бити промена у захтевима. Сама претпоставка је погрешна и нереална. На пример, 2001. године, студија о 1.027 ИТ пројеката у Великој Британији показала је да је ова претпоставка једини највећи разлог неуспеха ИТ пројеката.

У другом примеру, Цраиг Ларман, аутор књиге "Агилни и итеративни развој: Водич за менаџера", указао је на то како бројни пројекти које је Министарство одбране (ДО) извршило користећи модел водопада у САД-у нису успели постижу своје циљеве. Током 1980-их и 1990-их, ДоД је морао да користи модел водопада за своје пројекте развоја софтвера према стандардима објављеним у ДоД СТД 2167. Шокантна статистика открила је да 75% ових софтверских пројеката никада није коришћено. Након овог извештаја покренута је радна група под др Фредерицком Брооксом, познатим стручњаком за софтверски инжењеринг. Радна група је изашла са извештајем који је коментарисао „ДоД СТД 2167 такође треба радикалан ремонт да би одражавао модерну најбољу праксу. Еволуцијски развој је технички најбољи, јер штеди вријеме и новац. "

Следеће четири претпоставке модела водопада нису успеле у стварним сценаријима:

• Дати захтеви су разумно дефинисани и тако се неће битно променити.
• Чак и ако се захтеви мењају током фазе развоја, они ће бити довољно мали да се могу сместити у развојни циклус.
• Интеграција система, која се дешава након испоруке софтвера, ићи ће по плану.
• Иновација софтвера и напор потребни за иновирање ићи ће према планираном и предвидљивом распореду.

Како се агилна методологија бави проблемима модела водопада?

Агиле методологија битно се разликује од модела водопада и то је јасно из његових претпоставки:

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

Како је Агиле утицао на ИТ индустрију?

Агиле се усваја на многим местима, док много компанија планира да усвоји Агиле. Иако је Агиле дефинитивно извршио фундаменталне промене у ИТ индустрији, чињенице и бројке још су мало тешке добити. Али утицај Агиле-а може се разумети према студији случаја Бритисх Телецом-а (БТ) датој у даљем тексту.

Без грешака, без стреса - Ваш корак по корак водич за креирање софтвера за промену живота без да вам уништи живот

Не можете побољшати своје вештине програмирања када никога није брига за квалитет софтвера.

Разлози БТ прешли су на окретне праксе

БТ је почео да има бројне проблеме са праксама развоја софтвера још 2004. године. БТ је развио низ софтверских пројеката, и једноставних и сложених. Многи софтверски пројекти нису били у стању да развију квалитетне резултате у договореном року. БТ је утврдио да су проблеми настали због модела водопада. Дакле, ојачавање модела водопада неће помоћи. Главни узроци проблема су наведени у наставку:

Лоше управљање захтевима

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

Лош софтверски дизајн

• С обзиром на огроман број захтева, дизајнери су потрошили превише времена само покушавајући да схвате шта захтеви значе. Мало је времена остало за стварни дизајн.
• Аналитичари захтјева прешли су на друге задатке, узимајући са собом неписано, прешутно знање.
• Горња два фактора су резултирала лошим дизајном. Дизајнери су и даље морали да их испоручују у складу са оригиналном временском линијом.

Ограничења развоја

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

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

Шта је БТ урадио да реши горе наведене проблеме?

БТ је схватио да ојачавање модела водопада није одговор на проблеме. Требао је нови приступ. Дакле, одлучила је применити Агиле приступ. Према новом приступу, одлучене су следеће ствари:

• Уместо 12-месечног развојног циклуса, БТ би сада испоручио известан део софтвера у циклусу од 90 дана. Идеја је била усредсредити се на један или два пословна проблема и циљ је да се у року од 90 дана испоручи софтверско решење. Почетак овог циклуса био је обележен интензивном расправом између различитих актера, тако да су захтеви били јасно идентификовани, анализирани и приоритетни.
• Циљ је био пружање јасних, опипљивих пословних вредности. Интерни купац је био под притиском да пружи јасне захтеве. Уместо нејасних циљева, корисничке приче дате су са јасним критеријумима прихватања.
• Софтвер који би се испоручио био би у потпуности тестиран и документован. Софтвер би пролазио кроз честе интеграционе тестове да би претходно уочио проблеме.

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

Закључак

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