Екстремното програмиране (XP) е една от гъвкавите методологии за разработка софтуер. Автори на методиката са Кент Бек, Уорд Кънингам, Мартин Фаулър и др.

Играта на планиране

Нашият свят е твърде променлив и непредвидим, за да разчитаме на постоянството на ситуацията. Същото се случва и при разработката на софтуер: за рядка система може да се каже, че нейният окончателен вид е известен предварително в детайли в самото начало на разработката. Обикновено апетитът на клиента идва с яденето: той постоянно иска да промени нещо, да подобри нещо и изобщо да изхвърли нещо от системата. Това е променливостта на изискванията, от която всички толкова се страхуват. За щастие на човека е дадена способност да предвижда възможни вариантии така да държи ситуацията под контрол.
В Extreme Programming планирането е неразделна част от развитието и фактът, че плановете могат да се променят, се взема предвид от самото начало. Тази опорна точка, техника, която ви позволява да предвидите ситуацията и безболезнено да се примирите с промените, е играта на планиране. В хода на такава игра известните системни изисквания могат бързо да бъдат събрани, оценени и планирани за тяхното развитие в съответствие с приоритета.
Както всяка друга игра, планирането има своите участници и своята цел. Ключовата фигура, разбира се, е клиентът. Той е този, който информира за необходимостта от определена функционалност. Програмистите дават и приблизителна оценка на всяка функционалност. Красотата на играта на планиране се крие в единството на целта и солидарността между разработчика и клиента: в случай на победа всички печелят; в случай на поражение всички губят. Но в същото време всеки участник върви към победата по свой начин: клиентът избира най-важните задачи в съответствие с бюджета, а програмистът оценява задачите в съответствие със способността си да ги изпълнява.
Екстремното програмиране предполага, че разработчиците са в състояние сами да решат колко дълго ще се справят със задачите си и кой от тях би бил по-склонен да реши един проблем и кой не.
В идеална ситуация играта за планиране, включваща клиента и програмиста, трябва да се играе на всеки 3-6 седмици, преди началото на следващата итерация на разработката. Това прави сравнително лесно да се направят корекции в съответствие с успехите и неуспехите на предишната итерация.

План за освобождаване

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

Планиране на итерация

Планирането на итерация започва със среща в началото на всяка итерация за разработване на план от стъпки за постигане на целите на програмата. Всяка итерация трябва да продължи между една и три седмици. Изявленията в рамките на една итерация се сортират по ред на тяхната важност за клиента. Освен това се добавят задачи, които не са преминали тестовете за приемане и трябва да бъдат подобрени. Твърденията и резултатите от тестовете се превеждат в програмни задачи. Задачите са написани на карти, които образуват подробен план за повторение. За решаването на всяка от задачите са необходими от един до три дни. Задачи, които се нуждаят от по-малко от един ден, могат да бъдат групирани заедно, а големите задачи могат да бъдат разделени на няколко по-малки. Разработчиците оценяват задачите и крайните срокове за изпълнението им. Много е важно разработчикът да зададе точното време за изпълнение на задачата. Може да се наложи преоценка на част от езика и преразглеждане на плана за освобождаване след всеки три или пет итерации - това е напълно приемливо. Ако първо реализирате най-важните области на работа, тогава винаги ще имате време да направите максимално възможното за вашите клиенти. Стилът на разработка, базиран на последователност от итерации, подобрява процеса на разработка.

Постоянно заседание

Всяка сутрин има среща за обсъждане на проблемите, техните решения и повишаване на концентрацията на екипа. Срещата се провежда прав, за да се избегнат дълги дискусии, които не са интересни за всички членове на екипа.
В една типична среща повечето участници не допринасят с нищо, просто участват, за да чуят какво имат да кажат другите. Голяма част от времето на хората се губи, за да получат малко количество комуникация. Следователно участието на всички хора в срещите отнема ресурси от проекта и създава хаос в планирането.
За този вид комуникация е необходима постоянна среща. Много по-добре е да имате една кратка задължителна среща, отколкото много дълги, на които повечето разработчици така или иначе трябва да присъстват.
Ако имате ежедневни постоянни срещи, тогава на всички останали срещи трябва да присъстват само онези хора, които са необходими и ще донесат нещо. Освен това дори е възможно да избегнете някои срещи. С ограничен брой участници повечето срещи могат да се провеждат спонтанно пред монитор, където обменът на идеи е много по-интензивен.
Ежедневната сутрешна среща не е просто поредната загуба на време. Това ще ви позволи да избегнете много други срещи и ще ви спести повече време, отколкото загуба.

Простота

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

Метафорна система

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

Клиент на работното място

Основният проблем при разработването на софтуер е липсата на познания на програмистите в разработваната предметна област. Extreme Programming намери изход и от тази ситуация. Не, това не е стаж за разработчици в предприятието на клиента - тогава той няма да иска да програмира. Напротив, това е участието на клиента в процеса на разработка.
Как един програмист, без да разбира същността на въпроса и не е телепат, може да познае какво иска клиентът? Отговорът е очевиден. от най-много по прост начинда преодолеем подобно неудобство - и Екстремното програмиране ни учи да намираме най-много прости решения- ще зададе директен въпрос на клиента. По-строгите подходи изискват цялостен предварителен анализ на района, който се разработва. В някои случаи това е оправдано, въпреки че струва повече. Реалният опит от провеждането на светски проекти показва, че е невъзможно да се съберат всички изисквания предварително. Освен това, дори ако приемем, че всички изисквания са събрани в момента, все още ще има едно тясно място: програмите, като всичко в природата, не се създават моментално и междувременно бизнес процесите могат да се променят. Това трябва да се има предвид.
Мнозина се съмняват във възможността за включване на клиента в процеса на разработка. Наистина клиентите са различни. Ако не е възможно да се привлече клиент или негов представител, понякога има смисъл временно да се наеме специалист в областта, която се разработва. Такава стъпка ще намали неяснотите в работата, ще увеличи скоростта на разработка и ще доближи проекта до това, което клиентът иска да получи. Това може да бъде от полза и от финансова гледна точка: в края на краищата заплатата на програмист понякога значително надвишава заплатата на специалисти в други индустрии.
потребителска история. User Story (нещо като потребителска история) е описание на това как трябва да работи системата. Всяка потребителска история е написана на карта и представлява част от системната функционалност, която има логичен смисъл от гледна точка на клиента. Формата е един или два параграфа текст, който е разбираем за потребителя (не е много технически).
Потребителската история е написана от клиента. Те са подобни, но не се ограничават до сценарии за използване на системата. потребителски интерфейс. За всяка история се пишат функционални тестове, за да се потвърди, че тази история е правилно внедрена - те се наричат ​​още тестове за приемане.

