Гъвкави методологии (на английски: agile methodologies) за разработка на софтуер са набор от методологии и програмни техники при програмиране, софтуерна разработка и управление на софтуерни проекти. Както подсказва и името (на английски:agile: able to think and understand quickly, able to move quickly and easily), във фокуса на гъвкавите методологии е идеята, че разработката на софтуер е продължителен, понякога доста динамичен процес, в който дългосрочното планиране има желаната ефективност.

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

Част от практиките на гъвкавите методологии намират приложение и в други сфери на ИКТ и бизнеса.

Гъвкавата методология за разработка на софтуер се състои от група методи при създаването на софтуер, базирани на постепенно и повтарящо в своите фази разработване на софтуер. Към това софтуерните спецификации и решения се развиват на етапи чрез сътрудничество между донякъде самоорганизиращи се екипи, съставени от хора с различни функции. Гъвкавата методология насърчава адаптивно планиране, еволюираща разработка, а после и кодиране, и релийз на софтуера, времево-разпределен итеративен подход, продължаващо подобрение и поощрява бързото, и гъвкаво реагиране на настъпващи промени. Това е концептуална рамка, която насърчава взаимодействия, които са предвидени, през цялото времетраене на разработката на софтуерни проекти. Терминът от английски, agile software development, е въведен през 2001 година в The Agile Manifesto.

Британската организация за сертификации BVOP през 2018 година разширява разбирането гъвкава методология, като комбинира няколко йерархически практики и инструменти за управлението на проекти. Добавя и съвременни принципи и правила от продуктовото управление.

История

Предшественици Инкременталните методи за разработка на софтуер възникват през 1957.Gerald M. Weinberg, as quoted in През 1974 г. E. A. Едмъндс въвежда идеята за адаптивен процес на разработка на софтуер в своя статия. Едновременно и независимо, същите методи са разработени и разгърнати от New York Telephone Company's Systems Development Center под ръководството на Дан Гийлан. В началото на 1970 г. Том Гилб започва публикуването на концепцията за еволюционно управление на проекти (Evolutionary Project Management – EVO), която впоследствие се трансформира в т.нар. конкурентно инженерство. От средата до края на 1970 Гийлан дава лекции из различни щати на САЩ върху методологията, нейните практики и ползи. 

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

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

Ранните реализации на гъвкавите методи включват Rational Unified Process (1994), Scrum (1995), Crystal Clear, Екстремно програмиране (1996), Adaptive Software Development, Feature Driven Development, и Dynamic Systems Development Method (DSDM) (1995). Всички те сега са класифицирани като гъвкави методологии, след публикуването на Манифеста на гъвкавите методологии (Agile Manifesto) през 2001 година.

Манифест на гъвкавата методология (The Agile Manifesto) През февруари 2001 г. 17 разработчици на софтуер, сред които Уорд Кънингам и Мартин Фаулър,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, Stephen J. Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas се срещат в курорта Сноубърд, Юта, за да обсъдят гъвкавите методи за разработка. Публикуват Манифест на гъвкавите методологии, който дефинира подходите, сега известни като гъвкави методи за разработка на софтуер. Част от авторите на манифеста създават The Agile Alliance, неправителствена организация, която насърчава разработката на софтуер в съответствие с принципите на манифеста.

Манифестът на гъвкавите методологии гласи следното:

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

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

Хора и комуникация – според гъвкавата методология самоорганизацията и мотивацията са важни, като например работата в съвместно помещение и програмиране по двойки. Работещ софтуер – работещият софтуер е по-полезен по време на срещи с клиента, отколкото представянето на документация по проекта. Сътрудничество с клиента – софтуерните спецификации не могат да бъдат изцяло изготвени в началото на проекта, затова непрекъснатото участие на всички заинтересовани страни е ключово. Адресиране на промените – гъвкавата методология за разработка се фокусира над бърза реакция към промените и непрекъснато развитие.Ambler, S.W. „Examining the Agile Manifesto“. Посетен на 6 април 2011.

The Agile Manifesto се основава на дванадесет принципа:

Удовлетворение на клиентите чрез бърза доставка на полезен софтуер Промяна в спецификациите е възможна, дори и в късните фази на проекта Често предоставяне на работещ софтуер (в периоди от седмици, а не месеци) Работещият софтуер е основната мярка за напредък Устойчиво развитие, което успява да поддържа постоянно темпо Тясно, ежедневно сътрудничество между бизнес служители и разработчици Разговорите лице в лице са най-добрата форма на комуникация (съвместна локация) Проектите се изграждат около мотивирани хора, на които се има доверие Непрекъснато внимание към техническо съвършенство и добър дизайн Простота – изкуството максимално количество работа да бъде пропусната, е от съществено значение Самоорганизиращи се екипи Редовна адаптация към променящи се обстоятелства

През 2005 г. група начело с Алистър Кокбърн и Джим Хайсмит написва допълнение към принципите за управление на проекти, наречено „Декларацията на взаимозависимост“ (Declaration of Interdependence), със съвети за управлението на софтуерни проекти в съответствие с гъвкави методи за разработка.

През 2009 г. движение, ръководено от Robert C. Martin разширява принципите за разработка на софтуер според гъвкавата методология (Software Craftsmanship Manifesto) в съответствие с професионалната етика и майсторство.

През 2011 the Agile Alliance създава Guide to Agile Practices (и Agile Glossary), е развиващ се open-source компендиум от работни дефиниции за agile практиките, термините, елементите и заедно с интерпретациите и препоръките за самата практика, което е направено от международната agile общност от разработчици.

Характеристики

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

Гъвкавите методи разбиват задачите на малки стъпки с минимално планиране, без да засягат дългосрочното планиране на проекта. Итерациите (етапите) стават на кратки срокове (timeboxes), които обикновено траят от една до четири седмици. През всяка итерация екипът, съставен от хора с различни функции, работи по всяка една от функциите: планиране, анализ на изискванията, проектиране, разработка, тестване и проверка при приемане. В края на итерацията работещият софтуер се представя пред заинтересованите страни. Така се намалява цялостния риск и проектът може да бъде адаптиран бързо към промени. Една итерация може да не добавя достатъчно функционалност, за да обоснове пускане на пазара, но целта е да съществува работещо решение (с минимални грешки) в края на всяка итерация. За да се завърши даден софтуер или функционалност, могат да бъдат нужни множество итерации.

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

Обща характеристика на гъвкавите методи за разработка са ежедневните срещи относно напредъка на проекта или т.н. стенд-ъп срещи (stand-ups). По време на кратката среща, членовете на екипа докладват пред всички какво са направили предишния ден, какво възнамеряват да правят днес и има ли нещо, което ги възпрепятства да свършат задачите си.

Специфични инструменти и техники, като например, непрекъсната интеграция, автоматизирано компонентно тестване, програмиране по двойки, разработка чрез тестове (test-driven development), шаблони за дизайн (design patterns), дизайн според сферата (domain-driven design), преработка на код (code refactoring) и други техники, често се използват за подобряване на качеството и повишаване на гъвкавостта на проекта.

В гъвкавите методологии за разработка на софтуер се използват информационни радиатори (напр. дъска с листчета) – те онагледяват физически прогреса на проекта на видно място в офиса, където минувачите могат да го видят. Представляват актуално обобщение на състоянието на един софтуерен проект или друг продукт. Името е въведено от Алистър Кокбърн и е описано в неговата книга от 2002 година, „Гъвкава разработка на софтуер“. Могат да бъдат използвани и светлинни индикатори, информиращи екипа за текущото състояние на проекта.

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

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

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

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