Koti-Selaimet-Extreme Programming (XP) ei ole heikkohermoisille. XP perustuu tiiviiseen yhteistyöhön ohjelmoijien kanssa, joilla on yleisimmät taidot ja kyvyt.

Extreme Programming (XP) ei ole heikkohermoisille. XP perustuu tiiviiseen yhteistyöhön ohjelmoijien kanssa, joilla on yleisimmät taidot ja kyvyt.

Äärimmäinen ohjelmointi: Testilähtöinen kehitys

Omistettu Cindylle: sieluni siivet

Julkaisuoikeudet hankittu sopimuksella Addison-Wesley Longmanin kanssa. Kaikki oikeudet pidätetään. Mitään tämän kirjan osaa ei saa jäljentää missään muodossa ilman tekijänoikeuksien haltijoiden kirjallista lupaa.


Tämän kirjan sisältämät tiedot on saatu lähteistä, jotka kustantaja uskoo luotettaviksi. Mahdollisten inhimillisten tai teknisten virheiden vuoksi kustantaja ei kuitenkaan voi taata antamiensa tietojen ehdotonta tarkkuutta ja täydellisyyttä eikä ole vastuussa mahdollisista kirjan käyttöön liittyvistä virheistä.


ISBN 978-0321146533

ISBN 978-5-496-02570-6


© 2003, Pearson Education, Inc.

© Käännös venäjäksi LLC Kustantaja "Peter", 2017

© Painos venäjäksi, suunnitellut Piter Publishing House LLC, 2017

© Ohjelmoijan kirjasto -sarja, 2017

Esipuhe

Puhdas koodi, joka toimii(puhdas koodi, joka toimii), - tässä lyhyessä mutta merkityksellisessä lauseessa, jonka Ron Jeffries loi, piilee koko Test-Driven Developmentin (TDD) pointti. Puhdas toimiva koodi on tavoite, johon kannattaa pyrkiä, koska

Tämä on ennakoitava tapa kehittää ohjelmia. Tiedät, milloin työ voidaan katsoa valmiiksi, etkä ole huolissasi pitkästä virhejonosta;

Antaa mahdollisuuden oppia koodin opettamat opetukset. Jos käytät ensimmäistä mieleen tulevaa ideaa, sinulla ei ole mahdollisuutta toteuttaa toista, parempaa ideaa;

Parantaa ohjelmiesi käyttäjien elämää;

Antaa kollegoidesi luottaa sinuun ja sinun heihin;

Sellaisen koodin kirjoittaminen on mukavampaa.

Mutta kuinka saada puhdas koodi, joka toimii? Monet voimat estävät meitä saamasta puhdasta koodia, ja joskus emme voi edes saada koodia, joka vain toimii. Päästäksemme eroon monista ongelmista, kehitämme automaattiseen testaukseen perustuvaa koodia. Tätä ohjelmointityyliä kutsutaan testiohjautuvaksi kehitykseksi. Tämän metodologian mukaan

Uusi koodi kirjoitetaan vasta sen jälkeen, kun on kirjoitettu automaattinen testi, joka epäonnistuu;

Kaikki päällekkäisyydet poistetaan.

Kaksi yksinkertaista sääntöä, eikö niin? Ne luovat kuitenkin monimutkaisia ​​yksilö- ja ryhmäkäyttäytymiä, joilla on monia teknisiä seurauksia:

Suunnitteluprosessin aikana käytämme jatkuvasti koodia ja saamme käsityksen siitä, miten se toimii, mikä auttaa tekemään oikeita päätöksiä;

Kirjoitamme testejä itse, koska emme malta odottaa, että joku muu kirjoittaa testejä puolestamme;

Kehitysympäristömme on reagoitava nopeasti pieniin koodin muutoksiin;

Ohjelman suunnittelun tulisi perustua useiden erillisten, löyhästi kytkettyjen komponenttien käyttöön koodin testaamisen helpottamiseksi.

Mainitut kaksi TDD-sääntöä määrittävät ohjelmointivaiheiden järjestyksen.

1. Punainen - kirjoita pieni testi, joka ei toimi tai ehkä ei edes käännä.

2. Vihreä - suorita testi mahdollisimman nopeasti ajattelematta koodin suunnittelua ja puhtautta. Kirjoita vain tarpeeksi koodia, jotta testi toimii.

3. Refaktorointi - poista kaikki kopiot kirjoitetusta koodista.

Red-Green-Refactoring on TDD-mantra.

Olettaen, että tämä ohjelmointityyli on mahdollista, voidaan olettaa, että sen käytön ansiosta koodissa tulee olemaan huomattavasti vähemmän vikoja, lisäksi työn tarkoitus on selvä kaikille siihen osallistuville. Jos näin on, niin vain testien läpäisemiseen tarvittavan koodin kehittämisellä on myös sosiaalisia seurauksia:

Riittävän alhaisella vikatiheydellä Quality Assurance (QA) -tiimi pystyy siirtymään virheisiin vastaamisesta niiden estämiseen;

Vähemmän ikäviä yllätyksiä projektipäälliköt voivat arvioida tarkemmin työvoimakustannukset ja ottaa asiakkaat mukaan kehitysprosessiin;

Jos teknisten keskustelujen aiheet on määritelty selkeästi, ohjelmoijat voivat olla vuorovaikutuksessa toistensa kanssa jatkuvasti, eivät kerran päivässä tai kerran viikossa;

Jälleen kerran riittävän pienellä vikatiheydellä saamme joka päivä integroidun työtuotteen, johon on lisätty uutta toiminnallisuutta, jotta voimme solmia täysin uudenlaisen liikesuhteen asiakkaidemme kanssa.

Idea on siis yksinkertainen, mutta mikä on meidän etumme? Miksi ohjelmoijan pitäisi ottaa lisävastuu automaattisten testien kirjoittamisesta? Miksi ohjelmoijan pitäisi edetä pienin askelin, kun hänen aivonsa voivat ajatella paljon monimutkaisempaa suunnittelurakennetta? Urhoollisuus.

Urhoollisuus

TDD on tapa hallita pelkoa ohjelmoinnin aikana. En tarkoita pelkoa tuoliltasi putoamisesta tai pomosi pelkoa. Tarkoitan pelkoa tehtävästä "niin vaikeasta, että minulla ei ole vielä aavistustakaan, kuinka se ratkaistaan". Kipu on sitä, kun luonto sanoo: "Stop!", ja pelko on sitä, kun luonto sanoo: "Ole varovainen!" Varovaisuus ei ole ollenkaan pahasta, mutta etujen lisäksi pelolla on meihin negatiivinen vaikutus:

Pelko pakottaa meidät ajattelemaan etukäteen ja huolellisesti, mihin tämä tai tuo toiminta voi johtaa;

Pelko saa meidät kommunikoimaan vähemmän;

Pelko saa meidät pelkäämään palautetta työstämme;

Pelko tekee meistä ärtyneitä.

Mikään näistä ei ole hyödyllinen ohjelmointiprosessissa, varsinkin jos työskentelet monimutkaisen ongelman parissa. Joten kohtaamme kysymyksen, kuinka päästä ulos vaikeasta tilanteesta ja

Älä yritä ennustaa tulevaisuutta, vaan aloita heti ongelman käytännön tutkimus;

Ei eristäytyä muulta maailmalta, vaan lisätä viestintätasoa;

Ei välttää palautetta, vaan päinvastoin luoda luotettavaa palautetta ja sen avulla valvoa huolellisesti toimintansa tuloksia;

(Ärsytys on hoidettava itse.)

Vertaa ohjelmointia kauhan nostamiseen kaivosta. Kauha täytetään vedellä, käännät vipua, kierrät ketjua portin ympäri ja nostat kauhaa ylös. Jos kauha on pieni, tavallinen, vapaasti pyörivä portti käy. Mutta jos ämpäri on iso ja painava, väsyt ennen kuin ehdit nostaa sitä. Jotta voisi levätä vivun kierrosten välillä, tarvitaan räikkämekanismi, joka mahdollistaa vivun lukitsemisen. Mitä raskaampi kauha, sitä useammin räikkäpyörän hampaiden tulee seurata perässä.

TDD:n testit ovat räikkävaihteen hampaita. Tekemällä testin toimimaan tiedämme, että testi toimii nyt, nyt ja ikuisesti. Olemme askeleen lähempänä valmistumista kuin olimme ennen testin aloittamista. Sen jälkeen saamme toisen testin toimimaan, sitten kolmannen, sitten neljännen ja niin edelleen. Mitä monimutkaisempi ohjelmoijan kohtaama ongelma, sitä vähemmän toimintoja kunkin testin tulee kattaa.

kirjojen lukijat Extreme ohjelmointi selitetty on täytynyt huomata sävyeron Extreme Programming (XP) ja Test-Driven Development (TDD) välillä. Toisin kuin XP, TDD-metodologia ei ole ehdoton. XP sanoo: "Jos haluat jatkaa, sinun on hallittava tämä ja tuo." TDD on vähemmän spesifinen tekniikka. TDD olettaa, että päätöksen tekemisen ja tulosten vastaanottamisen välillä on aikaväli, ja tarjoaa työkaluja tämän aikavälin keston hallintaan. "Entä jos suunnittelen algoritmin paperille viikon ajan ja kirjoitan sitten koodin käyttämällä ensin testiä? Sopiiko se TDD:hen?" Tottakai se tulee olemaan. Tiedät aikavälin päätöksenteon ja tulosten arvioinnin välillä ja hallitset tätä väliä tietoisesti.

Useimmat ihmiset, jotka ovat oppineet TDD:n, väittävät, että heidän ohjelmointikäytäntönsä ovat muuttuneet parempaan suuntaan. Tartunta testeillä(testitartunta) on Erich Gamman keksimä määritelmä kuvaamaan tätä muutosta. Kun hallitset TDD:n, huomaat kirjoittavasi huomattavasti enemmän testejä kuin ennen ja jatkat eteenpäin pienin askelin, jotka olisivat tuntuneet sinusta aiemmin turhalta. Toisaalta jotkut ohjelmoijat, jotka ovat tutustuneet TDD:hen, päättävät palata vanhoihin käytäntöihin varaamalla TDD:n erikoistapauksiin, joissa perinteinen ohjelmointi ei johda toivottuun edistymiseen.

Varmasti on ongelmia, joita ei (ainakaan toistaiseksi) voida ratkaista pelkästään testeillä. Erityisesti TDD ei salli kehitetyn koodin riittävyyden mekaanista osoittamista tietoturvallisuuden ja rinnakkaistoimintojen luotettavuuden kannalta. Tietysti turvallisuus perustuu koodiin, joka ei saa olla viallinen, mutta se perustuu myös ihmisten osallistumiseen tietosuojamenettelyihin. Samanaikaisuuden hienovaraisia ​​ongelmia ei voida toistaa varmuudella yksinkertaisesti suorittamalla jotain koodia.

Extreme Programming (XP) on yksi joustavista ohjelmistokehitysmenetelmistä. Metodologian kirjoittajat ovat Kent Beck, Ward Cunningham, Martin Fowler ja muut.

Suunnittelupeli

