Väledad tarkvaraarenduse mudelid

Sissejuhatus

Välearendus on kiire tarkvaraarendus, kus kasutatakse agiilseid metoodikaid. Agiilsete metoodikate väljatöötamine sai alguse 1990. aastatel, kui tarkvaraarendajad mõistsid, et traditsioonilised tarkvaraarenduse meetodid paljude projektide jaoks ei sobi.

Traditsioonilised tarkvaraarenduse meetodid (nt kosemudel ja spiraalmeetod) panevad rõhku hoolikale projektiplaneerimisele, rohkele dokumentatsioonile ja süsteemidisainile enne arendustöö algust. Kuigi neid meetodeid on aja jooksul märkimisväärselt edasi arendatud, pole muudatused saanud jagu traditsiooniliste mudelite peamistest nõrkustest, milleks on lõhkised eelarved, võimetus ajagraafikus püsida ja vigased tooted – ühesõnaga ebaõnnestunud projektid. Samuti pole need oluliselt tõstnud tootlikkust, usaldusväärsust ega mudelite lihtsust.

Välearenduse puhul eeldatakse, et projektides tuleb muutusi ette niikuinii ning neid tuleb hallata, mitte vältida . Välearendus seab fookusesse inimesed, kes tarkvaraarendust teostavad ja kuidas nad koos töötavad. Lahendused valmivad iseorganiseeruvate ja polüfunktsionaalsete meeskondade koostöö tulemusena . Lähemalt võrreldakse traditsioonilist ja väledat tarkvaraarendust alljärgnevas tabelis .

Kategooria	Traditsiooniline tarkvaraarendus	Väle tarkvaraarendus
Juhtimisstiil	Käskiv ja kontrolliv	Koostööl põhinev
Suhtlus kliendiga	Ametlik	Mitteametlik
Arendusmudel	Elutsükli mudel (tarkvara spetsifitseerimine, arendamine, testimine toimub eraldi tsüklitena)	Evolutsiooniline mudel (arendamist, testimist tehakse kogu aeg, pidevalt)
Organisatsiooniline korraldus	Mehhaaniline, suunatud suurtele projektidele	Orgaaniline, suunatud väikestele ja keskmistele projektidele
Kvaliteedi tagamine	Keerukas planeerimine ja range kontroll	Nõuete, disaini ja lahenduste pidev kontroll
Arenduse suunitlus	Kindlalt määratletud	Kergesti muudetav
Kliendi kaasatus	Madal, klient näeb toodet siis, kui rakendus on valmis	Kõrge, klient on osa arendajate meeskonnast ning näeb tulemust pärast iga muudatust
Testimine	Pärast koodi valmimist	Arenduse käigus, pidevalt
Täiendavad nõudmised arendajatele	Pole	Suhtlemisoskus ja põhiteadmised kliendi äriloogikast
Projekti sobiv suurus	Suuremad projektid	Väiksemad ja keskmised projektid
Nõuded	Stabiilsed, projekti alguses teada	Pidevalt muutuvad
Esmane eesmärk	Kõrge turvalisus	Kiire tulemus
Meeskonna suurus	Suur	Väike

Esmalt käsitleb käesolev artikkel välearendust üldisemalt ning seejärel tutvustab lähemalt kolme tuntumat agiilset metoodikat: Scrum’i, Kanban’i ja ekstreemprogrammeerimist, seades fookuse nende professionaalsetele ja sotsiaalsetele aspektidele.

Välearenduse põhimõtted ja -printsiibid

2001. aastal sõnastas grupp tarkvaraarendajaid välearenduse põhimõtted ja -printsiibid, millele agiilsed metoodikad peaksid toetuma.

Agiilse tarkvaraarenduse põhimõtted

Tarkvara luues hinnatakse alljärgnevas tabelis vasakpoolses tulbas olevaid tegureid kõrgemalt, teadvustades samas ka parempoolse tulba tegurite väärtust .

Rohkem hinnatakse	Vähem hinnatakse
Inimesi ja nendevahelist suhtlust	Protsesse ja arendusvahendeid
Töötavat tarkvara	Kõikehõlmavat dokumentatsiooni
Koostööd kliendiga	Läbirääkimisi lepingute üle
Reageerimist muutunud oludele	Algse plaani järgimist

Agiilse tarkvaraarenduse põhiprintsiibid

Agiilse tarkvaraarenduse 12 põhiprintsiipi on järgmised :

• Kõige olulisem on tagada kliendi rahulolu, tarnides talle vajalikku tarkvara võimalikult kiiresti ja tihti.
• Mõistame muutuvaid olusid, isegi kui need ilmnevad arenduse lõppjärgus. Agiilsed meetodid pööravad sellised muutused meie kliendi konkurentsieeliseks.
• Tarnime tarkvara nii tihti kui võimalik, soovitavalt iga paari nädala kuni paari kuu tagant.
• Valdkonna spetsialistid ja tarkvaraarendajad peavad töötama igapäevaselt koos kogu projekti vältel.
• Projekti edukuse aluseks on motiveeritud inimesed. Loo neile meeldiv ja toetav töökeskkond ning nad saavad iseseisvalt tööga hakkama.
• Kõige tõhusam ja tulemuslikum viis info jagamiseks arendusmeeskonnas on näost näkku vestlus.
• Edu peamiseks mõõdupuuks on töötav tarkvara.
• Agiilse tarkvaraarenduse protsessid soodustavad jätkusuutlikku arendust. See tähendab, et projektiga saab samas tempos jätkata määramata aja jooksul.
• Tehnilist täiuslikkust ja head disaini pideva tähelepanu all hoides tagatakse tarkvaraarenduse kiirus ja paindlikkus.
• Lihtsus - ebavajaliku töö tegematajätmise kunst - on väga oluline.
• Parimad arhitektuurilised lahendused, nõuded ja disain tekivad iseorganiseeruvates meeskondades.
• Meeskond otsib regulaarselt võimalusi saamaks veelgi tõhusamaks ja muudab end vastavalt vajadusele.

Scrum

Ken Schwaber

Jeff Sutherland

Hirotaka Takeuchi

Ajalugu

Scrumi esitleti avalikkusele esmakordselt aastal 1995 Jeff Sutherland’i ja Ken Schwaber’i poolt. Samas on mudeli autorid öelnud, et tegemist pole mingi enneolematu lähenemisega – sarnaseid praktikaid on kasutatud ka varem. Nii Sutherland’i kui Schwaber’i jaoks oli Scrumi lõplik mudel aastatepikkuse kogemuste ja õppimise tulemus.

Mudeli mõlemad autorid osalesid aastatel 1967-1975 Vietnami sõjas. Sellel perioodil oli riskide hindamine meestele igapäevaelu loomulikuks osaks ning mõjutas ilmselt nende mõttelaadi ka tulevikus. Pärast sõda asusid mõlemad tööle tarkvaraarenduses ning hoidsid teineteisega kontakti.

Ken Schwaber

Ken Schwaber asutas pärast kümneaastast tarkvaraettevõttes töötamise kogemust 1985. aastal omaenda firma. Ta on öelnud, et ettevõttes töötamine tekitas temas palju stressi ning ta ei saanud aru, miks projektide õigeaegne ja edukas elluviimine ning inimeste meeskonnana tööle panemine oli niivõrd raske. Tollal lõppesid edukalt ligi 45% projektidest, mille kallal ta töötas. Inimestele ei meeldinud nende töö ja nad kippusid liikuma teistesse ettevõtetesse lootuses sealt midagi paremat eest leida.

Schwaber oli kosemudeli entusiast ning üritas seda oma projektides edutult rakendada. See pani teda mõistma, et tarkvaratööstus vajab muudatust. Ta on hiljem kirjutanud, et kosemudeli puhul eeldatakse, et tarkvaraarendus on protsessina lihtsasti hoomatav ning ootamatute tagajärgede ja probleemideta, kuid nii see tegelikkuses ei ole – tarkvaraarendus on paljudel põhjustel väga etteaimamatu.

Jeff Sutherland

Jeff Sutherland sai 1986. aastal ettevõttes Saddlebrook Corporation vastutavaks sularahaautomaatidega tegeleva osakonna eest. Seal seisis ta silmitsi traditsioonilise projektihalduse probleemidega, kus ei suudetud tähtaegadest kinni pidada ning kasutajate rahulolu ja kvaliteet olid madalad. Sutherland tahtis nendele probleemidele lahenduse leida ja seda ta ka tegi. Ta muutis sularahaautomaatide osakonna ettevõttes kõige probleemsemast ja vähem kasumlikumast üksusest kuue kuuga kõige edukamaks.

Sutherland õpetas oma meeskonda protsessi paremini juhtima, võrreldes seda lennuki maandamisega. Piloodil tuleb pikkamisi allapoole laskuda, täites ülesande ülesande haaval ja maanduda lõpuks edukalt lennurajale. Selle protsessi juures pidas ta oluliseks kolme aspekti: meeskonnaliikmete töö tulemused peavad olema kõigi jaoks nähtavad, iga liige peab vastutama talle määratud ülesannete eest ning meeskond peab suutma oma tööd ise ümber korraldada. See kogemus näitas Sutherland’ile, et on olemas vajadus uue arendusmetoodika järgi, mis sobiks paremini nii arendajatele kui klientidele ning aitaks projektidel õigeaegselt valmis saada.

