Дигитализация

Какво представлява agile методологията за създаване на софтуер? (Част 1)

CIO Media

Всяка организация за разработка на софтуер днес изглежда, че практикува agile методиката (подход, при който проекта се представя на части и производителите имат възможност да получат обратна връзка от клиентите и да адаптират разработката според техните изисквания) или някаква нейна версия. Или поне много хора вярват, че го правят точно по този начин. Независимо обаче дали сте новаци в сферата или сте научили занаята преди десетилетия, използвайки последователната методологията (waterfall development), днес работата ви със сигурност е повлияна от agile подхода.

Но какво точно представлява той и как трябва да се прилага при разработката на софтуер?



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

Ерата на последователната методология

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

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

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

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

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

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

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

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

Очаквйте продължение!


X