Start-up'id on on tänapäeva „kullapalavik“. Et olla teistest kiirem ja parem on it-valdkonnas nn projektijuhtimise metoodika tõhustamisega tõsiselt vaeva nähtud. Uurisin täpsemalt minu jaoks veel võõrsõnu nagu agiilne arendus, scrum, sprint, demo jne. Loetud raamat protsessi ameerikaliku huumoriga kirjeldav ja autori isiklikel kogemustel lähtuv jutustus. Siit tuleb ülevaade võhikutele:)
***
Scrum (est. k. ragbis palli mängu panema) on raamistik, mis ei ütle täpselt, kuidas tulemuseni jõuda aga annab põhimõtted, millest lähtuda. Ragbist on tulnud ka teine termin standup koosolek, kus standup näeb välja nagu pildil.
Sprint (est. k. kiirjooks) on kokkulepitud aeg teatud arendustööde teostamiseks, mille planeerimiseks korraldatakse üldjuhul kaks koosolekut:
* Esimesel koosolekul luuakse sprind'i backlog (est. k. tegemata tööd/teenused), see on toote omaniku poolt prioritiseeritud nimekiri vajadustest kliendi keeles. Koosolekul osaleb eelkõige tööde omanik ehk tellija ja srcum master (SM) ehk srcum meeskonna juht.
* Teise koosoleku eesmärk on anda tiimile piisavalt informatsiooni, et nad saaksid töötada rahulikult ja keskendunult järgnevad kaks kuni neli nädalat ning anda toote omanikule piisav kindlustunne, et kõik sujub. Sprind'i planeerimise koosoleku (2h) ülesanded prioriteetide järjekorras:
1- sprindi eesmärk ja demo aeg;
2- lugude nimekiri, mis on sprinti valitud;
3- igale loole on lisatud estimatsioon kui kaua selle ülesande lahendamine aega võtab (S/M/L) - võib juhtuda, et muudetakse esialgseid estimatsioone (arendajate poolt);
4- millal demotakse on vastuse saanud;
5- sprindi pikkus (velocity) on otsustatud;
6- päevase scrumi aeg ja koht on otsustatud;
7- lood on jaotatud ülesanneteks.
Scrum lõpeb demoga, kus arendustiim esitleb oma tööd toote omanikule ning peale seda toimub retrospektiiv, kus meeskond analüüsib arendustöö protsessi.
Alljärgnevalt kogu tööprotsessist pikemalt.
Sprindi eesmärk peab vastama küsimusele, miks me seda sprinti teeme. Tavaliselt on eesmärki raske sõnastada aga parem kehv eesmärk kui see, et eesmärki üldse ei ole. Sprindi eesmärk tundub alguses mittevajalik aga sellest on tavaliselt kõige rohkem kasu sprindi keskel, kui inimestel tekib segadus selles osas, mida nad ikkagi peaksid tegema.
Koos loomine on fundamentaalne osa scrumist ja laiemalt agiilsest arendusmetoodikast. Toote omanik peab osalema sprindi planeerimisel, sest plaan luuakse toote omaniku ja tiimi vahelises dialoogis. Toote omanik selgitab sprindi eesmärki ja kõige olulisemaid lugusid. Meeskond käib läbi ajalised esitmatsioonid, alustades kõige olulisemast. Dialoogi käigus toimub jätkuv skoobi (sh väline kvaliteet), esitmatsiooni ja prioriteetsuse hindamine.
Väline kvaliteet on see, mida tunnetavad süsteemi kasutajad, nt aeglane ja mitte intuitiivne kasutajaliides on näide halvast välisest kvaliteedist. Sisemisel kvaliteedil on olemuslik mõju süsteemi toimivusele, nt süsteemi disain, koodi loetavus jne.
Süsteem, millel on madal sisemine kvaliteet ei saa üldjuhul olla kõrge välise kvaliteediga. Samas võib juhtuda, et sisemine kvaliteeti ei ole vajalik, nt kui on kiiresti vaja prototüüpi. Selle määrab toote omanik. Siis peab aga hiljem jätma aega sisemise kvaliteedi ülesannete jaoks.
Toote omanik võib estimatsiooni kuuldes muuta ülesande prioriteetsust või teha ülesande väiksemateks osadeks.
Srcum koosolekuid timebox'itakse st määratakse neile kindel algus ja lõppaeg. Optimaalseks pidas autor ühe nädala kohta pidada üks tund planeerimiskoosolekut. Kui koosolek läheb pikemaks, lõpetage see. Kui väga vaja, lepi järgmine kohtumine järgmiseks päevaks. Pikad koosolekud väsitavad inimesi ja ei ole tõhusad. Lühike koosolekuaeg tähendab head backlogi ettevalmistust, nii toote omaniku kui tiimi poolt.
See kui palju lugusid mahub ühte sprinti otsustab arendajate meeskond (hea praktika on iga lugu on 2-8 inimpäeva pikk (inimpäev = 6 tõhusat töötundi), sprinti mahub 5-15 lugu). Lood on tulemused, millest toote omanik hoolib, lood jagatakse ülesanneteks, millest toote omanikul ei ole reaalset väärtust. Sprindi planeerimisel kirjutatakse mõned ülesanded lahti, et mõista loo sisu ja seoseid ülesannete vahel. Lisaks tuleb tehnilisi ülesandeid nt tarkvara uuendused jmt, mis ei too toote omanikule otsest kasu, aga on vaja ka kirja panna kas ülesannetesse või eraldi ülesannetena. Hea scrumi master suudab toote omanikuga läbi rääkida ka tehnilised, sisemise kvaliteedi ja tehnilise võla küsimused.
Meeskond kasutab sprindi planeerimisel varasemaid kogemusi ja see on parim ja lõbusaim viis planeerimiseks. Lisaks võib kalkuleerida kui palju inimtunde tiimil kokku on, võttes välja koolituste ja puhkuste ajad jmt. Kui numbrid on paigas lase tiimil teha „kõhutunde tšekk“ – kas estimatsioonid tunduvad mõistlikud. Oluline on ka defineerida, millal on ülesanne tehtud. Enamasti on ülesanne tehtud kui meeskond ja testija (viimane peab ära arvama toote tellija vajadused) ütlevad, et ülesanne on valmis.
Planeerimisel osalevad kõik sprindi tiimi liikmed, et saada ülevaade ülesannete sisust, koos anda estimatsioonid (hinnang antakse kogu ülesandele sh testimine) ja vaieldakse läbi kohad, kus estimatsioonid tulevad väga erinevad. Selleks, et „teadjama“ väljaöeldud estimatsioon ei hakkaks teiste hinnanguid segama kasutatakse „planeerimise pokkerit“ (vt pilti) st estimatsiooni kaarte ja valik tehakse esialgu omaette. Kui estimatsioonid on erinevad, toimub arutelu ja valitakse uuesti kaardid ja sama jätkub senikaua kuni estimatsioonid tulevad sarnased.
Samuti otsustatakse päevase scrum'i ehk standup'i aeg. Võib olla tiimi jaoks sobivaim aeg, tavaliselt hommikul, see on hea, et meelde tuletada, mis ülesanded oli vaja töösse võtta. Standup'pe korraldatakse püsti seistes kuni 15 min. Autori kogemusel on parimad arutelud reaalse backlogi ees. Sprindi backlogid on üldjuhul veebis. Autor aga ikka soovitab lisada paberil (valgel tahvlil) visuaalse backlog'i (vt pilti Information Radiator). Meeskond peab istuma koos sh nägema üksteist ja visuaalset backlog'i, kuulma üksteist ja olema piisavalt isoleeritud, et saaks vajadusel diskussioone pidada.
Standup'i ajal võiks toote omanik olla kättesaadav, võib meeskonna juures olla. Aga toote omanikel on kombeks küsida detailirohkeid küsimusi, mida tuleb osata piirata, et tiim saavutaks tiheda, ennastjuhtiva, hüperproduktiivse töörütmi.
Standup on tähtis tegevuste sünkroniseerimiseks. Sellest võib saada väga igav koosolek. Leia viise kuidas hoida põnevust. Igaüks vastab kohtumisel küsimusele:
1- Mis Sa eile tegid, mis aitas meie meeskonnal saavutada sprindi eesmärki
2- Mis Sa täna teed, mis aitab meie meeskonnal saavutada sprindi eesmärki
3- Kas on tekkinud mingeid takitusi, mis võivad nurjata sprindi eesmärgi saavutamist
Standup'i eesmärk on kommunikeerida, mitte administreerida. Autori soovitus on täiendada scrum'i tabelit jooksvalt päeva jooksul või siis koosoleku ajal. Ühiselt kokkulepitud korraldus on oluline. Liiga ei tohiks kinni jääda estimatsioonidesse vmt.
Sprint demol selgitatakse, mida tehti ja küsitakse, mida toote omanik sellest arvab. Demol saab meeskond tagasisidet, need on sotsiaalsed üritused, kus saab suhelda nt toote tellijatega ja mis sunnivad meeskonda päriselt ülesannet lõpetama. Ilma demodeta jääks suur osa asjadest 99% lõpetatud asjade hunnikusse. Demo tõttu saame ehk vähem valmis aga need ülesanded on siis päriselt lõpuni valmis. Isegi kui tiimil pole midagi ette näidata on hea anda ülevaade toimunust, et õppida sellest ja saada innustust järgmiseks sprindiks.
Demo kohtumise võtmepunktid: väljenda selgelt sprindi eesmärki, ära näe demo ettevalmistusega liiga palju vaeva (kindlasti mitte ppt) aga näita, mis töötab; hoia demod business-oriented (st räägi, mida tehti mitte kuidas tehti).
Retrospekviive (RP) ehk sprind'i analüüsi ei taheta sageli teha ja pigem soovitakse kiirelt uue asja kallale asuda. Mida rohkem on inimesed peale sprint'i stressis, seda vähema nad tahavad RP-d teha aga seda rohkem nad RP-d vajavad. RP ei tohiks kaua aega võtta, kahenädalase sprindi kohta võiks timeboxida 1h RP. Aga iga paari kuu tagant võiks teha pikema, kuni poole päevase RP, et tegeleda tõsisemate teemadega. RP-l on oluline, et tiim ise sõnastaks õppetunnid. Autori kogemusel hakkatakse ilma RP-ta nägema, kuidas tiim teeb samu vigasid aina uuesti.
RP-l osalevad toote omanik, meeskond ja meeskonna juht. RP meetodeid on mitmeid nt alustuseks võtab SM sprindi kokku ja siis saab igaüks segamatult sõna mis läks hästi, mis oleks võinud olla paremini ja mida teeksin järgmises sprindis teisiti, seejärel vaadatakse planeeritud sprindi pikkust ja reaalset pikkust, ning kokkuvõtteks SM võtab kokku, mida järgmisel korral paremini teha. Võib teha ka tiimi hääletuse selle kohta mida järgmise sprindi ajal kindlasti teisiti teha. Väljavalitud muudatuste juurde tullakse järgmisel RP-l tagasi. Või kui on aega nt 20 min siis küsige mida hoida ja mida muuta (erinevaid RP meetodeid leiab siit www.plans-for-retrospectives.com).
Kui on palju scrum tiime, siis võiks olla üks inimene, kes osaleb kõigil RP-del ja võtab teadmiste kogumise rolli ning aitab vajadusel ettevõttes suuremaid muutusi teha. Enamasti on nii, et kui leitakse arendamist vajavad asjad, siis nende selge väljaütlemine lahendab need järgmises sprindis iseenesest nt eriti kommunikatsiooniprobleemid. Pole vaja kohe hakata teema suuri muudatusi ja planeerima ekstra tegevusi. Kui iga kord hakatakse mingeid asju suuresti muutma, siis inimesed ei taha enam oma probleeme jagada.
Mõnedes ettevõtetes on sprintide vahel slack time (est.k. vähese koormusega aeg). Nt Spotify-s on kaks korda aastas kõigil ettevõtte töötajatel, samal ajal, üks nädal vaba. See nädal algab reede õhtul demoga ja peoga: http://tinyurl.com/spotifyagile.
***
Kokkuvõtteks jäid minu jaoks raamatust kõlama neli srum raamistiku põhimõtet: sisult ja kestvuselt hoomatav sprint, kliendi kaasamine arendusse, koosolekute timeboximine ning kokkulepitud tulemuste ja ajaga demo. Püüan scrumi juba rakendada oma töös haridusvaldkonnas. Põnev.
Raamatut saab lugeda siit: http://wwwis.win.tue.nl/2R690/doc/ScrumAndXpFromTheTrenchesonline07-31.pdf
 |