Nendele kogemustele tuginedes töötasid Schwaber ja Sutherland 4-5 aastat välja uut arendusmudelit, mis oleks paindlikum, annaks liikmetele protsessi üle rohkem kontrolli, aitaks kaasa loomingulisusele ning võimaldaks paremini hallata riske ja kulutusi.

The New New Product Development Game

Ülimalt oluliseks ideede allikaks uue tarkvaraarendusmetoodika kujundamisel oli 1986. aastal Hirotaka Takeuchi ja Ikujiro Nonaka poolt avaldatud artikkel „The New New Product Development Game“. See käsitles mõnes Jaapani ja USA firmas kasutatavat uudset ja holistilist tootearenduse lähenemist, mis muutis protsessi kiiremaks ja paindlikumaks ning aitas ettevõttes muutuseid läbi suruda. Need praktikad pärinesid tollastelt edukatelt firmadelt nagu Xerox, Canon, Honda ja Hewlett-Packard. Tootearenduse meeskonna tegevust võrdlesid Takeuchi ja Nonaka ragbitiimiga, mis liikus ühtse üksusena lõppeesmärgi saavutamiseks edasi, tegutsedes koos tekkinud takistuste ületamisega . Samast artiklist pärineb ka Scrumi nimetus – ragbis nimetatakse scrumiks palli mängupanemise momenti, kus meeskondade ründajad palli oma tiimile võitmiseks rüselevad .

Takeuchi ja Nonaka tõid oma artiklis näite uue auto väljatöötamisest Toyota’s. Töötajad said korralduse valmistada auto, mille kütusekulu oleks varasematest kaks korda väiksem ja saada auto valmis kaks korda kiiremini kui senised mudelid. Traditsioonilisi meetodeid kasutades olnuks selle ülesande täitmine võimatu, kuid arendusmeeskond suurendas koostööd ja muutus iseorganiseeruvaks, et kogu protsessi kiirendada.

Sutherland leidis, et samasugust lähenemist tuleb rakendada ka tarkvaraarenduses. Eriti oluliseks pidas ta meeskondade autonoomsust, üksteiselt õppimist ja ühist eesmärkide poole liikumist, toetudes meeskonnaliikmete kirglikkusele. 1994. aastal alustas Sutherland’i osavõtul tööd esimene Scrum tarkvaraarendustiim. Järgmisel aastal avaldasid Sutherland ja Schwaber Scrumi tutvustava artikli. Mõlemad olid tegevad ka välearenduse põhimõtete („Manifesto for Agile Software Development“) kirjapanekul 2001. aastal . Kuigi Sutherland ja Schwaber sõnastasid esimesena Scrumi raamistiku tarkvaraarenduse kontekstis, peavad paljud Takeuchi ja Nonaka mõju sedavõrd oluliseks, et nimetavad neid Scrumi loojateks ka tarkvaramaailmas .

Sisu

Võtmeväärtused

Scrum rajaneb empiirikale, mis tähendab, et teadmised tulenevad kogemustest ja otsuste langetamine teadaolevatest faktidest. Mudel on iteratiivse ja järk-järgulise lähenemisega, tehes nii projektiga seotud prognoositavuse ja riskide haldamise lihtsamaks.

Scrum tugineb kolmele põhiväärtusele :

• läbipaistvus – protsessi olulised aspektid peavad olema kõigile meeskonna liikmetele nähtavad
• kontroll – vigade vältimiseks tuleb aeg-ajalt kontrollida tehtud töö vastavust soovitud eesmärgile
• kohanemine – vigade eemaldamine ja ebasoovitavate aspektide parandamine tuleb edasiste probleemide vältimiseks teha võimalikult vara

Scrum meeskond

Scrum ragbis

Scrum meeskond koosneb tooteomanikust, arendusmeeskonnast ja Scrumi juhist (Scrum Master). Scrum meeskonnad on iseorganiseeruvad ja polüfunktsionaalsed. See tähendab, et meeskond ise otsustab, kuidas neile seatud ülesannet täita ning nad ei vaja töö teostamiseks abi teistelt väljaspool tiimi – kogu vajalik kompetents on meeskonnas endas olemas.

Tooteomanik on isik, kes vastutab nende ees, kes on toote tellinud. Tema ülesandeks on olla vahelüli kliendi ja arendusmeeskonna vahel. Ta peab tagama esialgse projekti rahastamise ning veenduma, et seda jätkuks terveks tootearendustsükliks. Tooteomanik esindab kõiki, kes on panustanud projekti ja selle tulemusse. Projekti alguses kogub ta esialgsed nõuded ning paneb need tööde nimekirja (Product Backlog). Tema otsustab, millised nõuded on tähtsamad ning millises iteratsioonis neid arendama peaks hakkama. Projekti käigus kontrollib tooteomanik projekti edenemist ning kliendi vajaduste täitmist.

Arendusmeeskond vastutab toote arendamise eest. Meeskonnas pole igal liikmel kindlat rolli – nad peavad tagama selle, et tiimis oleks olemas töö teostamiseks kõik vajalikud oskused ja inimesed. Arendusmeeskond peab olema piisavalt väike, et protsessi mitte kohmakaks muuta ning piisavalt suur, et vajalike tööde teostamisega õigeaegselt hakkama saada. Keskmiselt on meeskonnas aga seitse inimest. Tüüpiliselt on seal kaks-kolm programmeerijat, kaks-kolm testijat, üks analüütik/disainer ja üks dokumenteerija. Meeskond ise otsustab, milliste nõuete realiseerimisega iga iteratsiooni jooksul tegeletakse.

Scrumi juht vastutab selle eest, et töö Scrum meeskonnas vastaks Scrum teooriale, praktikale ja reeglitele. Ta peab tagama, et kõik arendusmeeskonna liikmed, tooteomanik ning teised projekti kaasatud inimesed mõistavad arendusprotsessi. Kui tekivad konfliktid, siis peab Scrumi juht need lahendama ning tagama arendusmeeskonnale rahuliku töökeskkonna koos kõige vajalikuga.

Töövoog

Scrum raamistiku mudel

Scrumis toimub tarkvaraarendus iteratsioonides, mida nimetatakse sprintideks. Iga sprindi ajal, mis kestavad 1-4 nädalat, loob arendusmeeskond tarkvarast potentsiaalselt valmis versiooni, mis töötab ning mida on testitud. Sprintide ajaline kestvus on üldiselt kogu tootearenduse protsessi jooksul sama.

Nõuded (Sprint Backlog), mida soovitakse realiseerida ühe sprindi jooksul, on kirja pandud toote tööde nimekirja (Product Backlog), kus on kõik tarkvara nõuded järjestatud nende tähtsuse järgi. Seda, milliseid toote osi sprindi jooksul arendama hakatakse, otsustatakse sprindi planeerimise (Sprint Planning) koosolekul. Sellel koosolekul teavitab tooteomanik arendusmeeskonda, milliseid toote osi peaks nad sprindi jooksul arendama hakkama ning seejärel määrab meeskond ära, milliseid neist saaksid nad teostada. Sprindi ajal ei ole kellelgi sprindi tööde nimekirja muuta lubatud.

Iga päev algab 15-minutilise arendusmeeskonna koosolekuga (Daily Scrum või stand-up), kus arutatakse, milliste nõuetega tegeleti eelmisel päeval ning millega tegeletakse eelseisval päeval . Iga arendusmeeskonna liige vastab järgmistele küsimustele :

• Mida ma tegin eile, et aidata arendusmeeskonnal sprindi eesmärki (Sprint Goal) täita?
• Mida ma teen täna, et aidata arendusmeeskonnal sprindi eesmärki täita?
• Kas ma näen enda või arendusmeeskonna töös sprindi eesmärgi täitmisel takistusi?

Iga sprindi lõpus korraldatakse sprindi ülevaate koosolek (Sprint Review), kus tutvustatakse sprindi käigus tehtud töid, tekkinud probleeme ja tehakse vajadusel parandusi toote tööde nimekirja. Koosolekul osalevad Scrum meeskond ja toote tellija/huvirühmad. Kuuajaliste sprintide puhul on koosoleku pikkuseks umbes neli tundi, lühemate sprintide puhul vähem. Lisaks toimub pärast sprindi ülevaate koosolekut ja enne järgmise sprindi planeerimist ka sprindi retrospektiiv (Sprint Retrospective), mis on koosolek, mille käigus Scrum meeskond analüüsib enda tööd lõppenud sprindi jooksul ning otsustab, mida järgmises sprindis paremini teha. Kuuajalise sprindi puhul kestab retrospektiiv üldjuhul umbes kolm tundi, lühemate sprintide puhul vähem.

Scrumi juurutamise sotsiaalsest mõjust

On avaldatud mitmeid teadusartikleid, milles kirjeldatakse Scrumi juurutamise mõju traditsioonilistes arendusmeeskondades. Juurutamisega seoses tuuakse välja nii positiivseid aspekte kui ka probleeme.