Тестване преди разработка

Тестването в класическия му смисъл е доста скучна процедура. Обикновено те наемат тестер, който периодично извършва едни и същи действия и чака деня, в който най-накрая ще бъде преместен на друга позиция или има възможност да смени работата.
В екстремното програмиране ролята на тестването е по-интересна: сега първо е тестът, а след това кодът. Как можете да тествате нещо, което все още не съществува? Отговорът е прост и банален: тествайте мислите си - какво трябва да се очаква от бъдещ софтуер или функционалност. Това ще ви позволи да разберете по-добре какво трябва да направят програмистите и да проверите функционалността на кода веднага щом бъде написан.
Но тестът също може да не работи. Какво ще кажете за писане на тест за тест? И след това тест за тест и така до безкрайност? Въобще не. Тестът за теста ще замени кода. Как така? Но вижте: представете си, че трябва да фиксирате гайката в средата на болта, така че да не се върти. Какво правят за това? Завийте втората гайка близо до първата, така че всяка гайка да предотвратява завъртането на следващата. Същото е и в програмирането: тестът тества кода, а кодът тества теста.
Опитът показва, че този подход не само не забавя, но и ускорява развитието. В края на краищата, знаейки какво трябва да се направи и необходимото количество работа ще спести време, като откаже да внедри непотърсени този моментподробности.

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

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

Смяна на позициите

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

Колективна собственост на кода

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

Конвенция за кодиране

Вие сте в екип, който работи по този проект от дълго време. Хората идват и си отиват. Никой не кодира сам и кодът принадлежи на всички. Винаги ще има моменти, когато ще е необходимо да разберете и коригирате кода на някой друг. Разработчиците ще премахват или променят дублиращия се код, ще анализират и подобряват класовете на други хора и т.н. С течение на времето няма да е възможно да се каже кой е авторът на даден клас.
Следователно всеки трябва да се подчинява на общите стандарти за кодиране - форматиране на кода, клас, променлива, постоянно именуване, стил на коментар. По този начин ще сме сигурни, че като правим промени в кода на някой друг (което е необходимо за агресивен и екстремен напредък напред), няма да го превърнем във вавилонски пандемониум.
Горното означава, че всички членове на екипа трябва да се споразумеят за общи стандарти за кодиране. Няма значение какво. Правилото е всички да ги спазват. Тези, които не желаят да ги спазват, напускат отбора.

Честа интеграция

Разработчиците, ако е възможно, трябва да интегрират и пускат своя код на всеки няколко часа. Във всеки случай никога не трябва да съхранявате промените по-дълго от един ден. Честото интегриране избягва отчуждението и фрагментацията в разработката, където разработчиците не могат да комуникират в смисъл на обмен на идеи или повторно използване на код. Всеки трябва да работи с последна версия.
Всяка двойка разработчици трябва да раздаде своя код веднага щом има разумна възможност да го направи. Това може да се случи, когато всички UnitTestове преминат 100%. Като изпращате промени няколко пъти на ден, вие намалявате проблемите с интеграцията почти до нищо. Интеграцията е дейност „плати сега или плати повече по-късно“. Следователно, като интегрирате промените ежедневно на малки порции, няма да се налага да прекарвате седмица, за да свържете системата заедно точно преди проектът да бъде доставен. Винаги работете на най-новата версия на системата.

Четиридесет часова работна седмица

Човек, особено ако е програмист, е способен да направи много в името на бизнеса: да остане на работа, да отиде на работа през уикенда, да откаже да си вземе отпуск, да остане буден няколко дни, да седи на клавиатурата. .. Като цяло не можете да направите нищо в името на любимото си занимание. Но екстремното програмиране е категорично против подобна саможертва и нарушаване на приетите норми на трудовото законодателство.
Това е продиктувано не само от съображения за законност и хуманност, но - на първо място - от необходимостта от повишаване на ефективността на работата и строга организация. В крайна сметка екстремното програмиране е колективна игра, предназначена не за отделни хора, а за цялата група като цяло. А такова нещо като например програмирането по двойки е възможно само ако биоритмите на участниците в него са синхронизирани. И е невъзможно, ако един човек дойде на работа в девет, а вторият в дванадесет или единият реши, че е по-добре за него да работи събота и неделя, а на другия му е неудобно.
Но най-важното е, че за да поддържа здравето и работоспособността, човек се нуждае от добра почивка. Осемчасовият работен ден и петдневната работна седмица са установени именно от съображения за максимална производителност. В много западни фирми късното напускане на работа се счита за лошо академично представяне или неспособност за правилно управление на работното време. В повечето случаи това е вярно. Да, и от медицинска гледна точка закъсненията на работа водят до постоянна умора, раздразнителност и намалена мозъчна активност. Ефективно ли е? Но как да организираме постоянна отворена комуникация между разработчиците в такъв екип и ще бъде ли възможно програмирането по двойки? Отговорът е отрицателен. Правилата са си правила и трябва да се спазват.

Заключение

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

Библиография:

Екстремното програмиране (XP) възниква като еволюционен метод за разработка на софтуер отдолу нагоре. Този подход е пример за т. нар. Agile Development Method. Групата на "живите" методи включва, освен екстремното програмиране, методите SCRUM, DSDM (Dynamic Systems Development Method), Feature-Driven Development (разработка, управлявана от системни функции) и др.

Основните принципи на разработката на софтуер "на живо" са фиксирани в манифеста за разработка на "живо", който се появи през 2000 г.

• · Хората, участващи в проекта и тяхната комуникация са по-важни от процесите и инструментите.
• · Работната програма е по-важна от изчерпателната документация.
• · Сътрудничеството с клиента е по-важно от обсъждането на детайлите по договора.
• · Практикуването на промени е по-важно от спазването на планове.

„Живите“ методи се появиха като протест срещу прекомерната бюрократизация на разработката на софтуер, изобилието от странични документи, които не са необходими за получаване на крайния резултат, които трябва да бъдат съставени по време на проекта в съответствие с повечето „тежки“ процеси , допълнителна работаза поддържане на фиксирания процес на организацията, както се изисква, например, от CMM. Повечето от тези работи и документи не са пряко свързани с разработката на софтуер и осигуряването на качеството, но са предназначени за спазване на официалните клаузи на договорите за разработка, получаване и потвърждаване на сертификати за съответствие с различни стандарти.

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

