Агилни развој софтвера

Agilni razvoj softvera (енгл. Agile software development) подразумева развој софтвера кроз итерације где се главни животни циклус пројекта састоји од неколико итерација у низу.

Образовање модерне дефиниције агилног развоја софтвера потиче из средине 1990-тих година и то као део све шире негативне реакције на робусне (енгл. heavyweigth) методе, пре свега због чврсто регулисаних и јако распрострањених водопад-модела развоја (енгл. waterfall). Процеси који су настајали из оваквог кориштења тог модела посматрани су као спори, бирократски, захтевни и контрадикторни ономе како се програмирање заиста одвија у пракси.

У почетку, агилне методе зване су лагане (енгл. lightweight). Истакнути светски софтверски инжењери су се састали 2001. године у месту Сноубирд, Јута, САД, где су усвојили назив “агилне методе.” Неки од њих су касније оформили непрофитну организацију „The Agile Aliance” чији је циљ промовисање агилног развоја. Ствараоци агилне методологије креирају манифест агилних методологија који прописује вредности и принципе које морају прихватити све овакве методе да би биле агилне.

Настанак раних агилних метода везује се за период пре 2000.године:

• 1986. – Скрам (енгл. Scrum), у области општег менаџмента
• 1995. – Адаптивни развој софтвера, Развој вођен карактеристикама и Метод динамичног развоја система
• 1996. – Crystal clear и екстремно програмирање

Тек са екстремним програмирањем настаје свест о новој врсти методологија. Најпознатије методе агилног софтверског развоја данас су:

• Екстремно програмирање (XP) и Индустријско екстремно програмирање (IXP)
• Scrum
• Агилно моделирање
• Адаптивни развој софтвера (ASD)
• Crystal clear и остале Crystal методе
• Метод динамичног развоја система (DSDM)
• Развој вођен карактеристикама (FDD)
• “Суви” развој (енгл. lean development)
• Agile Unified Process (AUP)

У ову врсту приступа такође спадају и

• Агилна документација
• ICONIX
• Microsoft Solutions Framework (MSF)
• Agile Data Method
• Рефакторисање база података

Такође, постоје и примери примене агилних принципа на друге области, а један од примера је кориштење “суве” производње (енгл. lean manufacturing).

Многи тврде да агилне и итеративне методе воде повратку на превазиђену цоде-фиx праксу која је водила кризи софтверског инжењерства, међутим то није случај. Истина је негде на пола пута до ове премисе.

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

Ово је ипак само површно гледиште. То је само симптом много дубљих разлика а оне су по Мартину Фоулеру следеће:

1. Агилне методе су пре адаптивне него предвидиве.
2. Агилне методе су оријентисане ка људима радије него ка процесима.

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

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

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

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

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

• Велики развојни тимови од преко 20 учесника
• Виртуални и дистрибурирани развојни подухвати физички раздвојених тимова
• Ризични подухвати од којих зависи шири развој или животи
• У условима функционалне организације – са линијском комуникацијом и/или командно-контролном корпоративном културом