“#5 unConference ” | IT zajednica Rijeka – Powered by 46elks 🦌

 In Sažetak razgovora


Autor: Deborah Brakus Kršul

📌 PREDAVAČI:

Karlo Šegota, Filip Perica  i Dea Marin

👨‍💻 VODITELJ:

RENE BRAKUS partner u 46ELKS (https://46elks.com) stvara preduvjete za dijeljenje znanja i jačanja povezanosti unutar IT zajednice u Rijeci. 

📌 DOMAĆIN:

STEPRI – Znanstveno-tehnološki park sveučilišta u Rijeci

Svrha osnivanja Znanstveno-tehnologijskog parka jest da se kroz sinergiju znanstvenih, tehnologijskih i poduzetničkih potencijala Sveučilišta i regije potakne brži razvoj

znanosti i poduzetništva i tako stvore dodatne vrijednosti koje će doprinijeti bržem ekonomskom razvoju i konkurentnosti regije i zemlje.

Usluge koje nudi Znanstveno-tehnologijski parku suradnji s Uredom za Transfer Tehnologija (UTT) Sveučilišta u Rijeci strukturirani su oko tri programa:

1. zaštita i transfer intelektualnog vlasništva,

2. inkubacija poduzetnika (tzv. spin-off tvrtke),

3. licenciranje i komercijalizacija novonastalog proizvoda i-ili intelektualnog vlasništva.

📌 SPONZOR: 46elks Croatia

Tvrtka 46elks developerima nudi API za SMS i voice s kojim je te usluge jednostavno ugraditi i aplikacije. Sponzor financira snimanje eventa profesionalnom A/V opremom i zaslužan je za to što ćete i ovaj UnConference moći pratiti i u njemu udaljeno sudjelovati uživo preko Youtubea, Facebooka i Linkedina. 

GALERIJA FOTOGRAFIJA JE NA DNU ČLANKA ⬇

Ako ste propustili live, razgovor možete pogledati na linku:

KARLO ŠEGOTA

Naš već poznati gost koji je sudjelovao u Live raspravi na temu: REMOTE RAD IZ PERSPEKTIVE POSLODAVACA I ZAPOSLENIKA

Još jedan uspješni Riječanin sa zagrebačkom adresom je certificirani voditelj projekta s poviješću rada u IT i uslužnoj industriji. Vješt u agilnim metodologijama, menadžmentu, pregovaranju, planiranju projekta, PM alatima i javnom nastupu.

Stručnjak za upravljanje programima i projektima sa SUMMA CUM LAUDE MBA diplomom, diplomirao na Zagrebačkoj školi ekonomije i menadžmenta.

Karlo je vlasnik tvrtke SOMNUS IT u industriji je od 2016. godine i posluje većinom sa stranim klijentima.

FILIP PERICA

Senior Data Engineer / ETL Developer s projektnim iskustvom u razvoju Data Lakes i Data Warehousea. Radio i završio je 6 projekata koji pokrivaju mnoge industrije i tehnologije uglavnom kao ETL / DW Developer.

Iskusni inženjer podataka koji koristi AWS stack developing pipelines upotrebljavajući Python, Lamba, Glue, PySpark, Step Functions, Redshift, Kinesis i Apache NiFi.

Osim tehničke strane, također je zainteresiran za Growth Hacking i vještine koje dolaze u vođenju i upravljanju projektima. Završio je edukacije koje pokrivaju kritičko mišljenje, dizajn razmišljanje, gamifikaciju, NLP, Scrum Master i druge vještine.

Svestrani Filip slobodno vrijeme predaje u svojoj plesnoj školi i organizira događanja i susrete.

DEA MARIN

Dea Marin je diplomirala Tehnički fakultet u Rijeci, gdje je i magistrirala računarstvo. Karijeru je također započela u Rijeci, kao developer, a danas je Senior Software Tester i Certified Scrum Master. Veliki je tech-enthusiast, a uz to, voli glazbu, planinarenje, sport i sve što vole mladi 🙂.

Dea je danas zbog obaveza s nama sudjelovala preko komentara koji su niže navedeni.

Dea se slaže sa kolegama i smatra da je stvar je u tome sto scrum / agile neće funkcionirati ako ga samo nas tim “uhvati”, već mora biti podržan od strane kompletne organizacije.

Što se tiče scrum mastera kaže kako često pomaže i da tim može neometano raditi, da npr. netko izvan tima ne krene potezati članove tima za rukav i uvaljivati im zadatke koji nisu dio backloga.

Dea se dotakla i Waterfall metode i gradnje Pelješkog mosta za koju smatra da je izvrsna usporedba.

Ta metoda se koristi za ponovljive stvari u industriji – tipa, radiš klupe, aute… dok software nastaje iz ideje, i stvari se mijenjaju “u hodu” pa nije primjenjiv.

Ako želite da projekt ima imalo šansi za uspjeh potrebno je imati dobro razrađenu metodologiju.

Metodologije se ugrubo mogu podijeliti na dvije skupine: standardne i agilne. Standardne metodologije se još nazivaju i waterfall (slap), jer se odvijaju po fazama, gdje jedna slijedi drugu.

Danas se u softverskoj industriji koristi niz različitih metodologija razvoja softvera. Metoda razvoja vodopada jedna je od najranijih metoda razvoja softvera. Sve ove ranije metodologije nazivaju se tradicionalnim metodologijama razvoja softvera.

Agile model je noviji model razvoja softvera uveden kako bi se riješili nedostaci tradicionalnih modela. Glavni fokus Agilea je uključivanje testiranja što je ranije moguće i izdavanje radne verzije proizvoda vrlo rano, raščlanjivanjem sustava na vrlo male i upravljive dijelove.

ŠTO JE AGILE DEVELOPMENT

Agilne metode po prvi puta se pojavljuju 1957. u IBM-u, no sredinom 1990-tih se razvijaju kao alternativa tradicionalnim odnosno standardnim metodama.

Agilni pristup odnosno metode imaju više objašnjenja. Jedno od njih jest da su one, govoreći o IT projektima interaktivne te kroz koje se zahtjevi projekta zajedno s riješenima razvijaju kroz suradnju više funkcionalnih timova. Najveći naglasak kod agilnih metoda dakako se stavlja na fleksibilnost te brz odgovor na promjene.

Agilne metode se smatraju adaptivnim, projekt može kretati temeljen na jednoj ideji te u konačnici, rezultirati nečime drugačijem od prvobitne ideje.

Glavne značajke agilnih metoda dakako jesu mogućnost promjena u bilo kojem trenutku životnog vijeka projekta te brz odgovor na rizik i promjene. Dakle, promjene se u agilnim metodama promatraju kao sastavni dio svakog projekta i tome su prilagođene

Na taj način, naručitelj odnosno korisnik u bilo kojem trenutku može dati nove zahtjeve ili eventualna poboljšanja proizvoda/usluge.

Najzastupljeniji agilni pristup je Scrum. Njegovoj zastupljenosti ponajviše se može prepisati jednostavnost principa funkcioniranja u smislu primjenjivosti istog na bilo kojem tipu projekta

SCRUM METODA

Termin Scrum potječe iz ragbija, a znači „vraćanje lopte koja je izašla iz igre nazad u igru“.

Radi se o brzom, prilagodljivom samo organiziranom procesu razvoja programskog proizvoda. Ovaj pristup koji povećava brzinu i fleksibilnost u razvoju programskog proizvoda, opisali su 1986. godine Takeuchi i Nonaka.


Današnji Scrum zacrtali su početkom ’90-tih Ken Schwaber i Jeff Sutherland. Proces razvoja programskog proizvoda provodi se kroz tri faze:
• Prije igre (planiranje, dizajn/arhitektura visoka razina apstrakcije)
• Igra (razvoj, sprintovi – iterativni ciklusi, poboljšanja, nove verzije)
• Poslije igre (nema novih zahtjeva, sustav spreman za produkciju).

Artefakti u Scrumu

Product Backlog

Product backlog je sortirana lista svega što će možda biti potrebno za proizvod i jedini izvor zahtjeva za bilo kakvim promjenama koje se rade na proizvodu. Vlasnik proizvoda je odgovoran za Product backlog, uključujući njegov sadržaj, raspoloživost i sortiranje. Product backlog evoluira kako evoluira proizvod i okolina na kojoj će se primjenjivati, on sadrži listu svih mogućnosti, funkcionalnosti, zahtjeva, unaprjeđenja i popravaka koja zajedno čine promjene koje će se primijeniti nad proizvodom u budućnosti. Obično je sortiran prema vrijednosti, riziku, prioritetu i nužnosti. Stavke na vrhu backloga su dio trenutnih razvojnih aktivnosti.

Sprint Backlog

Sprint backlog je skup stavki s Product Backloga koje su odabrane za Sprint plus plan. To je procjena razvojnog tima koje funkcionalnosti će biti u sljedećem Inkrementu.

Sprint backlog je plan S dovoljno detalja da bi se na Dnevnom scrumu mogle razumjeti aktualne promjene. Razvojni tim mijenja ga tijekom Sprinta. Ti zadaci se događaju kada Razvojni tim, radeći prema planu, nauči nešto više o poslu koji je potreban da se zadovolji cilj Sprinta. Kako se pojavi potreba za novim poslom, Razvojni tim ga dodaje na Sprint backlog. Samo razvojni tim može mijenjati Sprint backlog tijekom Sprinta. Sprint backlog je vidljiva slika posla u realnom vremenu kojeg Razvojni tim namjerava obaviti tijekom Sprinta i koji pripada isključivo Razvojnom timu.

SCRUM ULOGE

Uloge koje postoje su: Product Owner, Scrum Master i Development Team. 

Product Owner zastupa kupca i zna što kupac želi i to je uvijek samo jedna osoba. 

Scrum Master je osoba koja se često miješa s voditeljem projekta. Scrum Master nije voditelj projekta već osoba koja služi da timu pomaže kod primjene Scruma te da miče sve prepreke koje netko može postaviti pred tim. On zapravo vodi tim služeći mu.

Development Team je skupina pojedinaca koji rade na projektu tako da planiraju aktivnosti koje treba obaviti da bi napravili određene funkcionalnosti, procjenjuju ih, organiziraju ih u tzv. sprinteve i izvršavaju zadatke.

Događaji koji se odvijaju u Scrumu su: Sprint PlanningSprintDaily Sprint MeetingSprint Review i Sprint Retrospective Meeting.

Sprint Planning je sastanak (koji traje maksimalno jedan dan, a vrlo često i kraće) na kojem se uzimaju zadaci iz tzv.

Daily Sprint Meeting je dnevni sastanak, koji se održava svaki radni dan u isto vrijeme i u kojem članovi tima i samo oni daju odgovore na tri pitanja: „Što smo radili jučer?“„Što ćemo raditi danas?“ i „Imamo li kakvih problema?“

Kada je Sprint završen radi se sastanak koji se zove Sprint Review,  u kojem se Product Owneru i svim zainteresiranim prezentira što je napravljeno u Sprintu. 

Sprint Retrospecitve je sastanak na kojem tim i Scrum Master odgovaraju na pitanja: „Što je bilo dobro u zadnjem Sprintu“, „Što nije bilo dobro u zadnjem sprintu?“ i „Što učiniti da bi radili bolje?“

NE MOGU SE SVI PROJEKTI VODITI AGILNO

Prva i osnovna prepreka je da se svi projekti jednostavno ne mogu tako voditi. Državna institucija gradi Pelješki most propiše natječaj u kojem jasno opiše što želi i do kada to želi. Naravno uz fiksnu cijenu. Ovdje je agilnu metodologiju nemoguće promijeniti jer uz ta ograničenja promjene jednostavno nisu moguće.

Da bi se radilo po agilnim metodologijama, kupac (naručitelj) mora poznavati jednu od tih metodologija, aktivno sudjelovati u projektu i biti voljan istu i primijeniti.

Sva odgovornost je na timu, a ne na jednom pojedincu. To bi bilo predivno kada ne bi znali iz prakse da svi ljudi nisu odgovorni, a da takve jednostavno ne možete zamijeniti drugim, odgovornim, jer ih jednostavno – nemate.

WATERFALL MODEL JE TEŠKO PRIMJENJIV U IT PROJEKTIMA

Waterfall“ model upravljanja projektom jedan je od najpoznatijih klasičnih pristupa. Svoje ime je dobio jer u nacrtima podsjeća na slap s kaskadama. Prvi put se spominje još 1956. godine u prezentaciji Herbeta D. Beningtona na Simpozijumu
naprednih metoda programiranja digitalnih kompjutera.

Za njega je karakteristično da njegov napredak teče od vrha do dna, pri čemu se svaki faza završava prije početka nove
faze te je povratak na neku od prethodnih faza nemoguć.
U današnje doba ga se teško nalazi u IT projektima, ali zato se još uvijek koristi u građevinskim projektima što je sasvim logično.

Glavne faze jesu specifikacija zahtjeva, dizajn, implementacija/razvoj, testiranje i održavanje.

Sa stajališta IT projekata, tim vrlo puno vremena odvaja na fazu specifikacije zahtjeva odnosno planiranje i dizajn kako, kada krene faza implementacije/razvoja, nema dodatnih zahtjeva, nedoumica ili nedefiniranih dijelova projekta.. Iz tog razloga, projekti koji imaju dugi vremenski vijek su pogodi za vodopadni pristup.

On je pogodna za razvoj projekata koji su stabilni. Dakle, projekti na kojima se u samoj fazi planiranja i specifikacije zahtjeva mogu odrediti svi dijelovi krajnjeg rezultata, sve značajke istih te mogući rizici – to su projekti koji su pogodni za vodopadni pristup.
Taj princip je namijenjen projektima koji se u samom početku mogu u potpunosti definirati, odrediti se svi krajnji ciljevi, svi dijelovi krajnjeg rezultata te sve njegove značajke isto kao i projekti gdje je dulji vremenski rok samog trajanja projekta te potencijalno projekti koji nemaju velikih i značajnih utjecaja odnosno rizika u fazi razvoja.

KOJA JE RAZLIKA IZMEĐU WATERFALL I AGILE METODOLOGIJE ?

Agile model isporučuje radnu verziju proizvoda vrlo rano u usporedbi s Waterfall metodologijom. Kako se sve više značajki isporučuje postupno, kupac može rano shvatiti neke od prednosti.

Agile model isporučuje radnu verziju proizvoda vrlo rano u usporedbi s tradicionalnim metodologijama, tako da kupac može rano shvatiti neke od blagodati. Vrijeme ciklusa testiranja Agile relativno je kratko u usporedbi s Waterfall metodologijom, jer se ispitivanje vrši paralelno s razvojem.

Model vodopada vrlo je krut i relativno manje fleksibilan od modela Agile. Zbog svih ovih prednosti, Agile je trenutno poželjniji od Waterfall metodologije.

Waterfall pristup zahtjeva da se prvo napravi cijeli proizvod, što zna potrajati mjesecima, a potom se testira.

Pri testiranju se nerijetko dešava da se nalaze razne greške, te se projekt mora vratiti na prvu fazu,agilne metode izbjegavaju takve situacije.

Tako se klijentu u roku dva do četiri tjedna prezentiraju razni dijelovi proizvoda, te se izmjenjuju po potrebi.

GALERIJA FOTOGRAFIJA:

Hvala Vam što ste odvojili svoje vrijeme za nas i ukoliko ste zainteresirani za suradnju ili nam se samo želite pridružiti javite nam se na linkove:

🔗IT ZAJEDNICA RIJEKA:

📲 +385996768133

⌨ rene@46elks.com

Facebook grupa

Facebook stranica

LinkedIn

Meetup

46 ELKS

Recommended Posts

Leave a Comment

Kontaktirajte nas

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt

Start typing and press Enter to search