Maailmamme on liian muuttuva ja arvaamaton luottaaksemme tilanteen pysyvyyteen. Sama tapahtuu ohjelmistokehityksessä: harvinaisesta järjestelmästä voidaan sanoa, että sen lopullinen muoto tiedettiin etukäteen yksityiskohtaisesti jo kehityksen alussa. Yleensä asiakkaan ruokahalu tulee syömisen yhteydessä: hän haluaa jatkuvasti muuttaa jotain, parantaa jotain ja heittää jotain pois järjestelmästä. Tämä on vaatimusten vaihtelu, jota kaikki niin pelkäävät. Onneksi ihmiselle on annettu kyky ennakoida mahdollisia vaihtoehtoja ja siten pitää tilanne hallinnassa.
Extreme Ohjelmoinnissa suunnittelu on olennainen osa kehittämistä ja se, että suunnitelmat voivat muuttua, otetaan huomioon alusta alkaen. Tämä tukipiste, tekniikka, jonka avulla voit ennustaa tilanteen ja sietää kivuttomasti muutoksia, on suunnittelupeliä. Tällaisen pelin aikana tunnetut järjestelmävaatimukset voidaan nopeasti kerätä, arvioida ja suunnitella niiden kehittämistä varten prioriteetin mukaisesti.
Kuten kaikilla muillakin peleillä, suunnittelulla on osallistujansa ja tarkoituksensa. Avainhenkilö on tietysti asiakas. Hän ilmoittaa tietyn toiminnon tarpeesta. Ohjelmoijat antavat myös likimääräisen arvion jokaisesta toiminnasta. Suunnittelupelin kauneus piilee tarkoituksen yhtenäisyydessä ja yhteisvastuussa kehittäjän ja asiakkaan välillä: voiton tapauksessa kaikki voittavat, tappion tapauksessa kaikki häviävät. Mutta samalla jokainen osallistuja menee voittoon omalla tavallaan: asiakas valitsee tärkeimmät tehtävät budjetin mukaisesti, ja ohjelmoija arvioi tehtävät kykyjensä mukaisesti toteuttaa ne.
Extreme ohjelmointi olettaa, että kehittäjät voivat itse päättää, kuinka kauan he selviävät tehtävistään ja kumpi heistä olisi halukkaampi ratkaisemaan yhden ongelman ja kuka ei.
Ideaalitilanteessa suunnittelupeli, jossa asiakas ja ohjelmoija on mukana, tulisi pelata 3-6 viikon välein, ennen seuraavan kehitysiteerauksen alkamista. Tämä tekee säätöjen tekemisestä melko helppoa edellisen iteraation onnistumisten ja epäonnistumisten mukaisesti.

Julkaisusuunnitelma

Julkaisusuunnitelma määrittelee julkaisupäivät ja käyttäjäkielen, joka otetaan käyttöön kussakin julkaisussa. Tämän perusteella voit valita seuraavan iteroinnin sanamuodon. Iteroinnin aikana hyväksyntätestejä tuotetaan ja ajetaan tässä iteraatiossa ja kaikissa myöhemmissä iteraatioissa varmistaakseen, että ohjelma toimii oikein. Suunnitelmaa voidaan tarkistaa, jos jonkin iteroinnin tulosten seurauksena on merkittävä viive tai edistyminen.
Iteraatiot. Iteraatio tekee kehitysprosessista dynaamisen. Ohjelmointitehtäviä ei tarvitse suunnitella kauan etukäteen. Sen sijaan on parempi pitää suunnittelukokous jokaisen iteraation alussa. Ei kannata yrittää toteuttaa sellaista, mitä ei ollut suunniteltu. Sinulla on vielä aikaa toteuttaa nämä ideat, kun ne saavuttavat vuoronsa julkaisusuunnitelman mukaan.
Tottumalla siihen, ettei toimintoja lisätä etukäteen ja käyttämällä suoraa suunnittelua, voit mukautua helposti muuttuviin asiakkaiden tarpeisiin.

Iteraatiosuunnittelu

Iteraatiosuunnittelu alkaa tapaamisesta jokaisen iteroinnin alussa, jossa laaditaan suunnitelma vaiheista ohjelman tavoitteiden saavuttamiseksi. Jokaisen iteraation tulisi kestää yhdestä kolmeen viikkoa. Iteraatiossa olevat lausunnot lajitellaan niiden tärkeyden mukaan asiakkaalle. Lisäksi lisätään tehtäviä, jotka eivät läpäisseet hyväksyntätestejä ja joita on parannettava. Lausunnot ja testitulokset muunnetaan ohjelmatehtäviksi. Tehtävät kirjoitetaan korteille, jotka muodostavat yksityiskohtaisen iteraatiosuunnitelman. Jokaisen tehtävän ratkaiseminen kestää yhdestä kolmeen päivää. Alle yhden päivän vaativat tehtävät voidaan ryhmitellä yhteen ja suuret tehtävät useaan pienempään. Kehittäjät arvioivat tehtävät ja niiden suorittamisen määräajat. Kehittäjälle on erittäin tärkeää asettaa tarkka aika tehtävän suorittamiselle. Saattaa olla tarpeen arvioida osa kielestä uudelleen ja tarkistaa julkaisusuunnitelma kolmen tai viiden iteroinnin jälkeen - tämä on täysin hyväksyttävää. Jos toteutat ensin tärkeimmät työn osa-alueet, niin sinulla on aina aikaa tehdä asiakkaidesi puolesta mahdollisimman paljon. Iteraatioiden sarjaan perustuva kehitystyyli parantaa kehitysprosessia.

Pysyvä kokous

Joka aamu on tapaaminen, jossa keskustellaan ongelmista, niiden ratkaisuista ja lisätään tiimin keskittymistä. Kokous pidetään seisoen, jotta vältytään pitkiltä keskusteluilta, jotka eivät kiinnosta kaikkia tiimin jäseniä.
Tyypillisessä kokouksessa useimmat osallistujat eivät osallistu mitään, osallistuvat vain kuullakseen, mitä muilla on sanottavaa. Suuri määrä ihmisten aikaa menee hukkaan pienen määrän viestintään vastaanottamiseen. Siksi kaikkien ihmisten osallistuminen kokouksiin vie resursseja projektilta ja luo kaaosta suunnitteluun.
Tällaista viestintää varten tarvitaan pysyvä kokous. On paljon parempi pitää yksi lyhyt pakollinen kokous kuin monta pitkää kokousta, joihin useimpien kehittäjien on joka tapauksessa osallistuttava.
Jos sinulla on päivittäin seisovia kokouksia, kaikkiin muihin kokouksiin tulisi osallistua vain niitä ihmisiä, joita tarvitaan ja jotka tuovat jotain. Lisäksi on mahdollista jopa välttää joitain tapaamisia. Kun osallistujia on rajoitetusti, useimmat kokoukset voidaan pitää spontaanisti monitorin edessä, jossa ajatustenvaihto on paljon intensiivisempaa.
Päivittäinen aamukokous ei ole pelkkää ajanhukkaa. Sen avulla voit välttää monia muita tapaamisia ja säästää enemmän aikaa kuin hukkaan heitettyä.

Yksinkertaisuus

Yksinkertainen suunnittelu vie aina vähemmän aikaa kuin monimutkainen. Joten tee aina yksinkertaisimpia asioita, jotka voivat vain toimia. On aina nopeampaa ja halvempaa vaihtaa monimutkainen koodi heti, ennen kuin käytät paljon aikaa sen parissa. Pidä asiat mahdollisimman yksinkertaisina lisäämättä toimintoja ennen kuin se on suunniteltu. Muista: suunnittelun pitäminen yksinkertaisena on kovaa työtä.

Metafora järjestelmä

Metaforajärjestelmän valinta on tarpeen, jotta tiimi pysyy samassa kehyksessä luokkien ja menetelmien nimeämisessä. Objektien nimeäminen on erittäin tärkeää järjestelmän yleisen suunnittelun ja koodin uudelleenkäytön ymmärtämiseksi. Jos kehittäjä pystyy arvaamaan oikein, kuinka olemassa oleva objekti saatetaan nimetä, tämä säästää aikaa. Käytä objekteillesi nimijärjestelmää, jonka kaikki ymmärtävät ilman erityistä tietoa järjestelmästä.

Asiakas työmaalla

Ohjelmistokehityksen suurin ongelma on ohjelmoijien tietämyksen puute kehitetyllä ainealueella. Extreme Programming löysi myös tien ulos tästä tilanteesta. Ei, tämä ei ole kehittäjän harjoittelu asiakkaan yrityksessä - silloin hän ei halua ohjelmoida. Päinvastoin, se on asiakkaan osallistumista kehitysprosessiin.
Kuinka ohjelmoija voi arvata, mitä asiakas haluaa, ymmärtämättä asian ydintä perusteellisesti ja olematta telepaatti? Vastaus on ilmeinen. Helpoin tapa voittaa tämä vaiva - ja Extreme Programming opettaa meitä löytämään yksinkertaisimmat ratkaisut - on kysyä asiakkaalta suora kysymys. Tiukemmat lähestymistavat vaativat kattavan alustavan analyysin kehitettävistä alueista. Tietyissä tapauksissa tämä on perusteltua, vaikka se maksaa enemmän. Todellinen kokemus arkipäiväisten projektien toteuttamisesta osoittaa, että kaikkia vaatimuksia on mahdotonta kerätä etukäteen. Lisäksi vaikka olettaisimme, että kaikki vaatimukset on tällä hetkellä kerätty, yksi pullonkaula jää silti: ohjelmia, kuten kaikkea luonnossa, ei luoda hetkessä, ja sillä välin liiketoimintaprosessit voivat muuttua. Tämä on otettava huomioon.
Monet epäilevät mahdollisuutta ottaa asiakas mukaan kehitysprosessiin. Kyllä asiakkaat ovat erilaisia. Jos asiakasta tai hänen edustajaansa ei voida houkutella, on joskus järkevää palkata tilapäisesti asiantuntija kehitettäville alueille. Tällainen askel vähentää työn epäselvyyksiä, nopeuttaa kehitystä ja tuo projektia lähemmäksi sitä, mitä asiakas haluaa saada. Tästä voi olla hyötyä myös taloudelliselta puolelta: ohjelmoijan palkka ylittää joskus huomattavasti muiden alojen asiantuntijoiden palkan.
käyttäjän tarina. User Story (jokin käyttäjätarina) on kuvaus siitä, kuinka järjestelmän pitäisi toimia. Jokainen käyttäjätarina on kirjoitettu kortille ja edustaa jotakin järjestelmän toiminnallisuutta, joka on loogista Asiakkaan näkökulmasta. Lomake on yksi tai kaksi kappaletta tekstiä, joka on käyttäjälle ymmärrettävää (ei kovin teknistä).
Käyttäjätarina on asiakkaan kirjoittama. Ne ovat samanlaisia ​​kuin järjestelmän käyttötapaukset, mutta eivät rajoitu käyttöliittymään. Jokaiselle tarinalle kirjoitetaan toiminnalliset testit sen varmistamiseksi, että tämä tarina on toteutettu oikein - niitä kutsutaan myös hyväksymistesteiksi.

Testaus ennen kehitystä

