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 .

Mudelite võrdlus

  täitja: Magnus

Kokkuvõte

  täitja: Mirjam