Ile wam zajmowało wykonywanie tasków jak byliście juniorami?

0

Ile wam zajmowało wykonywanie tasków jak byliście juniorami? Chodzi mi o to, że np task był wyceniony na 10h to czy faktycznie wam tyle to zajmowało? Jeśli nie, to ile czasu potrzebowaliście?

1

Pierwsza sprawa, to czy osoba która estymowała task (zakładam, że to ktoś bardziej doświadczony niż Ty) wiedziała, że trafi on do juniora? Bo jeśli estymowała "pod siebie" to powinieneś pomnożyć to przez 2 (przynajmniej).

Druga sprawa to to, że nie ma ogólnej odpowiedzi na Twoje pytanie. Wszystko zależy od taska i od tego kto to estymował. Nawet jak się nie wyrobisz, to warto wspomnieć o tym liderowi i podać przyczynę. ;)

3

nawet seniorzy się nie mieszczą tylko rzadziej

0

Task wyceniany przeze mnie, ale wycena jest na poziomie co najmniej mida. W takim razie jeśli task został wyceniony na 10h ile czasu może to zając juniorowi?

1

Rzekłbym, że nawet 20-30h. Zależy jaki poziom reprezentuje dany junior i jak szybko przyswaja wiedzę.

3

Przeważnie "wycena" jak szybko zrobisz zadanie jest o kant .... potłuc. Scrum i inne agilowe techniki próbują oszacować niemierzalne, bo zwykle nie uwzględnia się czasu potrzebnego na:

  • nabycie wiedzy na temat tego zadania! Nie zaczynasz sobie kodzić tak o, tylko musisz wiedzieć co dokładnie masz zrobić, dlaczego itp. To powinno być omówione pewnie na jakimś meetingu, ale w życiu różnie z tym bywa. Chodzi zarówno o wiedzę biznesową, jak i techniczną (np. integracje z takim i siakim API)
  • review
  • poprawki
  • testy
  • release
  • możliwe opóźnienia wszelkiego rodzaju

Ogólnie nie jestem zwolennikiem Scruma i jemu podobnych, ale to oczywiście zależy przede wszystkim od ludzi, którzy z niego korzystają. Sam mam raczej słabe wspomnienia. Nauczony doświadczeniem, prawie zawsze jest lepiej estymować na wyrost - nie chodzi tu o lenistwo i chęć byczenia się w pracy. Zwykle po prostu tak jest, że myślimy, że dodanie ficzerka to tylko 3 linijki kodu...

0

Lepiej jest zaplanować dłuższy czas i wyrobić się przed terminem. Wtedy można odtrąbić sukces. Przekładając termin realizacji nie mamy takiej możliwości. Tak więc najlepiej dać drugie tyle ile myślimy, że nam to zajmie.

1

Task wyceniany przeze mnie, ale wycena jest na poziomie co najmniej mida. W takim razie jeśli task został wyceniony na 10h ile czasu może to zając juniorowi?

Czyli sam się wpakowałeś w syf i wyceniłeś coś zawyżając swoje umiejętności / zaniżając faktyczną estymację?

0

Od kilku minut do kilku tygodni. Wyceny wycenami, a życie życiem.

5

title

1

dla juniora: wycena x2
dla mida: wycena x1.5
do każdej wyceny 20-30%... bo coś po drodze i tak wyjdzie, a sama kwestia wycen to problem branży i spełniania oczekiwań biznesu 'to przecież tylko jeden przycisk więcej'; trochę więcej pesymizmu czasami się przydaje i lepiej przekazać informację, że coś potrwa 2 tygodnie, a później zostało skończone w tydzień

0

U siebie biore udział w estymacji więc już wtedy sobie odpowiednio zawyżam, bo często wychodzi, że jeszcze trzeba czekać na coś po drodzę, dostępy, nikt nie chce zrobić CR i tak dalej

0

Nie ma co estymować w czasie, lepiej w jakiejś abstrakcyjnej jednostce jak punkty.

1
AreQrm napisał(a):

Nie ma co estymować w czasie, lepiej w jakiejś abstrakcyjnej jednostce jak punkty.

I tak musisz to czasowo oszacować, gdy klient chce znać łączny czas, jaki jest przewidziany na zadania,

1

Nie ma w zasadzie powodu dla którego junior miałby wykonywać task szybciej lub wolniej od seniora.

Senior nie różni się od juniora tym, że pisze szybciej na klawiaturze tylko tym, że popełnia mniej błędów i przewiduje skutki swoich decyzji. Senior odradzając dany projekt i proponując inne rozwiązanie lepiej pasujące do koncepcji zaoszczędzi sporo pieniędzy klientowi.

