Äärimmäinen ohjelmointi - Extreme programming

Suunnittelu- ja palautesilmukat äärimmäisessä ohjelmoinnissa
Ohjelmistokehitys
Keskeiset toiminnot
Paradigmat ja mallit
Menetelmät ja puitteet
Tukea tieteenaloja
Käytännöt
Työkalut
Standardit ja tietämykset
Sanastot
Ääriviivat

Extreme -ohjelmointi ( XP ) on ohjelmistokehitysmenetelmä, jonka tarkoituksena on parantaa ohjelmiston laatua ja reagointia muuttuviin asiakkaiden vaatimuksiin. Eräänlaisena ketterän ohjelmistokehityksen , se kannattaa usein "tiedotteet" Lyhyesti kehitysvaiheet, jonka tarkoituksena on parantaa tuottavuutta ja ottaa käyttöön tarkastuspisteitä, joilla uudet asiakkaan vaatimukset voidaan hyväksyä.

Muita äärimmäisen ohjelmoinnin elementtejä ovat: pareittain ohjelmointi tai laajan koodin tarkistaminen , kaikkien koodien yksikkötestaus , ei ohjelmointiominaisuuksia, ennen kuin niitä todella tarvitaan , tasainen hallintarakenne, koodin yksinkertaisuus ja selkeys, odotettavissa olevat muutokset asiakkaan vaatimuksissa ajan kuluessa ja ongelma ymmärretään paremmin, ja usein kommunikoidaan asiakkaan ja ohjelmoijien kanssa. Menetelmä on saanut nimensä ajatuksesta, että perinteisten ohjelmistosuunnittelukäytäntöjen hyödylliset elementit viedään "äärimmäiselle" tasolle. Esimerkkinä koodikatselmuksia pidetään hyödyllisenä käytännönä; äärimmilleen, koodia voidaan tarkastella jatkuvasti (eli pariohjelmointi ).

Historia

Kent Beck kehitetty extreme programming hänen työstään Chrysler Comprehensive kompensointi (C3) palkkasumma projekti . Beckistä tuli C3 -projektin johtaja maaliskuussa 1996. Hän alkoi tarkentaa projektissa käytettyjä kehittämismenetelmiä ja kirjoitti metodologiasta kirjan ( Extreme Programming Explained , julkaistu lokakuussa 1999). Chrysler peruutti C3-hankkeen helmikuussa 2000 seitsemän vuoden kuluttua, kun Daimler-Benz osti yrityksen. Ward Cunningham oli toinen merkittävä vaikutus XP: hen.

Monet äärimmäisen ohjelmointikäytännöt ovat olleet käytössä jo jonkin aikaa; Menetelmä vie " parhaat käytännöt " äärimmäiselle tasolle. Esimerkiksi "kokeilua edeltävän kehityksen, suunnittelun ja kirjoittamisen testejä ennen jokaista mikrolisäystä" käytettiin jo NASA: n Mercury - projektissa , 1960-luvun alussa. Kokonaiskehitysajan lyhentämiseksi on kehitetty joitakin muodollisia testiasiakirjoja (kuten hyväksyntätestausta varten ) samanaikaisesti (tai vähän ennen) ohjelmiston testausvalmiutta. NASAn riippumaton testiryhmä voi kirjoittaa testimenettelyt muodollisten vaatimusten ja loogisten rajojen perusteella, ennen kuin ohjelmoijat kirjoittavat ohjelmiston ja integroivat sen laitteistoon. XP vie tämän käsitteen äärimmäiselle tasolle ja kirjoittaa automaattisia testejä (joskus ohjelmistomoduulien sisällä), jotka vahvistavat jopa pienien ohjelmistokoodausten toiminnan sen sijaan, että testaisivat vain suurempia ominaisuuksia.

Alkuperät

Kaksi suurta vaikuttajaa muokkasivat ohjelmistokehitystä 1990 -luvulla:

Nopeasti muuttuvat vaatimukset vaativat lyhyempiä elinkaareja , ja ne olivat usein ristiriidassa perinteisten ohjelmistokehitysmenetelmien kanssa.

