Екстремно програмиране – Екстремно програмиране. Методологии за разработка на софтуер

Оставете коментар 6,950

Изпратете добрата си работа в базата от знания е лесно. Използвайте формата по-долу

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

Публикувано на http://www.allbest.ru/

Съдържание

Въведение
1. Какво е XP?
3.1 Основни техникиXP
4. Предимства и недостатъци
5. История на употреба
Заключение

Въведение

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

XP често се представя като набор от техники, но самият XP не е финалната линия. Няма нужда да практикувате и развивате HR все по-добре, за да получите дългоочакваната златна звезда в края на този процес. Напротив, XP е началната линия. XP задава въпроса: "Колко минимални могат да бъдат нашите усилия, за да можем да продължим да произвеждаме качествен софтуер?"

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

1. Какво е XP?

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

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

Използвайки изключително кратки цикли на разработка, XP предлага бърза, реална и постоянна обратна връзка.

XP използва постепенно планиране, което води до възникване на цялостен план на проекта доста бързо, но се разбира, че този план се развива през целия живот на проекта.

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

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

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

XP се основава на развиващ се процес на проектиране, който продължава, докато съществува самата система.

XP се основава на тясно взаимодействие между програмисти с най-общи умения и способности.

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

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

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

2. Къде започва екстремното програмиране?

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

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

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

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

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

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

3. Техники на XP

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

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

· Хората, участващи в даден проект и тяхната комуникация са по-важни от процесите и инструментите.

· Работната програма е по-важна от изчерпателната документация.

· Сътрудничеството с клиента е по-важно от обсъждането на детайлите по договора.

· Работата по промените е по-важна от придържането към плановете.

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

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

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

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

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

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

Ориз.1 Диаграма на работния процес на XP

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

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

· Метафора (метафора) системи

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

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

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

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

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

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

· развитиеНабазатестване (тест- задвижванразвитие)

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

XP поставя особен акцент върху два вида тестване:

ь тестване на единици;

b тестване за приемане.

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

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

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

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

· Константарециклиране (рефакторинг)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· ВключванеклиентVекип (На- сайтклиент)

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

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

· Използванекодкаксъоръжениякомуникации

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

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

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

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

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

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

3.1 Основни XP техники

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

· Кратък цикъл на обратна връзка (фина обратна връзка)

o Разработка, насочена към тестване

o Игра за планиране

o Клиентът е винаги наблизо (Цял екип, клиент на място)

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

Непрекъснат, а не партиден процес

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

o Рефакторинг (Подобряване на дизайна, Рефакторинг)

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

· Споделено от всички разбиране

o Простота (прост дизайн)

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

o Притежаване на колективен код или избрани модели на дизайн (притежание на колективни модели)

o Стандарт за кодиране или конвенции за кодиране

· Благосъстоянието на програмиста:

o 40-часова работна седмица (устойчиво темпо, четиридесет часова седмица)

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

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

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

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

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

4. Предимства и недостатъци

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

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

5. История на употреба

XP като набор от описани техники беше използван за първи път по време на работата по проекта C3 (Chrysler Comprehensive Compensation System, разработване на система за отчитане на доходите на служителите в Daimler Chrysler). От 20-те участници в този проект, 5 (включително гореспоменатите 3 основни автора на XP) публикуваха 3 книги и огромен брой статии, посветени на XP по време на самия проект и впоследствие. Следните данни илюстрират проблемите с някои XP техники, когато се прилагат към доста сложни проекти.

Проектът стартира през януари 1995 г. От март 1996 г., след включването на Кент Бек, той се изпълнява с помощта на XP. По това време той вече е надхвърлил бюджета и плановете за поетапно изпълнение на функциите. Екипът за разработка беше съкратен и около шест месеца след това проектът се развиваше доста успешно. През август 1998 г. се появява прототип, който може да обслужва около 10 000 служители. Първоначално се очакваше проектът да бъде завършен в средата на 1999 г. и полученият софтуер ще се използва за управление на ползите за 87 000 служители на компанията. Той беше спрян през февруари 2000 г. след 4 години работа с XP поради пълно неспазване на времеви рамки и бюджет. Създаденият софтуер никога не е бил използван за работа с данни за повече от 10 000 служители, въпреки че е доказано, че може да обработва данни за 30 000 служители на компанията. Човекът, който играеше ролята на клиента, включен в екипа на проекта, се отказа след няколко месеца такава работа, не издържа на натоварването и така и не получи адекватен заместник до края на проекта.

