Mitä on Extreme-ohjelmointi?

Suunnittelu Peli

XP suunnittelu-osoitteet kaksi avain kysymyksiä software development: ennustaa, mitä tulee olla suoritettu eräpäivään mennessä, ja määritellään, mitä tehdä seuraavaksi. Pääpaino on ohjauksen – hanke, joka on varsin yksinkertainen – sen sijaan, tarkka ennustus siitä, mitä tarvitaan ja kuinka kauan se kestää – mikä on varsin vaikeaa., On olemassa kaksi keskeistä suunnittelun vaiheet XP, käsitellään nämä kaksi kysymystä:

Vapauta Suunnittelu on käytäntö, jossa Asiakas esittelee halutut ominaisuudet ohjelmoijia, ja ohjelmoijat arvioida niiden vaikeusaste. Kustannusarvioiden ollessa käsillä ja ominaisuuksien merkityksen tuntien asiakas laatii hankkeelle suunnitelman. Alustavat julkaisusuunnitelmat ovat välttämättä epätarkkoja: prioriteetit tai arviot eivät ole todella vankkoja, ja ennen kuin tiimi alkaa toimia, emme tiedä, kuinka nopeasti ne menevät., Jopa ensimmäinen julkaisusuunnitelma on riittävän tarkka päätöksentekoon, mutta XP-tiimit tarkistavat julkaisusuunnitelmaa säännöllisesti.

Iteraatiosuunnittelu on käytäntö, jossa joukkueelle annetaan suuntaa parin viikon välein. XP tiimit rakentaa ohjelmiston kahden viikon ”iterations”, tuottaa käynnissä hyödyllisiä ohjelmistoja lopussa kunkin iteraation. Iteroinnin suunnittelun aikana asiakas esittelee haluamiaan ominaisuuksia seuraavan kahden viikon ajan. Ohjelmoijat pilkkovat ne tehtäviksi ja arvioivat niiden kustannukset (tarkemmin kuin Julkaisusuunnittelussa)., Perustuu määrä työtä, joka on tehty aiemman iteraation, joukkue merkkejä, mitä toteutetaan nykyisen iteraation.

Nämä suunnittelun vaiheet ovat hyvin yksinkertaisia, mutta ne antavat erittäin hyvää tietoa ja erinomainen ohjaus käsissä Asiakas. Parin viikon välein edistyksen määrä näkyy täysin. XP: ssä ei ole ”yhdeksänkymmentä prosenttia tehtyä”: piirroskertomus valmistui tai sitten ei., Tämä keskittyminen näkyvyys tuloksia on mukava pieni paradoksi: toisaalta, niin paljon näkyvyyttä, Asiakas voi peruuttaa hankkeen, jos edistyminen ei ole riittävää. Toisaalta edistystä on siis nähtävissä, ja kyky päättää, mitä tehdään seuraavaksi on niin täydellinen, että XP-projekteissa on tapana antaa enemmän ja mitä tarvitaan vähemmän painetta ja stressiä.

Asiakas Testit

osana esittelee kunkin haluttu ominaisuus, XP Asiakas määrittelee yhden tai useamman automatisoidut acceptance testit osoittavat, että ominaisuus toimii., Joukkue rakentaa nämä testit ja käyttää niitä todistaa itselleen ja asiakkaalle, että ominaisuus on toteutettu oikein. Automaatio on tärkeää, koska ajan puristuksessa manuaaliset testit jätetään väliin. Se on kuin sammuttaisi valot, kun yö pimenee.

paras XP joukkueet kohtelevat asiakasta testit samalla tavalla he tekevät ohjelmoija testit: kun testi loppuu, joukkue pitää sen käynnissä oikein sen jälkeen. Tämä tarkoittaa, että järjestelmä vain paranee, aina notching eteenpäin, koskaan luopuminen.,

Pieni Julkaisut

XP joukkueet käytännössä pieni tiedotteet kahdella tärkeällä tavalla:

