Какво е Agile: превод, обхват. Гъвкава методология за развитие

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

Обща информация

Първоначално нека разгледаме техническите проблеми. Какво е Agile? Преводът (буквално) на тази дума от английския език - "жив, мобилен", е малко по-рядко споменаван "гъвкав". И между другото, това е намаление. Пълното име на този подход е пъргав разработка на софтуер. Но тъй като това е твърде дълго, беше решено да се намали. И сега те казват просто Agile. Преводът като "гъвкав" се използва, защото в най-голяма степен съответства на реалната ситуация.

Какво е включено тук?

Продължаваме да разглеждаме какво е "Агил". Тук би било желателно да се съсредоточи вниманието върху факта, че това е гъвкав подход, основаващ се на разнообразие от различни методологии (Scrum, XP, "Kanban", Lean). За да разберем по-добре темата, нека изготвим паралели. Да приемем, че гъвкавите технологии са процес на произход на Вселената. Крайният продукт е самият свят. Една голяма експлозия е най-болезненият проблем, който човек трябва да срещне - промяна на списъка на изискванията за продукта. Обикновено процесите на създаване включват използването на каскаден модел. В този случай всичко върви последователно и на етапи. Този подход може да се изрази накратко: Виждам целта - отивам при нея. И ако изискванията към крайния резултат се променят, тогава понякога трябва да вършите всичко. Това, което усложнява тази ситуация, е опит да се преструва, че всичко е нормално и трябва да се придвижим напред.

А Agile, методологията на управлението, е призована да се бори с всичко това, благодарение на своята гъвкавост. Този екип от екипи "минимум" минимизира различните рискове чрез използването на набор от принципи. Всички те са отразени в манифеста Agile, издаден през 2001 г. Накратко, те звучат така:

1. Основното е хората, не нещата.
2. Съдействайте, но не четете договора.
3. Документацията не трябва да пречи на работата.
4. Променете възможно най-бързо.

Може да изглежда твърде неясно и не точно, но нека подробно.

Дизайн на процесите

Като се има предвид какво е Agile, нека се обърнем към една от най-популярните методики, известни като "Scrum". Какво предлага тя? Първо трябва:

1. Изберете собственика на продукта. Човекът е подходящ за тази роля, която вижда целта, която трябва да бъде следвана, и какво в крайна сметка ще се случи.
2. Решете с екипа. За да направите това, имате нужда от група от три до десет души, които имат умения да получават резултати.
3. Изберете отговорния специалист. Това е човек, който ще следва развитието на проекта и ще помогне на екипа да избегне трудностите.
4. Разберете трудностите. Необходимо е да се съберат на едно място всички съществуващи изисквания към продукта и да се даде приоритет. Собственикът на продукта трябва да събере тук всичките си желания. След това екипът ги оценява и разбира дали може да бъде приложен и колко време отнема.
5. Необходимо е цялата работа да се прекъсне на части от времето, една седмица или две дълги, през които екипът ще изпълнява определени задачи.
6. Дневните срещи трябва да се провеждат не повече от петнадесет минути. Дневният ред трябва да бъде обсъден, какво беше направено вчера, какви са плановете за днес и пречките, които пречат на изкачването.
7. Провеждат се проучвания на резултатите от седмицата (две), през които екипът разказва какво се е случило. В този случай е необходимо да се покаже оперативността на частите на продукта.
8. След всеки период от време е необходимо да се обсъждат проблемите и да се търсят решения. И всички развития трябва да бъдат приложени незабавно.

Как да идентифицираме Agile?

Методологията на управление, независимо от избраната посока, винаги има следните характеристики:

1. Минимизиране на рисковете. Това е основната цел, преследвана от всеки гъвкав подход.
2. Итеративно развитие. В този случай това означава работа в малки цикли.
3. Най-важното е хората и комуникацията между тях.

Нека си представим реката. От една страна клиентът. На втория - на отбора. В този случай гъвкава методология за развитие има предимства за всички:

1. Клиентът се нуждае от минимално работещ продукт. Същевременно условията могат да се променят по време на създаването му.
2. Екипът е полезен да комуникира с колегите и клиента. В този случай рискът от неправилно разбиране е сведен до минимум, прозрачността на процесите се увеличава, проблемите се решават бързо, шансовете са, че ще има изненада при създаването на продукта.

Социалният фактор

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

От самото начало той е успял да намери признание в технологичните индустрии. В момента тя се използва широко за проектиране на нови софтуерни продукти. Но в рамките на общата бизнес практика този подход все още е малко известен. Ето защо той е предпазлив за онези, които не са се срещали с Agile преди. Трябва също така да се разбере, че трябва да се използва само когато хората са изправени пред задачата на интелектуалния труд.

Един малък пример

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

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

И какво да правите с опашката?

Добре, тук е екипът реши, че може да се справи с четири етажа в продължение на една седмица. Но как можем да се ориентираме във всичко, което съществува? Да кажем, че потребителите пращат по 10 истории на седмица. Обработени четири. По този начин опашката непрекъснато ще расте. За този случай има само един ефективен метод - думата "не". За собственика на продукта това е изключително важно. Да кажеш "да" не е трудно. Много по-трудно е и по-важно да решаваме какво да не правим. И за това е необходимо също така да носим отговорност. Следователно е необходимо да се реши какво да обърне внимание и какво трябва да бъде отложено. Да е правилно приоритет, Необходимо е собственикът на продукта да разбере стойността и обхвата на всяка история.

Вземане на решения

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

Възможни рискове

За да се избегнат проблеми, е необходимо да се дадат честни отговори на редица въпроси. Това са:

1. Правим ли правилните неща? Това е бизнес риск.
2. Можем ли да осъзнаем какво е необходимо? Това е социален риск.
3. Проектът ще работи ли на тази платформа. Това е технически риск.
4. Ще има ли достатъчно пари и ще имаме ли време? Това са рисковете от прилагането и разходите.

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

Как да науча?

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

Какво очаква в бъдеще?

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

В заключение

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