eXtreme Programming

eXtreme Programming — yleensä vain XP — on ketterän perheen vaativin jäsen. East Agile Tracker on rakennettu ensisijaisesti XP:tä varten; kaikki muu seuraa siitä.

Tämä sivu käsittelee, mitä XP on, miksi se toimii ja kuinka sitä harjoitetaan tracker suunnittelupintana.

Mitä XP on

XP:n loi Kent Beck 1990-luvun lopulla. Ensimmäinen kirja — Extreme Programming Explained: Embrace Change — julkaistiin vuonna 1999. Se alkoi, kuten monet asiat, turhautuneesta tiimistä, joka yritti toimittaa palkanlaskentajärjestelmää Chryslerille.

XP:n vedonlyönti on, että oikea tapa käsitellä epävarmuutta ohjelmistossa on tehdä asioita, jotka toimivat, ja tehdä niitä useammin. Testataanko? Testaa koko ajan. Integroidaanko? Integroi tunneittain. Puhutaanko? Puhu jatkuvasti. Suunnitellaanko? Suunnittele joka iteraatio ja suunnittele uudelleen oppiessasi.

“XP on kevyt metodologia pienille ja keskisuurille tiimeille, jotka kehittävät ohjelmistoa epämääräisten tai nopeasti muuttuvien vaatimusten edessä.” — Kent Beck

Viisi arvoa

XP nimeää viisi arvoa, joista kaikki muu riippuu:

1. Kommunikaatio — Tiimi puhuu. Päivittäin. Työstä, suunnittelusta, esteistä. Kasvokkain kun mahdollista. Siilot ovat vihollinen.
2. Yksinkertaisuus — Tee yksinkertaisin asia, joka voisi mahdollisesti toimia. Voit lisätä monimutkaisuutta myöhemmin, jos todella tarvitset sitä. Todennäköisesti et tarvitse.
3. Palaute — Koodista (testit), tiimiltä (pariohjelmointi, arviot), käyttäjältä (tiheät julkaisut). Hanki sitä nopeasti.
4. Rohkeus — Kerro totuus edistymisestä, arvioista ja suunnittelusta. Heitä pois koodi, joka ei toimi. Refaktoroi se, mikä jarruttaa sinua.
5. Kunnioitus — Jokainen tiimissä — ja nyt jokainen agentti tiimissä — tuottaa arvoa. Kohdelkaa toisianne sen mukaisesti.

Käytännöt

XP on kuuluisa kahdestatoista alkuperäisestä käytännöstään, jotka on järjestetty neljään alueeseen:

Suunnittelu

• Planning Game — Tiimi ja asiakas suunnittelevat yhdessä: mitä tulee seuraavaksi, missä järjestyksessä, kuinka suuri kukin pala on.
• Small Releases — Toimita usein. Päiviä, ei kuukausia. Saa palautetta jostakin konkreettisesta.
• User Stories — Vaatimukset ovat keskusteluja, kuvattuna lyhyinä tarinoina käyttäjän näkökulmasta. “Käyttäjänä haluan X:n, jotta Y.”

Suunnittelu (design)

• Simple Design — Yksinkertaisin suunnitelma, joka läpäisee testit ja ilmaisee jokaisen tarvittavan käsitteen. Ei enempää.
• Refactoring — Paranna jo toimivan koodin suunnittelua. Jatkuvasti.
• System Metaphor — Jaettu tarina siitä, miten järjestelmä toimii, käytetään suunnittelupäätösten johdonmukaistamiseen.

Koodaus

• Pair Programming — Kaksi kehittäjää, yksi näppäimistö. Toinen ajaa, toinen navigoi. Vaihda usein.
• Collective Code Ownership — Kuka tahansa voi parantaa mitä tahansa koodia. Ei läänityksiä.
• Continuous Integration — Integroi ja testaa koodi monta kertaa päivässä. Nappaa rikkoutumiset välittömästi.
• Coding Standards — Sovittu tyyli, jotta koodi lukeutuu kuin yksi henkilö olisi sen kirjoittanut.

Testaus

• Test-Driven Development (TDD) — Kirjoita epäonnistuva testi ensin, sitten koodi, joka saa sen läpäisemään.
• Acceptance Tests — Asiakas määrittää koodina tai suoritettavassa muodossa, mitä “valmis” tarkoittaa kullekin tarinalle.

Miksi XP toimii

XP on epämukavaa. Pariohjelmointi pakottaa sinut ajattelemaan ääneen. TDD pakottaa sinut tietämään, miltä onnistuminen näyttää, ennen kuin kirjoitat koodin. Jatkuva integraatio tappaa lempipitkäikäiset haarasi. Pienet julkaisut tarkoittavat, ettet voi piiloutua kuuden kuukauden tiekartan taakse.