1
Pipes napisał(a):

Przeważnie "wycena" jak szybko zrobisz zadanie jest o kant .... potłuc. Scrum i inne agilowe techniki próbują oszacować niemierzalne, bo zwykle nie uwzględnia się czasu potrzebnego na:

  • nabycie wiedzy na temat tego zadania! Nie zaczynasz sobie kodzić tak o, tylko musisz wiedzieć co dokładnie masz zrobić, dlaczego itp. To powinno być omówione pewnie na jakimś meetingu, ale w życiu różnie z tym bywa. Chodzi zarówno o wiedzę biznesową, jak i techniczną (np. integracje z takim i siakim API)
  • review
  • poprawki
  • testy
  • release
  • możliwe opóźnienia wszelkiego rodzaju

Ogólnie nie jestem zwolennikiem Scruma i jemu podobnych, ale to oczywiście zależy przede wszystkim od ludzi, którzy z niego korzystają. Sam mam raczej słabe wspomnienia. Nauczony doświadczeniem, prawie zawsze jest lepiej estymować na wyrost - nie chodzi tu o lenistwo i chęć byczenia się w pracy. Zwykle po prostu tak jest, że myślimy, że dodanie ficzerka to tylko 3 linijki kodu...

U mnie przy estymatach wszystkie w/w rzeczy są zawarte i klient musi się z tym pogodzić. Dodatkowo dorzucamy czas zależnie od wielkości na analize aby zrobić estymatę - więc de facto klient najpierw musi zapłacić za to, że dookreślimy to co on chce, jak ma być to zrobione i wtedy dopiero robimy estymatę na zadanie. Analiza może zająć od dnia do miesiąca.

Jeśli klient nie zgadza się na analizę to jest to po prostu szacowanie, które jest obarczone błędem z zastrzeżenim, że nie będzie w terminie.

Przy analizie należy zrobić dokłądny work-breakdown, inaczej osoba, która estymuje nie wie co estymuje. Albo wiesz dokładnie krok po kroku co trzeba zrobić / zaimplementować, albo wróżysz z fusów.

0

Najlepsze są właśnie te spotkania gdzie biznes przedstawia swój kolejny genialny pomysł z serii "rozszerzmy istniejący już feature" i:

  1. ten istniejący feature jest już tak stary, że nikt nie wie co to jest i jak to działa
  2. nikt nie ma pojęcia jak wygląda kod w tamtym miejscu i czy w ogóle istnieje szansa na rozszerzenie (bo może być potrzeba przepisania w całości)
  3. nikt z biznesu nie przyjdzie porozmawiać o tym wcześniej lub nie ma czasu na chociażby próbę zapoznania się z zakresem działania

Wtedy ochoczo estymuję rzucając albo znaki zapytania, albo estymaty sięgające wręcz miesięcy pracy podnosząc ciśnienie scrum masterowi do krytycznych wartości

Podoba mi się pomysł estymowania estymaty.

0

Ostatnio bardzo słabo wyceniłem task, szacowałem 2-3 dni, wyszło 8. Błędem było nieprzemyślenie jednej rzeczy, co kosztowało mnie około dnia, a reszta obsuwy to totalne niedogadanie się w pewnej kwestii.

0
  • Dwa inputy i jeden przycisk a dwa tygodnie pracy? To chyba jakaś pomyłka.
  • Google. Jeden input i jeden przycisk a od 21 lat nie mogą skończyć.
0

Ile wam zajmowało wykonywanie tasków jak byliście juniorami?

bardzo krotko, wspolpracownicy krzyczeli na mnie ze za szybko robie i przez to oni zle wygladaja

Chodzi mi o to, że np task był wyceniony na 10h to czy faktycznie wam tyle to zajmowało?

zazwyczaj zajmowalo mi 5-10x mniej niz byl wyceniany. ale to byly czasy januszsoftu gdzie trzeba bylo znalezc miejsce w kodzie gdzie trzeba bylo dodac nowa kolumne do dataGridView albo sprawdzic czemu null pointer leci

0
danek napisał(a):

bo często wychodzi, że jeszcze trzeba czekać na coś po drodzę, dostępy, nikt nie chce zrobić CR i tak dalej

I zamiast zabrać się za inne taski to po prostu czekasz? Jak zadanie jest zablokowane bo nie "schodzą" z nie niego godzinki.

tom8543 napisał(a):

Ile wam zajmowało wykonywanie tasków jak byliście juniorami?

Najpierw zdefiniuj kto to jest junior według Ciebie

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