Zwolnienia w CD Projekt. Spółka produkcyjna pożegna się ze 100 osobami.

@GordonLameman to chyba głównie przez to, że tym razem ludzie sami nie chcieli się zwolnić. CD Projekt Red miał zawsze gigantyczną rotację pracowników, gernalnie game dev to najgorsza fucha jaką może mieć programista.

@GordonLameman , kto mądry tam poszedł pracować. Już 5 lat temu dyskutowało się, że się tam nie idzie... ale fascynacja gierkami, jest ważniejsza niż kredyty i stabilność życiowa.

@cdbs praca w gamedevie jest ok dla młodziaka podczas studiów; ale jak zaczyna się prawdziwe życie, rodzina na utrzymaniu, kredyt itd to jest to słaba branża.

@KierownikW10 źle wdrożony adżajl, ja mam zawsze z tego bekę.

Ktoś wymyslił prosty system, robisz przez dwa tygodnie, podsumowujesz pracę, wydajesz, planujesz itd. w kółko. Potem ktoś wymyslił że da się na tym kroić frajerów więc wymyślono szkolenia, certyfikaty jakieś wagi, chuje muje powiązania i system skomplikowano tak że w IT sa ludzie co spędzają 50% czasu na klepaniu i aktualizowaniu tasków.

Ciekawe z którego projektu wyjebali ludzi w CDPR.

@libertarianin ja nie jestem z branży IT, ale z tego co słyszałem, to działanie w sprintach sprowadza się do tego, że zespoły planują sobie znacznie mniej tasków niż mogłyby tak żeby dowieźć sprint. Bo lepiej przez tydzień siedzieć na dupie i nic nie robić, niż później tłumaczyć się z tego, że się nie zdążyło.

Jeśli tak robią wszystkie zespoły, to nagle kadra managerska traci pojęcie o tym, co ile czasu powinno być robione i wszystko jest robione coraz dłużej i dłużej.

A dodatkowo tak jak mówisz - dorobiono do tego masę idelogii, spotkań itp. i nagle coś, co powinno być proste, urasta do systemu, który pochłania masę roboczogodzin.

@KierownikW10 Ja jestem z branży IT i ilość tasków w sprincie to tylko estymacja a nie deadline. Po to masz daily żeby zgłaszać problemy i informować że coś się przedłuży.

@KierownikW10 tak jak kolega @Vuaaas pisze, estymujesz zespołem, nie chodzi o dedline, dowieźć / nie dowieźć. Masz estymację ile zrobisz, za dwa tygodnie będziesz to prezentować klientowi ze działa albo wgrywać na żywo na serwer.

Chodzi o to żeby pracować pakietami i dzielić sobie duży problem ma wiele małych łatwiejszych do rozwiazania, ale przy tym zachować wszystkie zalezności między problemami. Alternatywnie, wcześniej (a do niedawna w gamingu to było popularne) jest używany tzw. waterfall, czyli wodospad. I to był straszny rak bo miałeś ludzi co napierdzielają kod do ogłoszonej jakiejś daty premiery na takim E3, i im bliżej daty wydania tym mniej śpisz, mniej widzisz swoje dzieci i mniej odwiedzasz dom - tzw. crunch culture.

Nie trudno przewidzieć że powodowało to masę błędów, wypalenie zawodowe, zwolnienia, wkurw i słabej jakości gry zaraz po wydaniu... (patrz cyberpunk)

@KierownikW10 to piszesz o źle wdrożonym agilu. Normalnie sprint jest "kontraktem" między zespołem a product ownerem. Ogarnięty product owner (albo PM) zna szybkość zespołu, dorzuca lub ujmuje tasków zależnie od tempa danego deva, itd.

A już lead dev to na pewno powinien być w stanie ogarnąć gdy członek zespołu leci w ch... z robotą.

@libertarianin to nie byl prawdziwy komunizm, to nie byl prawdziwy agile

@KierownikW10 

> działanie w sprintach sprowadza się do tego, że zespoły planują sobie znacznie mniej tasków niż mogłyby tak żeby dowieźć sprint. Bo lepiej przez tydzień siedzieć na dupie i nic nie robić, niż później tłumaczyć się z tego, że się nie zdążyło

Nie do końca. W ogólności robi się tak, żeby „dowieźć story pointy”, a nie dostarczyć coś porządnie zrobionego - bo nikogo nie obchodzi, czy to będzie zrobione porządnie.

