Czy często wam się nie dowozić zadania w trakcie sprintu ? Co wtedy mówić na daily ?

Czy często wam się nie dowozić zadania w trakcie sprintu ? Co wtedy mówić na daily ?

Sam mam obecnie taka sytuację, że zajmowałem się dwoma zadaniami na backendzie, których nie dowiozłem w aktualnym 2 tyg sprincie. Mam wrażenie, że nie były na tyle skomplikowane aby tyle czasu na nie poświęcić, ale wyszło jak wyszło. Spowodowane to było tym, że dłuższy czas zastanawiałem się jak działa logika w jednym miejscu, bo kod wyglądał jak spaghetti. Do tego mówiłem, że wystawie te oba taski do review już kilka dni temu, co jeszcze się nie stało. Teraz uważam, że to był błąd żeby to mówić. Do tego mam w zespole drugiego backendowca z mojej firmy i on np. mam wrażenie, że robi znacznie więcej i szybciej tasków niż ja przez co czuje presję. Ostatnio zacząłem nieco dłużej pracować żeby szybciej pokończyć swoje zadania.

Jak postępować w takiej sytuacji ? Co mówić na daily ? Po prostu, że nadal te zadania są w trakcie realizacji ? Jak efektywnie się tłumaczyć ?

Jak na czymś utkniesz to wołaj o pomoc, od tego masz team leadów i innych takich, acha i

Ostatnio zacząłem nieco dłużej pracować żeby szybciej pokończyć swoje zadania

Nie idź tą drogą.

zwróć uwagę na to jak się komunikujesz i jak współdziałasz z innymi.

mielony711 napisał(a):

Spowodowane to było tym, że dłuższy czas zastanawiałem się jak działa logika w jednym miejscu, bo kod wyglądał jak spaghetti.

Tutaj jest pole do tego, żeby przegadać to z kimś, zrobić pair programming itp. Czyli więcej komunikacji.

Do tego mówiłem, że wystawie te oba taski do review już kilka dni temu, co jeszcze się nie stało.

A tutaj coś nawaliło w procesie. Trzymanie kodu u siebie, bo jeszcze nie gotowe, jest słabym podejściem. Jak jest duże zadanie, to można podzielić je na kilka mniejszych (albo jeden formalnie task merdżować partiami), ew. dawać do review nawet WIP, żeby zebrać feedback.

Wstrzymywanie się z integracją to jak wstrzymywanie się przed pójściem do łazienki.

Jak postępować w takiej sytuacji ? Co mówić na daily ? Po prostu, że nadal te zadania są w trakcie realizacji ? Jak efektywnie się tłumaczyć ?

Daily przestaje pełnić swoją rolę, jeśli ludzie zamiast komunikować problemy, to szukają wymówek i sposobu, żeby je ukryć.

Pierwsza sprawa to dlaczego miałeś dwa zadania na sobie, skoro żadnego z nich nie skończyłeś? Tutaj widzę pierwszy poważny problem. Nigdy nie biorę na siebie kolejnego zadania devowego jeżeli poprzednie nadal robię. Chyba, że w trakcie wyjdzie, że w sumie dotyczą prawie tego samego i można je traktować jako jedno.

Kolejna sprawa to tak jak już pisali poprzednicy - komunikacja. Pytasz jak to robię, więc odpowiem, że robię tak, że jeżeli widzę, że wyszło coś niespodziewanego, albo po prostu jestem za głupi i idzie mi wolniej niż wynika z estymat to po prostu na pierwszym daily, po tym jak zauważę problem z czasem, od razu to mówię. Wtedy zawsze jako zespół reagujemy i staramy się rozwiązać problem. Albo dorzucamy drugą osobę do zadania, albo zamieniamy się zadaniami (bo np. ktoś ma dany temat lepiej ogarnięty i można taką akcję zrobić) albo po prostu omawiamy tego samego dnia temat, żeby znaleźć rozwiązanie.

No i jeżeli miałeś 2 tygodnie na 2 zadania, których w dodatku nie zdążyłeś zrobić, to coś mi mówi, że te zadania były za duże.

EDIT: Jeśli zadanie jest ważne i faktycznie muszę je koniecznie skończyć w danym tygodniu/sprincie, a nie wyrobiłem się, to jestem w stanie nad tym siedzieć dodatkowe godziny, ale tylko po uzgodnieniu z zespołem i jasnym wskazaniu, że będę to robił na nadgodzinach (płatnych oczywiście). Bo ogólnie źle widziane są u nas nadgodziny, a robienie ich "po kryjomu" praktycznie zawsze oznacza rozmowę z managerem, żeby wyprostować to.

Oczywiście. I jest to zupełne normalne - Niedoszacowanie w estymacji (Pewne rzeczy nie były wtedy wiadome), zależności trzecie na które nie masz wpływu itp itd. Przykłady można mnożyć.

Sprint to nie deadline, przynajmniej w normalnych firmach. Oczywiście jak notorycznie niedowozisz no to wtedy też nie fajnie.

Co mówić na daily? Prawdę, że niedoszacowałeś i nie dowieziesz. Na przyszłość komunikuj szybciej i najważniejsze... Nigdy nie mów w tonie twierdzącym, że coś będzie zrobione. Zacznij używać powinno, może, najprawdopodobniej. Wtedy zmienia to całkowicie wydźwięk i pozostawia pewien bufor bezpieczeństwa w przypadku błędów.

Tylko komunikacja. Nie rób po cichu nadgodzin. Może po prostu sprint został zaplanowany. Jeśli wchodzi do sprintu za dużo rzeczy i od razu masz tego świadomość podczas planningu, to też trzeba o tym mówić głośno. Jeśli to nie zespół jak całość ma wpływ na to co wchodzi do sprintu, to albo:

• podniesienie tematu i zmiana tego podejścia
• zmiana swojego podejścia i nieprzejmowanie się tym, że sprint nie został dowieziony (co oczywiście może być trudne w zależności od Twojego charakteru)
• zmiana pracy

Zgodnie z ideą Agile, nie powinno się nic stać. Bo zgodnie z duchem, sprint nie powinien być po to "żeby się w niego zmieścić", tylko to powinno być narzędzie do mierzenia szybkości. Robisz sprint, sprawdzasz ile punktów udało się zrobić zespołowi - i teraz wiesz czego się możesz spodziewać w następnym. Zrób kilka sprintow, wyciągnij średnią punktów - masz prędkośc zespołu której możesz użyć do planowania.

Wszelkie "róbmy szybko bo koniec sprintu" są trochę bezzasadne, bo niwelują sens mierzenia szybkości.

mielony711 napisał(a):

Sam mam obecnie taka sytuację, że zajmowałem się dwoma zadaniami na backendzie, których nie dowiozłem w aktualnym 2 tyg sprincie. Mam wrażenie, że nie były na tyle skomplikowane aby tyle czasu na nie poświęcić, ale wyszło jak wyszło. Spowodowane to było tym, że dłuższy czas zastanawiałem się jak działa logika w jednym miejscu, bo kod wyglądał jak spaghetti. Do tego mówiłem, że wystawie te oba taski do review już kilka dni temu, co jeszcze się nie stało. Teraz uważam, że to był błąd żeby to mówić. Do tego mam w zespole drugiego backendowca z mojej firmy i on np. mam wrażenie, że robi znacznie więcej i szybciej tasków niż ja przez co czuje presję. Ostatnio zacząłem nieco dłużej pracować żeby szybciej pokończyć swoje zadania.

Jak postępować w takiej sytuacji ? Co mówić na daily ? Po prostu, że nadal te zadania są w trakcie realizacji ? Jak efektywnie się tłumaczyć ?

Nie tłumaczyć się, i nie jojczyć, moim zdaniem.

To co piszesz, jasno pokazuje że skoro robiłeś jedno zadanie dwa tygodnie (i do tego go nie skończyłeś), to to jest bardzo jasny sygnał że ono było za duże. W momencie kiedy ustalacie jakie zadanie kto robi - powiedz że chciałbyś dużo mniejsze zadanie - albo jeśli nie ma - to poproś żeby podzielić istniejące zadania na mniejsze.

Ja jak zadeklarowałem się w Sprincie że coś dowiozę a widzę że jednak dłużej to będzie trwało to robię nadgodziny darmowe by się wyrobić - taki grind. Wiąże się to z tym, że pracuje w Sprintach gdzie nie jest mile widziane przenoszenie jednego zadania na kolejny Sprint (PO, managerzy tego nie lubią) ponieważ na kolejny Sprint jest już napchane kolejnej pracy pod kurek. Kiedyś też nie dowiozłem i manager powiedział na Retro publicznie że nie spełniam „Sprint Commitment”.

Stąd teraz jak pomylę się z estymatą a widzę ze nie dokończę to robię za darmo nadgodziny wieczorami na zdalnej. Ogólnie staram się wyceniać z zapasem ale nie zawsze się to udaje. Piszę całkiem serio.

heading

Rexioo napisał(a):

Ja jak zadeklarowałem się w Sprincie że coś dowiozę a widzę że jednak dłużej to będzie trwało to robię nadgodziny darmowe by się wyrobić - taki grind.

No to nie rób tak.

Wiąże się to z tym, że pracuje w Sprintach gdzie nie jest miłe widziane przenoszenie jednego zadania na kolejny Sprint (PO, managerzy tego nie lubią) ponieważ na kolejny Sprint jest już napchane kolejnej pracy pod kurek. Kiedyś też nie odwiozłem i manager powiedział na Retro publicznie że nie spełniam „Sprint Commitment”.

To jest absurd. Sprinty nie są po to (a przynajmniej nie powinny być), żeby coś obiecać i żeby było na wtedy. Poza tym, tak na prawdę to co się tam dzieje, to jak rozumiem "góra" wymaga od Ciebie perfekcyjnej wiedzy nt tego ile jakieś zadanie zajmie. A to jest raczej, no średnie podejście.

sprawdź czy KPI/OKRy masz mniej więcej na poziomie zespołu i swoich stawek, czyli mniej więcej tyle samo story pointów robisz co inni w zespole, jak nie wyrabiasz normy to trochę podkładasz głowę pod topór zwłaszcza w obecnej sytuacji na rynku. Jak mimo obsuwy nadal masz dobre statystyki to nic się stać nie powinno. Co do samego powiedzenia to najlepiej powiedzieć że się przedłuży i nadgonisz wieczorami w weekend by nie psuć roadmapy kolejnych sprintów

Takie życie, witamy w pracy programisty. Dlatego dla zdrowia zawsze wybiera się firmy, które dojrzały do nie estymowania tasków.

No a jak już się mleko rozlało to mówisz jak jest i tyle. To, że powiesz, że kod ciężko się analizuje i przez to zajmuje to więcej czasu to jest jak najbardziej uzasadnione. Dlatego jak już masz estymowac to zawsze 2x to co Ci się wydaje.

Jak widze ze sie z czyms nie wyrobie to biore na klate i siedze po godzinach bo jednak człowiek bierze pieniądze za to wszystko i jak sie zadeklarował to wypadałoby skończyć. Powyższe komentarze, ze spoko jest nie kończyc, ze nic sie nie dzieje - ciekawe co mysla management i biznes na takie podejście ze robota jest nie zrobiona.

Do sprintu bierz zawsze task normalny i jakąś popierdołę typu bugfix czy coś co leży od wieków zapomniane. Wtedy na daily zaczynasz że pracujesz intensywnie nad taskiem nr 1 a po zakończeniu tłumaczysz że wyszły nieprzewidziane problemy no i nieudało ale... za to zrobiłeś task nr 2 i jeszcze napisałeś do niego testy!

Każdy normalny (i zorganizowany) zespół zawsze ma tonę takiego gruzu co by zasypywać braki w fundamentach.

Rexioo napisał(a):

Ja jak zadeklarowałem się w Sprincie że coś dowiozę a widzę że jednak dłużej to będzie trwało to robię nadgodziny darmowe by się wyrobić - taki grind. Wiąże się to z tym, że pracuje w Sprintach gdzie nie jest mile widziane przenoszenie jednego zadania na kolejny Sprint (PO, managerzy tego nie lubią) ponieważ na kolejny Sprint jest już napchane kolejnej pracy pod kurek. Kiedyś też nie dowiozłem i manager powiedział na Retro publicznie że nie spełniam „Sprint Commitment”.

Stąd teraz jak pomylę się z estymatą a widzę ze nie dokończę to robię za darmo nadgodziny wieczorami na zdalnej. Ogólnie staram się wyceniać z zapasem ale nie zawsze się to udaje. Piszę całkiem serio.

zaczynam oficjalnie omówić, że darmowe nadgodziny są żałosne i w ogóle #przegryw. No offense ale ludzie ile tych pokoleń musi jeszcze się przetoczyć przez ten glob by pozbyć się mentalności chłopa pańszczyźnianego? jak bardzo trzeba nie mieć do siebie szacunku?

żeby ten post nie był bezwartościowy dla osób któe mimo wszystko dalej będą robić darmowe nadgodziny:
nie raz zdarzyło mi się nie zrobnić zadania w sprincie, ba nawet zdarzyło się, że task się ciągnął przez kilka bo estymata byłą błędna, refinement zadania okazał się błędny i roboty było dużo więcej. Nie ma mw tym problemu tak samo jak z poproszeniem o pomoc czy poradę.

Generalnie to czy jesteś słowny to kwestia kultury. Jak obiecujesz i nie dotrzymujesz obietnic no cóż tzn, że twoja kultura osobista jest na niskim poziomie.
Natomiast co do reszty to mówienie nie/nie wiem też jest umiejętnością której w życiu dorosłym warto się nauczyć.

Mówię na daily: wystąpiły nieprzewidywalne skutki zgłaszanych potrzeb refaktoryzacji kodu, przez co implementacja zajmie więcej czasu lub okroimy funkcjonalność w taki a taki sposób.