Paaris­programmeerimise äriline põhjendus: millal maksavad kaks arendajat vähem kui üks_

Paarisprogrammeerimist on lihtne valesti mõista, sest selle kõige nähtavam osa on ühtlasi kõige lihtsamini hinnastatav: kaks arendajat töötavad samal ajal sama ülesande kallal. Kui võrdlus sellega piirdub, näib paaris töötamine maksvat kaks korda rohkem.

Tarkvara tellija ei maksa aga lõppkokkuvõttes trükkimise aja eest. Ta maksab toimiva süsteemi, usaldusväärse tarne, hooldatavate otsuste, kiire õppimise ja jätkusuutliku meeskonna eest. Seetõttu ei ole õige võrdlus üks arendaja versus kaks arendajat ühe tunni jooksul. Võrrelda tuleb kasuliku tulemuse saavutamise ja selle pikaajalise töökindluse kogukulu.

Praktiline kogukulu hõlmab muu hulgas:

• esmast teostust;
• nõuete täpsustamist ja ümbertegemist;
• enne ja pärast reliisi leitud vigu;
• disainiotsuseid, mis muudavad hilisemad muudatused kalliks;
• koodi ülevaatamise ja üleandmise aega;
• uute inimeste sisseelamist ja teadmiste jagamist;
• viivitusi, mis tekivad ühe inimese hõivatuse või puudumise tõttu;
• toodanguintsidente ja taastamist;
• pikaajalist hooldust.

Paarisprogrammeerimine võib osutuda odavamaks, kui see vähendab märgatavalt mitut neist kululiikidest.

Mida kaks arendajat tegelikult teevad?

Üks arendaja juhib tavaliselt tarkvara kirjutamist, teine jälgib arutluskäiku, hindab tekkivat lahendust ja hoiab silme ees laiemat probleemi. Rolle vahetatakse regulaarselt. Tootlik paar ei tähenda üht töötavat ja teist passiivselt vaatavat inimest.

Paar vastab töö käigus pidevalt küsimustele, mis üksi töötades lükatakse sageli hilisemaks:

• Kas saime nõudest õigesti aru?
• Kas on olemas lihtsam lahendus?
• Millised äärejuhtumid on puudu?
• Kas muudatus sobib olemasoleva arhitektuuriga?
• Kuidas seda testida, juurutada ja jälgida?
• Kas tekitame turva- või töökindlusriski?
• Kas teine arendaja mõistab seda ka kuue kuu pärast?

See on pidev disainiülevaatus, koodiülevaatus ja teadmiste jagamine. Tagasiside saabub ajal, mil otsust on veel odav muuta.

Miks võib paaris töötamine kogukulu vähendada?

Varasem tagasiside tähendab vähem ümbertegemist

Tarkvara kirjutamise ajal avastatud arusaamatuse parandamine võib võtta minuteid. Vastuvõtutestis leitud sama probleem võib nõuda muudatusi koodis, testides, dokumentatsioonis ja integratsioonides. Toodangusse jõudes võib lisanduda kasutajatugi ja otsene äriline mõju.

Paarisprogrammeerimine ei kõrvalda vigu, kuid suurendab tõenäosust, et eeldused seatakse kahtluse alla enne, kui need levivad kõikjale süsteemidesse ja äriprotsessidesse.

Teadmised ei jää ühe inimese kätte

Üksi töötav arendaja kogub paratamatult unikaalset konteksti: miks mingi otsus tehti, milline väline süsteem käitub ootamatult ja kus asuvad ohtlikud äärejuhtumid. Sellest teadmisest saab ettevõtte sõltuvus.

Paaris töötades mõistab muudatust algusest peale vähemalt kaks inimest. See parandab järjepidevust puhkuste, haiguste, meeskonnavahetuste ja intsidentide ajal. Samuti väheneb vajadus hiljem dokumenteerimata ajalugu rekonstrueerida.

Keerulised otsused sünnivad kiiremini

Ka kogenud arendaja võib kulutada tunde suunale, mis ei vii tulemuseni. Paar märkab tupikut varem, võrdleb alternatiive reaalajas ja saab uurimistööd jagada ilma ühist konteksti kaotamata.

See on eriti oluline keeruliste ärireeglite, legacy-süsteemide, turvalisuse, integratsioonide ja arhitektuuri puhul. Rutiinne töö võidab paarist vähem; ebakindel ja suure mõjuga töö tavaliselt rohkem.

Ülevaatus toimub enne pull request'i

Tavapärane koodiülevaatus algab sageli alles siis, kui autor peab töö lõpetatuks. Ülevaataja peab taastama konteksti, mõistma eesmärki ja tegema ettepanekuid, mis võivad nõuda ulatuslikku ümbertegemist. Paarisprogrammeerimine toob suure osa sellest arutelust arenduse sisse.

Formaalne ülevaatus võib endiselt olla vajalik, kuid siis on see pigem kinnitus kui esimene sisuline arutelu lahenduse üle.

Kas paarisprogrammeerimine vähendab vigu?

See võib vigu vähendada, kuid seda ei tohiks müüa veatu tarkvara garantiina. Väärtus seisneb selles, et paljud eksimused muutuvad nähtavaks varem ja rohkem arutluskäike saavad kohe teise inimese kontrolli.