Chrysler Kattava kompensointi (C3) alkoi, jotta voidaan määrittää paras tapa käyttää esinettä teknologiaa käyttäen palkkausjärjestelmiä Chrysler objektina liittyvinä Smalltalk kielenä ja jalokivi kuin tietojen saatavuutta kerros . Chrysler kutsui Kent Beckin , merkittävän Smalltalk -harjoittajan, suorittamaan järjestelmän suorituskyvyn virityksen , mutta hänen roolinsa laajeni, kun hän huomasi useita kehitysprosessin ongelmia. Hän käytti tätä tilaisuutta hyväkseen ja ehdotti joitain muutoksia kehityskäytäntöihin - perustuen työhönsä usein yhteistyökumppaninsa Ward Cunninghamin kanssa . Beck kuvaa menetelmien varhaista käsitystä:

Ensimmäistä kertaa, kun minua pyydettiin johtamaan tiimiä, pyysin heitä tekemään vähän asioita, joita pidin järkevinä, kuten testaus ja arvostelut. Toisella kerralla linjalla oli paljon enemmän. Ajattelin: "Hitto torpedot, ainakin tästä tulee hyvä artikkeli", [ja] pyysin tiimiä kääntämään kaikki nupit 10: een asioista, joita pidin välttämättöminä, ja jättämään kaiken muun pois.

Beck kutsui Ron Jeffriesin projektiin auttamaan kehittämään ja parantamaan näitä menetelmiä. Jeffries toimi sen jälkeen valmentajana, joka kasvatti harjoituksia tottumuksina C3 -tiimiin.

Tietoja XP: n periaatteista ja käytännöistä levitettiin laajemmalle maailmalle keskusteluilla alkuperäisestä wikistä , Cunninghamin WikiWikiWebistä . Eri kirjoittajat keskustelivat ideoista ja laajensivat niitä, ja tuloksena oli joitakin spin-off-menetelmiä (ks. Ketterä ohjelmistokehitys ). Lisäksi XP -käsitteitä on selitetty useiden vuosien ajan käyttämällä hypertekstijärjestelmäkarttaa XP -verkkosivustolla osoitteessa http://www.extremeprogramming.org noin vuonna 1999.

Beck toimitti XP: llä kirjoja, alkaen omasta Extreme Programming Explained (1999, ISBN  0-201-61641-6 ) ja levitti ideoitaan paljon suuremmalle yleisölle. Sarjan tekijät kävivät läpi erilaisia ​​näkökohtia XP: ssä ja sen käytännöissä. Sarja sisälsi käytännön kriittisen kirjan.

Nykyinen tila

XP herätti suurta kiinnostusta ohjelmistoyhteisöjen keskuudessa 1990 -luvun lopulla ja 2000 -luvun alussa.

Alkuperäisten käytäntöjen vaatima korkea kurinalaisuus meni usein sivuraiteille, minkä seurauksena jotkut näistä käytännöistä, kuten liian jäykät, pidettiin vanhentuneina tai vähennetyinä tai jopa jätettiin kesken kesken yksittäisillä sivustoilla. Esimerkiksi tietyn projektin päivän lopun integrointitestien käytäntö voitaisiin muuttaa viikon lopun aikatauluksi tai yksinkertaisesti rajoittaa testaukseen yhteisesti sovituina päivinä. Tällainen rennompi aikataulu voisi välttää sen, että ihmiset tuntevat kiirettä keinotekoisten tynkien luomiseen vain päivän lopun testauksen läpäisemiseksi. Vähemmän jäykkä aikataulu mahdollistaa sen sijaan monimutkaisten ominaisuuksien kehittämisen usean päivän aikana.

Samaan aikaan muut ketterän kehityksen käytännöt eivät ole pysähtyneet, ja vuodesta 2019 lähtien XP kehittyy edelleen ja kokee enemmän kokemuksia alan kokemuksista muiden käytäntöjen käyttämiseksi. Extreme Programming Explainedin toisessa painoksessa (marraskuu 2004), viisi vuotta ensimmäisen painoksen jälkeen, Beck lisäsi enemmän arvoja ja käytäntöjä ja erotti toisistaan ​​ensisijaiset ja seuraavat käytännöt.

Konsepti

Tavoitteet

Extreme Programming Explained kuvaa äärimmäistä ohjelmointia ohjelmistokehityksen kurinalaisuutena, joka järjestää ihmiset tuottamaan laadukkaampia ohjelmistoja tuottavammin.