Testaus sen klassisessa merkityksessä on melko tylsä ​​toimenpide. Yleensä he palkkaavat testaajan, joka suorittaa ajoittain samat toiminnot ja odottaa päivää, jolloin hänet lopulta siirretään toiseen tehtävään tai on mahdollisuus vaihtaa työpaikkaa.
Äärimmäisessä ohjelmoinnissa testauksen rooli on mielenkiintoisempi: nyt ensin testi ja sitten koodi. Kuinka voit testata jotain, jota ei vielä ole olemassa? Vastaus on yksinkertainen ja banaalinen: testaa ajatuksesi - mitä tulevaiselta ohjelmistolta tai toiminnalta pitäisi odottaa. Näin ymmärrät paremmin, mitä ohjelmoijien tulee tehdä, ja tarkistat koodin toimivuuden heti sen kirjoittamisen jälkeen.
Mutta testikään ei välttämättä toimi. Entäpä kokeen kirjoittaminen kokeeseen? Ja sitten testi testiä varten ja niin edelleen loputtomiin? Ei lainkaan. Testin testi korvaa koodin. Kuinka niin? Mutta katso: kuvittele, että sinun on kiinnitettävä mutteri pultin keskelle, jotta se ei käänny. Mitä he tekevät tämän eteen? Kierrä toinen mutteri lähelle ensimmäistä niin, että jokainen mutteri estää seuraavaa kääntymästä. Sama on ohjelmoinnissa: testi testaa koodin ja koodi testaa testiä.
Kokemus osoittaa, että tämä lähestymistapa ei vain hidasta, vaan myös nopeuttaa kehitystä. Loppujen lopuksi, kun tiedetään, mitä on tehtävä, ja tarvittava määrä työtä, säästää aikaa kieltäytymällä toteuttamasta osia, joilla ei ole tällä hetkellä kysyntää.

Pariohjelmointi

Kaikki tuotantojärjestelmän koodit kirjoitetaan pareittain. Kaksi kehittäjää istuu vierekkäin. Toinen soittaa, toinen katselee. Ne muuttuvat aika ajoin. Yksin työskentely ei ole sallittua. Jos parin toiselta jostain syystä jäi jotain paitsi (hän ​​oli sairas, lähti pois jne.), hänen on tarkistettava kaikki ensimmäisen tekemät muutokset.
Se kuulostaa epätavalliselta, mutta lyhyen sopeutumisjakson jälkeen useimmat ihmiset työskentelevät erinomaisesti pareittain. He jopa pitävät siitä, koska työ tehdään huomattavasti nopeammin. Periaate "yksi pää on hyvä, mutta kaksi on parempi" pätee. Pariskunnat löytävät yleensä optimaalisempia ratkaisuja. Lisäksi koodin laatu paranee merkittävästi, virheiden määrä vähenee ja tiedon vaihto kehittäjien välillä nopeutuu. Kun toinen henkilö keskittyy kohteen strategiseen näkemykseen, toinen henkilö toteuttaa sen ominaisuuksia ja menetelmiä.

Asemien vaihto

Seuraavan iteroinnin aikana kaikki työntekijät tulisi siirtää uusille työalueille. Tällaiset liikkeet ovat välttämättömiä tiedon eristäytymisen välttämiseksi ja pullonkaulojen poistamiseksi. Erityisen hedelmällistä on yhden kehittäjän korvaaminen pariohjelmoinnissa.

Koodin kollektiivinen omistus

Koodin kollektiivinen omistaminen kannustaa kehittäjiä lähettämään ideoita projektin kaikkiin osiin, ei vain omiin moduuleihinsa. Kuka tahansa kehittäjä voi muuttaa mitä tahansa koodia lisätäkseen toimintoja ja korjatakseen virheitä.
Ensi silmäyksellä se näyttää kaaokselta. Mutta kun otetaan huomioon, että ainakin mikä tahansa koodi on parin kehittäjän luoma, että testeillä voidaan tarkistaa tehtyjen muutosten oikeellisuus ja että tosielämässä on silti ymmärrettävä jonkun muun koodi tavalla tai toisella, tulee selväksi. että kollektiivinen koodin omistaminen yksinkertaistaa suuresti muutosten käyttöönottoa ja vähentää riskiä, ​​joka liittyy tiimin jäsenen korkeaan erikoistumiseen.

Koodauskäytäntö

Olet tiimissä, joka on työskennellyt tämän projektin parissa pitkään. Ihmisiä tulee ja menee. Kukaan ei koodaa yksin ja koodi kuuluu kaikille. Aina tulee hetkiä, jolloin on tarpeen ymmärtää ja korjata jonkun toisen koodi. Kehittäjät poistavat tai muuttavat päällekkäistä koodia, analysoivat ja parantavat muiden ihmisten luokkia ja niin edelleen. Ajan myötä ei ole mahdollista kertoa, kuka tietyn luokan kirjoittaja on.
Siksi kaikkien on noudatettava yleisiä koodausstandardeja - koodin muotoilu, luokka, muuttuja, jatkuva nimeäminen, kommenttityyli. Tällä tavalla voimme olla varmoja siitä, että tekemällä muutoksia jonkun toisen koodiin (mikä on välttämätöntä aggressiiviseen ja äärimmäiseen edistymiseen eteenpäin), emme tee siitä Babylonian Pandemoniumia.
Yllä oleva tarkoittaa, että kaikkien tiimin jäsenten on sopia yhteisistä koodausstandardeista. Ei väliä mitä. Sääntönä on, että kaikki noudattavat niitä. Ne, jotka eivät halua noudattaa niitä, lähtevät joukkueesta.

Toistuva integraatio

Jos mahdollista, kehittäjien tulisi integroida ja julkaista koodinsa muutaman tunnin välein. Muutoksia ei missään tapauksessa pidä säilyttää yhtä päivää pidempään. Toistuva integrointi välttää vieraantumista ja pirstoutumista kehitystyössä, jossa kehittäjät eivät voi kommunikoida ideoiden vaihtamisen tai koodin uudelleenkäytön mielessä. Kaikkien tulee käyttää uusinta versiota.
Jokaisen kehittäjäparin tulee luovuttaa koodinsa heti, kun siihen on kohtuullinen tilaisuus. Tämä voi tapahtua, kun kaikki UnitTestit läpäisevät 100%. Lähettämällä muutoksia useita kertoja päivässä vähennät integrointiongelmat lähes olemattomiin. Integrointi on "maksa nyt tai maksa enemmän myöhemmin" -toimintoa. Siksi integroimalla muutokset päivittäin pienissä erissä sinun ei tarvitse käyttää viikkoa järjestelmän yhdistämiseen juuri ennen projektin toimittamista. Työskentele aina järjestelmän uusimmalla versiolla.

Neljänkymmenen tunnin työviikko

Henkilö, varsinkin jos hän on ohjelmoija, pystyy tekemään paljon liiketoiminnan vuoksi: pysyä töissä, mennä töihin viikonlopuksi, kieltäytyä ottamasta lomaa, pysyä hereillä useita päiviä istuen näppäimistön ääressä. .. Yleensä et voi tehdä mitään lempiajanviettosi vuoksi. Mutta äärimmäinen ohjelmointi vastustaa ehdottomasti tällaista uhrautumista ja hyväksyttyjen työlain normien rikkomista.
Tätä ei sanele vain laillisuus- ja inhimillisyysnäkökohdat, vaan - ennen kaikkea - tarve lisätä työn tehokkuutta ja tiukka organisointi. Loppujen lopuksi äärimmäinen ohjelmointi on kollektiivipeli, jota ei ole suunniteltu yksilöille, vaan koko ryhmälle kokonaisuutena. Ja sellainen asia kuin esimerkiksi pariohjelmointi on mahdollista vain, jos sen osallistujien biorytmit synkronoidaan. Ja on mahdotonta, jos toinen tulee töihin yhdeksältä ja toinen kahdeltatoista, tai toinen päättää, että hänen on parempi työskennellä lauantaina ja sunnuntaina, kun taas toinen tuntee olonsa epämukavaksi.
Mutta mikä tärkeintä, henkilö tarvitsee hyvän levon terveyden ja suorituskyvyn ylläpitämiseksi. Kahdeksan tunnin työpäivä ja viiden päivän työviikko on asetettu juuri maksimaalisen tuottavuuden vuoksi. Monissa länsimaisissa yrityksissä töistä myöhästymistä pidetään huonona akateemisena suorituksena tai kyvyttömyytenä hallita työaikaansa kunnolla. Useimmissa tapauksissa tämä on totta. Kyllä, ja lääketieteellisestä näkökulmasta katsottuna viivästykset työssä johtavat jatkuvaan väsymykseen, ärtyneisyyteen ja aivojen toiminnan vähenemiseen. Onko se tehokasta? Mutta kuinka järjestää jatkuva avoin viestintä kehittäjien välillä tällaisessa tiimissä, ja onko pariohjelmointi mahdollista? Vastaus on kielteinen. Säännöt ovat sääntöjä ja niitä tulee noudattaa.

Johtopäätös

Näitä tekniikoita ei ole yhdistetty sattumalta. Niiden johdonmukainen yhdistelmä pystyy tuomaan kehitysprosessin henkiseen resonanssiin, mikä parantaa merkittävästi tuotteen laatua ja lähentää sen julkaisuaikaa. Kaiken Extreme Programmingin tärkein kauneus on ennustettavuus ja kehityskustannusten minimoiminen; tarjota asiakkaalle tuote, jonka hän haluaa saada luovutushetkellä; ja tietysti viestintä ja kehittäjien koulutus työssä.

Bibliografia:

Kehitys (järjestelmän toimintojen ohjaama kehitys) jne.