Ei tasu eeldada, et agiilsete metoodikate juurutamiseks arendusmeeskonnas piisaks vaid meeskonnaliikmetele vastava metoodika tutvustamisest. Juurutamisprotsess nõuab muuhulgas olulisi muudatusi tööprotseduurides, tööriistades, sidekanalites, probleemilahendamise strateegiates, arendusmeeskonna liikmete rollides ja meeskonna sotsiaalses ülesehituses. Lisaks peavad muutustega kaasa minema ka teised tiimid ja osakonnad, juhtkond ning teised töötajad. Ühtlasi on välearenduse meeskonnad sotsiaalse loomuga, mistõttu vajab juurutamisprotsess muutuseid töötajatevahelises suhtluses ja koostööviisis.

Mitmed teadlased on rõhutanud suhtluse olulisust välearenduses. See hõlmab nii ametlikku kui mitteametlikku, suulist ja kirjalikku suhtlust. Tähtis roll on siin välearenduse praktikatel: igapäevastel koosolekutel, retrospektiividel ja sellel, et tüüpiliselt paigutatakse meeskonnad füüsiliselt üksteisele lähedale. Lisaks tuuakse välja sotsiaalse vastastikmõju kasvu, mis avaldub nii meeskonda liitvates kui ka lõhkuvates tegevustes. Sageli kerkivad traditsioonilistes arendusmeeskondades Scrumi juurutamisel esile inimeste isiklikud ja nendevahelised sotsiaalsed probleemid, mis suhtlust ja sotsiaalset vastastikmõju mõjutavad.

Paljud arendajad ja meeskonnad toonitavad aga Scrumi positiivseid külgi. Scrum suurendab meeskonna ühtekuuluvustunnet ja aitab liikmetes tekitada tunnet, et nende tööl ja otsustel on kaalu. Samuti suurendab see koostööd, meeskonna motivatsiooni ja vastutust, mis viib omakorda meeskonna ühise arusaamani jagatud juhtimisest, eesmärkidest, kohustustest ja ajagraafikus püsimisest.

Professionaalsed aspektid

Vähem dokumentatsiooni

Scrum vähendab märkimisväärselt arendustöö käigus loodava dokumentatsiooni hulka. Agiilsete metoodikate juures väidetakse lausa, et kood ise peaks olema dokument. Agiilsete metoodikatega rohkem harjunud arendajad lisavad pigem kommentaare koodi. Paljud arendajad aga osutavad, et vähene dokumentatsioon teeb uutel arendajatel olemasolevate projektide mõistmise ja nendele muudatuste tegemise väga keeruliseks.

Dokumentatsiooni vähendamise eesmärgiks on Scrumis arendusmeeskonna sees oskusteabe jagamine ja seeläbi selles osas kõigi liikmete võrdsena hoidmine. Kui aga seda õigesti ei tehta, võib sellest tekkida suur probleem. Näiteks, kui arendusmeeskonna peamine arendaja peaks töölt lahkuma, võib ettevõttel kuluda kuid tekkinud oskusteabe lünga täitmiseks. Praktikas on selliste situatsioonide täielik vältimine aga sisuliselt võimatu.

Koosolekud

Samuti tuleb Scrumis pidada kinni koosolekute reeglitest ja headest tavadest – nii on nendest kõige rohkem kasu. Koosolekute ajaline kestvus on ette määratud ja need ei tohiks venida pikemaks. Seoses paindliku töögraafikuga võivad tekkida probleemid ka koosolekute ajastamisega. Näiteks, kui koosolekud toimuvad hommikuti ja meeskonnaliikmed tulevad tööle erinevatel aegadel, võib koosoleku pidamine häirida nende inimeste keskendumist, kes jõudsid tööle juba varahommikul.

Klientide pühendumus

Scrumi, nagu ka teiste agiilsete metoodikate, puhul on oluline, et klient oleks arendusprotsessi loomulik osa alates tarkvara analüüsist kuni juurutamiseni välja. Seetõttu võib kliendi pühendumus paljudel puhkudel mängida projekti õnnestumise juures väga olulist rolli – kui kliendi esindajad ei ole altid arendusmeeskonnaga suhtlema, on suurem tõenäosus, et tulemus ei ole see, mida nad ootasid.

Töökeskkond

Scrumi sotsiaalse loomu tõttu sobib protsessiks paremini avatud ruum kui vaheseintega eraldatud ruum või eraldiseisvad kabinetid. See mõjub hästi meeskonna suhtlusele ja avatusele, kuid ei pruugi kõigile arendajatele sobida, sest ruumis võib olla mitmeid keskendumist segavaid faktoreid . Teadlased on aga uurinud ka ruumi ümberkujundamise lahendusi, et see toetaks Scrumi protsessi paremini ning annaks töötajatele võimalusi keskendumiseks ja puhkamiseks . Samuti on Scrumi võimalik edukalt rakendada ka kaugtöös .

Mõju arendajatele ja meeskondadele

Scrum võib mõjuda arendajatele väga motiveerivalt, sest see toetab üksteiselt õppimist, suurendab meeskondade ja nende liikmete autonoomsust ning soodustab inimestevahelisi suhteid. Isiklikel konfliktidel võib aga motivatsioonile olla negatiivne mõju, seetõttu peaks kogu meeskond arvestama üksteise isikupäradega . Kui meeskonna ühtekuuluvustunne on madal, liikmetevahelised suhted kehvad või inimesed vähemotiveeritud, soovitatakse meeskondade ümberorganiseerimist, projektijuhi rolli kaasamist, paaristöid ja motivatsiooni tõstmise meetmeid . Lisaks võib Scrumi mudelist tulenev suurem vastutus ja mudeli enda keerukus võrreldes traditsiooniliste tarkvaraarenduse metoodikatega viia arendajate läbipõlemiseni ja avaldada mõju mudeli sobivusele pikas perspektiivis .

Võimalikud väljakutsed Scrumi juurutamisel

Scrumi juurutamise juures on välja toodud mitmeid esineda võivaid väljakutseid .

Isiklikud väljakutsed:

• Töötajate suhtumise ja mõttemaailma muutmine
• Vajadus eriti andekate töötajate järele
• Töötajate vähene motiveeritus ja pühendumus
• Liialt entusiastlikud töötajad
• Välearenduse kogemuse puudumine
• Laiemate oskustega arendajate vähesus
• Kokkupuude väheste oskustega töötajatega
• Ebapiisav õppimisvõime
• Sotsiaalselt aktiivne olemisega kaasnev stress
• Meeskonnatööoskuse efektiivsus

Sotsiaalsed väljakutsed:

• Avatus ja teistesse töötajatesse suhtumine
• Vähene suhtlemine
• Vähene koostöö
• Usaldus ja ühised mõttemudelid
• Ühine juhtimine
• Ühine õppimine koos meeskonnaga

Väljakutsed juhtkonnale:

• Juhtimine mikrotasandil
• Juhtkonna suhtumine
• Organisatsiooni mõju ja kontroll
• Jagatud inimressursid

Organisatsioonilised väljakutsed:

• Kultuur
• Struktuur
• Muutuste juhtimine
• Teadmiste juhtimine
• Premeerimissüsteem
• Vananenud otsustusmudelid
• Spetsialistide kultuur
• Logistilised probleemid
• Välearenduse teostamise hindamine

Projektidega seotud väljakutsed:

• Projekti teostamine
• Progressi jälgimine
• Tehtud töö nähtavus teiste jaoks
• Kliendi panus
• Töö sünkroniseerimine
• Vähene arusaam äriloogikast

Võimalikud tegevused Scrumi juurutamise toetamiseks

Traditsioonilistes tarkvaraarenduse meeskondades Scrumi juurutamise toetamiseks on mitmeid võimalusi .

Teadlikkuse suurendamine:

• Töötajate, meeskonna ja organisatsiooni probleemide kindlaks tegemine
• Töötajatele arvamuste, tunnete, kahtluste ja hirmude väljendamiseks võimaluse loomine
• Toimepandavatele muudatustele osutatava eeldatava vastupanu vähendamine
• Töötajate motiveerimine
• Toimepandavate muudatuste kohta info jagamine

Organisatsioonipoolne sekkumine:

• Juurutamisprotsessi suunamine ja tekkivate probleemidega tegelemine
• Avatud õhkkonna loomine arvamuste, ettepanekute ja tagasiside esitamiseks
• Konfliktide lahendamine ja toimepandavatele muudatustele soodsa pinnase loomine
• Ametlike suhtlusmehhanismide ja tööprotsesside määratlemine
• Töötajate jaoks organisatsiooni väärtuste omaksvõtmise hõlbustamine

Meeskonnatöö:

• Töötajate arengu hõlbustamine ja inimestevaheliste sotsiaalsete võimete arendamine
• Meeskonnatöökultuuri loomine
• Töötajate sotsiaalsete võimete arendamine (usaldus, empaatiavõime, avatus tagasisidele, muutustega kohanemine, oskusteabe jagamine jms)
• Töötajate isejuhtimisvõimete arendamine

Muu:

• Tööruumi muutmine meeskonnatöö ja suhtlemise parandamiseks
• Scrumi olemuse, rollide ja tegevuste selgitamine
• Scrumi praktikate juurutamine, uute väärtuste omaksvõtt ja koostöötegevuste rakendamine

Kanban

Mis on Kanban?