Заключение

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

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

Публикувано на Allbest.ru

Подобни документи

Анализ на етапите и особеностите на разработването на оптимален и функционален ARIS модел - софтуерен продукт на IDS Scheer за моделиране на бизнес процесите на компанията. Изучаване на основните концепции, методологии и подходи на екстремното програмиране.

тест, добавен на 06/04/2011

Основните етапи на разработване на софтуер (софтуерен пакет), анализ на системните изисквания. Метод на поетапно детайлизиране. Езици за програмиране на ниско и високо ниво (императивни, обектно-ориентирани, функционални, логически).

презентация, добавена на 13.10.2013 г

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

урок, добавен на 26.10.2013 г

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

презентация, добавена на 30.04.2014 г

Машинни кодове и асемблер. Първите езици за програмиране на високо ниво. Програмен език FORTRAN. Предимства и недостатъци на ALGOL. Научни и счетоводни програми. Основните принципи, които са следвани при създаването на основния език за програмиране.

курсова работа, добавена на 21.06.2014 г

Концепцията и ключовата разлика в разпределената разработка на софтуер, нейните предимства и недостатъци. Идейно решение и избор на вид застрояване. Характеристики на софтуера с отворен код. Идеята и развитието на Open Source.

курсова работа, добавена на 14.12.2012 г

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

презентация, добавена на 14.08.2013 г

Международен стандарт за езика за програмиране Pascal. Техники на обектно-ориентираното програмиране в Turbo Pascal. Символи на езика, неговата азбука. Етапи на развитие на програмата. Понятие за алгоритми и алгоритмизация. Структура на програмите в Pascal.

курсова работа, добавена на 28.02.2010 г

Съвременни средства за разработка на софтуер за системи за управление. Универсални езици за програмиране и тяхното сравнение със SCADA системи. Разработка на софтуер с помощта на многоканални измервателни преобразуватели Ш9327.

дисертация, добавена на 13.07.2011 г

Основни техники за работа в програмна среда Delphi. Характеристики на технологията за създаване на прости приложения. Работа с компоненти на средата за разработка на приложения. Въвеждане, редактиране, подбор и извеждане на информация. Аспекти на използване на разклонена структура.

Extreme Programming или XP, eXtreme Programming е гъвкава методология за разработка на софтуер. Подобно на други гъвкави методологии, той има специфични инструменти, процеси и роли. Въпреки че авторът на XP не излезе с нищо ново, но взе най-добрите практики на гъвкаво развитие и ги засили до максимум. Ето защо програмирането се нарича екстремно.

Автор на метода е американският разработчик Кент Бек. В края на 90-те той ръководи проекта на Chrysler Comprehensive Compensation System и там е пионер в практиката на екстремно програмиране. Той описа опита си и създадената от него концепция в книгата Extreme Programming Explained, публикувана през 1999 г. Тя беше последвана от други книги, описващи подробно XP практиките. В разработването на методологията участват още Уорд Кънингам, Мартин Фаулър и др.

XP се различава от другите гъвкави методологии по това, че се прилага само в областта на разработката на софтуер.Не може да се използва в друг бизнес или ежедневието като scrum, kanban или lean.

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

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

1. Целият екип

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

2. Игра за планиране

Планирането в XP се извършва на два етапа - планиране на пускане и планиране на итерация.

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

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

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

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

3. Чести версии на версията

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

4. Потребителски тестове

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

5. Колективна собственост върху кода

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

6. Непрекъснато интегриране на код

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

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

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

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

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

9. Равномерно темпо

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

10. Разработка, управлявана от тестове

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

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

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

12. Опростен дизайн

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

13. Рефакторинг

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

Предимства и недостатъци на XP

Методологията на XP предизвиква много спорове и критики от онези, които никога не са успели да я внедрят в своя екип.