XP yrittää alentaa vaatimusten muutosten kustannuksia ottamalla useita lyhyitä kehityssyklejä pitkän sijasta. Tässä opissa muutokset ovat luonnollinen, väistämätön ja toivottava osa ohjelmistokehityshankkeita, ja ne olisi suunniteltava sen sijaan, että yritettäisiin määritellä vakaa vaatimusten joukko.

Äärimmäinen ohjelmointi tuo ketterän ohjelmointikehyksen päälle myös useita perusarvoja, periaatteita ja käytäntöjä.

Aktiviteetit

XP kuvaa neljä ohjelmistotoiminnan perustoimintoa: koodaus, testaus, kuuntelu ja suunnittelu. Jokainen näistä toiminnoista on kuvattu alla.

Koodaus

XP: n kannattajat väittävät, että järjestelmän kehittämisprosessin ainoa todella tärkeä tuote on koodi - ohjelmisto -ohjeet, jotka tietokone voi tulkita. Ilman koodia ei ole toimivaa tuotetta.

Koodauksen avulla voidaan löytää sopivin ratkaisu. Koodaus voi myös auttaa kommunikoimaan ajatuksia ohjelmointiongelmista. Ohjelmoija, joka käsittelee monimutkaista ohjelmointiongelmaa tai jonka on vaikea selittää ratkaisua muille ohjelmoijille, saattaa koodata sen yksinkertaistetusti ja käyttää koodia osoittaakseen, mitä he tarkoittavat. Koodit, sanovat tämän kannan kannattajat, ovat aina selkeitä ja ytimekkäitä, eikä niitä voida tulkita useammalla kuin yhdellä tavalla. Muut ohjelmoijat voivat antaa palautetta tästä koodista myös koodaamalla ajatuksiaan.

Testaus

Pääartikkeli: Testivetoinen kehitys

Testaus on keskeistä äärimmäisessä ohjelmoinnissa. Äärimmäisen ohjelmoinnin lähestymistapa on, että jos pieni testaus voi poistaa muutaman puutteen, paljon testausta voi poistaa monia muita virheitä.

  • Yksikkötestit määrittävät, toimiiko tietty ominaisuus aiotulla tavalla. Ohjelmoijat kirjoittavat niin monta automaattista testiä kuin voivat ajatella, mikä saattaa "rikkoa" koodin; Jos kaikki testit suoritetaan onnistuneesti, koodaus on valmis. Jokainen kirjoitettu koodi testataan ennen siirtymistä seuraavaan ominaisuuteen.
  • Hyväksyntätestit varmistavat, että ohjelmoijien ymmärtämät vaatimukset täyttävät asiakkaan todelliset vaatimukset.

Järjestelmän laajuista integraatiotestausta kannustettiin aluksi päivittäisenä päivän päätteeksi yhteensopimattomien rajapintojen varhaiseen havaitsemiseen, jotta yhteys muodostettaisiin uudelleen, ennen kuin erilliset osiot poikkesivat laajasti johdonmukaisesta toiminnasta. Järjestelmän laajuinen integraatiotestaus on kuitenkin lyhennetty viikoittain tai harvemmin järjestelmän yleisten rajapintojen vakauden mukaan.

Kuunteleminen

Ohjelmoijien on kuunneltava, mitä asiakkaat tarvitsevat järjestelmän tehdä, mitä " liiketoimintalogiikkaa " tarvitaan. Heidän on ymmärrettävä nämä tarpeet riittävän hyvin voidakseen antaa asiakkaalle palautetta teknisistä näkökohdista, joilla ongelma voidaan ratkaista tai ei voida ratkaista. Suunnittelupelissä käsitellään edelleen asiakkaan ja ohjelmoijan välistä viestintää .

Suunnittelu

