Екстремно програмиране (на английски: eXtreme Programming – XP) e тип програмиране и проектна методология за създаване на софтуер, една от няколкото гъвкави методологии (agile software development methodologies). Основната цел на гъвкавата методология е намиране на по-добри и по-гъвкави решения при създаването на софтуер.

Основни правила от манифеста на гъвкавите методологии Agile Manifest, които XP също следва са: Индивидуални качества и комуникация се предпочита пред строги процеси и инструменти Работещ софтуер за сметка на изчерпателна документация Клиентско съдействие измества договорно споразумение Лесно реагиращ на промяна софтуер вместо стриктното следване на план

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

Принципи XP следва свои прости правила и практики, които на пръв поглед може и да не изглеждат надеждни, но всъщност опитът показва, че дават добри резултати: Комуникация – при XP се стимулира вербалната комуникация, за разлика от другите концепции, при които комуникацията става чрез документацията. Простота – при XP се започва с възможно най-опростен дизайн и решение на дадения проблем, който се подобрява, чрез refactoring като при този начин на програмиране се пише за днес, а не за утре. Обратна връзка от системата – с помощта на тестове на единици или периодични интеграционни тестове програмистите имат директна обратна връзка от състоянието на системата след като промените са били въведени; с помощта на тази обратна връзка по-лесно може да се открие грешка в кода и дадения фрагмент да се пренапише. от клиента – функционалните тестове са писани от клиента и от тестерите. Те ще получат ясна представа от моментното състояние на системата. Тези тестове са предвидени да се правят веднъж на 2 – 3 седмици, за да може клиентът отблизо да следи развитието. от екипа – след като клиента веднага каже новите си изисквания екипът веднага да може да даде конкретен отговор колко точно време ще отнеме да се имплементират новите изисквания. Кураж – кураж да правиш дизайн и пишеш код за днес, а не за утре; кураж да пренапишеш даден код, който не отговаря на новите изисквания, независимо от факта, че си му отделил много време и усилия, куража кара разработчиците да се чувстват добре, когато техния код има нужда от refactoring. Уважение – в XP членовете на екипа трябва се уважават един друг, защото се смята, че по-този начин се подобрява работата в екипа, при което се получават по-добри резултати.

Дейности Дейности, който XP описва и който се използват при самия процес на софтуера разработка: Кодиране – Защитниците на XP смятат, че единственото наистина важно нещо в разработката на софтуер е писането на код. Тестването – без тестване не можем да бъдем сигурни дали нашият продукт наистина отговаря на изискванията на спецификацията; не можем да сме сигурни дали това, което сме написали, е това, което сме искали да напишем – за целта използваме Unit Test; не можем да бъдем сигурни дали това, което сме имали предвид, е това, което е трябвало да имаме предвид – за да проверим това, правим приемствени тестове(acceptance tests) на изискванията, които са дадени от клиента (дадени в exploration phase of release planning). Слушане – За програмистите по принцип не е необходимо да са наясно с бизнес страната на самата система. От друга страна, те трябва да „слушат“, за да знаят от какво се нуждае клиента. Правене на дизайн – При създаването на продукт, използвайки ХР, едно от най-важните неща е създаването на добър дизайн в началото.

Добри практики XP има 12 практики, групирани в 4 области, които са наследени от най-добрите практики на софтуерното инженерство:

Fine scale feedback: Програмиране по двойки – двама програмисти, които работят заедно на един компютър, driver и navigator. Докато driver-a пише на компютъра, navigator-а следи работата му. И е добре на половин час да си разменят ролите, а всеки ден да се сменят партньорите. Предимствата на pair programming-а са, че по този начин се пише по-верен код, правят се по-малко логически грешки; разменят се знания, защото колкото и да знае даден човек, никога не може да знае всичко и винаги може да научи повече; така се сближават хората от екипа - нещо много важно за XP. Ако хората се сменят по-често, повече от тях ще бъдат въведени в различните features и по този начин всеки ще е много по-добре запознат с цялостния продукт и комуникацията ще е по-лесна. Смята се, че по този начин има по-малко прекъсвания на работата, което води до по-голяма продуктивност. Друго предимство е, че по-малко компютри са необходими, за да се свърши работата, при което свободните могат да бъдат използвани за други цели. Planning Game – основният planning process; самият planning game е среща на екипа, която се състои веднъж на всяка итерация (обикновено веднъж седмично). Самият planning process се състои от 2 части - release planning и iteration planning Release Planning – фокусира се върху това какви изисквания има за следващия release. Състои се от 3 фази: Exploration Phase – клиентът казва какви са изискванията му Commitment Phase – има договаряне каква точно функционалност ще се търси при следващия release и кога се очаква да излезе Steering Phase – при тази фаза изискванията може да бъдат подобрени, да бъдат добавени нови, да бъдат премахнати някои от старите Iteration Planning – тук се обсъждат вече дейностите и задачите на разработчиците, клиентът не се намесва. Състои се от 3 фази: Exploration Phase – изискванията се разпределят в различни задачи. Commitment Phase – задачите се разпределят между разработчиците и ще бъде оценено времето, необходимо за завършването им Steering Phase – представят се завършените задачи и се сравняват с предварителните изисквания Test Driven Development – използват се Unit tests, които се пишат още преди да е написан кода, за да могат предварително да се предвидят ситуациите, в които кодът може да fail-не. При ХР се смята, че продуктът е завършен, когато не могат да изникнат нови състояния, при които кодът да fail-не. Whole Team – при ХР клиентът е този, за когото е предназначен самият продукт; с ХР не се създават продукти по принцип за много хора; създават се за даден конкретен клиент, който впоследствие ще използва продукта, и самите разработчици поддържат връзка с него. Continuous process: Continuous Integration – практика, в която разработчиците интегрират често работата си. Design Improvement – code refactoring Small Releases

Shared Understanding: Coding Standards Collective Code Ownership Simple Design System Metaphor

Programmer welfare: Sustainable Pace

Източници

Външни препратки Managing software development using extreme programming Extreme Programming: extremeprogramming.org Code refactoring

Категория:Процес на софтуерното разработване Категория:Програмиране Категория:Управление на проекти