Етапи на гъвкаво развитие. Какво е Agile? В началото екипът изследва реалността на разработката на приложения и обхвата. По-нататъшната работа е разделена на три взаимосвързани цикъла

Agile („пъргав“) е дума, която напоследък се чува от всяка ютия. Но какво е Agile и, най-важното, защо е необходим този Agile?

Ако е отворен речник, например Оксфорд, тогава можете да прочетете поне две дефиниции там:

1. Може да се движи бързо и лесно.
2. Способен да мисли и разбира бързо.

Тоест, за да си пъргав, трябва да можеш да се движиш бързо и лесно и да мислиш бързо. Изглежда доста полезни качества, особено в бизнеса. Бързото мислене и бързата реакция е точно това, което лекарят нареди за нашето време, в противен случай просто няма да оцелеете: конкурентите ще ви погълнат. В света има все по-малко индустрии, в които тези конкуренти не съществуват. Освен това скоростта на копиране прави практически невъзможно продуктът да се пусне на пазара и да се почива на лаврите му. Без способността за бързо адаптиране към промените, което дава така наречената „Agile методология“, е все по-трудно да оцелееш.

Неслучайно вземам израза „Agile методология“ в кавички, защото често можете да го чуете, но не е съвсем коректен. Ако не навлизате в технически подробности, тогава Agile не е методология, а сборно име за различни методи и подходи за управление, които:

1. Фокусирайте екипа върху нуждите и целите на клиентите.
2. Опростете организационната структура и процеси.
3. Предлагат работа на кратки цикли.
4. Използвайте активно обратна връзка.
5. Има увеличаване на правомощията на служителите.
6. Те се основават на хуманистичен подход.
7. Те не са крайно състояние, а по-скоро начин на мислене и живот.

Нищо свръхестествено, нали? Нека да разгледаме точка по точка и да видим защо горното е важно, за да бъдем бързи и пъргави, и как Agile постига тези цели.

Фокусирайте се върху нуждите и целите на клиента

Мисля, че не си струва да обяснявам защо най-успешният бизнес е този, който задоволява нуждите на своя клиент по-добре от конкурентите. По-интересно е да разберем какви инструменти в Agile помагат за постигането на това.

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

„Инструменти за работа“ в този случай са кратки, но интензивни сесии (срещи) на всички участници в работата или ключовото мнозинство, където се генерират и тестват различни идеи. Същите тези срещи служат за ниво на разбиране и фокусиране: всички участници в изходната среща разбират какво правят, защо и защо е важно за клиента. А демократичният формат на семинара, за разлика от скучните презентации, гарантира по-голямо включване и мотивация на всички участници.

Примери за такива инструменти са Lean Canvas, Impact Mapping, User Story Mapping и други Agile методи за описание на хипотези и процеси.

Един от крайъгълните камъни на Agile е изключителната простота. И организационната структура на организацията, и процесите, по които хората работят, и правилата трябва да бъдат възможно най-прости. Това ще позволи на хората да се съсредоточат върху работата си, върху стойността, която създават, а не върху спазването на регулации и правила. Страхотни примери за този подход могат да бъдат намерени в много екипи, работещи по Scrum, най-популярният начин за организиране на работния процес в Agile. Всъщност всички споразумения и правила на екип от 10-11 души, текущи задачи за няколко седмици, цели, както и стратегически планове могат лесно да се поберат на 2-3 листа хартия A0. На един лист може да има така наречения „назад за спринт“, списък на всичко, което екипът ще направи в следващата итерация. Ако закачите такъв в стаята, в която работите, можете да си спестите труда да помните всичко това. Същото важи и за процесите. Например в Scrum мястото и времето на всички срещи са строго фиксирани. Всеки участник знае със сигурност, че например в понеделник в 10-00 е планирана следващата итерация, а в петък в 17-30 - среща за подобряване на работния процес.

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

Примери за опростяване (и изравняване, но това е тема за друга дискусия) в Agile са Scrum, Nexus, LeSS (Large-Scale Scrum или Scrum в голям мащаб), както и самият Agile манифест.

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

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

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

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

Друго предимство на този подход, в допълнение към ранното навлизане на пазара и извършването на промени в ранните етапи на работа, е възможността за по-точно измерване на напредъка. Ние не просто „свършихме 15% от работата“, което е доста абстрактно. „Направихме 15% от функционалността“, която вече работи.

всичко процесни подходив Agile има кратки цикли, било то споменатите по-рано Scrum, Nexus, LeSS, SAFe или освен това необходимостта от работа с такива цикли е спомената в самия манифест на Agile.

Активно, системно използване на обратна връзка

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

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

