Väledad tarkvaraarenduse mudelid

Sissejuhatus

  täitja: Mihkel

Scrum

  täitja: Mihkel

Kanban

  täitja: Mirjam

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

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 (Its core purpose is minimizing waste activities without sacrificing productivity). 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 liiga suurt toorainete hulka, 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 taske ette, 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 laialdaselt ITs kasutuses 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

Visualization

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 – sõltuvalt ettevõttest ning võimalustest. 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 .

Work In Progress

Kanban limiteerib tööde hulka, mis võivad olla hetkel “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 kui lükata 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.

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 kõrgema limiidiga (st korraga võib laual olla vähe ülesandeid) töövoog paistab sujuvalt edasi liikuvat, võib vähendada limiiti, 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 vähendada limiiti ning pakkuda tiimiliikmetele taaskord arengupunkti.

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”.

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 taski 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 taskide 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 taski 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

Higher Rate of Self-Organization

Projektijuhtimine ja sellega kaasas käivad nõuded on vajalikud, et saavutada see, mis projektiga saavutada soovitakse. 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. Seetõttu 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.

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 teab, et tema tööd hinnatakse ja vaadatakse pidevalt üle. See aitab kaasa personaalsele heaolule, 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 teeb kasutamise korral 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 ülesannete staatuseid silmapilguga 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). Puuduvad kindlad 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 jäätmed – 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 ainult Kanbani pole võimalik õ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 real-life 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.

Mõjutused muudele metoodikatele

Kuna Kanban oma loomult ei ole arendusmetoodika, saab seda kasutada mitmete teiste arendusmetoodikatega segatuna. Üheks parimaks ja laialt levinumaks näiteks saab tuua Kanbani ja Scrumi segu 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.

Extreme Programming

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.

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 leiavad, et kui kasutusel ei ole kõik XP printsiibid, siis ei ole tegemist õige XP arendusega .

Ajalugu

Töö Extreme Programmingu kui arendusmudeli välja töötamiseks sai alguse aastal 1996. XP välja töö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 Extreme Programming'u nime alla koondatult.

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

Lühitutvustus

Extreme Programming 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 Extreme Programming on tiimi meeskonna jaoks uus lähenemine) kaasatakse ka treener (Coach) . XP aitab luua lihtsa, aga efektiivse keskkonna, mis aitab meeskondael saavutada kõrge produktiivsuse .

Extreme Programming'u kohta käivad 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 tagasiside;
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.

Extreme Programming'u reegleid on päris mitmeid, neid kõiki siin rühmatöö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

Extreme Programming 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 mingitki väärtust tellivale osapoolele.

Integratsioonihaldus

Allikas toob välja, et Extreme Programming ei paku abi, et integreerida mitte-programmeerijate töövaeva. Mõned XP pooldajad leiavad, et tehniliste kirjutajate, 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õndade teiste protsessidega, mille kohaselt paigutub tarne, dokumenteerimine ja testimine ajaplaani lõppu.

Tarkvaraarendajate suhtes on Extreme Programming 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

Extreme Programmingu 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 Extreme Programmingust kasutatavaid Story Card'e, võib täheldada nende suurt sarnasust tööpakkidega.

Planeerimismäng

Tööpakid pannakse kirja käsitsi kirjutatud kirjeldustena kasutajat puudutavast funktsionaalsusest. 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 funktsionaalsusest rääkida; need ei peaks kirjeldama tehnilist funktsionaalsust arendaja vaatepunktist. Story Card'e kasutatakse, et töötada välja hinnanguid, tarkvara ehitamise ajakavasid, autoriseerida tööd, eestvedada testimist ning raporteerida staatust.

Extreme Programming'us 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 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 sisaldatavatesse reliisidesse. Nagu eelnevalt mainitud, kaasab XP arendusprotsessi kliendi 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 arendajaid üle koormamast . Extreme Programmingus eelistatakse muutuvate tarnimiskuupäevade asemel ujuvat skoopi.

Kvaliteedihaldus

Töötulemi kvaliteedi hoidmine võib Extreme Programming'u 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 Extreme Programming koodile, mis vastab praegustele autoriseeritud tööpakkidele. Tulevaste featuuride ja lugude implementeerimiseks täiustatakse ja parendatakse pidevalt koodi. 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 endiselt toimib.

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

Extreme Programming'u kohaselt toimub produktsioonikoodi kirjutamine ainult paarides — kaks arendajat istuvad ühe arvuti taga. Paarisprogrammeerimine viib ellu kollektiivomandi 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

Extreme Programming sobib meeskondadele, kus on kuni 12-15 tiimiliiget. Kasutan siinkohal allikat, mis leiab, et sama meeskonnaliikmete maksimumarv on kasulik viimase aasta Tarkvaratehnika 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 muunud paljud nendest trendikateks, mida varasemalt peeti tülikaks.

Artikkel toob välja, et üks agiilse liikumise eestvedajatest Alistair Cockburn leiab, et Extreme Programming on rakendatav ainult käputäie projektitüüpide jaoks: projektid, mille elluviimisega on seotud kuni 15 inimest ning mis ei ole enam kui 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. Extreme Programming 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 arendus-eelsel 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 abile, enamasti tuutori või töötaja. 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 teda, 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, Extreme Programming'u 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 töö organiseerimist ja juhtimist puudutavaid.

Extreme Programming 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, antud artikli üks autor oli seotud paarisprogrammeerimise kasutuselevõtuga ühes suures (~500 tudengit) esimese aasta arvutitudengite 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. 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 läbi. Selle kõige vältel ei ole võimalik tagada töötava tulemi olemasolu, mille pealt töö kulgu hinnata.

Allika 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 koodi kõrvuti 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

Extreme Programming'us 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 tundub 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 Extreme Programming kui ühtne tervik ei sobi ülikooliõppes rakendamiseks. Teisalt võivad valitud Extreme Programmingu praktikad olla kasulikud õpetamaks väiksema mastaabi tarkvaraarendust. Paarisprogrammeerimise rakendamist soovitatakse edasi uurida.

Mudelite võrdlus

mudelite võrdlus

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	-	Iteratsiooni plaanimise koosolek , Igapäevane Stand-up
Töö limiteerimine		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	XP on terviklahendus ja seega pigem teisi lahendus välistavam
Programmeerimisele spetsialiseeritud?	Tavapäraselt kasutatakse programmeerimist hõlmavate projektide puhul	Ei ole porgrammeerimisele spetsialiseeritud	Tugevalt spetsialiseeritud programmeerimisele
Millistele projektidele sobib paremini?			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

Kokkuvõte

  täitja: Mirjam