mitä on Extreme-ohjelmointi? Katsaus XP: n sääntöihin ja arvoihin

jo 1990-luvulla Internetin nousu edellytti ohjelmistokehityksen muutosta. Jos yrityksen menestys riippui nopeus, jolla yhtiö voisi kasvaa ja tuoda tuotteita markkinoille, yrityksiä tarvitaan dramaattisesti vähentää ohjelmiston kehityksen elinkaaren aikana.,

– Se oli tässä ympäristössä, että Kent Beck loi extreme programming (XP), ketterä projektinhallinta menetelmää, joka tukee usein tiedotteet lyhyesti kehitysvaiheet parantaa ohjelmiston laatua ja salli kehittäjät voivat vastata asiakkaiden muuttuviin vaatimuksiin.

vaikka saatat tunnistaa joitakin näistä käytännöistä ja arvoista muista projektinhallintamenetelmistä, XP vie nämä käytännöt ”äärimmäisille” tasoille, kuten menetelmän nimi antaa ymmärtää., Haastattelussa Informit, Kent kertoo:

”ensimmäistä kertaa olin pyytänyt johtaa joukkue, pyysin heitä tekemään vähän asioita, joita ajattelin, olivat järkeviä, kuten testausta ja arvostelua. Toisella kerralla oli paljon enemmän pelissä. Kysyin joukkue vääntää kaikki nupit 10 asioita, joita ajattelin, olivat välttämättömiä, ja jättää kaikki muu pois.”

Jos sinä ja tiimisi täytyy päästä nopeasti ja reagoida asiakkaan pyyntöihin, katsomaan arvot ja säännöt äärimmäinen ohjelmointi—se voisi olla täydellinen istuvuus.,

Arvot extreme programming-metodologian

XP on enemmän kuin vain sarja vaiheita, hallita projekteja—tästä seuraa joukko arvoja, jotka auttavat joukkue työskennellä nopeammin ja tehdä yhteistyötä entistä tehokkaammin.

Yksinkertaisuus

Joukkueet suorittaa sen, mitä on pyydetty ja mitään muuta. XP hajottaa jokaisen vaiheen suuren prosessin pienemmiksi, saavutettavissa tavoitteiksi tiimin jäsenille saavuttaa.,

Virtaviivainen viestintä

Joukkueet toimivat yhdessä jokaiselle osa hanketta, kerääminen vaatimusten täytäntöönpanoa koodi ja osallistua daily stand-up kokoukset pitää kaikki tiimin jäsenet ajan tasalla. Kaikkiin huolenaiheisiin tai ongelmiin puututaan välittömästi.

johdonmukainen, rakentava palaute

XP: ssä tiimit sopeuttavat prosessinsa projektiin ja asiakkaiden tarpeisiin, ei toisin päin. Joukkue olisi osoitettava ohjelmistoa aikaisin ja usein, jotta he voivat kerätä palautetta asiakkaalta ja tehdä tarvittavat muutokset.,

Respect

Extreme-ohjelmointi kannustaa ”all for one and one for all” – mentaliteettiin. Jokaista joukkueessa olevaa henkilöä kunnioitetaan hierarkiasta riippumatta heidän panoksistaan. Tiimi kunnioittaa asiakkaiden mielipiteitä ja päinvastoin.

rohkeus

tiimin jäsenet sopeutuvat muutoksiin noustessaan ja ottavat vastuun työstään. He kertovat totuuden edistymisestään—ei ole olemassa ”valkoisia valheita” tai tekosyitä sille, että ihmiset eivät tuntisi oloaan paremmaksi. Ei ole syytä pelätä, koska kukaan ei koskaan työskentele yksin.,

Säännöt ja extreme programming-metodologian

Don Wells julkaisi ensimmäisen XP säännöt vuonna 1999 laskuri väittää, että äärimmäinen ohjelmointi ei tue toimintoja, jotka ovat tarpeen, ohjelmistojen kehittäminen, kuten suunnittelu, hallinta ja suunnittelu. Suunnittelusta ohjelmiston testaamiseen, noudata näitä perusvaiheita kunkin iteraation.

Suunnittelu

Tässä vaiheessa on missä UX taika tapahtuu., Sen sijaan pitkän vaatimukset asiakirja, asiakas kirjoittaa käyttäjätarinoita, jotka määrittävät toiminnot asiakas haluaisi nähdä, yhdessä liiketoiminta-arvoa ja prioriteetti kunkin näistä ominaisuuksista. Käyttäjien tarinoiden ei tarvitse olla tyhjentäviä tai liian teknisiä—niiden tarvitsee vain antaa tarpeeksi yksityiskohtia auttaakseen tiimiä määrittämään, kuinka kauan näiden ominaisuuksien toteuttaminen kestää.

