14. päev - arendus/testimine + üksteise projektide testimine

14. päev tähendas seda, et ainult 1,5 päeva oli aega meeskondadel veel tegeleda projektide arendamisega ja testimisega. Sellel päeval testisid meeskonnad umbes tunni teise meeskonna toodet. Üksteise toodete testimine tõi välja kohti, mida ise meeskonnad seni ei olnud avastanud. Ühel meeskonnal rohkem, teisel vähem, kuid mõlemate meeskondade puhul avastati seni avastamata vigasid.

14. päeva õhtuks enam uusi arendusi ei tehtud. Edaspidi tegeleti tarkvaraarenduse poole pealt vaid testimise ja väikeste vigade parandamisega.

13. päev - arendus + kardisõit

Arendus

Viimasel nädalal tuleb kindlasti kõik feature-id valmis saada. Oluline on ka, et asjad saavad korralikult läbi testitud. Ühelt poolt pinged arenduses kasvavad, kuna panused kasvavad: lõpudemol eksimisruumi ei ole. Teisalt on aga meeskonnad ennast kenasti sisse töötanud, et pinge ei paista väga väljagi, iga päev saab korralikult nalja. 

Kardisõit

Mis oleks aga parem moodus oma pea hetkeks arendusmõtetest puhtaks saada, kui minna kardiga sõitma. 

Nagu töö juures aitavad osalejad üksteist nii ka vabal ajal.

Finaal

Kiireim sõitja rajal.

Esikolmik 

Kõik osalejad aga nautisid õhtut täiega.

12. päev - Sprint demo + retro + sprint planning + arendus

Sprint Demo

12. päeva hommik algas demodega.

Saali koguneb järjest rohkem ja rohkem Helmese töötajaid, kes tahavad näha, millega noored on hakkama saanud. 

 Demod toimuvad väga struktureeritud viisil. Kõige pealt näidatakse, mida sprinti alguses kokku lepiti ja siis näidatakse, kuidas see päriselt testkeskonnas välja näeb.

  Osalejad on juba väga lähedal MVP-dele(Minimal Viable Product). See tähendab, et lõppkasutajad saavad juba väga reaalse pildi, kuidas neile kasutamiseks mõeldud süsteem hakkab toimima.

Retro

 Retrol panevad igaüks kirja, mis nende arust läks sprintil hästi ja mis oleks saanud paremini minna.

 Seejärel läheb igaüks tahvli juurde ja räägib lühidalt, mida ta kirja pani.

Retro lõpeb sellega, et valitakse välja kaks asja nii positiivse kui negatiivse poole pealt. Positiivse poole pealt valitud asju kindlasti jätkatakse järgmisel sprintil. Negatiivse poole pealt valitud asjad üritatakse järgmise sprintiga ära parandada. 

Sprinti planeerimine

Sprindi planeerimine on see koht, kus tooteomanik seab uue nädala arendusprioriteedid. Meeskond saab aru, mis järjekorras nad hakkavad featureid ehitama.

Oluline on et meeskond ja tooteomanik saaksid ühte moodi aru, mida ehitama hakatakse. Tooteomaniku, meeskonna ja Scrum Masteri koostöö pareneb iga nädalaga. Sprinti planeerimise koosolekud muutuvad järjest efektiivsemaks (ja ajaliselt lühemaks). 

 Sprinti planeerimise lõpus meeskond hindab kui keerulised on seekordsed user story-d. Seejärel otsustab meeskond koostöös Scrum Master-iga , kui palju nad lubavad, et jõuavad selle sprintiga valmis.

Pärastlõunal jätkus arendus.

11. päev - arendus

Mentor näitab Java meeskonnale, kuidas on mõistlik autentimist ülesse seada.

Tegemist on selle sprinti viimase päevaga. See tähendab, et kõik mida tahetakse demol näidata tuleb nüüd valmis saada.

