Stanje u IT sektoru

[Lord Protector]

20 hours ago, Svarog said:

mali intermezzo na topiku, sa događajem od juče:

 

- Da li imate Fortran developere? Trebaju nam hitno za jedan projekat.

- Je l može da budu juniori?

- Daj ne zezaj.

- Pa prvi si počeo.

 

Verovao ili ne, ima jedna institucija kod nas gde se još vrte cobol programi, i moraju da zovu developere iz penzije da im održavaju sistem. Nov sistem nije zaživeo već godinama pa su prinuđeni da se oslone na stari.

 

 

Edited January 28, 2023 by slow

[Lord Protector]

8 hours ago, LaLinea said:

Samo na jednom projektu smo imali pravi scrum. Product owner koji je tacno znao sta zeli, jer je prethodno organizovao 5-dnevno okupljanje stakeholdera i developera da se usaglase zelje i tech mogucnosti. Grooming za sledeci sprint svakog drugog cetvrtka, satanak za pitanja iz tekuceg sprinta, ako ih ima, svakog utorka. Release svake druge srede, na kraju sprinta, uz demo njemu i stakeholderima. Nakon toga odmah njihov review. Sutradan, umesto daily imali smo retrospektivu samo za nas iz dev tima, potom planning i startovanje novog sprinta. Ceo projekat smo odradili bez trzavica i prekoracenja rokova.

Jos jedan projekat mi je bio odlican, jer je product owner poznavao sve moguce poslovne procese, UX, payment, pravne, tehnicke, ekonomske i sve druge uticaje na app. Osim sto smo imali dvonedeljni sprint i jednom u dve nedelje grooming, nismo imali druge sastanke. Prekoracili smo rok od godinu dana za mesec dana, ali su stakeholderi  bili bas zadovoljni.

Svi ostali projekti su “scrum”, jer se agile svede na to da product owner u stvari ne zna sta hoce, ne poznaje dovoljno biznis procese i samo delimicno pokrije cak i happy flow jer je uglavnom uzasno povrsan i ima losu komunikaciju i sa dev i sa stakeholders, jer je umislio da je polubog. Pogibelj za dev tim 

 

 

Dragi kolega, mi matoriji moramo da se oslonimo na AI da bi smo vas razumeli 

 

Ja sam tvoj post ubacio u ChatGPT sa sledećim upitom: 

 

Zameni reči: scrum, product owner, stekeholder, grooming, sprint, review, daily, retrospektiva sa definicijama na srpskom jeziku i detaljno analiziraj sledeći tekst sa zamenjenim definicijama u tekstu:

 

i dobio:

 

Quote

Samo na jednom projektu smo imali pravi metod rada po principima agilnog razvoja softvera, poznatog kao Scrum. Product owner, odnosno osoba koja je odgovorna za proizvod, je tačno znao šta želi, jer je prethodno organizovao 5-dnevno okupljanje svih zainteresovanih strana, poznatih kao stakeholders, i developera da se usaglase želje i tehničke mogućnosti. Grooming, odnosno planiranje i priprema za sledeći sprint, svakog drugog četvrtka, satanak za pitanja iz tekućeg sprinta, ako ih ima, svakog utorka. Release, odnosno objavljivanje proizvoda svake druge srede, na kraju sprinta, uz demo njemu i stakeholders. Nakon toga odmah njihov review, odnosno pregled proizvoda. Sutradan, umesto svakodnevnog sastanka, imali smo retrospektivu, odnosno analizu šta je dobro i šta loše radili, samo za nas iz dev tima, potom planning, odnosno planiranje, i startovanje novog sprinta. Ceo projekat smo odradili bez trzavica i prekoračenja rokova. Još jedan projekat mi je bio odličan, jer je product owner poznavao sve moguće poslovne procese, UX, payment, pravne, tehničke, ekonomske i sve druge uticaje na app. Osim što smo imali dvonedeljni sprint i jednom u dve nedelje grooming, nismo imali druge sastanke. Prekoračili smo rok od godinu dana za mesec dana, ali su stakeholders bili baš zadovoljni. Svi ostali projekti su “scrum”, jer se agile svede na to da product owner u stvari ne zna šta hoće, ne poznaje dovoljno biznis procese i samo delimično pokrije cak i happy flow jer je uglavnom užasno površan i ima lošu komunikaciju i sa dev i sa stakeholders, jer je umislio da je polubog. Pogibelj za dev tim.

 

 

 

 

 