Ensimmäinen joukkue tiedotteet käynnissä, testattu ohjelmisto, tuottaa liiketoiminta-arvoa, jonka Asiakas valitsee jokaisen iteraation. Asiakas voi käyttää tätä ohjelmistoa mihin tahansa tarkoitukseen, joko arviointi-tai jopa vapauttaa loppukäyttäjille (erittäin suositeltavaa). Tärkeintä on, että ohjelmisto näkyy ja annetaan asiakkaalle jokaisen iteraation lopussa. Tämä pitää kaiken avoimena ja konkreettisena.

toiseksi, XP-joukkueet julkaisevat loppukäyttäjilleen usein myös., XP Web-projektit julkaisevat niin usein kuin päivittäin, house-projekteissa kuukausittain tai useammin. Jopa kutistepäällysteiset tuotteet toimitetaan yhtä usein kuin neljännesvuosittain.

voi tuntua mahdottomalta luoda hyviä versioita näin usein, mutta XP-joukkueet kaikkialla tekevät sitä koko ajan. Katso Jatkuva Integraatio lisää tästä, ja huomaa, että usein nämä julkaisut ovat pidetään luotettava XP on pakkomielle testaus, tässä kuvatulla tavalla Asiakkaan Testeistä ja Test-Driven Kehitystä.

Simple Design

XP-tiimit rakentavat ohjelmiston yksinkertaiseen, mutta aina riittävään suunnitteluun., Ne alkavat yksinkertainen, ja kautta ohjelmoija testaus ja suunnittelun parantaminen, he pitävät sen niin. XP-tiimi pitää suunnittelun juuri sopivana järjestelmän nykyiseen toiminnallisuuteen. Turhaa liikettä ei ole, ja ohjelmisto on aina valmis seuraavaan.

design XP: ssä ei ole mikään kertaluonteinen asia, tai etujuttu, se on kaikkien aikojen juttu. On olemassa suunnittelun vaiheet julkaisun suunnittelun ja toteutuksen suunnittelua, ja joukkueet harjoittaa nopea suunnittelu istuntoja ja suunnitella korjausten kautta refaktorointi, läpi kurssin koko hankkeen., Inkrementaalisessa, iteratiivisessa prosessissa, kuten Extreme-ohjelmoinnissa, hyvä muotoilu on olennaista. Siksi muotoiluun panostetaan niin paljon koko kehityksen ajan.

Pariohjelmointi

Kaikki XP: n tuotanto-ohjelmisto on kahden ohjelmoijan rakentama, vierekkäin istuva, samalla koneella. Tämä käytäntö varmistaa, että kaikki tuotantokoodi tarkistetaan vähintään yksi muu ohjelmoija, ja johtaa parempaan suunnitteluun, parempaan testaukseen ja parempaan koodiin.

saattaa tuntua tehottomalta, että kaksi ohjelmoijaa tekee ”yhden ohjelmoijan työtä”, mutta päinvastainen on totta., Pariohjelmoinnin tutkimus osoittaa, että parinmuodostus tuottaa parempaa koodia suunnilleen samaan aikaan kuin ohjelmoijat, jotka työskentelevät yksin. Aivan oikein: kaksi päätä todella on parempi kuin yksi!

jotkut ohjelmoijat vastustavat ohjelmoinnin parittamista kokeilematta sitä koskaan. Se kestää jonkin käytännössä tehdä hyvin, ja sinun täytyy tehdä se hyvin muutaman viikon nähdä tuloksia. Yhdeksänkymmentä prosenttia ohjelmoijista, jotka oppivat pariohjelmoinnin, suosivat sitä, joten suosittelemme sitä kaikille tiimeille.

pariliitoksen lisäksi paremman koodin ja testien tarjoaminen palvelee myös tiedon välittämistä koko tiimissä., Parikytkentänä jokainen saa kaikkien erikoistiedon edut. Ohjelmoijat oppivat, heidän taitonsa paranevat, heistä tulee arvokkaampia tiimille ja yritykselle. Parivaljakko, jopa yksinään XP: n ulkopuolella, on iso voitto kaikille.

Testivetoinen kehitys

Extreme-ohjelmointi on palautteen pakkomielle, ja ohjelmistokehityksessä hyvä palaute vaatii hyvää testausta. Top XP-tiimit harjoittelevat ”testivetoista kehitystä”, työskentelevät hyvin lyhyissä jaksoissa lisäämällä testin, jolloin se toimii., Lähes vaivattomasti joukkueet tuottavat koodia lähes 100 prosentin testikattavuudella, mikä on suuri edistysaskel useimmissa kaupoissa. (Jos ohjelmoijasi tekevät jo entistäkin hienostuneempaa testausta, lisää tehoa sinulle. Jatka samaan malliin, se voi vain auttaa!)