Yksinkertaisuuden kannalta voidaan tietysti sanoa, että järjestelmän kehittäminen ei vaadi muuta kuin koodausta, testaamista ja kuuntelua. Jos nämä toiminnot suoritetaan hyvin, tuloksena tulee aina olla toimiva järjestelmä. Käytännössä tämä ei toimi. Suunnittelematta voi tulla pitkälle, mutta jossakin vaiheessa jää jumiin. Järjestelmä muuttuu liian monimutkaiseksi ja järjestelmän sisäiset riippuvuudet lakkaavat olemasta selviä. Tämän voi välttää luomalla suunnittelurakenteen, joka järjestää järjestelmän logiikan. Hyvä suunnittelu välttää monia riippuvuuksia järjestelmässä; tämä tarkoittaa, että yhden järjestelmän osan muuttaminen ei vaikuta järjestelmän muihin osiin.

Arvot

Äärimmäinen ohjelmointi tunnisti alun perin neljä arvoa vuonna 1999: viestintä, yksinkertaisuus, palaute ja rohkeus. Uusi arvo, kunnioitus, lisättiin Extreme Programming Explainedin toiseen painokseen . Nämä viisi arvoa on kuvattu alla.

Viestintä

Ohjelmistojärjestelmien rakentaminen edellyttää järjestelmävaatimusten ilmoittamista järjestelmän kehittäjille. Muodollisissa ohjelmistokehitysmenetelmissä tämä tehtävä suoritetaan dokumentaation avulla. Äärimmäisiä ohjelmointitekniikoita voidaan pitää menetelminä institutionaalisen tiedon nopeaan rakentamiseen ja levittämiseen kehitysryhmän jäsenten kesken. Tavoitteena on antaa kaikille kehittäjille jaettu näkemys järjestelmästä, joka vastaa järjestelmän käyttäjien näkemystä. Tätä varten äärimmäinen ohjelmointi suosii yksinkertaisia ​​malleja, yleisiä vertauskuvia, käyttäjien ja ohjelmoijien yhteistyötä, toistuvaa suullista viestintää ja palautetta.

Yksinkertaisuus

Äärimmäinen ohjelmointi kannustaa aloittamaan yksinkertaisimmasta ratkaisusta. Lisätoimintoja voidaan sitten lisätä myöhemmin. Ero tämän lähestymistavan ja tavanomaisempien järjestelmäkehitysmenetelmien välillä on keskittyminen nykypäivän tarpeiden suunnitteluun ja koodaamiseen huomisen, seuraavan viikon tai seuraavan kuukauden tarpeiden sijasta. Tämä kiteytetään joskus " Et tarvitse sitä " (YAGNI) lähestymistapana. XP: n kannattajat tunnustavat sen haittapuolen, että tämä voi toisinaan vaatia enemmän ponnisteluja järjestelmän muuttamiseksi. He väittävät, että tämä on enemmän kuin kompensoitu sillä, että ei investoida mahdollisiin tuleviin vaatimuksiin, jotka saattavat muuttua ennen kuin niistä tulee merkityksellisiä. Koodaus ja suunnittelu epävarmoille tulevaisuuden vaatimuksille merkitsevät riskiä käyttää resursseja johonkin, jota ei ehkä tarvita, mutta ehkä viivyttää tärkeitä ominaisuuksia. "Viestintä" -arvoon liittyen suunnittelun ja koodauksen yksinkertaisuuden pitäisi parantaa viestinnän laatua. Useimmat tiimin ohjelmoijat ymmärtävät helposti yksinkertaisen rakenteen ja erittäin yksinkertaisen koodin.

Palaute

Äärimmäisessä ohjelmoinnissa palaute liittyy järjestelmän kehittämisen eri ulottuvuuksiin:

  • Palaute järjestelmästä: kirjoittamalla yksikkötestejä tai suorittamalla säännöllisiä integrointitestejä, ohjelmoijat saavat suoraa palautetta järjestelmän tilasta muutosten toteuttamisen jälkeen.
  • Palaute asiakkaalta: Toiminnalliset testit (eli hyväksymistestit ) ovat asiakkaan ja testaajien kirjoittamia. He saavat konkreettista palautetta järjestelmänsä nykytilasta. Tämä tarkastelu on suunniteltu kerran kahdessa tai kolmessa viikossa, jotta asiakas voi helposti ohjata kehitystä.
  • Palaute tiimiltä: Kun asiakkaat esittävät uusia vaatimuksia suunnittelupelissä, tiimi antaa suoraan arvion toteutuksesta.