Tulemus sõltub paari kvaliteedist. Kaks arendajat võivad kinnistada vale eeldust sama hästi, kui üks arendaja võib teha suurepärase otsuse. Paaris töötamine toimib kõige paremini siis, kui mõlemad osalevad aktiivselt, julgevad konstruktiivselt eriarvamusele jääda ning neid toetavad automaattestid, jälgitavus ja distsiplineeritud tarneprotsess.

Tellijale ei ole kõige kasulikum küsimus "Kas paaris töötamine välistab kõik vead?", vaid "Kas see tööviis suurendab tõenäosust, et oluline viga leitakse ajal, mil selle parandamine on veel odav?"

Mis juhtub, kui üks arendaja lahkub?

Paarisprogrammeerimine ei kõrvalda kogu personaliriski, kuid vähendab teadmiste koondumist. Kui arendajad vahetavad paare ja töötavad süsteemi eri osades, levivad arhitektuuri- ja valdkonnateadmised kogu meeskonnas.

See loob tervema omandimudeli kui püsivate moodulite määramine üksikutele spetsialistidele. Eesmärk ei ole, et kõik teaksid kõike. Eesmärk on, et ükski ärikriitiline valdkond ei sõltuks ühest inimesest, keda ei saa asendada, toetada või kelle otsuseid ei saa kontrollida.

Kas iga ülesanne peab olema tehtud paaris?

Ei. Kui paarisprogrammeerimist käsitleda rituaali, mitte riskijuhtimise vahendina, tekib raiskamine.

Paaris töötamine annab tavaliselt kõige rohkem väärtust järgmistes olukordades:

• uus või ebaselge äriloogika;
• arhitektuurilised muudatused;
• turvatundlik töö;
• toodanguintsidendid;
• keerulised integratsioonid;
• riskantsed migratsioonid;
• uue inimese sisseelamine;
• suure ebaõnnestumiskuluga muudatused.

Üksi töötamine võib olla mõistlik rutiinse seadistuse, iseseisva uurimistöö, lihtsate sisumuudatuste või hiljem turvaliselt ülevaadatavate ülesannete puhul. Küps meeskond valib tööviisi keerukuse ja riski järgi, kuid teeb teadmiste jagamise teadlikuks.

Kas paarisprogrammeerimine sobib kliendi enda meeskonnaga?

Jah, ning see võib olla praktika üks tugevamaid kasutusviise. Välise kogenud inseneri ja sisemise arendaja paar annab edasi palju enamat kui koodi. Liiguvad valdkonnateadmised, töövõtted, arhitektuuriline mõtlemine ja süsteemi praktiline tundmine.

Selleks ei tohi suhe muutuda juhendamiseks, kus üks osapool ainult vaatab. Mõlemad arendajad peavad saama panustada, eeldusi vaidlustada ja rolle vahetada. Eesmärk on ühine meeskond, mitte välisekspert, kes jagab passiivsele osalejale korraldusi.

Kuidas mõõta, kas paaris töötamine toimib?

Ärge hinnake paarisprogrammeerimist koodiridade või üksikisiku hõivatuse järgi. Mõõtke mõistliku perioodi jooksul tarne tulemusi:

• aeg kokkulepitud vajadusest toodanguni;
• uuesti avatud või suurelt ümber tehtud töö osakaal;
• toodangusse jõudnud vead ja intsidendid;
• muudatuste ülevaatamiseks ja juurutamiseks kuluv aeg;
• uue arendaja sisseelamisaeg;
• kriitiliste valdkondade arv, mida mõistab ainult üks inimene;
• taastumisaeg võtmeisiku puudumisel;
• tarne prognoositavus;
• valminud süsteemi hooldatavus.

Võrdlus peab käima realistliku alternatiiviga, mitte kujuteldava üksikarendajaga, kes teeb alati kohe õige otsuse.

Millal paarisprogrammeerimine tõenäoliselt ära ei tasu?

Paaris töötamine võib olla halb valik siis, kui töö on väga väike, korduv, kergesti osadeks jagatav ja odavalt parandatav. See ebaõnnestub ka siis, kui üks osaleja lülitub välja, oskuste erinevust hallatakse halvasti või organisatsioon premeerib meeskonnatulemuse asemel individuaalset väljundit.

Paarisprogrammeerimine ei asenda tooteomanikku, selgeid prioriteete, testimist ega pädevat inseneritööd. See võimendab meeskonna tööviisi, kuid ei paranda üksi katkist keskkonda.

Otsus käib riskiga korrigeeritud kulu kohta

Paarisprogrammeerimise äriline põhjendus ei ole väide, et kaks inimest toodavad alati rohkem koodi kui üks. Tavaliselt ei tooda. Põhjendus on selles, et tarkvara maksumust kujundavad otsused, tagasiside, vead, teadmised ja viivitus, mitte ainult teostustunnid.

Lühikese ja madala riskiga töö puhul võib üks arendaja olla kõige ökonoomsem valik. Pika elueaga ärikriitilise tarkvara puhul, kus reeglid on keerulised ja eksimused kallid, võib hästi toimiv paar vähendada kogukulu, ennetades ümbertegemist, jagades teadmisi ja parandades otsuseid enne, kui neid on raske tagasi pöörata.

Paarisprogrammeerimist kasutava arenduspartneri hindamisel küsige, kuidas praktika mõjutab tarne tulemusi, kuidas paare vahetatakse, milliseid töid tehakse eraldi ja kuidas meeskond kvaliteeti mõõdab. Metoodika väärtus peab olema nähtav tulemustes, mitte ainult arvel.