XP:n tekijöiden mukaan tämä tekniikka ei niinkään noudata joitain yleisiä toimintamalleja kuin seuraavien tekniikoiden yhdistelmää. Jokainen tekniikka on kuitenkin tärkeä, ja ilman sitä kehitystä ei pidetä XP:n ulkopuolella, sanoo Kent Beck, yksi tämän lähestymistavan kirjoittajista yhdessä Ward Cunninghamin ja Ron Jeffriesin kanssa.

  • Live-suunnittelu (suunnittelupeli)

    Sen tehtävänä on määrittää mahdollisimman nopeasti työmäärä, joka on tehtävä ennen seuraavaa ohjelmistoversiota. Päätös tehdään ensinnäkin asiakkaan prioriteettien perusteella (eli hänen tarpeidensa perusteella, mitä hän tarvitsee järjestelmästä toimiakseen menestyksekkäämmin) ja toiseksi teknisten arvioiden (eli arvioiden monimutkaisuudesta) perusteella. kehitys, yhteensopivuus järjestelmän muiden osien kanssa jne.). Suunnitelmat muuttuvat heti, kun ne alkavat poiketa todellisuudesta tai asiakkaan toiveista.

  • Usein vaihtuva versio (pienet julkaisut)

    Ensimmäisen toimivan version pitäisi ilmestyä mahdollisimman pian ja se tulee käyttää välittömästi. Seuraavat versiot valmistellaan melko lyhyin väliajoin (muutamasta tunnista pienillä muutoksilla pienessä ohjelmassa, kuukauteen tai kahteen suuren järjestelmän suureen päivitykseen).

  • Järjestelmän metafora

    Metaforan tulee kuvata järjestelmän päämekanismia melko yksinkertaisessa ja ryhmälle ymmärrettävässä muodossa. Tämä konsepti muistuttaa arkkitehtuuria, mutta sen pitäisi olla paljon yksinkertaisempaa, vain yhdellä tai kahdella lauseella, kuvaamaan hyväksyttyjen teknisten ratkaisujen ydinolemus.

  • Yksinkertaiset suunnitteluratkaisut (yksinkertainen suunnittelu)

    Järjestelmä tulee aina suunnitella mahdollisimman yksinkertaisesti. Ominaisuuksia ei tarvitse lisätä etukäteen - vain sen nimenomaisen pyytämisen jälkeen. Kaikki ylimääräinen monimutkaisuus poistetaan heti, kun se havaitaan.

  • Testilähtöinen kehitys

    Kehittäjät kirjoittavat ensin testejä ja yrittävät sitten toteuttaa moduulinsa niin, että testit toimivat. Asiakkaat kirjoittavat etukäteen testejä, jotka esittelevät järjestelmän pääominaisuudet, jotta voit nähdä järjestelmän todella toimivan.

  • Jatkuva käsittely (refaktorointi)

    Ohjelmoijat muokkaavat järjestelmää jatkuvasti poistaakseen tarpeettoman monimutkaisuuden, lisätäkseen koodin ymmärrettävyyttä, lisätäkseen sen joustavuutta, mutta muuttamatta sen käyttäytymistä, mikä varmistetaan suorittamalla testien jokaisen uudelleenkäsittelyn jälkeen. Samalla suositaan tyylikkäämpiä ja joustavampia ratkaisuja verrattuna niihin, jotka yksinkertaisesti antavat halutun tuloksen. Epäonnistuneet uudelleenmuodostetut komponentit tulee havaita testejä suoritettaessa ja palauttaa viimeiseen yhdenmukaiseen tilaan (sekä niistä riippuvien komponenttien kanssa).

  • Pariohjelmointi

    Koodauksen suorittaa kaksi ohjelmoijaa yhdellä tietokoneella. Pariliitos on mielivaltainen ja vaihtelee ongelmasta toiseen. Se, jonka käsissä näppäimistö yrittää ratkaista nykyisen ongelman parhaalla tavalla. Toinen ohjelmoija analysoi ensimmäisen työtä ja antaa neuvoja, pohtii tiettyjen päätösten seurauksia, uusia testejä, vähemmän suoria, mutta joustavampia ratkaisuja.

  • Koodin yhteisomistus (kollektiivinen omistus)

    Kuka tahansa tiimin jäsen voi milloin tahansa muuttaa mitä tahansa koodin osaa. Kenenkään ei pidä erottaa omaa vastuualuettaan, vaan koko tiimi on vastuussa kaikesta koodista.

  • Jatkuva integraatio

    Järjestelmä kootaan ja integroidaan niin usein kuin mahdollista, useita kertoja päivässä, joka kerta, kun pari ohjelmoijaa lopettaa jonkin ominaisuuden toteuttamisen.

  • 40 tunnin työviikko

    Ylityöt nähdään merkkinä projektin suurista ongelmista. Ylitöitä ei saa tehdä 2 viikkoa peräkkäin - tämä uuvuttaa ohjelmoijat ja tekee heidän työstään huomattavasti vähemmän tuottavaa.

  • Asiakkaan osallistuminen tiimiin (on-site-asiakas)

    Osana kehitystiimiä on aina paikalla asiakkaan edustaja, joka on tavoitettavissa koko työpäivän ja pystyy vastaamaan kaikkiin järjestelmää koskeviin kysymyksiin. Hänen velvollisuutensa on vastata nopeasti kaikentyyppisiin kysymyksiin, jotka koskevat järjestelmän toimintoja, sen käyttöliittymää, vaadittua suorituskykyä, järjestelmän oikeaa toimintaa vaikeissa tilanteissa, tarvetta kommunikoida muiden sovellusten kanssa jne.

  • Koodin käyttäminen viestintävälineenä

    Koodi nähdään tärkeimpänä viestintävälineenä tiimin sisällä. Koodin selkeys on yksi tärkeimmistä prioriteeteista. Selkeyden tarjoavien koodausstandardien noudattaminen on välttämätöntä. Tällaisten standardien tulee koodin selkeyden lisäksi varmistaa mahdollisimman vähän ilmaisuja (ei koodin ja tiedon päällekkäisyyttä), ja kaikkien tiimin jäsenten tulee hyväksyä ne.

  • Avoin työtila (avoin työtila)

    Ryhmä on sijoitettu yhteen huoneeseen, joka on riittävän tilava mahdollistamaan kommunikointi ja mahdollisuus yhteisiin keskusteluihin suunnittelua ja tärkeitä teknisiä päätöksiä tehtäessä.

  • Sääntöjen muuttaminen tarpeen mukaan (vain säännöt)

    Jokaisen tiimin jäsenen tulee hyväksyä luetellut säännöt, mutta tarvittaessa tiimi voi muuttaa niitä, jos kaikki sen jäsenet ovat samaa mieltä tästä muutoksesta.

Kuten käytetyistä tekniikoista näkyy, XP on suunniteltu käytettäväksi pienissä ryhmissä (enintään 10 ohjelmoijaa), mitä myös tämän tekniikan kirjoittajat korostavat. Suurempi tiimikoko tuhoaa onnistumisen kannalta välttämättömän kommunikoinnin helppouden ja tekee monista luetelluista tekniikoista mahdottomaksi.

XP:n etuja, jos sitä voidaan käyttää, ovat suurempi joustavuus, kyky tehdä ohjelmistoon muutoksia nopeasti ja tarkasti asiakkaiden muuttuvien vaatimusten ja yksilöllisten toiveiden mukaisesti, tuloksena olevan koodin korkea laatu ja tarpeeton vakuuttaa asiakkaat siitä, että tulos vastaa heidän odotuksiaan.

Tämän lähestymistavan haittoja ovat riittävän suurten ja monimutkaisten projektien epäkäytännöllisyys tässä tyylissä, kyvyttömyys suunnitella projektin ajoitusta ja työvoimavaltaisuutta riittävän pitkälle aikavälille ja ennustaa selkeästi pitkän aikavälin projektin tuloksia. tuloksen laadun ja käytetyn ajan ja resurssien suhdetta. Voidaan myös todeta, että XP ei sovellu sellaisiin tapauksiin, joissa mahdollisia ratkaisuja ei aikaisemman kokemuksen perusteella heti löydy, vaan ne vaativat alustavaa tutkimusta.

XP:tä kuvattujen tekniikoiden yhdistelmänä käytettiin ensimmäisen kerran työskenneltäessä C3-projektissa (Chrysler Comprehensive Compensation System, Daimler Chryslerin työsuhde-etuuksien laskentajärjestelmän kehittäminen). Tämän projektin 20 avustajasta 5 (mukaan lukien 3 edellä mainitut XP:n päätekijät) julkaisi 3 kirjaa ja valtavan määrän artikkeleita XP:stä itse projektin aikana ja tulevaisuudessa. Tämä projekti on toistuvasti mainittu eri lähteissä esimerkkinä tämän tekniikan käytöstä,,. Alla olevat tiedot on koottu viitatuista artikkeleista, joista on vähennetty anekdoottiset todisteet, ja ne kuvaavat joidenkin XP-tekniikoiden ongelmia, kun niitä sovelletaan melko monimutkaisiin projekteihin.

Hanke alkoi tammikuussa 1995. Maaliskuusta 1996 lähtien Kent Beckin sisällyttämisen jälkeen sitä on ajettu XP:llä. Siihen mennessä se oli jo ylittänyt budjetin ja suunnitelmia toimintojen vaiheittaisesta toteuttamisesta. Kehitystiimiä supistettiin ja noin puoli vuotta sen jälkeen projekti kehittyi varsin menestyksekkäästi. Elokuussa 1998 ilmestyi prototyyppi, joka voisi palvella noin 10 000 työntekijää. Aluksi projektin oli määrä päättyä vuoden 1999 puolivälissä ja tuloksena olevaa ohjelmistoa käytettäisiin yhtiön 87 000 työntekijän etujen hallintaan. Se keskeytettiin helmikuussa 2000 neljän vuoden XP-työskentelyn jälkeen, koska aikataulua ja budjettia ei saavutettu. Luotua ohjelmistoa ei ole koskaan käytetty yli 10 000 työntekijän tietojen käsittelyyn, vaikka on osoitettu, että se pystyy käsittelemään 30 000 yrityksen työntekijän tietoja. Projektitiimiin kuuluvan asiakkaan roolissa ollut henkilö irtisanoutui muutaman kuukauden työskentelyn jälkeen kestämättä kuormaa eikä saanut riittävää vaihtoa ennen projektin päättymistä.

Extreme Programming - nopea ohjelmistokehitysmenetelmä. Se koostuu joukosta tekniikoita ja periaatteita, jotka mahdollistavat kehitysprosessin optimoinnin sekä yksilöllisesti että yhdessä. Tämä lähestymistapa säätelee myös kehittäjien ja asiakkaiden oikeuksia.

Oikeudet ja roolit

Äärimmäisessä ohjelmoinnissa kaikki roolit on kuvattu selkeästi. Jokainen rooli sisältää tyypilliset oikeudet ja velvollisuudet. Tässä on kaksi avainroolia: asiakas ja kehittäjä.

Asiakas

Henkilö tai ihmisryhmä, joka on kiinnostunut luomaan tietyn ohjelmistotuotteen. Hänellä on seuraavat oikeudet ja velvollisuudet:

  • korjata tuoteversioiden julkaisupäivämäärät;
  • tehdä päätöksiä ohjelman suunnitelluista osista;
  • tietää kunkin toiminnallisen komponentin arvioidut kustannukset;
  • tehdä tärkeitä liiketoimintapäätöksiä;
  • tietää järjestelmän nykyisen tilan;
  • muuttaa järjestelmävaatimuksia, kun sillä on todella merkitystä.

Käyttääkseen oikeuksiaan onnistuneesti asiakkaan tulee luottaa kehittäjien antamiin tietoihin.

Kehittäjä

Yksi tai kahdesta kymmeneen hengen ryhmä, joka osallistuu suoraan ohjelmointiin ja siihen liittyviin suunnitteluasioihin. Kehittäjällä on seuraavat oikeudet ja velvollisuudet:

  • hankkia riittävästi tietoa ohjelmoitavista asioista;
  • pystyä selventämään kehitysprosessin yksityiskohtia;
  • antaa viitteelliset mutta rehelliset arviot työvoimakustannuksista jokaiselle toiminnalliselle osalle tai käyttäjätarinalle;
  • muuttaa arvioita tarkempiin kehitysprosessissa;
  • antaa arvion tiettyjen teknologioiden käyttöön liittyvistä riskeistä.

Roolit roolissa

Jokainen Extreme Programming -perusrooleista voidaan jalostaa pienemmiksi rooleiksi. XP:ssä roolien yhdistäminen saman henkilön sisällä on sallittu.

Asiakaspuoli