Palaute liittyy läheisesti viestintään ja yksinkertaisuuteen. Järjestelmän puutteista on helppo ilmoittaa kirjoittamalla yksikkötesti, joka osoittaa, että tietty koodinpätkä rikkoutuu. Järjestelmän suora palaute kehottaa ohjelmoijia koodaamaan tämän osan uudelleen. Asiakas voi testata järjestelmää säännöllisesti toiminnallisten vaatimusten mukaisesti, joita kutsutaan käyttäjätarinoiksi . Kent Beckiä lainaten: "Optimismi on ohjelmoinnin ammatillinen vaara. Palaute on hoito."

Rohkeutta

Useat käytännöt ilmentävät rohkeutta. Yksi on käsky suunnitella ja koodata aina tänään eikä huomiselle. Tällä pyritään välttämään suunnittelun juuttuminen ja vaatimaan paljon vaivaa kaiken muun toteuttamiseksi. Rohkeuden avulla kehittäjät voivat tuntea olonsa mukavaksi muokata koodiaan tarvittaessa. Tämä tarkoittaa nykyisen järjestelmän tarkistamista ja muuttamista, jotta tulevat muutokset voidaan toteuttaa helpommin. Toinen esimerkki rohkeudesta on tietää, milloin heittää koodi pois: rohkeus poistaa vanhentunut lähdekoodi, riippumatta siitä, kuinka paljon vaivaa on käytetty kyseisen lähdekoodin luomiseen. Rohkeus tarkoittaa myös sinnikkyyttä: ohjelmoija saattaa olla jumissa monimutkaisessa ongelmassa koko päivän, sitten ratkaista ongelman nopeasti seuraavana päivänä, mutta vain jos he ovat pysyviä.

Kunnioittaminen

Kunnioitusarvo sisältää muiden kunnioittamisen sekä itsekunnioituksen. Ohjelmoijien ei pitäisi koskaan tehdä muutoksia, jotka rikkovat kokoamisen, tekevät nykyiset yksikkötestit epäonnistuneiksi tai viivästyttävät vertaistensa työtä. Jäsenet kunnioittavat omaa työtään pyrkimällä aina korkeaan laatuun ja etsimällä parhaan mahdollisen suunnittelun ratkaisulle.

Neljän aikaisemman arvon omaksuminen johtaa muiden tiimin jäsenten saamaan kunnioitukseen. Kukaan tiimistä ei saa tuntea olevansa arvostamaton tai jätetty huomiotta. Tämä takaa korkean motivaation ja kannustaa uskollisuutta tiimiä ja projektin päämäärää kohtaan. Tämä arvo riippuu muista arvoista ja on suunnattu tiimityöhön.

Säännöt

Don Wells julkaisi XP: n sääntöjen ensimmäisen version vuonna 1999 XP: n verkkosivustolla. 29 sääntöä annetaan suunnittelun, hallinnan, suunnittelun, koodauksen ja testauksen luokissa. Suunnittelua, hallintaa ja suunnittelua on nimenomaisesti vastustettu väitteille, joiden mukaan XP ei tue näitä toimintoja.

Ken Auer ehdotti toista versiota XP -säännöistä XP/Agile Universe 2003. Hän koki XP: n määrittelevän sen säännöillä, ei sen käytännöillä (jotka vaihtelevat enemmän ja ovat epäselviä). Hän määritteli kaksi luokkaa: "sitoutumissäännöt", jotka sanelevat ympäristön, jossa ohjelmistokehitys voi tapahtua tehokkaasti, ja "pelisäännöt", jotka määrittelevät minuutti minuutilta toiminnot ja säännöt sitoutumissääntöjen puitteissa.

Tässä muutamia sääntöjä (epätäydellisiä):

Koodaus

Testaus

  • Kaikilla koodeilla on oltava yksikkötestit
  • Kaikkien koodien on läpäistävä kaikki yksikötestit ennen kuin ne voidaan vapauttaa.
  • Kun vika löytyy, testit luodaan ennen vian korjaamista (virhe ei ole logiikan virhe; se on testi, jota ei ole kirjoitettu)
  • Hyväksymistestejä suoritetaan usein ja tulokset julkaistaan

Periaatteet

