Този сайт използва бисквитки (cookies). Ако желаете можете да научите повече тук. Разбрах

Новини Виртуално пространство

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

За разлика от от последователния модел, този подход осигурява значително по-голяма гъвкавост при реализацията на проекти

от , 28 март 2018 0 7088 прочитания,

След като в първата част ви запознахме с малко факти около последователната методология (waterfall development), в тази ще обърнем внимание на прехода към по-гъвкавия подход и на ролите, които имат различните звена в него.

Преходът към agile методологията

Създадена през 1970 г., последователната методология е революционна за времето си, защото създава стриктна дисциплина при разработката на софтуер, гарантираща, че има ясна спецификация, която се следва неотлъчно. Тя е базирана на иновативния метод на производство на монтажната линия на Хенри Форд от 1913 г., която прави така, че всяка стъпка в производствения процес е насочена към първоначално поставените изисквания към крайния продукт.

Прочетете още: Какво представлява agile методологията за създаване на софтуер?

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

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

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

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

През 2001 г., група от опитни софтуерни разработчици се събират, обединени от идеята тази нова практика да бъде институционализирана, и колективно приемат идеята за разработване на софтуер по различен от класическата методика начин. За целта е изготвена обща позиция, наречена Agile Manifesto, в която се документира общата визия за това как трябва да функционира съвременният процес на разработка на софтуер. В нея се насърчава сътрудничеството по отношение на документацията и самоорганизация, за сметка на строгите управленски практики, и способността да екипите да се справят с постоянни промени, вместо работата да се заключва в предварително заложени правила и срокове. Именно от тези принципи се ражда и agile методология за разработка на софтуер.

Различните роли при новата методология

Agile-процесът за разработка на софтуер винаги започва с дефиниране на потребителите и изграждане на визия за проблемите, възможностите и стойността, свързани с проекта. В последствие компанията-изпълнител формира мултидисциплинарен екип или екипи, които да претворят визията в продукт. Ето и кратко описание на ролите в този процес.

Продуктов отговорник (product owner)

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

Процесът на разработка започва от някой, който играе ролята на гласа на клиента, включително на всички вътрешни заинтересовани страни. Този човек обединява всички прозрения, идеи и обратната връзка, за да създаде продуктова визия. Тя често е проста и кратка, но винаги трябва да е достатъчно изчерпателна, за да дава яснота за това какво представлява клиентът/потребителят, каква добавена стойност и функционалности трябва да получи и каква стратегия трябва да се разработи за постигането им. Ако трябва да дадем пример с Google например, тази продуктова визия би звучала така: “Да улесним всеки, който има достъп до интернет, в намирането на подходящи уеб страници чрез прост интерфейс, управляван от ключови думи, и алгоритъм, който класира реномираните източници по-високо в резултатите от търсенето".

Tози човек се нарича продуктов отговорник (product owner). Неговата работата е да дефинира основната визия и след това да работи с разработчиците, за да може тя да стане реалност.

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

Екип за разработка на софтуер

При agile-подхода екипът за разработки и отговорностите на членовете му се различават от тези при традиционната методика.

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

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

КОМЕНТАРИ ОТ  

Полезни страници
    За нас | Аудитория | Реклама | Контакти | Общи условия | Декларация за поверителност | Политика за бисквитки |
    Действителни собственици на настоящото издание са Иво Георгиев Прокопиев и Теодор Иванов Захов