Въпреки това, XP има своя собствена схема на процеса на разработка (въпреки че, най-общо казано, широко използваното разбиране за „процеса на разработка“ като доста твърда схема от действия противоречи на самата идея за „жизненост“ на разработката), показана на фиг. 1 .

Според авторите на XP, тази техника не е толкова следване на някои общи модели на действие, колкото използване на комбинация от следните техники. Въпреки това всяка техника е важна и без нея разработката се счита за извън XP, според Кент Бек, един от авторите на този подход заедно с Уорд Кънингам и Рон Джефрис.

· жив планиране игра)

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

Фиг. 1

· Често срещан промяна версии (малки издания)

Първата работеща версия трябва да се появи възможно най-скоро и трябва незабавно да се използва. Следващи версиисе приготвят на сравнително кратки интервали (от няколко часа с малки промени в малка програма, до месец-два със сериозна обработка на голяма система). Версиите (изданията) на продукта трябва да се произвеждат възможно най-често. Работата по всяка версия трябва да отнема възможно най-малко време. В същото време всяка версия трябва да е достатъчно значима от гледна точка на полезност за бизнеса.

· Метафора на системата

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

Архитектурата е някаква представа за компонентите на системата и как те са взаимосвързани. Разработчиците използват архитектурата, за да разберат къде в системата е добавена нова функционалност и с какво ще взаимодейства някой нов компонент.

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

· просто дизайн решения (прости дизайн)

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

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

· развитие на база тестване (тестово управление развитие)

Разработчиците първо пишат тестове, след което се опитват да внедрят своите модули, така че тестовете да работят. Клиентите предварително пишат тестове, които демонстрират основните характеристики на системата, за да видите дали системата наистина работи.

XP се фокусира върху два вида тестване:

ь тестване на единици (единично тестване);

ь тестване за приемане (изпитване за приемане).

софтуер за екстремно програмиране

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

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

За XP подходът, наречен TDD (Test Driven Development), е по-приоритетен, първо се пише тест, който не преминава, след това се пише кодът, така че тестът да премине, и след това кодът се преработва.

· Константа рефакторинг

Не е тайна, че всяка добавена нова функция и нарастващият код затрудняват разработването, улавянето на грешки и извършването на последващи промени. Един от триковете на екстремното програмиране е да компенсира добавянето на функционалност чрез подобряване на кода. Това е рефакторинг на код или рефакторинг.

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

Рефакторингът е техника за подобряване на кода без промяна на неговата функционалност. XP предполага, че след като кодът е написан, той почти сигурно ще бъде преработен много пъти по време на проекта. Разработчиците на XP безмилостно преработват предварително написан код, за да го подобрят. Този процес се нарича рефакторинг. Липсата на тестово покритие провокира отхвърлянето на рефакторинг, поради страха от счупване на системата, което води до постепенно влошаване на кода.

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

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

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

· Колектив владение код (колективен собственост)

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

Като даваме на всеки програмист правото да променя кода, ние рискуваме да въведем грешки от програмисти, които си мислят, че знаят какво правят, но не вземат предвид някои зависимости. Добре дефинираните UNIT тестове решават този проблем: ако непрегледаните зависимости генерират грешки, тогава следващото изпълнение на UNIT тестовете ще бъде неуспешно.

· Константа интеграция (непрекъсната интеграция)

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

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

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

· 40 часа работещ седмица

Извънредният труд се разглежда като знак за големи проблеми в проекта. Не се допуска извънреден труд 2 седмици подред – това изтощава програмистите и прави работата им значително по-малко продуктивна.

Човек, особено ако е програмист, е способен да направи много в името на бизнеса: да остане на работа, да отиде на работа през уикенда, да откаже да си вземе отпуск, да остане буден няколко дни, да седи на клавиатурата. .. Като цяло не можете да направите нищо в името на любимото си занимание. Но екстремното програмиране е категорично против подобна саможертва и нарушаване на приетите норми на трудовото законодателство.

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

Но най-важното е, че за да поддържа здравето и работоспособността, човек се нуждае от добра почивка. Осемчасовият работен ден и петдневната работна седмица са установени именно от съображения за максимална производителност. В много западни фирми късното напускане на работа се счита за лошо академично представяне или неспособност за правилно управление на работното време. В повечето случаи това е вярно. Да, и от медицинска гледна точка закъсненията на работа водят до постоянна умора, раздразнителност и намалена мозъчна активност. Ефективно ли е? Но как да организираме постоянна отворена комуникация между разработчиците в такъв екип и ще бъде ли възможно програмирането по двойки? Отговорът е отрицателен. Правилата са си правила и трябва да се спазват.

· Включване клиент в команда (на място клиент)

Основният проблем при разработването на софтуер е липсата на познания на програмистите в разработваната предметна област. Extreme Programming намери изход и от тази ситуация. Не, това не е стаж за разработчици в предприятието на клиента - тогава той няма да иска да програмира. Напротив, това е участието на клиента в процеса на разработка.

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

Мнозина се съмняват във възможността за включване на клиента в процеса на разработка. Наистина клиентите са различни. Ако не е възможно да се привлече клиент или негов представител, понякога има смисъл временно да се наеме специалист в областта, която се разработва. Такава стъпка ще намали неяснотите в работата, ще увеличи скоростта на разработка и ще доближи проекта до това, което клиентът иска да получи. Това може да бъде от полза и от финансова гледна точка: в края на краищата заплатата на програмист понякога значително надвишава заплатата на специалисти в други индустрии.

· Използване код как финансови средства комуникации

Кодът се разглежда като най-важното средство за комуникация в екипа. Яснотата на кода е един от основните приоритети. Следването на стандарти за кодиране, които осигуряват такава яснота, е наложително. Такива стандарти, в допълнение към яснотата на кода, трябва да гарантират минимум изрази (без дублиране на код и информация) и трябва да бъдат приети от всички членове на екипа.

· отворен работещ пространство (отворено работно пространство)

Екипът се помещава в едно помещение, достатъчно просторно за улесняване на комуникацията и възможност за колективни дискусии при планиране и вземане на важни технически решения.

· промяна правила На необходимо (просто правила)

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

Както може да се види от използваните техники, XP е предназначен за използване в малки екипи (не повече от 10 програмисти), което се подчертава и от авторите на тази техника. По-големият размер на екипа разрушава лесната комуникация, необходима за успеха, и прави много от изброените техники невъзможни.

