@potato_fairy

DL;DR

1. zasada: zawsze bierz o 100% wiecej czasu niz uwazasz, ze potrzebne, bo czesto tak wlasnie bedzie, a jezeli faktycznie skonczysz tak jak zamierzales, to odpocznij 50% pozostalego czasu, a nastepnie poinformuj 50% pozostalego czasu, ze skonczyles wczesniej. Jest to calkowicie klarowne i uczciwe. w rzeczywistosci nikt od Cb nie wymaga realizowania zadan tak szybko jak to sie glosno mowi. rzeczywistosc jest zazwyczaj taka ze nawet jak bys byl o wiele wolniejszy, to w dalszym czasie jestes mega potrzebny i oplacalny dla nich. to troche jak z kobieta, ona cos mowi i chce, ale musisz troche wiedziec lepiej od niej co bedzie lepiej

2. wiekszym problemem jest kiedy bierzesz za malo czasu i sie spuzniasz, niz wzial bys 2x wiecej. a poinformowal wczesniej. jest to korzystne dla Cb i dla firmy. musisz brac pod uwage przedewszystkim Twoje wypalenie zawodowe. kture bedzie postepowalo o wiele szybciej. jezeli bedziesz sie bawil w krutkie terminy i zyl niepotrzebnym stresem. a na drugim miejscu, co tez troszke wazne, to spuznienia sie eskaluja dalsze problemy i stresy w projekcie i zespole, wiec po co to generowac + spieszenie sie powoduje bledy, ktore potem tez beda gdzies sie odkladaly takze nie warto

reasumujac: przedewszystkim zrozum, to co tutaj wyzej jest napisane, bo tu nie potrzebne sa wielkie kursy, to jest kwestia mindsetu i po prostu swiadomosci co dla Cb i firmy jest lepsze - a jest to to samo, nie ma tu kolizji interesu, ze oni potrzebuja max malo, a Ty max duzo. to tak nie dziala. oboje potrzebujecie solidnej dawki czasu zeby odnosic sukcesy dlugoterminowe, a nie tylko chwilowe, a zaraz problemy

jest w tym wszystkim wiele niewolnika zapieprzacza, i wlasnie ten mindset trzeba opuscic, bo jest swietny do przerzucania kamieni - nie, nawet tam nie - ale bardzo slaby w pracach umyslowych i projektowych, cel to spokojny mindset architekta

jak to wszystko dobrze zrozumiesz to bedziesz mial wiecej odwagi, bo tego potrzeba, zeby okreslac porzadne dawki czasu, to jest podobna sytuacja jak negocjowanie pensji, potrzeba odwagi zeby nie brac najnizszej tylko dyskutowac, a ta najnizsza tez by byla szkodliwa dla firmy, bo pracownik by pracowal jak ciec

@potato_fairy Z moich obserwacji wynika, że im masz większe doświadczenie w używanych technologiach jak i w projekcie tym lepiej jesteś w stanie estymować. Raczej nie widzę możliwości żeby nauczyć się tego z kursu. Dużo też zależy od tego czy taski są poprawnie opisane i od sposobu w jaki estymujecie. U nas jest przyjęte, że 1, 2 i 3 SP wpadają do zadań "na kilka dni", 5 do tych "tydzień lub więcej" a 8 do "cały sprint ale z ryzykiem, że więcej". Nie spotkałem się z systemem który by pozwolił estymować z dokładnością do kilku godzin. U nas to się sprawdza - raz musisz spiąć poślady i pracować szybciej, raz masz luzik w połowie sprintu ale zazwyczaj takie estymaty pozwalają na lajtową pracę przez cały okres sprintu. Wszystko chyba zależy od srum mastera i tego jak zorganizuje on pracę zespołu.

@potato_fairy Jeśli wydaje ci się, że coś zajmie ci godzinę, to mów, że zajmie dwie. Skończysz prawdopodobnie przed czasem to super, wow jaka wydajność wow uszanowanko. A coś się zesra i rzeczywiście zejdą dwie godziny? Cóż, przecież mówiłeś, no nie?

@jonas dokladnie, to samo wyzej rozpisalem tylko szerzej

@potato_fairy tldr; czy jesteś juniorom czy seniorem, nie będziesz w stanie prawidłowo wyestymowac czasu potrzebnego na zadanie

@potato_fairy Ja bym dodał jedną rzecz. Ustal sobie minimalny czas na realizacje zadań. U siebie wybrałem 4h i poniżej tego czasu nigdy nie wyceniam (nawet w przypadku zmiany koloru przycisku). Niestety jeśli jest kilka projektów to samo przełączanie kontekstu zajmuje czas. Czasami chcesz uruchomić stary projekt i okazuje się, że ktoś zostawił bałagan, środowisko lokalne nie działa, testy nie przechodzą itd. I nagle brakuje czasu. Dzięki tym dodatkowym godzinom zawsze masz bufor na tego typu rzeczy. A jak skończysz w 15min to super, będzie sukces w firmie, bo zrobiłeś dużo poniżej estymacji i firma zaoszczędziła dolary.

PS: Też jestem z drużyny Łazika (a może raczej Łozika) xD

@potato_fairy warto wspminieć o rozbijaniu tasków na mniejsze jeżeli szacowanie sprawia trudność

@potato_fairy 90% funkcjonalności powstaje przez 90% czasu. Pozostałe 10% powstaje przez drugie 90% czasu.

Go from there.

@potato_fairy U mnie działa taka zasada: określam czas najlepiej jak umiem i potem mnożę przez trzy.