Enda kogemuse kohta veel.. et peegeldas väga hästi et kooli praktikaprojektid on täpselt samasugused oma olemuselt ja probleemidelt kui päris maailma it projektid. seega hea ettevalmistus. Järgnevatele põlvedele tahaks öelda et joonista KÕIK ära, ärge tehke mitte ühtegi liigutust enne kui pole korra tahvlile/paberile sirgeldanud, aitab kõvasti. Meie tiim ei teinud isegi test-serveris midagi ilma konkreetse plaanita. Tulemus - laivis/serveris ei pidanud me mitte midagi tõsist ümber tegema, ainult pisiasjad. Küll aga pidime paberile joonistatud kavandit muutma mitu korda. Selline lähenemine aitab kõvasti muuta tööd kiiremaks. Kuna tehakse asju juba teadmisega, mida minnakse tegema. Teine soovitus / kogemus: Enne praktika algust peab üldine plaan koos olema, ja sellest tuleb üritada kinni pidada. Nii jõuab kõige paremini valmis. Kui mõni päev läks natuke rohkem vaja et planeeritud valmis saada, ei lükatud tööd edasi vaid õpiti hiljem kodus juurde. Samas teine päev sai tunnike varem koju. Samas kõik sai plaanipäraselt valmis Töömaht on tunduvalt suurem, kui paistab. Ei ole mõtet mõelda, et võib aeglaselt tegeleda, kuna tööd on vähe. Iga meeskonnaliikme panus on väga tähtis, muidu koormus hakkab aina suuremaks kasvama. Töö dokumenteerimine on sama tähtis, kui töö ise. Konspekteerige vigu ja nüansse, mida tuleb pärast parandada, muidu jääb kahe silma vahel ja pärast on juba hilja parandada. Rohkem arutelusid, vähem vaidlusi ? see viib sihile! (Nagu meil. :) ) Kui enne praktikumi meeskonnaliikmed elumärke ei ilmuta, tuleks kaaluda uute liikmete otsimist teistest meeskondadest, kus on ka nn "surnud" liikmeid. Ise sai see läbi tehtud, ühest meeskonnast oli aktiivseid liikmeid 3 ja teisest ainult 2, mis andis ideaalse võimaluse uue meeskonna moodustamiseks. Aga meeskonnaliikmeid ei tasu "surnuks" lugeda juba pärast 2 päeva ekirjadele mittevastamist. Soovitatavalt valmistage kõik dokumendid õigeaegselt ära kuupäevadeks mis teile seatakse kuna hiljem läheks teil väga kiireks. Kui on võimalik siis kohtuge meeskonnaga ja tellijaga vähemalt paar korda enne arendusprotsessi, selgitage välja nõuded, mõelge sellele, mida te arendama hakkate ja kuidas midagi reaalselt arendada. Enne arendusperioodi algust (ehk enne seda 2 nädalat) teha juba paar nädalat varem selgeks, mida klient konkreetselt soovib, see meeskonnaga läbi arutada, joonistada lõpptulemuse pilt paberile; mõelda läbi, uurida ja testida erinevaid vahendeid, millega selle lõpptulemuseni jõuda. Soovitused: Järgmistele põlvedele soovitaksin kohe kindlasti kasutada versioonikontrolli ning saabuda "tööle" kokkulepitud ajaks. Ilma nende kahe punktika ei saa mitte kui midagi head tehtud. Kindlasti ei tasu end heidutada mõnest pisemast ebaõnnestumisest; selleks praktika ongi, et õppida oma vigadest, koguda uusi kogemusi ja õppida takistusi ületama. Ärge unustage puhkepause. Tähtsad on koosolekud. Stand-up miitingud iga hommik. Iganädalased koosolekud enne suve. Kaasata kogu tiimi arutellu ja kuulata kõigi arvamusi, mõni neist võib välja tulla hea lahendusega. Ja keegi peaks alati kirja panema kõik, mida arutleti. Omavahel suhtlemine on oluline. Kui kõik rühmaliikmed teavad kus keegi parajasti on oma tegevustega, siis sellega väldib segadusi. Kindlasti kasutage erinevaid online suhtlusvahendeid/koosolekuid/koostage to-do liste või veel parem, kõiki neist. Kõige olulisem osa suveprojektis on meeskond. Tähtis on see, et meeskonnaliikmed saaksid omavahel läbi ning koostöö sujuks. Kindlasti suurimaks soovituseks on koguda meeskonda vähemalt 2 inimest digimeediast ning 2 inimest tarkvarast, kuna kahe mooduli teadmised on erinevad ning projektis on üldjuhul vaja mõlemat. Probleemid võivad tekkida juba meeskonna loomisel. Tuleb arvestada, et liikmed võivad kaduda, näiteks minna USAsse raamatuid müüma või lihtsalt koolist loobuda. Isiklikult ei soovitaks sõpradega meeskonda teha, kuna enda meeskond sai kokku pandud liikmetest, kellega tihti ei suhelnud ning meeskonnatöö oli suurepärane. Meeskonnad tuleb siiski ise kokku panna, mitte jääda lootma õppejõudude abile. Meie lõplik meeskond sai kokku mitme teise meeskonnaga liikmeid vahetades, et oleksid võimalikult võrdsed tiimid. Soovitaksin eelnevalt - kui on teada näiteks mis programeermiskeeles te hakkate enda probleemi lahendama, minge näitkes CodeAcademy lehele ja tehke täiendavalt väheke lisakoolitust endale. Planeeri enne praktika algamist kas ühine hackaton tehnoloogia peale mida ehitama hakkate või organiseerige endale koolitus antud tehnoloogiate kohta. Nii väldid esimesel nädalal valusat õppe protsessi keset tööd. Pange alguses paika reeglid, kellaajad ja üldine distsipliin ja pidage sellest kinni. Kellaajad ja kohalejõudmised peavad olema täpsed, et iga hommikust tegevuskava ei pea mitu korda ülerääkima igale meeskonna liikmele, kes jõuab eri ajal. Ärge hilinege praktikale. Kui praktika hakkab kell 9:00, siis tehke standup meeting 9:15. Iga minut on nii lühikesel ajaperioodil nagu 8 päeva tähtis ning SCRUM põhimõtete järgi ületunde ei tehta. Kui vähegi võimalik, harrastage paaris programmeerimist. Projekti algusfaas läheb nii kiiremini ning hiljem on vähem muresid asjade seletamisel, kuidas miski toimib. Alustage varakult – töö algab juba siis, kui meeskond on kokku pandud. Mõelge koheselt läbi, mis töö kõigile sobib ning siis kui käib tööde esitlemine, siis sobiva kandidaadi leidmisel võtke koheselt kliendiga ühendust, sest vastasel korral võib keegi Teist ette jõuda ja võib juhtuda olukord, kus peate tegema meeskonnaga midagi, millest jõud üle ei käi. Kui olete kliendiga juba kokkuleppele jõudnud, siis hakake varakult planeerima tööde teostamist. Meeskonna liikmena olla kohusetundlik ja arvestada teistega. Käige praktikal kohal. Nii sujub meeskonnatöö paremini. Olla õigel ajal kohal. Käigu suvepraktikal korralikult kohal ja ärgu tulgu käega lööma, et küll kuidagi ikka tehtud saab. Ette antud ajast reserveerige eos ära mingi väikene aeg (kasvõi viimane päev) üllatuste likvideerimiseks, kuna neid tuleb programmeerimises alati ette. Ärge jääge kinni detailidesse, pange paika kindlad prioriteedid, millele keskenduda