Tarinantekijä- alan asiantuntija, jolla on kyky selkeästi ilmaista ja kuvata kehitettävän järjestelmän vaatimukset. Tämä henkilö tai ihmisryhmä on vastuussa käyttäjien tarinoiden kirjoittamisesta ja ohjelmoijien väärinkäsitysten selvittämisestä.

vastaanotin- henkilö, joka valvoo järjestelmän moitteetonta toimintaa. Hyvä aihealueen tuntemus. Työtehtäviin kuuluu hyväksyntäkokeiden kirjoittaminen.

Iso pomo- valvoo kaikkien linkkien toimintaa kehittäjistä loppukäyttäjiin. Hän valvoo järjestelmän toteutusta ja siihen liittyviä organisatorisia asioita. Voi olla myös sijoittaja hankkeeseen.

Kehittäjän puoli

Ohjelmoija- henkilö, joka osallistuu koodaukseen ja suunnitteluun alhaisella tasolla. Hän on riittävän pätevä ratkaisemaan ajankohtaisia ​​kehitysongelmia ja antamaan totuudenmukaisia ​​arvioita suunnitelluista tehtävistä.

Ohjaaja- kokenut kehittäjä, joka tuntee hyvin koko kehitysprosessin ja sen tekniikat. Vastaat tiimin opettamisesta kehitysprosessiin liittyvistä näkökohdista. Toteuttaa ja ohjaa käytetyn prosessin menetelmien oikeaa toteutusta. Kiinnittää tiimin huomion tärkeisiin, mutta jostain syystä jääneisiin kehityksen hetkiin. Samanaikaisesti ohjaaja, kuten kukaan muu, ei ole kaikkitietävä ja on tarkkaavainen muiden tiimiläisten ideoille.

Tarkkailija- kehitystiimin jäsen, joka nauttii koko ryhmän luottamuksesta, joka seuraa kehityksen etenemistä. Se vertailee alustavia arvioita työvoimakustannuksista ja todellisia kuluja ja näyttää määrälliset indikaattorit tiimin työstä. Näitä ovat esimerkiksi keskinopeus sekä suoritettujen ja suunniteltujen tehtävien prosenttiosuus. Nämä tiedot toimitetaan asiakkaalle tilanteen nopeaa hallintaa varten. Osa näistä tiedoista annetaan huomaamattomasti kehittäjille, jotta he tietävät projektin tilan, missä vaikeuksia ilmenee ja mitä muuta voidaan tehdä.

Diplomaatti- seurallinen henkilö, joka aloittaa kommunikoinnin tiimin jäsenten välillä. Koska asiakirjavirta on minimoitu, jatkuva viestintä ja kokemusten siirto tiimin sisällä on tärkeää sekä järjestelmän vaatimusten parempi ymmärtäminen. Diplomaatti säätelee ja yksinkertaistaa asiakkaiden ja kehittäjien välistä viestintää. Se on tärkeä linkki kokouksissa. Se estää laiminlyöntejä, intohimon huipentumaa ja tarpeettomia riitoja. Diplomaatti ei voi painostaa mielipidettään väittelijöille.

Ulkopuoliset roolit

Konsultti- asiantuntija, jolla on erityisiä teknisiä taitoja auttamaan kehittäjiä vaikeissa tehtävissä. Yleensä tuodaan ulkopuolelta.

Äärimmäiset ohjelmointisäännöt

Koodauskäytäntö

Olet tiimissä, joka on työskennellyt tämän projektin parissa pitkään. Ihmisiä tulee ja menee. Kukaan ei koodaa yksin ja koodi kuuluu kaikille. Aina tulee hetkiä, jolloin on tarpeen ymmärtää ja korjata jonkun toisen koodi. Kehittäjät poistavat tai muuttavat päällekkäistä koodia, analysoivat ja parantavat muiden ihmisten luokkia ja niin edelleen. Ajan myötä ei ole mahdollista kertoa, kuka tietyn luokan kirjoittaja on.

Siksi kaikkien on noudatettava yleisiä koodausstandardeja - koodin muotoilu, luokka, muuttuja, jatkuva nimeäminen, kommenttityyli. Tällä tavalla voimme olla varmoja siitä, että tekemällä muutoksia jonkun toisen koodiin (mikä on välttämätöntä aggressiiviseen ja äärimmäiseen edistymiseen eteenpäin), emme tee siitä Babylonian Pandemoniumia.

Yllä oleva tarkoittaa, että kaikkien tiimin jäsenten on sopia yhteisistä koodausstandardeista. Ei väliä mitä. Sääntönä on, että kaikki noudattavat niitä. Ne, jotka eivät halua noudattaa niitä, lähtevät joukkueesta.

Koodin kollektiivinen omistus

Koodin kollektiivinen omistaminen kannustaa kehittäjiä lähettämään ideoita projektin kaikkiin osiin, ei vain omiin moduuleihinsa. Kuka tahansa kehittäjä voi muuttaa mitä tahansa koodia lisätäkseen toimintoja, korjatakseen vikoja tai palauttaakseen sen.

Ensi silmäyksellä se näyttää kaaokselta. Ottaen kuitenkin huomioon, että ainakin mikä tahansa koodi on parin kehittäjän luoma, että yksikkötesteillä voi tarkistaa tehtyjen muutosten oikeellisuuden ja että tosielämässä täytyy silti ymmärtää jonkun muun koodi tavalla tai toisella, käy selväksi, että koodin kollektiivinen omistaminen yksinkertaistaa suuresti muutoksia ja vähentää riskiä, ​​joka liittyy tiimin jäsenen korkeaan erikoistumiseen.

CRC-istunto

Käytä luokka-, vastuu-, yhteistyö- (CRC) -kortteja tiimisuunnitteluun. Flashcards avulla on helpompi oppia ajattelemaan objekteja funktioiden ja menettelyjen sijaan. Kortit mahdollistavat myös useamman ihmisen osallistumisen suunnitteluprosessiin (mieluiten koko tiimin), ja mitä enemmän ihmisiä suunnittelee, sitä mielenkiintoisempia ideoita tuodaan.

Jokainen CRC-kortti on esineen esiintymä. Päälle voidaan kirjoittaa objektiluokka, vasemmalle tehtävät, oikealle vuorovaikutukset. Sanomme "voidaan kirjoittaa", koska CRC-istunnon ollessa käynnissä osallistujat tarvitsevat yleensä vain pienen määrän luokan nimikortteja, eikä niitä tarvitse olla täysin täytettyinä.

CRC-istunto menee näin: jokainen osallistuja toistaa järjestelmän sanomalla, mitä viestejä se lähettää millekin kohteelle. Välittää viestin viestin toisensa jälkeen koko prosessin ajan. Heikkoudet ja ongelmat tunnistetaan välittömästi. Suunnitteluvaihtoehdot näkyvät myös selvästi prosessia simuloitaessa.

Järjestyksen palauttamista käytetään usein rajoittamaan kahden samanaikaisen vuorovaikutuksen määrää.

Asiakas

Yksi XP:n vaatimuksista on, että asiakas on aina tavoitettavissa. Hänen ei pitäisi vain auttaa kehitystiimiä, vaan olla sen jäsen. XP-projektin kaikki vaiheet edellyttävät yhteydenpitoa asiakkaan kanssa mieluiten kasvokkain - paikan päällä. Mikä parasta, määritä vain yksi tai useampi asiakas kehitystiimiin. Varo, asiakasta tarvitaan vielä pitkään ja asiakkaan toimisto saattaa yrittää antaa sinulle harjoittelijan asiantuntijaksi. Tarvitset asiantuntijan.

Käyttäjien tarinoita asiakkaan kirjoittama kehittäjien avulla. Asiakas auttaa varmistamaan, että suurin osa halutuista järjestelmän ominaisuuksista on katettu User Storyssa.

Julkaisusuunnittelun aikana asiakkaan on keskusteltava suunniteltuun julkaisuun sisällytettävien käyttäjätarinoiden valinnasta. Saatat myös joutua sopia itse julkaisuajasta. Asiakas tekee liiketoimintatavoitteisiin liittyviä päätöksiä.

Valitse yksinkertaisin ratkaisu

Yksinkertainen suunnittelu on aina helpompi toteuttaa kuin monimutkainen. Joten tee aina yksinkertaisin ratkaisu, joka voi toimia. Jos löydät jotain monimutkaista, korvaa se jollain yksinkertaisella. On aina nopeampaa ja halvempaa korvata monimutkainen koodi yksinkertaisella koodilla ennen kuin alat ymmärtää monimutkaista koodia.

Refaktori jonkun muun koodin, jos se tuntuu sinusta monimutkaiselta. Jos jokin näyttää monimutkaiselta, se on varma merkki ongelmasta koodissa.

Pidä päätökset mahdollisimman yksinkertaisina niin pitkään kuin mahdollista. Älä koskaan lisää toimintoja tulevaisuutta varten - ennen kuin niitä tarvitaan. Muista kuitenkin: suunnittelun pitäminen yksinkertaisena on kovaa työtä.

Toiminnalliset testit

Hyväksymistestit (aiemmin myös funktionaaliset) kirjoitetaan User Story:n perusteella. He pitävät järjestelmää mustana laatikkona. Asiakas vastaa toimintatestien oikeellisuuden varmistamisesta. Näitä testejä käytetään järjestelmän kunnon tarkistamiseen ennen sen julkaisua tuotantoon. Toiminnalliset testit ovat automatisoituja, jotta niitä voidaan suorittaa usein. Tulos raportoidaan tiimille ja tiimi vastaa toimintatestien korjausten ajoittamisesta.

Toistuva integraatio

Jos mahdollista, kehittäjien tulisi integroida ja julkaista koodinsa muutaman tunnin välein. Muutoksia ei missään tapauksessa pidä säilyttää yhtä päivää pidempään. Toistuva integrointi välttää vieraantumista ja pirstoutumista kehitystyössä, jossa kehittäjät eivät voi kommunikoida ideoiden vaihtamisen tai koodin uudelleenkäytön mielessä. Kaikkien tulee käyttää uusinta versiota.

Jokaisen kehittäjäparin tulee luovuttaa koodinsa heti, kun siihen on kohtuullinen tilaisuus. Tämä voi tapahtua, kun kaikki UnitTestit läpäisevät 100%. Lähettämällä muutoksia useita kertoja päivässä vähennät integrointiongelmat lähes olemattomiin. Integrointi on "maksa nyt tai maksa enemmän myöhemmin" -toimintoa. Siksi integroimalla muutokset päivittäin pienissä erissä sinun ei tarvitse viettää viikkoa järjestelmän yhdistämiseen juuri ennen projektin toimittamista. Työskentele aina järjestelmän uusimmalla versiolla.

Johtajaksi. Jos kehittäjä ei julkaise muutoksia yli yhden päivän ajan, tämä on selvä merkki vakavasta ongelmasta. Sinun on heti selvitettävä, mikä on vialla. Koko XP-tiimien kokemus kertoo, että viivästyksen syynä on aina huono suunnittelu ja se on aina uusittava myöhemmin.

Iteraatiosuunnittelu

