Załóżmy taką hipotetyczną sytuację. Dołączasz do nowego projektu razem z inną osobą. Oboje z was są backend developerami i regularami. Na starcie dostajecie mocno podobne taski wycenione na tyle samo SP. Kolega dowozi swojego taska, a Ty jeszcze jesteś w trakcie robienia. Co wtedy robisz ?
Lub może byście postąpili jeszcze inaczej w takiej sytuacji ?
To pytanie dlaczego ta jedna osoba ma problem z wykananiem a druga nie?
Może współpracujcie. Ja ostatnio miałem taska - coś czego nie robiłem wcześniej, to się grzebałem, kolega mi coś tam podpowiadał. Za parę dni on miał taska w którym nie miał wprawy to ja mu pomagałem. Osobiście nie widziałem z tym problemu.
Jeśli widzisz że jakbyś się wziął do roboty zamiast pół czasu gadać z innymi i przepalać czas na kawki to zrobił byś to 2x szybciej to weź się za robotę i na drugi raz nie odstawaj tak bardzo od drugiej osoby bo będziesz pierwszy do odstrzału. Moje doświadczenia są także że jak firma zatrudnia kilku ludzi naraz poniżej seniora do jednego zespołu to nie potrzebuje kilku tylko robi ostatni etap rekrutacji więc po okresie próbnym najpóźniej najsłabsze ogniwa wylatują.
Od drugiej strony to jak task jest naprawdę mocno podobny to możesz zerżnąć rozwiązanie.
Wybrałbym opcję pierwszą, bo tworzenie oprogramowania to maraton, a nie sprint. Lepiej dowozić ze stałą szybkością niż zrobić coś szybko, a potem się wypalić po kilku sprintach i zakładać wątek na forum "robię darmowe nadgodziny, a i tak grozi mi zwolnienie".
- Ciśniesz mocniej aby też jak najszybciej zrobić taska.
Ale przecież to nie ma sensu, jeśli nie umiesz zrobić taska, to go i tak nie zrobisz szybciej samemu (no chyba, że masz problem z etyką pracy i się opieprzasz). Najlepsze co możesz zrobić, żeby przyśpieszyć ten proces, to wciągnąć w to inne osoby i jeśli kolega dowiózł taska, to wkręcić go, żeby ten z kolei też się nie opieprzał i tobie pomógł.
Odpowiedź 1, ponieważ SP z definicji określa złożnoność zadania, a nie czas potrzebny (przyznany? dozwolony? akceptowalny?) na wykonanie tego czasu przez daną osobę.
A to że obie osoby są regularami wcale nie oznacza, że mają dokładnie te same umiejętności i zrobią dane zadanie w dokładnie identycznym czasie.
Estymacja to jedno, zdrowy rozsądek to drugie. Jeśli jesteś nowy to wiadomo że możesz robić dłużej. Najlepiej nie dać się wciągnąć w scrumowe wyścigi, stąd bliska droga do poczucia winy, siedzenia po godzinach i wyrabiania 200% normy ku uciesze poganiaczy :)
Podłączam się do pytania, macie np. taska na 1SP ile czasu max. mozna na niego przeznaczyć? Czy robienie taska 1-2 tygodnie w projekcie ze skomplikowaną domeną jest akceptowalne u was?
@adamKowal: eeeee nie wiem, z tego co widzę jest to zależne od firmy, np u jednego klienta mamy, że jeśli ktoś powie 5 sp tzn że zajmie to więcej niż 1dzień więc task trzeba podzielić a 1sp to przyjmuje 2h :p 3sp to u niego 5-6h. Czyli 1sp to taski pokroju bug z marginesem na stronie, albo tekst ma być pogrubiony a nie jest :p
ehhhhh napisał(a):
@adamKowal: np u jednego klienta mamy, że jeśli ktoś powie 5 sp tzn że zajmie to więcej niż 1dzień więc task trzeba podzielić a 1sp to przyjmuje 2h :p 3sp to u niego 5-6h. Czyli 1sp to taski pokroju bug z marginesem na stronie, albo tekst ma być pogrubiony a nie jest :p
6 lat pracuje jako programista i mogę Ci zagwarantować że przeliczanie Story Pointow na czas/godziny zawsze kończyło się w dłuższej perspektywie nadgodzinami dla programistów.
Nigdy nie idź tą drogą. Nawet w Scrum Guide przed tym ostrzegają. Sam tego doznałem i jak tylko widzę ze biznes zaczyna tak robić zapala mi się czerwona lampka i zaczynam ich edukować.
adamKowal napisał(a):
Podłączam się do pytania, macie np. taska na 1SP ile czasu max. mozna na niego przeznaczyć? Czy robienie taska 1-2 tygodnie w projekcie ze skomplikowaną domeną jest akceptowalne u was?
Problem jest w tym, że jak się za długo robi coś samemu, to:
Czyli jak się coś długo robi, to potrzebna jest ciągła komunikacja z zespołem, integracja kodu z resztą repo i synchronizacja z działaniami innych programistów, bo inaczej taka robota jest bez sensu.
Scrum to scam. O ile jeśli robisz po raz n-ty jakieś zadanie, to możesz mniej więcej oszacować. Ale jak robisz ciągle jakieś nowe rzeczy, wchodzicie w nowe technologie i zespół cały czas ewoluuje to szacowanie ile coś zajmie często jest zupełnie bez sensu.
Ja bym poprosił tego który zrobił szybciej żeby się zabił albo przynajmniej zaczął go publicznie oczerniać. A się tłumaczył że zadanie było za mało wycenione trzeba było przepisać tony legacy spaghetti.
Dodam jeszcze, że to że dwie osoby pracują na takim samym stanowisku, wcale nie oznacza, że tyle samo zarabiają i są wobec nich identyczne oczekiwania.Rozbieżność wbrew pozorom może być nieraz naprawdę duża.
Co to znaczy "cisnąć mocniej taska"? Serio pytam, bo ja nie za bardzo jestem w stanie postanowić sobie, że dzisiaj będę myślał szybciej/efektywniej itp.
Jak ktoś nie jest pewien swoich umiejętności, to mu się wydaje, że robi wszystko wolniej. Taski nigdy nie są takie same, szybciej nie zawsze znaczy lepiej, ktoś może być od ciebie lepszy (i możliwe, że lepiej wynagradzany), albo przepierniczać mniej czasu na głupoty.
Zastanów się co jest przyczyną tych różnic i wtedy się zastanawiaj jak je wyrównać (albo nie).
mielony711 napisał(a):
Załóżmy taką hipotetyczną sytuację. Dołączasz do nowego projektu razem z inną osobą. Oboje z was są backend developerami i regularami. Na starcie dostajecie mocno podobne taski wycenione na tyle samo SP. Kolega dowozi swojego taska, a Ty jeszcze jesteś w trakcie robienia. Co wtedy robisz ?
- Robisz dalej spokojnie taska nawet jakby to miało trwać jeszcze nawet kilka dni.
- Ciśniesz mocniej aby też jak najszybciej zrobić taska.
Lub może byście postąpili jeszcze inaczej w takiej sytuacji ?
Obie te rzeczy, bo zawsze robię taski spokojnie i najszybciej jak umiem. I w ogóle nie interesuje mnie jak wycenione taski dowożą moi koledzy i kiedy.
Oczywiste jest też, że jak ktoś skończy swoją robotę, to pomaga reszcie. Pracuję w zespole, nie
PaulGilbert napisał(a):
Scrum to scam. O ile jeśli robisz po raz n-ty jakieś zadanie, to możesz mniej więcej oszacować. Ale jak robisz ciągle jakieś nowe rzeczy, wchodzicie w nowe technologie i zespół cały czas ewoluuje to szacowanie ile coś zajmie często jest zupełnie bez sensu.
Wszystko jest bez sensu, jeśli robi się to bez przygotowania.