se ei riitä testien kirjoittamiseen: ne pitää suorittaa. Tässäkin Äärimmäinen ohjelmointi on äärimmäistä. Nämä ”ohjelmoija testit”, tai ”yksikkö testit” ovat kaikki kerätty yhteen, ja joka kerta, kaikki ohjelmoija vapauttaa koodia arkistoon (ja paria tyypillisesti release kahdesti päivässä tai enemmän), jokainen ohjelmoija testit on suoritettava oikein., Sataprosenttisesti koko ajan! Tämä tarkoittaa sitä, että ohjelmoijat saavat välitöntä palautetta siitä, miten he pärjäävät. Lisäksi nämä testit tarjoavat korvaamatonta tukea, kun ohjelmistosuunnittelua parannetaan.

Suunnittelu Parannus (Refaktorointi)

Extreme Ohjelmointi keskittyy tuottamaan liiketoiminnan arvo jokaisen iteraation. Tämän saavuttamiseksi koko projektin aikana ohjelmiston on oltava hyvin suunniteltu. Vaihtoehtona olisi hidastaa vauhtia ja lopulta jäädä jumiin., Joten XP käyttää prosessin jatkuvan suunnittelun parantamista kutsutaan Refaktorointi, otsikko Martin Fowlerin kirja, ”Refaktorointi: Parantaminen Suunnittelu Olemassa olevaa Koodia”.

refaktorointi prosessi keskittyy poistamalla päällekkäisyyksiä (varma merkki huono suunnittelu), ja lisää ”yhteenkuuluvuutta” koodia, ja samalla vähentää ”kytkentä”. Korkea koheesio ja matala kytkentä on tunnustettu hyvin suunnitellun koodin tunnusmerkiksi ainakin kolmenkymmenen vuoden ajan. Tuloksena on, että XP-tiimit aloittavat hyvällä, yksinkertaisella muotoilulla, ja niillä on aina hyvä, yksinkertainen muotoilu ohjelmistolle., Näin ne voivat ylläpitää kehitysvauhtiaan ja itse asiassa yleensä lisätä nopeutta hankkeen edetessä.

Refaktorointi on, tietenkin, tukevat vahvasti kattava testaus varmistaa, että suunnittelu kehittyy, mikään ei ole rikki. Näin ollen asiakastestit ja ohjelmointitestit ovat kriittinen mahdollistava tekijä. XP-käytännöt tukevat toisiaan: ne ovat vahvempia yhdessä kuin erikseen.

Jatkuva Integraatio

Extreme Ohjelmointi joukkuetta pitää järjestelmän täysin integroitu kaikkina aikoina. Sanomme, että päivittäinen rakentaa ovat wimps: XP joukkueet rakentaa useita kertoja päivässä., (Yksi XP joukkue neljäkymmentä ihmistä rakentaa vähintään kahdeksan tai kymmenen kertaa päivässä!)

hyöty tämän käytännön voidaan nähdä ajattelu takaisin hankkeet olet ehkä kuullut (tai edes osa), jossa rakentaa prosessi oli viikoittain tai harvemmin, ja yleensä johti ”integraatio helvetti”, jossa kaikki rikki ja kukaan ei tiennyt miksi.

harvoin tapahtuva integraatio johtaa vakaviin ongelmiin ohjelmistoprojektissa., Ensinnäkin, vaikka integraatio on kriittinen toimitus hyvä toimiva koodi, joukkue ei ole harjoitellut sitä, ja usein se on delegoitu ihmiset, jotka eivät tunne koko järjestelmää. Toiseksi, harvoin integroitu koodi on usein – sanoisin yleensä-buginen koodi. Integraatiohetkellä on ongelmia, joita ei havaita yhdessäkään integroimattomassa järjestelmässä suoritetussa testauksessa. Kolmanneksi heikko integraatioprosessi johtaa pitkiin koodijäädytyksiin., Koodi jäätyy tarkoittaa, että sinulla on pitkiä aikoja, jolloin ohjelmoijat voivat työskennellä tärkeitä shippable ominaisuuksia, mutta että nämä ominaisuudet on pidätellä. Tämä heikentää asemaasi markkinoilla tai loppukäyttäjien kanssa.