Ползите от екстремното програмиране имат смисъл, когато екипът използва напълно поне една от XP практиките. И така, какво си струва да опитате:

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

Въпреки всички предимства, XP не винаги работи и има редица слабости. И така, екстремно програмиране - недостатъци:

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

Принципи на XP

В първата си книга Кент Бек артикулира принципите на екстремното програмиране: простота, комуникация, обратна връзка и смелост. В новото издание на книгата той добави и пети принцип – уважението.

1. Простота

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

2. Комуникация

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

3. Обратна връзка

Обратната връзка в XP се реализира в три посоки наведнъж:

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

4. Смелост

Някои екстремни техники за програмиране са толкова необичайни, че изискват смелост и постоянен самоконтрол.

5. Уважение

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

Алгоритъм за внедряване на XP методология и работен процес

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

За да внедрите XP в съществуващ проект, трябва постепенно да овладеете неговите техники в следните области:

тестване
дизайн
планиране
управление
развитие

Тестване.

Екипът създава тестове ПРЕДИ да напише нов код и постепенно преработва стария код. За стар код тестовете се пишат според нуждите: когато трябва да добавите нова функционалност, да коригирате грешка или да преработите част от стария код.

Дизайн.

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

Планиране.

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

Управление.

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

развитие.

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

В проект, който работи по методологията на XP, процесът е структуриран по следния начин:

Който използва XP

Според проучване на Versionone от 2016 г. само 1% от гъвкавите компании използват екстремно програмиране в чист вид. Други 10% работят, използвайки хибридна scrum и XP методология.

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

Не е лесно да се намери информация за екипи, които използват XP, но има и такива, които рекламират, че тази методология е причината за техния успех. Пример за екстремно програмиране е Pivotal Software, Inc.

Pivotal Software, Inc.

Американска софтуерна компания, която разработва софтуер за бизнес анализ, базиран на големи данни и предоставя консултантски услуги. Основните продукти се използват от Ford, Mercedes, BMW, GAP, Humana, големи банки, държавни агенции, застрахователни компании и др.

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

Екстремно програмиране,
Екстремно програмиране: Планиране,
Екстремно програмиране: Разработка, водена от тестове / Кент Бек

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

Рефакторинг: Подобряване на съществуващ код / Мартин Фаулър

Екстремно програмиране: формулиране на процеса. От първите стъпки до горчивия край / Кен Ауер, Рой Милър

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

Приложения за внедряване на XP в екип

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

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

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

Джира

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

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

Присъда

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

Тази методика е предназначена изключително за полето разработване на софтуери не може да се адаптира за друг бизнес.

Това е една от най-трудните методики за изпълнение, защото включва цели тринадесет практики!

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

Никой не ви принуждава да прилагате XP на базата на всичко или нищо. В крайна сметка гъвкавите методологии трябва да бъдат гъвкави в своето приложение – съобразени с нуждите на конкретен екип и проект.

Развитие (развитие, водено от системни функции) и др.

