Hipotetyczna sytuacja związana z robieniem zadań w pracy

0

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 ?

  1. Robisz dalej spokojnie taska nawet jakby to miało trwać jeszcze nawet kilka dni.
  2. Ciśniesz mocniej aby też jak najszybciej zrobić taska.

Lub może byście postąpili jeszcze inaczej w takiej sytuacji ?

4

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.

1

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ą.

5
  1. To nie rywalizacja, jesteście w zespolce. Rób ile potrzebujesz, nie oglądaj się na innych.
  2. Do tej pory w takiej sytuacji to ja byłem tym "kolegą", więc po prostu staję nad tym wolniejszym z kawusią i delektuję się chwilą wyglądajac za okno mówiąc "ah" po każdym siorpnięciu. W dobie roboty zdalnej możesz zawracać dupę drugiej osobie na czacie nawiązując że razem zaczęliście i prowadzić bezsensowne smalltalki i okazać dominację przez pokazywanie ile masz wolnego czasu.

Od drugiej strony to jak task jest naprawdę mocno podobny to możesz zerżnąć rozwiązanie.

1

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".

  1. 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ł.

3

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.

3

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 :)

0

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?

0

@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

2
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ć.

1 użytkowników online, w tym zalogowanych: 0, gości: 1