Ekstreemprogrammeerimine
Sageli aetakse ekstreemprogrammeerimise metoodika (extreme programming methodology) segamini selle ühe võtte, paarisprogrammeerimisega. Paarisprogrammeerimine on aga ekstreemprogrameerimise üks praktika nagu on seda ka plaanimismäng, rekodeerimine, lõppkasutaja projekti kaasamine jne. Paarisprogrammeerimine ajamahukates projektide on üsnagi riskantne, mu meelest... isikuomadused ja stress teeb oma töö.
Olen teinud üht ajakriitilist projekti ekstreemprogrammeerimise erinevate võtete abil ja tulemus oli üllatavalt hea. Oli teada, et tellija nõuded võivad pidevalt muutuda kuna süsteem osteti värskelt reformitud organisatsioonile, polnud veel kindlat struktuuri ja kasutajate tööülesanded võisid muutuda. Õnneks mõistis ka tellija olukorra kriitilisust ja nii saigi mehitatud kliendi lõppkasutajatest kasutajaliidese testimisrühm, kes prototüüpe ja uuendusi katsetasid ning vigade korral kiiret tagasisidet andsid. Kogu projekt oli jaotatud väiksemtaks redaktsioonideks (release) kestvusega 1-2 nädalat, mille alguses täpsustati kliendiga ülesannet ja millele järgnes implementeerimine. Programmeerijad kasutasid süsteemi arhitekti koordineerimisel rekodeerimise (refactoring) praktikat, mis tähendab programmi ümbertöötlemist nii, et funktsionaalsus ei muutu aga programmi struktuur muutub. Parendatakse programmi sisemiselt (ei tulene otseselt süsteemi funktsionaalsetest nõuetest, vaid programmi enda ülesehitusest).
Dokumenteerimisele me eriti "aega ei raisanud". Kuna nõuded muutusid pidevalt, sai selleks lihtsalt e-maili või telefoni teel infot vahetatud. Vahest oli vaja ka pikemat arutelelu, kus süsteemi arhitektiga koostöös kliendile sobivaid lahendusi otsisime.
Projekti närvesöövaim osa oligi vast kliendile testimise ja tagasiside andmise õpetamine, juurutamine.
Plussid:
1. Kliendi kõrge motivatsioon tarkvara loomisprotsessis osalemisel. Kuni tippjuhini välja:)
2. Ajamahukas projekt läbiti õigetähtaegselt
3. Klient õppis tarkvara kiiresti kasutama, tänu kasutajaliidese testimisele (üleminek toimus DOS-põhiselt tarkvaralt veebirakendusele)
4. Kõigil arendusmeeskonna liikmetel oli võrdne informeerituse tase.
Miiinused:
1. Raske oli projekti lõpetada ehk siis - skoobiväliseid asju "ujus" palju välja.
2. Pikemas perspektiviis oleks testide läbiviimine hakanud segama kasutajate põhitööd.
Olen teinud üht ajakriitilist projekti ekstreemprogrammeerimise erinevate võtete abil ja tulemus oli üllatavalt hea. Oli teada, et tellija nõuded võivad pidevalt muutuda kuna süsteem osteti värskelt reformitud organisatsioonile, polnud veel kindlat struktuuri ja kasutajate tööülesanded võisid muutuda. Õnneks mõistis ka tellija olukorra kriitilisust ja nii saigi mehitatud kliendi lõppkasutajatest kasutajaliidese testimisrühm, kes prototüüpe ja uuendusi katsetasid ning vigade korral kiiret tagasisidet andsid. Kogu projekt oli jaotatud väiksemtaks redaktsioonideks (release) kestvusega 1-2 nädalat, mille alguses täpsustati kliendiga ülesannet ja millele järgnes implementeerimine. Programmeerijad kasutasid süsteemi arhitekti koordineerimisel rekodeerimise (refactoring) praktikat, mis tähendab programmi ümbertöötlemist nii, et funktsionaalsus ei muutu aga programmi struktuur muutub. Parendatakse programmi sisemiselt (ei tulene otseselt süsteemi funktsionaalsetest nõuetest, vaid programmi enda ülesehitusest).
Dokumenteerimisele me eriti "aega ei raisanud". Kuna nõuded muutusid pidevalt, sai selleks lihtsalt e-maili või telefoni teel infot vahetatud. Vahest oli vaja ka pikemat arutelelu, kus süsteemi arhitektiga koostöös kliendile sobivaid lahendusi otsisime.
Projekti närvesöövaim osa oligi vast kliendile testimise ja tagasiside andmise õpetamine, juurutamine.
Plussid:
1. Kliendi kõrge motivatsioon tarkvara loomisprotsessis osalemisel. Kuni tippjuhini välja:)
2. Ajamahukas projekt läbiti õigetähtaegselt
3. Klient õppis tarkvara kiiresti kasutama, tänu kasutajaliidese testimisele (üleminek toimus DOS-põhiselt tarkvaralt veebirakendusele)
4. Kõigil arendusmeeskonna liikmetel oli võrdne informeerituse tase.
Miiinused:
1. Raske oli projekti lõpetada ehk siis - skoobiväliseid asju "ujus" palju välja.
2. Pikemas perspektiviis oleks testide läbiviimine hakanud segama kasutajate põhitööd.
Kommentaarid
Üks kasulik raamat paarisprogrammeerimise kohta on Addison Wesley poolt välja antud "Pair Programming Illuminated". Autoriteks on siis L. Williams ja R. Kessler (huvitav kas nad kasutasid raamatu kirjutamisel sama tehnikat). Seal on juttu ka sellest, kuidas paare kokku panna, mis peaks huvitav olema.
Peamiseks probleemiks paarisprogrammeerimisega on see, et ei teata täpselt mida tegema peab ning sealt lähebki tihi asi kiiva. Suurimaks ämbriks on see, et üks trükib ja teine ütleb mida (Carr, James. 14.03.2007. Backseat Driving in Pair Programming). Enne kui seda suuresti praktiseerima hakata, tuleks palju uurida selle kohta, sest see pol nii lihtne kui paistab.
Koodi kommenteerimine peaks igas normaalses, jätkusuutlikus tarkvaraarendusfirmas olema iseenesestmõistetav.
Lugedes Su antud viidet, leidsin kinnitust arusaamisele, et paarisprogrammeerimine eeldab osalt sarnast backroundi, võte toimib suurest "kokkuleppelisel teadmisel". Ja sarnasel mõtlemisel/käekirjal. Ühe ja sama task`i teostamiseks võib olla erinevaid lahendeid, paarisprogejatel puhul oleks ideaalne, kui "tee" lahendini oleks samane.
Teine probleem on nendega veel see, et nad võivad eksitada või valetada. See juhtub peamiselt koodi kopeerimisega (muideks see viitab ka sellele, et koodi struktuuri on võimalik parandada).