Направо към съдържанието

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

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

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

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

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

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

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

История

[редактиране | редактиране на кода]
Дейв Томас говори на трибуната на Пасадена Студио
Мартин Фоулър един от основателите на гъвкавата методология

Предшественици

[редактиране | редактиране на кода]

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

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

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

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

Манифест на гъвкавата методология (The Agile Manifesto)

[редактиране | редактиране на кода]

През февруари 2001 г. 17 разработчици на софтуер, сред които Уорд Кънингам и Мартин Фаулър,[7] се срещат в курорта Сноубърд, Юта, за да обсъдят гъвкавите методи за разработка. Публикуват Манифест на гъвкавите методологии,[1] който дефинира подходите, сега известни като гъвкави методи за разработка на софтуер. Част от авторите на манифеста създават The Agile Alliance, неправителствена организация, която насърчава разработката на софтуер в съответствие с принципите на манифеста.

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

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

  • Хората и комуникацията стоят над процесите и инструментите
  • Работещият софтуер е над подробната документация
  • Сътрудничеството с клиента е над преговорите по време на сключване на договора
  • Адресирането на промените стои над следването на плана

Това означава, че въпреки че десните елементи имат своята стойност, ние ценим точките отляво повече.[1]

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

  • Хора и комуникация – според гъвкавата методология самоорганизацията и мотивацията са важни, като например работата в съвместно помещение и програмиране по двойки.
  • Работещ софтуер – работещият софтуер е по-полезен по време на срещи с клиента, отколкото представянето на документация по проекта.
  • Сътрудничество с клиента – софтуерните спецификации не могат да бъдат изцяло изготвени в началото на проекта, затова непрекъснатото участие на всички заинтересовани страни е ключово.
  • Адресиране на промените – гъвкавата методология за разработка се фокусира над бърза реакция към промените и непрекъснато развитие.[8]

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

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

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

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

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

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

[редактиране | редактиране на кода]
Програмиране по двойки, гъвкава техника, използвана в Екстремно програмиране. Забележете „информационните радиатори“ (information radiators) във фона.

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

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

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

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

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

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

Сравнение с други методологии

[редактиране | редактиране на кода]

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

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

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

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

За разлика от тях планиращите методи се фокусират върху детайлното анализиране и планиране на бъдещето и справяне с предвидимите рискове. В крайности, един планиращ екип може да даде точен списък на функционалностите и задачите, планирани в целия ход на процеса на разработка. Планиращите методи разчитат на пълен ефективен предварителен анализ и ако той се окаже погрешен, проектът може да изпита съществени затруднения и да промени посоката си на развитие. Планиращите екипи често определят комисия по контрол на промените (change control board), която да гарантира разглеждането само на най-смислените промени.

За разлика от адаптивните и планиращите методи, формалните методи прилагат теорията на информатиката и широк спектър от подходи за формална проверка за коректност. Един формален метод цели доказването на коректност с определена степен на детерминизъм. Някои формални методи са базирани на проверка за непротиворечивост на модела и намират контра-примери в случаите, когато непротиворечивостта не може да бъде доказана. Гъвкавите методи може да прилагат формални методи с висока степен на строгост.[17]

През 2008 Институтът за софтуерно инженерство (Software Engineering Institute, SEI) публикува техническия доклад „CMMI or Agile: Why Not Embrace Both“,[18] за да подчертае, че подходът Capability Maturity Model Integration и гъвкавите методологии могат да бъдат комбинирани. CMMI Version 1.3 включва съвети за съвместното прилагане на гъвкавите методологии и CMMI.[19] Една от разликите между гъвкавите методи и методът на водопада е, че тестовете на софтуера се провеждат на различни етапи от цикъла на разработката на софтуера. В метода на водопада има отделна фаза на тестване малко преди имплементацията. В гъвкавото екстремно програмиране тестовете се провеждат едновременно с имплементацията.

Подвидове на agile методологията

[редактиране | редактиране на кода]

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

[редактиране | редактиране на кода]
Виж цялата статия Екстремно програмиране.

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

Скръм (Scrum)

[редактиране | редактиране на кода]
Виж цялата статия Scrum

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

Канбан (Kanban)

[редактиране | редактиране на кода]
Виж цялата статия Канбан (разработка на софтуер)