Екстремното програмиране е отклонение от традиционния процес на създаване на програми - вместо еднократно планиране, анализ и проектиране на система с дългосрочна перспектива, програмистите вече прилагат всички тези операции постепенно по време на разработката.

Първоначално имаше модел „водопад“ (фиг. 1а): ние молим потребителите недвусмислено да формулират своите изисквания; ние проектираме система, която ще прави всичко, което потребителите искат; пишем код; ние тестваме програмата, за да сме сигурни, че прави това, което трябва да прави. Всичко се оказва страхотно.

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

Така че дългият цикъл на развитие е лош, защото не е в състояние да се адаптира към промените. Тогава, може би, е необходимо да се съкрати цикълът и всички проблеми ще бъдат решени? На фиг. 1b илюстрира трансформацията на модела на водопада в итеративен модел.

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

Академичната общност на разработчиците на софтуер се зае с проблема с високата цена на промяната и създаде нови технологии - релационни бази данни, модулно програмиране, скриване на информация. Но какво ще стане, ако всички тези произведения вече са изчерпали своя потенциал? И можем да намерим нов начиннамалите разходите за извършване на промени, като не режете „водопада“ на парчета, а просто смесите всичките му компоненти? Резултатът е показан на фигура 1c. Нарекохме го „Екстремно програмиране“ (XP).

Анатомия на XP

XP се отдалечава от традиционния процес на създаване софтуерна системаи вместо еднократно планиране, анализ и проектиране в дългосрочен план, с XP всички тези дейности се изпълняват постепенно по време на разработката, като по този начин се постига значително намаляване на разходите за промени в програмата. Методите на XP са проектирани с мисъл за кумулативно използване, така че когато разберете един от тях, неизбежно ще разберете и останалите (вижте страничната лента). Страничната лента проследява историческия фон на този подход.)

Цикъл на разработка на XP

На фиг. 2 процес XP е свързан с различни времеви оси, където години, месеци, седмици и дни се използват като мерна единица. Клиентът определя следващата версия (release) на системата, като избира най-ценните функции (в XP те се наричат ​​stories - истории) от всички възможни. Стойността на функциите се определя от материалните и времеви разходи за тяхното изпълнение от екипа за разработка.

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

Истории

От гледна точка на XP, периодът, водещ до първото пускане на системата в реална работа, е опасна аномалия в кръговат на животапроект и той трябва да бъде преодолян възможно най-скоро. Работата по всеки проект обаче трябва да започне по някакъв начин.

На първо място е необходимо да се реши за какво е предназначена системата като цяло и какво трябва да може да прави на първо място. По правило е необходим известен анализ, за ​​да се вземат такива решения. Символизира се от тесния син правоъгълник на фиг. 1s. Не можете да започнете да програмирате, докато не разберете какво всъщност трябва да се програмира.

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

Версия

Както се вижда от фиг. 2, ние не прилагаме всички истории наведнъж. Клиентът първо избира малък набор от най-важните истории, които са логически свързани една с друга. И първо ги програмираме и пускаме в действие. След това се изпълнява всичко останало.

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

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

Повторение

Целта на всяка итерация е да стартира няколко нови, тествани и готови за изпълнение истории в производство. Този процес започва с план, който определя какви истории ще бъдат внедрени и как екипът за разработка ще изпълни тази задача. Докато тече разработката, клиентът предлага функционални тестове. В края на една итерация тестовете трябва да се изпълняват и разработчиците трябва да са готови за следващата итерация.

Започвайки да планират итерация, разработчиците отново молят клиента да избере най-ценните истории, този път измежду останалите за внедряване в тази версия. Разработчиците разделят историите на задачи - модули, които един човек може да изпълни за няколко дни. Ако има няколко технически предизвикателства, като например преместване в нова версиябази данни, те също са включени в общия списък.

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

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

Задача

За да изпълни дадена задача, отговорният за нея програмист първо търси партньор, тъй като крайният код винаги се пише от двама души на една и съща машина. Ако възникнат въпроси относно предмета или методите на изпълнение, партньорите провеждат кратка (15-минутна) среща с клиента и/или програмисти, които са запознати с проблемите на кодирането, които е най-вероятно да бъдат свързани с кода на тази задача по време на прилагането.

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

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

След като тестът проработи, може отново да разберем как да подобрим системата, което ще направим.

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

Тест

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

Някои методологии, по-специално Cleanroom, забраняват на програмистите да тестват и в някои случаи дори да компилират своите програми. Обикновено програмистът пише код, компилира го, уверява се, че работи и след това го изпраща на някаква организация за тестване. Традиционните методи за сравнителен анализ включват преминаване през код и променливи, интерпретиране на резултатите от отчети за печат, тестване на бутони на менюто и т.н.

XP не въвежда никакви нови техники за тестване в сравнение с конвенционалните методи. Просто тестването се извършва под различна форма и вместо да правите нещо, което няма да остави следа след приключване на тестването, вие създавате тестове за дългосрочен план. Тези тестове работят днес, ще работят в деня, в който системната интеграция приключи, и на следващия ден, и след седмица, и следващата година. Увереността в нормалната работа на всеки отделен тест постепенно изгражда доверие сред разработчиците в нормалната работа на системата като цяло.

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

Имате проблеми?

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

Преоценка на собствените способности.Понякога поемате повече, отколкото можете да понесете. Необходимо е да сведете до минимум броя на такива ситуации, като прибягвате до количествени оценки на работата си възможно най-често. Ако се окажете претоварени, първо потърсете причината в себе си. Анализирайте: може би сте твърде разсеяни от решаването на практически проблеми. Напълно ли сте ангажирани с тестването, работата с партньор, преработването на системата и интегрирането? Правите ли повече от необходимото на клиента в момента?

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

Ако клиентът не съдейства.Представете си ситуация, в която клиентът не приема правилата на вашата игра. Не измисля тестове, не приоритизира, не формулира истории. Първо опитайте да инсталирате доверителна връзкас клиента. Чрез увеличаване на функционалността на системата от итерация на итерация, дайте на клиента възможност да контролира процеса на разработка. Ако взаимното доверие не работи, анализирайте дали вината е ваша. Правите ли всичко за ефективно взаимодействие с клиента?

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

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

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