Игра за планиране на живо
Неговата задача е да определи възможно най-бързо количеството работа, която трябва да бъде извършена преди следващата версия на софтуера. Решението се взема, на първо място, въз основа на приоритетите на клиента (т.е. неговите нужди, какво му трябва от системата, за да управлява бизнеса си по-успешно) и второ, въз основа на технически оценки (т.е. оценки на сложността на на развитие, съвместимост с други елементи на системата и др.). Плановете се променят веднага щом започнат да се разминават с реалността или желанията на клиента.
Чести промени на версиите (малки версии)
Първата работеща версия трябва да се появи възможно най-бързо и да започне да се използва веднага. Следващите версии се подготвят на сравнително кратки интервали (от няколко часа за малки промени в малка програма до месец или два за основна преработка на голяма система).
Метафора на системата
Метафората, в доста проста и разбираема за екипа форма, трябва да описва основния механизъм на системата. Тази концепция напомня на архитектурата, но трябва да описва основната същност на техническите решения, взети много по-просто, само с една или две фрази.
Опростени дизайнерски решения
Във всеки един момент системата трябва да бъде проектирана възможно най-просто. Не е необходимо да се добавят функции предварително - само след изрична заявка за това. Цялата ненужна сложност се премахва веднага щом бъде открита.
Разработка, управлявана от тестове
Разработчиците първо пишат тестове, след което се опитват да внедрят своите модули, така че тестовете да работят. Клиентите предварително пишат тестове, които демонстрират основните възможности на системата, за да видят дали системата наистина работи.
Непрекъснат рефакторинг
Програмистите непрекъснато преработват системата, за да премахнат ненужната сложност, да увеличат разбираемостта на кода, да увеличат неговата гъвкавост, но без да променят поведението му, което се проверява чрез стартиране след всяка преработка на тестовете. В същото време предпочитание се дава на по-елегантни и гъвкави решения, в сравнение с тези, които просто дават желания резултат. Неуспешно преработените компоненти трябва да бъдат идентифицирани по време на изпълнение на теста и върнати до последното непокътнато състояние (заедно с компонентите, които зависят от тях).
Програмиране по двойки
Кодирането се извършва от двама програмисти на един компютър. Сдвояването е произволно и варира от задача до задача. Този, в чиито ръце е клавиатурата, се опитва да реши текущия проблем по най-добрия начин. Вторият програмист анализира работата на първия и дава съвети, обмисля последствията от определени решения, нови тестове, по-малко директни, но по-гъвкави решения.
Колективна собственост върху кода
По всяко време всеки член на екипа може да промени всяка част от кода. Никой не трябва да има собствена зона на отговорност; целият екип е отговорен за целия код.
Непрекъсната интеграция
Системата се сглобява и се подлага на интеграционни тестове възможно най-често, няколко пъти на ден, всеки път, когато няколко програмисти завършат изпълнението на следващата функция.
40 часова работна седмица
Извънредният труд се разглежда като знак за по-големи проблеми в проекта. Не се допуска извънреден труд в продължение на 2 седмици подред – това изтощава програмистите и прави работата им значително по-малко продуктивна.
Включване на клиента в екипа (клиент на място)
Екипът за разработка винаги включва представител на клиента, който е на разположение през целия работен ден и може да отговори на всички въпроси относно системата. Негова отговорност е да отговаря своевременно на въпроси от всякакъв тип относно функциите на системата, нейния интерфейс, необходимата производителност, правилната работа на системата в трудни ситуации, необходимостта от поддържане на комуникация с други приложения и др.
Използване на код като средство за комуникация
Кодът се разглежда като най-важното средство за комуникация в екипа. Яснотата на кода е един от основните приоритети. Следването на стандартите за кодиране, които осигуряват тази яснота, е наложително. Такива стандарти, в допълнение към яснотата на кода, трябва да гарантират минимален език (без дублиране на код и информация) и трябва да бъдат приети от всички членове на екипа.
Отворено работно пространство
Екипът се помещава в една доста просторна стая, за да улесни комуникацията и да позволи групови дискусии при планиране и вземане на важни технически решения.
Промяна на правилата според нуждите (само правила)
Всеки член на екипа трябва да приеме изброените правила, но ако възникне необходимост, екипът може да ги промени, ако всички негови членове са съгласни с тази промяна.

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

XP като набор от описани техники беше използван за първи път по време на работата по проекта C3 (Chrysler Comprehensive Compensation System, разработване на система за отчитане на доходите на служителите в Daimler Chrysler). От 20-те участници в този проект, 5 (включително гореспоменатите 3 основни автора на XP) публикуваха 3 книги и огромен брой статии, посветени на XP по време на самия проект и впоследствие. Този проект многократно се споменава в различни източници като пример за използването на тази техника. Следните данни са събрани от споменатите статии, минус анекдотични доказателства, и илюстрират проблемите с някои XP техники, когато се прилагат към доста сложни проекти.

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

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

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

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

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

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

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

Среща прав

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

Простота

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

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

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

Клиент на работната площадка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

Фиг. 1

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

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

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

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

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

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

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

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

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

XP поставя особен акцент върху два вида тестване:

ь тестване на единици;

b тестване за приемане.

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

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

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

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

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

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

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

· Използване код как съоръжения комуникации

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