Канбан е метод за управление на интелектуални дейности с наблягане на доставката точно на време, без същевременно членовете на екипа да са пренатоварени. Името произлиза от японски и буквално преведено означава „сигнална карта“. Методът, както е формулиран от Дейвид Андерсън,[20][21] е подход към постепенен, еволюционен процес. Използва система за ограничаване на текущата работа като основен механизъм, за да разкрива системно операционни проблеми и да стимулира взаимопомощта, с цел продължително подобряване на системата.

Lean разработване

[редактиране | редактиране на кода]
Виж цялата статия Lean разработване

Терминът Lean софтуер разработване произлиза от едноименната книга, написана от Мери Попендийк и Том Попендийк. Книгата представя традиционните lean принципи в модифициран формат, както и набор от 22 инструмента и ги сравнява с гъвкавите практики. Участието на Попендайови в обществото на гъвкавото софтуерно разработване, включително и беседи на няколко конференции, се отразява на приемането на различни концепции сред въпросната общност.

Адаптиране на методологиите

[редактиране | редактиране на кода]

Има различни термини, които се отнасят до понятието „адаптация на метод“, включително „'method tailoring“, 'method fragment adaptation' и „'situational method engineering'. Адаптирането на методи се определя като:

Процес или възможност, в която се определя системен подход за развитие на конкретната ситуация (проекта), чрез чувствителни промени и динамични взаимодействия между контексти, намерения и отделните фрагменти на метода.[22]

Потенциално, почти всички гъвкави методи са подходящи за адаптиране. Дори DSDM методът се използва за тази цел и е успешно приспособен в CMM.[23] Целесъобразността със ситуацията може да се счита като отличителна разлика между гъвкавите методи и традиционните методи за разработка на софтуер, като последните са относително по-строги. Изводът е, че гъвкавите методи позволяват на различни екипи да адаптират ежедневните си практики в съответствие с нуждите на отделните проекти. Като практики формулираме конкретни дейности или продукти, които са част от структурата на един метод. На по-крайно ниво, философията на този метод, състояща се и от редица принципи, може да се адаптира (Aydin, 2004).[22]

Екстремното програмиране (XP) прави нуждата от адаптиране на методите изрична. Една от основните идеи на XP е, че не всеки процес може да се впише в определен проект, а по-скоро практиките трябва да бъдат съобразени с нуждите на отделните проекти. Частичното приемане на XP практики, предложено от Kent Beck, е съобщавано няколко пъти.[24]

Mehdi Mirakhorli предлага метод за адаптиране, който осигурява достатъчно насоки за адаптиране на всички практики. RDP практиката е предназначена за персонализиране на XP. Тази практика е предложена за първи път на APSO workshop, през конференцията ICSE 2008 и е единственият приложим метод за персонализиране на XP. Въпреки че това е специализирано решение за XP, тази практика има възможност за включване и в други методологии. На пръв поглед тази практика изглежда е в категорията на статичните методи за адаптация, но опитът с практиката на RDP показва, че тя може да бъде третирана и като динамичен метод. Разликата между статичния метод и динамичния е едва доловима.[25]

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

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

Адаптивен vs. прогностичен

[редактиране | редактиране на кода]

Методите за разработка съществуват в континуум от „адаптивни“ до „предсказуеми“ или предиктивни. Agile методите за разработка на софтуер се намират в „адаптивни“ страна на този континуум.

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

Agile и waterfall

[редактиране | редактиране на кода]

Една от разликите, които се пораждат между софтуерната разработка при 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).[24]

Практики на Agile софтуерната разработка

[редактиране | редактиране на кода]

Измерване на гъвкавостта

[редактиране | редактиране на кода]

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

Индексът Agility Index Measurements (AIM) оценява проектите според група от фактори.[26]

Характеристиката с подобно име – Agility Measurement Index[27], измерва процеса на разработка спрямо пет измерения на един софтуерен проект: продължителност, ниво на риск, иновативност, усилие и интерактивност.

Други подходи се базират на измерими цели.[28]

Разработки на базата на размити множества и размита логика[29] предлагат като мярка за оценка на степента на гъвкавост на един проект да бъде използвана скоростта му на развитие.