Ennen kunkin iteroinnin alkua kutsutaan koolle iteraatiosuunnittelukokous, jossa suunnitellaan kyseisessä iteraatiossa tehtäviä tehtäviä. Iterointia varten valitaan käyttäjätarinat, jotka asiakas valitsi julkaisusuunnitelma alkaen tärkeimmistä asiakkaalle ja pahimmasta (riskiin liittyvästä) kehittäjille. Iteraatioon sisältyy myös toimimattomia toiminnallisia testejä.

Käyttäjien tarinat ja epäonnistuneet toiminnalliset testit jaetaan tehtäviin. Tehtävät kirjoitetaan korteille. Nämä kortit ovat yksityiskohtainen iteraatiosuunnitelma. Jokaisen tehtävän tulisi olla 1–3 ihanteellisen päivän mittainen.

Kehittäjät erittelevät tehtävät ja arvioivat niiden suorittamiseen tarvittavan ajan. Siten jokainen kehittäjä arvioi, kuinka kauan tehtävä kestää häneltä. On tärkeää, että kehittäjä itse tekee lopullisen arvioinnin työn laajuudesta.

Projektin nopeus määrittää, sopivatko tehtäväsi iteraatioon vai eivät. Iteraatioon suunniteltujen tehtävien kokonaiskesto ei saa ylittää edellisessä iteraatiossa saavutettua nopeutta. Jos kirjoitit liikaa, asiakkaan on päätettävä, mitkä käyttäjätarinat lykkäävät seuraavaan iteraatioon. Jos sait liian vähän pisteitä, sinun on lisättävä seuraava käyttäjätarina. Joissakin tapauksissa voit pyytää asiakasta jakamaan toisen käyttäjätarinasta kahteen osaan sisällyttääksesi osan nykyiseen iteraatioon.

Käyttäjätarinan lykkääminen seuraavaan iteraatioon saattaa tuntua pelottavalta, mutta älä anna itsesi uhrata uudelleenkäsittelyä ja yksikkötestejä saadaksesi enemmän aikaan. Näiden luokkien velka hidastaa nopeasti nopeuttasi. Älä tee sitä, mitä luulet tarvittavan seuraavissa iteraatioissa – tee vain se, mikä on tarpeen nykyisten käyttäjätarinoiden täydentämiseksi.

Seuraa projektin nopeutta ja odottavia käyttäjien tarinoita. On mahdollista, että julkaisusuunnitelmaa on muokattava uudelleen kolmen tai viiden iteroinnin välein. Tämä on hyvä. Vapautussuunnitelma on loppujen lopuksi katse tulevaisuuteen ja on luonnollista odottaa, että ennusteitasi täytyy korjata.

Iteraatiot

Iteratiivinen kehitys lisää prosessin joustavuutta. Jaa suunnitelmasi iteraatioihin, jotka kestävät 2–3 viikkoa. Pidä iteroinnin kesto vakiona projektin keston ajan. Olkoon iteraatio projektisi pulssi. Tämä on rytmi, joka tekee edistymisen mittaamisesta ja suunnittelusta yksinkertaista ja luotettavaa.

Älä suunnittele etukäteen. Kerää sen sijaan Iteraatiosuunnittelu jokaisen iteraation alussa suunnitella, mitä tehdään. Sääntörikkomukseksi katsotaan myös mennä itsensä edelle ja tehdä jotain, mitä ei ole suunniteltu tässä iteraatiossa. Näin on mahdollista pitää asiakkaan muuttuvat vaatimukset hallinnassa.

Ota iteroinnin määräajat vakavasti. Mittaa edistymistä työskennellessäsi. Jos näyttää siltä, ​​että et pysty suorittamaan kaikkia ajoitettuja tehtäviä määräaikaan mennessä, kokoa iteraatiosuunnittelu uudelleen ja arvioi tehtävät uudelleen ja lykkää osaa tehtävistä.

Keskity asiakkaan valitsemien tärkeimpien tehtävien suorittamiseen sen sijaan, että kehittäjä valitsee muutaman keskeneräisen tehtävän.

Vaihda tehtäviä

Kehittäjien tehtäviä on ajoittain muutettava, jotta voidaan vähentää tiedon keskittymisen ja koodin pullonkaulojen riskiä. Jos vain yksi henkilö tiimistäsi voi työskennellä tietyllä alueella ja hän lähtee, tai jos sinulla on vain paljon tehtävää tietyssä ohjelman osassa, huomaat, että projektisi tuskin etenee.

Ristikoulutus on yleensä tärkeä näkökohta yrityksissä, jotka yrittävät välttää tiedon keskittymistä yhteen henkilöön. Ihmisten siirtäminen koodin läpi yhdessä pariohjelmointi tekee Cross Trainingin huomaamattomasti puolestasi. Yhden henkilön sijaan, joka tietää kaiken tietystä koodista, kaikki tiimisi jäsenet tietävät paljon kunkin moduulin koodista.

Tiimi muuttuu paljon joustavammaksi, jos kaikki tietävät tarpeeksi kustakin järjestelmän osasta aloittaakseen työskentelyn. Sen sijaan, että odottaisit "gurun" valmistuvan kriittisen koodin parissa, useat ohjelmoijat voivat työskennellä sen parissa samanaikaisesti.

Uuden alussa iteraatioita jokaisen kehittäjän on siirryttävä uuteen tehtävään. Pariohjelmointi auttaa voittamaan käyttöönotto-ongelman (eli uusi kehittäjä voi muodostaa parin kokeneen kehittäjän kanssa).

Tämä käytäntö rohkaisee myös uusia ideoita ja parannettua koodia.

Jätä optimointi myöhempään käyttöön

Älä koskaan optimoi mitään ennen kuin koodaus on valmis. Älä koskaan yritä arvata, missä suorituskyvyn pullonkaulat ovat. Mitata!

Saat sen toimimaan, sitten toimimaan oikein ja sitten nopeasti.

Pariohjelmointi

Kaikki tuotantojärjestelmän koodit (eli kokeiluratkaisuja lukuun ottamatta) kirjoitetaan pareittain. Kaksi kehittäjää istuu vierekkäin. Toinen soittaa, toinen katselee. Ne muuttuvat aika ajoin. Yksin työskentely ei ole sallittua. Jos parin toiselta jostain syystä jäi jotain paitsi (hän ​​oli sairas, lähti pois jne.), hänen on tarkistettava kaikki ensimmäisen tekemät muutokset.

Kuulostaa epätavalliselta, mutta XP väittää, että lyhyen sopeutumisajan jälkeen useimmat ihmiset työskentelevät hyvin pareittain. He jopa pitävät siitä, koska työ tehdään huomattavasti nopeammin. Periaate "yksi pää on hyvä, mutta kaksi on parempi" pätee. Pariskunnat löytävät yleensä optimaalisempia ratkaisuja. Lisäksi koodin laatu paranee merkittävästi, virheiden määrä vähenee ja tiedon vaihto kehittäjien välillä nopeutuu.

Armottomasti Refaktoroi!

Meillä ohjelmoijat on tapana pysyä suunnittelussa kauan sen jälkeen, kun se on kömpelö. Käytämme jatkuvasti ylläpitämätöntä koodia, koska se toimii edelleen jotenkin ja pelkäämme pilaavan sen. Mutta onko siitä oikeasti hyötyä? XP katsoo, että tämä on kannattamatonta. Kun poistamme redundanssin, parannamme vanhentunutta suunnittelua, poistamme käyttämättömiä kappaleita - teemme refaktoroinnin. Refaktorointi säästää viime kädessä aikaa ja parantaa tuotteiden laatua.

Palaa hellittämättä mihin tahansa koodiin pitääksesi suunnittelun yksinkertaisena sen kehittyessä. Pidä koodi selkeänä ja ymmärrettävänä, jotta se on helppo ymmärtää, muokata ja laajentaa. Varmista, että kaikki on kirjoitettu kerran ja vain kerran. Viime kädessä se vie vähemmän aikaa kuin monimutkaisen järjestelmän tuominen mieleen.

Julkaisusuunnitelma

Vapautussuunnitelma laaditaan Julkaisusuunnittelukokouksessa. Julkaisusuunnitelmat kuvaavat näkymää koko projektista, ja niitä käytetään myöhemmin iteraatioiden suunnitteluun.

On tärkeää, että tekniset ihmiset tekevät teknisiä päätöksiä ja liikemiehet tekevät liikepäätöksiä. Julkaisusuunnittelu määrittelee joukon sääntöjä, joiden avulla jokainen voi tehdä omat päätöksensä. Nämä säännöt määrittelevät menetelmän laatia kaikkia tyydyttävä työsuunnitelma.

Kehitystiimin julkaisusuunnittelukokouksen ydin on arvioida jokainen käyttäjätarina ihanteellisilla viikkoilla. Ihanteellinen viikko on se, kuinka kauan uskot tehtävän suorittamiseen kuluvan, jos mikään muu ei häiritse sinua. Ei riippuvuuksia, ei lisätehtäviä, mutta mukaan lukien testit. Asiakas päättää sitten, mitkä tehtävät ovat tärkeimpiä tai korkeampia.

Käyttäjien tarinat kirjoitetaan korteille. Kehittäjät ja asiakas sekoittavat yhdessä kortteja pöydällä, kunnes saadaan joukko User Stories -paketteja, jotka yhdessä muodostavat ensimmäisen (tai seuraavan) julkaisun. Kaikki haluavat julkaista hyödyllisen järjestelmän, joka voidaan testata mahdollisimman pian.

Julkaisu voidaan ajoittaa ajan tai äänenvoimakkuuden mukaan. Käytä projektin nopeutta määrittääksesi, kuinka monta käyttäjätarinaa voidaan toteuttaa tiettyyn päivämäärään mennessä tai kuinka paljon reaaliaikaa tietty tehtäväryhmä vie. Jos suunnittelet ajoissa, kerro iteraatioiden määrä projektin nopeudella saadaksesi selville, kuinka monta User Storyä voidaan toteuttaa. Kun suunnittelet volyymin mukaan, jaa kaikille User Storiesille tarvittavien ihanteellisten viikkojen kokonaismäärä projektin nopeudella ja saat julkaisun suorittamiseen tarvittavan iteraatioiden määrän.

Jos johto ei ole tyytyväinen valmistumispäivään, saattaa olla houkuttelevaa alentaa laajuusarvioita. Sinun ei pitäisi koskaan tehdä tätä. Alhaiset arvosanat aiheuttavat varmasti paljon ongelmia myöhemmin. Sen sijaan neuvottele johtajien, kehittäjien ja asiakkaiden kanssa, kunnes sinulla on julkaisusuunnitelma, joka on kaikkien hyväksyttävä.

Säännölliset julkaisut

Kehittäjien tulee julkaista järjestelmän versioita käyttäjille (tai betatestaajille) niin usein kuin mahdollista.

Julkaisun suunnittelu käytetään etsimään pieniä toiminnallisuuksia, joilla on mielekästä liiketoimintaa ja jotka voidaan vapauttaa todelliseen maailmaan kehitysvaiheessa. Tämä on tärkeää hyödyllisen palautteen saamiseksi oikea-aikaisesti, jotta voimme vaikuttaa kehitysprosessiin. Mitä enemmän viivytät järjestelmän tärkeän osan julkaisemista, sitä vähemmän sinulla on aikaa korjata se.

kokeiluratkaisu

