Podkręcanie tempa w zespole przez nowego pracownika

Hej :) W zespole w którym pracuję mamy dość spoko atmosferę, w sensie "fajnie się robi". Estymujemy taski z zapasem, robimy sobie na spokojnie, mamy dość zgrany zespół. Tak się wszyscy zgadaliśmy że manager jest zadowolony, klient też itd, a w dodatku w czasie pracy mam czas na samorozwój, nie muszę się dokształcać po pracy.

Taski estymujemy w ten sposób że się wyrabiamy w 3-4h, by mieć spokojnie czas na obiad, review i tak dalej, by nie robić sobie nawzajem presji. Niestety do naszego zespołu dołączyły dwie nowe osoby i zaczęły robić dość agresywne estymaty, czytaj niższe Story Pointy. Nie jestem osobą która chce się wykłócać z takimi osobnikami, ale ona taką jest. Na głos mówi managerowi że to tyle i tyle zajmie i ogólnie no jest bardzo nadgorliwa. Mówię, że chcę dać Story Pointów 5, a gość się wykłóca że zajmie 3 itd.... W końcu mu ustępuję.

Suma summarum stosując te niższe, "zbite" estymaty dowozimy tyle samo, ale spadło nam "Velocity". No i zgadnijcie co? Manager dowalił nam więcej roboty aby wyrównać "Velocity" do tego co było poprzednio xD

Jak ogólnie unikać takich sytuacji w życiu? Naprawdę fajnie mi się robiło, ale przez dwóch nadgorliców zacząłem lekko czuć presję i mieć 20-30% więcej roboty. Po prostu nie chce mi się mówiąc kolokwialnie robić w takim tempie. Tym bardziej że rok tak pracowałem wcześniej i było okej.

Macie jakiś sposób na takich "nadgorliwców", jak rozwiązać takie sytuacje?

Rób w swoim tempie, pamietaj że nie warto poświęcać się za bardzo dla pracy, jedynie co możesz zyskać to 100 zł powyżki

MarioBros33 napisał(a):

Mówię, że chcę dać Story Pointów 5, a gość się wykłóca że zajmie 3 itd.... W końcu mu ustępuję.

a nie możecie chociaż wyciągnąć średniej?

Taski estymujemy w ten sposób że się wyrabiamy w 3-4h, by mieć spokojnie czas na obiad, review i tak dalej, by nie robić sobie nawzajem presji. Niestety do naszego zespołu dołączyły dwie nowe osoby i zaczęły robić dość agresywne estymaty, czytaj niższe Story Pointy.

no to dorzuć dodatkowe story pointy na code review :)

A może to człowiek góry, który ma sprawdzić czemu tak wolno robota idzie i zrobić porządki?

Zapytaj się gościa jak jego estymaty mają się do innych estymat na 5 lub 3 story pointy.

Jeżeli dalej jest taki do przodu to powiedz, że znaleźliśmy wolontariusza do tych zadań. A pod koniec sprintu na retro po prostu zapytaj czy te estymaty były poprawne.

Też miałem takich gości, często byli to juniorzy, którzy nie rozumieli czym jest story point.

Zróbcie scrum pokera i głosujcie, jeden głos znaczy mniej niż 5 :)

Oggy2 napisał(a):

Zróbcie scrum pokera i głosujcie, jeden głos znaczy mniej niż 5 :)

Mamy Scrum Pokera. Problem polega na dwaniu niskich estymat i wykłócaniu się że coś można robić szybciej. A ja 5 lat już i po prostu mam dość kłótni i jakiś takich dziwnych akcji

MarioBros33 napisał(a):

Oggy2 napisał(a):

Zróbcie scrum pokera i głosujcie, jeden głos znaczy mniej niż 5 :)

Mamy Scrum Pokera. Problem polega na dwaniu niskich estymat i wykłócaniu się że coś można robić szybciej. A ja 5 lat już i po prostu mam dość kłótni i jakiś takich dziwnych akcji

