Nie dotrzymuje tempa pracy w projekcie

W skrócie o mnie, mam 41 lat. Programuję zawodowo już 11 lat. Na papierze jestem Java Developerem, w praktyce w ostatnim czasy one-man-army (pisanie kodu, stawianie ci/cd, devops/ zbieranie wymagań, rozmowy z biznesem, praca w scrumie). Od stycznia zacząłem nowy projekt i widzę że sytuacja zaczyna się powtarzać. Estymaty zaniżane, presja na zamykanie tasków, sporo spotkań Scrumowych, a robić nie ma kiedy.

Podczas wycen tasków niejednokrotnie zaznaczam, że nie jest to deadline tylko moja labelka którą daję, jako skomplikowanie taska. Robię rzetelnie od 9 do 17 bez żadnego obijania się. Mam gości w zespole, bo jest nas piątka razem. 4 programistów + jeden Technical Project Manager. W zeszłym tygodniu wycenialiśmy taska i moje estymaty były zaniżane, a 3 gości Devów z którymi pracuję widzę że mają parcie na "karierę" bo robią w tej pracy bez opamiętania, mam tutaj na myśli że widzę że programują za free do projektu nie zgłaszając tego. W pewnym sensie sami sobie stwarzają presję.

No i nie dowożę już taska któryś raz z kolei, zazwyczaj dowożę, ale w kolejnym Sprincie. Na pytanie dlaczego, mówię że nie ma czasu i pracuję 8h dziennie. Do tego w zespole jesteśmy wyoutsourcowani do firmy zewnętrznej jako zespół i robię jako BA po części z tamtejszym Product Ownerem, także tak jakby nie robię u siebie.

Wczoraj miałem pogadankę z Technical Project Managerem że nie robię "Sprint commitment", a ja mu powiedziałem że nie robię, bo nie wyrabiam się, pracuję 8h i niech mi płaca. Zaznaczę też że mam rodzinę, po pracy się dokształcać nie zamierzam, 4 dzieci, a z kolegami w zespole którzy jeszcze 30 lat nie mają, ani rodzin, "ścigać" się nie zamierzam.

Pamiętam, dawniej tak robiłem jak oni, ale teraz już nie zamierzam, życie jest za krótkie.

Czy to już czas na przejście w jakieś role managerskie/kierownicze? Czuję po prostu, że jako dev nie jestem w stanie sprostać temu w jak szybkim czasie trzeba się uczyć nowych rzeczy, często kosztem wolnego czasu itd. itd. itd. To wszystko poszło w odstawkę dla mojej rodziny. wiecie o co mi chodzi. Dzięki za odpowiedzi jak mógłbym pokierować teraz swoją karierą

Zmień ten kołchoz i wyluzuj, zacząłeś od szukania problemu w sobie, a wg mnie on leży w pracodawcy. Gwarantuję Ci, że większość z nas nie siedzi po godzinach, żeby wyrobić sprint commitment.

A czy masz sprecyzowane, co chciałbyś robić? Może być dalej deweloperem Javy, menedżerem, kimś innym?

Przejdz sobie do jakiejs firmy z europy zachodniej - tam taka praca to standard, a otrzec lzy bedziesz mogl funtami

Ewentualnie możesz też spróbować popracować dla firm skandynawskich - tam bardziej cenią "work-life balance", a pieniądze też jak na nasze standardy są bardzo w porządku

norek111 napisał(a):

3 gości Devów z którymi pracuję widzę że mają parcie na "karierę" bo robią w tej pracy bez opamiętania, mam tutaj na myśli że widzę że programują za free do projektu nie zgłaszając tego. W pewnym sensie sami sobie stwarzają presję.

Jak to jest możliwe? Przecież w tych korporacyjnych scrumowych rytuałach wszystko musi być na tacy. Nie można sobie przepychać tasków pod stołem, bez zgłaszania. To jest tzw. side commitment i jest to wbrew tym wszystkim scrumowym zasadom ;). Ewentualnie może to być dopuszczalne, jak ktoś prowadzi firmę/projekt i sam sobie wymyślił takie zasady, a nie jak jest "szeregowym koderem".