Edited January 28, 2023 by slow

[Vapad]

Prosto uživam čitajući vas

 

Lepo je videti toliko različitih, pravih, iskustava. Zapravo, neprocenjivih iskustava.

Jer je previše šuma i fame oko raznih frejmworka rasuto svuda po netu, ponajviše jer je koučing u tome još uvek ponekome biznis, pa se tu priča o savršenim stvarima i brzim rešenjima.

A nije tako. Čitao sam jednu sjajnu knjigu u izdanju Harvard Biznis Rivjua- doing agile right, apsolutno preporučujem.

 

Ono što sam video se, uglavnom poklapa sa time, iz knjige mislim, of fejlovima, mada me to ne čini preterano srećnim jer sam se zaglibio na sve strane, u svakom pogledu, prepoznajem se u negativnim iskustvima prečesto

 

U kompaniji koju sam baš jako voleo ali sam morao zbog sebe i svog zdravlja otići pre par godina su zamislili u jednom trenutku da je agile sveti gral, pa su vrednosti promenili tako da je agile jedna od njih, doveli stručnjaka za procese koji je crtao divne flow charts, računao fantastično tačne TRT i sve ali... mućak, jer se svelo na to da bez direkcije svi sve rade odmah u projektu jer su agilniji od drugih, ali ne za iste stvari, tako da se dešavalo da svi postignu svoje brojke a biznis fejluje sa OKR debelo. Čujem da se to i dalje dešava. Mislim da izgradnja ipak mora, barem donekle, imati jasan pipeline i timeline kad šta ima smisla raditi.

 

U sledećoj, maloj softverskoj kompaniji koja je bila u fazonu mi smo otelotvorenje agile principa se ispostavilo da je je organizacija takva da CTO direktno samnom priča o tome šta pravimo i zašto i koliko treba vremena, ja dignem tikete developerima i oni rade u nedeljnim sprintovima ali bez ikakvog pravog pretresa šta se i kako radi, priortizuje se dizanjem tiketa na vrh steka ali bez razgovora, a dev radi šta mu se sviđa, to je bilo frustrirajuće. Na kraju kroz priču pokazalo da je debelo precenjena sposobnost tima da isporuči (na tri projekta po 50% over). Ali i projekti su bili shady tako nije bio problem, osim što mi nije prijalo pa sam otišao.

 

Sada sam u firmi koja je osnovana od programera, sa načelima koja su zaista fantastična, ali... CTO otišao pre pet meseci, timovi dobili ovo što je kolega pričao, ownership nad onim što rade, ali tu je isplivao pre svega karakter, a agile je samo naznaka, forma. Ljudi koji su glasni, asertivni, odlučni, jači su isplivali i ipak se na njih oslanja ostatak ekipe. A puno ljudi nije naviklo da ima tako direktne interakcije i da nema "zaštitu" pa vidiš da im je ogroman psihološki teret u razgovoru direktno, recimo za neki feature pored ownera je bio i dev, koji je čovek na svako pitanje crveneo, pokrivao šakama lice, vidim da čoveku nije dobro što je exposed i mora da "običnim" rečnikom objasni što nešto može ili ne može. Ne deluje mi fer na duže staze, ne verujem da je toliko cimanje iz komfor zone baš dobro za neke ljude, možda grešim. Takođe, pošto je interni proizvod, review je teži jer ljudi ipak imaju zadršku a retro još nisam video, a godinu dana sam tu.

 

Voleo bih videti negde zaista pravu uhodanu mašinu, ne mora da bude ni true agile ili šta, samo da radi i da su svi, većinski, happy. Počeo sam da verujem da to ne postoji IRL

[francuski sobar]

14 minutes ago, Vapad said:

Prosto uživam čitajući vas

 

 

I ja isto iako ništa ne razumem

 

[LaLinea]

44 minutes ago, slow said:

 

 

Kolega, mi matoriji moramo da se oslonimo na AI da bi smo vas razumeli 

 

Ja sam tvoj post ubacio u ChatGPT sa sledećim upitom: 

 

Zameni reči: scrum, product owner, stekeholder, grooming, sprint, review, daily, retrospektiva sa definicijama na srpskom jeziku i detaljno analiziraj sledeći tekst sa zamenjenim definicijama u tekstu:

 

i dobio:

 

ubacio je happy flow 

Da, to je zanimljiva tema za razgovor.