Новите членове на екипа на XP в хода на работа по първите две итерации са ограничени до подпомагане на по-опитния партньор в двойката, изучаване на тестове и комуникация с клиента. Чувствайки по-голяма увереност в своите способности, те ще могат да поемат отговорност за определена задача. По време на разработването на следващите няколко итерации производителността на новодошлите се увеличава толкова много, че те могат да демонстрират на всички изпълнението на конкретни задачи навреме. След няколко месеца те вече не могат да бъдат разграничени от опитни членове на екипа.

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

Променящи се изисквания.Проблемът с проблемите за повечето системи за разработка изобщо не е такъв за XP. Създаден днес за решаване на конкретни проблеми, проектът XP ще се справи с всякакви промени във функционалността в бъдеще със същата ефективност. Ще бъде по-лесно да направите нещо подобно на вече направеното, тъй като XP изповядва принципа "формулирайте всяка мисъл веднъж и само веднъж". Най-често възниква необходимостта от такава обработка. Но дори и в случай, че се появи напълно ново изискване за системата, не е необходимо да изграждате набързо нови механизми за нейната работа.

В началото нямах ясна представа за адаптивността на XP към промени. В първата версия на XP процесът на избор на история беше част от планирането на версията и историите бяха присвоени на всички итерации във версията. След това разработчиците откриха, че с по-малко усилия за планиране могат да постигнат най-добри резултати. Следователно сега от клиента се иска да посочи само тези истории, които трябва да присъстват в следващата итерация. Ако се появи нова история, поставяте го в резерв и не разбърквате останалата част от повторението. След една-две седмици, ако новата история все още не е загубила своята актуалност, клиентът ще я избере.

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

Без съмнение XP е елегантна, логически завършена идея. Все още не са напълно ясни границите на неговата приложимост. Възприемайки този подход сега, вие трябва да покажете известна смелост, гъвкавост и готовност да се откажете от проекта, ако се провали. XP трябва първо да се изпробва в онези проекти, където ползите от този подход са очевидни: при индивидуална или вътрешна разработка на малки системи, изискванията за които не са ясно дефинирани и могат да се променят.

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

Силното разграничение в XP между бизнес и технически решения се връща към работата на архитект Кристофър Александър. Неговата книга The Timeless Way of Building отбелязва, че тези, които управляват сграда, трябва да могат да вземат важни решения по време на нейното изграждане.

Принципите на XP за бързо развиване на план в съответствие с технически и свързани с бизнеса промени отразяват принципите на методологията Scrum и езика за шаблони на Episodes, разработен от Ward Cunningham.

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

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

Спираловият модел от Бари Бьом беше първата реакция на остаряването на модела на водопада. За дълго времев овладяването на мощни технологии никой не може да надмине Дейв Томас и неговите колеги от Object Technology International, които създадоха метода JIT.

Корените на принципа на метафората, използван в XP, могат да бъдат намерени в книгите на Джордж Лакоф и Марк Джонсън, по-специално тяхната последна работа Philoslphy in the Flesh. Този принцип е предложен и от Ричард Койн, който свързва метафората и разработката на софтуер от гледна точка на постмодерната философия.

И накрая, голяма част от акцента на XP върху организацията на офиса произтича от работата на Джим Коплиен, Том Демарко и Тим Листър, които отбелязват влиянието на условията на околната среда върху работата на програмистите.

Примери за изпълнение на проекти с помощта на XP

Аксиома: по пътя към постигане на обща цел

Джи Ханула

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

Приложение:база данни за управление на кампании

Период на изпълнение: 3 години

Acxiom създаде приложение за управление на бизнеса, базирано на хранилището на данни, използвайки разпределения обектно-ориентиран инструментариум за разработка Forte. Малък екип от разработчици - само 10 души - твърдо се придържаха към принципите на обектно-ориентираното програмиране и съвместната разработка при създаването на приложението. От трите години, необходими за разработването, през последните две години екипът, включващ мениджъри, бизнес анализатори, разработчици, тестери и технически писатели, използва екстремни методи за програмиране и ето как успяха.

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

Много усилия бяха положени за тестване на единици, защото Forte не предлага вградени основни инструменти за тестване. Трябваше да създадем наши собствени и да ги използваме за успешен тест. Наскоро преминахме към езика за програмиране Java и сега използваме JUnit като инструмент за тестване.

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

Разбрахме, че всеки член на екипа трябва да следва принципите на XP, в противен случай този подход няма да работи. Сега незабавно предупреждаваме потенциален разработчик, че ако не е доволен от възприетия от нас стил, по-добре да потърси работа в друг екип. Един човек, който не се интересува от избрания метод на развитие, може да обезсили усилията на целия екип. Същността на XP е колективното разработване на нови идеи в процеса на създаване на система.

Съществува погрешно схващане за HR, че този подходпотиска творческата дейност и развитието на индивидуалните способности на разработчика. Всъщност всичко е точно обратното. XP стимулира творческия растеж на програмиста и дава шанс на отделните членове на екипа да блеснат. Основното нещо е да решите и твърдо да се придържате към избраната посока.

„Екстремното програмиране” не постави екипа ни в екстремни условия. Този метод използва добре познати и до голяма степен познати подходи за разработка. Всички работят в тясно сътрудничество и заедно вървят към целта.

DaimlerChrysler: най-добрият отбор в света

Чет Хендриксен

екип: 15 души, включително 10 програмисти

Приложение:пълна автоматизация на изчисляването на заплатите

Период на изпълнение: 4 години

Работата по проекта C3 започва през януари 1995 г. Chrysler Corporation сключи договор с партньорска компания, според който съвместен екип за разработка от двете организации се зае с проекта. Нашите партньори следваха методология за развитие, фокусирана върху употребата GUIи игнорира автоматизацията на теста. Резултатът беше система, която беше пълна с невпечатляващи графики и изчисляваше заплатата неправилно за повечето служители. Ще отнеме около 100 дни за такава система, за да генерира месечна заплата. Разбрахме, че програмата, която написахме, никога няма да бъде използвана.

Свързахме се с Кент Бек, за да ни помогне да настроим производителността на системата. Той откри в нас същите явления, с които се сблъсква постоянно, когато поема задачата за настройка на производителността: лошо проектиран код, тестове, които не могат да бъдат повторени, ръководство, което е загубило доверие в своя проект. Кент Бек препоръча да изхвърлите целия написан код и да започнете пълноценен XP проект.