Se toimii, koska kaikki nämä asiat lyhentävät palautesilmukoita. Mitä nopeammin saat selville olleesi väärässä, sitä halvempi korjaus on. XP on pohjimmiltaan siitä, että palautesilmukasta tehdään niin tiukka kuin se voi olla.

Se on myös rohkeudesta ja kunnioituksesta. XP:tä voi tehdä vain tiimissä, joka luottaa toisiinsa riittävästi ollakseen väärässä ääneen.

Kurinalainen tarinamalli

East Agile Tracker koodaa erityisen suunnitteluteorian. Käsittele tätä osiota käyttöoppaana sille, miksi tietomalli näyttää siltä miltä se näyttää — ja kenttäoppaana sille, mitä tehdä (ja mitä ei) käytännössä.

Miksi neljä tarinatyyppiä on tärkeää

Kaikki on tarina, mutta niitä on neljää lajia, ja ero on koko pointti:

• Ominaisuudet (features) kantavat pisteitä ja ovat ainoa asia, joka “lasketaan” nopeuteen. Tämä pakottaa sinut pilkkomaan työn käyttäjälle havaittavaksi arvoksi.
• Virheet (bugs) ovat pisteettömiä (nolla). Viat eivät ansaitse pisteitä, mikä tekee uudelleentyön kustannuksesta näkyvän sen sijaan, että siitä palkittaisiin.
• Askareet (chores) ovat myös pisteettömiä — välttämätöntä työtä ilman suoraa käyttäjäarvoa (infra, refaktoroinnit, asennus). Niiden pitäminen nollassa painostaa tiimiä niputtamaan ne osaksi ominaisuuksia aina kun mahdollista, jotta arvonäkökulma pysyy rehellisenä.
• Julkaisut (releases) ovat nollapisteisiä merkkejä, joita käytetään virstanpylväiden ankkurointiin ja siihen, että työkalu voi ennustaa päivämäärän.

Käyttäytymisvaikutus on se, millä on merkitystä: kun virheet ja askareet eivät tuota pisteitä, tiimi pyrkii luonnostaan ilmaisemaan työn käyttäjälähtöisenä toiminnallisuutena, ja se tulee terävän tietoiseksi vikojen kustannuksesta. Se on suunnittelukurinalaisuus, joka on koodattu tietomalliin.

Yksi järjestetty työjono

Kolme vyöhykettä, yksi sääntö.

• Icebox on priorisoimaton ideapooli.
• Backlog on tiukasti järjestetty, yksittäisen prioriteetin lista — ei tasapeliä, ei “P1/P1/P1”.
• Current-vyöhyke pitää sisällään aktiivisen iteraation/aktiiviset iteraatiot.

Tuoteomistaja omistaa järjestyksen ylhäältä alas, ja muuttumaton periaate on, että työjonon kärki on aina tärkein ja parhaiten määritelty, ja selkeys vähenee oikeutetusti alaspäin mennessä. Lähellä kärkeä oleva tarina, jolla on epämääräiset hyväksyntäkriteerit, on suunnitteluvirhe. Iceboxin sallitaan olla hautausmaa; Backlogin ei.

Nopeusvetoinen automaattinen suunnittelu

Tämä on se osa, jonka useimmat tiimit toteuttavat uudelleen huonosti muualla. Tracker-tyyppinen suunnittelu laskee liukuvan keskinopeuden viimeaikaisista hyväksytyistä pisteistä ja vetää automaattisesti sen verran pisteitä tarinoita seuraavaan iteraatioon — et “sitoudu” sprinttiin käsin, empiirinen data tekee sen puolestasi. Kaksi seurausta, jotka kannattaa säilyttää:

• Arvioit vain ominaisuudet käyttäen suhteellisia pisteitä (Fibonacci 1/2/3/5/8 tai tiukempi 0/1/2/3), et tunteja. Arviointi on koonkeskustelu, ei lupaus.
• Et pelaa nopeudella. Pisteiden paisuttaminen “näyttääksesi nopealta” tai askareiden pisteyttäminen rikkoo ennusteen, joka tekee koko järjestelmästä rehellisen. Nopeus on mittausväline, etkä peukaloi omaa mittaustasi.

Palkinto on, että julkaisupäivän ennuste muuttuu laskelmaksi neuvottelun sijaan, ja keskustelu sidosryhmien kanssa siirtyy kysymyksestä “voitko sitoutua toimittamaan X perjantaihin mennessä” muotoon “nykyisellä nopeudella tämä julkaisu osuu noin päivämäärälle Y — tässä on laajuus/päivämäärä-vaihtokauppa”.