kollektiivinen koodin omistus

äärimmäisessä Ohjelmointiprojektissa mikä tahansa ohjelmoijapari voi parantaa mitä tahansa koodia milloin tahansa. Tämä tarkoittaa, että kaikki koodi saa hyötyä monien ihmisten huomiota, mikä lisää koodin laatua ja vähentää vikoja., On toinenkin tärkeä etu: kun koodi on yksityishenkilöiden omistuksessa, vaaditut ominaisuudet laitetaan usein väärään paikkaan, kun yksi ohjelmoija huomaa tarvitsevansa ominaisuuden jossain koodissa, jota hän ei omista. Omistaja ei ehdi tehdä sitä, joten ohjelmoija laittaa ominaisuuden omaan koodiinsa, jonne se ei kuulu. Tämä johtaa ruma, vaikeasti ylläpidettävä koodi, täynnä päällekkäisyyttä ja alhainen (huono) yhteenkuuluvuus.

Kollektiivinen omistus voi olla ongelma, jos ihmiset toimi sokeasti koodi he eivät ymmärrä., XP välttää nämä ongelmat läpi kaksi avain tekniikoita: ohjelmoija testit saalis virheitä, ja pari ohjelmointi tarkoittaa, että paras tapa työskennellä tuntemattomia koodi on parin asiantuntijan kanssa. Sen lisäksi, että tämä käytäntö takaa tarvittaessa hyviä muutoksia, se levittää tietoa koko joukkueeseen.

Koodausstandardi

XP – joukkueet noudattavat yhteistä koodausstandardia, joten kaikki järjestelmän koodi näyttää siltä kuin se olisi yhden – erittäin pätevän-henkilön kirjoittama., Standardin erityispiirteet eivät ole tärkeitä: tärkeintä on, että kaikki koodi näyttää tutulta, kollektiivisen omistuksen tueksi.

Metafora

Extreme Ohjelmointi joukkuetta kehittää yhteinen visio siitä, miten ohjelma toimii, jota kutsumme ”metafora”. Parhaimmillaan metafora on yksinkertainen mielikuvia herättävä kuvaus siitä, miten ohjelma toimii, kuten ”tämä ohjelma toimii kuin pesää mehiläisiä, menee ulos siitepölyä ja tuo sen takaisin pesään”, kuten kuvaus agentti perustuva tiedonhakujärjestelmä.

joskus ei synny riittävän runollista metaforaa., Joka tapauksessa, tai ilman vivid kuvastoa, XP joukkueet käyttävät yhteistä järjestelmää nimiä, voit olla varma, että jokainen ymmärtää, miten järjestelmä toimii ja mistä etsiä löytää toiminnallisuus etsit, tai voit löytää oikea paikka laittaa toiminnallisuutta olet aikeissa lisätä.

Sustainable Pace

Extreme-Ohjelmatiimit ovat siinä mukana pitkällä tähtäimellä. He tekevät kovasti työtä ja sellaista tahtia, jota voidaan jatkaa loputtomiin. Tämä tarkoittaa sitä, että he tekevät ylitöitä, kun se on tehokasta, ja että he yleensä työskentelevät siten, että maksimoidaan tuottavuus viikko ja viikko pois., Se on melko hyvin ymmärretty näinä päivinä, että kuolema maaliskuussa hankkeet eivät ole tuottavia eikä tuottaa laadukkaita ohjelmistoja. XP-joukkueet ovat siinä voittamassa, eivät kuolemassa.

Conclusion

Extreme Programming on ohjelmistokehityksen tieteenala, joka perustuu yksinkertaisuuden, viestinnän, palautteen ja rohkeuden arvoihin. Se toimii tuomalla koko tiimin yhteen läsnäollessa yksinkertaisia käytäntöjä, tarpeeksi palautetta, jotta joukkue nähdä, missä he ovat ja virittää käytäntöjä niiden ainutlaatuinen tilanne.