Предишният договор беше прекратен и Chrysler почти наполовина актуализира своя екип за разработка. От този момент нататък действахме според правилата на XP. Бяха разпределени отговорности, планирани итерации, установени правила за тестване, програмирането по двойки тествано и прието като стандарт. До края на 33-тата седмица имахме система, в която вече можехме да започнем да отстраняваме грешки в производителността и да провеждаме паралелни тестове. Можем да започнем да променяме производителността, тъй като системата беше добре обмислена и подкрепена пълен комплектединици тестове. Бяхме готови за паралелно тестване, тъй като серия от функционални тестове ясно демонстрираха на клиента, че системата има необходимите възможности.

Тази фаза от внедряването на C3 стартира през май 1997 г., въпреки че очаквахме по-ранна дата. Провалът на нашите планове се дължи на два фактора. Първо решихме да сменим само вътрешните компоненти платежна система. Всички външни интерфейси останаха недокоснати. Изход за съвпадение нова системакомпоненти на стария се оказаха много повече предизвикателна задачаотколкото очаквахме. Второ, решихме да не инициираме специални изисквания по време на който и да е период на плащане, като обработка на W-2, споделяне на печалба или общо увеличение. заплати. В резултат това, което трябваше да бъде направено през ноември, беше отложено за април.

От стартирането на системата за изчисляване на месечните плащания добавихме няколко нови функции и автоматизирано изчисляване на плащанията на всеки две седмици. Заплатата за пилотната група се изчислява от август 1998 г. и се надяваме да имаме работеща система за останалите служители до ноември 1999 г.

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

Ford Motor: уникална комбинация от ефективност и качество

Дон Уелс

екип: 17 души, включително 12 програмисти

Приложение:система за анализ на разходите

Период на изпълнение: 6 години

Отделът за финансови системи на Ford Motor Company разработва системата за анализ на разходите и печалбата на превозните средства (VCAPS), която генерира отчети за производствени приходи, разходи, нетни приходи и печалба. Входящите данни в системата са спецификации на инженерни продукти, фиксирани разходи и разходи и променливи разходи, като работни часове. VCAPS събира всички тези данни и изготвя подробни отчети с анализ на разходите, които позволяват ефективно прогнозиране и вземане на корпоративни решения. Работата по проекта VCAPS започва през 1993 г. Разработен с помощта на VisualWorks и GemStone Smalltalk. В момента VCAPS се поддържа от малък екип от хора и скоро ще бъде заменен от по-модерно приложение.

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

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

Работата по методите на XP започна с етапа на планиране. И се оказа грешка. Клиентите и ръководството не са свикнали да определят работните графици заедно. Случилото се в резултат страда от липса на правдоподобност и практическа приложимост. Трябваше да преминем към планове на MS Project, които можеха да се променят без организиране на общи събрания и с помощта на които получихме планове във формата, позната на ръководството.

След това направихме няколко модулни теста и след една година 40% от системата беше тествана, а ръководството отбеляза 40% намаление на броя на съобщенията за грешки. След това XP получи голямо внимание.

Решихме проблемите, като внедрихме всички нови методи на XP. Тестовете ни позволиха да преминем към непрекъсната интеграция и чести промени на версиите. Това от своя страна проправи пътя за колективна собственост и препроектиране на системата. Имахме за цел да създадем прост проект. Най-накрая дойде моментът, в който решихме да опитаме да програмираме по двойки. И ние трябваше да работим много, за да постигнем този успех. Първоначално нашите разработчици намериха този метод за изключително неудобен; Отне известно време, за да свикна и да се чувствам доста комфортно в него.

След година и половина броят на системните повреди намаля толкова много, че нашите клиенти и ръководство можеха да заявят значително по-висока стабилност на системата. За нас това символизира успеха на принципите на XP.

Тарифна система: тестове, които можете да прочетете

Роб Ми

екип:трима разработчици

Приложение:система за изчисляване на транспортните тарифи

Период на изпълнение: 3 месеца

Tariff System е част от голям проект, реализиран с помощта на SmallTalk/GemStone в една от големите международни компании, специализирани в контейнерни превози. Подходът XP направи възможно преминаването през всички етапи на разработването на тази подсистема, от концепцията до въвеждането в експлоатация, за три месеца от трима души. Резултатът беше забележително стабилен и лесен за поддръжка.

Започвайки работа по проекта, веднага решихме твърдо да се придържаме към няколко основни принципи XP: винаги кодирайте по двойки, поддържайте архитектурата възможно най-проста, активно преработвайте системата и пишете много модулни тестове. Всички тези принципи са доказали своята ефективност. Една идея за XP ни се стори малко пресилена в началото - да пишем тестове за кода, преди да бъде написан самият код. Още повече бяхме изненадани да установим, че този принцип ни позволява да идентифицираме архитектурни проблеми и ускорява процеса на разработка.

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

Докато създавахме и преработвахме тестови случаи, осъзнахме, че за писане на основни обекти на домейн, малките езици, специално измислени за тях, ще бъдат много полезни, благодарение на които тестовият код става много по-сбит и четим. Освен това спряхме да губим време в изобретяване на начини за задаване на екземпляри на обекти в процеса на писане на тестове и дефинирахме граматики за десет класа домейн. Граматиката автоматично генерира анализатор, който се използва от конструктора за създаване на домейн обекта. Кодът за инстанциране на обект с помощта на стандартни конструктори ще бъде много дълъг, почти нечетлив и ще има малка прилика със самия тестов случай.

Възприемане на промяната с екстремно програмиране, Кент Бек. Компютър, октомври 1999 г., стр. 70-77, Препечатано с разрешение, Copyright IEEE, 1999, Всички права запазени.

Екстремното програмиране (XP) е опростена методология за разработка на софтуер за малки до средни екипи за разработка, които изграждат софтуерен продукт с неясни или бързо променящи се изисквания.

Основните цели на XP са повишаване на доверието на клиентите към софтуерния продукт чрез предоставяне на реални доказателства за успеха на разработката на процеса на разработка и рязко намаляване на времето за разработка на продукта . В същото време XP е фокусиран върху минимизиране на грешки в ранните етапи на разработка. Това прави възможно постигането на максимална скоростпускането на готовия продукт и дава възможност да се говори за предвидимостта на работата. Почти всички XP техники са насочени към подобряване на качеството на софтуерния продукт.

Принципи XP

Основните принципи са:

• Повторение.Разработката се извършва на кратки итерации при наличие на активна връзка с клиента. Предлага се итерациите като такива да бъдат кратки, препоръчителната продължителност е 2-3 седмици и не повече от 1 месец. В една итерация група програмисти трябва да внедрят няколко характеристики на системата, всяка от които е описана в потребителска история. Потребителските истории (UI) в този случай са първоначалната информация, на базата на която се създава модулът. Те се различават от случаите на употреба (UT). Описанието на PI е кратко - 1-2 параграфа, докато PI обикновено се описва достатъчно подробно, с основните и алтернативните потоци и се допълва от модел. UI се пишат от самите потребители, които в XP са част от екипа, за разлика от UI, които системният анализатор описва. Липсата на формализиране на описанието на входните данни на проекта в XP се търси да се компенсира с активното включване на клиента в процеса на разработка като пълноправен член на екипа.
• Простота на решенията.Приема се първото най-просто работещо решение. Екстремният характер на метода е свързан с висока степенрискът от вземане на решение поради повърхностността на анализа и твърдия времеви график. Минималният набор от основните функции на системата се изпълнява при първата и всяка следваща итерация; функционалността се разширява при всяка итерация.
• Интензивно развитие от малки екипи(не повече от 10 души) и програмиране по двойки(когато двама програмисти създават код заедно на едно общо работно място), активна комуникация в групата и между групите. Всичко това има за цел възможно най-ранното откриване на проблеми (както грешки, така и пропуснати срокове). Програмирането по двойки е насочено към решаване на проблема със стабилизирането на проекта. При използване на методологията на XP съществува висок риск от загуба на код поради напускането на програмист, който не може да издържи на интензивен работен график. В този случай вторият програмист от двойката играе ролята на "наследник" на кода. Важно е и как са разпределени групите в работното пространство - XP използва отворено работно пространство, което предполага бърз и безплатен достъп за всеки за всеки.
• Обратна връзка от клиента, чийто представител реално участва в процеса на разработка.
• Достатъчна степен на смелости желание за поемане на рискове.

XP трикове (практики)

Обикновено XP се характеризира с набор от 12 правила (практики), които трябва да се следват, за да се постигне добър резултат. Нито една от практиките не е фундаментално нова, но те са обединени в XP.

1. Планиране на процеса.Целият екип за разработка се събира, взема се колективно решение кои функции на системата ще бъдат внедрени в следващата итерация. Сложността на изпълнението на всяко свойство се определя от самите програмисти.
2. Тясно взаимодействие с клиента.Представителят на клиента трябва да е член на екипа на XP. Той пише потребителския интерфейс, избира историите, които ще бъдат внедрени в определена итерация, и отговаря на въпроси, свързани с бизнеса. Представител на клиента трябва да бъде експерт в автоматизираната предметна област. Необходима е постоянна обратна връзка от представителя на клиента.
3. Общи правила за именуване на системата.Добри конвенции за именуване на системата лекота на именуване класове и променливи. Екипът за разработка трябва да има еднакви конвенции за именуване.
4. Проста архитектура.Всяко свойство на системата трябва да се реализира възможно най-просто. Програмистите в екипа на XP работят под мотото: „Нищо повече!“. Първото просто работещо решение е прието, необходимото ниво на функционалност се внедрява в момента. Това спестява време на програмиста.
5. Рефакторинг.Това е оптимизация на съществуващия код с цел опростяването му.Такава работа трябва да се извършва постоянно. Като поддържат кода прозрачен и дефинират елементите му само веднъж, програмистите намаляват броя на грешките, които трябва да бъдат коригирани по-късно. Когато внедрява всяко ново свойство на системата, програмистът трябва да обмисли дали съществуващият код може да бъде опростен и как това ще помогне за внедряването на новото свойство. Освен това не можете да комбинирате рефакторинг с дизайн: ако създавате нов код, рефакторингът трябва да се отложи.
6. Програмиране по двойки.Всички програмисти трябва да работят по двойки: единият пише кода, другият гледа. По този начин е необходимо да се постави група от програмисти на едно място. XP работи най-добре в неразпределени екипи от програмисти и потребители.
7. 40 часова работна седмица.Програмистът не трябва да работи повече от 8 часа на ден. Нуждата от извънреден труд е ясен индикатор за проблем в тази конкретна област на развитие. Откриването на причините за извънредния труд и своевременното им отстраняване е едно от основните правила.
8. Колективна собственост на кода.Всеки програмист в екипа трябва да има достъп до кода на всяка част от системата и правото да прави промени във всеки код. Задължително правило: ако програмист е направил промени и след това системата не работи правилно, тогава този програмист трябва да коригира грешките.
9. Единни стандарти за кодиране.Стандартите за кодиране са необходими за поддържане на други практики: споделяне на код, програмиране по двойки и рефакторинг. Без единен стандарт е най-малкото по-трудно да се изпълняват тези практики, но в действителност като цяло е невъзможно: групата ще работи в режим на постоянна липса на време. Екипът работи по проекта дълго време. Хората идват и си отиват. Никой не кодира сам и кодът принадлежи на всички. Винаги ще има моменти, когато ще е необходимо да разберете и коригирате кода на някой друг. Разработчиците ще премахват дублиращия се код, ще анализират и подобряват класове на други хора и т. н. С течение на времето няма да е възможно да се каже кой е авторът на определен клас. Следователно всеки трябва да се подчинява на общите стандарти за кодиране - форматиране на кода, клас, променлива, постоянно именуване, стил на коментар. Горното означава, че всички членове на екипа трябва да се споразумеят за общи стандарти за кодиране. Каквото и да става, но всеки е длъжен да им се подчинява.
10. Малки издания.Минималната итерация е един ден, максималната е месец; колкото по-често се правят издания, толкова повече недостатъци в системата ще бъдат разкрити. Първите версии помагат да се идентифицират недостатъците на най-ранните етапи, след което функционалността на системата се разширява въз основа на потребителския интерфейс. Тъй като потребителят е включен в процеса на разработка от първото издание, той оценява системата и издава потребителска история и коментари. Въз основа на това се определя следващата итерация, тоест каква ще бъде новата версия. Всичко за XP е свързано с предоставянето на непрекъсната обратна връзка на потребителите.
11. Непрекъсната интеграция.Интегрирането на нови части на системата трябва да се извършва възможно най-често, поне веднъж на всеки няколко часа. Основното правило на интеграцията е следното: интеграцията може да се извърши, ако всички тестове преминат успешно. Ако тестовете не преминат, тогава програмистът трябва или да направи корекции и след това да интегрира компонентите на системата, или да не ги интегрира изобщо. Това правило е твърдо и недвусмислено. Ако има поне една грешка в създадената част от системата, тогава интеграцията не може да бъде извършена. Честата интеграция ви позволява да получите готова система по-бързо, вместо да харчите седмица за сглобяване.
12. Тестване.За разлика от повечето други методологии, тестването в XP е един от най-важните компоненти. Екстремният подход предполага това тестовете се пишат преди да се напише кодът . Всеки модул трябва да има unit test - тест за този модул. По този начин XP извършва регресионно тестване, "невлошаващо качество" при добавяне на функционалност. Повечето грешки се коригират на етапа на кодиране. Тестовете се пишат от самите програмисти, всеки от тях има право да напише тест за всеки модул. Друг важен принцип: тестът определя кода, а не обратното (разработка, управлявана от тестове), тоест част от кода се поставя в хранилището, ако и само ако всички тестове са преминали успешно, в противен случай тази промяна на кода се отхвърля.

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