Planowanie to tak naprawdę loteria, bo w praktyce ktoś ci rzuca temat, bez jasno określonego zakresu tego co trzeba zrobić, masz kilka minut na zastanowienie się, po czym „głosujemy nad estymacją”. Nie ma nawet czasu, żeby zerknąć w istniejący kod czy specyfikacje, i się na spokojnie zastanowić, doprecyzować coś. Do tego takie „estymowanie” (zazwyczaj robione dla zadań na długie miesiące) potrafi trwać bite 10 godzin z krótkimi przerwami, więc po jakimś czasie nie ogarniasz już w ogóle niczego i skupiasz się na tym, żeby zgadnąć taką liczbę, jaką dadzą koledzy (bo ci, którzy się wyłamią w górę/dół, muszą się spowiadać i kłócić z managerem nieogarem).

@sebie_juki

> A już lead dev to na pewno powinien być w stanie ogarnąć gdy członek zespołu leci w ch... z robotą.

Wszyscy lecą, z leadami i kadrą zarządzającą włącznie. Zarządzający to już w ogóle rak, bo notorycznie rozwalają ci cały dzień spotkaniami. A to „daily standup” (w teorii 15-minutowy, w praktyce rzadko kiedy trwa krócej, niż godzinę, potrafi być też rozbity na dwie części w ciągu dnia), a to „sprint retrospective”, a to „lessons learned”, a to jeszcze jakieś inne chore gówno. I tak jest postęp, bo obecnie często pracuje się z domu, a nie z jakiegoś mrowiska 50 osób w pokoju z nieustannie trwającymi rozmowami, dzwoniącymi telefonami, itd.

W ogólności system działa tak, że jakakolwiek próba zrobienia czegoś większego PORZĄDNIE szybko doprowadza delikwenta do frustracji, z tego błędnego koła nie ma wyjścia.

______

Recepta: nie przejmować się. Ważne, że zapłacą. Dobrą kasę. A wyższa kadra zarządzająca bardzo SCRUMa lubi, bo dostaje ładne wykresy.

Na szczęście nie wszystkie projekty to SCRUM/AGILE

@sierzant_armii_12_malp współczuję ci doświadczenia; sam spędziłem ponad 3 lata na projekcie, gdzie mało kto leciał w ch... (jakiś junior dev, jakiś junior qa); dlatego się tam kurczowo trzymałem pomimo lukratywniejszych propozycji z rynku. Robione scrum-but'em. Kluczowe osoby dla powodzenia projektu wysoce wydajne, inteligentne, bez syndromu primabaleriny.

@sebie_juki Widzisz… jak dostaniesz zj**ę od klienta za niezamknięcie taska w Jirze („wiem, że zazwyczaj działa, ale jest taki jeden specyficzny przypadek brzegowy, muszę go jeszcze przedyskutować z Iksińskim z innego zespołu, bo to dotyczy działania jego implementacji, on za dwa dni wraca z urlopu i wtedy (…)”) to się, niestety, dostosowujesz.

@sierzant_armii_12_malp miałem wywalone na zjeby i dość szybko na projekcie miałem tupet hamować releasy / flagować, że coś nie jest ok itd. Zapobiegam zamiataniu brudów pod dywan, a jeśli jednak muszę - sporządzam stosowny komentarz w jirze/azurze. "A nie mówiłem!?"

@sebie_juki Nikt Jiry nie czyta, bo wszyscy się przyzwyczaili, że tam nic nie ma. Kumpel kilka miesięcy temu napisał dla jaj, że ostatni odcinek jakiegoś tam serialu na Netfliksie był do bani - nikt się nie skapnął.

SCRUM to rak - na szczęście, do dopiero drugi taki projekt w mojej karierze.

@sierzant_armii_12_malp @KierownikW10 Proszę się nie obrazić, ale wyrażacie dość mocne opinie, jednocześnie jestem pewien że pracujecie w mało profesjonalnym środowisku.

Życzę bardziej "agileowych" środowisk w przyszłości, myślę że to sprawi że zmienicie zdanie.

Pozdrawiam i z Bogiem

@Kyros Środowiska trafiają mi się różne - to jest wyjątkowo nieprofesjonalne, niestety. Ale z rozmów z kolegami - przy SCRUMie porządku nie ma chyba nigdy.

> z Bogiem

Na szczęście ta gadzina na grubo ponad 99% nie istnieje.

@sierzant_armii_12_malp O ziomuś, ktoś przedawkował tam u was SAFe. Macie zdecydowanie za duży zespół na Agile jeżeli wasze daily trwają dłużej niż 30 minut. Moje daily - nawet, jak mieliśmy zadania - trwały maksymalnie 30 minut. Wszystko ponad 30 minut to były dyskusje na zasadzie "dobra, złapaliśmy się już, to obgadajmy kilka dodatkowych rzeczy, tych co to nie interesuje żegnamy".