XP: n perustana olevat periaatteet perustuvat juuri kuvattuihin arvoihin, ja niiden tarkoituksena on edistää päätöksiä järjestelmän kehityshankkeessa. Periaatteiden on tarkoitus olla konkreettisempia kuin arvot, ja ne on helpompi kääntää ohjeeksi käytännön tilanteessa.

Palaute

Äärimmäinen ohjelmointi pitää palautetta hyödyllisimpänä, jos se tehdään usein ja nopeasti. Siinä korostetaan, että toiminnan ja sen palautteen välinen minimaalinen viive on kriittinen oppimiseen ja muutosten tekemiseen. Toisin kuin perinteiset järjestelmäkehitysmenetelmät, kontakti asiakkaan kanssa tapahtuu useammin iteraatioina. Asiakkaalla on selkeä käsitys kehitettävästä järjestelmästä ja hän voi antaa palautetta ja ohjata kehitystä tarpeen mukaan. Kun asiakas antaa usein palautetta, kehittäjän tekemä virheellinen suunnittelupäätös huomataan ja korjataan nopeasti, ennen kuin kehittäjä käyttää paljon aikaa sen toteuttamiseen.

Yksikkötestit edistävät nopean palautteen periaatetta. Kun kirjoitat koodia, yksikötestin suorittaminen antaa suoraa palautetta siitä, miten järjestelmä reagoi tehtyihin muutoksiin. Tämä sisältää paitsi kehittäjätunnuksen testaavien yksikkötestien suorittamisen, myös kaikkien yksikkötestien suorittamisen kaikkia ohjelmistoja vastaan ​​käyttämällä automaattista prosessia, joka voidaan käynnistää yhdellä komennolla. Tällä tavalla, jos kehittäjän muutokset aiheuttavat vian jossakin muussa järjestelmän osassa, josta kehittäjä ei tiedä juurikaan tai ei ollenkaan, automaattinen kaikkien yksiköiden testaussarja paljastaa vian välittömästi ja varoittaa kehittäjää muutoksen yhteensopimattomuudesta järjestelmän muut osat ja niiden muutoksen poistamisen tai muuttamisen tarve. Perinteisten kehityskäytäntöjen mukaan automaattisen, kattavan yksikkötestisarjan puuttuminen merkitsi sitä, että tällainen koodin muutos, jonka kehittäjä oli vaarattomaksi pitänyt, olisi jätetty paikalleen, ja se ilmestyisi vain integraatiotestauksen aikana-tai mikä pahempaa, vain tuotannossa; ja sen määrittäminen, mikä koodimuutos aiheutti ongelman, kaikkien muutosten joukossa, joita kaikki kehittäjät tekivät integrointitestejä edeltävien viikkojen tai jopa kuukausien aikana, oli valtava tehtävä.

Yksinkertaisuutta olettaen

Kyse on jokaisen ongelman käsittelemisestä ikään kuin sen ratkaisu olisi "erittäin yksinkertainen". Perinteiset järjestelmäkehitysmenetelmät sanovat suunnittelevansa tulevaisuutta ja koodattavan uudelleenkäytettävyyttä. Äärimmäinen ohjelmointi hylkää nämä ajatukset.

Äärimmäisen ohjelmoinnin kannattajat sanovat, että suurten muutosten tekeminen kerralla ei toimi. Äärimmäinen ohjelmointi tekee asteittaisia ​​muutoksia: esimerkiksi järjestelmässä voi olla pieniä julkaisuja kolmen viikon välein. Kun monet pienet askeleet on tehty, asiakas hallitsee paremmin kehitysprosessia ja kehitettävää järjestelmää.

Muutoksen omaksuminen

Muutoksen omaksumisen periaate on se, että emme toimi muutoksia vastaan, vaan omaksumme ne. Esimerkiksi jos jossakin iteratiivisessa kokouksessa näyttää siltä, ​​että asiakkaan vaatimukset ovat muuttuneet dramaattisesti, ohjelmoijien on omaksuttava tämä ja suunniteltava uudet vaatimukset seuraavaa iteraatiota varten.

Käytännöt

Lisätietoja: Äärimmäiset ohjelmointikäytännöt

Äärimmäisellä ohjelmoinnilla on kuvattu olevan 12 käytäntöä, jotka on ryhmitelty neljään alueeseen:

Hieno mittakaava palaute