No to przecież macie chyba TL który prowadzi planning ? Ja takie wykłócania ucinam a jak ktoś za bardzo fika to manager ma się typa pozbyć albo utemperować. Jako dev masz chyba f2f z managerem to możesz powiedzieć co o tym myślisz że psuje wam to pracę.

Skoro mieliście 4h na m.in code review itp itd - to zrezygnujcie z tego :) brak CR szybko przywróci wam wyższe estymaty :)

Wyceniacie w story pointach, a w nie w roboczogodzinach/idealnych roboczogodzinach, a w story pointach wycenia się tak, że ma się przygotowaną listę wzorcowych, ukończonych zadań na 1, 3, 5 (do każdego story pointa po 2-3 przykładowe zadania) i jak jest wycena to patrzycie czy to nowe zadanie czasochłonnością bardziej przypomina to na 3 story pointy czy to na 5 story pointów/czy jest od nich większe czy mniejsze. Z czasem zespół pamięta tę listę, wszyscy mają podobne wyobrażenie o 1, 3, 5 itd. storypointach i lista rzadko jest wyciągana.

Zgłoś na spotkaniu podsumowującym sprint, że w ostatnim sprincie bywały różnice zdań co do wycen i proponujesz zrobienie takiej wzorcowej listy z wyceną. Zapamiętaj sobie teorię dot. story pointów ze Scrum Guide i jak się nowi w odpowiedzi będą rzucać to im wyrecytuj czym są story pointy i że to nie to samo co roboczogodziny. By zbić ewentualne obiekcje menadżera zanim one wybrzmią:

• powiedz, że takie rozwiązanie zaoszczędzi Wam czasu na wyceny i konfliktów w zespole
• zgłoś się na ochotnika, który przygotuje taką listę
• powiedz, że to zrobienie takiej listy to chwila (pewnie z godzinę-dwie by dobrze dobrać zadania :P)

Osobiście wolę roboczogodziny, ale jeśli macie story pointy to myślę, że to co opisałem to dobre rozwiązanie problemu.

MarioBros33 napisał(a):

Suma summarum stosując te niższe, "zbite" estymaty dowozimy tyle samo, ale spadło nam "Velocity". No i zgadnijcie co? Manager dowalił nam więcej roboty aby wyrównać "Velocity" do tego co było poprzednio xD

Jak ogólnie unikać takich sytuacji w życiu?

Macie niedouczonego manago/chrum mastera. Każda zmiana składu zespołu powoduje, ze velocity idzie do kosza i trzeba kilku sprintów, zeby wypracować nową. Podstawy podstaw scruma.

dziękuje bardzo wszystkim za odpowiedzi poruszę ten temat na retro

MarioBros33 napisał(a):

Suma summarum stosując te niższe, "zbite" estymaty dowozimy tyle samo, ale spadło nam "Velocity".

No to po prostu weź tych dwóch nowych na bok i im powiedz dokładnie to samo - że dowozicie tyle samo a gorzej to wygląda na papierze i zaniżanie estymat działa na niekorzyść zespołu bo manago widzą niższe velocity.

U mnie na odwrót, dołączyłem do zespołu gdzie zadania wyceniane są za nisko a później zespół się tłumaczy z błędów przy estymacjach.
Większość z tych błędów to po prostu lakoniczne podejście do potencjalnych problemów, które stawia przed nami wykonanie czegoś.

A wyrabiacie się z backologiem w ciągu tych 2 tyg? Bo jeśli "kończycie" sprint po tygodniu, albo przenosicie regularnie taski na kolejne sprinty to planowanie nie jest optymalne. Jaką rangę mają te osoby? Seniorzy? Z reguły osoby z mniejszym stażem są nadgorliwe i dają mniej SP w taskach.

Można też tak, na pokerze, wyliczyć średnią z głosów i dać tę liczbę Fibonacciego, która jest najbliżej (tej średniej).

