Agile методология: какво е и защо е важна

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

Предисловие

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

След като приключехме, чакахме нетърпеливо развиването и след това откривахме дали има страхотни снимки, или са размазани или изгорени.

Това е метод на пробата и грешката.

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

Гъвкава процедура, нали?

Какво общо има това с разработката на софтуер? Много.

Не знам дали знаеш, че имаше период, в който софтуерните програми се пишеха на перфокарти. Написваш програмата и я занасяш в изчислителния център. Там я прехвърляха на перфокарти (карта на Холерит), на които информацията се кодира чрез наличието или отсъствието на отвори на предварително определени позиции. След това се чакаше няколко дни, за да се провери дали програмата няма грешки и дали е изпълнима.

Ако се допуснеше дори една грешка в изписването на програмата (програмираше се на Fortran), цялата процедура заедно с времето за чакане се повтаряше отново.

И това е метод на пробата и грешката.

Днес сам знаеш как се създават програмите. Процедурата е много по-гъвкава. Но съвсем не се е стигнало веднага до гъвкавите методологии.

Имам още една история преди това.

В началото беше методът на Водопада – Waterfall

Методът на Водопада (Waterfall) води началото си от промишлеността и строителния сектор, среди, в които работният процес е бил и все още е задължително линеен.

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

През 1970 г. компютърният учен Уинстън У. Ройс е първият, който предлага прилагането на този подход и в процесите на разработка на софтуер. Името Waterfall обаче е измислено малко по-късно, първото официално появяване всъщност датира от статия от 1976 г. на TE Bell и TA Thayer.

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

• Анализ на изискванията.
• Проектиране.
• Развитие.
• Тестване.
• Поддръжка.

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

Около 80-те години на миналия век този метод започва да проявява основни дефекти, особено при работа с много големи проекти и чиито изисквания не са ясни от самото начало.

Линейността на метода не позволява лесно да проследи стъпките и трябвало да приключи всяка фаза, преди да може да се продължи със следващата.

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

В началото на публикацията писах за фотографирането при аналоговите и дигиталните апарати. Писах и за програмирането с перфокарти.

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

(adsbygoogle = window.adsbygoogle || []).push({});

И тогава идва Agile

Как да се държим днес в този постоянно променящ се свят, където нуждите на пазара са различни всеки ден и конкуренцията върви винаги с по-голяма скорост?

Отговорът винаги се намира в приемане на ситуацията и бърза адаптация.

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

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

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

Така се ражда „Agile Alliance“ и техният „ Манифест за гъвкава разработка на софтуер “ – методът Agile.

Манифестът също така съдържа известните 12 принципа, лежащи в основата на Agile Manifesto, принципи, които укрепват основните концепции на метода Agile.

Какво е Agile?

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

Agile е начин на мислене, базиран на организационната парадигма за споделена автономия.

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

Виж още: Сравнение на коучинг, наставничество и обучение: разлики и приложения

Как Agile се различава от методологиите?

Терминът „методология“ се прилага към Agile по аналогия с предишни подходи за организиране на разработката на софтуер: RAD, RUP, XP и други.

За разлика от тях, Agile е кратък: той се състои от 4 ценности и 12 принципа. Сам по себе си методът не предоставя алгоритми, методи и техники. Основава се не на конкретни процеси или дори елементи на процеса, а на ценности от високо ниво. Следването на тези ценности увеличава скоростта на развитие и бизнес въздействието на разработваните продукти.

Ето някои от ключовите разлики между Agile и традиционните методологии:

Гъвкавост и променливост

Обратна връзка и сътрудничество

Управление на риска

Участие на екипа

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

(adsbygoogle = window.adsbygoogle || []).push({});

Ценностите на Agile

• Променя се фокусът: насочва се върху хората и подобряването на комуникациите между тях, вместо да се изграждат свръхстроги процеси;
• Започва фокусиране върху продукта, вместо да се пише сложна проектна документация, която никой не чете;
• Вместо строгите и неудобни договорни условия, които клиентът е бил принуден да подписва, се изграждат истински партньорства и интерес към исканията и нуждите на клиента;
• Готовност за промени, защото е ясно, че светът около нас се променя и заедно с това отпадат или се прибавят изисквания към проекта.