Kanban on töövoo manageerimise meetod, mille disain aitab töö tegemist visualiseerida ning kasutada maksimaalselt produktiivsust ning efektiivsust. Sõna pärineb jaapanikeelsest sõnast “kamban”, mis tähendab suurt kuulutuse plakatit (ingl.k billboard) või kaarti. Selline töömetoodika sai alguse juba möödunud sajandi keskpaigas tootmissektoris, tarkvaraarendusse jõudis see tükk maad hiljem. Tänapäeval on tegu metoodikaga, mis on kasutuses üsna mitmes eluvaldkonnas.

Kanbani algus

Taiichi Ohno

Kanban kui metoodika sai alguse 1940ndate Jaapanis, kus Toyota insener Taiichi Ohno soovis parandada autotööstuse kitsaskohti ning muuta Jaapani autotööstus efektiivsemaks ja kiiremaks kui nende Ameerika konkurentidel. Selle lahenduse, mille algne nimetus oli “just-in-time production”, eesmärk oli kontrollida ja manageerida tööd ja inventari optimaalselt igal tootmissammul – vähendada mitteolulisi tegevusi nii, et ka produktiivsus ei langeks. Tänu sellele lähenemisele suutis Toyota jõuda paindliku ja efektiivse tootmisvooni – tootmine sõltub klientide nõudlusest, aga mitte mentaliteedist toota võimalikult palju asju võimalikult kiiresti, mis oli tolle aja standardiks.

Ohno on öelnud: “The two pillars of the Toyota production system are just-in-time and automation with a human touch, or autonomation. The tool used to operate the system is kanban.". Seega tuleb Kanbani puhul vaadata kogu süsteemi. Ideaalses süsteemis on kontrolli all kogu tootmisahel alates tooraine saamisest kuni lõppkasutajateni jõudmiseni. Tänu sellele on võimalik vältida toorainete ülejääki, kuid samas pakkuda klientide nõudluse vastava hulga lõpptooteid. See tähendab, et kogu tööl tuleb hoida silma peal ning erilist tähelepanu tuleb pöörata olukordadele, mis võivad saada nö pudelikaelaks tootmises. Aja jooksul on selline mõtteviis jõudnud Jaapanist kaugemalegi.

IT sektorisse jõudis antud metoodika alles käesoleva sajandi alguses, kui David Anderson seda 2004. aastal Microsoftis tutvustas. Selle eesmärk oli limiteerida samal ajal töös olevate tööde hulka ning kasutada nö pull approach’i. See tähendas seda, et vastupidiselt sellele, et arendajatele söödetakse järjest ette ülesandeid, millega kohe tegelema peab hakkama, saab arendaja alustada uue taskiga, kui eelmine on lõpetatud. Nüüdseks on see metoodika jõudnud väga paljude IT inimeste ja ettevõtete tööprotsessi.

Tuleb aga mainida, et kuigi kanban on ITs laialdaselt kasutusel ning seda kõrvutatakse tihti Scrumiga, ei ole selle näol tegemist tarkvaraarenduse- või projektiplaneerimise metoodikaga. Kanban ei ütle, kuidas tarkvara peaks arendama, planeerima või implementeerima. Seega pole Kanban juhtimisraamistik nagu seda on Scrum. Kanbani eesmärk on hoopis pidevalt parandada tööprotsessi kui tervikut. Seetõttu on Kanbani võimalik kasutada erinevate arendusmetoodikate raames, olgu selleks agiilsed meetodid nagu Scrum või Ekstreemprogrammeerimine, või traditsioonilisemad nagu waterfall – Kanbani abil saab nende kõikide tööprotsessi parandada ning töövoogu efektiivsemaks muuta.

Kanbani eripärad

Visualisatsioon

Näide Kanban board'ist

Visualiseerimine on oluline osa mõistmaks töövoogu ning tööd ennast. Seega on oluline luua raam, mis:

• On ühine kõikidele asjassepuutuvatele inimestele
• On eritähenduslik erinevatele inimestele

Üheks selliseks vahendiks/raamiks on Kanbanis ilmselt kõige tuntum Kanban board ehk vahend, millega märkida ära töövoog, ülesanded ning nende staatused.

Sõltuvalt ettevõttest ja board’i loojast, saab tahvlit kujundada erinevate värvide, kujundite ja materjalidega. Tarkvaraarenduses jaguneb tahvel tavaliselt mitmeks tulbaks, mis kujutavad endas ülesannete staatusi. Iga ülesannetega tegeleja peab hoidma tahvlit ajakohasena ning liigutama enda ülesandeid vastavalt staatusele järgmistesse tulpadesse.

Kanban board’i kasutamise tulemusena on võimalik märgata töövoos tekkinud probleeme (nt pudelikaelad, blokaatorid jne) kiiremini, tagades selle, et tiimil on võimalik sujuvamalt liikuda oma eesmärkide poole. Samuti on võimalik märgata probleeme, mis võivad potentsiaalselt kogu protsessi kulgu aeglustada – riskide manageerimine ja ohuolukordade avastamine on mugavam.

Kanbani praktiseerimise lihtsustamiseks on loodud mitmeid tööriistu, sh Jira, Trello ja Hygger.

Töös olevad ülesanded (Work In Progress e WIP)

Kanban limiteerib tööde hulka, mis võivad olla korraga “In progress”, st kasutatakse pull metoodikat. Pull ja push metoodikate erinevusest arusaamiseks võib tuua näite kirjaklambritega. Kui ühendada üksteise külge mitu kirjaklambrit ning panna need lauale, siis lükates viimast kirjaklambrit esimese suunas, tekib tõenäoliselt tropp ning kirjaklambrid kuhjuvad. Samas, kui tõmmata esimest kirjaklambrit edasi, liigub kogu kirjaklambrikett vabalt ning tõrgeteta.

“In a pull system, work is processed through being signalled, rather than being scheduled.”

Tarkvaraarenduses tähendab pull süsteem seda, et kuigi ülesandeid võib tulla juurde, on see tiimiliikme ülesanne otsustada, kas ta saab seda sel hetkel teha või mitte. Mida rohkem võetakse ülesandeid, seda rohkem saab neid juurde luua. Kui aga ülesandeid kiiresti ei võeta, on see signaal, et uusi ülesandeid juurde luua pole mõtet, et vältida ülesannete kuhjumist. Push süsteem tähendaks aga, et ülesandeid loodaks juurde hoolimata sellest, kas on ressurssi neid lahendada või mitte.

Work in Progress’i limiteerimisel on suur mõju produktiivsusele ning tiimitööle.

Pidev areng (Continuous Improvement)

Kanbani süsteemi üks suurimaid eesmärke on üleüldse Kanbani süsteemist lahti saada. See tähendab, et tiimiliikmed peaksid alati otsima võimalusi, et töö liiguks edasi, mitte hoidma ennast kogu aeg rakkes. “Kanban is something you strive to get rid of, not be proud of”.

Ühe võimaluse selleks annab WIP limiitide vähendamine. Kui piiravama limiidiga (st korraga võib laual olla vähe ülesandeid) töövoog paistab sujuvalt edasi liikuvat, võib suurendada "In progress" ülesannete arvu, et tuua välja järgmised kitsaskohad ja pudelikaelad.

Vajadust limiidi muutmisele aitab leida retrospektiiv, kus tiimiliikmeid saavad arutada, kas tööd on liiga palju või vastupidi. Kui on pigem vähe, saab suurendada "In progress" ülesannete arvu ning pakkuda tiimiliikmetele rohkemate ülesannete näol uut arengut.

Eesmärk on liikuda pidevalt “Flow zone”s. Mike Rother ja John Shook on öelnud Kanbani kohta: “Flow where you can, pull when you must”.

Fookus töö lõpetamisel (Focus on Completing Instead of Starting Work)

Erinevate uuringute kohaselt satub 60% IT sektoris töötavatest inimestest mingil hetkel olukorda, kus toimub läbipõlemine (burn-out). Selle põhjuseks on suuresti see, et töötajad peavad tihti end ümber lülitama mõnd teist ülesannet tegema, mistõttu tuleb end uuesti teise konteksti seada. Gerald Weinberg on oma raamatus “Quality Software Management: Systems Thinking” öelnud, et 20% ajast läheb kaduma iga uue ülesande puhul. Seega kui ainult ühe ülesande tegemine korraga tähendab 100% ajakulu sellele ülesandele, siis kaks ülesannet korraga tähendab, et mõlema ülesande jaoks on keskmiselt 40% koguajast, kolme ülesande puhul on ühe ülesande ajakasutus 20% jne. Seega, mida vähem ülesandeid, seda väiksem ajakadu. Teada on, et multitaskimine kaugele ei vii. Lõppkokkuvõttes on ülesannete järjestikku tegemine tulemust andvam, kui nende samaaegne tegemine.

Kanbani metoodika vähendab võimalust ülesannete vahetamise tõttu läbi põleda, kuna limiteerib ülesannete hulka, mis võivad korraga olla tegemises. Seda kas üksikisiku seisukohast või kogu protsessi seisukohast. See tähendab, et töötajad saavad rohkem keskenduda käesolevale ülesandele ning viia see enne lõpule, kui nad uut alustavad. Ühelt poolt vähendab see aega, mis kulub ülesande lõpetamisele, teiselt poolt soodustab ka tiimitööd, kuna annab võimaluse aidata teisi tiimiliikmeid, kui oma ülesanded saavad tehtud ning uusi veel võtta pole vaja.

