[maestrozo]

Zacząłem prace jako programista. Nie ma w niej żadnych daily, pmów, sprintów i innych review codów. Gita zresztą też nie ma tylko svn. Źle trafiłem?

#programowanie #pracait

[Zwierzak24]

@maestrozo: Przypomina mi to poprzedni projekt, uciekaj

[zwei]

@maestrozo: hm, ja mam daily 2x w tygodniu, płaską hierarchię, sprinty są luźne bez żadnych planning pokerów czy tego typu #!$%@? rzeczy i jak dla mnie jest to spoko. Brak code review to trochę #!$%@?, szczególnie jak zaczynasz. SVN zamiast gita to nie wiem, co to za problem. Nie każdy musi używać gita w projekcie, ciesz się, że zipów sobie po ftpie nie wysyłacie XD

[czuczer]

@zwei kurde powiem Ci, nie jestem devem tylko PMem, i te wszystkie planning pokery mnie jakoś wykręcają. Dlaczego nie można normalnie przegadać i ustalić ile mniej więcej potrzebujemy czasu tylko takie pierdo-uciekawienia.

[Nullek]

@maestrozo: brzmi jak jakiś januszex z poprzedniej epoki

[Tytanowy_robak]

@maestrozo brak code review to najgorsze co może być, svn jeszcze ujdzie. Generalnie to dla wpisu CV posiedz chwilę i uciekaj żeby biurwy hrowe chętniej brały na rozmowy

[stackhouse]

@maestrozo: Jak to mówią: to zależy.

Jak to mała firma < 50 osób z własnym produktem to powiedziałbym, że jak najbardziej ok. Prace programistyczne to pewnie dostosowanie pod wdrożenie u nowego klienta + utrzymanie.

Jeśli nie, i są to różne zadania od czapy typu tutaj coś w wordpresie, tam z kolei jakiś programik w .NET czy jakieś dziwne integracje czegoś z czymś w pojedynkę to radziłbym uciekać ( ͡° ͜

[Myzreal]

@maestrozo tak

[smiech2]

bez żadnych planning pokerów

@zwei: Zawsze mogło być gorzej. Robiłem kiedyś w zespole w ponad 50% zaimportowanym z rosji.

[Krolik]

brak code review to najgorsze co może być

@Tytanowy_robak: w swoich projektach personalnych open-source nie mam code-review a jakoś żyją i mają się nieźle; twierdzę że jakościowo nawet lepiej niż te firmowe robione z CR.

CR nieźle działa jak masz bardzo różny poziom ludzi w zespole np. 10 praktykantów na jednego seniora.
Natomiast jak masz samych juniorów to CR nie działa, bo juniorzy zwykle patrzą na mało istotne głupoty jak wcięcia,

[Tytanowy_robak]

@Krolik jak zwykle to zależy, jeśli ktoś jest początkujący to mimo wszystko cr się przydaje, nie każdy od początku jest jakościowym bogiem i fajnie wiedzieć co się spier***lo, w innym przypadku zgadzam się z Tobą.

[WhiskyRomeo]

@maestrozo: ogarnij wszystko co brakuje, pogrzeb w najbardziej krytycznym miejscu kodu abyś tylko Ty to rozumiał - prosta droga do bycia seniorem. Następnie naturalnie się zwolnij.

[LazyInitializationException]

@czuczer:

tylko takie pierdo-uciekawienia

Bo takie pierdo-uciekawienia pokazują jaka jest wiedza na temat danego USa w zespole. Jak pojawiają się skrajnie różne estymaty to coś jest nie tak. Jak po prostu to przegadujesz to nie ma efektu zaskoczenia, osoby mniej się w to angażują i zazwyczaj sugerują się cudzą opinią

[T.....d]

Natomiast jak masz samych juniorów to CR nie działa, bo juniorzy zwykle patrzą na mało istotne głupoty jak wcięcia, a nie widzą błędów. A jak masz samych seniorów to CR też nie działa, bo się kłócą o to jak robić te wcięcia. :D

@Krolik: jebla idzie dostać ( ͡° ͜ʖ ͡°)

[czuczer]

@LazyInitializationException ale mi chodzi o "przeglądanie" na poziomie mh lub md intu też jeden może powiedzieć 2h a drugi 22h i też możesz to wyłapać :) nie trzeba robić (oczywiście można jak zespół lubi) w udziwniony sposób..wiesz to taka moja refleksja jak przechodzę od kilku lat różne etapy i podejścia. I mam wrażenie że wiele różnic między waterfall a agile jest robionych na siłę żeby było bardziej "ciekawie" :) ale może się