Tarinan elinkaari ja hyväksyntäsilmukka

Tilakone on Start → Finish → Deliver → Accept / Reject. Kriittinen tila on Deliver: insinööri merkitsee tarinan toimitetuksi, mutta se ei ole valmis ennen kuin tuoteomistaja nimenomaisesti hyväksyy sen sen hyväksyntäkriteerejä vasten — tai hylkää sen, jolloin se palaa takaisin. Tämä leipoo asiakaspalautesilmukan jokaiseen yksittäiseen tarinaan sen sijaan, että hyväksyntä lykättäisiin sprintin lopun demoon.

Hyväksyntäkriteerit kuuluvat tarinaan ennen sen aloittamista, mieluiten Given/When/Then-muodossa, jotta ne kartoittuvat suoraan hyväksyntätesteiksi. INVEST on järkevyystarkastus sille, onko tarina hyvin muotoiltu:

• Independent (riippumaton) — voidaan julkaista ilman muita tarinoita.
• Negotiable (neuvoteltavissa) — vangitsee aikomuksen, ei jäädytettyä määrittelyä.
• Valuable (arvokas) — käyttäjälle tai sidosryhmälle.
• Estimable (arvioitavissa) — tiimi voi mitoittaa sen.
• Small (pieni) — mahtuu mukavasti yhteen iteraatioon.
• Testable (testattavissa) — sillä on hyväksyntäkriteerit, joita voidaan harjoittaa.

Rytmi

Suunnitteluseremoniat ovat kevyitä ja säännöllisiä:

• Viikoittainen iteraation suunnittelukokous (Iteration Planning Meeting) uusien tarinoiden pisteyttämiseksi ja hyväksyntäkriteerien naulaamiseksi työjonon kärjessä.
• Lyhyt päivittäinen standup, joka keskittyy virtaukseen ja esteisiin.
• Retrospektiivi iteraatiota kohti prosessin säätämiseksi.

Iteraatiot ovat yleensä yksi tai kaksi viikkoa — riittävän lyhyitä, jotta huono arvio on halpa havaita.

Insinööritekniikat, jotka saavat suunnittelun toimimaan

Tracker-tyyppinen suunnittelu on XP:n näkyvä puolisko; se romahtaa ilman insinööripuoliskoa.

• Test-first / TDD ja todellinen hyväksyntätestipaketti ovat se, mikä antaa “toimitetulle” merkityksen.
• Jatkuva integraatio ja pienet, tiheät julkaisut pitävät läpimenoajan lyhyenä, joten nopeus on vakaa eikä mukkurainen.
• Pariohjelmointi (tai vahva arviointi) pitää keskeneräisen työn vähäisenä — lopeta ennen kuin aloitat — mikä on yksittäinen suurin vipuvarsi läpimenoaikaan.
• Tavoitettavissa oleva tuoteomistaja on se, mikä estää hyväksy/hylkää-silmukkaa pysähtymästä.

Vältettävät vastakäytännöt

Toistuvat epäonnistumiset:

• Backlogin kohtelu pysäköintipaikkana todellisen prioriteettijärjestyksen sijaan.
• Virheiden ja askareiden arviointi, jotta nopeus näyttäisi paremmalta.
• Valtavien tarinoiden kantaminen, jotka eivät voi valmistua yhdessä iteraatiossa. Pilko, kunnes kukin on itsenäisesti toimitettavissa.
• Tarinoiden kasaantuminen Delivered-tilaan, koska kukaan ei hyväksy.

Mikä tahansa näistä muuntaa hiljaa empiirisen järjestelmän takaisin toiveajatteluksi suunnittelussa. Tracker ei voi estää sinua tekemästä niitä; se voi vain tehdä niistä näkyviä. Katso Delivered-saraketta jokaisen iteraation lopussa — jos se kasvaa, se on signaalisi.

XP East Agile Trackerilla

Tracker on suunnittelupinta, jota XP-tiimit ovat halunneet Pivotal Tracker -päivistä lähtien. Jokainen käsite kartoittuu suoraan:

User Stories → Tarinat

XP:n käyttäjätarinat ovat East Agile Tracker -tarinoita. Kirjoita ne Feature-tyyppiin. Käytä kuvausta keskusteluun; käytä kommentteja jatkuvaan keskusteluun. Hyväksyntäkriteerit kuuluvat kuvaukseen.

Planning Game → Taulu