Jatkuva prosessi

Jaettu ymmärrys

Ohjelmoijan hyvinvointi

Kiistanalaiset näkökohdat

XP: n käytännöistä on käyty kiivasta keskustelua. Äärimmäisen ohjelmoinnin kannattajat väittävät, että kun paikan päällä oleva asiakaspyyntö muuttuu epävirallisesti, prosessista tulee joustava ja se säästää muodollisia yleiskustannuksia. XP: n kriitikot väittävät, että tämä voi johtaa kalliisiin uusintatöihin ja projektin laajuuteen, joka ylittää aiemmin sovitun tai rahoitetun.

Muutoksenhallintapaneelit ovat merkki siitä, että projektin tavoitteissa voi olla ristiriitoja ja rajoituksia useiden käyttäjien välillä. XP: n nopeutetut menetelmät ovat jossain määrin riippuvaisia ​​siitä, että ohjelmoijat kykenevät omaksumaan yhtenäisen asiakkaan näkökulman, jotta ohjelmoija voi keskittyä koodaukseen eikä kompromissitavoitteiden ja rajoitusten dokumentointiin. Tämä pätee myös silloin, kun mukana on useita ohjelmointiorganisaatioita, erityisesti organisaatioita, jotka kilpailevat hankkeiden osuuksista.

Muita äärimmäisen ohjelmoinnin mahdollisesti kiistanalaisia ​​näkökohtia ovat:

  • Vaatimukset ilmaistaan ​​automaattisina hyväksymistesteinä eikä erittelyasiakirjoina.
  • Vaatimukset määritellään asteittain sen sijaan, että yritettäisiin saada ne kaikki etukäteen.
  • Ohjelmistokehittäjien on yleensä työskenneltävä pareittain.
  • Edessä ei ole suurta suunnittelua . Suurin osa suunnittelutoiminnasta tapahtuu lennossa ja vähitellen alkaen"yksinkertaisin asia, joka voisi toimia" ja lisää monimutkaisuutta vain silloin, kun testit epäonnistuvat. Kriitikot vertaavat tätä " järjestelmän virheenkorjaamiseen ulkonäöksi " ja pelkäävät, että tämä johtaa enemmän uudelleensuunnitteluun kuin vain uudelleen suunnitteluun, kun vaatimukset muuttuvat.
  • Asiakas edustaja on kiinnitetty projektiin. Tästä roolista voi tulla yksittäinen epäonnistumispaikka projektille, ja jotkut ihmiset ovat kokeneet sen olevan stressin lähde. Lisäksi on olemassa vaara, että ei-tekninen edustaja yrittää hallita mikrotietoja ja yrittää määrätä ohjelmistojen teknisten ominaisuuksien ja arkkitehtuurin käytön.

Kriitikot ovat havainneet useita mahdollisia haittoja, kuten ongelmia epävakaiden vaatimusten kanssa, ei dokumentoituja kompromisseja käyttäjäristiriidoista ja yleisen suunnittelumäärityksen tai asiakirjan puuttumista.

Skaalautuvuus

ThoughtWorks on vaatinut kohtuullista menestystä hajautetuissa XP -projekteissa jopa kuusikymmentä henkilöä.

Vuonna 2004 teollinen ääriohjelmointi (IXP) otettiin käyttöön XP: n kehityksenä. Sen tarkoituksena on tuoda kyky työskennellä suurissa ja hajautetuissa ryhmissä. Sillä on nyt 23 käytäntöä ja joustavia arvoja.

Erotettavuus ja vastaukset

Vuonna 2003 Matt Stephens ja Doug Rosenberg julkaisivat Extreme Programming Refactored: The Case Against XP , jossa kyseenalaistettiin XP -prosessin arvo ja ehdotettiin tapoja, joilla sitä voitaisiin parantaa. Tämä aiheutti pitkän keskustelun artikkeleissa, Internet-uutisryhmissä ja verkkosivustojen chat-alueilla. Kirjan ydin on, että XP: n käytännöt ovat toisistaan ​​riippuvaisia, mutta harvat käytännön organisaatiot ovat halukkaita/kykeneviä omaksumaan kaikki käytännöt. siksi koko prosessi epäonnistuu. Kirjassa esitetään myös muita kritiikkejä, ja se vertaa XP: n "kollektiivisen omistuksen" mallia sosialismiin negatiivisella tavalla.