В по-строга версия тезите са формулирани от бащите-основатели на гъвкавите методологии в документ, наречен Agile Manifesto:

• Хората и техните взаимодействия са по-важни от процесите и инструментите;
• Крайният продукт е по-важен от неговата документация;
• Сътрудничеството с клиента е по-важно от строгите договорни ограничения;
• Реагирането на промяната е по-важно от следването на план.

Принципи Agile

• Нашият най-висок приоритет е, да задоволим нуждите на клиента чрез ранно и постоянно доставяне на стойностен софтуер.
• Приветстваме променящите се изисквания, даже и в напреднал статий на разработка. Agile процесите прегръщат промяната в иметона конкурентното предимство на клиента.
• Често доставяне на работещ софтуер – между две седмици и два месеца – с предпочитание към по-кратките срокове.
• Хората на бизнеса и разработчиците трябва да работят заедно ежедневно през цялото време на проекта.
• Проекти се изграждат от мотивирани личности. Дайте им средата и подкрепата, от които се нуждаят и им гласувайте доверие, че ще свършат работата.
• Най-ефективният и най-ефикасен метод за предаване на информация към и вътре в екипа от разработчици, е разговорът лице в лице.
• Работещият софтуер е основната мярка на прогреса.
• Agile процесите насърчават непрекъснатата разработка. Спонсорите, разработчиците и потребителите трябва да могат да поддържат постоянен ритъм безсрочно.
• Постоянното внимание към техническо усъвършенстване и добрият дизайн подобряват гъвкавостта.
• Простотата – изкуството да се максимизира работата, която не е нужно да се върши – е от изключително значение.
• Най-добрите архитектури, изисквания и дизайни произлизат от самоорганизиращи се екипи.
• През равни интервали от време, екипът обсъжда какда стане по-ефективен, след което настройва работата си в съответствие с взетото решение.

Oсновни Agile методи и рамки

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

Гъвкавите спринтове са начин за управление на проект в гъвкава рамка.

Kак работят тези фази?

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

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

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

Има няколко Agile методи и рамки:

• Agile Scrum методология (или просто Scrum);
• Lean разработка на софтуер;
• Kanban;
• Екстремно програмиране (XP – Extreme Programming);
• Crystal;
• Метод за развитие на динамични системи (DSDM – Dynamic Systems Development Method);
• Разработка, управлявана от функции (FDD – Feature Driven Development)

Ще разгледам по-използваните от тях.

Agile Scrum методология

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

Роли в Scrum:

Product Owner (Собственик на продукта). Отговаря за дефинирането на изискванията и приоритетите на продукта, предоставя обратна връзка и въвежда нови функционалности.

Scrum Master. Отговаря за подпомагането на екипа да следва Scrum процеса, премахва преградите и насърчава комуникацията.

Development Team (Разработващ Екип). Група от разработчици, които работят заедно, за да създадат продукта. Те са самоорганизиращи се и отговарят за доставянето на работещи инкременти на продукта.

Scrum Events (Събития в Scrum):

1. Sprint – фиксиран период от време (най-често 2-4 седмици), през който екипът работи върху определен набор от функционалности и доставя работещ продукт.
2. Sprint Planning – среща в началото на всеки спринт, по време на която Product Owner дефинира работата, която трябва да бъде извършена, а екипът я планира и обвързва с конкретни задачи.
3. Daily Scrum (Daily Standup) – кратка среща всеки ден, по време на която екипът споделя какво е направено, какво ще бъде направено и какви препятствия са налице.
4. Sprint Review – среща в края на спринта, на която екипът представя завършените функционалности на заинтересованите страни.
5. Sprint Retrospective – среща след Sprint Review, по време на която екипът разглежда как работи и идентифицира начини за подобрение на процеса си.

Scrum Артефакти (носят информация за задачите, приоритета им и резултатите, които са набелязани за постигане):

1. Product Backlog – списък с всички задачи, които трябва да бъдат разработени в продукта.
2. Sprint Backlog – списък със задачите, които екипът се ангажира да завърши по време на текущия спринт.
3. Increment (Инкремент на продукта) – работещ продукт, който е добавен към продукта след всеки спринт.

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