Agile предлага систематично използване на този подход навсякъде: при създаване на продукт (пускаме го на пазара или го показваме на клиента, или провеждаме тестове и използваме обратна връзка, за да го коригираме), при изграждане на процеси (периодично „спираме“ работата и анализирайте самия процес, за да го подобрите, да се отървете от загубите и проблемите), дори при изграждането на структурата на организацията и фината настройка на взаимоотношенията в екипите.

Отново примерите са навсякъде: ретроспективни срещи в Scrum, Kanban, Nexus и LeSS, I&A цикли в SAFe, подход на дизайнерско мислене за създаване на продукти и т.н.

Защо да давате повече пълномощия, когато можете да дадете лист хартия с инструкции? Има поне три причини да направите това.

Първо, хората, занимаващи се с умствена работа, не обичат да се чувстват като маймуни (добре или роботи) и като отнемаме способността за вземане на решения от човек, ние отнемаме умствената работа от него сама по себе си. А това определено действа демотивиращо.

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

Трето, все още е същата скорост. Ако човек може да реши проблем сам, на негово място, без да пита никого, това намалява времето за вземане на решения. Край на изпращането на въпроса „нагоре“ и чакането на отговор от ръководството. Това предимство не е толкова забележимо, ако имате 3-ма работещи, но ако имате 30, или 300, или 3000 ... В големи организации, изградени върху чисто йерархично вземане на решения, парализата на волята може да бъде доста често срещана.

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

Защо да се отнасяме към хората като към човешки същества? Тоест, моралната страна на въпроса е ясна, но каква полза ще донесе на собственика на предприятието?

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

И, което е хубаво, ако копаете в същия Scrum, се оказва, че всички ключови фактори за мотивиране на работник за умствена и / или творческа работа вече са включени в него. Във всяка итерация („спринт“) си поставяме цел, която искаме да постигнем; дава ни се възможност да решим как точно да постигнем целта; накрая гледаме колко сме станали по-добри (или по-лоши) да работим от преди; виждаме хора, които се интересуват от продукта и техните емоции от опознаването му. Особено добре е, ако тези емоции са положителни.

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

Agile не е крайно състояние, а начин на мислене и живот

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

И ако всичко е било успешно: хората в компанията разбират и споделят ценностите и принципите на Agile и работят според тях, тогава ръководството няма да трябва да „влачи“ промени или да „рита“ служители, за да започнат да правят нещо различно. Предприятието ще се превърне в единен организъм, чието управление ще изисква по-малко усилия и ще носи повече удоволствие.
И къде има повече удоволствие от работата, и резултатът е по-висок. Това се отнася не само за специалистите, но и за ръководството, и то в още по-голяма степен.

Всеки, който някога се е занимавал с управление на проекти, знае колко е трудно да се организира добре координирана работа на екип и в условията на постоянно променящи се изисквания за резултата от даден проект, всички положени усилия могат да се окажат напразни. Гъвкавият метод за управление на проекти е идеален за работа с такива проекти.

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

История на Agile

Еволюционно управление на проекти и адаптивно развитие софтуерсе появява в началото на 70-те години. През 1970 г. д-р Уинстън Ройс представи документ, озаглавен "Управление на разработката на големи софтуерни системи", който беше критичен към последователното развитие. Той твърди, че софтуерът не трябва да се разработва като кола на поточна линия, в която всяка част се добавя в последователни фази. В такива последователни фази всяка фаза на проекта трябва да бъде завършена, преди да може да започне следващата фаза. Д-р Ройс препоръча използването на поетапен подход, при който разработчиците първо събират всички изисквания на проекта и след това завършват цялата си архитектура и дизайн, след което пишат целия код и т.н.

През 90-те години бяха разработени редица гъвкави методи за разработка на софтуер в отговор на преобладаващите тежки методи. Те включват: от 1991 г. - RAD (бърза разработка на приложения); от 1994 г. - Метод за развитие на динамични системи (DSDM); от 1995 г. - Scrum; От 1996 г. Crystal Clear and Extreme Programming (XP); И от 1997 г. - разработка, управлявана от функции (FDD). Въпреки че са възникнали преди публикуването на Манифеста за гъвкава разработка на софтуер, те се наричат ​​колективно гъвкава разработка на софтуер.

През февруари 2001 г. седемнадесет разработчици на софтуер се срещнаха в Snowbird Resort в Юта, за да обсъдят олекотени техники за разработка. Заедно те публикуваха Agile Manifesto.

Agile манифест

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

4 гъвкави идеи

1. Хората и взаимодействието са по-важни от процесите и инструментите.
2. Работещият софтуер е по-важен от документацията.
3. Сътрудничеството с клиентите е по-важно от договарянето на условията на договора.
4. Желание да се направят промени в приоритета, вместо да се придържате към първоначалния план.