Planning Game XP:ssä on keskustelu liiketoiminnan ja tiimin välillä prioriteetista ja koosta. East Agile Trackerissa:

1. Tuotehenkilö kirjoittaa tarinat Backlogiin ja järjestää ne prioriteetin mukaan.
2. Tiimi arvioi ominaisuudet pisteinä (Fibonacci- tai East Agile -asteikko).
3. Järjestelmä suunnittelee iteraatiot automaattisesti nopeudesta.
4. Tiimi aloittaa tarinat Current-sarakkeen kärjestä.

Siinä se. “Peli” elää keskustelussa; tracker vain pitää pisteet.

Small Releases → Julkaisut (tarinatyyppi)

XP sanoo: julkaise usein. Release on yksi East Agile Trackerin neljästä tarinatyypistä. Luo julkaisu jokaiselle toimitusvirstanpylväälle; vedä se iteraatioon, jossa se toimitetaan. Julkaisut ohittavat Started/Finished/Delivered ja menevät suoraan Accepted-tilaan, kun toimitat.

Continuous Integration → Tarinan tilakone

Tilakone ei ole CI sinänsä — se on rakennusjärjestelmäsi — mutta polku Finished → Delivered → Accepted peilaa asiakashyväksyntäsilmukkaa, jonka XP kuvaa. Saata työ valmiiksi, toimita se asiakkaalle, hyväksy kun se on vahvistettu toimivaksi.

Velocity → “Eilisen sää”

XP kutsuu sitä eilisen sääksi: kuinka paljon sait tehtyä viime iteraatiossa, on paras ennuste sille, kuinka paljon saat tehtyä tässä. East Agile Tracker laskee nopeuden automaattisesti — viimeaikaisten iteraatioiden keskiarvo, määritettävissä oleva strategia — ja käyttää sitä seuraavan iteraation kapasiteetin automaattiseen suunnitteluun.

Acceptance Tests → Arviot

Tarinan arviot trackerissa kartoittuvat hyväksyntään. Määritä arvioija (asiakas, tuoteomistaja tai jopa sellaisena toimiva agentti). He hyväksyvät tai hylkäävät. Hylkäys lähettää tarinan takaisin Started-tilaan.

Pair Programming → Yhteisomistus

XP-tiimit parittavat koodissa. Trackerissa tämä näkyy useina omistajina tarinassa. Määritä molemmat parit tarinaan; molemmat nimet näkyvät kortilla.

XP agenttien kanssa — uusi käytäntö

XP kirjoitettiin ennen kuin tekoälyagentit pystyivät merkittävästi osallistumaan ohjelmistoon. Mielestämme tämä on tärkein päivitys XP:hen kahteenkymmeneenviiteen vuoteen.

Käytännössämme — ja siihen, mihin tracker on rakennettu — agentti on nimetty XP-tiimin jäsen. Sillä on oma roolinsa, oma parikumppaninsa (ihminen tai agentti) ja oma tarkastusjälkensä. Se voi tehdä mitä tahansa, mitä inhimillinen tiimin jäsen voi tehdä suunnittelupinnassa: arvioida, omistaa tarinoita, kommentoida, siirtää, hyväksyä arvioita.

XP-arvot pätevät edelleen. Kommunikaatio: agentit kommunikoivat lukemalla tapahtumavirtaa ja julkaisemalla kommentteja. Yksinkertaisuus: agentit ovat rajattuja rooleihin, jotka myönnät niille. Palaute: jokainen agentin toiminta on tarkastuslokissa, välittömästi tarkasteltavissa. Rohkeus: ole rehellinen siitä, mitä agenttisi tekivät oikein ja mitä eivät. Kunnioitus: agenttitiimikaverit tuottavat arvoa — tunnista se.

Emme laita agentteja trackerin sisään tekemään koodausta. Annamme suunnittelupinnan ihmisille ja agenteille, jotka työskentelevät yhdessä. Sinä tuot koodausagentin — Claude Code, Codex, oman — ja yhdistät sen trackeriin API:n kautta. Agentti poimii tarinoita, tekee työn, kommentoi, siirtää. Sinä tarkastat jäljen ja hyväksyt.

Tämä on Osallistava ketterä suunnittelu. Se on XP:tä, sillä tiimillä joka sillä todella on.

Lisälukemista

• Extreme Programming Explained — Kent Beckin perustavanlaatuinen kirja, 1999.
• Ketterä manifesti — Mistä perhe alkoi.
• Ketterä kehitys — Laajempi kuva.
• Käyttöohjeet — Käytännön opas trackeriin.
• API-opas — Koodausagentin kytkeminen.