Przejmowanie moich sub taskow przez innego programistę

hej,

Podczas sprintu miałem swój task, który spokojnie bym dowiózł w sprincie. Jednak w trakcie sprintu pojawił się pilny bug, który zajął mi około 3 dni, bo był dosyć złożony. Przez to nie zdążyłbym dowieźć swojego taska w sprincie. I w takim przypadku część sub taskow z tego taska zrobił inny deweloper po konsultacji ze mną.

Nie wiem czy to jest ok, ze ktoś inny zrobił część mojego taska żeby dowieźć go w sprincie? Jak na to może patrzeć klient lub inni członkowie zespołu?

Dodam, ze na tym projekcie jestem dopiero 1.5 miesiąca.

Jak na to może patrzeć klient

Ogólnie klient powinien mieć to w D dopóki dowozicie. Zwłaszcza jak jesteście samoorganizującym się zespołem. Co do reszty zespołu to pytaj zespołu. Ale moja kryształowa kula mówi że według Mirka to spoko, a Janusz się wnerwił, No ale Janusz zawsze się wnerwia wiec bym się nim nie przejmował

Wow, ale tu się robi programistyczna samosia :D

Jeżeli nie masz sobie nic do zarzucenia, bo pracowałeś nad czymś innym to nie rozumiem czemu ktokolwiek miałby mieć pretensje.

To tak zwykle wygląda. Task rozpisany na pierdyliard podtasków (no może nie pierdyliard ale kilka) i kto ma wolne moce przerobowe to się łapie żeby było szybciej. Ktoś czeka na coś tam co będzie za dwa dni - łapie poddatask kogoś innego.
Nigdy się nie zastanawiałem czy to źle czy dobrze.

A Ty masz jakieś udziały w firmie klienta, że mówisz, że uważasz, że to w ogóle był "twój task"?
Uważasz, że lepiej byłoby, aby kolega się nudził, a task został niedowieziony?

Po to dzieli się zadania na mniejsze, żeby mogło nad nimi pracować wielu ludzi. Np. u mnie zazwyczaj w toku są 2 zadania, nad każdym pracują 2-3 osoby. Mało które zadanie jest "jednoosobowe".

To normalne a wręcz bardzo dobre. Wymienialność tasków jest pożądaną cechą, ale aby to było przyjemne zespół music być na podobnym poziomie technicznym.
Są zadania którymi się nie wymienisz bo np. 80% czasu to nauka czegoś zanim coś zrealizujesz. Wtedy mocno nieefektywnym staje się zabranie takiego taska przez inną osobę, no chyba że nic innego juz nie zostało na sprint

Ogólnie, to taski są "zespołu" a nie twoje. W praktyce różnie bywa. Jak zespół zobowiązał się, że dostarczy X na koniec sprintu, a później się okazało, że ma dostarczyć X+buga to dobrze, że ktoś zabrał się za robotę, zamiast drapać się przez tydzień w tyłek i patrzeć jak lecisz na ścianę. Szczególnie, jak jesteś w projekcie krótko i masz większe szanse na wtopę.

U mnie to wygląda tak że jak zrobimy cel sprintu i tak 75% story pointów to uznajemy to za wspólny sukces i nie wnikamy kto ilerobił.

Ale nie ma takiego czegoś jak "mój task". Jak task wisi w "todo", to bierze go ten, kto ma czas. A jak task zaczęty, ale jest coś pilniejszego, to po prostu zwracasz go do "todo", odpinasz się, a potem ktoś inny zaczyna od miejsca, w którym skończyłeś.

A co za roznica? Dowiezliscie jako zespol wiec jest ok.

Jeśli to zrobił po konsultacji z tobą, to naprawdę nie wiem, w czym może być problem.
Zespół potrafi się zorganizować w obliczu nieoczekiwanego buga z produkcji. Wszystko gra.

Wyczuwam nadmierne przywiązanie do własnego kodu. Zrozumiałbym (ale nie popierałbym), gdybyś był architektem, który od 5 lat pielęgnuje swój ulubiony kawałek kupy, ale tu masz zaledwie kilka tygodni w projekcie. Projekt i jego wynik jest klienta. Twoja jest tylko wypłata i doświadczenie.

A od kiedy bug jest wazniejszy niż historyjka?

A jeśli wazniejszy to kto tak twierdzi.

A po to masz zespół żeby wskoczył na twoje miejsce jak ty nie zdążysz.

To tyle moją kryształowa kula. Amen.

Trudne sprawy odcinek 1547.

Jest to ok. Ważne, że zrobione.