Kanssa Lucidchart, asiakkaat voivat luoda perus vuokaavio ja helposti tallentaa ja jakaa halutun toiminnallisuuden.,

– sieltä, joukkue luo julkaisuaikataulu ja jakaa projektin toistojen (yksi-kolme viikkoa pitkä). Projektipäälliköt saattavat haluta luoda aikajanan tai yksinkertaistetun Gantt-kaavion, jotta aikataulu voidaan jakaa tiimin kanssa.

Hallinta

tässä vaiheessa, projektipäällikkö asettaa joukkueen menestyä tämän menetelmän. Kaikkien on tehtävä yhteistyötä ja kommunikoitava tehokkaasti, jotta vältyttäisiin lipsahduksilta. Tähän vaiheeseen kuuluu:

• avoimen työtilan luominen tiimillesi
• kestävän tahdin asettaminen (ts., määritetään oikea pituus toistojen)
• Aikataulutus päivittäin standup kokous
• Mittaaminen-hanke (velocity määrä työtä saada tehdä oman projekti)
• Siirtämisellä työn välttää pullonkauloja tai tiedon menetys
• Muuttaa sääntöjä, jos XP ei toimi täydellisesti joukkue

Suunnittelu

Tämä sääntö juontaa juurensa arvo yksinkertaisuus: Aloita yksinkertaisin suunnittelu, koska se vie vähemmän aikaa kuin monimutkainen ratkaisu. Älä lisää toimintoja aikaisin. Refactor usein pitää koodin puhtaana ja ytimekäs., Luo spike ratkaisuja tutkia ratkaisuja mahdollisiin ongelmiin ennen kuin he laittavat tiimisi taakse.

Kent Beck ja Ward Cunningham loivat myös class-responsibility-collaboration (CRC) – kortteja käytettäväksi osana XP-metodologiaa. Näiden korttien avulla koko projektitiimi voi suunnitella järjestelmän ja nähdä, miten esineet ovat vuorovaikutuksessa keskenään. Jos haluat kokeilla tätä aivoriihi työkalu itsellesi, aloita meidän selväjärkinen malli.,

Koodaus

Sitten tulee aika toteuttaa koodia. XP: n käytännöt, kollektiivinen koodin omistaminen: Kaikki arviot koodi ja tahansa kehittäjä voi lisätä toimintoja, korjata vikoja, tai refactor. Jotta kollektiivinen koodien omistus toimisi, ryhmän tulisi:

• valita järjestelmämetafora (standardoitu nimeämisjärjestelmä).
• harjoittele pariohjelmointia., Tiimin jäsenet työskentelevät pareittain, yhdellä tietokoneella, luodakseen koodin ja lähettääkseen sen tuotantoon. Vain yksi pari yhdistää koodin kerrallaan.
• integroi ja toimita koodi arkistoon muutaman tunnin välein.

asiakkaan tulee olla saatavilla, mieluiten paikan päällä, tänä koko prosessi, jotta he voivat vastata kysymyksiin ja vahvistaa vaatimukset.

testaus

tiimi tekee yksikkötestejä ja korjaa vikoja ennen koodin julkaisua. He myös tekevät hyväksymistestejä usein.,

milloin extreme-ohjelmointia

on vielä epävarma, sopiiko XP joukkueesi tarpeisiin, vaikka sen säännöt ja arvot olisi luettu? Extreme-ohjelmointi voi toimia hyvin tiimeissä, jotka:

• odottavat järjestelmänsä toimivuuden muuttuvan muutaman kuukauden välein.
• Koe jatkuvasti muuttuvia vaatimuksia tai työskentele sellaisten asiakkaiden kanssa, jotka eivät ole varmoja, mitä he haluavat järjestelmän tekevän.
• haluaa lieventää projektiriskiä etenkin tiukkojen määräaikojen tienoilla.
• sisältää pienen määrän ohjelmoijia (2-12 on parempi).
• pystyvät tekemään tiivistä yhteistyötä asiakkaiden kanssa.,
• pystyy luomaan automatisoituja yksikkö-ja toiminnallisia testejä.

jos yhteistyö ja jatkuva kehittäminen ovat tiimisi painopisteitä, extreme-ohjelmointia kannattaa kokeilla. Koska tämä erittäin joustava malli vaatii jatkuvaa palautetta asiakkailta, ennakoi virheitä matkan varrella, ja vaatii kehittäjät työskentelevät yhdessä, XP ei vain varmistaa terveyden tuote julkaisu, mutta on myös tahattomasti tuottavuuden kehitys joukkueet kaikkialla.,

Jos päätät käyttää XP, kokeile dokumentointi käyttäjän tarinoita, julkaisuaikatauluista, CRC-kortteja, ja järjestelmän dokumentointi visuaalisesti Lucidchart. Rekisteröidy ilmaiseksi tilisi tänään.

---