Osalised saavad väga hea versioonihalduse kogemuse. Kõikide feature-ite arendus toimub iseseisvas branch-is. Osalised nimetavad tegevust, kui feature branche hakatakse kokku panema MergeParty-ks. Mõlemad meeskonnad täitsid selle sprindi eesmärgid kuhjaga ning õhtuks olid uuendatud rakendused testkeskondaes üleval.

10. päev - arendus + kohtumine lõppkasutajaga + Helmese tutvustus

Arendus

Meeskondade efektiivsus on märgatavalt kasvanud. Koostöö nii meeskonna liikmete kui mentoritega on kenasti sisse töötanud ja sujub väga hästi. Uued funktsionaalsused valmivad järjest kiiremini ja kiiremini.

Vajalikul hetkel võtab mentor meeskonna kokku ja seletab olulisi nüansse. 

Kohtumine lõppkasutajaga

Pärast esimest sprinti demo joonistus kenasti välja, miks on agiilne arendus parem waterfall lähenemisest. Kui lõppkasutaja näeb töötavat funktsionaalsust, siis ta oskab välja tuua aspekte, mida esialgsel planeerimisel ei suudeta ette näha. Arenduse käigus saab teha vajalikud muudatused ning lõppkokkuvõttes saab klient väärtuslikuma lahenduse. Kümnendal päeval kohtuti lõppkasutajaga, et paremini aru saada, kuidas nad päriselt tahavad rakendust kasutada. Kuna põhifunktsionaalsused olid selleks hetkeks juba enam-vähem valmis, siis oli lõppkasutajatel suhteliselt lihtne anda konstruktiivset tagasisidet. 

Helmes tutvustus

Helmese asutaja ja tegevjuht tutvustas osalistele, kuidas Helmes on ülesse ehitatud ning kuhu suunas liigutakse. Osalistel oli väga tore näha, et tegevjuhi südameasjaks on töötajate rahulolu. 

9. päev - arendus jätkub

Oli väga tegus päev ning palju funktsionaalsusi sai valmis. Pildilt on näha, kuidas osad tegelevad koodi kirjutamisega ning teised arutavad, mis funktsionaalsust, kuidas ja milleks tegema hakatakse.

8. päev - Demo, Retro ja Sprindi planeerimine

Demo

Kaheksas päev oli väga sisutihe. Hommik algas sellega, et meeskonnad näitasid, mida nad olid esimese sprintiga valmis jõudnud. Mõlemad meeskonnad olid väga tublid. Kõik asjad, mis nad lubasid valmis saada, said valmis ja tooteomanik võttis need kenasti vastu. Kohal olid ka toodete lõppkasutajad, kes andsid väärtuslikku tagasisidet toodete edasiseks arenduseks.

Retro

Pärast demosid võeti eelmine sprint kokku. Arutati, mis läks hästi ja mida saab järgmine kord paremini teha. Valiti välja, mida kindlasti jätkatakse ning kuidas esilekerkinud puudused lahendatakse. Mõlemad meeskonnad tõid välja, et meeskond toimib tervikuna hästi ja kõik meeskonnaliikmed on ägedad.

Sprinti planeerimine

Pärast eelmise sprindi kokkuvõtmist hakati uut sprinti planeerima. Ühel meeskonnal vahetus tooteomanik, mis tõi kaasa ka väikese fookuse muutuse projektis. Seoses sellega panustas see meeskond rohkem aega prioriteetide läbi arutamisele. Kuna kasutatakse agiilset arendusmetoodikat, siis selline suunamuutus ei vii meeskonda põhja. Vastupidi see võimaldab luua kiiremini väärtust kliendile. Teine meeskond tegeles vähem prioriteetide ülevaatamisega, rohkem aega panustati tehniliste detailide planeerimisele.

Arendus

Kuigi selline tihe päev on päris väsitav, siis mõlemad meeskonnad leidsid endas jõudu tegeleda veel ka koodi kirjutamisega.

7. päev : tarkvaraarendus + team building

 