Seega Kanbani seisukohast on igal arendajal neli valikut, järjestatud prioriteetselt :

• Tööta edasi ülesande kallal, mille oled endale võtnud
• Aita tiimiliikmeid, et vältida pudelikaela efekti
• Alusta mõne uue ülesandega, kui on ülesandeid, mida teha
• Leia midagi muud kasulikku, mida teha

Eneseorganiseerimine (Higher Rate of Self-Organization)

Projektijuhtimine ja sellega kaasas käivad nõuded on vajalikud, et saavutada projekti eesmärgid. See eeldab pidevat kontrolli projektijuhi poolt ning pidevat töötajate manageerimist. Kanbani puhul on palju rõhutud sellele, et kõik tiimiliikmed teavad iga hetk, mida nad peaksid tegema ja millega ametis olema, ilma, et seda neile pidevalt öeldaks. Tänu sellele on tiimiliikmetel parem eneseorganiseerimise võimalus, mistõttu ollakse positiivsemalt meelestatud oma ülesannete suhtes ning lõppkasutajateni jõuab kvaliteetsem ja läbimõeldum toodang.

Tiimi motivatsioon (Team Morale Improvement)

Üks põhilisi Kanbani aspekte on pidev tagasiside saamine lõppkasutajatelt. See aitab töötajaid hoida ülesande fookuses ning olla osake nö suuremast masinast. See aitab kaasa ka töötaja rahulolule, kuna ta teab, et tema tööd hinnatakse ja vaadatakse pidevalt üle. Lisaks tõstab see personaalse heaolu taset, mis omakorda võimendab heaolu ka kogu tiimis või töötajaskonnas.

Kanban kokkuvõtvalt

Kokkuvõtvalt võib öelda, et Kanbanil on palju eeliseid, mis teevad projekti manageerimise efektiivsemaks. Kanbani tugevused on :

• Suurenenud läbilaskevõime – Kuna tiimiliikmed ei pea ootama, kuni neile ülesanne kätte antakse, vaid saavad ise olemasolevate hulgast valida, vähendab Kanbani kasutus jõude istumise aega.
• Parem suhtlus – Tiimiliikmed näevad ülevaatlikult kõikide ülesannete staatuseid Kanban board’ilt. Kanbani üks põhimõtetest on ka igapäevaste stand-up’ide tegemine, mis sunnib tiimiliikmeid oma tööst igapäevaselt aru andma, mis omakorda annab teistele tiimiliikmetele selgema pildi kogu olukorrast. See on heaks võimaluseks leida ka kitsaskohti ning üksteist ülesannetes aidata.
• Paindlikkus – Kanban on üsna paindlik raamistik, kuna võimaldab ülesandeid lisada ja eemaldada mistahes hetkel (kui need ei ole juba töös). Kanbani rakendamisel puuduvad piiravad reeglid, mistõttu on raamistikku võimalik kasutada igas valdkonnas. Samuti puuduvad kindlad rollid, mis tiimis peavad olema, mis võimaldab raamistikku juurutada mistahes tiimide sees.
• Vähendatud ressursikulu – Kuna tiimiliikmed teevad tööd efektiivselt, vähendab see nende tegevuste hulka, mis pole otseselt ülesannetega seotud. See tõstab valmis saadud ülesannete hulka märgatavalt. Kanbani kasutajate hulgas on see tugevus üheks määravamaks, miks neile Kanbani kasutada meeldib.

Kuigi Kanbanil on hulganisti projekti käekäigu sujuvust ja kvaliteeti soodustavaid mõjureid, pole siiski tegemist ideaalse metoodikaga. Kanbani nõrkadeks külgedeks võib pidada :

• Võib kiiresti laguneda – Kanbanil on kaks tegurit, millest ühe puudumisel võib kogu protsessimajandus kokku kukkuda: hästi defineeritud protsess ning tiimi teadlikkus protsessidest ja oma rollist nendes. Kui juba üks tiimi liige ei tea päris täpselt, mida temalt oodatakse, võib see doominoefektina mõjutada ka teisi tiimiliikmeid ning kogu tööd.
• Tingib vajaduse pidevaks tööks – Vajalik on tiimi pidev töö. Kui tekib tööta olemise olukordi, annab see tunda järgmistes etappides, kus töö maht on suurem.
• Puuduvad ajalised piirangud – Kuna Kanban ei määra ülesannetele ajalist raamistikku, võib ajakavas püsimine osutuda keeruliseks (eriti, kui paralleelselt ei kasutata mõnda arendusraamistikku, nt Scrumi). Tiim peaks oskama ennustada tööks kuluvat aega ning see võiks olla märgitud ka ülesannete juurde.
• Kõrgema prioriteediga tööd võivad jääda tagaplaanile – Kuna tiimi liikmetel on vaba voli valida endale ülesandeid, mida järgmisena teha, võivad kõrgema prioriteediga ülesanded jääda tähelepanuta. Seetõttu tuleks tiimis kokku leppida ülesannete prioriteedid ning võimaluse korral lahendada enne need, mis on ärile olulisemad.

Kasutajaskond

Uuringuid selle kohta, kui palju kasutatakse spetsiifiliselt Kanbani tänapäeva tarkvaraarendustes, pole tehtud. Küll aga on teada, et agiilseid arendusmetoodikaid (või nende poole kallutatud metoodikaid) kasutatakse nii palju, et tõenäoliselt ületab see varsti traditsioonilisemate meetodite kasutamise .

Agiilseid meetodeid, sh ka Kanbani, kasutavad mitmed suurkorporatsioonid oma IT arenduses . Näiteks Spotify, VMWare, Volvo IT, Auto Trader ja Blizzard Sport. Need ettevõtted on tõestuseks, et isegi kõige lihtsam Kanbani kasutus võib positiivselt mõjutada IT-tiimide protsesse. Ian Carrol on öelnud: “The beauty of Kanban is that you start with what you do now.” .

Kuigi Kanbani positiivsed küljed kaaluvad tihti üles negatiivsed küljed, siis Kanban iseenesest ei garanteeri edu. Uuringuid selle kohta, kas ja kuidas on Kanbani kasutamine mõjutanud tarkvaraarendust, on vähe. Ühes uurimistöös on kirjutatud, et Kanbani pole võimalik eraldiseisvalt õppida, vaid samal ajal tuleb õppida ka workflow, flow diagrammide, burn-down graafikute ja muu sellise kohta. Autorite poolt pakuti välja, et tulevikus võiks uurida Kanbani kasutust ka reaaleluliste andmetega töötamisel ning analüüsimisel; ja julgustati veelgi Kanbani süvitsi uurima ning selle mõju hindama.

Teises uuringus , milles uuriti Scrumi ja Kanbani mõju tarkvaraarenduse projektidele, leiab, et mõlemad meetodid tagavad edukaid projekte. Uuring põhines vastanute statistikal ning käsitles eelarvest kinnipidamist, riskihaldust, tulemi kvaliteeti, olemasolevate ressursside hulka, projekti skoopi ning ajagraafikust kinnipidamist. Kuigi vastustest ei selgunud, kumb metoodika on neid aspekte silmas pidades oluliselt parem, leiti, et ajagraafikus püsimise koha pealt on Kanban parem kui Scrum. Tegemist oli siiski uuringuga pigem tehnilisest vaatepunktist ning autorid loodavad tulevikus uurida nende meetodite mõju ka tiimitööle, tööjaotusele ja läbipaistvusele.

Ekstreemprogrammeerimine

Eelmises kahes jaotises oli juttu agiilsetest metoodikatest Scrum ja Kanban. Need kaks ei välista teineteist. Vastupidi — nende kahe kooslus on küllaltki levinud nähtus ning see kannab nime Scrumban. Scrumban ühendab endas mõlema metoodika parimad küljed, parendamaks projektide ülalpidamist. Kanban annab võimaluse Scrumi võlusid veelgi efektiivsemalt rakendada. Scrumban on tänapäeval väga populaarne.

Ekstreemprogrammeerimine (ingl. k. Extreme Programming, XP) on aga teistsugune ning pakub terviklikumat ja spetsialiseeritumat lähenemist, keskendudes just programmeerimise ja arendustöö efektiivsusele. Antud arendusmetoodika puhul on tegemist ühe tervikuga. Suur osa XP kommuunist leiab, et kui kasutusel ei ole kõik XP printsiibid, siis ei ole tegemist õige XP arendusega .

Ajalugu

Kent Beck

Töö ekstreemprogrammeerimise kui arendusmudeli välja töötamiseks sai alguse aastal 1996. XP väljatöötamise keskkonnaks oli Chrysler Comprehensive Compensation System (C3), mille arendus vältas aastatel 1993 kuni 1999 ning mille eestvedaja (nagu nimestki võib välja lugeda) oli ettevõte Chrysler. Võib öelda, et C3 oli XP kasvulava. C3'e arendustiimi kuulus terve rida mõjukaid tarkvarainsenere, kes olid osa XP väljakujunemisest. Kõne all oleva arendusmetoodika loojaks on Kent Beck, kes oli ka juhtiv tarkvarainsener C3's. Teiste nimedena toob viidatav allikas välja järgnevad: Ron Jeffries, Ward Cunningham, Don Wells ja Martin Fowler. Nad kõik on oma valdkonna eksperdid ning vastavates ringkondades hästi tuntud.