[LazyInitializationException]

też jeden może powiedzieć 2h a drugi 22h

@czuczer: No nie powie, bo usłyszy co mówiła osoba przed nim i ulegnie jej sugestii

[barman84]

@LazyInitializationException: planning zespołowy to najgorsze gówno. Najgłupiej przepalone godziny, po to aby wycenić prace, którą będzie wykonywał ktoś inny - kto ma zupełnie inną wiedzę, inne doświadczenie, inne predyspozycje.
Efektywny planning - wbrew scrumowym fundamentalistom, planuje pracę konkretnych osób (ew. pracy w parach). Dzięki czemu każdy wie co ma robić i układa sobie zadania w przemyślany sposób (np. podobne taski, albo wynikające jeden z drugiego).

[MQs]

@maestrozo: Teoretycznie mogłeś trafić na jakiś konkretny agile o którym niejeden polski wyrobnik mógłby pomarzyć, ale wtedy byś o tym wiedział i ten wpis byłby zarzutką. Jeśli więc pytasz poważnie to pewnie powinieneś się rozglądać za czymś lepszym.

[LazyInitializationException]

Najgłupiej przepalone godziny, po to aby wycenić prace, którą będzie wykonywał ktoś inny - kto ma zupełnie inną wiedzę, inne doświadczenie, inne predyspozycje.

@barman84: Planning przeprowadza zespół i zadania robi zespół. Co masz na myśli, że będzie pracę wykonywał ktoś inny?

Efektywny planning - wbrew scrumowym fundamentalistom, planuje pracę konkretnych osób

Czyli jak ktoś pójdzie na L4 to praca nie będzie zrobiona bo reszta osób w zespole nie wie o co

[barman84]

Planning przeprowadza zespół i zadania robi zespół. Co masz na myśli, że będzie pracę wykonywał ktoś inny

@LazyInitializationException: jeśli masz 7 osób w zespole (zgodnie ze scrumem), to w ponad 80% planujesz pracę komuś innemu.
Zespół nie jest monolitem. To grupa ludzi o różnych cechach, wiedzy i doświadczeniu.

Co do L4 - dlatego mówię o ew. parach (i tak jest CR).

[LazyInitializationException]

@barman84: Jeżeli planujesz pracę komuś innemu to nie jest to scrum

[bzyku95]

@maestrozo: @Krolik:
błędy powinny być sprawdzone przez testy, albo testerów
wcięcia itp to powinien być zasetupowany jakiś dobry linter w pipeline / w githooku

ja code review traktuje jako nauka o różnych miejscach w kodzie, w których nie pracuje + zauważanie jakichś patternów, których ktoś gdzieś użył, zamiast powielania kodu + jakieś domenowe niespójności, które można poprawić
No i najważniejsze, nazewnictwo zmiennych ( ͡° ͜ʖ ͡°)

[Krolik]

@bzyku95: nie da się wszystkich błędów złapać testami. Nie da się przetestowac wszelkich możliwych wejsc. Nie da się testami udowodnić poprawności synchronizacji wątków. Nie da się wykryć błędów projektowych. No i wreszcie same testy też mogą być błędne, jeśli pisał je ten sam programista co pisał kod. Czyli testy też trzeba sprawdzić na CR.

Co do całej reszty się zgadzam. CR to znacznie więcej niż tylko wyszukiwanie błędów.

[WyrobCzekoladopodobny]

@maestrozo: Jest w pytę ( ͡° ͜ʖ ͡°) nie marnujesz czasu na bullshit