И други.

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

Енциклопедичен YouTube

1 / 5

Екстремно програмиране (XP) - основни техники

Hexlet Webinar #6: Екстремно програмиране

житейски съвети. Защо да участвате в състезания по програмиране?

032. Програмиране по двойки - Сергей Бережной

Extreme Programming Channel v. 2.0

субтитри

XP основни трикове

Дванадесетте основни техники на екстремното програмиране (според първото издание на книгата Обяснено екстремно програмиране) могат да бъдат групирани в четири групи:

• Кратък цикъл на обратна връзка (обратна връзка с фин мащаб)
  • Разработка чрез тестване (разработка, управлявана от тестове)
  • Игра за планиране
  • Клиентът е винаги там (Цял екип, клиент на място)
  • Програмиране по двойки
• Непрекъснат, а не партиден процес
  • Непрекъсната интеграция
  • Рефакторинг (Подобряване на дизайна, Рефакторинг)
  • Чести малки издания
• Споделено от всички разбиране
  • Простота
  • Системна метафора
  • Колективна собственост върху код или избрани шаблони за проектиране (Колективна собственост върху модели)
  • Стандарт за кодиране или конвенции за кодиране
• Социално осигуряване на програмиста (Programmer welfare):
  • 40-часова работна седмица (устойчиво темпо, 40-часова седмица)

Тестване

XP включва писане на автоматизирани тестове (програмен код, написан специално за тестване на логиката на друг програмен код). Особено внимание се обръща на два вида тестове:

• модулно тестване на модули;

Разработчикът не може да бъде сигурен в коректността на кода, който пише, докато не работят абсолютно всички модулни тестове на системата, която разработва. Единичните тестове (единични тестове) позволяват на разработчиците да се уверят, че всеки от тях поотделно работи правилно. Те също така помагат на други разработчици да разберат защо е необходима определена част от кода и как функционира - в хода на изучаване на тестовия код става ясна логиката на тествания код, тъй като е ясно как трябва да се използва. Единичните тестове също така позволяват на разработчика да рефакторира без никакъв страх.

Функционалните тестове са предназначени да тестват функционирането на логиката, образувана от взаимодействието на няколко (често доста впечатляващи по размер) части. Те са по-малко подробни от модулните тестове, но покриват много повече - тоест тестове, които при изпълнението си засягат по-голямо количество код, очевидно имат по-голям шанс да открият някакво неправилно поведение. Поради тази причина в индустриалното програмиране писането на функционални тестове често има предимство пред писането на модулни тестове.

За XP с по-висок приоритет е подходът, наречен TDD (от англ. test-driven development - развитие чрез тестване). В съответствие с този подход първо се пише тест, който първоначално се проваля (тъй като логиката, която трябва да провери, просто все още не съществува), след което се прилага логиката, необходима за преминаването на теста. TDD в известен смисъл ви позволява да пишете код, който е по-удобен за използване - защото при писане на тест, когато все още няма логика, е най-лесно да се погрижите за удобството на бъдещата система.

Играта на планиране

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

Клиентът е винаги там

„Клиентът“ в XP не е този, който плаща сметките, а крайният потребител на софтуерния продукт. XP твърди, че клиентът трябва да бъде във връзка през цялото време и да е на разположение за въпроси.

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

Програмиране по двойкипредполага, че целият код е създаден от двойки програмисти, работещи на един и същи компютър. Единият работи директно с текста на програмата, другият гледа работата си и следи цялостната картина на случващото се. Ако е необходимо, клавиатурата се прехвърля свободно от един на друг. Докато работите по проект, двойките не са фиксирани: препоръчително е да ги смесите, така че всеки програмист в екипа да има добра представа за цялата система. По този начин програмирането по двойки подобрява взаимодействието в екипа.

Непрекъсната интеграция

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

Рефакторинг

Рефакторингът е техника за подобряване на кода без промяна на неговата функционалност. XP предполага, че след като кодът е написан, той почти сигурно ще бъде преработен много пъти по време на проекта. Разработчиците на XP безмилостно преработват предварително написан код, за да го подобрят. Този процес се нарича рефакторинг. Липсата на тестово покритие провокира отхвърлянето на рефакторинг поради страх от счупване на системата, което води до постепенно влошаване на кода.

Чести малки издания

Версиите (изданията) на продукта трябва да се произвеждат възможно най-често. Работата по всяка версия трябва да отнема възможно най-малко време. В същото време всяка версия трябва да е достатъчно значима от гледна точка на полезност за бизнеса.

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

Лесен дизайн

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

Системна метафора

Архитектурата е представяне на компонентите на системата и техните взаимовръзки. Разработчиците трябва да анализират софтуерната архитектура, за да разберат къде в системата трябва да добавят нова функционалност и с какво ще взаимодейства новият компонент.

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

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

Стандарти за кодиране

Всички членове на екипа трябва да спазват изискванията на общите стандарти за кодиране в процеса на работа. По този начин:

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

Ако екипът не използва единни стандарти за кодиране, за разработчиците става по-трудно да преработят; при смяна на партньори по двойки има повече трудности; като цяло напредъкът на проекта е труден. В рамките на XP е необходимо да се гарантира, че е трудно да се разбере кой е авторът на тази или онази част от кода - целият екип работи по единен начин, като един човек. Екипът трябва да формира набор от правила и след това всеки член на екипа трябва да следва тези правила по време на процеса на кодиране. Списъкът с правила не трябва да бъде изчерпателен или твърде обемист. Задачата е да се формулират общи насоки, които да направят кода разбираем за всеки от членовете на екипа. Стандартът за кодиране трябва да бъде прост в началото, след това постепенно може да стане по-сложен, когато екипът за разработка натрупа опит. Няма нужда да отделяте твърде много време за предварително изготвяне на стандарт.

Колективна собственост

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