12 принципа на Agile

1. Удовлетвореност на клиентите чрез ранна и непрекъсната доставка на софтуер. Клиентите са по-щастливи, когато получават работещ софтуер на редовни интервали.
2. Направете промени в изискванията на продукта през целия процес на разработка.
3. Честа доставка на работещ софтуер (всеки месец, веднъж на две седмици, седмично и т.н.).
4. Сътрудничество между заинтересованите страни (клиент и разработчици) по време на целия проект.
5. Подкрепа, доверие и мотивация на участващите хора. Мотивираните екипи са по-склонни да постигнат своите резултати най-добрата работаотколкото служители, недоволни от условията на труд.
6. Взаимодействие лице в лице. Комуникацията е по-успешна, когато екипите за разработка могат да комуникират директно.
7. Работещият софтуер е основната мярка за напредък. Предоставянето на функционален софтуер на клиента е крайният фактор, който измерва напредъка.
8. Поддържане на постоянно темпо на работа. Екипите установяват повтаряща се и устойчива скорост на работа, с която могат да доставят работещ софтуер.
9. Внимание към техническите детайли и дизайна. Правилните умения и добър дизайнпозволяват на екипа да поддържа инерция, непрекъснато да подобрява продукта и да работи върху промяната.
10. Простота.
11. Самоорганизиращите се екипи насърчават отличната архитектура, изисквания и дизайн. Квалифицирани и мотивирани членове на екипа, които имат правомощия да вземат решения, редовно комуникират с останалите членове на екипа и обменят идеи, които ще осигурят създаването на качествен продукт.
12. Постоянно адаптиране към променящите се условия, което ще помогне да се направи продуктът по-конкурентоспособен на пазара.

Основата на Agile метода

В основата на гъвкавия метод за управление на проекти са редица ключови елементи:

1. Визуален контрол. Участниците в проекта използват карти с различни цветове и видове по време на работа по проекта, които сигнализират кой елемент от крайния продукт вече е разработен, планиран, завършен и т.н. По този начин екипът има визуално представяне на текущото състояние на нещата. Визуалният контрол осигурява еднаква визия на проекта от всеки от участниците.
2. Всички участници в проекта работят рамо до рамо, включително и клиента. Този подход не само ускорява много от процесите, свързани с информирането на членовете на работната група, но и създава благоприятна атмосфераза сътрудничество и ефективна работа.
3. Адаптивно управление. Ръководителят на проекта не е човек, който дава инструкции, а лидер, който определя основните правила за работа и сътрудничество.
4. Сътрудничество. Екипът, ръководителят на проекта и клиентът работят заедно, което елиминира възможността за загуба на информация и неразбиране на целите. Също така, прозрачността на всички процеси ви позволява незабавно да елиминирате възникващите проблеми и да намерите успешни решения и подобрения.
5. Работа, базирана на разделянето на общия обхват на проекта на неговите съставни части. Тази система на работа значително намалява сложността на проекта и позволява на екипите да се фокусират върху всяка част поотделно.
6. Работете върху грешките. По време на работата на един цикъл екипът научава нови умения и анализира възникналите грешки, което изключва появата им в следващия цикъл.
7. Спринтове и ежедневни срещи. Спринтове - периоди от време, през които екипите изпълняват поредица от задачи - ви позволяват ясно да видите резултатите от работата. Разделяйки времето за работа по проекта на спринтове, получаваме например 10 спринта, всеки за две седмици. И ежедневните срещи за не повече от 15 минути ще помогнат на всеки член на екипа да отговори на три въпроса за себе си: какво направих вчера, какво ще правя днес, какво ми пречи да върша работа?

Така въведението гъвкав метод Agile е възможен при следните условия:

• значението на проекта е ясно посочено,
• клиентът участва активно в целия проект,
• възможно поетапно изпълнение на целия обхват на проекта,
• резултатът от работата е по-важен от документацията,
• работната група е не повече от 7-9 човека.

На този моментГъвкавият метод е широко разпространен в областта на ИТ и започва да овладява бизнес сферата, по-специално маркетинг, управление, обучение и др. Гъвкавият метод за управление на проекти се използва от много компании и държавни агенции, например правителствата на Норвегия и Ню Йорк Зеландия използва Agile. В Русия Сбербанк овладява Agile за търговския сектор.

Системи за управление на проекти, базирани на Agile

Има много методи, базирани на идеята за Agile, най-популярните от тях са Scrum и Kanban.

СКРЪМ