Kuuendal päeval jätkus tarkvaraarendus. Õhtu poole mängisid osalised mängu Kapo Kuulab.

 

Moodustatud meeskonnad said endale raadiosaatjad ning pidid nendega küsimusi küsides aru saama, mis objekte oli mõeldud. Samas konkureerivad meeskonnad kuulsid, mis küsimusi küsiti, mistõttu tuli hoolikalt mõelda mida küsida. Võtja meeskond küsis 30 küsimust.

Pärast seda algas lauamängu - ja saunaõhtu. 

6. päev - joonistame sajajalgset ja saame teadmisi testimisest

Reino viis meid testimise maailma, rääkis erinevatest testimisviisidest ja ärgitas kaasa mõtlema.

Koos sai läbi tehtud sajajalgse harjutus, et paremini mõista ja teadvustada testimise olulisusest.

Testimise seminaril saime lisaks kõigele muule ülevaate testimise liikidest.

Osalised kuulasid suure huviga ja said palju kasulikke näpunäiteid.

 

Pärastlõunal asusime taaskord tarkvara arendamise kallale.

 

 

Muidugi olid kohal ka mentorid, kes vajadusel aitasid osalisi.

 

Koodi kirjutamine see on fun!

Mulle tundub, et selleks hetkeks olid meeskonnad küll kenasti sisse elanud ja tundsid ennast üksteise seltskonnas vabalt. Tegelikult paistis juba päris algusest peale, et inimesed oleks tundnud üksteist justkui terve elu:)

5. päev - alustame tarkvara arendamist

Viienda päeva hommik algas standupiga. Sellest sai rutiin, igapäevane satndup oli meie tööelu tavaline osa. Standupil rääkis iga meeskonna liige, mida ta eelmisel päeval tegi, mis takistusi oli kohanud ning mida plaanis käesoleval päeval teha. Standupi viis läbi professionaalne Scrum Master.

Mõlemad meeskonnad tegid esimesed sisulised commitid koodihoidlasse. Algas reaalsete projektide tarkvaraarendus. Jess!

4. päev - teeme prototüüpe ja õpime meeskonnakaaslasi tundma

Hommikul tutvustasid meeskonnad user interface (UI) prototüüpe tooteomanikele.

Ja seda nii paberkujul kui elektroonselt:)

Ka mentoritele pakkusid UI prototüübid väga huvi.

Osalejad said jooksvalt tagasisidet prototüüpidele.

Pinnale kerkisid küsimused äriprotsesside kohta, mis koheselt lähemalt lahti selgitati.

Päeva teises pooles pani Sander meid arhitektuuri seminaril mõtlema keeruka infosüsteemi jaoks kõige sobivamate lahenduste leidmisele.

Osalised mängisid värskes õhus erinevaid team building mänge, milledest kõige rohkem kirgi küttis paadihuku simulatsioon. Kui tahad oma meeskonnakaaslasi tõsiselt tundma õppida, siis tasub ära proovida:)

Mängud mängitud, asuti jälle töö kallale. Päev lõppes esimese sprindi planeerimisega.

3. päev - mida klient päriselt vajab ehk analüüs on kõige alus

Hommik algas liftilause koostamisega . Selle käigus tekkinud arutelu viis meeskonna arendamise osas ühele lainele.

 

Denissi läbi viidud analüüsi seminarist sain endale kirja huvitava mõtte - uuelt kliendilt tasub küsida seda, mida ta oma vana süsteemi juures vihkab.

 

Lisaks aitasid mentorid osalistel valmistuda tooteomanikega kohtumiseks.

Kohtumine tooteomanikega läks mõlemal meeskonnal väga produktiivselt. Lepiti kokku, mis nõuded on olulised ja mille võib algselt välja jätta.

Kaisa viis läbi User Interface seminari, kus avastasin, et on palju lihtsaid, pisikesi, kuid väga olulisi UI ja UX aspekte, millele ma varem absoluutselt tähelepanu ei osanud pöörata.