Druga sprawa, to fakt, czy jakość pracy tych programistów, co tak cisną jest zadowalająca, czy jedynie robią szybko, ale byle jak. Jeżeli Twoja praca trwa dłużej, a jej jakość jest lepsza, to możesz tego użyć jako argumentu, jak ktoś się Ciebie uczepi.

W IT nie da się precyzyjnie określić, ile coś zajmie roboty. Jak ktoś się Ciebie czepia, że powiedziałeś na jakimś planningu, że coś ma tyle pointów, a zajęło to więcej czasu, to nie powinno być to problemem. M.in. dlatego uważam, że te wszystkie wyceny tasków i poker planningi, to bullshit dla managerów i strata czasu.

Takie nieustanne ciśnienie nie jest normalną sytuacją. Ja bym na Twoim miejscu postawił sprawę jasno, że praca zajmuje tyle i tyle czasu, nie da się tego przyspieszyć. Jeżeli koledzy robią robotę szybciej, to dlatego, że siedzą za darmo po godzinach, a Ty nie będziesz siedział za darmo po godzinach. Jak nie będą potrafili Ciebie zrozumieć po ludzku, to czas na zmiany.

Idiotyczny pomysł, który pozwoli przetrwać w tym projekcie:

Jesli wyceny zaniżają o 20% to wyceniaj o 20% więcej.

norek111 napisał(a):

Czuję po prostu, że jako dev nie jestem w stanie sprostać temu w jak szybkim czasie trzeba się uczyć nowych rzeczy, często kosztem wolnego czasu itd. itd. itd.

Trzeba być na bieżąco, ale bez przesady. W tych 8 godzinach, za które masz płacone, powinieneś spokojnie znaleźć czas na naukę nowych rzeczy. Jak ciśnienie w projekcie jest duże, to po prostu zmień projekt.
Ewentualnie możesz ratować sytuację. Za dowiezienie tasków jest odpowiedzialny cały zespół, niekoniecznie jedna osoba musi brać jedno story. Możesz się z kimś podzielić storyjką, rozbić ją na mniejsze taski i dopiero działać. Możesz zaproponować pair programming itd.

mam 41 lat. Programuję zawodowo już 11 lat

oraz

a z kolegami w zespole którzy jeszcze 30 lat nie mają, ani rodzin, "ścigać" się nie zamierzam.

Tutaj chyba jest problem - jeśli po 11 latach stażu nadal siedzisz w tym samym miejscu, gdzie inni, młodsi wiekiem i stażem. Z takim doświadczeniem raczej powinieneś być gdzieś wyżej - jakiś kierownik projektu, doradca, architekt czy ktoś, kto już nie zajmuje się (albo nie tylko) kodowaniem.

To trochę jak na budowie - jak masz pracownika, który ma doświadczenie i pracuje już długo, to nie każesz mu biegać z łopatą i wiertarką, bo po pierwsze - szkoda marnować jego potencjał, a po drugie - raczej nie wygra porównania z 20-latkiem, ten drugi będzie szybciej łopatować. Z takiego pracownika robi się majstra/brygadzistę, jakiegoś kierownika, daje mu zadania bardziej związane z koordynacją czy organizacją prac.

Moim zdaniem opisany przez Ciebie problem istnieje, ale nie jest to Twoja wina, tylko firmy, która nie umie dobrze zagodpodarować posiadanych tak zwanych "zasobów ludzkich".

Jak nie udaje się Sprint Commitment to twój szef nawalił a nie ty xd, przecież ty jesteś tylko od przepychania klocków a nie ustalania, które są ważne i jaka powinna być kolejność ich realizacji. Czasami mam wrażenie, że w IT jest za dobrze i ludzie sami sobie wymyślają problemy

