Гъвкава методология за разработка на софтуер

Гъвкави методологии (на английски: 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. През 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 година.
През февруари 2001 г. 17 разработчици на софтуер, сред които Уорд Кънингам и Мартин Фаулър, се срещат в курорта Сноубърд, Юта, за да обсъдят гъвкавите методи за разработка. Публикуват Манифест на гъвкавите методологии, който дефинира подходите, сега известни като гъвкави методи за разработка на софтуер. Част от авторите на манифеста създават The Agile Alliance, неправителствена организация, която насърчава разработката на софтуер в съответствие с принципите на манифеста.
Манифестът на гъвкавите методологии гласи следното:
Значенията на елементите от лявата част на горните твърдения са описани тук:
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 месеца по-късно, един адаптивен екип би могъл да заяви единствено заложените във версията характеристики или очакваната стойност срещу цената.
За разлика от тях планиращите методи се фокусират върху детайлното анализиране и планиране на бъдещето и справяне с предвидимите рискове. В крайности, един планиращ екип може да даде точен списък на функционалностите и задачите, планирани в целия ход на процеса на разработка. Планиращите методи разчитат на пълен ефективен предварителен анализ и ако той се окаже погрешен, проектът може да изпита съществени затруднения и да промени посоката си на развитие. Планиращите екипи често определят комисия по контрол на промените (change control board), която да гарантира разглеждането само на най-смислените промени.
За разлика от адаптивните и планиращите методи, формалните методи прилагат теорията на информатиката и широк спектър от подходи за формална проверка за коректност. Един формален метод цели доказването на коректност с определена степен на детерминизъм. Някои формални методи са базирани на проверка за непротиворечивост на модела и намират контра-примери в случаите, когато непротиворечивостта не може да бъде доказана. Гъвкавите методи може да прилагат формални методи с висока степен на строгост.
През 2008 Институтът за софтуерно инженерство (Software Engineering Institute, SEI) публикува техническия доклад „CMMI or Agile: Why Not Embrace Both“, за да подчертае, че подходът Capability Maturity Model Integration и гъвкавите методологии могат да бъдат комбинирани. CMMI Version 1.3 включва съвети за съвместното прилагане на гъвкавите методологии и CMMI. Една от разликите между гъвкавите методи и методът на водопада е, че тестовете на софтуера се провеждат на различни етапи от цикъла на разработката на софтуера. В метода на водопада има отделна фаза на тестване малко преди имплементацията. В гъвкавото екстремно програмиране тестовете се провеждат едновременно с имплементацията.
Екстремно програмиране (Extreme Programming – XP) e друг вид методология за създаване на софтуер. Основната цел на XP е да редуцира цената на проект, ако се наложи дадена промяна. Оттук се вади извода, че XP е методология, подходяща да се използва при проекти, които имат често променящи се изисквания и при които по-стандартни методологии (като Waterfall модела например) не са оптимални за постигане на голяма продуктивност; подходяща е при проекти, които включват нови технологии или непредвидими проблеми, свързани с имплементацията; използва се също така при по-малки и по-лесни за реализация проекти с неофициални методи; добра технология за проекти, изискващи изследване.
Scrum е процес, използван при изготвяне и управление на големи проекти. Той е разработен с цел дългосрочното планиране на изработването на даден продукт да бъде улеснено значимо. За разлика от типичния мениджмънт чрез контрол и командване, при Scrum процесите се набляга на обратната връзка и се дава повече власт на хората, вършещи „черната работа“.
Канбан е метод за управление на интелектуални дейности с наблягане на доставката точно на време, без същевременно членовете на екипа да са пренатоварени. Името произлиза от японски и буквално преведено означава „сигнална карта“. Методът, както е формулиран от Дейвид Андерсън, е подход към постепенен, еволюционен процес. Използва система за ограничаване на текущата работа като основен механизъм, за да разкрива системно операционни проблеми и да стимулира взаимопомощта, с цел продължително подобряване на системата.
Терминът Lean софтуер разработване произлиза от едноименната книга, написана от Мери Попендийк и Том Попендийк. Книгата представя традиционните lean принципи в модифициран формат, както и набор от 22 инструмента и ги сравнява с гъвкавите практики. Участието на Попендайови в обществото на гъвкавото софтуерно разработване, включително и беседи на няколко конференции, се отразява на приемането на различни концепции сред въпросната общност.
Има различни термини, които се отнасят до понятието „адаптация на метод“, включително „'method tailoring“, 'method fragment adaptation' и „'situational method engineering'. Адаптирането на методи се определя като:
Потенциално, почти всички гъвкави методи са подходящи за адаптиране. Дори DSDM методът се използва за тази цел и е успешно приспособен в CMM. Целесъобразността със ситуацията може да се счита като отличителна разлика между гъвкавите методи и традиционните методи за разработка на софтуер, като последните са относително по-строги. Изводът е, че гъвкавите методи позволяват на различни екипи да адаптират ежедневните си практики в съответствие с нуждите на отделните проекти. Като практики формулираме конкретни дейности или продукти, които са част от структурата на един метод. На по-крайно ниво, философията на този метод, състояща се и от редица принципи, може да се адаптира (Aydin, 2004).
Екстремното програмиране (XP) прави нуждата от адаптиране на методите изрична. Една от основните идеи на XP е, че не всеки процес може да се впише в определен проект, а по-скоро практиките трябва да бъдат съобразени с нуждите на отделните проекти. Частичното приемане на XP практики, предложено от Kent Beck, е съобщавано няколко пъти.
Mehdi Mirakhorli предлага метод за адаптиране, който осигурява достатъчно насоки за адаптиране на всички практики. RDP практиката е предназначена за персонализиране на XP. Тази практика е предложена за първи път на APSO workshop, през конференцията ICSE 2008 и е единственият приложим метод за персонализиране на XP. Въпреки че това е специализирано решение за XP, тази практика има възможност за включване и в други методологии. На пръв поглед тази практика изглежда е в категорията на статичните методи за адаптация, но опитът с практиката на RDP показва, че тя може да бъде третирана и като динамичен метод. Разликата между статичния метод и динамичния е едва доловима.
Ключово предположение за статичния метод за адаптация е, че контекстът на проекта е даден в началото му и остава фиксиран по време на изпълнението на проекта. Резултатът е статично определение на контекста. Като се има предвид това, може да се определи, кои от основните фрагменти на метода трябва да се използват за конкретен проект, а също и въз основа на предварително определени критерии.
Динамичният метод за адаптация, напротив, предполага, че проектите са разположени в един неочакван (пораждащ се) контекст. Това означава, че един проект трябва да се справя с възникващите фактори, които засягат съответните условия и не са предсказуеми. Това също така означава, че контекстът на даден проект не е фиксиран, а се променя в процеса на изпълнение. В такъв случай препоръчителните карти не са подходящи. Практическата последица от динамичния метод е, че ръководителите на проекти често се налага да променят структурирани фрагменти или дори нововъведени такива по време на изпълнение на проекта.
Методите за разработка съществуват в континуум от „адаптивни“ до „предсказуеми“ или предиктивни. Agile методите за разработка на софтуер се намират в „адаптивни“ страна на този континуум.
„Адаптивните“ методи са насочени към бързо адаптиране към променящите се реалности. Когато нуждите на проекта се променят, адаптивният екип се променя. Но понякога адаптивният екип има затруднения да опише точно какво ще се случи в бъдеще и колкото по-далеч е датата, толкова по-неясен става адаптивният метод за това какво ще се случи на тази дата. Тук се намесват „прогностичните“ методи, напротив, се съсредоточават върху подробния анализ и планиране на бъдещето и отчитат известни рискове. В крайни случаи екипът за прогнозиране може да информира точно какви функции и задачи са планирани за целия период на процеса на разработка. Методите за прогнозиране се основават на ефективен анализ на ранен етап и ако това се обърка напълно, проектът може да има трудности при промяна на посоката. Екипите за прогнозиране често създават съвет за контрол на промените, за да гарантират, че отчитат само най-ценните промени.
Една от разликите, които се пораждат между софтуерната разработка при agile и waterfall / методологиите тип Водопад, или каскадни методологии е поне в най-видимата част подходът към качеството и тестването. Пре agile методологиите тестването, макар и подробно се движи след разработката, докато при водопадния модел, тестовата фаза се движи успоредно с дивелопмънта, в постоянни фази на кодиране – тестване. Или дори при водопадния подход подготовката за тествовите cases може да е преди и предхожда самият процес на разработка. Макар водопадния модел да изглежда подтикващ към добри резултати за процеса на разработка и тестване, в действителност agile включва повече мениджърска работа, което значи, че двата модела са по-скоро съсредоточени в раличните отдели, тоест когато agile методологията, когато е подвключваща waterfall, тя е по-икономически продуктивна, по-адаптивна и т.н.
Гъвкавите методи са насочени към различни аспекти от жизнения цикъл на софтуерната разработка. Някои се фокусират върху практиката (екстремно програмиране, прагматично програмиране, гъвкаво моделиране), докато други наблягат върху управлението на софтуерни проекти (Scrum). И все пак, има подходи, покриващи целия цикъл на една софтуерна разработка (динамични системи за развитие, или DSDM, IBM Rational Unified Process, или RUP), докато други са повече насочени към отделните етапи на разработка (feature-driven development или FDD).
Следователно, налице е ясна разлика между различните гъвкави методи за разработка на софтуер в това отношение. DSDM и RUP не се нуждаят от допълнителни подходи в разработването на софтуер, а други – в различна степен. DSDM може да се използва от всеки (макар само DSDM членове да могат да предлагат DSDM продукти или услуги). RUP, обаче, е комерсиално насочена среда за разработка (Abrahamsson, Сало, Rankainen & Warsta, 2002).
Agile методологии могат да бъдат разглеждани като средство за постигане на определена цел в софтуерния процес на разработка, така че множество подходи са разработени постигане на това и за количественото им характеризиране.
Индексът Agility Index Measurements (AIM) оценява проектите според група от фактори.
Характеристиката с подобно име – Agility Measurement Index, измерва процеса на разработка спрямо пет измерения на един софтуерен проект: продължителност, ниво на риск, иновативност, усилие и интерактивност.
Други подходи се базират на измерими цели.
Разработки на базата на размити множества и размита логика предлагат като мярка за оценка на степента на гъвкавост на един проект да бъде използвана скоростта му на развитие.
Съществуват подходи за самооценка на един екип спрямо това дали и доколко използва гъвкавите методологии (Nokia test, Karlskrona test, 42 points test).
Въпреки гореописаните опити за оценка, практическото им приложение все още предстои да бъде оценено. Допълнителни данни могат да бъдат намерени на CSIAC ROI Dashboard.
Едно от най-ранните проучвания, доказващи по-високите печалби и подобрения в производителността на бизнеса чрез използване на гъвкави методи, е проведено от Shine Technologies от ноември 2002 до януари 2003 г. В подобно проучване, проведено през 2006 г. от Скот Амблър, обучаващ по Гъвкави методологии в компанията IBM Rational's Methods Groupe, е докладвано за същите ползи. Други твърдят, че гъвкавите методи за разработка са все още твърде малко развити, за да е необходим широк академичен анализ на тяхната успешност.
Широкомащабната гъвкава разработка в софтуерната индустрия продължава да бъде една активна изследователска област.
Гъвкавите методологии са широко разглеждани и като по-подходящи за определени видове среди, включително малки екипи от експерти.
Към тях се наблюдава положителна нагласа в Европа в сферата на embedded системите през последните години.
Някои от нещата, които могат да повлияят негативно на успеха на един проект, са:
Ранните успехи, предизвикателствата и ограниченията, възникнали при приемането на гъвкави методи в голяма организация, са документирани.
По отношение на „аутсорсинг методологията“, Michael Hackett, старши вицепрезидент на LogiGear Corporation заявява – „офшорните екипи ... трябва да имат опит, добри комуникативни умения, междукултурно разбирателство, доверие и разбирателство между групите и помежду членовете им.“
Гъвкавите методи са широко използвани за разработване на софтуерни продукти и някои от тях използват определени характеристики на софтуера (като обектните технологии например. Въпреки това, тези техники могат да бъдат приложени за развитието на не-софтуерни продукти, като например компютри, моторни превозни средства, медицински изделия, храни, облекла и т.н.
Анализът на риска (Risk analysis) също може да бъде използван за избор между адаптивни (agile или value-driven) и планиращи (plan-driven) методи. Barry Boehm и Richard Turner застъпват разбирането, че всяка част от спектъра има своята „територия“ и приложимост, както следва:
Гъвкавите методологии могат да бъдат неефективни в големи организации и при някои видове проекти (вж. точка „Приложимост“). Най-добре е да се използват за развиващи се и непоследователни проекти. Много организации смятат, че гъвкавите методологии са твърде крайни и приемат хибриден вариант, който смесва елементи на гъвкави и планиращи подходи.
Agile също са критикувани от множество наблюдатели като каприз на мениджмънта – термин, използван за характеризиране на промяна във философията или операциите, извършени от предприятие или институция. Този термин е субективен и има тенденция да се използва в отрицателен смисъл, тъй като това означава, че тази промяна се прилага само, защото по това време е „модерна“ в управленските среди, а не непременно поради някаква реална необходимост от организационна промяна. Опитът показва, че след като основната философия вече не е „популярна“, тя ще бъде заменена с най-новите „популярни“ идеи, по същия начин, както предишната идея.