Scrum е методология за управление на проекти, която се фокусира върху контрола на качеството на работния процес. Хиротака Такеучи и Икуджиро Нонака, първите, които описват подхода Scrum, го обясняват като „подхода на ръгби“, при който схватката се бори за топката. Самият метод е процес на разработка, разделен на малки итерации – спринтове, в края на които потребителите получават подобрена версия на софтуера. Спринтът е строго фиксиран във времето и продължителността му е от 2 до 4 седмици. Работата в рамките на един спринт се състои от няколко етапа:

1. Планиране на обхвата на работа за един спринт.
2. Ежедневни срещи по 15 минути за коригиране на работата на екипа и обобщаване на междинни резултати.
3. Демонстрация на резултатите от работата.
4. Ретроспектива на спринта с преглед на успехите и неуспехите на последния спринт.

Scrum най-често се използва за управление на сложен софтуер и разработване на продукти, като се използват итеративни и инкрементални методи.

Scrum значително увеличава производителността и намалява времето до предимство пред класическите "водопадни" процеси. Scrum процесите позволяват на организациите безпроблемно да се адаптират към бързо променящите се изисквания и да създадат продукт, който отговаря на променящите се бизнес цели. Scrum ви позволява да:

• Подобряване на качеството на резултатите;
• По-добре да се справите с промяната;
• Осигурете по-точни оценки, като отделяте по-малко време за създаването им;
• По-добре е да контролирате сценария на проекта и етапите на работа.

Канбан

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

Канбан се основава на три принципа:

1. Визуализация на задачите: видимостта на цялата информация за проекта ще помогне да се видят недостатъците, грешките и наслагванията.
2. Контрол и ограничаване на WIP (текуща работа): Това помага да се балансира подходът на нишките, така че екипите да не започват и да вършат твърде много работа наведнъж.
3. Контролирайте времето за изпълнение на задачата и оптимизирайте работата, за да спестите време.

Предимства и недостатъци на Agile

Всяка методология има предимства и недостатъци. Помислете за плюсовете и минусите на Agile.

Предимства

1. Повече гъвкавост в сравнение с методологията Waterfall.

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

2. По-малко дефекти в крайния продукт.

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

недостатъци

1. Постоянното получаване на обратна връзка води до постоянно отлагане на датата на завършване на проекта.

С моменталната обратна връзка, която Agile предоставя, има опасност дълга работа. Крайните потребители, които виждат, че тези изисквания могат да бъдат изпълнени "лесно" (те виждат само резултата, а не усилията), ще поискат допълнителни функции. Ако ръководителят на проекта и разработчиците не могат да управляват очакванията, крайните потребители ще продължат да искат повече, докато целият екип не бъде натоварен с допълнителна работа.

2. Документация

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

3. Чести срещи

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

Гъвкаво внедряване

1. Изборът на методология.Има различни гъвкави методологии, които се разработват при определени условия. Първата стъпка в работата с Agile е да се определят целите на работната задача, срокове, брой служители и много други и да се избере такава гъвкава методология за управление на проекти, която да отговаря на всички изисквания.
2. обучение.Обучението е необходимо, така че служителите да разберат основните принципи на Agile и да знаят как да работят с тях. Именно на този етап се идентифицират капаните, които могат да бъдат намалени Гъвкава ефективност. Екипът готов ли е за промяна? Подходящи ли са проектите на компанията за гъвкави практики? На тези и много други въпроси обикновено отговарят Agile бизнес треньорите. Освен всичко друго, ще бъде изготвен списък с обучения и план, според който ще се извърши внедряването на Agile в компанията.
3. Гъвкава демонстрация.Един вид Agile тест драйв, който се провежда под наблюдението на специалист и показва всички етапи на работа, обяснява функциите на ролите, взаимодействието в екипа и между екипите и др.
4. Създаване на екип.Освен подбор на служители, създаването на екип включва и дефиниране на отговорности, разпределение на задачите, създаване на график за срещи и др. Всеки метод е предназначен за определено количество отчовек от екипа.
5. Избор на инструментнеобходими за разпределяне на задачи, отчитане, анализи и др.
6. Първи проект с Agile.В първия проект ще има грешки, несъответствия, отхвърляне на някои инструменти и избор на други. Всяка техника изисква своеобразна адаптация към характеристиките на компанията, в която се прилага.

Ако намерите грешка, моля, маркирайте част от текста и щракнете Ctrl+Enter.

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

Главна информация

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

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

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

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

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

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

Проектиране на процеса

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

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

Как да разпознаем Agile?

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

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

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

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

социален фактор

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

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

Малък пример

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

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

Какво да правим с опашката?

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

Ние вземаме решения

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

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

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

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

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

Как да се научим?

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

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

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

Накрая

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