10h planowania/refinementu? Brzmi jak SAFe, gdzie z dupy masz nagle zaplanować trzy sprinty z góry, chuj że ten plan i tak się wypierdoli po drodze. Normalnie refinement to godzina tygodniowo, czasu na przejrzenie kodu masz tyle ile chcesz (aczkolwiek osobiście nie potrzebuję go zwykle wcale, bo dobrze podzielone projekty są tak małe, że cały codebase znam lepiej niż swoje własne mieszkanie), i planujesz w ten sposób maksymalnie dwa-trzy duże zadania albo naście małych.

Ja też nie jestem fanem wielu ceremonii robionych na siłę. Siła Agile jest w tym, że robisz to, co działa w zespole, a nie przychodzi Scrum Maestro z batem i napierdala, że teraz robisz retrospektywę, chuj w to że zespół jej ewidentnie nie potrzebuje bo nie ma zbyt wielu kwasów; albo robisz demo zawsze, bo trzeba, nawet jak do pokazania są zadania typu "no zmieniłem konfigi w YAMLu dzisiaj" xD Ale u was coś mocno nie pykło.

I mówię to z doświadczenia w waterfallu, SAFe, Scrumie, Agile'u i Kanbanie. To trochę jak z wyborem języka programowania - no nie będziesz robił czegoś w Javie, jak lepiej działa w Node.js, albo na odwrót. Wkręcanie śrub młotkiem i takie tam xD Wybierasz system działający w danym zespole i składzie osobowym, i docinasz go potem dokładnie do kształtu.

No i słowem zakończenia - jebać certyfikacje ze Scruma, SAFe, i inne metodologie "zwinnopodobne" dopasowane do wyjebania jak najmniejszej liczby Grażynek, co nic nie umieją, a teraz są jakimś Release Train Engineerem czy co tam te debile w SAFe powymyślały xD

@jeikobu__ 

> Brzmi jak SAFe, gdzie z dupy masz nagle zaplanować trzy sprinty z góry, chuj że ten plan i tak się wypierdoli po drodze

Więcej niż trzy. Plan potrafi się posypać jeszcze w trakcie planowania - wystarczy, że wielki bogaty poddostawca powie, że z ważnych przyczyn jego deliwerka zostanie opóźniona o kilka tygodni

Z doświadczenia: Kanban działa chyba najlepiej - menedżer sobie na bieżąco wpisuje priorytety do zadań, ja jak skończę jedno (albo coś mnie blokuje) to po prostu biorę następne o najwyższym priorytecie, itd. Czasami przychodzi menedżer z butami i wrzuca ASAP’a, wtedy się wszystko zostawia i robi o co proszą.

Owszem, formalne spotkania synchronizacyjne są potrzebne, ale w dojrzałym zespole wystarczy jedno na tydzień. A sprinty to się sprawdzają przy integracji (np. robienie cotygodniowego release’a).

@sierzant_armii_12_malp scrum to nie agile, Scrum to dobry frawework pracy na start, jeśli nie ma się ludzi doświadczonych w zespole. Jestem SM w firmie ale zawsze zalecam, jeśli są zasoby, iść dalej. Wiem ze jest wielu SM którzy traktują scrum wręcz biblijnie, co przeważnie kończy się absolutna porażka

agila widzę tak: zadania są małe ale i tak zależność jest taka że trzeba je wszystkie zrobić że coś działało więc przenosi siebie na kolejny sprint, spotkania daily trwają ok 30 ale zespół aktualnie jest mikro, jak był większy to trwały godzinę a potem i tak były kolejne spotkania, zadania w jirze są chujowo opisane więc i tak trzeba się spotkać z autorem a te ciągle spotkania wydają ciągła presję na wynik co powoduje że "a lepiej to zostawię bo znowu będę siedział 2 dni dłużej"

Wcześniej były co tygodniowe spotkania i był luz zadanie skonczone, jak był czas to się poprawiało pewne rzeczy a jak nie to pisalo się "szybciej", teraz czujesz sie ciągle pod presją żeby zadano skończyć więc jest na odpierdol, osoba sprawdzająca oczywiście ma uwagi ale też wszystkiego nie zauważy więc odpierdol się kumuluje XD

@sierzant_armii_12_malp "nikt", "wszyscy". Grratuluję, że byłeś na wszystkich projektach we wszystkich firmach, przeczytałeś wszystkie tickety we wszystkich językach.

@sebie_juki Wiesz, znam osobiście wielu ludzi, którzy pracowali w SCRUMie. I nikt z nich go nie chwali.

@sierzant_armii_12_malp wielu to nie wszyscy. I znanie wielu z 4 firm to nie to samo co znanie wielu z 80 firm

Ale nawet w tej samej firmie inny zespół może mieć kompletnie inne doświadczenia.

@sebie_juki … ale ze dwudziestu ludzi z doświadczeniami w różnych projektach dla różnych firm to już jest coś.

@pluszowy_zergling Coraz więcej ofert mam na LI, więc chyba się uspokaja.