Na moje, jeżeli podałeś że coś zajmie tydzień, a ktoś inny powiedział, "nie, to proste jest, 3 dni wystarczą" to on się zobowiązał, że to dowiezie a nie ty. Wymuszanie w jakiejkolwiek formie dodatkowej pracy bez zapłaty jest złem i należy to tępić. Nie mówię o sytuacjach kiedy to jest naprawdę potrzebne i dogaduję się z pracodawcą, ok, to w przyszłym tygodniu/miesiącu sobie to odbiorę. Ogólnie nie ma głupszego pomysłu na "wywieranie presji" niż gadanie o sprint commitment, czyli osiągnięciu z d...y wziętego celu w z d...y wziętym terminie. Sprinty, planowanie może mieć wartość, ale nie jest nią wywarcie presji.

Jeżeli nie widzisz siebie na stanowisku managerskim, to nie idź w tym kierunku. Ogólnie w software house'ach, czy ogólnie zespołach zakontraktowanych na wykonanie jakiegoś statement of work za stałą kasę taka presja będzie praktycznie zawsze, bo na którymś etapie, ktoś sobie zaplanował, że wykonasz jakąś pracę, za jakąś kasę i kiedy ten plan bierze w łeb to tracą swoją działkę. W dodatku dostają zlecenia z grubsza dlatego, że zaoferowali najniższą cenę klientowi. Parę lat temu ten model się sprawdzał, bo pensje programistów w PL były niższe, więc pole manewru większe. Teraz to się zmienia bardzo szybko, więc ryzyko dla projektów zleconych w PL rośnie.

Zmień ten kołchoz. To jest patologia scrumu i managementu. Z takim doświadczeniem imo to rzucisz CV i zaraz cos sie znajdzie.

Mam 33 lata (ale ja już jestem stary :O ). Pracuję od 10 lat. Często zdarza mi się czegoś nie dowieźć bo system to spagetti. Jak czegoś niedowiozę to drugi programista broni mnie że to bylo bardziej skomplikowane niż myśleliśmy na estymacie. Większość osób w teamie ma dzieci (chociaż ja nie mam). Outsoursing

Gdzie wy kur'a pracujecie? (to kieruję nie tylko do OPa ale też do przeszłych i przyszłych ludzi z podobnymi problemami) Nie jesteście w stanie znaleźć na spokojnie jakiejś nie poj'banej firmy z średnią wieku 30+?

Zmień kołchoz.
Dla przykładu w jednym tygodniowo klepałem w klawiaturę 40 godz., może i więcej, w drugim 8. Drugi płacił więcej niż pierwszy.
Aczkolwiek więcej nauczyłem się w pierwszym niż w drugim.

norek111 napisał(a):

Na papierze jestem Java Developerem, w praktyce w ostatnim czasy one-man-army (pisanie kodu, stawianie ci/cd, devops/ zbieranie wymagań, rozmowy z biznesem, praca w scrumie).

Może w tym jest problem. Jeśli masz za dużo różnych obowiązków (dochodzi zapewne "context switching"), to nic dziwnego, że się nie wyrabiasz.

Podczas wycen tasków niejednokrotnie zaznaczam, że nie jest to deadline tylko moja labelka którą daję, jako skomplikowanie taska.

Może za słabo estymujesz? Estymacje czasowe to trochę jak negocjacje finansowe - lepiej estymować z zapasem, żeby móc z czego schodzić. Jak myślisz, że coś ci zajmie 2 dni, to estymuj np. 5 dni itp. Wtedy jak się wyrobisz w 4 dni to i tak jesteś do przodu w stosunku do estymacji.

Robię rzetelnie od 9 do 17 bez żadnego obijania się.

Może w tym też leży problem. Tak intensywnie pracujesz, że nie masz czasu pomyśleć. Jest takie powiedzenie "work smart, not hard". Może nie kwestia tego, żeby jak najwięcej zapierxalać, ale kwestia tego, żeby umieć np. oddelegować część obowiązków do innych, część zautomatyzować, z części zrezygnować, część połączyć w całość (czasem kilka różnych tasków jest ze sobą w rzeczywistości powiązanych) itp. Iść zgodnie z duchem agile - starać się robić jak najmniej, a w dalszym ciągu dostarczać wartościowy soft.