Tietyt XP: n näkökohdat ovat muuttuneet Extreme Programming Refactoredin julkaisemisen jälkeen ; erityisesti XP mukauttaa nyt käytäntöjä niin kauan kuin vaaditut tavoitteet saavutetaan. XP käyttää myös yhä yleisempiä termejä prosesseille. Jotkut väittävät, että nämä muutokset mitätöivät aiemman arvostelun; toiset väittävät, että tämä vain yksinkertaistaa prosessia.

Muut kirjoittajat ovat yrittäneet sovittaa XP: n yhteen vanhempien menetelmien kanssa yhtenäisen menetelmän muodostamiseksi. Jotkut näistä XP: stä pyrkivät korvaamaan, kuten vesiputousmenetelmä ; esimerkki: Projektin elinkaaret: vesiputous, nopea sovellusten kehittäminen (RAD) ja kaikki muu. JPMorgan Chase & Co. yritti yhdistää XP: n valmiuksien kypsyysmallin integroinnin (CMMI) ja Six Sigman tietokoneohjelmointimenetelmiin . He havaitsivat, että kolme järjestelmää vahvistivat toisiaan hyvin, mikä johti parempaan kehitykseen, eivätkä olleet keskenään ristiriidassa.

Kritiikki

Äärimmäisen ohjelmoinnin alkuhuuto ja kiistanalaiset periaatteet, kuten pariohjelmointi ja jatkuva suunnittelu , ovat herättäneet erityistä kritiikkiä, kuten McBreenin ja Boehmin ja Turnerin, Matt Stephensin ja Doug Rosenbergin esittämät arvostelut. Ketterien harjoittajien mielestä monet kritiikit ovat kuitenkin ketterän kehityksen väärinkäsityksiä.

Erityisesti äärimmäistä ohjelmointia ovat tarkastelleet ja arvostelleet Matt Stephensin ja Doug Rosenbergin Extreme Programming Refactored .

Katso myös

Viitteet

Lue lisää

  • Ken Auer ja Roy Miller. Äärimmäistä ohjelmointia sovellettu: Playing To Win , Addison – Wesley.
  • Ken Auer; Ron Jeffries ; Jeff Canna; Glen B. Alleman; Lisa Crispin; Janet Gregory (2002). "Ovatko testaajat eXtinct? Miten testaajat voivat osallistua XP -tiimeihin?". Äärimmäinen ohjelmointi ja ketterät menetelmät - XP/Agile Universe 2002 . Luennon muistiinpanoja tietojenkäsittelytieteessä. 2418 . Springer-Verlag. s. 287. doi : 10.1007/3-540-45672-4_50 . ISBN 978-3-540-44024-6.
  • Kent Beck : Extreme Programming Explained: Embrace Change , Addison – Wesley.
  • Kent Beck ja Martin Fowler : Extreme Programming Planning , Addison – Wesley.
  • Kent Beck ja Cynthia Andres. Äärimmäinen ohjelmointi selitetty: Embrace Change, toinen painos , Addison – Wesley.
  • Alistair Cockburn : Ketterä ohjelmistokehitys , Addison – Wesley.
  • Martin Fowler : Refactoring: Olemassa olevan koodin suunnittelun parantaminen , Addison – Wesley.
  • Harvey Herela (2005). Tapaustutkimus: Chryslerin kattava korvausjärjestelmä . Galen Lab, UC Irvine.
  • Jim Highsmith . Agile Software Development Ecosystems , Addison – Wesley.
  • Ron Jeffries , Ann Anderson ja Chet Hendrickson (2000), Extreme Programming Installed , Addison – Wesley.
  • Craig Larman & V. Basili (2003). "Iteratiivinen ja asteittainen kehitys: lyhyt historia", tietokone (IEEE Computer Society) 36 (6): 47–56.
  • Matt Stephens ja Doug Rosenberg (2003). Äärimmäinen ohjelmointi uudistettu: tapaus XP: tä vastaan , Apress.
  • Waldner, JB. (2008). "Nanotietokoneet ja parvi älykkyys". Julkaisussa: ISTE, 225–256.

Ulkoiset linkit