Съществуват подходи за самооценка на един екип спрямо това дали и доколко използва гъвкавите методологии (Nokia test,[30] Karlskrona test,[31] 42 points test[32]).

Въпреки гореописаните опити за оценка, практическото им приложение все още предстои да бъде оценено. Допълнителни данни могат да бъдат намерени на CSIAC ROI Dashboard.[33]

Опит и приемане

[редактиране | редактиране на кода]

Едно от най-ранните проучвания, доказващи по-високите печалби и подобрения в производителността на бизнеса чрез използване на гъвкави методи, е проведено от Shine Technologies от ноември 2002 до януари 2003 г.[34] В подобно проучване, проведено през 2006 г. от Скот Амблър, обучаващ по Гъвкави методологии в компанията IBM Rational's Methods Groupe, е докладвано за същите ползи.[35] Други твърдят, че гъвкавите методи за разработка са все още твърде малко развити, за да е необходим широк академичен анализ на тяхната успешност.[36]

Приложимост

[редактиране | редактиране на кода]

Широкомащабната гъвкава разработка в софтуерната индустрия продължава да бъде една активна изследователска област.[37][38]

Гъвкавите методологии са широко разглеждани и като по-подходящи за определени видове среди, включително малки екипи от експерти.[39][40]:с. 157

