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

от Уикипедия, свободната енциклопедия
Интерактивен преглед на историята
← По-стара редакцияПо-нова редакция →
Изтрито е съдържание Добавено е съдържание
ВизуаленУикитекст
м Бот: замяна на тире с дефис в по- и най-
Antonradev (беседа | приноси)
17 редакции
Ред 283: Ред 283:
* [http://scrum.org/ Scrum.org]
* [http://scrum.org/ Scrum.org]
* [http://scrumalliance.org/ Scrum Alliance]
* [http://scrumalliance.org/ Scrum Alliance]
*[https://bvop.org/agile/ BVOP Agile Guide]


{{Превод от|en|Agile_software_development|571189248}}
{{Превод от|en|Agile_software_development|571189248}}

Версия от 17:19, 17 декември 2019

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

Гъвкави методологии (английски: agile) за разработка на софтуер е неформален сбор от методологии и техники за управление на проекти за разработка на софтуер. Както подсказва и името, във фокуса на гъвкавите методологии е идеята, че разработката на софтуер е динамичен процес, в който дългосрочното планиране има ограничена ефективност.

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

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

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

История

Мартин Фоулър, общопризнат за един от основателите на гъвкавата методология

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Съществуващите методи варират от „адаптивни“ до „планиращи“.[14] Гъвкавите подходи попадат в „адаптивната“ част на този спектър.

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

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

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

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

Гъвкави методологии

Скръм (Scrum)

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

Виж цялата статия – Scrum.

Канбан (Kanban)

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

Виж цялата статия – Канбан (разработка на софтуер).

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

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

Виж цялата статия – Lean разработване.

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

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

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

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

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

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

Потенциално, почти всички гъвкави методи са подходящи за адаптиране. Дори DSDM методът се използва за тази цел и е успешно приспособен в CMM. [21] Целесъобразността със ситуацията може да се счита като отличителна разлика между гъвкавите методи и традиционните методи за разработка на софтуер, като последните са относително по-строги. Изводът е, че гъвкавите методи позволяват на различни екипи да адаптират ежедневните си практики в съответствие с нуждите на отделните проекти. Като практики формулираме конкретни дейности или продукти, които са част от структурата на един метод. На по-крайно ниво, философията на този метод, състояща се и от редица принципи, може да се адаптира (Aydin, 2004).[20] Екстремното програмиране (XP) прави нуждата от адаптиране на методите изрична. Една от основните идеи на XP е, че не всеки процес може да се впише в определен проект, а по-скоро практиките трябва да бъдат съобразени с нуждите на отделните проекти. Частичното приемане на XP практики, предложено от Kent Beck, е съобщавано няколко пъти. [22] [23] Mehdi Mirakhorli предлага метод за адаптиране, който осигурява достатъчно насоки за адаптиране на всички практики. RDP практиката е предназначена за персонализиране на XP. Тази практика е предложена за първи път на APSO workshop, през конференцията ICSE 2008 и е единственият приложим метод за персонализиране на XP. Въпреки че това е специализирано решение за XP, тази практика има възможност за включване и в други методологии. На пръв поглед тази практика изглежда е в категорията на статичните методи за адаптация, но опитът с практиката на RDP показва, че тя може да бъде третирана и като динамичен метод. Разликата между статичния метод и динамичния е едва доловима. [23] Ключово предположение за статичния метод за адаптация е, че контекстът на проекта е даден в началото му и остава фиксиран по време на изпълнението на проекта. Резултатът е статично определение на контекста. Като се има предвид това, може да се определи, кои от основните фрагменти на метода трябва да се използват за конкретен проект, а също и въз основа на предварително определени критерии.

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

Жизнен цикъл на софтуерната разработка

Жизнен цикъл на софтуерната разработка

Виж също:Софтуерно инженерство

Гъвкавите методи са насочени към различни аспекти от жизнения цикъл на софтуерната разработка. Някои се фокусират върху практиката (екстремно програмиране, прагматично програмиране, гъвкаво моделиране), докато други наблягат върху управлението на софтуерни проекти (Scrum). И все пак, има подходи, покриващи целия цикъл на една софтуерна разработка (динамични системи за развитие, или DSDM, IBM Rational Unified Process, или RUP), докато други са повече насочени към отделните етапи на разработка (feature-driven development или FDD).

Следователно, налице е ясна разлика между различните гъвкави методи за разработка на софтуер в това отношение. DSDM и RUP не се нуждаят от допълнителни подходи в разработването на софтуер, други пък, в различна степен. DSDM може да се използва от всеки (макар само DSDM членове да могат да предлагат DSDM продукти или услуги). RUP, обаче, е комерсиално насочена среда за разработка (Abrahamsson, Сало, Rankainen & Warsta, 2002).[22]

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

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

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

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

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

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

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

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

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

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

Приложимост

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

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

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

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

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

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

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

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

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

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

Критики

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

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

Източници

  1. ↑ а б в Beck, Kent. Manifesto for Agile Software Development // Agile Alliance, 2001. Посетен на 14 юни 2010.
  2. ↑ а б 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. 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 ... All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for 'software development.'
  3. ↑ Edmonds, E. A. A Process for the Development of Software for Nontechnical Users as an Adaptive System // General Systems 19. 1974. с. 215 – 18.
  4. ↑ Evolutionary Project Management (EVO)
  5. ↑ Larman, Craig. Agile and Iterative Development: A Manager's Guide. Addison-Wesley, 2004. ISBN 978-0-13-111155-4. с. 27.
  6. ↑ 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
  7. ↑ Ambler, S.W. „Examining the Agile Manifesto“. Посетен на 6 април 2011.
  8. ↑ Beck, Kent. Principles behind the Agile Manifesto // Agile Alliance, 2001. Архивиран от оригинала на 14 юни 2010. Посетен на 6 юни 2010.
  9. ↑ Anderson, David. Declaration of Interdependence // 2005.
  10. ↑ Beck, Kent. Embracing Change with Extreme Programming // Computer 32 (10). 1999. DOI:10.1109/2.796139. с. 70 – 77.
  11. ↑ Gauthier, Alexandre. What is scrum // Planbox, 17 август 2011.
  12. ↑ Cockburn, Alistair. Information radiator
  13. ↑ а б 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.
  14. ↑ Boehm, B. и др. Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA, Addison-Wesley, 2004. ISBN 0-321-18612-5. Appendix A, pages 165 – 194
  15. ↑ Black, S. E. и др. Formal versus agile: Survival of the fittest // IEEE Computer 49 (9). Септември 2009. с. 39 – 45.
  16. ↑ TECHNICAL NOTE CMU/SEI-2008-TN-003 CMMI or Agile: Why Not Embrace Both
  17. ↑ CMMI Product Team, CMMI for Development, Version 1.3 (CMU/SEI-2010-TR-033). Software Engineering Institute, Carnegie Mellon University, 2010.
  18. ↑ Anderson, David. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Prentice Hall, September 2003. ISBN 0-13-142460-2.
  19. ↑ Anderson, David. Kanban – Successful Evolutionary Change for your Technology Business. Blue Hole Press, April 2010. ISBN 0-9845214-0-2.
  20. ↑ а б 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
  21. ↑ Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244 – 254
  22. ↑ а б Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Development Methods: Review and Analysis. VTT Publications 478
  23. ↑ а б 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
  24. ↑ David Bock's Weblog: Weblog // Jroller.com. Посетен на 2 април 2010.
  25. ↑ Agility measurement index // Doi.acm.org. Посетен на 2 април 2010.
  26. ↑ Peter Lappo и др. Assessing Agility // Посетен на 6 юни 2010.
  27. ↑ 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.
  28. ↑ Joe Little. Nokia test, A scrum-specific test // Agileconsortium.blogspot.com, 2 декември 2007. Посетен на 6 юни 2010.
  29. ↑ Mark Seuffert, Piratson Technologies, Sweden. Karlskrona test, A generic agile adoption test // Piratson.se. Посетен на 6 юни 2010.
  30. ↑ How agile are you, a scrum-specific test // Agile-software-development.com. Посетен на 6 юни 2010.
  31. ↑ CSIAC ROI Dashboard Посетен на 11 ноември 2011.
  32. ↑ Agile Methodologies Survey Results (PDF) // Shine Technologies, януари 2003. Посетен на 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
  33. ↑ 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.
  34. ↑ Answering the „Where is the Proof That Agile Methods Work“ Question // Agilemodeling.com, 19 януари 2007. Посетен на 2 април 2010.
  35. ↑ Agile Processes Workshop II Managing Multiple Concurrent Agile Projects. Washington: OOPSLA 2002
  36. ↑ а б W. Scott Ambler (2006) Supersize Me in Dr. Dobb's Journal, 15 февруари 2006.
  37. ↑ а б Boehm, B. и др. Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA, Addison-Wesley, 2004. ISBN 0-321-18612-5. с. 55 – 57.
  38. ↑ Beck, K. Extreme Programming Explained: Embrace Change. Boston, MA, Addison-Wesley, 1999. ISBN 0-321-27865-8.
  39. ↑ K Petersen's doctoral research in Sweden Implementing Lean and Agile Software Development in Industry
  40. ↑ Schaaf, R.J. (2007). Agility XL Systems and Software Technology Conference 2007, Tampa, FL
  41. ↑ Bridging the Distance // Sdmagazine.com. Посетен на 1 февруари 2011.
  42. ↑ Martin Fowler. Using an Agile Software Process with Offshore Development // Martinfowler.com. Посетен на 6 юни 2010.
  43. ↑ Art of Agile Development James Shore & Shane Warden pg 47.
  44. ↑ Evans, Ian. Agile Delivery at British Telecom // Посетен на 21февруари 2011.
  45. ↑ LogiGear, PC World Viet Nam. Януари 2011.
  46. ↑ Smith, Preston G. Flexible Product Development. Jossey-Bass, 2007. ISBN 978-0-7879-9584-3. с. 25.
  47. ↑ Sliger, Michele, Broderick, Stacia. The Software Project Manager's Bridge to Agility. Addison-Wesley, 2008. ISBN 0-321-50275-2. с. 46.
  48. ↑ 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=9702887“.