Съдържание на статията
Agile – ключът към управлението на проекти в динамична среда
2 стр. - Практиките
3 стр. - Extreme programming (XP)
4 стр. - Scrum
5 стр.- Feature-Driven Development
6 стр.- Crystal
7 стр. - Dynamic System Development Methodology
8 стр. - Заключение
Всички страници

EXTREME PROGRAMMING (XP)

XP е безспорният флагман на Agile философията. Както личи от името, тука всичко е „екстремално“. Авторът Кент Бек прави простото разсъждение: „Щом нещо е добро, да го усилим в максимална степен“ и от това създава работещи ХР практики:

  • щом общуването е добро, да го правим постоянно – общо помещение и др.
  • щом взаимодействието с клиента е добро, да го правим постоянно – представител на клиента като част от екипа
  • щом тестването е добро, да го правим постоянно – автоматизирано тестване, тестване преди кодиране
  • щом интеграцията е добра, да я правим постоянно – ежедневна интеграция (и нощни автоматизирани интеграционни тестове)
  • щом внедряването е добро, да го правим всяка седмица – седмична инсталация на работеща система
  • щом преглеждането на кода (code review) е добро, да го правим постоянно - програмиране по двойки
  • и т.н.

ОТ ТАКИВА РАЗСЪЖДЕНИЯ СЕ РАЖДАТ ОСНОВНИТЕ ПРАКТИКИ НА ХР. НАЙ-ИНТЕРЕСНИТЕ ОТ ТЯХ СА:

Постоянен представител на клиента в разработващия екип

Интересно и доста трудно за изпълнение изискване, но така се решава почти напълно проблемът с комуникацията. Всички недоразумения се откриват и дискутират на възможно най-ранен етап. Освен това така се засилва и отговорността на клиента към развитието на проекта.

Събиране на спецификациите във формата на "истории" (user stories)

Обикновено се очаква изискванията към системата да бъдат максимално пълни и подробни. Не и в ХР! Тук подробните спецификации се заменят с user stories – кратки описания на функционалността, не повече от няколко изречения, само най-важното без подробности. Знаем, че подробности има, както има и специални случаи, обработка на изключения и т.н. Но не искаме в самото начало всички те да са подробно описани, просто защото не винаги е възможно. Подробностите се уточняват в процеса на разработка – нали имаме представител на клиента подръка във всеки момент! Блестящ пример за рационално отношение към документацията!

Споделена отговорност за кода

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

Програмиране по двойки

Окончателният код се пише като програмистите се разделят по двойки. Единият пише, другият контролира като постоянно тече обсъждане. В даден момент ролите могат да се разменят. На пръв поглед това изглежда много странна практика. В действителност обаче така много силно се намалява възможността за логически грешки. В крайна сметка рязкото повишаване на качеството на кода многократно компенсира двойно по-голямата загуба на работно време. Между другото, лично съм наблюдавал как при кодирането на някой особено проблемен епизод програмистите сами се събират по двама или трима на един компютър и след решаване на задачата се разделят.

Минимална архитектура, максимална простота

Основна ценност на ХР е максималната простотата. Всяко усложняване на архитектурата с оправданието, че „това може да ни потрябва по-нататък“ е неуместна – ние не знаем какво ще поиска клиентът по-нататък!

Предварително писане на тестове

Още един „бисер“ на ХР е писането на тестове преди писането на самия код. Кент Бек, авторът на ХР, казва: „Напишете фрагмент как бихте искали да използвате кода. Това е вашият тест. После напишете кода така, че тестът да мине“. Лично мога да гарантирам, че така се проектира много по-удобен и качествен код.

Самодокументиращ се код

Още един цитат от Бек: „Тестовете са най-добрата документация на работещия код. Няма нужда от друга.“ И наистина, за какво е нужна документацията на кода? За да може този код да се поддържа във времето дори и от други програмисти. За нищо друго! Тогава каква по-добра документация от тестовете (които по същество са примери за използването на кода) заедно с коментарите в самия код.

Това са най-ярките практики от колекцията на ХР.

Повечето от практиките в тази методология са от групите на технологичните и социалните. Организационни и проектни практики екипът трябва да избере сам. От друга страна, останалите Agile методологии почти не дефинират технологични и социални практики (или те се покриват с ХР). Това позволява ХР практиките да се използват свободно в останалите Agile методологии.

Успелите да внедрят ХР в своята организация твърдят, че „са се родили отново“. Това обаче не е лесна работа. Първо, трябва да разполагаме с екип от равностойни по качества добри специалисти. Второ този екип трябва да възприеме някои непривични начини на работа. Ето защо ХР в чист вид рядко се прилага. По-често тази методика се използва като „извор“ на добри технологични и социални практики за попълване на слабите страни на другите Agile методологии.