| Wikipedia |
Scrum (est. k. ragbis palli mängu panema) on raamistik, mis ei ütle täpselt, kuidas tulemuseni jõuda aga annab põhimõtted, millest lähtuda. Ragbist on tulnud ka teine termin standup koosolek, kus standup näeb välja nagu pildil.
Sprint (est. k. kiirjooks) on kokkulepitud aeg teatud arendustööde teostamiseks, mille planeerimiseks korraldatakse üldjuhul kaks koosolekut:
* Esimesel koosolekul luuakse sprind'i backlog (est. k. tegemata tööd/teenused), see on toote omaniku poolt prioritiseeritud nimekiri vajadustest kliendi keeles. Koosolekul osaleb eelkõige tööde omanik ehk tellija ja srcum master (SM) ehk srcum meeskonna juht.
* Teise koosoleku eesmärk on anda tiimile piisavalt informatsiooni, et nad saaksid töötada rahulikult ja keskendunult järgnevad kaks kuni neli nädalat ning anda toote omanikule piisav kindlustunne, et kõik sujub. Sprind'i planeerimise koosoleku (2h) ülesanded prioriteetide järjekorras:
1- sprindi eesmärk ja demo aeg;
2- lugude nimekiri, mis on sprinti valitud;
3- igale loole on lisatud estimatsioon kui kaua selle ülesande lahendamine aega võtab (S/M/L) - võib juhtuda, et muudetakse esialgseid estimatsioone (arendajate poolt);
4- millal demotakse on vastuse saanud;
5- sprindi pikkus (velocity) on otsustatud;
6- päevase scrumi aeg ja koht on otsustatud;
7- lood on jaotatud ülesanneteks.
Scrum lõpeb demoga, kus arendustiim esitleb oma tööd toote omanikule ning peale seda toimub retrospektiiv, kus meeskond analüüsib arendustöö protsessi.
Alljärgnevalt kogu tööprotsessist pikemalt.
Sprindi eesmärk peab vastama küsimusele, miks me seda sprinti teeme. Tavaliselt on eesmärki raske sõnastada aga parem kehv eesmärk kui see, et eesmärki üldse ei ole. Sprindi eesmärk tundub alguses mittevajalik aga sellest on tavaliselt kõige rohkem kasu sprindi keskel, kui inimestel tekib segadus selles osas, mida nad ikkagi peaksid tegema.
Koos loomine on fundamentaalne osa scrumist ja laiemalt agiilsest arendusmetoodikast. Toote omanik peab osalema sprindi planeerimisel, sest plaan luuakse toote omaniku ja tiimi vahelises dialoogis. Toote omanik selgitab sprindi eesmärki ja kõige olulisemaid lugusid. Meeskond käib läbi ajalised esitmatsioonid, alustades kõige olulisemast. Dialoogi käigus toimub jätkuv skoobi (sh väline kvaliteet), esitmatsiooni ja prioriteetsuse hindamine.
Väline kvaliteet on see, mida tunnetavad süsteemi kasutajad, nt aeglane ja mitte intuitiivne kasutajaliides on näide halvast välisest kvaliteedist. Sisemisel kvaliteedil on olemuslik mõju süsteemi toimivusele, nt süsteemi disain, koodi loetavus jne.
Süsteem, millel on madal sisemine kvaliteet ei saa üldjuhul olla kõrge välise kvaliteediga. Samas võib juhtuda, et sisemine kvaliteeti ei ole vajalik, nt kui on kiiresti vaja prototüüpi. Selle määrab toote omanik. Siis peab aga hiljem jätma aega sisemise kvaliteedi ülesannete jaoks.
Toote omanik võib estimatsiooni kuuldes muuta ülesande prioriteetsust või teha ülesande väiksemateks osadeks.
Srcum koosolekuid timebox'itakse st määratakse neile kindel algus ja lõppaeg. Optimaalseks pidas autor ühe nädala kohta pidada üks tund planeerimiskoosolekut. Kui koosolek läheb pikemaks, lõpetage see. Kui väga vaja, lepi järgmine kohtumine järgmiseks päevaks. Pikad koosolekud väsitavad inimesi ja ei ole tõhusad. Lühike koosolekuaeg tähendab head backlogi ettevalmistust, nii toote omaniku kui tiimi poolt.
See kui palju lugusid mahub ühte sprinti otsustab arendajate meeskond (hea praktika on iga lugu on 2-8 inimpäeva pikk (inimpäev = 6 tõhusat töötundi), sprinti mahub 5-15 lugu). Lood on tulemused, millest toote omanik hoolib, lood jagatakse ülesanneteks, millest toote omanikul ei ole reaalset väärtust. Sprindi planeerimisel kirjutatakse mõned ülesanded lahti, et mõista loo sisu ja seoseid ülesannete vahel. Lisaks tuleb tehnilisi ülesandeid nt tarkvara uuendused jmt, mis ei too toote omanikule otsest kasu, aga on vaja ka kirja panna kas ülesannetesse või eraldi ülesannetena. Hea scrumi master suudab toote omanikuga läbi rääkida ka tehnilised, sisemise kvaliteedi ja tehnilise võla küsimused.
Meeskond kasutab sprindi planeerimisel varasemaid kogemusi ja see on parim ja lõbusaim viis planeerimiseks. Lisaks võib kalkuleerida kui palju inimtunde tiimil kokku on, võttes välja koolituste ja puhkuste ajad jmt. Kui numbrid on paigas lase tiimil teha „kõhutunde tšekk“ – kas estimatsioonid tunduvad mõistlikud. Oluline on ka defineerida, millal on ülesanne tehtud. Enamasti on ülesanne tehtud kui meeskond ja testija (viimane peab ära arvama toote tellija vajadused) ütlevad, et ülesanne on valmis.
Planeerimisel osalevad kõik sprindi tiimi liikmed, et saada ülevaade ülesannete sisust, koos anda estimatsioonid (hinnang antakse kogu ülesandele sh testimine) ja vaieldakse läbi kohad, kus estimatsioonid tulevad väga erinevad. Selleks, et „teadjama“ väljaöeldud estimatsioon ei hakkaks teiste hinnanguid segama kasutatakse „planeerimise pokkerit“ (vt pilti) st estimatsiooni kaarte ja valik tehakse esialgu omaette. Kui estimatsioonid on erinevad, toimub arutelu ja valitakse uuesti kaardid ja sama jätkub senikaua kuni estimatsioonid tulevad sarnased. Samuti otsustatakse päevase scrum'i ehk standup'i aeg. Võib olla tiimi jaoks sobivaim aeg, tavaliselt hommikul, see on hea, et meelde tuletada, mis ülesanded oli vaja töösse võtta. Standup'pe korraldatakse püsti seistes kuni 15 min. Autori kogemusel on parimad arutelud reaalse backlogi ees. Sprindi backlogid on üldjuhul veebis. Autor aga ikka soovitab lisada paberil (valgel tahvlil) visuaalse backlog'i (vt pilti Information Radiator). Meeskond peab istuma koos sh nägema üksteist ja visuaalset backlog'i, kuulma üksteist ja olema piisavalt isoleeritud, et saaks vajadusel diskussioone pidada.
Standup'i ajal võiks toote omanik olla kättesaadav, võib meeskonna juures olla. Aga toote omanikel on kombeks küsida detailirohkeid küsimusi, mida tuleb osata piirata, et tiim saavutaks tiheda, ennastjuhtiva, hüperproduktiivse töörütmi.
Standup on tähtis tegevuste sünkroniseerimiseks. Sellest võib saada väga igav koosolek. Leia viise kuidas hoida põnevust. Igaüks vastab kohtumisel küsimusele:
1- Mis Sa eile tegid, mis aitas meie meeskonnal saavutada sprindi eesmärki
2- Mis Sa täna teed, mis aitab meie meeskonnal saavutada sprindi eesmärki
3- Kas on tekkinud mingeid takitusi, mis võivad nurjata sprindi eesmärgi saavutamist
Standup'i eesmärk on kommunikeerida, mitte administreerida. Autori soovitus on täiendada scrum'i tabelit jooksvalt päeva jooksul või siis koosoleku ajal. Ühiselt kokkulepitud korraldus on oluline. Liiga ei tohiks kinni jääda estimatsioonidesse vmt.
Sprint demol selgitatakse, mida tehti ja küsitakse, mida toote omanik sellest arvab. Demol saab meeskond tagasisidet, need on sotsiaalsed üritused, kus saab suhelda nt toote tellijatega ja mis sunnivad meeskonda päriselt ülesannet lõpetama. Ilma demodeta jääks suur osa asjadest 99% lõpetatud asjade hunnikusse. Demo tõttu saame ehk vähem valmis aga need ülesanded on siis päriselt lõpuni valmis. Isegi kui tiimil pole midagi ette näidata on hea anda ülevaade toimunust, et õppida sellest ja saada innustust järgmiseks sprindiks.
Demo kohtumise võtmepunktid: väljenda selgelt sprindi eesmärki, ära näe demo ettevalmistusega liiga palju vaeva (kindlasti mitte ppt) aga näita, mis töötab; hoia demod business-oriented (st räägi, mida tehti mitte kuidas tehti).
Retrospekviive (RP) ehk sprind'i analüüsi ei taheta sageli teha ja pigem soovitakse kiirelt uue asja kallale asuda. Mida rohkem on inimesed peale sprint'i stressis, seda vähema nad tahavad RP-d teha aga seda rohkem nad RP-d vajavad. RP ei tohiks kaua aega võtta, kahenädalase sprindi kohta võiks timeboxida 1h RP. Aga iga paari kuu tagant võiks teha pikema, kuni poole päevase RP, et tegeleda tõsisemate teemadega. RP-l on oluline, et tiim ise sõnastaks õppetunnid. Autori kogemusel hakkatakse ilma RP-ta nägema, kuidas tiim teeb samu vigasid aina uuesti.
RP-l osalevad toote omanik, meeskond ja meeskonna juht. RP meetodeid on mitmeid nt alustuseks võtab SM sprindi kokku ja siis saab igaüks segamatult sõna mis läks hästi, mis oleks võinud olla paremini ja mida teeksin järgmises sprindis teisiti, seejärel vaadatakse planeeritud sprindi pikkust ja reaalset pikkust, ning kokkuvõtteks SM võtab kokku, mida järgmisel korral paremini teha. Võib teha ka tiimi hääletuse selle kohta mida järgmise sprindi ajal kindlasti teisiti teha. Väljavalitud muudatuste juurde tullakse järgmisel RP-l tagasi. Või kui on aega nt 20 min siis küsige mida hoida ja mida muuta (erinevaid RP meetodeid leiab siit www.plans-for-retrospectives.com).
Kui on palju scrum tiime, siis võiks olla üks inimene, kes osaleb kõigil RP-del ja võtab teadmiste kogumise rolli ning aitab vajadusel ettevõttes suuremaid muutusi teha. Enamasti on nii, et kui leitakse arendamist vajavad asjad, siis nende selge väljaütlemine lahendab need järgmises sprindis iseenesest nt eriti kommunikatsiooniprobleemid. Pole vaja kohe hakata teema suuri muudatusi ja planeerima ekstra tegevusi. Kui iga kord hakatakse mingeid asju suuresti muutma, siis inimesed ei taha enam oma probleeme jagada.
Mõnedes ettevõtetes on sprintide vahel slack time (est.k. vähese koormusega aeg). Nt Spotify-s on kaks korda aastas kõigil ettevõtte töötajatel, samal ajal, üks nädal vaba. See nädal algab reede õhtul demoga ja peoga: http://tinyurl.com/spotifyagile.
***
Kokkuvõtteks jäid minu jaoks raamatust kõlama neli srum raamistiku põhimõtet: sisult ja kestvuselt hoomatav sprint, kliendi kaasamine arendusse, koosolekute timeboximine ning kokkulepitud tulemuste ja ajaga demo. Püüan scrumi juba rakendada oma töös haridusvaldkonnas. Põnev.
Raamatut saab lugeda siit: http://wwwis.win.tue.nl/2R690/doc/ScrumAndXpFromTheTrenchesonline07-31.pdf
Kommentaare ei ole:
Postita kommentaar