(adsbygoogle = window.adsbygoogle || []).push({});

Lean разработката на софтуер (Lean Software Development)

Lean Software Development е методология за разработка на софтуер, която се базира на принципите на Lean Manufacturing. Тя се стреми да оптимизира процеса на разработка на софтуер, като използва принципите за елиминиране на излишък, ускоряване на процеса и постигане на максимална стойност за клиента. Методологията предлага седем принципа, които са много близки по концепция до принципите на Lean Manufacturing.

Принципи на Lean Software Development

Създаване на стойност (Create Value) – фокусиране върху създаването на стойност за клиента. Работа за предоставяне на функции, които задоволяват нуждите му.

Елиминиране на излишното (Eliminate Waste) – идентифициране и елиминиране на ненужните дейности, задачи или процеси, които не добавят стойност към продукта. Усилията са насочени към премахване на тези излишни неща, за да се повиши ефективността на разработката.

Управление на потока (Manage Flow) – оптимизиране на потока на работа в екипа, за да се намали времето, необходимо за разработка и внедряване. Стремеж към плавен и равномерен поток на работа във всички фази на развитие.

Увеличаване на ученето (Amplify Learning) – прегръщане на култура на непрекъснато учене. Учене от опита, грешките и обратната връзка, за да се подобряват непрекъснато процесите.

Решаване възможно най-късно (Decide as Late as Possible) – отлагане на решенията до последния отговорен момент, когато съществува най-много информация и разбиране на изискванията. Това позволява на екипа да се адаптира към променящите се условия и изисквания.

Доставяне възможно най-бързо (Deliver as Fast as Possible) – стремеж към бързо и често внедряване, за да се получава бърза обратна връзка от клиентите и да се адаптира бързо към техните изисквания. Това също намалява времето за излизане на пазара и повишава конкурентоспособността на продукта.

Оптимизиране на цялото (Optimize the Whole) – съсредоточаване върху оптимизирането на цялата система вместо върху отделни компоненти. Всички аспекти на развитието трябва да бъдат координирани и оптимизирани за по-голяма ефективност и предоставяне на стойност.

Практики в Lean Software Development

Канбан – визуална система за управление на работния поток, която помага в управлението на задачите и откриването на проблеми в процеса.

Just-In-Time (JIT) – постигане на производство и доставка на продукта точно в момента, когато той е необходим, за да се намали загубата от ненужни запаси и излишни стъпки.

Lean Thinking – прилагане на Lean принципите в разработката на софтуер, като се фокусира на стойността, потока, насърчаването на постоянно усъвършенстване и ангажирането на екипите.

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

Виж още: Намиране на мотивацията за работа: 7 научни изследвания обясняват как

Канбан – гъвкавост и визуален контрол

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

Основни Принципи на Канбан

1. Визуално управление – Канбан използва дъска с колони, представляващи различните фази на разработването (например „Чакащи“, „В Процес“, „Готови“). Задачите се визуализират като картички, които се придвижват през колоните в зависимост от статуса им.
2. Лимит на работния процес (WIP Limit) – определят се максимален брой задачи, които могат да бъдат в процес едновременно. Този лимит помага в управлението на потока на работа и предотвратява претоварване на екипа.
3. Приоритети и обратна връзка – Канбан позволява лесно установяване на приоритети чрез маркиране на важността на всяка задача. Обратната връзка с клиента или екипа се интегрира във визуалната система.
4. Непрекъснато подобрение – Канбан насърчава непрекъснатото усъвършенстване на процесите. Чрез анализ на визуалната дъска, екипът може да идентифицира проблеми и да извлече уроци за бъдещите итерации.

Предимства на Канбан

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

Екстремно програмиране (XP – Extreme Programming)

Екстремното програмиране (Extreme Programming или XP) е софтуерна методология, която се фокусира върху доставката на висококачествен софтуер чрез агресивни практики за управление на проекти. XP предлага набор от техники и принципи, целящи да подобрят сътрудничеството в екипа, качеството на кода и способността за адаптация към променящи се изисквания.

