a jak zadanie wyestymujesz na 10h i zrobisz w 8h lub po prostu twój menago będzie widział że pchasz projekt do przodu (domykasz swoje rzeczy) i sobie w excelu zapisze, to to już nie wystarczy? (just kiddin troche)
oczywiście możesz nakłamać z estymacją, ale to chyba w obu ""systemach""? zresztą chyba ktoś też weryfikuje twoje estymaty (w miarę rozsądku)
@WeiXiao: nie rozumiesz managerów. Oni kochają bezsensowne numerki.
My programiści też.
Jak tylko widzimy, że od sp zależą premie to namawamy zespół do zwiększania estymat.
Wszyscy będą zadowoleni: programiści dostają bonusy, menadżerowie dostają bonusy (bo zepoły dostarczyły więcej sp). Win/win.
Acha, tak, przećwiczyłem to. Nawet się specjalnie ze strategią nie kryłem.
@WeiXiao: O nadzwyczajną, niezauważoną wydajność pytaj manago który zazwyczaj niedowidzi ;)
Albo rób swoje w wyznaczonym czasie i dowoź na czas - i oglądaj koty ;)
Niezbadane są - bo obarczone subiektywnym czynnikiem sympatii/antypatii - werdykty przełożonych
BraVolt napisał(a):
Ciężko o posadę juniora?
Z pretensjami o ciężko o posadę juniora po bootcampie nich uderzają do kierownika bootcampu.
Już od roku na grupach na fejsie nie tylko deklarują się pracować od poniedziałku do niedzieli ale nawet chcą pracować rok za darmo.
Jednak do "wbicia w branżę" to im nie daje.Disclaimer
Nie dotyczy game-dev i web-dev
To z czego mają iść do pracy w IT, KUL czy wyższej szkoły morskiej ? Ja się załapałem na robotę po studiach humanistycznych, po samodzielnym poduczeniu. Obecnie pewnie moje cv automatycznie wylądowałoby w koszu. Dzisiaj firmy wybrzydzają bo jest nadmiar juniorów i takie są fakty.
Czulu napisał(a):
Ja się załapałem na robotę po studiach humanistycznych, po samodzielnym poduczeniu.
I bardzo dobrze, uczyłeś się więc zaprocentowało.
Natomiast
Obecnie pewnie moje cv automatycznie wylądowałoby w koszu.
i takie są fakty.
Piszesz to tak, jakby to była moja wina, bo tak piszę. Takiej mocy sprawczej nie ma ani Ojciec Dyrektor ani Ojciec Naczelnik.
Generalnie nikt nie zadał pytania jak są zatrudnieni Ci ludzie. UoP to UoP, nie wolno robić nadgodzin dobrowolnie. Szef jeśli ma jakąś wyobraźnię i życiowe doświadczenie powinien wiedzieć, że taki pracownik nawet jeśli sam się na razie zgadza na to, to na koniec może np. wytoczyć firmie proces. Szczególnie jeśli będzie np. zwolniony za jakiś błąd/niedopatrzenie/naganę. To popsuje wizerunek firmy, narazi ją na konsekwencje prawne i finansowe. Nawet jeśli są jakieś systemy monitoringu czasu to rutynowa kontrola może komuś z kadry kierowniczej popsuć humor.
Jeśli natomiast ludzie są zatrudnieni na B2B i w ramach jakiejś tam umowy o współpracę coś ustalili, to ok. Skąd wiadomo jaką umowę ma dany człowiek? Może jednak mu za to jakoś płacą, albo w drugą stronę - ma karę za niedotrzymanie jakiegoś terminu. Różnie bywa.
Do Opa - menager to menager, może mieć zadaniowy czas pracy. Ale tego kolegę to weźcie na browara, od promila w górę wyłóżcie swoje racje, że robi Wam pod górę i jeśli będzie tak dalej robił to na wszystkich się to źle odbije.
Sam pracując na UoP nie raz zrobiłem troszkę nadgodzin jako programista, żeby dowieźć coś na czas (nie uważam się za wymiatacza). Inaczej jak ja bym się nie wyrobił, a termin był nie ubłagany to inni musieli by to robić i de facto zadowoleni by nie byli.
No dobra, ale skoro oni pracują tyle, bo to ich pasja, to to nie są nadgodziny tylko czas spędzony nad hobby.
Niech tylko uważają z tą pasja, aby nie skończyli jak bohater filmu Gibsona pod tym tytułem. ;)
powiedział mi, że Java to jego pasja i że sprawia mu to przyjemność
Psychol jakiś, radzę trzymać się od niego z daleka.
@Marcys32 Mam podobną sytuację, którą opisałem tutaj: Kiedy zespoły zaczynają się kanibalizować Widziałem nawet, że się wypowiedziałeś w moim wątku. Postaram się zrobić mały update tego co udało mi się od tamtego czasu poprawić i co mi w tym pomogło.
Szanuję @jarekr000000 za dzielenie się techniczną wiedzą, natomiast osobiście uważam to co pisze na temat agile'a za szkodliwe. Z tego co pamiętam, kiedyś w jednym wątku napisał, że jednym z jego sukcesów na retrospektywach było zlikwidowanie retrospektyw. Z mojego doświadczenia retrospektywy są właśnie narzędziem walki z patologiami. Przez ponad pół roku zgłaszałem swoje uwagi opisane w poprzednim temacie, między innymi to, że część zespołu pracuje w weekendy i kluczowe zmiany kodu są przepychane w bardzo słabej jakości bez żadnego review w weekendy, ale też kilka innych rzeczy. Kiedy miarka się przebrała, porozmawiałem z kilkoma osobami z którymi przez cały ten okres omawiałem te rzeczy. Następnie opisałem konkretne przypadki i zaraportowałem to do szefa osoby, która wpływała tak patologicznie na część zespołu. Szefowie tamtej osoby czytali nasze retrospektywy i przyznali mi rację. Tamta osoba została persona non grata w naszym zespole, a ja tylko umocniłem swoją pozycję.
W moim wątku większość osób mówiło, że jedynym rozwiązaniem jest zmiana pracy. Wydaje mi się, że wiele osób celowo odwraca głowę w takich sytuacjach bo boi się konfrontacji. W rzeczywistości rozsądnej firmie zależy na tym, żeby miała dobrą opinię i nie będzie tolerowała patologii. Są też firmy, które nastawione są tylko i wyłącznie na zysk i tam nikt nie liczy się z tym czy opinia firmy jest dobra bo jeżeli wypłyną brudy to firma krzak się po prostu zwinie. Ja swoją obronę przygotowywałem przez prawie rok i wyciągnąłem swoje działa w odpowiednim momencie po odpowiednim rozeznaniu. Twoja sytuacja może być inna, ale obrona zawsze jest podobna. Musisz najpierw przygotować sobie grunt, tzn. zacząć rozmawiać o konkretnych problemach.
Wszyscy będą zadowoleni: programiści dostają bonusy, menadżerowie dostają bonusy (bo zepoły dostarczyły więcej sp). Win/win.
@jarekr000000 Raczej lose/lose i niezrozumienie tego do czego służą estymaty. Estymaty nie są dla programistów tylko dla managerów. Jedyne co powinien robić programista to estymować zadania zgodnie z prawdą, obowiązującą skalą i metodologią. Jeden zespół zrobi 200 sp w sprincie, drugi 20. To nie znaczy, że ten co robi 200 jest lepszy. Każdy zespół ustala własną skalę według której szacuje zadania. Te szacunki są właśnie po to, żeby product owner w trakcie sezonu urlopowego był w stanie oszacować ile zespół jest w stanie dostarczyć i żeby później product owner mógł powiedzieć, że zostało dowiezione wszystko co zostało zadeklarowane. To jest właśnie zarządzanie. Jeżeli product owner wymusza na zespole zrobienie większej ilości story pointów niż wynika to z prędkości zespołu to po prostu zespół tego fizycznie nie jest w stanie dowieźć bez nadgodzin. Nadgodziny są dodatkowym kosztem w budżecie projektu i ktoś odpowie za ten koszt. Jeżeli programiści robią bezpłatne nadgodziny, że dostarczyć wymuszone przez product ownera zadania to znaczy, że ktoś tutaj nie umie zarządzać.
@jarekr000000: Sama prawda
Pracowałem kiedyś w zespole mieszanym, międzynarodowym
Koledzy z zagranicy estymowali wyżej, ale dostarczali mniejwartości biznesowej, nie mówię, że dużo mniej, może 70-80 procent tego co my
kto zbierał opierdziel - no my, bo myło mniej SP w papierach
ba nawet były specjalne spotkania czemu tak i co zamierzamy z tym zrobić
stara prawda znów wyszła na wierzch, że uczciwą robotą to garba można się tylko dorobić :)
U mnie retrospektywy to i tak zazwyczaj była strata czasu.
Ponarzekałem sobie na ludzi nie piszących testów, na niską jakość kodu, na brak czasu na refaktoring, na brak konkretnych wymagań biznesowych, na chaos i burdel.
I tak co 2 tygodnie w koło na nowo, bez żadnych efektów, poza planowaniem zmian i nigdy nie wcielaniem ich w życie, bo sprint obładowany po brzegi :)
I tak każdy manago/lider przelicza SP na dupogodziny.
twoj_stary_pijany napisał(a):
Szanuję @jarekr000000 za dzielenie się techniczną wiedzą, natomiast osobiście uważam to co pisze na temat agile'a za szkodliwe.
Hmm, ale on tu przecież pisał o scrumie, a nie o agile. Scrum jest anty-agile w swojej idei i założeniach.
Z tego co pamiętam, kiedyś w jednym wątku napisał, że jednym z jego sukcesów na retrospektywach było zlikwidowanie retrospektyw. Z mojego doświadczenia retrospektywy są właśnie narzędziem walki z patologiami.
Konieczność czekania dwóch tygodni na zaproponowanie zlikwidowanie patologii, to patologia sama w sobie.
Estymaty nie są dla programistów tylko dla managerów.
A mimo tego, częściej rozumieją je programiści niż managerowie, którzy po prostu przeliczają SP na MD według swojego widzimisię.
I tak co 2 tygodnie w koło na nowo, bez żadnych efektów, poza planowaniem zmian i nigdy nie wcielaniem ich w życie, bo sprint obładowany po brzegi :)
@urke Ok, a jakie mieliście action itemy po tych retrospektywach? I do kogo action itemy były przypisane? I czy narzekałeś na retrospektywach na brak konkretnych akcji po retrospektywach?
I tak każdy manago/lider przelicza SP na dupogodziny.
A mimo tego, częściej rozumieją je programiści niż managerowie, którzy po prostu przeliczają SP na MD według swojego widzimisię.
@urke @somekind Czyli po prostu managerowie są niekompetentni i nie rozumieją czym są story pointy i może powinniście dokładnie przedyskutować to w jaki sposób mierzony jest performance zespołu. Jeżeli przeliczacie performance programistów na man days to macie wyścig szczurów. Właśnie przypomniałeś mi jaką patologię miałem w jednym startupie w którym kiedyś pracowałem. Moi koledzy ze zespołu estymowali taski po man day i jeden gość estymował coś na dwa tygodnie i robił coś 3 tygodnie i dalej były błędy. Ja wyestymowałem jedną rzecz na 3 tygodnie i zdeployowałem ją działającą w dwa tygodnie. Ja dostałem zjebę, że daję zbyt wysokie estymaty. Po tym jak powiedziałem, że dostarczyłem swoją rzecz na czas, a nie po czasie jak inni i czy miałem zamiast tego kłamać dostałem odpowiedź, że może powinienem. Nie muszę chyba mówić oczywistości, że kolega, który niedoszacowywał historyjki był wielkim przeciwnikiem wszelkiego rodzaju groomingów, retrospektyw i innych podobnych narzędzi.
Niestety szacowanie po MD jest zwykłym zgadywaniem kto da najbardziej prawdopodobną liczbę. Niestety taka liczba w 50% przypadków będzie niedoszacowana. Dobrą estymatą MD byłaby liczba dla której na 90% zmieścimy się w danym limicie czasowym i później obcinanie pensji osobie niedoszacowującej jeżeli więcej niż 10% historyjek jest niedoszacowana w sprincie. Może wtedy ludzie by się nauczyli czym jest rozkład Gaussa.
Dobremu product ownerowi powinno zależeć na tym, żeby historyjki były przeszacowane bo wtedy w oczach szefostwa będzie wyglądał na osobę rzetelną, która jeżeli raportuje, że programiści zrobią wszystko w sprincie to zawsze to dowiozą.
Przekornie powiem, że jeżeli wasi product ownerowie tego nie rozumieją to może powinniście zmienić pracę?
Dlatego często zmieniam :)
TL;DR Dla mnie patologią jest dąsanie się na kogoś kto pracuje tyle ile trzeba żeby osiągnąć cel.
Jedyne co widzę złego w tej historii to to wycenianie w story pointach i sugerowanie że ktoś się nie wyrabia.
Story point powinien określać uśrednioną pracochłonność dla przeciętnego członka zespołu.
Kto wyznacza te estymaty?
vpiotr napisał(a):
TL;DR Dla mnie patologią jest dąsanie się na kogoś kto pracuje tyle ile trzeba żeby osiągnąć cel.
OP pisze na wstępie, że zaczął jeden "pasjonat no-life", teraz jest toksyczna atmosfera w zespole. To jest patologia
a w story pointach to nie? xD Czaem idea SP nie jest taka, że można po jakimś czasie wyznaczyć velocity zespołu, czyli wiadomo ile SP zespół robi w czasie sprintu średnio. Właśnie po to zeby manager mógł przeliczać to na MD?
@Shalom nie. Story pointy nie mają związku z dniami. Zacznijmy w ogóle od tego, że szacowanie czegoś na MD to jest micromanagement. Co do tego, że micromanagement to jest patologia to chyba wszyscy się zgadzamy. Historyjka, która ma 2SP może zabierać nawet i 5 dni jeżeli tak są wyskalowane historyjki. Jeżeli jakaś historyjka zajmuje 13 SP to albo jest historyjka jest bardzo trudna, albo zajmuje dużo czasu, albo jest niejasna. W każdym z tych przypadków nie wyrobisz się z nią w jednym sprincie i musisz tę historyjkę przedyskutować z innymi. Dyskusja i rozbijanie historyjek na mniejsze, które mają jasne i konkretne artefakty do dostarczenia sprawiają, że co sprint dostarczasz jakieś działające rzeczy. Co do szacowania velocity, szacujesz prędkość w oparciu o statystyki z poprzednich sprintów. Jeżeli estymaty dla historyjek rosną i zespół dostarcza mniej SP w sprincie to znaczy, że historyjki są niejasne dla zespołu i winę za to ponoszą liderzy i product owner.
Całym sednem story pointów jest to, żeby historyjka miała na tyle mało story pointów, czyli była na tyle jasne i prosta, że w ciągu dwóch tygodni się z nią wyrobisz i żeby dostarczała działającą rzecz, a nie, że ktoś mówi, że dostarczył coś, ale nie zdążył przetestować. To znaczy, że nie dostarczył nic.
szacowanie czegoś na MD to jest micromanagement
Co? Przecież to ja/zespół estymuje, więc gdzie tu jest jakiś micromanagement?
Dyskusja i rozbijanie historyjek na mniejsze, które mają jasne i konkretne artefakty do dostarczenia sprawiają, że co sprint dostarczasz jakieś działające rzeczy.
Nie widzę żadnej wartości dodanej z przypisywania jakichś abstrakcyjnych story pointów żeby osiągnąć taki efekt. Jeśli przypisując magiczne punkty widzę że coś jest zbyt skomplikowane, to widzę też i bez tego. Punkty dodają tylko kolejny poziom abstrakcji zaciemniając sytuacje i rodzą problemy natury jak porównać X z Y.
Jeżeli estymaty dla historyjek rosną i zespół dostarcza mniej SP w sprincie to znaczy, że historyjki są niejasne dla zespołu i winę za to ponoszą liderzy i product owner.
Albo znaczy że zwyczajnie coś jest bardziej złożone.
żeby historyjka miała na tyle mało story pointów
Jakem żyw nigdy czegoś takiego nie widziałem. Moze w CRUDowniach faktycznie da się taki stan osiągnąć, szczególnie kiedy każde story to jest dodać nowe pole do tabelki, ale w innym przypadku bardzo trudno mi sobie to wyobrazić. Ale ja też jestem raczej wyznawcą ideologii http://programming-motherfucker.com/
a nie, że ktoś mówi, że dostarczył coś, ale nie zdążył przetestować
To jest kwestia wewnętrznego definition of "done" i z jakimś story pointami nie ma nic wspólnego.
Ok rozumiem że u ciebie w zespole koledzy nie potrafią bez przypisania punktów stwierdzić że coś jest zbyt skomplikowane. Ciekawi mnie jak w takim razie potrafią przypisać punkty...
@Shalom weźmy przykład. 5 devów szacuje historyjkę na kolejno: 3, 5, 5, 8, 13 punktów. Co z tego wynika? Trzech gości uważa, że historyjka jest relatywnie jasna, jeden gość uważa, że jest trudna bo coś tam, a trzeci gość wręcz uważa, że nie dość, że historyjka wydaje się trudna to jest wręcz niejasna. Podczas groomingu mówi np., że przez to, że historyjka jest dla niego niejasna podniósł estymatę. Pozostali koledzy, którzy dali np. 3, 5 i 5 zaczynają mu tłumaczyć historyjkę i wyjaśniać dlaczego jest prosta, ale podczas tłumaczenia zauważają, że np. brakuje w ich układance jakiegoś komponentu i mówią, że w sumie to nie jest takie proste jak początkowo zakładali więc można wydzielić coś jako osobną historyjkę lub też np. podnoszą swoje szacunki do 8. Ewentualnie po rozwianiu wątpliwości gościa, który dał 13, ten gość zmniejsza swój szacunek. Jeżeli nie ma konsensusu to znaczy, że PO musi lepiej opisać historyjkę, żeby było wiadomo co trzeba dokładnie zrobić.
No ale w takim razie mogę ci tylko współczuć zespołu :(
Ja mogę Ci tylko współczuć estymowania rzeczy po MD. Been there, done that. Rozdział 10. Mistrza czystego kodu pomoże Ci zrozumieć dlaczego błądzisz.
weźmy przykład. 5 devów szacuje historyjkę na kolejno: 3, 5, 5, 8, 13 punktów. Co z tego wynika? Trzech gości uważa, że historyjka jest relatywnie jasna, jeden gość uważa, że jest trudna bo coś tam, a trzeci gość wręcz uważa, że nie dość, że historyjka wydaje się trudna to jest wręcz niejasna. Podczas groomingu mówi np., że przez to, że historyjka jest dla niego niejasna podniósł estymatę. Pozostali koledzy, którzy dali np. 3, 5 i 5 zaczynają mu tłumaczyć historyjkę i wyjaśniać dlaczego jest prosta, ale podczas tłumaczenia zauważają, że np. brakuje w ich układance jakiegoś komponentu i mówią, że w sumie to nie jest takie proste jak początkowo zakładali więc można wydzielić coś jako osobną historyjkę lub też np. podnoszą swoje szacunki do 8. Ewentualnie po rozwianiu wątpliwości gościa, który dał 13, ten gość zmniejsza swój szacunek. Jeżeli nie ma konsensusu to znaczy, że PO musi lepiej opisać historyjkę, żeby było wiadomo co trzeba dokładnie zrobić.
i gdybyśmy zamiast story pointów wpisali godziny, to jaka różnica
3h 5h 5h 8h 13h
Marcys32 napisał(a):
Rozmawiałem z jednym i powiedział mi, że Java to jego pasja i że sprawia mu to przyjemność, więc robi za darmo.
Dla mnie programowanie to też pasja, dlatego po pracy to chcę sobie pokodować swoje projekty, poznać coś nowego na co w pracy nie ma czasu, a nie robić taski.
Marcys32 napisał(a):
Hej! Pracuję aktualnie w projekcie, gdzie Team-Leader pracuje miesięcznie po 200-250 godzin miesięcznie. (...) Do tego doszedł jeszcze jeden chłopak który także robi nadgodziny za darmo. (...) Wycenianie tasków na jak najmniejszą ilość story-pointów, a potem oczywiście niewyrabianie się i siedzenie po 12 godzin dziennie. (...) w zespole wytworzył się kult "zapier..."
Czy my nie pracujemy razem? ;)
@twoj_stary_pijany nigdzie nie napisałem że robie estymacje po MD. W ogóle takich nie robimy, bo nie ma to żadnego sensu.
Wyobraź sobie teraz tą swoją historię, tylko bez żadnych punktów. Siadamy zespołem, mamy ficzery wpisane do backloga zgodnie z priorytetami i zaczynamy dyskusje co da radę wejść do sprintu a co nie. Trafiamy na tą twoją konkretną historyjkę i robimy dyskusje z której jasno wynika, że niektórzy uważają że to dużo roboty a inni że mało. Robimy refinement, rozkładamy story na kawałki żeby było widać ile rzeczy jest do zrobienia, sortujemy backlog i wracamy do dyskusji z czym sie zmieścimy a z czym nie.
Nie były do tego potrzebne żadne punkty, godziny ani dni. Ale do tego trzeba znać swój zespół i wiedzieć ile jesteśmy w stanie zrobić w ciągu sprintu. Finalnie manager czy reszta zespołu i tak jest zainteresowana czasem, bo jak ktoś się mnie spyta kiedy skończe robić API z którym ma się integrować to oczekuje że powiem za 2 dni a nie 69 story pointów.
@WeiXiao: różnica jest taka, że w każdym z tych przypadków zakładasz, że historyjka nie będzie trwała dłużej niż 3h, 5h, 5h, 8h, 13h. Uśredniona wartość da około 5h. Teraz wyobraź sobie, że tę historyjkę bierze junior, a nie senior. I junior dostaje później baty bo robi historyjkę 10h. Ludzki mózg głupieje przy dużych liczbach. Jeżeli ktoś ukradł 100 zł to powiesz, że złodziej, jeżeli ktoś ukradł milion to powiesz, że biznesman. Tak samo, historyjki na 2 albo 3 tygodnie to jest absurd. Jak to jest niby wyliczone? Siedzenie na kiblu też się liczy? A to na pewno jest 120 godzin? A nie przypadkiem 119 godzin? Na pewno nie oszukujesz?
Story pointy z drugiej strony biorą pod uwagę przede wszystkich 3 czynniki: complexity, effort, uncertainty. Żadna z tych cech nie jest związana z czasem. Mógłbyś do każdej historyjki przypisywać 3 cechy i planowanie trwało by jeszcze dłużej. Natomiast jeżeli wszyscy estymują historyjki na małe liczby, np. 1, 2, 3, 5 to znaczy, że te historyjki są dobrze opisane, zajmują relatywnie mało czasu i ryzyko ich nieukończenia ze względu na różne czynniki jest niskie. I o tym w tym wszystkim wchodzi, żeby historyjki dało się skończyć w krótkim czasie.
Siadamy zespołem, mamy ficzery wpisane do backloga zgodnie z priorytetami i zaczynamy dyskusje co da radę wejść do sprintu a co nie.
@Shalom: ile razy to słyszałem jak jeden gość mówił za cały team "siadamy", "robimy". A jakiś chłopaczek w zespole bał się odezwać i nie przyznał się, że czegoś nie rozumie i później robił nadgodziny. Ja rozumiem, że biznes i zarabianie hajsu, ale bez przesady.
różnica jest taka, że w każdym z tych przypadków zakładasz, że historyjka nie będzie trwała dłużej niż 3h, 5h, 5h, 8h, 13h. Uśredniona wartość da około 5h
xD co? To jak macie story pointy to można siąść i przedyskutować czemu estymacje są różne a jak macie godziny to już nie można? Co to za fikołek logiczny?
ile razy to słyszałem jak jeden gość mówił za cały team "siadamy", "robimy". A jakiś chłopaczek w zespole bał się odezwać i nie przyznał się, że czegoś nie rozumie
No tak, przy dyskusji bez punktów boi się odezwać, ale z punktami się już nie boi. Trudno polemizować z taką logiką.
Jedyna różnica między SP a MD jest taka, ze SP pozwalają na uniknięcie estymowania. Bo jak się nie wyrobisz to najwyżej masz dupochron, że w tym sprincie mamy niższe velocity czy jakiś inny scrum-bełkot, a jak powiedziałeś ze coś będzie za 2 dni, to trzeba się przyznać, że coś poszło nie tak.
Historyjka, która ma 2SP może zabierać nawet i 5 dni jeżeli tak są wyskalowane historyjki. Jeżeli jakaś historyjka zajmuje 13 SP to albo jest historyjka jest bardzo trudna, albo zajmuje dużo czasu
Mam mindfuck jak czytam to zdanie. Skąd niby wiesz, że 13 SP to dużo - może tak są wyskalowanie historyjki, że 13 SP zajmuje 10 minut i nawet nie ma nad czym się pochylać...
Strzelam, że jak wszyscy prawie te sorry pointy jakie znasz to po prostu zakamuflowane osobodni, ale wszyscy się oszukujecie, że coś za tym ciekawszego stoi i sobie przeliczacie - żeby było zabawniej.
Jakby to były prawdziwe story pointsy (*) to byście mieli tablicę referencyjnych story, z której raczej dość szybko by wyszło jakie te punkty to nonsens.
(*) oczywiście prawdziwe story pointsy występują mniej więcej tak samo często jak prawdziwy komunizm, prawdziwe DDD czy inne patologie.
Finalnie manager czy reszta zespołu i tak jest zainteresowana czasem, bo jak ktoś się mnie spyta kiedy skończe robić API z którym ma się integrować to oczekuje że powiem za 2 dni a nie 69 story pointów.
@Shalom: zacznijmy od tego, że stakeholder jest zainteresowany ficzerem, a nie tym, że robisz jakąś historyjkę albo nie i ile ona zajmuje. Oni mają gdzieś kto i co robi. Płacą za ficzer. Na ten ficzer składa się często kilkanaście historyjek i nie interesuje ich to, że robisz go 12,5h czy może jeszcze w międzyczasie robisz cokolwiek innego. W scrumie cały zespół deklaruje, że dostarczy ileś historyjek w sprincie i np. ficzer w 3 sprinty. Nikogo nie interesuje Twój indywidualny performance oprócz Ciebie kiedy idziesz po podwyżkę. Jasne, możesz pracować w kilkuosobowych zespołach gdzie zgarniasz większość kasy za dany ficzer, ale wtedy też nikogo nie interesuje ile godzin pracujesz oprócz Ciebie kiedy musisz oszacować kiedy się wyrobisz i żeby Twoja stawka za godzinę była satysfakcjonująca.
Gdybyś mierzył to tak samo w większych zespołach to nagle by się okazało, że architekt, który nie robi konkretnych ficzerów tylko robi research i szkoli devów jest niepotrzebny w zespole bo nie dostarcza business value. To samo z refactoringiem, ale to jak go dobrze ukryć w sprincie to jest już następna historia.
to byście mieli tablicę referencyjnych story
@jarekr000000: mamy.
Storypointy służą głównie do tego, żeby założyć na programistów chomąto i orać nimi CRUDa :)
Już łatwiej by było rozdzielać zadania osobno i pytać się programistę ile mu to godzin/dni/tygodni może zająć, zamiast uśrednionej liczby przez zaniżających lizusów :)
( Ale wtedy trzeba mieć na papierze co trzeba zrobić zamiast 1 zdania z brudnopisu z belkotem prosto od Pani Jadzi z dzialu ksiegowosci :) )
Ale tak to by gorzej na papierze wyglądało, bo spotykałem się i z taką patologią, że klient wewnętrzny miał do rozdysponowania tasków za XY storypointów na sprint, a potem podczas wyceny leader/manago wręcz wymuszał na innych zaniżanie estymat - "Bo to już jest zrobione, wystarczy odkomentować", "Wystarczy przekopiować" i inne tego typu bzdury.
Ogólnie każdy system wyceny bez analizy/konkretnych wymagań implementacyjnych/biznesowych będzie się różnił czasem wykonania względem wyceny do kilkuset procent.
@Shalom @jarekr000000 @twoj_stary_pijany in inni ostatnie kilkadziesiąt postów o wyższości / niższości estymowania w SP / MD / w niczym z użyciem tabelek referencyjnych i bez powinny polecieć za kompletny Off-Topic, ale nawet nie chce mi się tego zgłaszać :] brakuje jeszcze dyskusji o wyższości Excela nad Jirą do śledzenia historyjek i sprintów
OP przytoczył słowa swojego TLa, który siedzi po te 200+ godzin w miesiącu bo Java to jego pasja, a nie bo nam menago przelicza SP na dupogodziny i muszę robić żeby zdążyć.
OP mówi o tym, że więcej ludzi siedzi po godzinach, a potem estymuje czy tam wrzuca do sprintu tyle, że najwyraźniej trzeba sobie uwzględnić robienie tych darmowych nadgodzin (bo oficjalnie nadgodzin w firmie nie ma).
Z opisu wynika, że taka sytuacja jest bardziej regułą niż wyjątkiem i trwa od jakiegoś czasu, więc mimo ułomności SP, scrumów i innych najwyraźniej zespół świetnie sobie radzi z estymowaniem, ile można zrobić w sprincie... Tylko że przy 60h tygodniu pracy :)
Dla rozluźnienia polecam naprawdę słabą piosenkę:
Można puszczać kolegom.
różnica jest taka, że w każdym z tych przypadków zakładasz, że historyjka nie będzie trwała dłużej niż 3h, 5h, 5h, 8h, 13h. Uśredniona wartość da około 5h. Teraz wyobraź sobie, że tę historyjkę bierze junior, a nie senior. I junior dostaje później baty bo robi historyjkę 10h. Ludzki mózg głupieje przy dużych liczbach. Jeżeli ktoś ukradł 100 zł to powiesz, że złodziej, jeżeli ktoś ukradł milion to powiesz, że biznesman. Tak samo, historyjki na 2 albo 3 tygodnie to jest absurd. Jak to jest niby wyliczone? Siedzenie na kiblu też się liczy? A to na pewno jest 120 godzin? A nie przypadkiem 119 godzin? Na pewno nie oszukujesz?
nie, nie zakładam że task NIE będzie trwał dłużej niż X, a to że raz na jakiś czas jakaś estymata wyjdzie okropnie źle (np. estymata 10h vs real 80h), to już po prostu życie, ale zmiana jednostki z godzin na zwierzątka 
nic tu nie zmieni.
Jeżeli masz story wycenione na 120h to przecież w tym story masz N tasków które składają się na te 120h i da się je już sensowniej ocenić czy zasadne czy nie