Какво е Agile?
Къде се прилага Agile?
КАКВО Е AGILE
Каква е историята на Agile и какво точно означава?
Буквалният превод на „agile“ е „пъргав“. Понятието „Agile“ се използва в много области, включително Agile Manufacturing, Business Agility и други, но тук нашият фокус е върху гъвкавите (agile) методи за управление на проекти.
Agile подходите възникват при разработването на софтуер. От 50-те години на 20-ти век в тази област започват да се прилагат еволюционни и адаптивни подходи, като контрапункт на тежките методи, залагащи на подробното първоначално планиране и стремеж планът да се изпълни възможно най-точно.
През 90-те години на 20-ти век възникват редица подходи за гъвкаво разработване на софтуер, като Rapid Application Development (RAD) през 1991, Dynamic Systems Development Method (DSDM) през 1994, Scrum през 1995, Extreme Programming (XP) през 1996 и Feature-Driven Development (FDD) през 1997. Някои от тях като, XP и FDD, са ориентирани повече към процеса на разработване, отколкото към управлението на процеса на разработване. Други, като Scrum и DSDM, са ориентирани изцяло към управлението на процеса на разработване, тоест към управлението на проекти.
През 2001 г., седемнайсет водещи експерти в гъвкавото разработване на софтуер публикуват Manifesto for Agile Software Development (Манифест за гъвкаво разработване на софтуер), известен и като Agile Manifesto. Манифестът дава силен тласък на гъвкавото разработване на софтуер и на други видове продукти, както и на гъвкавото управление на проекти, което е приложимо и в области извън софтуера.
Манифест
за гъвкаво разработване на софтуер
Ние откриваме по-добри начини за разработване на софтуер, като го правим и помагаме на другите да го правят.
В процеса на работата, стигнахме до извода, че трябва да ценим:
Хората и взаимодействията повече от процесите и инструментите
Работещия софтуер повече от пълната документация
Сътрудничеството с клиентите повече от преговорите за сключване на договор
Реагирането на промените повече от следването на плана
Така че, докато има стойност в нещата отдясно, ние ценим повече нещата отляво.
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
Източник: https://agilemanifesto.org
Една от най-често срещаните дефиниции за Agile в контекста на разработването на продукти и управлението на проекти е, че Agile e начин на мислене в съответствие с принципите на Манифеста на Agile.
Използвайки тази дефиниция, можем да кажем, че отличителните черти на гъвкавото управление на проекти са:
- Фокус върху хората и техните взаимодействия
- Фокус върху създаването на стойност
- Фокус върху адаптивността
Като контраст, характерните черти на традиционното управление на проекти са:
- Фокус върху процесите и инструментите
- Фокус върху създаването на продуктите на проекта в рамките на срока и бюджета
- Фокус върху създаването на възможно най-добър план и неговото следване
КЪДЕ Е ПРИЛОЖИМ AGILE
В какви проекти може да се използва Agile?
Agile е адаптивен и еволюционен подход. Традиционното управление на проекти е детерминистичен подход, който се стреми да управлява чрез планиране.
Според насоките на Манифеста, Agile е приложим за всякакви видове проекти, с всякакъв вид продукти на проекта.
Погрешно се смята, че Agile не е приложим за проекти с физически продукти, тъй като при тях не може да се приложи итеративен подход. Погрешно се смята също така, че Agile не е приложим за проекти, в които всички изисквания към продуктите на проекта могат да се определят предварително.
Приложим ли е Agile при неитеративното създаване на продукти?
Итерация (iteration) означава повторение на даден процес. При софтуера, итерация означава нова (по-добра) версия.
Итеративното разработване предполага създаване на последователни версии на един продукт, като всяка версия преминава през целия цикъл на разработване (напр. планиране, дизайн, разработване и тестване). То обикновено се съчетава с постепенно надграждане на функциите и характеристиките на последователните версии – това се нарича инкрементален (добавящ, нарастващ) подход.
Итеративният подход дава възможност за по-бързо получаване на стойност, когато клиентът започне да използва първите, макар и несъвършени версии на продукта. И нещо изключително важно – този подход дава възможност за ранна и бърза обратна връзка за продукта, за вземане на решение за посоката на неговото развитие и за адаптиране на продукта към променящите се условия и към по-добре осъзнатите нужди на клиента.
От гледна точка на Agile, итеративният подход е страхотен инструмент за постигане на адаптивност и за създаването на повече стойност. Този инструмент може да се приложи при създаването на всякакви продукти, когато резултатът от разработването е информация – независимо дали тя има формата на програмен код или на документация, описваща продукта. Например – документация, описваща физически продукт, който ще се произвежда, технически проект на сграда или съоръжение, дизайн на маркетингова кампания, организационна структура, транспортен маршрут и т.н.
Разбира се, (в повечето случаи) итеративният подход не може да се използва за създаване на продукти на проекта, които имат физическа форма. Типичен пример за това са крайните продукти на строителните проекти. Това дава основание на редица специалисти по управление на проекти да твърдят, че Agile не е приложим за такива проекти. Красноречив пример, който посочват е, че с Agile не може да се построи къща.
Ето как може да протече един разговор на тема „Agile“:
A: „Кажете ми как може да се приложи Agile при построяването на къща!“
Б: „Когато стаите са готови, можете да поканите клиента, за да избере къде точно да бъдат монтирани осветителните тела.“
А: „Как да стане това, когато мястото на осветителните тела е ФИКСИРАНО в работния проект и разрешението за строеж и след като електрическата инсталация ВЕЧЕ е изградена до точките за монтаж?!?“
Подобна дискусия показва ограничено разбиране за Agile и от двете страни.
Ако заменим „софтуер“ с „къща“ и „разработване“ с „изграждане“ в Манифеста на Agile, ще видим, че той продължава да бъде на 100% приложим и при построяването на къща.
Друг пример, в който итеративният подход не може да се приложи, са проектите с право на „един изстрел“ (в превод на английски - single shot projects)*, като тези за организиране на събития, провеждане на кампании и мисии, преместване на офис или производство в нова сграда. Имаме само една възможност да извършим ключовите дейности в такива проекти. Те изискват голяма гъвкавост и адаптивност в рамките на строги ограничения.
Използването на итеративен подход не е задължително, за да бъде определен един метод за управление на проекти като гъвкав (адаптивен).
Итеративният подход е инструмент за адаптивност, който се прилага с голям успех, когато е възможно, но той не е единственият възможен инструмент. В проектите с физически продукти и с право на „един изстрел“, адаптивността може бъде постигната с редица други подходи (например тези в Lean Project Management) и когато тя е налице, тези проекти се управляват гъвкаво.
* Ако не сте чували за проекти с право на „един изстрел“ / single shot projects, причината е, че този термин е измислен специално за тази публикация на Agile.bg.
Приложим ли е Agile при проекти с ясно определени изисквания?
От гледна точка на яснотата на изискванията, продуктите на един проект могат да бъдат три вида:
- Продукти с ясни изисквания
- Продукти, за които очакванията на клиента и изискванията се доизясняват в процеса на работата по проекта
- Продукти, чиито характеристики се определят чрез проучвания и експерименти по време на проекта
Пример за втория вид продукти е софтуерът по поръчка, а за третия вид – новите продукти, разработвани от стартиращи компании. За тези видове продукти типично се използва итеративно и инкрементално разработване, чрез което се намалява несигурността по отношение на изискванията. С продуктите от втори и трети вид са свързани съответно подходите Agile Development и Lean Startup.
Типичен пример за първия вид продукти са сградите и съоръженията, за които има разработени и одобрени технически проекти. Изискванията са вече ясни и фиксирани, макар че на практика те рядко остават такива до края на проекта.
Но нека предположим, че изискванията действително са ясни и фиксирани. Това означава, че няма несигурност по отношение на изискванията и не е необходимо да се адаптираме. Следователно, в този случай няма нужда от гъвкав, адаптивен и еволюционен подход за управление на проекти.
Но разбира се, има едно голямо „НО“.
Проектът е инициатива, за която е характерна определена степен на уникалност, което води до несигурност - по-голяма от тази в една текуща дейност.
Изискванията към продуктите на проекта са само един от възможните източници на несигурност!
Други възможни източници на несигурност в проекта са:
- Несигурност по отношение на наличието на ресурси
- Несигурност по отношение на производителността на екипа
- Несигурност по отношение на процеса на създаване на продуктите на проекта
- Несигурност по отношение на цените на ресурсите
- Несигурност по отношение на обема на работата
- Несигурност по отношение на ползите от проекта
- Несигурност по отношение на външните зависимости на проекта
- Несигурност по отношение на приоритета на проекта
- Несигурност по отношение на средата на проекта
Следователно, всеки проект, независимо дали има или няма ясни и фиксирани изисквания, има нужда от адаптивен (agile) подход, от адаптивно (agile) управление на проекти!
Друг е въпросът, че Agile (все още) се свързва най-вече с разработването на софтуер и че адаптивните подходи в други области са брандирани с „Lean” – Lean Product Development, Lean Construction, Lean Startup и най-общото Lean Project Management (например LeanPM Framework). Lean и Agile са тясно свързани и можем да говорим за Lean-Agile управление на проекти. Вижте повече за тази взаимовръзка по-долу.
Заключение
От казаното по-горе можем да направим извод, че адаптивното Lean-Agile управление на проекти е приложимо и актуално за всички видове проекти, в противовес на традиционното „предвидимо“ (predictive) управление на проекти.
AGILE И LEAN
Каква е взаимовръзката между Agile и Lean?
Lean и Agile споделят общ еволюционен, адаптивен и ориентиран към хората начин на мислене и Agile е повлиян от Lean.
Както казва Martin Fowler, един от авторите на Манифеста на Agile:
“You don't do agile or lean you do agile and lean.”
Прочетете повече по този въпрос тук: https://martinfowler.com/bliki/AgileVersusLean.html
Lean e един от основните източници за развитие на скалираните рамки за гъвкаво разработване като SAFe и LeSS и на набора с инструменти Disciplined Agile. Lean мисленето (lean thinking), заедно с емпиризма, стои в основата на рамката Scrum.
Lean Project Management е сравнително ново направление в управлението на проекти. Негов фокус са създаването на стойност, намаляването на разхищенията (waste), непрекъснатите подобрения, адаптивността и хората. Рамки като LeanPM предлагат подходи за адаптивност и по-успешно управление на всички видове проекти.
СЕРТИФИЦИРАНЕ ПО AGILE
Какви са възможностите за обучение и сертифициране по Agile?
В световен мащаб има множество възможности за сертифициране по гъвкави методи за разработване на продукти и в известна степен - и за гъвкаво управление на проекти.
Ето някои от тези възможности в България:
Искаме да чуем Вашето мнение!
Какво мислите за Agile? Съгласни ли сте с написаното по-горе?
Моля коментрайте!