Източник на изображение: pixabay.com

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

Представете си това: Проект за разработка на софтуер за нов продукт, основан на предимството на първо място на пазара, току-що е забелязан на радара на вашата компания. Традиционните методи за екстремно програмиране, при които клиентът знае „точно“ какво искат, не съществуват. Екипът ви е малък и съставен от млади професионалисти, които вероятно ще реагират добре на радикален модел за управление на проекти. Какви са вашите възможности?

Вероятно ще кажете, Agile Project Management, разбира се! Но коя методология бихте искали да използвате? Има няколко варианта: за един, има изключително популярният Scrum: който включва създаване на кратки „спринти“ въз основа на изоставането от клиенти. И тогава има Kanban, който работи за оптимизиране на тръбопровода. Съществува и Extreme Programming, често съкратено до XP, което се фокусира върху усилването на положителните страни на традиционните модели на програмиране, така че да работят до максималния си потенциал.

Extreme Programming е изключително популярна (макар и не толкова популярна като Scrum) методология, фокусирана върху удовлетворяването на променящите се изисквания на клиента. Първият проект за екстремно програмиране е стартиран през март 1996 г. от Кент Бек от Chrysler. В книгата си от 1999 г., Обяснено с екстремно програмиране: Прегърни промяна, той подробно описа аспектите за разработка на софтуер.

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

Петте стойности на Extreme Programming, базирани на Explained са:

общуване

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

простота

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

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

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

Обратната връзка може да се предлага в различни вкусове:

  • От самата програма: Кодът се тества енергично през целия цикъл на разработване на проекта, така че промените да могат да бъдат внедрени от разработчиците.
  • От клиента: Това е съществена част от повечето Agile системи. Клиентите пишат тестове за приемане, на които се основава разработката, и това формира основата на процеса на разработка. Всички повторения също се доставят на клиента, за периодична обратна връзка.
  • От екипа: След като бъде създаден нов случай на употреба / история, екипът веднага се връща с оценка на разходите и времевата линия, засилвайки изискванията, когато възникнат. В екстремното програмиране никой не „притежава“ никакъв код и следователно в рамките на екипи за екстремно програмиране се насърчава обратна връзка относно кода на един друг.

Смелост

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

отношение

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

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

Екстремното програмиране отличава четири прости дейности на проекта. Те са:

  • Кодиране : Екстремното програмиране счита това за най-важната дейност. "Без код няма нищо", казва Кент Бек, основателят на Extreme Programming.
  • Тестване : Кодът е само това, освен ако не е тестван. Екстремното програмиране е натрапчиво по отношение на тестването, като се използват единични тестове, за да се потвърди, че кодът работи, и генерирани от клиента тестове за приемане, за да се потвърди, че кодът тества това, което трябва да бъде тествано.
  • Слушане: Слушането, пример за основната стойност на комуникацията, е дейност, която изисква от разработчиците не просто да чуват клиентите, а наистина да слушат това, което искат. Разработването и бизнесът са две различни неща и често разработчиците не разбират бизнес случая на конкретно решение. Потребностите на клиента, както и на разработчиците, са в основата на дейността „слушане“.
  • Проектиране : Може да ви изненада, че в един проект за разработка на софтуер, дизайнерската дейност, често толкова важна и основна, се поставя в края. Това е така, защото Extreme Programming умишлено иска да извади хората от „проектирането и разработването“ на мисленето, което индустрията поддържа в продължение на много години. Не е да се ограничи значението на проектирането. По-скоро добрият и минимален дизайн е едно от отличителните белези на един проект.

От ценностите и дейностите произлизат 12-те принципа на екстремното програмиране, както е разработено от неговия основател, в книгата си „Обяснено екстремно програмиране“.

  • Игра за планиране
  • Програмиране на двойки
  • Тестово управление
  • Целият екип
  • Непрекъсната интеграция
  • Подобряване на дизайна
  • Малки издания
  • Стандарти за кодиране
  • Собственост на колективен код
  • Прост дизайн
  • Система метафора
  • Устойчива крачка

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

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

Това е частта за планиране на проекта, наречена „Игра за планиране“. Тя включва планиране на следващата итерация и пускане, след консултация с потребителя / клиента, както и вътрешно планиране на екипите по отношение на задачите, по които ще работят.

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

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

  1. Тестово ориентирано развитие

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

  1. Подобряване на дизайна (рефакторинг)

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

  1. Прост дизайн

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

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

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

Роли в рамките на екстремен програмен проект:

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

Ролите за екстремно програмиране са:

  • Клиент : Разяснява се. Причината за проекта. Тя решава какво трябва да направи проекта. Тя предоставя потребителски истории.
  • Програмист : Това е човекът, който:
    • Взема историите, които клиентът измисля
    • Създава задачи за програмиране от истории
    • Реализира потребителските истории
    • Тества кода по единица
  • Треньор : Треньорът обикновено гарантира, че проектът е на път, а също и се намесва, за да помогне, когато е необходимо.
  • Tracker : Tracker отправя специфични запитвания към програмистите на зададен интервал. Обикновено той обикаля проверката на напредъка на програмистите, предлагайки помощ, където е необходимо, по няколко начина: запретване на ръкави и директно помощ с кода, уведомяване на треньора или определяне на среща с клиента, според нуждата.
  • Тестер : Изпълнява функционални тестове. Тестерът не изпълнява единични тестове, които се изпълняват от самите програмисти.
  • Съдър: Това, както подсказва името, е близко до Черната шапка в системата на груповото мислене на Едуард Де Боно. Всеки може да бъде Съдник, който обикновено маркира потенциални проблеми и помага да се поддържат проблеми в правилната перспектива.
  • Мениджър : Мениджърът в един проект за екстремно програмиране прилича повече на планировчик, като се гарантира, че срещите се случват по план и се гарантира, че решенията, взети по време на срещи, се предават на подходящия човек, по-често, отколкото не, на Tracker. Мениджърът обаче не казва на хората какво да правят и кога да го правят. Това се прави от Клиента и / или самите Истории на потребителите.
  • Собственик на злато : собственикът на злато е лицето, което финансира проекта. Това може да е клиента, но не е задължително.

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

Клиентът, например, не може да бъде и програмистът. Програмистът и следещият също не могат да бъдат едно и също лице.

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

Недостатъци на екстремното програмиране:

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

Някои от негативите на екстремното програмиране са:

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

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

Категория:

Развитие на предприемачеството