Luo kokeiluratkaisuja vastataksesi monimutkaisiin teknisiin kysymyksiin, perustellaksesi tiettyjä teknisiä ratkaisuja. Kaikissa teknologiapäätöksissä on riski, ja kokeiluratkaisut on suunniteltu vähentämään sitä.

Tee ohjelma, joka toistaa tutkittavana olevan ongelman ja jättää huomioimatta kaiken muun. Useimpia kokeiluratkaisuja ei ole tarkoitettu käytettäväksi myöhemmin, joten odota, että ne heitetään pois. Niiden luomisen tarkoituksena on vähentää riskiä tehdä väärä tekninen päätös tai arvioida tarkemmin User Storyn käyttöönottoaika.

Pysyvä kokous

Joka aamu on tapaaminen, jossa keskustellaan ongelmista, niiden ratkaisuista ja lisätään tiimin keskittymistä. Kokous pidetään seisoen, jotta vältytään pitkiltä keskusteluilta, jotka eivät kiinnosta kaikkia tiimin jäseniä.

Tyypillisessä kokouksessa useimmat osallistujat eivät osallistu mitään, osallistuvat vain kuullakseen, mitä muilla on sanottavaa. Suuri määrä ihmisten aikaa menee hukkaan pienen määrän viestintään vastaanottamiseen. Siksi kaikkien ihmisten osallistuminen kokouksiin vie resursseja projektilta ja luo kaaosta suunnitteluun.

Tällaista viestintää varten tarvitaan pysyvä kokous. On paljon parempi pitää yksi lyhyt pakollinen kokous kuin monta pitkää kokousta, joihin useimpien kehittäjien on joka tapauksessa osallistuttava.

Jos sinulla on päivittäin seisovia kokouksia, kaikkiin muihin kokouksiin tulisi osallistua vain niitä ihmisiä, joita tarvitaan ja jotka tuovat jotain. Lisäksi on mahdollista jopa välttää joitain tapaamisia. Kun osallistujia on rajoitetusti, useimmat kokoukset voidaan pitää spontaanisti monitorin edessä, jossa ajatustenvaihto on paljon intensiivisempaa.

Päivittäinen aamukokous ei ole pelkkää ajanhukkaa. Sen avulla voit välttää monia muita tapaamisia ja säästää enemmän aikaa kuin hukkaan heitettyä.

Järjestelmän metafora

Valitse aina System Metafor - yksinkertainen ja selkeä konsepti, jonka avulla tiimin jäsenet kutsuvat kaikkia asioita samalla nimellä. Objektien nimeäminen on erittäin tärkeää järjestelmän ymmärtämiseksi ja kaksoiskoodin välttämiseksi. Jos voit arvata minkä tahansa järjestelmän objektin nimen (jos tiedät mitä se tekee) ja sitä todella kutsutaan sellaiseksi, säästät paljon aikaa ja vaivaa. Luo objekteillesi nimijärjestelmä, jotta jokainen tiimin jäsen voi käyttää sitä ilman erityistä järjestelmän tuntemusta.

Yksikkötestit

Yksikkötesteillä on keskeinen rooli XP:ssä. Niiden avulla voit muuttaa koodia nopeasti ilman pelkoa uusien virheiden tekemisestä. Jokaiselle luokalle kirjoitetaan yksikkötesti, testin tulee testata kaikki luokan näkökohdat - testata kaikkea, mikä ei ehkä toimi.

Temppu tässä on, että luokan koe on kirjoitettava ennen itse luokkaa. Tämä tarkoittaa, että heti kun julkaiset ensimmäisen työtuloksen, testausjärjestelmä tukee sitä. Testien suorittamista varten kirjoitetaan erityinen testausjärjestelmä omalla käyttöliittymällään.

Luokan yksikkötesti tallennetaan jaettuun arkistoon luokkakoodin kanssa. Mitään koodia ei voida vapauttaa ilman yksikkötestiä. Ennen koodin lähettämistä kehittäjän on varmistettava, että kaikki testit läpäisivät virheettömästi. Kukaan ei voi antaa koodia, jos kaikki eivät ole läpäisseet 100%. Toisin sanoen, koska kaikki testit läpäisivät ennen muutoksiasi, jos sinulla on virheitä, tämä on muutosten tulos. Sinä ja oikein. Joskus testikoodi on virheellinen tai puutteellinen. Siinä tapauksessa sinun on korjattava se.

Valtava houkutus on säästää yksikkötesteissä, kun aikaa on vähän. Mutta huijaat vain itseäsi tällä. Mitä vaikeampaa kokeen kirjoittaminen on, sitä enemmän aikaa säästyy myöhemmin. Tämä on käytännössä todistettu.

Yksikkötestit mahdollistavat koodin kollektiivisen omistamisen. Niiden avulla on suhteellisen helppoa palata huonoon koodiin. Yksikkötestien avulla voit myös saada vakaan toimintajärjestelmän milloin tahansa.

Käyttäjän tarina

User Story (jokin käyttäjätarina) on kuvaus siitä, kuinka järjestelmän pitäisi toimia. Jokainen käyttäjätarina on kirjoitettu kortille ja edustaa jotakin järjestelmän toiminnallisuutta, joka on loogista Asiakkaan näkökulmasta. Muoto - yksi tai kaksi kappaletta tekstiä, joka on käyttäjän ymmärrettävissä (ei kovin tekninen).

Käyttäjätarina on asiakkaan kirjoittama. Ne ovat samanlaisia ​​kuin järjestelmän käyttötapaukset, mutta eivät rajoitu käyttöliittymään. Jokaiselle tarinalle kirjoitetaan toiminnalliset testit sen varmistamiseksi, että tämä tarina on toteutettu oikein - niitä kutsutaan myös hyväksymistesteiksi.

Liiketoiminta (käyttäjä, asiakas, markkinointiosasto) asettaa kullekin käyttäjätarinalle prioriteetin ja kehittäjät arvioivat sen läpimenoajan. Jokainen tarina on jaettu tehtäviin ja sille on varattu aika, jolloin se toteutetaan.

XP:ssä käytetään käyttäjätarinoita perinteisten vaatimusten sijaan. Suurin ero User Storyn ja vaatimusten välillä on yksityiskohtaisuus. User Story sisältää vähimmäistiedot, joita tarvitaan kohtuullisen arvion tekemiseen siitä, kuinka kauan sen käyttöönotto kestää.

Tyypillinen User Story kestää 1-3 viikkoa ihanteellisesti. Tarina, joka vaatii alle viikon, on liian yksityiskohtainen. Yli 3 viikkoa vaativa tarina voidaan jakaa osiin – erillisiin tarinoihin.

Projektin nopeus

Projektin nopeus (tai yksinkertaisesti nopeus) on mitta siitä, kuinka nopeasti projektisi tehdään.

Projektin nopeuden mittaamiseksi sinun on yksinkertaisesti laskettava käyttäjätarinoiden määrä tai kuinka monta (ajassa mitattuna) tehtävää suoritettiin iteraatiota kohti. Laske vain kokonaisaika arvioidaksesi työn määrän (ihanne aika).

Julkaisusuunnittelun aikana projektin nopeutta käytetään arvioimaan kuinka monta käyttäjätarinaa voidaan tehdä.

Iteraatiosuunnittelun aikana projektin nopeutta edellisessä iteraatiossa käytetään määrittämään, kuinka monta käyttäjätarinaa nykyiselle iteraatiolle suunnitellaan.

Tämän yksinkertaisen mekanismin avulla kehittäjät voivat toipua vaikeasta iteraatiosta. Jos sinulla on vielä vapaata aikaa kunnostuksen jälkeen, mene asiakkaan luo ja pyydä toinen käyttäjätarina. Tämän seurauksena nopeus kasvaa jälleen.

Tätä parametria ei tarvitse käyttää absoluuttisena. Se ei sovellu kahden projektin tuottavuuden vertailuun, koska jokaisella tiimillä on omat ominaisuutensa. Tämä parametri on tärkeä vain, jotta joukkue pitää sen "tasaisessa kölissä".

Sinun pitäisi odottaa pieniä muutoksia projektin nopeuteen työskennellessäsi. Mutta jos nopeus muuttuu paljon, sinun on ajoitettava julkaisu uudelleen. Heti kun uusi järjestelmä siirtyy käyttäjille, odota projektin nopeuden muuttuvan, kun sinulla on tukitehtäviä.

Kun virhe löytyy

Jos virhe löytyy, luodaan testi sen toistumisen estämiseksi. Tuotantojärjestelmässä (jo asennettu) ilmennyt virhe vaatii toimintatestin kirjoittamisen. Toiminnallisen testin luominen juuri ennen vian diagnosointia antaa asiakkaille mahdollisuuden kuvata ongelmaa selkeästi ja ilmoittaa ongelmasta kehittäjille.

Epäonnistunut toimintatesti on luotava yksikkötesti. Tämä auttaa keskittymään virheenkorjauspyrkimyksiin ja osoittaa selvästi, kun virhe on korjattu.

Et tarvitse sitä

Vältä täyttämästä järjestelmää asioilla, joita tarvitset tulevaisuudessa. Vain 10 % odotuksistasi todella tarvitaan alkuperäisessä muodossaan, eli 90 % ajasta menee hukkaan.

Aina on houkutus lisätä toimintoja nyt eikä myöhemmin, koska näemme kuinka se lisätään nyt ja uskomme, että järjestelmä tulee olemaan paljon parempi. Mutta meidän on aina muistutettava itseämme, että emme koskaan tarvitse sitä. Lisätoiminnot vain hidastavat edistymistä ja syövät resursseja. Unohda tulevat vaatimukset ja lisäjoustavuus. Keskity siihen, mitä nyt on tehtävä.

XP:n perustemppuja

Ääriohjelmoinnin kaksitoista perustekniikkaa (kirjan ensimmäisen painoksen mukaan Extreme ohjelmointi selitetty) voidaan jakaa neljään ryhmään:

  • Lyhyt palautesilmukka (hieno mittakaavapalaute)
    • Kehitys testaamalla (testilähtöinen kehitys)
    • Pelin suunnittelu
    • Asiakas on aina paikalla (koko tiimi, asiakas paikan päällä)
    • Pariohjelmointi
  • Jatkuva, ei eräprosessi
    • Jatkuva integraatio
    • Refaktorointi (suunnittelun parantaminen, uudelleentekijä)
    • Säännölliset pienet julkaisut
  • Kaikille yhteinen ymmärrys
    • Yksinkertaisuus
    • Järjestelmän metafora
    • Koodin kollektiivinen omistajuus tai valitut suunnittelumallit (kollektiivisten mallien omistus)
    • Koodausstandardi tai koodauskäytännöt
  • Ohjelmoijan hyvinvointi:
    • 40 tunnin työviikko (kestävä tahti, 40 tunnin viikko)

Testaus

XP keskittyy kahdentyyppiseen testaukseen:

  • yksikkö testaus;
  • hyväksyntätestaus.

Kehittäjä ei voi olla varma kirjoittamansa koodin oikeellisuudesta ennen kuin ehdottoman kaikki hänen kehittämänsä järjestelmän yksikkötestit toimivat. Yksikkötestien avulla kehittäjät voivat varmistaa, että heidän koodinsa toimii oikein. Ne auttavat myös muita kehittäjiä ymmärtämään, miksi tiettyä koodia tarvitaan ja miten se toimii. Yksikkötestien avulla kehittäjä voi myös reagoida ilman pelkoa.