Upotreba engleskih reci u nasem jeziku, bez obzira na to koliko mi nije draga, postaje gotovo neminovnost ukoliko za svaki termin od jedne ili par reci, moras upotrebiti citavu recenicu da ga opises.

Nas jezik nije pratio razvoj tehnologija i metodologila u ovoj oblasti, narocito od kad je taj razvoj postao ubrzan. 
Nazalost, slicno se desava i u drugim oblastima u kojima cak i imamo odgovarajuce reci u srpskom, a koristimo nemacke i engleske reci (pokusaj da razumes automehanicara, npr). 
Za utehu je to sto je tako bilo oduvek, negde procitah da, kad si obucen u zimsku odecu, jedino su rukavice izvorno iz naseg jezika, sve ostalo smo pozajmili iz nekog od jezika koji su tada bili dominantni. To je takodje jedan od nacina da se obogati jezik.

[Delija67]

3 hours ago, Vapad said:

U kompaniji koju sam baš jako voleo ali sam morao zbog sebe i svog zdravlja otići pre par godina su zamislili u jednom trenutku da je agile sveti gral, pa su vrednosti promenili tako da je agile jedna od njih

Ovo sam primetio na dosta mesta da se od agile scruma (na srpskom bi to bio neki oblig radnickog samoupravljanja ) pravi religija. Kad nekog propovednika pitas da ti objasni zasto se tako radi uglavnom dobijes odgovor zato sto je tako po skramu. Nemam nikakvo formalno znanje iz organizacije rada, ali bih voleo da vidim neko kriticko poredjenje agile i waterfall principa gde se vidi sta je prednost, a sta mana svakog pristupa. Ja radim u mikrotimu za velikog i ozbiljnog klijenta po waterfall sistemu okruzen skram i nekim hibridnim timovima oko mene.

[LaLinea]

Po mom misljenju, velike razlike postoje jedino kad se krece u razvoj novog projekta.

 

Waterfall podrazumeva da na pocetku prikupis sve zahteve od stakeholdera i dev tim krece da projektuje i razvija pun set funkcionalnosti, uz povremene prezentacije zahtevaocima onoga sto je do tad uradjeno. Nema deployment-a na produkciju sve dok gotovo svi inicijalni zahtevi nisu u potpunosti zavrseni.

Prednosti: dev tim ima siroku sliku celog proizvoda, projektovanjem se predvide sve funkcionalnosti, odabir arhitekture se pravi prema unapred utvrdjenom setu zahteva.

Mane: kasno se dobije povratna informacija od korisnika, pa se moze desiti da, ako se neki zahtev lose razumeo, a utice na niz drugih funkcionalnosti, ispravke budu dosta slozene, nekad se cak i odbaci ceo projekat. Zbog paralelnog rada, tim je najcesce podeljen po funkcionalnostima.

Scrum podrazumeva da ceo tim radi na malim delovima projekta, koji se mogu zavrsiti brzo, isporuka se radi nakon svakog sprinta, znaci na 2 ili 3 nedelje, dobije se povratna informacija od krajnjih korisnika odmah i ako nesto nije ok, ispravlja se mali deo koda.

Prednosti: brzo dobijanje povratnih informacija da li software ispunjava zahteve, lakse je praviti korekcije, svi clanovi tima rade na svim funkcionalnostima zajedno

Mane: dosta sastanaka, tim nema siru sliku na pocetku, pa ima dosta izmena na vec projektovanim delovima, nekad mora da se menja i tehnologija koja se koristila, jer kod kasnije ispostavljenih zahteva ona prethodna bude nedovoljno dobra. Mnogo stresno ukoliko ni Product owner nije imao jasnu viziju sta hoce od projekta.

 

Na projektima koji su zavrseni i koji su usli u fazu odrzavanja i sporadicnih dodavanja novih funkcionalnosti, mislim da nema velike razlike izmedju ova dva nacina organizacije rada, osim u terminologiji.

 

[Sammael]

Waterfall radi samo ako su unapred poznati svi zahtevi projekta i nema nikakvih promena u toku projekta. Čim dođe do bilo kakve promene koja zahteva vraćanje u neku prethodno završenu fazu (npr. analizu), to više nije čist waterfall nego nekakav hibrid, koji se često zove iterativni waterfall.

 

Waterfall je sasvim ok za određene tipove projekata. 

[Sammael]

Za projekte u održavanju kanban je po mom iskustvu bolji i od scruma i od waterfalla.

[lord_s]