Към тях се наблюдава положителна нагласа в Европа в сферата на embedded системите през последните години.[41]

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

  • Усилията при широкомащабна развойна дейност (>20 разработчици), макар че има описания на стратегии за мащабиране[38] и доказателства за приложимост при някои широкомащабни проекти[42].
  • Разпределена развойна дейност (географски разделени екипи. Описани са стратегии в „Bridging the Distance“[43] и „Using an Agile Software Process with Offshore Development“[44].
  • Принудителното вграждане на гъвкави методи в екипа.[45]
  • Критични системи, когато провалът не е вариант (например софтуер за управление на въздушното движение).

Ранните успехи, предизвикателствата и ограниченията, възникнали при приемането на гъвкави методи в голяма организация, са документирани.[46]

По отношение на „аутсорсинг методологията“, Michael Hackett, старши вицепрезидент на LogiGear Corporation заявява – „офшорните екипи ... трябва да имат опит, добри комуникативни умения, междукултурно разбирателство, доверие и разбирателство между групите и помежду членовете им.“[47]

Гъвкавите методи са широко използвани за разработване на софтуерни продукти и някои от тях използват определени характеристики на софтуера (като обектните технологии например.[48] Въпреки това, тези техники могат да бъдат приложени за развитието на не-софтуерни продукти, като например компютри, моторни превозни средства, медицински изделия, храни, облекла и т.н.

Анализът на риска (Risk analysis) също може да бъде използван за избор между адаптивни (agile или value-driven) и планиращи (plan-driven) методи. Barry Boehm и Richard Turner застъпват разбирането, че всяка част от спектъра има своята „територия“ и приложимост, както следва:[39]

Пригодност на различни методи за разработка
Среда от гъвкави методи Среда от „plan-driven“ (можем да ги преведем като методи за продължително разработване по определен план) методи Формални методи
Ниска критичност Висока критичност Прекалена критичност
Опитни програмисти Начинаещи програмисти Опитни програмисти
Често се променят изискванията Не се променят често Ограничени изисквания, ограничени ползи
Малък брой програмисти Голям брой програмисти Изискванията могат да бъдат променяни
Култура, отговаряща на промените Култура, изискваща ред Прекалено качество

Критики

[редактиране | редактиране на кода]

Гъвкавите методологии могат да бъдат неефективни в големи организации и при някои видове проекти (вж. точка „Приложимост“). Най-добре е да се използват за развиващи се и непоследователни проекти. Много организации смятат, че гъвкавите методологии са твърде крайни и приемат хибриден вариант, който смесва елементи на гъвкави и планиращи подходи.[49]

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

Източници

[редактиране | редактиране на кода]
  1. ↑ а б в Beck, Kent. Manifesto for Agile Software Development // Agile Alliance, 2001. Посетен на 14 юни 2010.
  2. ↑ BVOP. About the Business Value-Oriented Principles // The BVOP Ultimate Guide.
  3. ↑ а б Gerald M. Weinberg, as quoted in Larman, Craig и др. Iterative and Incremental Development: A Brief History // Computer 36 (6). Юни 2003. DOI:10.1109/MC.2003.1204375. с. 47 – 56. Prominent software-engineering thought leaders from each succeeding decade supported IID practices, and many large projects used them successfully. ...We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale at IBM's Service Bureau Corporation. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell ... the waterfall description ... make us realize that we were doing something else, something unnamed except for 'software development.'
  4. ↑ Edmonds, E. A. A Process for the Development of Software for Nontechnical Users as an Adaptive System // General Systems 19. 1974. с. 215 – 18.
  5. ↑ Evolutionary Project Management (EVO), архив на оригинала от 14 април 2012, https://web.archive.org/web/20120414230702/http://www.gilb.com/Project-Management, посетен на 4 септември 2013 
  6. ↑ Larman, Craig. Agile and Iterative Development: A Manager's Guide. Addison-Wesley, 2004. ISBN 978-0-13-111155-4. с. 27.
  7. ↑ 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
  8. ↑ Ambler, S.W. „Examining the Agile Manifesto“. Посетен на 6 април 2011.
  9. ↑ Beck, Kent. Principles behind the Agile Manifesto // Agile Alliance, 2001. Архивиран от оригинала на 2010-06-14. Посетен на 6 юни 2010.
  10. ↑ Anderson, David. Declaration of Interdependence // 2005. Архивиран от оригинала на 2018-01-27. Посетен на 2013-09-04.
  11. ↑ McDonald, Kent. How You Can Help Agile Alliance Help You // Agile Alliance Blog. 1 ноември 2016. Посетен на 4 юли 2017.
  12. ↑ Beck, Kent. Embracing Change with Extreme Programming // Computer 32 (10). 1999. DOI:10.1109/2.796139. с. 70 – 77.
  13. ↑ Gauthier, Alexandre. What is scrum // Planbox, 17 август 2011. Архивиран от оригинала на 2012-03-25. Посетен на 2013-09-04.
  14. ↑ Cockburn, Alistair. Information radiator
  15. ↑ а б Ambler, Scott. Agile Modeling: Effective Practices for EXtreme Programming and the Unified Process. John Wiley & Sons, 12 април 2002. ISBN 978-0-471-20282-0. с. 12, 164, 363.
  16. ↑ Todorova, Ana и др. Supply Chain Organization: Agile vs. Waterfall // Journal of Entrepreneurship & Innovation Issue 14, Year XIV, November' 2022. 2022. с. 61-71.
  17. ↑ Black, S. E. и др. Formal versus agile: Survival of the fittest // IEEE Computer 49 (9). Септември 2009. с. 39 – 45.
  18. ↑ TECHNICAL NOTE CMU/SEI-2008-TN-003 CMMI or Agile: Why Not Embrace Both
  19. ↑ CMMI Product Team, CMMI for Development, Version 1.3 (CMU/SEI-2010-TR-033). Software Engineering Institute, Carnegie Mellon University, 2010.
  20. ↑ Anderson, David. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Prentice Hall, September 2003. ISBN 0-13-142460-2.
  21. ↑ Anderson, David. Kanban – Successful Evolutionary Change for your Technology Business. Blue Hole Press, April 2010. ISBN 0-9845214-0-2.
  22. ↑ а б Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. (2004). An Agile Information Systems Development Method in use. Turk J Elec Engin, 12(2), 127 – 138
  23. ↑ Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244 – 254
  24. ↑ а б Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Development Methods: Review and Analysis. VTT Publications 478
  25. ↑ а б Aydin, M.N., Harmsen, F., Slooten van K., & Stegwee, R.A. (2005). On the Adaptation of An Agile Information(Suren) Systems Development Method. Journal of Database Management Special issue on Agile Analysis, Design, and Implementation, 16(4), 20 – 24
  26. ↑ David Bock's Weblog: Weblog // Jroller.com. Посетен на 2 април 2010.
  27. ↑ Agility measurement index // Doi.acm.org. Посетен на 2 април 2010.
  28. ↑ Peter Lappo и др. Assessing Agility // Архивиран от оригинала на 2009-09-15. Посетен на 6 юни 2010.
  29. ↑ Kurian, Tisni (2006). Agility Metrics: A Quantitative Fuzzy Based Approach for Measuring Agility of a Software Process, ISAM-Proceedings of International Conference on Agile Manufacturing'06(ICAM-2006), Norfolk, U.S.
  30. ↑ Joe Little. Nokia test, A scrum-specific test // Agileconsortium.blogspot.com, 2 декември 2007. Посетен на 6 юни 2010.
  31. ↑ Mark Seuffert, Piratson Technologies, Sweden. Karlskrona test, A generic agile adoption test // Piratson.se. Архивиран от оригинала на 2012-03-24. Посетен на 6 юни 2010.
  32. ↑ How agile are you, a scrum-specific test // Agile-software-development.com. Архивиран от оригинала на 2010-03-05. Посетен на 6 юни 2010.
  33. ↑ CSIAC ROI Dashboard Архив на оригинала от 2013-05-09 в Wayback Machine. Посетен на 11 ноември 2011.
  34. ↑ Agile Methodologies Survey Results (PDF) // Shine Technologies, януари 2003. Архивиран от оригинала на 2010-08-21. Посетен на 3 юни 2010. 95% stated that there was either no effect or a cost reduction ... 93% stated that productivity was better or significantly better ... 88% stated that quality was better or significantly better ... 83% stated that business satisfaction was better or significantly better
  35. ↑ Ambler, Scott. Survey Says: Agile Works in Practice // Dr. Dobb's. 3 август 2006. Посетен на 3 юни 2010. Only 6% indicated that their productivity was lowered ... No change in productivity was reported by 34% of respondents and 60% reported increased productivity ... 66% [responded] that the quality is higher ... 58% of organizations report improved satisfaction, whereas only 3% report reduced satisfaction.
  36. ↑ Answering the „Where is the Proof That Agile Methods Work“ Question // Agilemodeling.com, 19 януари 2007. Посетен на 2 април 2010.
  37. ↑ Agile Processes Workshop II Managing Multiple Concurrent Agile Projects. Washington: OOPSLA 2002
  38. ↑ а б W. Scott Ambler (2006) Supersize Me in Dr. Dobb's Journal, 15 февруари 2006.
  39. ↑ а б Boehm, B. и др. Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA, Addison-Wesley, 2004. ISBN 0-321-18612-5. с. 55 – 57.
  40. ↑ Beck, K. Extreme Programming Explained: Embrace Change. Boston, MA, Addison-Wesley, 1999. ISBN 0-321-27865-8.
  41. ↑ K Petersen's doctoral research in Sweden Implementing Lean and Agile Software Development in Industry Архив на оригинала от 2013-04-04 в Wayback Machine.
  42. ↑ Schaaf, R.J. (2007). Agility XL Systems and Software Technology Conference 2007 Архив на оригинала от 2016-03-13 в Wayback Machine., Tampa, FL
  43. ↑ Bridging the Distance // Sdmagazine.com. Посетен на 1 февруари 2011.
  44. ↑ Martin Fowler. Using an Agile Software Process with Offshore Development // Martinfowler.com. Посетен на 6 юни 2010.
  45. ↑ Art of Agile Development James Shore & Shane Warden pg 47.
  46. ↑ Evans, Ian. Agile Delivery at British Telecom // Посетен на 21февруари 2011.
  47. ↑ LogiGear, PC World Viet Nam[неработеща препратка]. Януари 2011.
  48. ↑ Smith, Preston G. Flexible Product Development. Jossey-Bass, 2007. ISBN 978-0-7879-9584-3. с. 25.
  49. ↑ Barlow, Jordan B. и др. Overview and Guidance on Agile Development in Large Organizations // Communications of the Association for Information Systems 29 (1). 2011. с. 25 – 44.

Допълнителни материали

[редактиране | редактиране на кода]

Външни препратки

[редактиране | редактиране на кода]
Уикикниги
Уикикниги
  Тази страница частично или изцяло представлява превод на страницата Agile software development в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите. ​

ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни.​

Нормативен контролРедактиране в Уикиданни
Взето от „https://bg.wikipedia.org/w/index.php?title=Гъвкава_методология_за_разработка_на_софтуер&oldid=12079479“.