Kent Beck liitus C3 projektiga aastal 1996. Selleks ajaks oli projekt olnud tegemisel kolm aastat, ent projekti tulemina loodav programm ei olnud veel toimiv. Projektile anti veel veidi üle kahe aasta arendusaega juurde ning sellesse investeeriti miljoneid dollareid. Lõpuks, aastal 1999, jäeti projekt katki. Sellest hoolimata oli C3 projekti algne edu see, mis andis XP-le vajaliku tõuke. Ühe suurema läbimurdena võib näha C3'e tiimi produktiivsuse ja samal ajal ka koodikvaliteedi tõusu. Sellised positiivsed muutused saavutati tööstuses kasutatavate metoodikate (nagu Lean tootmine) rakendamisel tarkvaraarenduses.

Martin Fowler on toonud välja, et tõsisem arendustöö C3 projekti kallal algas aastal 1995, programmeerimiskeeles Smalltalk, aga kuna projekti viimine stabiilsesse seisu ebaõnnestus, tehti sellele restart. Selles uuesti alustatud projektis leidsid rakendust kõik praktikad, mis on tänasel päeval tuntud ekstreemprogrammeerimise nime alla koondatult.

C3 projekti liikmed jätkasid XP metoodika arendamist pärast projekti lõppemist aastal 1999. Ekstreemprogrammeerimine on viimase kahe kümnendi jooksul tasapisi kogunud populaarsust ning nüüdseks on selle meetodid ja põhimõtted võtnud omaks tarkvaraarendusjuhid üle maailma.

Lühitutvustus

Paarisprogrammeerimine

Ekstreemprogrammeerimine on edukas, sest see seab tähtsale kohale kliendi rahulolu. XP protsess tarnib tarkvara, mida klient vajab, ajaks, mil tal seda vaja läheb. Ekstreemprogrammeerijad on võimelised reageerima klientide muutlikele nõuetele, isegi kui need tulevad arenduse hilises faasis.

XP seab tähtsale kohale ka meeskonnatöö. Meeskonnaliikmeid — juhte, kliente ja arendajaid — käsitletakse võrdsete partneritena kaastööd tegevas tiimis. Vajadusel (kui ekstreemprogrammeerimine on tiimi meeskonna jaoks uus lähenemine) kaasatakse ka treener (Coach) . XP aitab luua lihtsa, aga efektiivse keskkonna, mis aitab meeskondadel saavutada kõrge produktiivsuse .

Ekstreemprogrammeerimist iseloomustavad viis põhilist märksõna:

1. kommunikatsioon — suhtlus nii klientidega kui ka arendajate vahel;
2. lihtsus — implementatsioonid tuleb hoida lihtsa ja puhtana;
3. tagasiside — tarkvara testitakse esimesest päevast alates; klientidele tarnitakse tarkvara nii vara kui võimalik ning võetakse arvesse nende tagasisidet;
4. austus — kujuneb läbi iga tiimiliikme unikaalse panuse ja väikeste võitude;
5. julgus — eeltoodu loob vundamendi, tänu millele on võimalik julgelt reageerida muutuvatele nõuetele ja tehnoloogiatele.

Ekstreemprogrammeerimise reegleid on päris mitmeid, neid kõiki käesolevas töös välja ei tooda. Need kategoriseeritakse planeerimise (Planning), halduse (Managing), disainimise (Designing), koodi kirjutamise (Coding) ja testimise (Testing) alla. Siinkohal tasub välja tuua väikeste reliiside, iteratsioonideks jaotamise, avatud tööruumi, stand-up'ide, TDD (test driven developmenti) ja testide katvuse olulisuse. Üks oluline XP metoodika osa on ka paarisprogrammeerimine .

Projektihaldus

Riskihaldus / väikesed reliisid

Ekstreemprogrammeerimine kasutab ära teadmist, et väiksematel projektidel on kõrgem edutõenäosus, tükeldades kõik tarkvaraprojektid mitmeks väiksemaks reliisiks. Igaüks nendest koosneb väiksemast osast nõutavast funktsionaalsusest. Selline lähenemine võimaldab kliendil ja lõppkasutajatel arendustulemustega juba varakult tutvuda ning seeläbi anda kvaliteetsemat ja täpsemat tagasisidet. Asjakohasem tagasiside tagab parema tellija ja täitja vahelise koostöö. XP-s on soovitatavaks reliisidevaheliseks ajaks kaks kuni kaheksa nädalat, sealjuures pidades silmas, et väiksem ajavahemik on parem. Varajaste reliiside pealt avastatud probleemid aitavad õigeaegselt juhtida projekti kulgu. Reliisid eeldavad demonstreeritavat tarkvaratulemit. Isegi kui projekt peaks enneaegselt lõppema, omavad juba loodud tulemid vähemalt mingit väärtust tellivale osapoolele.

Integratsioonihaldus

Ühes teadusartiklis toodi välja, et ekstreemprogrammeerimine keskendub programmeerijate tööpanusele. Mõned XP pooldajad leiavad, et tehniliste kirjutajate (technical writers), andmebaasihaldurite ja kvaliteedi tagamise spetsialistide panus pole vajalik. Siiski, kõne all olev metoodika ei välista nende töö integreerimist, kes ei ole tarkvaraarendajad. Eelmainitud väikesed reliisid teevad integratsioonihaldusest järjepidevama protsessi, võrreldes mõnede teiste protsessidega, mille kohaselt paigutub tarne, dokumenteerimine ja testimine ajaplaani lõppu.

Tarkvaraarendajate suhtes on ekstreemprogrammeerimine konkreetne — arenduses peab olema kesksel kohal pidev integratsioon (ingl. k. Continuous Integration) ja see peaks toimuma igapäevaselt. Ehkki selline praktika võib nõuda arendajatelt lisatööd, võimaldab igapäevane CI tiimil tuvastada probleeme märksa varasemalt.

Aja- ja skoobihaldus

Ekstreemprogrammeerimise puhul läheb põhiline planeerimistöö hästi läbimõeldud tööjaotusstruktuuri (Work Breakdown Structure) ja selle juurde kuuluvate tööpakkide (Work Packages) välja töötamisele. XP ei räägi tööjaotusstruktuurist ja tööpakkidest otse, ent uurides ekstreemprogrammeerimises kasutatavaid Story Card'e, võib täheldada nende suurt sarnasust tööpakkidega.

Planeerimismäng

Tööpakid pannakse kirja käsitsi kirjutatud kirjeldustena ning nende skoop on kasutajat puudutav funktsionaalsus. Nagu eelmises lõigus mainitud, on nende kaartide nimeks Story Card'id. Antud nimi tuletab projekti osalistele meelde, et need peavad kirjeldama lugu, mida kasutaja võib soovitavast funktsionaalsusest rääkida; need ei peaks kirjeldama tehnilist funktsionaalsust arendaja vaatepunktist. Story Card'e kasutatakse, et töötada välja hinnanguid, koostada tarkvara ehitamise ajakavasid, autoriseerida arendajate tööd, juhtida testimist ning raporteerida staatust.

Ekstreemprogrammeerimises on planeerimise poolel olulisel kohal töö autoriseerimised. Neid tehakse iga iteratsiooni juures, üldiselt iga kahe nädala tagant. Iga iteratsiooni alguses annavad arendajad meeskonnana hinnangu kõikidele olemasolevatele Story Card'idele. Kui Story Card läheb mahult liiga suureks (ületab iteratsiooni kestust), siis tükeldatakse see kaheks või enamaks väiksemaks Story Card'iks, mis kollektiivselt vastavad esialgse kaardi funktsionaalsusele. Nendele uutele Story Card'idele (teisisõnu tööpakkidele) antakse samuti hinnangud.

Kui lood (stories) on hinnatud, siis need grupeeritakse kasulikku funktsionaalsust sisaldavatesse reliisidesse. Nagu eelnevalt mainitud, kaasab XP kliendi arendusprotsessi juba varakult. Reliisid aitavad kliendil ja arendajatel jõuda üksmeeleni selle osas, kas projekt liigub soovitud suunas. Reliisid omakorda tükeldatakse kahenädalasteks arendusiteratsioonideks. Lood paigutatakse iteratsioonidesse eelkõige ärilist väärtust ning kuluhinnanguid arvestades; arendusefektiivsus on siinkohal pigem teisejärguline.

Käesoleva iteratsiooni lood tükeldatakse arendajate ühisarutelu käigus lihtsamateks arendusülesanneteks või tegevusteks, mis jaotatakse üksteise vahel. Pärast seda algab töö. Kui mingi lugu või ülesanne saab valmis, siis märgitakse see tehtuks kõigile nähtaval viisil. Nagu eelnevalt mainitud, on XP-s oluline koht töö autoriseerimisel. Arendajad tohivad tööd teha ainult autoriseeritud lugude kallal. Kui arendajad soovivad muuta arendusstrateegiat, siis tuleb Story Card'id ümber kirjutada, uuesti hinnata ja ajastada.