Waterfall je veoma tesko primenljiv u danasnjem IT sofwtware developmentu, makar onaj cisti, izvorni tip, evo ti project case, sam odredjuj requirements, sow, ne brini za budget, etc.
Ima mnogo siru primenu u proizvodnji, gradjevini i slicnim industrijama.
Takodje, waterfall je u istoj ravni kao i agile ako pricamo o project management principima dok su scrum i kanban frameworksi, tj razliciti (a prilicno povezani) nacini implementiranja agile metodologije. Principi kanbana su svuda oko nas, maltene sve PM platforme danas koriste kanban tablu i veoma cesto ide ruku-uz-ruku uz scrum koji definise citav proces rada (vec spominjani sastanci, sprintovi, demo's, budget monitoring, i slicno).

[Sammael]

Meni prilično smeta termin agilna "metodologija," najpre zato što uopšte nije u pitanju metodologija nego skup vrlo načelnih principa (od kojih su mnogi na nivou "mir u svetu"). Zato mnogo više volim da pričam o principima agilnog rada (kraće iteracije, brže dobijanje feedback-a, rezultati ispred formalnih procedura, preuzimanje vlasništva nad proizvodom od strane tima, itd).

 

Waterfall s druge strane jeste jedna vrlo jasna i precizna metodologija i kao i mnoge druge metodologije pada u vodu čim se susretne sa patternom koji metodološki nije predviđen.

 

Najveća slabost agilnog rada je to što su ugovori koji se potpisuju sa klijentima izuzetno retko takvi da podržavaju takav rad. Isto kao što niko nije blesav da molera plaća na sat nego plaća po m2 ofarbane površine, tako i klijenti nisu ludi da plaćaju agilne timove T&M dok oni iteriraju, nego žele da plate za konkretne feature, a žele bogami i procenu kada će te konkretne feature dobiti. Tu agilni rad pada potpuno u vodu i mora se primeniti, na nezadovoljstvo svih, klasični project management: broj resursa x broj sati x cena po satu + bafer za nepredviđene okolnosti. Kako dolazimo do potrebnog broja sati? Lupamo cifre, kao i uvek, praveći se da je moguće biti egaktan. Skoro sam gledao neko ludilo koje se zove COSMIC poeni, i inkorporirano je u ISO standard, ali apsolutno ne mogu da zamislim realan scenario gde se ovo koristi osim za NASA projekte: https://www.iso.org/standard/54849.html

[Zverilla]

Agilni i vodopad su pristupi pravljenju programskih resenja a ne metodologije.

 

Metodologija je nauka o metodi 

[Zverilla]

5 hours ago, LaLinea said:

Po mom misljenju, velike razlike postoje jedino kad se krece u razvoj novog projekta.

 

Waterfall podrazumeva da na pocetku prikupis sve zahteve od stakeholdera i dev tim krece da projektuje i razvija pun set funkcionalnosti, uz povremene prezentacije zahtevaocima onoga sto je do tad uradjeno. Nema deployment-a na produkciju sve dok gotovo svi inicijalni zahtevi nisu u potpunosti zavrseni.

Prednosti: dev tim ima siroku sliku celog proizvoda, projektovanjem se predvide sve funkcionalnosti, odabir arhitekture se pravi prema unapred utvrdjenom setu zahteva.

Mane: kasno se dobije povratna informacija od korisnika, pa se moze desiti da, ako se neki zahtev lose razumeo, a utice na niz drugih funkcionalnosti, ispravke budu dosta slozene, nekad se cak i odbaci ceo projekat. Zbog paralelnog rada, tim je najcesce podeljen po funkcionalnostima.

Scrum podrazumeva da ceo tim radi na malim delovima projekta, koji se mogu zavrsiti brzo, isporuka se radi nakon svakog sprinta, znaci na 2 ili 3 nedelje, dobije se povratna informacija od krajnjih korisnika odmah i ako nesto nije ok, ispravlja se mali deo koda.

Prednosti: brzo dobijanje povratnih informacija da li software ispunjava zahteve, lakse je praviti korekcije, svi clanovi tima rade na svim funkcionalnostima zajedno

Mane: dosta sastanaka, tim nema siru sliku na pocetku, pa ima dosta izmena na vec projektovanim delovima, nekad mora da se menja i tehnologija koja se koristila, jer kod kasnije ispostavljenih zahteva ona prethodna bude nedovoljno dobra. Mnogo stresno ukoliko ni Product owner nije imao jasnu viziju sta hoce od projekta.

 

Na projektima koji su zavrseni i koji su usli u fazu odrzavanja i sporadicnih dodavanja novih funkcionalnosti, mislim da nema velike razlike izmedju ova dva nacina organizacije rada, osim u terminologiji.

 

Ne slažem se sa ovim prednostima i manama. Radio sam na velikim projektima, neki su rađeni vodopadom , neki agilnim pristupom, i ne mogu reći da postoji ovako jasna podela kako si napisao. 

 

Tipa, broj sastanaka u vodopadu je sulud. Ili da u agilnom pristupu svi članovi tima rade (ili bar znaju) na svim funkcijama proizvoda. Čim projekat naraste da je potrebno nekoliko timova, obično sve ode u materinu / zavisi od pojedinaca koliko će potegnuti da vide šta rade ljudi oko njih a koji nisu u njihovom timu 

 

Ja ipak dajem prednost agilnom pristupu iz prostog razloga: nemoguće je unapred znati i definisati sve detalje proizvoda, a pogotovo proceniti šta je uradivo unutar predefinisanog budžeta ( u zavisnosti od tehnologije, nešto što deluje trivijalno može biti besmisleno kompleksno, ili obratno. A djavo često sedi u detalju kog na početku niko nije svestan)

[salerokada]

11 hours ago, Vapad said:

Voleo bih videti negde zaista pravu uhodanu mašinu, ne mora da bude ni true agile ili šta, samo da radi i da su svi, većinski, happy. Počeo sam da verujem da to ne postoji IRL

Ja sam to imao u jednoj prethodnoj firmi. Nije bio agile tj. imali smo neki svoj. Planiranje svakog ponedeljka, verzija kada se završi par opipljivih zadataka (nekad posle 3 dana, nekad posle 2-3 nedelje). Bez menadžera, bez product owner-a, bez skram mastera. Samo nas 5-6 programera. Ja i vođa tima smo poznavali domen i pričali sa klijentima.
Ali smo bili svi sličnog senioriteta, svi već više godina u firmi i bili smo se baš lepo uigrali i podelili uloge.
Iako je firma generalno bila bezveze, mi u timu smo odlično radili.

Poznanik koji je prodžekt menadžer je otišao u jednu američku firmu kod nas i tamo kaže da je zatekao zategnut proces gde on kao menadžer dovoljno unapred zna šta treba da se radi i sada pravi planove za ono što stiže za 2-3 meseca sa vođom tima i onda se samo drže tog plana.
Skoro sam pričao sa programerima iz jedne manje poznate NS firme gde je jedan hvalio da su im procesi dobri i da sada završavaju nešto što u produkciju treba da ide u aprilu.

Edited January 28, 2023 by salerokada

[LaLinea]

50 minutes ago, Zverilla said:

Ne slažem se sa ovim prednostima i manama. Radio sam na velikim projektima, neki su rađeni vodopadom , neki agilnim pristupom, i ne mogu reći da postoji ovako jasna podela kako si napisao. 

 

Tipa, broj sastanaka u vodopadu je sulud. Ili da u agilnom pristupu svi članovi tima rade (ili bar znaju) na svim funkcijama proizvoda. Čim projekat naraste da je potrebno nekoliko timova, obično sve ode u materinu / zavisi od pojedinaca koliko će potegnuti da vide šta rade ljudi oko njih a koji nisu u njihovom timu 

 

Ja ipak dajem prednost agilnom pristupu iz prostog razloga: nemoguće je unapred znati i definisati sve detalje proizvoda, a pogotovo proceniti šta je uradivo unutar predefinisanog budžeta ( u zavisnosti od tehnologije, nešto što deluje trivijalno može biti besmisleno kompleksno, ili obratno. A djavo često sedi u detalju kog na početku niko nije svestan)

Naravno da ova podela, sa prednostima i manama, nije uvek jednostavna kako je napisano, pokusala sam da, in general, dam odgovor Deliji.
Posao dobrih engineering manager-a ili team lead-ova jeste da organizuju i sinhronizuju rad timova i sta ide u koji release, da ne bi sve otislo u pm.

Najrealnije je da svaki projekat zahteva drugaciji pristup, koji zavisi od mnogo faktora: velicine i vrste projekta, da li je firma za koju se radi start-up ili ima stabilan biznis sa utvrdjenim procesima, da li narucilac ima jasne zahteve ili ne, iskustva i velicine dev tima, dinamike isporuka, dinamike i nacina placanja i jos mnogo stvari.