Pamietam jak u mnie byly storypointy jakies, jkaies kolorowe kartki z punktami i gadali tak dlugo az wszyscy nie rzucili tego samego punktu czy tam wagi. ja rzucalem to co chceili bo mialem wywalone i robilem swoje. Powoli i tyle, doszktalcalem sie ogladajac kursy w pracy i normlanie mowielm ze sie ucze. Na testy naukowe zrobilem swoj projekt jakis tam, okazalo sie ze jak go wypuscilem live to sie sprawdzil. i byly zainteresowane firmy zeby go odkupic za ilestam kasy. ALe na tyle duzo ze jak sie dowiedzieli u mnie w pracy to dostalem pozew do sadu ze kod ktory napisalem w pracy nalezy sie pracodawcy i kasa ze sprzedazy tego projektu rowniez, plus koszty poniesienia strat za to ze nie pracowalem dla nich itd itd.

xDDDDD takze ogolnie polecam uwazac z robieniem kodu dla siebie w miejscu pracy bo moze byc slaboooo. Uratowalo mnie to ze kod pisalem na swoim wynajetym serwerze typu godady, ovh ionos taki vps :) spec oszacowal ile czasu godzin zajmuje napisanie takiego kodu i musialem oddac kase za te godziny pracodawcy, tak jakbym nie pracowal poniewaz kod byl u mnie a nie u nich na kompie wiec nalezal do mnie. a ze dostalem za projekt sporo kasy to bez problemu zaplacilem.

Nie, nie wywalili minie z pracy, zostalem PO ale teraz nie robie juz tutaj nic swojego hahahah

@Czitels: Czyli ktoś się sprzedał po prostu. A z ciekawości, jaki typ umowy?

mialem umowe smieciowa czyli umowa o prace. Nie myslalem w kontekscie ze ktos mnie sprzedal tylko na zasadzie ze pokazywalem ze nauczylem sie tego, ze zrobilem to tutaj i pokazywalem w tym moim programie jak to wykorzystuje, ze moze zaimplementujemy to w firmie itd. to bylo takie hmm portfolio moze wewnetrzne? i kazdy to wiedzial ( bo ja najlepiej ucze sie jak mam jakis porjekt, cel do zrealizowania) i jak potem puscilem lajv i sie podobalo to tez mowilem ze, troche ludzi to lubi, ze sie podoba pomysl ze to ze tamto i ten proces trwal. a potem jak wyszla grubsza sprawa i weszla troche konkretneijsza kasa to nagle sie obudzili ze to im sie nalezy itd.

Z lotu ptaka jak tak atrze to sam sobie jestem winien bo sam sie wygadalem pewnie chcialem zeby mnie podziwiali w jakims stopniu.

push bak or get faked. Albo na review wyrwać chwasta. Wciecia nie te, zmienne nazwy jakies takie sobie, moze ta klasa w innym pakiecie?
JK za kazdym razem jak slysze o tych ceremoniach skramowym to dziekuje bogu i chatgpt, ze nie mam tego u siebie

Wasz problem to nie kolega, to SCRUM. Jak zwykle przeszkadza w robocie.

Dlaczego tylko kierownicy mają wyciągać debilne wniosku ze scruma? Pracownicy też mogą, np. tak:
Panie januszualfeczku, wcisnąłeś do zespołu jakichś dwóch kolesi i velocity nam spadło. Matematykę pozostawiam tobie.

MarioBros33 napisał(a):

Mówię, że chcę dać Story Pointów 5, a gość się wykłóca że zajmie 3 itd.... W końcu mu ustępuję.

No można dać nawet 0, co to zmienia?
Spal na tego taska 5SP, i wyjdzie Twoja racja.

MarioBros33 napisał(a):

Suma summarum stosując te niższe, "zbite" estymaty dowozimy tyle samo, ale spadło nam "Velocity". No i zgadnijcie co? Manager dowalił nam więcej roboty aby wyrównać "Velocity" do tego co było poprzednio xD

Macie jakiś sposób na takich "nadgorliwców", jak rozwiązać takie sytuacje?

Abstrchuję już od tego czy pracowaliście 4 godziny czy 8. Jeśli robiliście x, estymaty spadły o y%, a macie "dowieźć" tyle samo punktów to macie teraz dwie opcje:
a) Robić więcej żeby spalone punkty się zgadzały i udowodnić, że gość miał racje.
b) Robić tyle co zawsze i udowodnić, że jego estymacje są niepoprawne -> powrót do starych estymat.
Upewniacie się na review, że jego nazwy zmiennych i organizacja kodu spełnia standardy?
Na planowaniu na pewno rozmawiacie o punktach, a nie godzinach ile coś powinno zająć?

MarioBros33 napisał(a):

Hej :) W zespole w którym pracuję mamy dość spoko atmosferę, w sensie "fajnie się robi". Estymujemy taski z zapasem, robimy sobie na spokojnie, mamy dość zgrany zespół. Tak się wszyscy zgadaliśmy że manager jest zadowolony, klient też itd, a w dodatku w czasie pracy mam czas na samorozwój, nie muszę się dokształcać po pracy.

Taski estymujemy w ten sposób że się wyrabiamy w 3-4h, by mieć spokojnie czas na obiad, review i tak dalej, by nie robić sobie nawzajem presji. Niestety do naszego zespołu dołączyły dwie nowe osoby i zaczęły robić dość agresywne estymaty, czytaj niższe Story Pointy. Nie jestem osobą która chce się wykłócać z takimi osobnikami, ale ona taką jest. Na głos mówi managerowi że to tyle i tyle zajmie i ogólnie no jest bardzo nadgorliwa. Mówię, że chcę dać Story Pointów 5, a gość się wykłóca że zajmie 3 itd.... W końcu mu ustępuję.

Suma summarum stosując te niższe, "zbite" estymaty dowozimy tyle samo, ale spadło nam "Velocity". No i zgadnijcie co? Manager dowalił nam więcej roboty aby wyrównać "Velocity" do tego co było poprzednio xD

Jak ogólnie unikać takich sytuacji w życiu? Naprawdę fajnie mi się robiło, ale przez dwóch nadgorliców zacząłem lekko czuć presję i mieć 20-30% więcej roboty. Po prostu nie chce mi się mówiąc kolokwialnie robić w takim tempie. Tym bardziej że rok tak pracowałem wcześniej i było okej.

Macie jakiś sposób na takich "nadgorliwców", jak rozwiązać takie sytuacje?

To nie ustępuj :) i jak trafi na ciebie task to rób na 5SP i potem na retro powiedz "A nie mówiłem :)"

Uśpiony wiosenny but napisał(a):

MarioBros33 napisał(a):

Hej :) W zespole w którym pracuję mamy dość spoko atmosferę, w sensie "fajnie się robi". Estymujemy taski z zapasem, robimy sobie na spokojnie, mamy dość zgrany zespół. Tak się wszyscy zgadaliśmy że manager jest zadowolony, klient też itd, a w dodatku w czasie pracy mam czas na samorozwój, nie muszę się dokształcać po pracy.

Taski estymujemy w ten sposób że się wyrabiamy w 3-4h, by mieć spokojnie czas na obiad, review i tak dalej, by nie robić sobie nawzajem presji. Niestety do naszego zespołu dołączyły dwie nowe osoby i zaczęły robić dość agresywne estymaty, czytaj niższe Story Pointy. Nie jestem osobą która chce się wykłócać z takimi osobnikami, ale ona taką jest. Na głos mówi managerowi że to tyle i tyle zajmie i ogólnie no jest bardzo nadgorliwa. Mówię, że chcę dać Story Pointów 5, a gość się wykłóca że zajmie 3 itd.... W końcu mu ustępuję.

Suma summarum stosując te niższe, "zbite" estymaty dowozimy tyle samo, ale spadło nam "Velocity". No i zgadnijcie co? Manager dowalił nam więcej roboty aby wyrównać "Velocity" do tego co było poprzednio xD

Jak ogólnie unikać takich sytuacji w życiu? Naprawdę fajnie mi się robiło, ale przez dwóch nadgorliców zacząłem lekko czuć presję i mieć 20-30% więcej roboty. Po prostu nie chce mi się mówiąc kolokwialnie robić w takim tempie. Tym bardziej że rok tak pracowałem wcześniej i było okej.

Macie jakiś sposób na takich "nadgorliwców", jak rozwiązać takie sytuacje?

To nie ustępuj :) i jak trafi na ciebie task to rób na 5SP i potem na retro powiedz "A nie mówiłem :)"

To będzie stosowany mobbing wobec niego, że nie zrobił na czas i sam jest zbyt wolnym programistą podając przykład kolegi, który przecież mówiłby, że zrobi to w 3SP.

A skoro OP pracuje w firmie gdzie jest ta patologia estymowania taskow to raczej nie jest mu łatwo zmienić pracę.

Lukxxx napisał(a):

Wasz problem to nie kolega, to SCRUM. Jak zwykle przeszkadza w robocie.

Gorzej, tak jak SCRUM jest zbiorem paru przypadkowych praktyk, to tutaj jeszcze je zrypano.

Teoria Story Pointa w pigułce:
Zamiast Story Pointów, można by liczyć historyjki na sztuki i policzyć sobie średnią liczbę historyjek zrobionych w poprzednich okresach.
Ponieważ historyjka historyjce nierówna, to można trochę zwiększyć precyzję tego szacowania wprowadzając SP, który jest takim "ni pies ni wydra, coś na kształ świdra miarą złożoności i pracochłonności zadania".
Nie ma sensu przejmowanie się spadkiem/wzrostem velocity, to to nie jest miara tempa pracy zespołu. Jak ktoś chce mierzyć, czy zespół dobrze pracuje, to powinien mierzyć realną wartość, typu "zdobyliśmy dodatkowe 100 tysięcy użytkowników naszego serwisu", "wzrosła sprzedaż w sklepie internetowym który robimy", "spadł czas niedostępności usług" itp.

Praktyczne rady:
Dzielić historyjki na mniejsze kawałki. Wiele małych historyjek zawsze da więcej SP niż jedna duża.
Kłócić się ze stachanowcami. Co to jest za argument "to proste jest"? Warto mieć parę kontrargumentów i je podawać w takich dyskusjach.
Zwrócić uwagę na korelację pomiędzy spadkiem velocity, a pojawieniem się 2 gości w zespole. To nie może być przypadek przecież.

Czitels napisał(a):

Uśpiony wiosenny but napisał(a):

MarioBros33 napisał(a):

Hej :) W zespole w którym pracuję mamy dość spoko atmosferę, w sensie "fajnie się robi". Estymujemy taski z zapasem, robimy sobie na spokojnie, mamy dość zgrany zespół. Tak się wszyscy zgadaliśmy że manager jest zadowolony, klient też itd, a w dodatku w czasie pracy mam czas na samorozwój, nie muszę się dokształcać po pracy.

Taski estymujemy w ten sposób że się wyrabiamy w 3-4h, by mieć spokojnie czas na obiad, review i tak dalej, by nie robić sobie nawzajem presji. Niestety do naszego zespołu dołączyły dwie nowe osoby i zaczęły robić dość agresywne estymaty, czytaj niższe Story Pointy. Nie jestem osobą która chce się wykłócać z takimi osobnikami, ale ona taką jest. Na głos mówi managerowi że to tyle i tyle zajmie i ogólnie no jest bardzo nadgorliwa. Mówię, że chcę dać Story Pointów 5, a gość się wykłóca że zajmie 3 itd.... W końcu mu ustępuję.

Suma summarum stosując te niższe, "zbite" estymaty dowozimy tyle samo, ale spadło nam "Velocity". No i zgadnijcie co? Manager dowalił nam więcej roboty aby wyrównać "Velocity" do tego co było poprzednio xD

Jak ogólnie unikać takich sytuacji w życiu? Naprawdę fajnie mi się robiło, ale przez dwóch nadgorliców zacząłem lekko czuć presję i mieć 20-30% więcej roboty. Po prostu nie chce mi się mówiąc kolokwialnie robić w takim tempie. Tym bardziej że rok tak pracowałem wcześniej i było okej.

Macie jakiś sposób na takich "nadgorliwców", jak rozwiązać takie sytuacje?

To nie ustępuj :) i jak trafi na ciebie task to rób na 5SP i potem na retro powiedz "A nie mówiłem :)"

To będzie stosowany mobbing wobec niego, że nie zrobił na czas i sam jest zbyt wolnym programistą podając przykład kolegi, który przecież mówiłby, że zrobi to w 3SP.

A skoro OP pracuje w firmie gdzie jest ta patologia estymowania taskow to raczej nie jest mu łatwo zmienić pracę.

@Czitels: to wtedy to nie jest scrum tylko januszerka z pseudo scrumem, równie dobrze możesz mieć wywalone jajca szukać pracy albo mieć 2 etaty i ten traktować jako drugorzędny i czekać, aż ci plan naprawczy albo wypo dadzą. To tak jak mój kolega wylądował w projekcie z 22 letnimi przodownikami pracy z 300% normy, a kolega z żoną, dwójką dzieci. To wiadomo, że najsłabiej wypadał, bo nie robił po godzinach ukrytych 4-5h ekstra i najmniej roboty robił, nie było tego widać, bo młodzi nie logowali tego ale już commity były dziwne o 22:00 o 01:00 :) oczywiście broniąc się przez atak, użył tego jako argumentu na co został zkwitowany przez młodego, że są flexible hours, i jego 8h może być 4h rano a potem wieczorkiem 4h kolejne :)

Czitels napisał(a):

To będzie stosowany mobbing wobec niego, że nie zrobił na czas i sam jest zbyt wolnym programistą podając przykład kolegi, który przecież mówiłby, że zrobi to w 3SP.

No mówił, ale nie zrobił. Następnym razem można przypisywać taski osobie, które ja najniżej wyestymuje. Po dwóch sprintach skończy się rumakowanie.

A skoro OP pracuje w firmie gdzie jest ta patologia estymowania taskow to raczej nie jest mu łatwo zmienić pracę.

Nie wiem co metodyka pracy ma do łatwości jej zmiany, ale estymowanie zadań to nie jest żadna patologia. To jest normalne działanie, które każdy w miarę ogarnięty człowiek robi codziennie, żeby np. wiedzieć, czy wyrobi się do żabki po harnasia przed jej zamknięciem.

Problem pojawia się, gdy ktoś nie odróżnia estymaty od deadline albo przelicza SP na godziny.

Póki mi nie płacą w pracy per ukończony task tylko godzinowo, to nie muszę się ścigać z Sonicami programowania :) kasa ta sama, a po co się wypalać i codziennie mieć zlansowany mózg od programowania 8-12h.

Polecam(tak napawdę nie) poprogramować ale realnie ciężkie taski albo zawiłości biznesowe i dosyć ciężke testy integracyjne, gdzie jeszcze nie jest prosto potestować bo trzeba się nakombinować np. z concurrency awaitality i dobrym stepowaniem po czasie.

Dobrze, że od 4 lat pracuję full remote, bo jakbym takiego typa spotkał w biurze to mógłby gdzies przypadkiem spasc ze schodow lub inne losowe zdarzenie mogloby sie mu przytrafic :D

Moja rada jest taka: jezeli wiekszosci w teamie to przeszkadza i z innymi developerami masz dobre relacje i są po Twojej stronie, to zgadajcie sie razem zeby go ignorowac i trzymac sie Wadzych estymat. Robcie swoje na spokojnie a jak on twierdzi, ze cos da sie zrobic szybciej to niech robi. Potem przy review czepiajcie sie go i na retro mozecie to wytknac ze przez pospiech bylo wiele bledow i wynika to z jego zanizonych estymat.
Moze wtedy jakoś się ogarnie.

Mozna tez powiedziec mu wprost na czacie 1 on 1 lub callu ze nie zamierzacie robic 2x wiecej roboty za te same pieniadze, bo nie o to chodzi w IT zeby byc "utilizowamym 8h" tylko dowozic zadania na czas. Tak wiem wiem zaraz sie odezwą tutaj przegrywy, ze raportujac 8h a pracujac realnie 4 jestes "oszustem"