Основни принципи и практики на Екстремното програмиране

1. Сътрудничество с клиента (Customer Collaboration) – непрекъснато взаимодействие с клиента за ясно разбиране и адаптация на изискванията му.
2. Бързи итерации (Continuous Feedback) – разработване на софтуер в кратки, често двуседмични, итерации за бърза обратна връзка.
3. Тестване преди кодиране (Test-Driven Development – TDD) – създаване на тестове преди писане на кода, за да се гарантира функционалността и устойчивостта на приложението.
4. Подсигуряване на качество (Continuous Testing) – имплементиране на автоматизирани тестове, които се изпълняват автоматично всеки път, когато се направят промени в кода.
5. Рефакториране (Refactoring) – постоянно подобряване на кода, без да се променя функционалността му, за да се осигури чистота и поддръжка.
6. Сътрудничество в екип (Collaboration) – силно сътрудничество между програмистите, тестерите и клиента, за да се гарантира ефективност и разбирателство.
7. Простота (Simplicity) – избягване на излишества и сложности, съсредоточавайки се върху основните функционалности.
8. Непрекъсната интеграция (Continuous Integration) – интегриране на кода на всеки участник в екипа непрекъснато, за да се предотвратят конфликти и да се осигури стабилност.

Предимства на Екстремното програмиране

1. Гъвкавост и адаптивност – способността да бъде бързо адаптирана към изменящи се изисквания прави XP подходящ за проекти с висока степен на несигурност.
2. По-високо качество – систематичното тестване и рефакторирането гарантират високо ниво на качество и намаляват броя на бъговете.
3. Устойчиви проекти – процесите за непрекъсната интеграция и тестване гарантират устойчивост на проектите при въвеждане на нов функционалност.
4. Повишаване на продуктивността – насочването към ефективност и сътрудничество води до по-голяма продуктивност и бързина в разработката.

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

Виж още: Фокусът е избор, целта е по-важна от препятствието

Crystal методология в Agile

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

Основни принципи

1. Сътрудничество и комуникация – подчертава значението на комуникацията и сътрудничеството в екипа и с клиента. Отворената и ефективна комуникация е ключова за успеха на проекта.
2. Способност за адаптация – подчертава гъвкавостта и способността за адаптация към променящите се изисквания и условия.
3. Широк спектър от кристали – вместо да предлага една универсална методология, предоставя няколко „кристала“ (например, Кристал Клиър, Кристал Жълт и други), които се адаптират към конкретните характеристики на проекта.
4. Оптимизиране за човешкия фактор – подчертава важността на човешкия фактор в разработката на софтуер. Тя се фокусира върху хората и тяхната способност да работят заедно ефективно.
5. Непрекъснато усъвършенстване – подпомага непрекъснатото усъвършенстване на процесите и екипната работа. Обратната връзка и рефлексията са ключови компоненти в този процес.

Приложение на Кристалната методология

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

(adsbygoogle = window.adsbygoogle || []).push({});

Области на приложения на Agile

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

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

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

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

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

Заключение: мястото на Agile сред родствени управленски подходи

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

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

Agile също е събирателно име за много различни подходи към управлението на разработката, някои от които дори не споделят всичките 4 ценности на Agile (пример е Kanban).

Agile се фокусира конкретно върху разработката – по-точно върху внедряването и доставката на готови продукти. Докато за генериране и тестване на идеи за нови продукти, Agile трябва да бъде допълнен с различни продуктови подходи: Customer Development, Design Thinking и др.

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

За подходи за ускоряване на ниво програма и портфолио от проекти (в големи организации) е по-подходящо да се използва терминът Enterprise Agility, въпреки че в много контексти те също се наричат Agile.

Що се отнася до подходите за увеличаване на гъвкавостта / бързината на вземане на решения на ниво целия бизнес, това е много по-широко от Agile. За обозначаване на такива подходи трябва да се използва терминът Business Agility, който стана популярен в края на 2010 г. Бизнес гъвкавостта включва не само бързо предоставяне на стойност на клиентите и бързо реагиране на промените, но и гъвкавост при поставяне на цели и разпределение на ресурсите в рамките на организацията.