Iga iteratsiooni kohta arvutatakse mõõdikud. Kaks nendest on Kiirus (Velocity) ja Eilne Ilm (Yesterday's Weather). Kiiruse arvutamiseks liidetakse kokku iteratsiooni käigus valmis saadud kasutajalugude hinnangud, samuti ülesannete hinnangud . Mõõdik Eilne Ilm põhineb metafooril, et tänane ilm on tõenäoliselt sama, mis eile. Üle kantuna tähendab on antud mõõdiku tähendus, et praeguse (sprindi) olukorra hindamiseks tasub olla teadlik sellest, mis toimus varasemalt. Olukorra hindamine on oluline, et vältida arendajate ülekoormust . Ekstreemprogrammeerimises eelistatakse muutuvate tarnimiskuupäevade asemel ujuvat skoopi.

Kvaliteedihaldus

Töötulemi kvaliteedi hoidmine võib ekstreemprogrammeerimise puhul osutuda keeruliseks, kuna programmeerijad liiguvad nii ühelt tööautoriseerimiselt teisele kui ka erinevate koodiosade vahel. Seetõttu nõuab XP kõrgelt distsiplineeritud lähenemist, saavutamaks vabaduse ressursside määramisel ilma kvaliteedis allahindlusi tegemata.

Lihtne disain, refaktoreerimine

Esimene oluline põhimõte, mis aitab saavutada ja hoida kvaliteeti, on lihtsale disainile fokusseerumine. Selle asemel, et püüda saavutada ülipaindlikku koodi, mis sobituks potentsiaalsete uuendustega tulevikus, keskendub ekstreemprogrammeerimine koodile, mis vastab praegustele autoriseeritud tööpakkidele. Tulevaste featuuride ja lugude implementeerimiseks täiustatakse ja parendatakse koodi pidevalt. Seda praktikat nimetatakse refaktoreerimiseks. Refaktoreerimine toimub samm-sammu haaval ning selle hõlbustamiseks on vajalik automatiseeritud kvaliteedikontroll. Järgmise refaktoriseerimissammu juurde ei minda enne, kui ollakse veendunud, et kõik toimib endiselt.

Testimine

Automatiseeritud testimine on vajalik, et oleks võimalik praktikas saavutada sajaprotsendiline kvaliteedikontrolli testide läbivus pärast igat järk-järgulist programmeerimissammu. Igal avalikul meetodil ja funktsioonil peab olema spetsifikatsioon automatiseeritud testide näol. XP-s on nõutud, et ühiktestid peavad olema loodud enne koodi, mis peab neid teste läbima. Sellise programmaatilise spetsifikatsiooni selge eelis tuleneb asjaolust, et arvuti saab automaatselt verifitseerida koodi vastavust nõuetele.

Paarisprogrammeerimine

Ekstreemprogrammeerimise kohaselt toimub produktsioonikoodi kirjutamine ainult paarides — kaks arendajat istuvad ühe arvuti taga. Paarisprogrammeerimine viib ellu kollektiivomandi (collective ownership) põhimõtet palju paremini kui koodiülevaatamised (code review). Kahekesi programmeerides võidavad tüüpiliselt mõlemad osapooled ning see aitab tõsta ka tiimitunnetust. Paarisprogrammeerimise partnerid ei taha teineteist alt vedada — vastupidi, nad näevad eraldi vaeva, et järgida tiimis kehtestatud kokkuleppeid ja tavasid. Paaride liikmete vahetamise teel saavutatakse värskus ning informatsiooni liikumine.

Kasutus hariduslikus keskkonnas

Ekstreemprogrammeerimine sobib meeskondadele, kus on kuni 12-15 tiimiliiget. Käesolevas peatükis on kasutatud teadusartiklit, mis leiab, et sama meeskonnaliikmete maksimumarv on kasulik lõpuaasta Tarkvaratehnika bakalaureuse õppekava projektide jaoks. Seetõttu leiavad artikli autorid, et XP kasutamine on antud tudengiprojektide puhul teostatav.

Mõned XP printsiibid on tudengite poolt olnud üsna leigelt vastu võetud. Nendeks on näiteks testimise olulisus (eriti just testide kirjutamine enne koodi kirjutamist), fookus kvaliteetse tarkvara kirjutamisel algusest peale, koodikirjutamis-standardite ja konfiguratsioonihalduse olulisus. XP printsiibid ei ole tegelikkuses midagi niivõrd uut, ent antud arendusmudel on muutnud paljud nendest trendikateks, mida varasemalt peeti tülikaks.

Artikkel toob välja, et üks agiilse liikumise eestvedaja Alistair Cockburn leiab, et ekstreemprogrammeerimine on rakendatav ainult käputäie projektitüüpide jaoks: projektid, mille elluviimisega on seotud kuni 15 inimest ning mis on kuni keskmise kriitilisusega. Artikkel märgib ka, et just sellised projektid sobivad tudengite poolt tegemiseks. Projektid, mis lähevad nendest piiridest üle, ei ole õppimise jaoks ei praktiliselt ega eetiliselt otstarbekad. XP tundub siinkohal seega mõistlik valik.

Tarkvaratehnika tudengitele on oluline teooria ja praktika kaudu anda edasi järgnevad tõsiasjad:

• Ei ole olemas metoodikat, mis sobiks mistahes projektile.
• Mõned tarkvaraarenduse tehnikad sobivad hästi arvestades projekti piiranguid, teised vähem.
• Tarkvaraarendus on enamat kui lihtsalt programmeerimine, seda tuleks võtta kui inseneritegevust.

Kvaliteedi tagamine

Kvaliteedi tagamine on üheks suuremaks väljakutseks enamike tarkvaraarendusprojektide jaoks. Ekstreemprogrammeerimine sisaldab endas 12 praktikat, enamik neist aitavad kaasa kvaliteedi tagamisele moel või teisel. Lähemal uurimisel selgub, et XP keskendub kõige enam koodi kvaliteedi tagamisele. Väiksem fookus on arenduseelsel nõuete valideerimisel ja nendega arvestamisel. Selliste aspektide katmine on iga üksiku tiimi enda ülesanne. See nõuab tiimi, kus on vähemalt mõni suurema kogemusega arendaja. Tudengiprojektide tiimides selliseid arendajaid tihtipeale paraku ei ole. Sestap peavad tudengitiimid toetuma välisele, enamasti tuutori või töötaja, abile. Nii jääb aga tudengitele vähem manageerimist ja seeläbi jääb õppekogemus väiksemaks.

Artikli autorid leiavad, et refaktoreerimine on teine praktika, millega esineb hariduslikus keskkonnas probleeme. Kogenud arendaja paneb tähele, kui "kood haiseb". Väiksema kogemusega arendaja ei ole aga piisavalt koodi näinud ega kirjutanud, et sellist asja täheldada. See omakorda tähendab, et tudengitelt ei saa eeldada efektiivset koodi refaktoreerimise oskust. Samas XP toetub just refaktoreerimisele, et hoida projekti kood puhas.

Kasutajakeskne protsess võib aidata saavutada vajalikku funktsionaalsust ja kasutatavust. On ka teine lähenemine, mille kohaselt peaks rakendatama hoopis kasutuskeskset disaini — kasutaja roll on tihtipeale olulisem kui konkreetne isik. Tarkvara peab toetama seda, kes iganes juhtub asjassepuutuvat ülesannet täitma. XP näeb ette, et kasutaja on töökohal olemas ning temaga saab tekkivaid küsimusi pidevalt arutada. Tegelikkuses ei suuda üks "kasutaja" lõpuni välja esindada suure tarkvaraprojekti kõikide huvituvate osapoolte huve.

Artikli autorid leiavad, ekstreemprogrammeerimise praktikad ei kata kvaliteedi tagamisel tekkida võivaid probleeme piisaval määral. Sisse tuleb tuua teisi praktikaid, mis ei ole XP projekti kontekstis koheselt ilmsed, ent mis võivad olla selgemalt vajalikud suuremas ja/või kriitilisemas projektis. Kui õppekeskkonnas need teised praktikad välja jätta, siis võib tudengitele jääda ekslik mulje, et kvaliteedi tagab pelgalt hästi kirjutatud kood.

Koos töötamine

Üks olulisemaid asju, mida tarkvaraarendust õppivad tudengid peaksid selgeks saama, on tiimina koos töötamine. Tarkvaraarendus on harva vaid ühe inimese töö. Sestap peaksid tudengid saama tiimis töötamise kogemust erinevatel õppetasemetel, seda nii väiksemates kui ka suuremates meeskondades. Oluline on ka see, et tudengid saaksid läbi proovida erinevaid rolle, mis esinevad suuremates tiimides, eriti just neid, mis puudutavad töö organiseerimist ja juhtimist.

Ekstreemprogrammeerimine paneb suurt rõhku tiimitööle. Isegi nii suurel määral, et XP ei toimi ilma kogu arendust läbiva koostööta. Arendusmudel toob välja, et tööd teeb üks meeskond, mitte mitu koostööd tegevat väiksemat alam-meeskonda. Neid asjaolusid arvesse võttes võib järeldada, et meeskonnatöö poole pealt on XP lähenemised väga kasulikud.

XP üks oluline osa on paarisprogrammeerimine ning see eeldab, et kõik arendusmeeskonna liikmed omavad vähemalt mõistlikul tasemel programmeerimise oskust, on võimelised ja tahavad paarides tööd teha. Paarisprogrammeerimise juures on taseme-erinevuste eksisteerimise korral soovitatav panna koos programmeerima vähem ja rohkem kogenud arendajad — nii on võimalik aidata kaasa vähemkogenud arendajate taseme tõusule. Samuti on soovitatav paare tihti vahetada.

Koolikeskkonnas on paarisprogrammeerimine andnud vastakaid tulemusi. Ühes uuringus leiti, et paarisprogrammeerimine tõstab tudengite edukust õppeaines, enesekindlust oma lahenduste osas ning selline programmeerimine pakub rohkem rõõmu. Teisalt, käesolevas peatükis kasutatava teadusartikli üks autor oli seotud paarisprogrammeerimise kasutuselevõtuga ühes suures (~500 tudengit) esimese aasta Tarkvaratehnika tudengite aines. Eesmärgiks oli tõsta tudengite üldist programmeerimise taset, arvates, et arenduse käigus toimuv arutelu aitab sellele kaasa. Paraku tegi paari tugevam liige põhilise osa tööst ning nõrgemad kippusid eksamitel läbi kukkuma. Paaride puhul, mille mõlemad liikmed olid võrdsel tasemel, täheldati, et liige, kes parasjagu koodi ei kirjutanud, kippus istuma jõude ning mõtlema muudele asjadele kui käesolevale ülesandele. Pandi tähele, et erinevad isiksused sobituvad paarisprogrammeerimisega erinevalt.

Kui õppetingimustes rakendada paarisprogrammeerimist, siis võidaksegi piirduda kaheliikmeliste tiimidega, kuid päriselus moodustuvad paarid suuremast tiimist. Sestap tasuks suurema haridusliku kasu nimel varieerida tiimi suurusi. Nii saavad tudengid paremini kogeda, mida tiimitöö ning tiimiviisiline probleemide lahendamine tegelikult tähendavad.

Paarides töötavad tudengid peavad olema suutlikud pidama isiklikke hindamistulemusi vähemolulisemaks kui paari üldist edu. Paremini hakkama saavad tudengid võivad tahta lihtsalt asja ära teha ilma, et nad pingutaksid vähemkogenud paariliikme arengu nimel. Tudengitel võib olla selleni raske jõuda, sest kaasprogrammeerija aitamisest tulenev kasu ei pruugi neile olla nii selge.

Projektitulemid

Agiilse tarkvaraarenduse manifesti kohaselt on töötav tarkvara kõige olulisem projektitulem. Ent selline suhtumine võib tudengite silmis jätta varju mõned teised tulemid, mis on samuti vajalikud. Üheks selliseks tulemiks on projekti tegemise käigus saadud õppetunnid, mida võib hariduslikus kontekstis pidada oluliseks. Paraku toimub tõhus õppeprotsess enamasti ainult läbi vigade tegemise, probleemide analüüsi ning nende parandamise. Selle kõige vältel ei ole võimalik tagada töötava tulemi olemasolu, mille pealt töö kulgu hinnata.

Teadusartikli autorid leiavad, et koodi käsitlemine põhilise tulemina tekitab tudengites valesid arusaamu. Suuremates projektides on tihtipeale vaja enamat kui töötavat tarkvara, näiteks dokumentatsiooni. Tudengid ei pruugi lisaks koodile tekkivate tulemite vajadust mõista. Eraldi probleemiks on tudengite panuse hindamine (sealhulgas isiklik initsiatiiv, pühendumus kvaliteetsele tööle jms), sest XP ei paku selleks otsest võimalust.

Suhtlus kliendiga

Ekstreemprogrammeerimises on suhtlus kliendiga olulisel kohal. Ideaalis peaks olema klient arendajatele pidevalt kättesaadav, parimal juhul oleks klient isegi arendajatega samas ruumis. Töökeskkonnas on seda raske saavutada, rääkimata hariduslikust keskkonnast.

Kliendid ei pruugi lõpuni mõista pideva arendaja ja kliendi vahelise suhtluse kasusid. Neile võib tunduda see tülikas. Tudengid tajuvad seda ning ei taha omakorda klienti pidevalt tülitada väikeste või triviaalsete probleemidega, ent XPs on just selline suhtlus projekti edu saavutamiseks hädavajalik. Frustratsiooni tekitavad probleemid ilmnevad siis, kui tudengid jõuavad lahenduse mingisuguse aspektiga perfektsuseni, aga klient annab selle peale negatiivset tagasisidet.

Teadusartikli autorid leiavad, et kohapealse kliendi olemasolu vajadus on pigem teisene. Hoopis olulisem on, et tudengid kogevad tagasiside väärtust. Tudengite juhendajad peaksid nägema vaeva, et valida välja sellised projektid, mille kliendid saavad aru tagasiside vajalikkusest ja on võimelised seda pakkuma.

Muud probleemid

Artikkel toob välja veel probleeme :

• 40-tunnise töönädala printsiip on hariduskeskkonnast raskesti järgitav.
• Eelnevast tingitud on vajadus muuta XP arendustsükleid, muutes nende skoopi.
• Tudengitele ei meeldi protsessid, distsipliin meeldib neile isegi vähem.

Teadusartikli kokkuvõte

Artikkel ilmus 2005. aastal ning selleks ajaks oli olnud vähe kogemust agiilsete metoodikate rakendamisel hariduslikus kontekstis. Huvi agiilsete metoodikate vastu oli arendusmaailmas aga juba toona suur ning üha enam taheti tuua neid uusi metoodikaid kolmanda astme haridusse.

Kokkuvõttes leiavad artikli autorid, et ekstreemprogrammeerimine kui ühtne tervik ei sobi ülikooliõppes rakendamiseks. Teisalt võivad valitud ekstreemprogrammeerimise praktikad olla kasulikud õpetamaks väiksema mastaabi tarkvaraarendust. Paarisprogrammeerimise rakendamist soovitatakse edasi uurida.

Ülevaade mudelitest

Arendusmudel	Scrum	Kanban	Extreme Programming
Millal loodud?	1995	1940ndad	Loomisprotsess algas 1996, avalikustati 1999
Põhilised autorid	Jeff Sutherland ja Ken Schwaber	Toyota insener Taiichi Ohno	Kent Beck
Võtmeväärtused / märksõnad	läbipaistvus, kontroll, kohanemine	suurenenud läbilaskevõime parem suhtlus paindlikkus vähenenud jäätmed	kommunikatsioon lihtsus tagasiside austus julgus
Rollid	tooteomanik arendusmeeskond Scrum'i juht	-	Põhiliselt: juht klient arendaja Vajadusel ka treener (coach)
Meeskonna suurus	Kuni 10 liiget	-	Kuni 12-15 liiget
Aja- ja skoobihaldus	Aeg on hallatud läbi sprindi kestuse, sprindi skoobi paneb paika Sprint Backlog	Work In Progress töö limiteerimine aitab aega ja skoopi hallata	Planeerimismäng, sealhulgas Story Card'id ja töö autoriseerimine
Tööjaotus	Sprindid kestusega 1 kuni 4 nädalat. Kestus püsib kogu tootearenduse protsessei vältel üldiselt sama.	-	Iteratsioonid, tüüpiliselt kestusega 1 kuni 2 nädalat
Koosolekud	Iga päev 15-minutiline Daily Scrum või stand-up. Iga Sprindi lõpus Sprint Review. Pärast Sprindi ülevaate koosolekut ja enne järgmise sprindi planeerimist retrospektiiv	Soovituslik: retrospektiiv, stand-up'id	Iteratsiooni plaanimise koosolek , Igapäevane Stand-up
Töö limiteerimine	Tööde maht pannakse paika sprindi nõuete nimekirjaga (Sprint Backlog)	Samal ajal töös olevate tööde hulk on piiratud	Töömahu planeerimist ja limiteerimist aitavad otsustada mõõdikud
Eksklusiivsus	Ei välista teiste arendusmetoodikate kasutust	Ei välista teiste arendusmetoodikate kasutust	XP on terviklahendus ja seega pigem teisi lahendus välistavam
Programmeerimisele spetsialiseeritud?	Tavapäraselt kasutatakse programmeerimist hõlmavate projektide puhul	Ei ole programmeerimisele spetsialiseeritud	Tugevalt spetsialiseeritud programmeerimisele
Millistele projektidele sobib paremini?	Scrum on hästiskaleeruv, kuid on pigem välja töötatud väiksemate projektide jaoks		Kuni keskmise kriitilisusega projektid
Kaugtöö toetus	Kaugtöö edukalt rakendatav	Sobib kaugtööks	Kaugtöö võib tekitada probleeme paarisprogrammeerimise ja muude XP põhimõtete osas, kuid on võimalik
Nõrgad kohad	Suurem vastutus võib viia arendusmeeskonna liikmete läbipõlemiseni Mudeli enda suurem keerukus võib muutuda arendajatele väsitavaks Toetub olulisel määral meeskonnaliikmete pidevale suhtlusele ja heale läbisaamisele	Võib kiiresti laguneda Tingib vajaduse pidevaks tööks Puuduvad ajalised piirangud Kõrgema prioriteediga tööd võivad jääda tagaplaanile	Liiga suur fookus koodil, mis võib jätta ülejäänud aspektid unarusse Ei mõõda koodi kvaliteeti 2005. aasta teadusartikkel leiab, et XP'd ei ole mõistlik kasutada hariduskeskkonnas.

Kokkuvõte

  täitja: Mirjam