Mam gości w zespole, bo jest nas piątka razem. 4 programistów + jeden Technical Project Manager. W zeszłym tygodniu wycenialiśmy taska i moje estymaty były zaniżane, a 3 gości Devów z którymi pracuję widzę że mają parcie na "karierę" bo robią w tej pracy bez opamiętania, mam tutaj na myśli że widzę że programują za free do projektu nie zgłaszając tego. W pewnym sensie sami sobie stwarzają presję.

Niestety tak to jest w "młodych dynamicznych teamach". Ale to może najlepiej zmienić team, gdzie nie będzie takich narwanych juniorów, którzy mają parcie na karierę (tzn. zakładam, że to są juniorzy, bo jak ktoś już ma ustabilizowaną pozycję zawodową i dobre zarobki, to po co ma się jeszcze ścigać? Przecież i tak nic nie osiągnie więcej).

Czy to już czas na przejście w jakieś role managerskie/kierownicze?

Do roli menedżerskiej/kierowniczej potrzebna jest dobra komunikacja, a z tego co piszesz, to już jako dev masz problem, żeby zakomunikować zespołowi, że taski są słabo wyestymowane i nie umiesz wybronić swojej pozycji albo poprosić (skutecznie) kogoś o pomoc. Więc możliwe, że byłbyś takim miękkim menedżerem, który daje sobie wejść na głowę i nie potrafi konkretnie wpłynąć na ludzi.

Tzn. nie mówię, żebyś się nie odnalazł w roli menedżerskiej, tylko zwracam uwagę na potencjalne problemy.

praca w scrumie

Bo "to nie był prawdziwy scrum" XD

norek111 napisał(a):

No i nie dowożę już taska któryś raz z kolei, zazwyczaj dowożę, ale w kolejnym Sprincie. Na pytanie dlaczego, mówię że nie ma czasu i pracuję 8h dziennie. Do tego w zespole jesteśmy wyoutsourcowani do firmy zewnętrznej jako zespół i robię jako BA po części z tamtejszym Product Ownerem, także tak jakby nie robię u siebie.

ja tu widzę przyczynę problemów, firma zewnętrzna, czuli Twoja firma na jakość pracy ma wywalone

Dziwne, mnie nigdy nikt nie spytał, jak task nie dowieziony "czemu".

wszystko w temacie

Masz tu kilka zagadnień:
a) team - estymacje, zaniżanie, praca za free, tempo, weryfikacja jakości
b) wiek i rodzina a szkolenia
c) przyszłość w zawodzie

Ad a.
Wygląda jakbyś pracował na akord. Outsourcing? Jeśli liczy się liczba ticketów / sprint bez analizy co jest w środku to prawdopodobnie jest to właśnie kołchoz do którego mało kto pasuje.
Jeśli młode wilki chcą się wykazać to daj im szansę (niekoniecznie musisz się temu przyglądać).
Downsizing to popularny antypattern skrama.

Ad b.

Zaznaczę też że mam rodzinę, po pracy się dokształcać nie zamierzam, 4 dzieci

No to masz do wyboru:

• pracować w stale tej samej technologii (z doświadczenia polecam COBOLa - tam się mało zmienia)
• dokształcać się w czasie pracy
• zmienić robotę na nietechniczną - na niewymagającą dokształcania (managier, kolekcjoner wymagań, sprzedawca, praca biurowa, spawanie, piekarnictwo)

Ad c.
"dokształcać nie zamierzam" - w dłuższej perspektywie - ok. 10 lat - powinieneś zaplanować wyjście z zawodu (chyba że jednak weźmiesz się za technologie "nieumarłe" jak COBOL) gdyż mniej więcej po tym czasie technologie są zastępowane całkowicie przez coś nowego i wymagane jest dogłębne dokształcenie się by być nadal w zawodzie. Możesz się kształcić codziennie albo tylko w momencie gdy chcesz zmienić pracę. Przy tym drugim podejściu zależnie od zaległości będziesz potrzebował nawet roku żeby nadgonić rynek.
Java pod tym względem jest jednym z najgorszych wyborów, masa frameworków, tooli, wzorców, podejść (reactive, functional, cloud), kierunków (JEE, Spring, Nieee Spring), kupa nauki i ciągle coś dochodzi nowego.

Każdy mówi, że kołchoz, a tak naprawdę wszędzie jeśli nie dowiezie się tasków w sprincie, to są pytania "Czemu". Tylko zamiast dziwnych odpowiedzi w stylu że pracuję 8h dziennie, wystarczą odpowiedzi, że coś zeszło dłużej, nastąpiły nieprzewidziane problemy itd.

Pinek napisał(a):

Każdy mówi, że kołchoz, a tak naprawdę wszędzie jeśli nie dowiezie się tasków w sprincie, to są pytania "Czemu". Tylko zamiast dziwnych odpowiedzi w stylu że pracuję 8h dziennie, wystarczą odpowiedzi, że coś zeszło dłużej, nastąpiły nieprzewidziane problemy itd.

Nie pamiętam, żebym musiał się z czegoś tłumaczyć, a odkąd pamiętam w sprintach dowozi się w porywach połowę tasków. Kwestia przyzwyczajenia (managementu).

norek111 napisał(a):

w praktyce w ostatnim czasy one-man-army (pisanie kodu, stawianie ci/cd, devops/ zbieranie wymagań, rozmowy z biznesem, praca w scrumie).

Normalna część pracy programisty.

Od stycznia zacząłem nowy projekt i widzę że sytuacja zaczyna się powtarzać. Estymaty zaniżane, presja na zamykanie tasków, sporo spotkań Scrumowych, a robić nie ma kiedy.

Co to znaczy "Estymaty zaniżane"? Zespół musi dojść do porozumienia co do wycena taska. A nie, Ty "20h", ktoś "5h" i krakowskim targiem wpisujecie "10h"

i że widzę że programują za free do projektu nie zgłaszając tego. W pewnym sensie sami sobie stwarzają presję.

Uświadom ich, że za frajer się nie pracuje. Jak to nic nie da to zmień robotę.

BTW Mając 10 lat doświadczenia powinieneś wiedzieć jak się zachować :P

Ja mam duze doswiadczenie i sprinty 2 tygodniowe i tygodniowe!!!! i 4 tygodniowe. Coby nie było backlog i plan na poczatku sprintu zawsze w pollwie sie zesral. A to cos dodac innego, a to koncepcja sie zmienia;. wiec jako szefu powiedzialem ok robimy roczny sprint :) i to bylo najlepsze wyjscie.

mechanix napisał(a):

norek111 napisał(a):

Od stycznia zacząłem nowy projekt i widzę że sytuacja zaczyna się powtarzać. Estymaty zaniżane, presja na zamykanie tasków, sporo spotkań Scrumowych, a robić nie ma kiedy.

Co to znaczy "Estymaty zaniżane"? Zespół musi dojść do porozumienia co do wycena taska. A nie, Ty "20h", ktoś "5h" i krakowskim targiem wpisujecie "10h"

a co sądzicie o takim podejściu by w ogóle nie estymować?
ufamy sobie wzajemnie, zakładamy, że każdy jest zmotywowany i każdy orze jak może.

a co sądzicie o takim podejściu by w ogóle nie estymować?
ufamy sobie wzajemnie, zakładamy, że każdy jest zmotywowany i każdy orze jak może.

@LitwinWileński: ale to nie rozwiązuje problemu dla którego powstały estymaty. Estymaty tworzą członkowie teamu i na ich podstawie klient czy tam menago może sobie wybrać co będzie się działo w sprincie. Np. jeśli w idealnym świecie mamy 3 taski: wprowadzenie nowego guzika (10p), zmiana koloru starego guzika na czerwony (5p) i poprawa buga w innych guziku (4p) a team jest w stanie zrobić (10p) to osoba planująca sprint może na podstawie tych liczb wybrać czy chce nowy guzik czy może chce poprawić dwa istniejące.

Oczywiście tak powinno być. Jak to działa w praktyce możemy empirycznie doświadczyć czytając tematy takie jak ten

@LitwinWileński:
Ogólnie, to założenie, że grupa zdrowych na umyśle, nieźle opłacanych ludzi zdaje sobie sprawę, że to co napiszą przekłada się na pieniądze i satysfakcję ze zrobionej pracy jest bardzo słuszne i bardzo rzadkie.
Co do samego szacowania pracochłonności, ma ono dla mnie zupełnie inną wartość niż wiedza "na kiedy będzie". Jeżeli zespół jest w stanie podzielić jakąś funkcjonalność na historyjki i wycenić te historyjki w czymkolwiek, to dla mnie oznacza to tylko tyle, że wiadomo co trzeba zrobić i z grubsza jak. Czas jest zawsze bardzo niepewny, bo zadanie, które wydawało się łatwe może się okazać straszną kupą, jak już ktoś zajrzy w ten kod i dojdzie do wniosku, że najpierw to trzeba 3 miesiące poświęcić na refaktor kawałka systemu. W aktualnym projekcie rozwiązujemy to w ten sposób (gram architekta i próbuję PO), że pytany przez "biznes" o pracochłonność daję bardzo bezpieczne wartości nie konsultując się z zespołem. Po planowaniu, już z zespołem dajemy bardziej sensowne estymaty + "obiecujemy" tylko i wyłącznie rzeczy, które będzie można na 100% dowieźć, oczywiście jeżeli nic nie wybuchnie. Cała reszta, w tym jakiekolwiek zadania zależne od wkładu z zewnątrz dostają labelkę "postaramy się".
Pracujemy trochę wg. Kanban, trochę wg. Scrum :D
Ogólnie backlog jest zorganizowany wg. kolejności zadań do wykonania, sprinty nie istnieją. Raz na 6 tygodni (czyli PI wg. SAFe) robimy sobie planowanie i parę innych ceremonii, żeby upewnić się, że praca na kolejne 6 tygodni jest przygotowana zrozumiana itd. Wtedy faktycznie story pointy są jakąś tam pomocą w odpowiedzi na pytanie "co się zmieści". W zależności od rodzaju zadań taka zabawa zajmuje 4h do jednego dnia.
Przy okazji taka 6 tygodniowa kadencja jest dość dobrym sygnałem do przeprowadzenia np. retro i ustalenia, że trzeba się w najbliższym czasie np. zabrać za testy, poprawę pipeline itp. czyli ogólnie przegadanie rzeczy, na które właściwie nie ma czasu w trakcie normalnej pracy, a warto je okresowo zrobić.
Jeżeli trafia się coś nagłego, typu "trzeba zrobić X", "system padł" itp. to przegadujemy historyjkę "na szybko" w trakcie, wstawiamy na górę backlogu i informujemy "biznes", że plan poszedł się walić bo coś się stało.

Pracowałem kiedyś w podobnym klimacie jeżeli chodzi o estymowanie tasków. Tylko jeszcze lepiej że taski były estymowane czasowo. No miałem takich młodych gniewnych którzy na scrum pokerze jeszcze zanim doczytali do końca już dawali 15 minut na zadanie :) . Ja dawałem przykładowo 1h-2h na to samo zadanie (czasy tylko przykładowe). No potem 3 do 1 czemu ja daje takie wysokie estymaty. No to mówię że w 15 min to nawet nie przygotujesz poprawnie MR tak żeby chociaż samemu przetestować, zrobić jakiś rebase jak masz kilka commitów itd.... Ale oczywiście wychodziło na to że to mi się robić nie chce. Nie ważne było że żadne zadania nie były dowożone w terminie. Był to pretekst do kolejnego awaryjnego spotkania dla PM'a pod tytułem "co można zrobić aby dowozić na czas" :) . A już wisienką na torcie było jak mieliśmy w zespole taką jakby specjalizację, czyli wiadomo że jeden przeważnie zajmuje się tym, drugi tamtym. I mamy wycenę i gość który na 100% wie że danego taska nie będzie robił daje estymację 5 minut a jak dostaje pierdołę którą wie że on będzie robił to zaczyna opowiadania jakie to skomplikowane, ile to czasu zajmie itd... No stwierdziłem że ja z tego statku wysiadam. Jak się okazało bardzo dobrze bo statek już był dziurawy a projekt za jakiś czas poszedł na dno. Teraz to pierwsza rzecz jaką oceniam w nowej firmie, nazwijmy to "kulturą wyceny tasków".

espe napisał(a):

Pracowałem kiedyś w podobnym klimacie jeżeli chodzi o estymowanie tasków. Tylko jeszcze lepiej że taski były estymowane czasowo. No miałem takich młodych gniewnych którzy na scrum pokerze jeszcze zanim doczytali do końca już dawali 15 minut na zadanie :)

Estymacje 15 minutowe kompletnie nie mają sensu. Jak coś wydaje się, że zajmie 15 minut, to lepiej estymować np. godzinę (wystarczą jakieś drobne problemy i z 15 minut zrobi się godzina).

. Ja dawałem przykładowo 1h-2h na to samo zadanie (czasy tylko przykładowe).

No potem 3 do 1 czemu ja daje takie wysokie estymaty. No to mówię że w 15 min to nawet nie przygotujesz poprawnie MR tak żeby chociaż samemu przetestować, zrobić jakiś rebase jak masz kilka commitów itd.... Ale oczywiście wychodziło na to że to mi się robić nie chce.

Zabawne jest, że nawet jeśli twoi współpracownicy mieliby rację w estymatach (i taski faktycznie byłyby takie proste, że zajmowałyby 5 czy 15 minut), to znaczyłoby, że te spotkania to straszna strata czasu. Dzień pracy ma 8 godzin (co prawda tylko teoretycznie, ale the point stands), więc jak estymujecie 15 minutowe taski, to jednego dnia estymujecie 32 taski? To chyba więcej czasu estymujecie niż pracujecie :D W takim układzie należałoby raczej połączyć wiele małych 15 minutowych tasków w jeden większy, żeby móc estymować od razu większy task.

Jeśli mieliby rację. Ale z tego, co piszesz, to po prostu są to niedoświadczeni programiści, którzy estymują zbyt optymistycznie, szczególnie rzeczy, które będzie robić ktoś inny.

Praktycznie zerowe bezrobocie, pracodawcy biora kazdego kto odrozna CLI od GUI a jak znasz angielski to zarobki * 4 #pdk
Nie rob tego sobie! No i -:-:-:-RUN-:-:-:-

Kurcze to ja doświadczam czegoś zupełnie innego niż OP. Na programistów w ogóle nie nakłada się ograniczeń czasowych, mało się kontroluje ich pracę - zdarzało mi się nawet pracować w firmach, gdzie nie logowało się czasu pracy. Pracodawcy boją się w ogóle kontrolować czy wyciągać konsekwencje bo rekrutację są trudne, wdrożenie do złożonego projektu trwa itp.

Wydawaloby by się, że sielanka, ale przesada w żadną stronę nie jest dobra. Takie podejście kończy się tym, że projekt ciągną 1-2 osoby, a reszta się opierdziela. Z czasem pojawiają się problemy z biznesem i nagle rzucamy wszystko standardy aby docisnąć projekt kolanem i na końcu wszyscy są zdemotywowani.

Moim zdaniem wycena w SP + logowanie czasu na taski w celach analitycznych jest najlepszym podejściem.

Swoją drogą to kolejny podobny post - odnoszę wrażenie, że w 80% takich historii pojawia się Java. Może za duży wyścig szczurów w tej technologii i warto rozważyć zmianę na coś innego?