Екстремно програмирање
Замислите ово: Пројект развоја софтвера за нови производ, заснован на предности на тржишту, управо је примећен на радару ваше компаније. Традиционалне методе екстремног програмирања, где клијент зна „тачно“ шта жели, не постоје. Ваш тим је мален и састављен од младих професионалаца који ће вероватно добро реаговати на радикални модел управљања пројектима. Које су ваше могућности?
Вероватно ћете рећи, Агиле Пројецт Манагемент, наравно! Али коју методологију желите да користите? Постоји неколико опција: за једну, ту је изузетно популаран Сцрум: који укључује креирање кратких „спринтова“ на основу броја задатака клијента. А онда, ту је Канбан, који ради на оптимизацији цевовода. Постоји и Екстремно програмирање, често скраћено до КСП, које се фокусира на појачавање позитивних аспеката традиционалних програмских модела тако да раде на максималном потенцијалу.
Екстремно програмирање је изузетно популарна (иако не тако популарна као Сцрум) методологија усмерена на испуњавање променљивих захтева клијента. Први пројекат екстремног програмирања покренут је у марту 1996. године, Кент Бецк из Цхрислера. У својој књизи из 1999. године ( Ектреме Программинг Екплаинед: Ембраце Цханге) детаљно је описао аспекте развоја софтвера.
Кент Бецк је такође био пионир развоја вођеног тестом, који је тестирање примера на радару ставио као побољшање у односу на начин како се тада радило: писање линија и линија кода, а затим тестирање. Такође је био један од оригиналних потписника Магифеста Агиле, помажући обликовању манифестације да промени начин на који је написан екстремни програмски софтвер.
Пет вредности Екстремног програмирања заснованог на Објашњено су:
Комуникација
Екстремно програмирање не зависи од опсежне документације. У ствари, екстремна програмска документација се предлаже само кад је то потребно. Дакле, методологија се у великој мери ослања на комуникацију између чланова тима, а такође и са корисницима.
Једноставност
То је у сржи екстремног програмирања. Методологија фаворизира једноставне дизајне, не размишљајући предалеко у будућност, већ се фокусирајући на данашње потребе, а сам програм чини довољно робусним да дода захтјеве које будућност поставља.
Повратна информација
Ова суштинска петља која иде напред и назад разликује Агиле системе уопште и Екстремно програмирање, посебно, од осталих методологија управљања софтверским пројектима. Континуирана повратна информација може радити на различите начине, али сви раде на томе да систем постане јачи и поузданији.
Повратне информације могу бити у различитим укусима:
- Из самог програма: Код се интензивно тестира током читавог циклуса развоја пројекта, тако да програмери могу да примене промене.
- Од клијента: Ово је суштински део већине Агиле система. Клијенти пишу тестове прихватања на којима се заснива развој, а то чини окосницу развојног процеса. Све итерације се такође достављају клијенту, ради повременог повратног обавештења.
- Из тима: Једном када је створен нови случај / прича о употреби, тим се одмах враћа ценама и процени временске траке, појачавајући захтеве како настају. У екстремном програмирању нико не "посједује" било који код, и зато се у оквиру екстремних програмских тимова подстичу повратне информације о кодовима других.
Храброст
Ово би могло изгледати чудно у екстремном програмирању за развој софтвера, погодније за нешто попут војске или маринаца! Међутим, размислите о томе: Софтверски пројекти су одавно затрпани традиционалним екстремним програмским методама управљања; осигурајте у удобности опсежне документације и хијерархије која не омогућава иновације. Ова вредност представља језгро екстремног програмирања: будите спремни за скок, без падобрана ако дође до тога! Погледајте овај другачији стил управљања пројектима и будите спремни на одговорност, одрећи се хијерархије и бити одговорни и радити без да у почетку све знате.
Поштовање
Поштовање, пета вредност, додата је касније и значи поштовање других и себе. Такође подразумева поштовање писаног кода и очекивања и потребе клијента. Ова вредност лежи и у комуникацији између различитих актера.
Активности екстремног програмског пројекта
Екстремно програмирање разликује четири једноставне активности пројекта. Су:
- Кодирање : Екстремно програмирање сматра ово најважнијом активношћу. „Без кода нема ништа“, каже Кент Бецк, оснивач Ектреме Программинг-а.
- Тестирање : Код је само то ако није тестиран. Екстремно програмирање је опсесивно за тестирање, користећи јединице тестова да бисте потврдили да код ради и тестови прихваћања генерисани од стране клијента да потврде да код тестира шта треба тестирати.
- Слушање: Слушање, као пример основне вредности комуникације, је активност која захтева од програмера да не само чују клијенте, већ заиста слушају шта желе. Развој и посао су две различите ствари и често, програмери не разумеју пословни случај одређене одлуке. Потребе корисника, као и програмери, представљају основу активности „слушања“.
- Дизајнирање : Може вас изненадити да је у пројекту развоја софтвера активности дизајнирања, често толико важне и примарне, при крају. То је зато што Екстремно програмирање намерно жели људе избацити из „дизајнирања и развоја“ размишљања које индустрија негује више година. Не треба ограничити важност дизајна. Уместо тога, добар и минималан дизајн једно је од обележја пројекта.
Из вредности и активности произилази 12 принципа екстремног програмирања, које је осмислио његов оснивач, у својој књизи Објашњено екстремно програмирање.
- Игра планирања
- Парно програмирање
- Тест Дривен Девелопмент
- Цео тим
- Континуирано интеграција
- Побољшање дизајна
- Мала издања
- Стандарди кодирања
- Власништво над колективним кодом
- Једноставни дизајн
- Системска метафора
- Одржива темпа
Неколико ових екстремних програмских пракси, све мапиране на најбоље праксе софтверског инжењеринга, разликују се од генеричких Агиле методологија. Неке од пракси екстремног програмирања објашњене су у наставку:
-
Игра планирања
Ово је део планирања пројекта, назван „Игра планирања“. То укључује планирање следеће итерације и пуштања, уз консултације са корисником / клијентом, као и интерно планирање тимова, у вези са задацима на којима ће радити.
-
Парно програмирање
То укључује двоје људи који раде на комаду кода. Једна особа, звана тастатура, уноси код, док друга, која се зове монитор, надгледа је, коментаришући је и прочишћујући је, уколико се укаже потреба. Двоје људи често мењају улоге. Доказано је да значајно побољшава ефикасност кода. То можда није прикладно за све развојне сценарије, а то је нешто што треба размотрити пре пријаве за екстремно програмирање.
-
Тест усмерен на развој
Сав код који је написан прегледава се јединично, тј. Прво се тестира сваки део кода који може нешто учинити. Екстремно програмирање даје велики нагласак на тестирању. Ово помаже да се потврди да код функционише и да се након тога може сматрати укључивањем у сам програм екстремног програмирања. То је аналогно јединственим тестовима у школи: мали број информација које се тестирају, тако да наставник / студент може да изврши корекције курса и не лепрша током годишњих испита!
-
Побољшање дизајна (рефакторинг)
КСП пројекти, засновани на својој карактеристици једноставности, имају за циљ стално побољшавати код који је написан. То значи да се цео код (а понекад и база података) увек побољшава. Рефацторинг не додаје никакве функције; само побољшава постојећи код. Чини га чвршћим и јаснијим. Сродна је уређивању дела, полирању и побољшавању.
-
Једноставан дизајн
У екстремном програмирању функције се не додају док се то посебно не затражи. Чак и ако се код којим се тренутно ради врло је сличан ономе што би могло бити потребно у будућности, неће се узимати ако није договорено као корисничка прича.
-
Системска метафора
То укључује стандардизацију свих конвенција о именовању тако да се њихова сврха и функција лако дешифрују. На пример, или операције могу помоћи било којем програмеру да разуме њихову функцију. То би требало бити учињено током целог пројекта екстремног програмирања, тако да је било ко лако прегледати код и модификовати га или побољшати, овисно о случају.
Улоге у оквиру програма екстремног програмирања:
Као и Сцрум, Ектреме Программинг има неколико одређених улога у оквиру сваког пројекта. Сада улоге не морају увек да обављају различити људи, а човек може да преузме више од једне улоге.
Улоге за екстремно програмирање су:
- Купац : саморазјашњење. Разлог пројекта. Она одлучује шта пројекат треба да уради. Она пружа корисничке приче.
- Програмер : Ово је особа која:
- Узима приче које купац смисли
- Ствара задатке програмирања из прича
- Имплементира корисничке приче
- Тестира код по јединици
- Тренер : Тренер углавном осигурава да је пројекат у току и такође ускаче у помоћ када је то потребно.
- Трацкер : Трацкер врши одређене упите програмерима у задатом интервалу. Обично прегледава напредак програмера, нудећи помоћ тамо где је то потребно на неколико начина: завезивање рукава и директно помоћ код кода, обавештавање тренера или заказивање састанка са клијентом, према потреби.
- Тестер : ради функционалне тестове. Тестер не изводи јединице тестова, које покрећу сами програмери.
- Доомсаиер: Ово, као што име сугерира, сродно је Црном шеширу у систему групног размишљања Едварда Де Бона-а. Свако би могао бити Доомсаиер, који обично означава потенцијалне проблеме и помаже одржавању проблема у исправној перспективи.
- Менаџер : Менаџер у пројекту екстремног програмирања више личи на распоред времена, осигуравајући да се састанци одвијају како су планирани и осигуравајући да се одлуке донете током састанака преносе одговарајућој особи, чешће него не, Трагачу. Менаџер, међутим, не говори људима шта да раде и када то треба урадити. То ради Купац и / или Корисничке приче.
- Власник злата: Власник злата је особа која финансира пројекат. То би могао бити купац, али није нужно и тако.
Неке од екстремних програмских улога, како је описано горе, могу се комбиновати, али неке очигледно не могу.
На пример, купац такође не може бити програмер. Програмер и Трагач, слично, не могу успешно бити иста особа.
Екстремне програмске улоге дефинисане су довољно јасно да не долази до забуне и створене за максималну флексибилност и ефикасност.
Недостаци екстремног програмирања:
Док заговорници Екстремног програмирања сликају ружичасту слику, чињеница је да је Екстремно програмирање, као што назив вероватно сугерира, изузетно тешко имплементирати. Фазе екстремног програмирања могу се успешно укључити у пројекте него што је потпуно усвајање КСП-а.
Неки од негативних ефеката екстремног програмирања су:
- Екстремно програмирање је ефикасније у мањим групама . Њена ефикасност у већим групама је оспоравана, а боља опција је поделити екстремне програмске тимове тако да групе буду мање.
- Једна од кључних карактеристика екстремног програмирања, програмирање у паровима не функционише добро у многим случајевима . За сложено кодирање могу бити потребне две главе, али не морају сви људи захтевати две особе, при чему је друга особа мртва тежина. У ствари, програмирање у паровима, ако један од чланова није у синхронизацији са другим, један је од главних разлога зашто Екстремно програмирање у многим случајевима не успе.
- Зависност о купцу, до тачке сугерисања ресурса на лицу места са стране клијента, може бити дубоко узнемирујућа. Такође може довести до сметњи, стварних и замишљених током развоја.
- Усредсређеност екстремног програмирања на једноставност може отежати додавање тренутном пројекту, што значи већи буџет за чак и једноставне промене, које више не остају једноставне.
- Равна хијерархијска структура значи да тим увек треба да буде фокусиран, а у недостатку руководиоца за разне врсте људи, тим за екстремно програмирање у потпуности зависи од емоционалне зрелости свих чланова тима, фактора који није увек поуздан. .
Чак и уз ове факторе, Екстремно програмирање остаје моћно средство за коришћење правог пројекта, при чему компаније пријављују о повећаној ефикасности након усвајања екстремног процеса програмирања. Систем заснован на развојним програмерима, за разлику од Сцрум-а, који је више процесни систем, екстремно програмирање или барем делови система, могу довести до револуције у начину на који развијамо екстремни софтверски софтвер.