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

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

CIO Media

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

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

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

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

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

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

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

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

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

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

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

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


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

© CIO Media, Cio.bg

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

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

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

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

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

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

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


X