Hyväksymistestien avulla voit varmistaa, että järjestelmällä todella on ilmoitetut ominaisuudet. Lisäksi hyväksyntätestien avulla voit tarkistaa kehitetyn tuotteen oikean toiminnan.

XP:ssä TDD (Test Driven Development) -niminen lähestymistapa on prioriteetti - ensin kirjoitetaan testi, joka ei läpäise, sitten koodi kirjoitetaan niin, että testi läpäisee, ja sen jälkeen koodi faktoroidaan uudelleen.

Suunnittelupeli

Suunnittelupelin päätavoitteena on muodostaa nopeasti karkea työsuunnitelma ja päivittää sitä jatkuvasti tehtävän ehtojen selkiytyessä. Suunnittelupelin artefakteja ovat joukko paperikortteja, jotka sisältävät asiakkaan toiveet (asiakastarinat) ja karkean työsuunnitelman tuotteen seuraavan yhden tai useamman pienen version julkaisua varten. Kriittinen tekijä, joka tekee tästä suunnittelutyylistä tehokkaan, on se, että tässä tapauksessa asiakas on vastuussa liiketoiminnallisista päätöksistä ja kehitystiimi teknisistä päätöksistä. Jos tätä sääntöä ei noudateta, koko prosessi hajoaa.

Asiakas on aina paikalla

XP:n "asiakas" ei ole se, joka maksaa laskut, vaan ohjelmistotuotteen loppukäyttäjä. XP väittää, että asiakkaan on oltava koko ajan yhteydessä ja käytettävissä kysymyksiin.

Pariohjelmointi

Pariohjelmointi oletetaan, että kaikki koodit ovat samassa tietokoneessa työskentelevien ohjelmoijaparien luomia. Toinen heistä työskentelee suoraan ohjelman tekstin kanssa, toinen katselee työtään ja seuraa kokonaiskuvaa siitä, mitä tapahtuu. Tarvittaessa näppäimistö siirtyy vapaasti toisesta toiseen. Projektin parissa työskennellessä parit eivät ole kiinteät: ne on suositeltavaa sekoittaa, jotta jokaisella tiimin ohjelmoijalla on hyvä käsitys koko järjestelmästä. Siten pariohjelmointi tehostaa vuorovaikutusta tiimin sisällä.

Jatkuva integraatio

Jos integroit järjestelmäsi riittävän usein, voit välttää useimmat siihen liittyvät ongelmat. Perinteisissä menetelmissä integrointi suoritetaan pääsääntöisesti tuotteen työskentelyn lopussa, kun katsotaan, että kaikki kehitettävän järjestelmän komponentit ovat täysin valmiita. XP:ssä koko järjestelmän koodiintegrointi suoritetaan useita kertoja päivässä, sen jälkeen kun kehittäjät ovat varmistaneet, että kaikki yksikkötestit toimivat oikein.

Refaktorointi

Refaktorointi on tekniikka koodin parantamiseksi muuttamatta sen toimintoja. XP tarkoittaa, että kun koodi on kirjoitettu, se melkein varmasti uusitaan monta kertaa projektin aikana. XP-kehittäjät muokkaavat armottomasti aiemmin kirjoitettua koodia parantaakseen sitä. Tätä prosessia kutsutaan refaktorointiksi. Testin kattavuuden puute provosoi refaktoroinnin hylkäämisen järjestelmän rikkoutumisen pelosta, mikä johtaa koodin asteittaiseen huononemiseen.

Pienet julkaisut usein

Tuotteen versiot (julkaisut) tulee ottaa tuotantoon mahdollisimman usein. Kunkin version käsittelyn tulisi kestää mahdollisimman vähän aikaa. Samanaikaisesti jokaisen version tulee olla riittävän merkityksellinen liiketoiminnalle.

Mitä nopeammin julkaisemme tuotteen ensimmäisen toimivan version, sitä nopeammin asiakas alkaa saada siitä lisätuottoa. Muista, että tänään ansaittu raha on arvokkaampaa kuin huomenna ansaittu raha. Mitä nopeammin asiakas aloittaa tuotteen käytön, sitä nopeammin kehittäjät saavat häneltä tietoa siitä, mikä vastaa asiakkaan vaatimuksia. Nämä tiedot voivat olla erittäin hyödyllisiä seuraavan julkaisun suunnittelussa.

Suunnittelun yksinkertaisuus

XP lähtee siitä, että työn aikana ongelman olosuhteet voivat muuttua toistuvasti, mikä tarkoittaa, että kehitettävää tuotetta ei tule suunnitella etukäteen kokonaan ja täydellisesti. Jos jo työn alussa yrität suunnitella järjestelmän yksityiskohtaisesti alusta loppuun, hukkaat aikaasi. XP ehdottaa, että suunnittelu on niin tärkeä prosessi, että sitä on tehtävä jatkuvasti koko projektin elinkaaren ajan. Suunnittelu tulee tehdä pienin askelin jatkuvasti muuttuvat vaatimukset huomioon ottaen. Pyrimme joka hetki käyttämään yksinkertaisinta nykyiseen tehtävään sopivaa suunnittelua. Samalla muutamme sitä ongelman olosuhteiden muuttuessa.

Järjestelmän metafora

Arkkitehtuuri on esitys järjestelmän osista ja niiden keskinäisistä suhteista. Kehittäjien on analysoitava ohjelmistoarkkitehtuuria ymmärtääkseen, mihin järjestelmään heidän on lisättävä uusia toimintoja ja minkä kanssa uusi komponentti on vuorovaikutuksessa.

Järjestelmän metafora on analoginen sen kanssa, mitä useimmat tekniikat kutsuvat arkkitehtuuriksi. Järjestelmämetafora antaa tiimille käsityksen siitä, miten järjestelmä tällä hetkellä toimii, mihin uusia komponentteja lisätään ja missä muodossa niiden tulisi olla.

Hyvän metaforan valitseminen auttaa kehitystiimiä ymmärtämään järjestelmän toimintaa. Joskus tämä ei ole helppoa.

Koodausstandardit

Kaikkien tiimin jäsenten tulee noudattaa yhteisten koodausstandardien vaatimuksia työssään. Siten:

  • tiimin jäsenet eivät tuhlaa aikaa typeriin väittelyihin asioista, jotka eivät itse asiassa vaikuta projektin työn nopeuteen;
  • muiden käytäntöjen tehokas toteuttaminen varmistetaan.

Jos tiimi ei käytä yhtenäisiä koodausstandardeja, kehittäjien on vaikeampi reagoida uudelleen. kun vaihdat kumppaneita pareittain, on enemmän vaikeuksia; yleisesti ottaen projektin eteneminen on vaikeaa. XP:n puitteissa on varmistettava, että on vaikea ymmärtää, kuka on tämän tai toisen koodin kirjoittaja - koko tiimi toimii yhtenäisellä tavalla, kuin yksi henkilö. Ryhmän on muodostettava säännöt, ja jokaisen tiimin jäsenen on noudatettava näitä sääntöjä koodausprosessin aikana. Sääntöluettelo ei saa olla tyhjentävä tai liian laaja. Tehtävänä on muotoilla yleiset ohjeet, jotka tekevät koodista ymmärrettävän jokaiselle tiimin jäsenelle. Koodausstandardin tulee olla aluksi yksinkertainen, sitten se voi vähitellen muuttua monimutkaisemmaksi, kun kehitystiimi saa kokemusta. Standardin laatimiseen ei tarvitse käyttää liikaa aikaa.

Yhteinen omistus

Yhteinen omistus tarkoittaa, että jokainen tiimin jäsen on vastuussa kaikesta lähdekoodista. Näin ollen jokaisella on oikeus tehdä muutoksia mihin tahansa ohjelman osaan. Pariohjelmointi tukee tätä käytäntöä: työskentelemällä eri pareissa kaikki ohjelmoijat tutustuvat kaikkiin järjestelmän koodin osiin. Koodin kollektiivisen omistajuuden tärkeä etu on, että se nopeuttaa kehitysprosessia, koska virheen sattuessa kuka tahansa ohjelmoija voi korjata sen.

Antamalla jokaiselle ohjelmoijalle oikeuden muuttaa koodia, otamme riskin, että ohjelmoijat, jotka luulevat tietävänsä mitä tekevät, mutta eivät ota huomioon joitain riippuvuuksia, aiheuttavat virheitä. Hyvin määritellyt UNIT-testit ratkaisevat tämän ongelman: jos tarkistamattomat riippuvuudet aiheuttavat virheitä, seuraava UNIT-testien ajo epäonnistuu.

Kirjallisuus

  • Kent Beck: Extreme ohjelmointi- Peter, 2002, ISBN 5-94723-032-1.
  • Kent Beck, Martin Fowler: Äärimmäinen ohjelmointi: Suunnittelu- Peter, 2003, ISBN 5-318-00111-4.
  • Kent Beck: Äärimmäinen ohjelmointi: Testilähtöinen kehitys- Peter, 2003, ISBN 5-8046-0051-6.
  • Ken Auer, Roy Miller: "Ääriohjelmointi: prosessin asettaminen alusta loppuun" - Peter, 2003, ISBN 5-318-00132-7.

Katso myös

Linkit

  • Ward Cunningham Wiki (englanniksi) - "cutting edge" XP.
  • XProgramming.com (englanniksi) - Ron Jeffreysin verkkosivusto: artikkeleita ja resursseja XP:stä ja vastaavista aiheista, kirja-arvostelut.
  • Äärimmäinen ohjelmointi: lempeä johdanto
  • MAXKIR.COM (venäjä) - XP:n perustajien ja ideologien artikkelien käännökset
  • www.agiledev.ru (rus.) - Ketterä kehityssivusto
  • TopCoder (englanniksi) - urheiluohjelmointikilpailu
  • Sähköinen kirjasto Extreme Programming -kirjoista (venäjäksi)
  • Extreme-ohjelmointi – todellisuus ja myytit (venäjä)
  • Testaus äärimmäisen ohjelmoinnin valossa. Osa 1 (venäjä)
  • IT ja psykologia. Pariohjelmoinnin inhimillinen tekijä: miksi monet eivät saa sen toteutuksesta mitä haluavat? (Venäjän kieli)

Wikimedia Foundation. 2010 .

Katso, mitä "Extreme Programming" on muissa sanakirjoissa:

    äärimmäinen ohjelmointi- Yksi ohjelmistokehityksen menetelmistä. Aiheet tietotekniikka yleisesti FI extreme-ohjelmointiXP ... Teknisen kääntäjän käsikirja

    Tämä artikkeli on kirjoitettava kokonaan uudelleen. Keskustelusivulla voi olla selityksiä. Tällä termillä on muita merkityksiä, katso Ohjelmat ... Wikipedia

    Extreme Project Management (XPM) on tapa hallita erittäin monimutkaisia ​​tai epävarmoja projekteja. XPM eroaa perinteisistä projektinhallintamenetelmistä olemalla avoin, joustava ja ... ... Wikipedia

Aiheeseen liittyvät julkaisut: