Czy bierzecie nowe taski do sprintu, jeżeli wszystko już skończyliście?

Jak w tytule. Ostatnio zacząłem się zastanawiać, czy wszędzie tak jest, czy ja po prostu trafiłem na pracoholików. Jeżeli wszystkie tickeciki w danym sprincie są już skończone, to bierzecie i wciągacie do obecnego sprintu, tickeciki z następnego sprintu/backlogu, czy robicie coś innego? Jako coś innego mam na myśli cokolwiek, może być opierniczanie się, nauka, gra na kompie, refactoring, tworzenie nowych ticketów.

U mnie w zespole często zdarza się, że wciągane są nowe tickety do sprintu (i to nawet bez wcześniejszej konsultacji z kimkolwiek), jak już nic nie ma na TO DO. Ogólnie nie jest to czymś dziwnym, ale ostatnio było więcej roboty i presji, w końcu jest nieco luźniejszy sprint, więc ja postanowiłem spędzić w końcu trochę czasu na nauce i innych rzeczach. Wczoraj pisaliśmy o tym z kolegą z zespołu, on też stwierdził, że poświęci więcej czasu na naukę, a dzisiaj już jeden tickecik z następnego sprintu skończony, obecnie ciśnie kolejnego :D Stąd zacząłem się zastanawiać, czy to parcie na jak najwięcej wykonanych tickecików/story pointów to standard, czy ja trafiam na tak ambitnych współpracowników?

Pewnie tzw Project Manager ma duży wpływ na zespół i jego celem jest zrealizowanie jak największej części backlogu w jak najszybszym czasie. Do tego może trafili Ci się ludzie, którzy lubią wyścig szczurów, różnie bywa.
Po 20 latach pracy z różnymi zespołami pokochałem prace w 1 osobowym zespole. Ciśnienie na zapieprz, charakterystyczne dla niektórych młodych deweloperów oraz PM'ów też z wiekiem przechodzi :)

Tak, generalnie mam wyj*** na scruma. Nie stresuje się, że mało dowiozłem i w drugą stronę po prostu jak coś skończę to biorę się za następnego taska

Tak robiliśmy do momentu jak zaczęli się czepiać wykresów, że nie robimy 100% sprintu bo jakiś task jest nie skończony.

Jak zostaje 2-3 dni do końca sprintu i nie ma tasków to dociągamy, jak zostaje 0.5-1.5 dnia to często robimy jakieś poprawki, refaktor, naukę etc.
W żadnej firmie nie pozwoliłem sobie na narzucanie, że:

• musicie dociągać taski
• nie skończyliscie sprintu bo n taksów jest niezamkniętych

Pracowałem w zespołach z "cywilną odpowiedzialnością" gdzie każdy miał prawo się trochę poobijać jak potrzebował ale i też gdy trzeba zasuwał nawet po godzinach. Balans kluczem do sukcesu. A manager nie ma żadnego prawa Ci mówić jak masz żyć. Jeśli mikromanagementuje to odsyłam do scrum mastera/coacha/agile manifesto albo jednoznaczych artykułów dlaczego przekracza swoje uprawnienia. Nigdy nawet nikt nie próbował pisnąć, że bede miał z tego tytułu konsekwencje.

Jak dobrze że obecnie nie mam żadnych sprintów.

korokczan napisał(a):

U mnie w zespole często zdarza się, że wciągane są nowe tickety do sprintu (i to nawet bez wcześniejszej konsultacji z kimkolwiek), jak już nic nie ma na TO DO.

Wg jakiej metodyki? Bo np. w Scrumie każdy sprint powinien mieć swój określony cel, więc wyciąganie randomowych ticketów, bo programista poczuł chęć dostarczania sobie dopaminy, mija się z celem.

Z drugiej strony nie wszędzie, gdzie są sprinty, wyznaje się Scrum. Ale mimo wszystko, dzielenie projektu na iteracje zwane sprintami, tylko po to, żeby potem i tak traktować backloga jako niekończący się strumień tasków realizowanych z dnia na dzień, jak się programiście zachce i jak znajdzie czas... na tym etapie można by równie dobrze przestać to nazywać sprintami

korokczan napisał(a):

Jeżeli wszystkie tickeciki w danym sprincie są już skończone (...)

U mnie w zespole często zdarza się, że (..) już nic nie ma na TO DO.

Jak tak się zdarza częściej to brzmi jak zbyt pesymistyczne estymacje i zbyt mało wrzucone do sprinta (nie to, żebym lubił zapieprz, ale taka logiczna przyczyna mi się nasuwa).

Ew. odwrotnie - jeśli robicie to za szybko (tracąc jakość). Może lepiej robić wolniej, a lepiej?

Albo: może lepiej robić wolniej, ale na spokojnie, może jak się zrobi wszystko w sprincie to po prostu zająć się np. nauką nowych technologii czy czymkolwiek pożytecznym (żeby nie było, że się nie pracuje), ale po co ruszać kolejne taski, skoro wszystkie ze sprinta zostały zrealizowane?

Brałbym, ale niestety z żadnym sprintem się nie wyrobiłem odkąd zwolnił się drugi backendowiec z zespołu :D

Jak się praca skończyła, to znaczy, że można rozwiązać zespół.

Jak skończyły Ci się zadania, to zapytaj TL albo managera, co mógłbyś zrobić extra. Świadczy to o pewnej dojrzałości i świadomości, po co przychodzimy do pracy, za co jesteśmy wynagradzani i awansowani. Coś do refactoringu albo rozkminki zawsze się znajdzie. Nie mówiąc już o jakichś tematach, które sam możesz zaproponować.

Scrum nie powinien być wymówka, że zespół nie może dowieźć większego zakresu, bo się jakieś śmieszne wykresy zle narysują (choć rzeczywiście słyszałem o takim podejściu - dramat).

Kiedyś brałem, potem nabrałem rozumu i godności człowieka i przestałem

Najlepszym rozwiazaniem jest, jak już widzisz że szybciej skończycie sprint, trochę poprzeciągać swoje taski. Wtedy oddajesz taski dzień przed albo w ostatnie dzień sprintu i wszyscy zadowoleni.

dochaty napisał(a):

Najlepszym rozwiazaniem jest, jak już widzisz że szybciej skończycie sprint, trochę poprzeciągać swoje taski. Wtedy oddajesz taski dzień przed albo w ostatnie dzień sprintu i wszyscy zadowoleni.

jak to robisz, że ostatniego dnia taska integrujesz do mastera, przechodzi wszystkie zestawy testów, testy testera na środowisku i finalny odbiór taska? :P

Ja się dziwię czemu u wszystkich są jakieś patoscrumy gdzie niespalony task to problem albo że tester nie ma co robić na początku xD u mnie scrum wygląda tak:

-główny cel planowania sprintów to po prostu wiedzieć ile można dowieźć przez sprint. Można dowieźć =/= na pewno dowieziemy, czasem czegoś nie zrobimy i się nic nie stanie, czasem coś dobierzemy, ogólnie wyciągamy średnią SP za poprzednie sprinty by się orientacyjnie planować.

-osobne taski deweloperskie i testerskie oraz osobne ich szacowanie. Zazwyczaj testy są sprint później by robić development bez spiny. Jakby testy się nagromadziły i by miały być dwa sprinty później (co wiem dzięki wycenom), to rezygnujemy z ficzerów na siłę i robimy jakieś refaktory, podbijamy biblioteki, itp. (co też wyceniamy by wiedzieć ile SP można na spłacanie długu wykorzystać)

-nie dowiozłeś taska na koniec sprintu? Nie ma sprawy, przeszacuj go sobie np. z 5SP na 2SP, wtedy wiemy że teraz spaliliśmy 3SP, a do kolejnego sprintu dorzucimy nieco mniej by było miejsce na dokończenie tych 2SP

-szacowanie relatywne, mamy jakieś taski wzorcowe na 1, 3, 5SP i staramy się nowe do nich porównać. Jak coś jest większe niż 5SP to staramy się podzielić.

-1SP na testy =/= 1SP na dewelopment =/= 1 manday. Po prostu to wychodzi w praniu i trzeba paru sprintów by wiedzieć ile się spala. U nas to wyszło jakoś 5SP na sprint na osobę na development, 4SP na osobę w testach, na tej podstawie się planujemy, ew. proporcjonalnie ucinamy jak są urlopy.

Ogólnie staramy się podchodzić profesjonalnie do pracy, czyli z jednej strony spokojna, jakościowo dobra, ale bez opierniczania się praca, z drugiej brak nacisków z góry bo i tak zrobimy podobnie SP jak zazwyczaj (jak ma wejść na już coś nowego pilnego, no to trzeba coś wywalić ze sprintu) i szacunki co kiedy zrobimy są w miarę jasne i przewidywalne, więc PM wie co i kiedy dowieziemy, wszyscy zadowoleni. Scrum to takie narzędzie które jednocześnie ma nie przeszkadzać i nie stwarzać presji, ale jednocześnie dawać jakieś estymaty i myślę że udaje nam się to robić. Z tym że trzeba wzajemnego zaufania i/lub np. niedopuszczania PM do szacowania. Ten obecny scrum to najlepsza metodologia w jakiej pracowałem, chociaż konkurencji za dużej nie było, wcześniej to był januszsoft gdzie prezes z zespołem planował taski co do kwadransa, oraz ziomek co postanowił być software housem i dał mi wszystkie taski z jednego projektu i bym sobie robił po kolei (niby fajnie, ale totalnie nie byłem w stanie określić czy coś mi zajmie jeden czy pięć dni).

korokczan napisał(a):

Jak w tytule. Ostatnio zacząłem się zastanawiać, czy wszędzie tak jest, czy ja po prostu trafiłem na pracoholików. Jeżeli wszystkie tickeciki w danym sprincie są już skończone, to bierzecie i wciągacie do obecnego sprintu, tickeciki z następnego sprintu/backlogu, czy robicie coś innego? Jako coś innego mam na myśli cokolwiek, może być opierniczanie się, nauka, gra na kompie, refactoring, tworzenie nowych ticketów.

Nikt mi nie płaci za opierniczanie się ani grę na kompie, więc nie.
Jak jest wystarczająco dużo czasu, to biorę story z następnego sprintu. Jak nie, to jakiś tech debt z dalszego backlogu.
Tickety tworzę gdy są potrzebne, a nie jak mam wolny czas.

somekind napisał(a):

korokczan napisał(a):

Jak w tytule. Ostatnio zacząłem się zastanawiać, czy wszędzie tak jest, czy ja po prostu trafiłem na pracoholików. Jeżeli wszystkie tickeciki w danym sprincie są już skończone, to bierzecie i wciągacie do obecnego sprintu, tickeciki z następnego sprintu/backlogu, czy robicie coś innego? Jako coś innego mam na myśli cokolwiek, może być opierniczanie się, nauka, gra na kompie, refactoring, tworzenie nowych ticketów.

Nikt mi nie płaci za opierniczanie się ani grę na kompie, więc nie.
Jak jest wystarczająco dużo czasu, to biorę story z następnego sprintu. Jak nie, to jakiś tech debt z dalszego backlogu.
Tickety tworzę gdy są potrzebne, a nie jak mam wolny czas.

Masz w umowie "W przypadku ukończenia wszystkich zaplanowanych działań niewolnik zobowiązuje się do wykonania nadmiarowej, niepłatnej dodatkowo pracy"?

Nie wykonuję nadmiarowej, niepłatnej pracy.
Porąbało Ci się coś z bezpłatnymi nadgodzinami, ale nie dziwi mnie to. Lata pracy w patologii zapewne sprawiają, że nie odróżnia się już normalności od fikcji.

korokczan napisał(a):

Czy bierzecie nowe taski do sprintu, jeżeli wszystko już skończyliście?

Jako facet biorę. Wynika to chyba z podświadomej obawy że prawdziwego mężczyznę ocenia się po tym jak kończy. Żeby więc uniknąć takiego ryzyka należy po prostu nigdy nie kończyć.

somekind napisał(a):

Nie wykonuję nadmiarowej, niepłatnej pracy.
Porąbało Ci się coś z bezpłatnymi nadgodzinami, ale nie dziwi mnie to. Lata pracy w patologii zapewne sprawiają, że nie odróżnia się już normalności od fikcji.

Dzisiaj kafelkarz ma u mnie skończyć łazienkę, powiedział, że skończy do 21, jak się wyrobi przed czasem to jeszcze kazę mu zrobić gniazdka w pokoju obok.

Gratuluję.
A ja nie robię gniazdek w pokoju obok. Ja mam nieskończoną podłogę z płytek do ułożenia. Bo jak już się trzymamy budowlanych analogii, to mniej więcej tak wygląda praca w firmie produktowej.

Ja widze 3 mozliwe scenariusze:

• obie strony się szanują, któraś bierze na klate zarówno benefity (udało się zrobić szybciej niż estymata, więc zróbmy coś jeszcze) jak i koszty (niedoszacowanie, niedowiezienie sprintu). W przypadku relacji pracownik - pracodawca, tą stroną jest zawsze pracodawca (płaci pracownikowi za czas, nawet jesli zadanie bylo niedoszacowane), w przypadku b2b i pracy zadaniowej - po stronie zleceniobiorcy. Zdrowa relacja, bez zbędnego ciśnienia, bez super luzu, poczucia winy za niedowiezienie.
• jedna strona dyma drugą - w przypadku pracownika/zleceniobiorcy jest to granie w piłkarzyki do konca sprintu 'bo juz wszystko zrobiłem', ale jak mi coś zajmuje dłuzej, to 'płać za nadgodziny' lub po prostu nie dowozisz sprintu. W przypadku pracodawcy/zleceniodawcy to wyciskanie pracownikow, wywolywanie doła w zespole po nie dowiózł, wymaganie niepłatnych nadgodzin, jednoczesnie wciskanie rzeczy z backlogu jesli praca poszła sprawniej niz przewidywana. Obydwie te sytuacje to patologia, choc bardzo częsta.
• obydwie strony starają się wydymać tą drugą - to już kombo sytuacji opisanych w punkcie drugim. Obydwie strony są sobie winne i dobrze im tak :D

W którym scenariuszu widzisz siebie?

Czas przeznaczam na naukę, poznanie nowych pracowników (pojechanie do biura xD), ew załatanie jakiegos długu poza konkursem co mnie bardzo irytował. Ew po prostu ide pobiegać

BTW sporo klientów miało właśnie taką politykę, że jak się wyrobisz w sprincie to prioritety jak wyżej :v. I mi tak zostało do dzis xD.

Trzeba brać uwagę, że programista "biorąc" task generuje także pracę innym. Kiedyś dostałem opierdol od menagera ze nie mogę tak zapierdalać bo potem on po nocach siedzi zeby opracować wymagania xD.

Coraz głupsze te pytania.
A czy jak się nie wyrobisz z taskiem, to siedzisz po godzinach żeby się zmieścić w sprincie?

Tak się zastanawiam, skoro dobieracie taski z backlogu, to w takim razie po co w ogóle jest scrum? Skoro liczy się ciągła i regularna praca, to scrum jest niepotrzebny, bo liczba taskow jest nieskończona, a czas spędzony na ceremoniach scrumowych (albo część tego czasu) mógłby zostać wykorzystany na pracę nad taskami.

korokczan napisał(a):

Tak się zastanawiam, skoro dobieracie taski z backlogu, to w takim razie po co w ogóle jest scrum? Skoro liczy się ciągła i regularna praca, to scrum jest niepotrzebny, bo liczba taskow jest nieskończona, a czas spędzony na ceremoniach scrumowych (albo część tego czasu) mógłby zostać wykorzystany na pracę nad taskami.

Tak. Scrum jest do d**y. I powinien zostać zastąpiony Kanbanem

korokczan napisał(a):

Tak się zastanawiam, skoro dobieracie taski z backlogu, to w takim razie po co w ogóle jest scrum? Skoro liczy się ciągła i regularna praca, to scrum jest niepotrzebny, bo liczba taskow jest nieskończona, a czas spędzony na ceremoniach scrumowych (albo część tego czasu) mógłby zostać wykorzystany na pracę nad taskami.

Bo scrum byku jest po to by sprawiać wrażenie ogarniętej pracy a tak naprawdę chodzi o kontrolę i wyzysk. Dobrze, że w końcu to zobaczyłeś.

Jak nie pracuję, bo taski mi się pokończyły, to co mam logować? Że nic nie robiłem? To jest może ok, jeśli jesteś na UoP. Na b2b po prostu nie powinienem wtedy fakturować tego czasu.

Wtedy zwykle albo robię jakiś refactor, bugi, albo biorę jakieś luźniejsze taski z backlogu.

korokczan napisał(a):

Jak w tytule. Ostatnio zacząłem się zastanawiać, czy wszędzie tak jest, czy ja po prostu trafiłem na pracoholików. Jeżeli wszystkie tickeciki w danym sprincie są już skończone, to bierzecie i wciągacie do obecnego sprintu, tickeciki z następnego sprintu/backlogu, czy robicie coś innego? Jako coś innego mam na myśli cokolwiek, może być opierniczanie się, nauka, gra na kompie, refactoring, tworzenie nowych ticketów.

U mnie w zespole często zdarza się, że wciągane są nowe tickety do sprintu (i to nawet bez wcześniejszej konsultacji z kimkolwiek), jak już nic nie ma na TO DO. Ogólnie nie jest to czymś dziwnym, ale ostatnio było więcej roboty i presji, w końcu jest nieco luźniejszy sprint, więc ja postanowiłem spędzić w końcu trochę czasu na nauce i innych rzeczach. Wczoraj pisaliśmy o tym z kolegą z zespołu, on też stwierdził, że poświęci więcej czasu na naukę, a dzisiaj już jeden tickecik z następnego sprintu skończony, obecnie ciśnie kolejnego :D Stąd zacząłem się zastanawiać, czy to parcie na jak najwięcej wykonanych tickecików/story pointów to standard, czy ja trafiam na tak ambitnych współpracowników?

Z mojego doświadczenia jeśli ludzie w zespole ściągaj się na taski i wrzucają do sprintu z backlogu na siłę, to o ile dobrze estymują to przeważnie piszą brudny kod który jest często tightly coupled i koszmarem w utrzymaniu i to kiedyś się odbije dla was czkawką :) albo koledzy nie wiedzą co estymują i nie biorą pod uwagę refaktoru do estymacji

w ogole nie konczymy nigdy sprintu i przerzucamy do nastepnego.
Nikogo z nas nie zwalniaja.

Tak trzeba FIRMĘ!

To zależy. Jeśli w konsekwencji np scrum master stwierdzi, że w kolejnym sprincie możemy zrobić więcej to zdecydowanie nie warto i poświęciłbym ten czas na jakieś pierdoły np zaległy update systemu operacyjnego, wolontariat, mentoring, badania okresowe, może nauka pod jakiś certyfikat itp

W sumie jedną rzecz bym wziął jeszcze pod uwagę: to czy firma to zwykły outsourcing i robiąca dla zewnętrznego klienta, czy ma własny produkt. W tym drugim przypadku myślę, że nie byłoby problemu, żeby nie brać więcej rzeczy do sprintu, jeśli taki się skończą. Gorzej jeśli się ma klienta z zewnątrz. Tutaj może mu zależeć na czasie, może wymagać dobierania nowych tasków, może się nie zgodzić na jakiś refactor, itp.