Semantyczne rozmycie terminów w informatyce i programowaniu, np. "product owner"

piotrpo napisał(a):

Zależy gdzie. Jeżeli nikt mi nie powie ile ten 1SP "powinien" zająć, sam tego nie policzę (bo po co), to dla mnie dalej jest to abstrakcja.

Jaki jest sens takiego estymowania?

Są zadania pracochłonne/skomplikowane i zadania szybkie/proste. Sam nie mam problemu z podaniem, że jakieś tam zadanie o którym nikt nie ma pojęcia, to te 13SP. Jednocześnie nie podałbym żadnego sensownego terminu, bo go nie znam. Mogę podać, że jakieś zadanie zajmie mi np. 2 dni, ale powyżej tej wartości zwyczajnie nie wiem czy to będą 3 dni, czy 3 tygodnie,

Czyli równie dobrze możesz podawać losowe wartości - skoro nie wiesz ile to zajmie i ile to jest 13 SP - skąd wiesz, ze 13, a nie 14? Wiesz, że 13, a nie 14 a nie wiesz czy 3 dni czy 3 tygodnie???

Jestem prostym chłopem, nie wierze w kosmitów i takie story pointsy - to się nie trzyma kupy nawet gdyby to obwiązać szarą taśmą.

WeiXiao napisał(a):

Ale sekunda, przecież estymuje ten, kto się bierze za daną pracę, prawda?

No jeśli tak miałoby być, to faktycznie żadne planowanie i estymowanie nie miałoby sensu. Na szczęście to nie jest prawda.

Przecież zastosowanie urojonej jednostki nie sprawia że nagle nie mamy różnicy w skillach pomiędzy pracownikami, halo.

Właśnie dzięki abstrakcyjnej jednostce te różnice się uśredniają (podobnie jak błędy estymowania i ryzyko).

Jedyny argument za SP jaki znam to taki, że w patologicznym środowisku działa jako dupochron, no ale nadal większym problemem jest patologiczne środowisko.

No tak, lepiej mieć niepatologiczne środowisko, w którym ludzie planują cały sprint co do godziny, a potem co każde dwa tygodnie dziwią się, że nie dowieźli.

jarekr000000 napisał(a):

Po prostu nieważne jakie reference stories, voodoo psychologiczne, agilowe copium czy co innego ludzie odwalają to SP zawsze stają się (najdalej po kilku sprintach) po prostu miarą czasu (tyle, że powaloną).

No nie wiem, u mnie w obecnej firmie działały latami. Dopiero jak psychopaci zatrzymani organizacyjnie w latach 90tych przejęli firmę, to wprowadzili nakaz estymowania w godzinach. Oczywiście nie działa - na szczęście nie ja się muszę tłumaczyć.

WeiXiao napisał(a):

To jest w ogóle największy hit i dziecinada - estymowanie w wyimaginowanych jednostkach, szkoda że jeszcze nie estymują w słoneczkach czy jabłuszkach :D

Wszystkie jednostki są wyimaginowane Nie ma tak że gdzieś na ziemi sobie leży amper, cal albo pascal i można go podnieść.

Poza tym @piotrpo ma rację. Właśnie o to chodziło, żeby członkowie zespołu przestali myśleć o estymacji w kontekście czasu.

Programiści w zespole wiedzą z grubsza/mniej więcej jak któreś zadanie jest trudne; oraz klientów którzy wiedzą mniej więcej jaki feature im się opłaca. Story Pointy miały być po to, żeby jako pierwsze zrobić zadania które mają największą wartość niskim kosztem. Nie jest to idealne rozwiązanie oczywiście, ale miało być lepsze niż po prostu brać je po kolei. Chodziło o to żeby zrobić ORDER BY task.rough_gain / task.rough_cost.

W podobnym stylu możnaby sobie wymyśli Feature-Pointy (copyright Riddle, właśnie to wymyśliłem), gdzie to klienci estymują zadaniom feature poinsty; a potem programiści robią te które są dla nich najłatwiejsze żeby dowieść ich jak najwięcej. Oczywiście to też byłoby używane źle, bo większość faux-agile firm robiłaby te taski które mają najwyższą FP, a nie te które mają dobry stosunek FP do trudności.

Swoją drogą, z punktu widzenia klienta najlepiej byłoby dostarczyć jak najmniej SP Bo to znaczy że najniższym kosztem dowieźli największą wartość. Jeśli jeden task ma 1SP (ale zarobi dla firmy $1mln.), a inny ma 10SP (ale zarobi tylko $10tys.) to oczywiście że bardziej się opłaca zrobić ten co ma 1SP. I właśnie tu jest ten problem że patrząć "ślepo" na SP, możemy dojść do wniosku że zespół który zrobił te 10SP przyniósł więcej wartości niż ten 1SP (co jest nie prawdą ofc).

jarekr000000 napisał(a):

Czyli równie dobrze możesz podawać losowe wartości - skoro nie wiesz ile to zajmie i ile to jest 13 SP - skąd wiesz, ze 13, a nie 14? Wiesz, że 13, a nie 14 a nie wiesz czy 3 dni czy 3 tygodnie???

Wyobraź sobie że pracujesz sam jeden nad projektem (0 klientów, 0 product managerów, brak szefa), jesteś tylko Ty i nikt więcej. Piszesz sobie swój prywatny projekt. Chcesz do niego dodać powiedzmy 20 super fajnych funkcji! Wiesz które z tych funkcji będą łatwe do dodania, które średnio-trudne a które bardzo proste.

I teraz o co chodzi w story pointach, to po prostu to żeby w jakiś prosty sposób powiedzieć komuś które są trudne, które są średnio trudne a które proste - i tyle. Nic więcej. Można użyć trudne|średnie|łatwe, można iśc liczbami, rozmiarami koszulek (large, medium, small), można iśc fibbonacim; ale w gruncie rzeczy chodzi o to samo.

Jeśli ktoś chciałby na podstawie takich trudności szacować czas to wiadomo że wyjdzie mu niedokładny wynik.

Problem polega właśnie na tym że jakiś mądrala product owner próbuje mierzyć "produktywność" zespołów story pointami, to się w ogóle mija z celem, one nie od tego są.

@jarekr000000 Szacunki, to tylko szacunki. Jak masz zadania polegające na kopaniu rowów, to będą dokładniejsze, jeżeli jakieś trudniejsze, to mniej dokładne i będziesz krążył pomiędzy błędami 10% a 500%. Nie ważne, czy będą to godziny pracy, czy będą to SP.
Natomiast SP jest jednostką, która dynamicznie zmienia swoje znaczenie, bo z jednej strony z każdym szacowaniem zespół ma bardziej wspólne rozumienie "ile to jest", a z każdym zrobionym zadaniem masz lepszą średnią historyczną, która chociaż częściowo przekłada się na przyszłość.
Chodzi tylko i wyłącznie o delikatnie lepsze wyniki niż gdybyś policzył średni czas implementowania historyjki w przeszłości i przełożył to na resztę backlogu.

I co najważniejsze - to tylko narzędzie. Jeżeli zespół ma potrzebę podania jakiejś prognozy, to może, ale nie musi go użyć. Zakładając, że pracujemy w agile i zgodnie z duchem tego podejścia to zespół wybiera sobie sposób w jaki pracuje i realizuje zewnętrzne wymagania.

somekind napisał(a):

Właśnie dzięki abstrakcyjnej jednostce te różnice się uśredniają (podobnie jak błędy estymowania i ryzyko).

Nie, stosowanie urojonej jednostki nie sprawia że część devów zyskuje skilla, a inna część traci :P

A tak na serio - jak i po co?

Masz 10x senior distinguished pryncypal inżyniera który jest w projekcie od początku i wszystko ogarnia i estymuje sobie np. 2, 6, 9 SP (latwe/srednie/trudne) i robi to średnio 2, 5, 8 dni.

I drugiej strony żuniora który rzuca 5 / 10 / 20 SP i robi je srednio 4, 8, 11 dni

I co nam z tego wychodzi? Jest tu jakaś użyteczna informacja? Dowieziesz ten kwartał czy jednak przejdą rzeczy na kolejny?

No tak, lepiej mieć niepatologiczne środowisko, w którym ludzie planują cały sprint co do godziny, a potem co każde dwa tygodnie dziwią się, że nie dowieźli.

Ani w januszeksach, ani w corpo sytuacje gdzie ktoś się dopomina o jakiś feature czy bug mógłbym policzyć na palcach jednej ręki.

Tak jak napisałem - jeżeli nie ma odpowiedniej kultury pracy, to ani SP, ani jabłuszka, ani estymacje co do sekundy nie zdziałają cudów :P

No nie wiem, u mnie w obecnej firmie działały latami. Dopiero jak psychopaci zatrzymani organizacyjnie w latach 90tych przejęli firmę, to wprowadzili nakaz estymowania w godzinach. Oczywiście nie działa - na szczęście nie ja się muszę tłumaczyć.

A w ilu firmach pracowałeś przez ostatnie 10 lat, i tak co najmniej rok, no bo w tydzień raczej ciężko ocenić czy dane podejście działa

WeiXiao napisał(a):

A tak na serio - jak i po co?

Po to, że jeśli ktoś wymaga od nas estymacji, to nie podamy mu w miarę trafnych estymacji w dniach ani godzinach, bo w tych jednostkach estymowanie na ogół nie wychodzi.

Masz 10x senior distinguished pryncypal inżyniera który jest w projekcie od początku i wszystko ogarnia i estymuje sobie np. 2, 6, 9 SP (latwe/srednie/trudne) i robi to średnio 2, 5, 8 dni.

I drugiej strony żuniora który rzuca 5 / 10 / 20 SP i robi je srednio 4, 8, 11 dni

I co nam z tego wychodzi? Jest tu jakaś użyteczna informacja? Dowieziesz ten kwartał czy jednak przejdą rzeczy na kolejny?

Z tego akurat nic nie wychodzi, ale to nie tak działa. Wychodzisz z błędnego założenia, że każdy estymuje sobie indywidualnie, co po prostu nie ma sensu w tym przypadku.

Tak jak napisałem - jeżeli nie ma odpowiedniej kultury pracy, to ani SP, ani jabłuszka, ani estymacje co do sekundy nie zdziałają cudów :P

Ale kto mówi, że zdziałają?
Są różne organizacje i różne tryby pracy, które mogą się w nich sprawdzić. SP to narzędzie, które może pasować gdzieś, a gdzieś indziej nie.

A w ilu firmach pracowałeś przez ostatnie 10 lat, i tak co najmniej rok, no bo w tydzień raczej ciężko ocenić czy dane podejście działa

W obecnej jestem 4,5 roku, w poprzedniej byłem niecałe 4, a w jeszcze poprzedniej niecałe 2.

@somekind

Po to, że jeśli ktoś wymaga od nas estymacji, to nie podamy mu w miarę trafnych estymacji w dniach ani godzinach, bo w tych jednostkach estymowanie na ogół nie wychodzi.

Z tym się nie zgadzam. Na "zewnątrz" wychodzą najczęściej zrozumiałe wyniki, w przydatnych "komuś" jednostkach.

Chyba cała ta dyskusja shodzi na jakieś boczne tory i zapominamy o celach (zupełnie jak w większości projektów).
Realna sytuacja, to biznes z pomysłem na biznes "zróbmy system IT, żeby sprzedawać produkt/usługę i zarabiać na tym ileś tam baniek rocznie. Na kiedy możecie to zrobić i ile to będzie kosztowało?

Tradycyjnie, siadał ktoś tam, robił listę rzeczy do zrobienia (WBS), przypisywał elementom jakieś tam wymyślone wartości w czasie pracy, PM kładł to na ganta, dzielił na etapy, planował zapotrzebowanie na pracę i jej rodzaj, a po upłynięciu 80-120% czasu przewidzianego na projekt i ze zużytym w całości budżetem na pytanie "how is the project?" przestawała wystarczać odpowiedź "fine".
Mierzenie postępu projektu, niby było możliwe, ale jak przychodziło co do czego, to okazywało się, że w kodzie zamiast funkcji biznesowych leciały skróty, czy wręcz komentarze TODO, FIXME itp. Skoro liczy się zamykanie kolejnych zadań w czasie i budżecie, to są zamykane w czasie i budżecie, a w chwili kiedy ktoś powie "sprawdzam", to i tak już będziemy w innych firmach.

Agile, w moim przekonaniu, opiera się na prostej prawdzie objawionej, że najszybszą drogą do zrobienia czegoś, jest zacząć to robić. Oczywiście jakieś wstępne szacunki nadal są potrzebne, bo trzeba sobie odpowiedzieć na pytanie czy projekt ma szansę się zwrócić i warto wiedzieć, czy zrobienie jakiegoś tam systemu będzie kosztowało 1, 10, czy 100 baniek.
W podejściu o którym ja piszę (i uważam za najbardziej skutecznie), zaczynamy robić ten system, nie koniecznie od razu pełnymi siłami i po powiedzmy miesiącu mamy coś zrobione. Czyli z sytuacji, w której mamy jedynie teoretyczne rozważania architekta/PM'a przechodzimy do takiej, w której mamy już działające coś, wiemy ile to zajęło czasu i ile kosztowało.
W tym momencie przydają się szacunki, bo jeżeli oszacowaliśmy tę już gotową część pracy i mamy oszacowaną całość, to prosta matematyka pozwala powiedzieć, ze w miesiąc udało się zrobić 3% planowanego rozwiązania. Kosztowało to powiedzmy 300k, więc aktualna wiedza jest taka, że przy obecnym zespole, wymaganiach i sposobie pracy, całość systemu zajmie 34 miesiące i będzie kosztować 10 baniek.
Po kolejnym miesiącu mamy kolejne ukończone funkcje, może coś się zmieniło w backlogu i według tej nowszej wiedzy znowu jesteśmy znowu w stanie wykonać kilka prostych obliczeń i podać zaktualizowane prognozy ukończenia projektu i kosztu.
O ile tradycyjne podejście, opiera się na planie wyrytym w kamieniu i PM, który goni wszystkich, żeby się w ten wyciągnięty z tyłka plan wpasowali, to zwinność odwraca tę zależność. Nie zapierniczamy, żeby powiesić bombki na choince przed świętami, tylko staramy się przewidzieć kiedy te święta należy zorganizować. jeżeli faktycznie są jakieś sztywne daty, to możliwe, że zdecydujemy się ograniczyć liczbę bombek, albo zastąpimy je lampkami, albo nawet stwierdzimy, że to nie ma sensu i w tym roku świąt nie będzie.

@somekind

Po to, że jeśli ktoś wymaga od nas estymacji, to nie podamy mu w miarę trafnych estymacji w dniach ani godzinach, bo w tych jednostkach estymowanie na ogół nie wychodzi.

Ale wy mu w ogóle żadnej sensownej estymaty nie dacie, a dacie jedynie potencjalną złożoność z którą co zrobi? nałoży średni czas dla danej złożoności i dostanie naiwna estymate? :D

A biznes jak wspomniałem wyżej operuje na kwartałach, raportach finansowych, planach wydawnicznych, road mapach, okazjach typu summer sale, winter sale, holidays, back to school, etc etc.

Z tego akurat nic nie wychodzi, ale to nie tak działa. Wychodzisz z błędnego założenia, że każdy estymuje sobie indywidualnie, co po prostu nie ma sensu w tym przypadku.

No to kto estymuje?

WeiXiao napisał(a):

Ale wy mu w ogóle żadnej sensownej estymaty nie dacie, a dacie jedynie potencjalną złożoność z którą co zrobi? nałoży średni czas dla danej złożoności i dostanie naiwna estymate? :D

Wiedząc ile realnie jesteśmy w stanie wykonać, wiedząc ile jest do zrobienia, możemy sensownie przewidzieć na kiedy coś dowieziemy.
Na tyle sensownie, że przez ponad 4 lata spóźniliśmy się 2 razy.
Mam porównanie z ludźmi, którzy estymują w dniach, i płaczą (także na tym forum), że nigdy nie dowożą.

A biznes jak wspomniałem wyżej operuje na kwartałach, raportach finansowych, planach wydawnicznych, road mapach, okazjach typu summer sale, winter sale, holidays, back to school, etc etc.

Owszem, ale jaki to ma związek?

No to kto estymuje?

W pracy zespołowej - zespół.

piotrpo napisał(a):

Z tym się nie zgadzam. Na "zewnątrz" wychodzą najczęściej zrozumiałe wyniki, w przydatnych "komuś" jednostkach.

Biznesu nie obchodzą godziny ani dni., na zewnątrz wychodzi wynik w postaci dwutygodniowego okresu, w którym coś zostanie dostarczone.

somekind napisał(a):

Biznesu nie obchodzą godziny ani dni., na zewnątrz wychodzi wynik w postaci dwutygodniowego okresu, w którym coś zostanie dostarczone.

Czym jest biznes? I tak w ogóle to czemu opisujesz typowy just-in-time gdzie wszystko musi płynąć bo jak nie to mamy kryzys globalny i wojny?

loza_prowizoryczna napisał(a):

Czym jest biznes?

Nie wiem jak to wytłumaczyć bezrobotnemu, ale spróbuję - to tacy ludzie, którzy płacą komuś za to, że coś dla nich wykona.

I tak w ogóle to czemu opisujesz typowy just-in-time gdzie wszystko musi płynąć bo jak nie to mamy kryzys globalny i wojny?

Nie wiem, nie piłem alkoholu od dwóch tygodni.

somekind napisał(a):

Nie wiem jak to wytłumaczyć bezrobotnemu, ale spróbuję - to tacy ludzie, którzy płacą komuś za to, że coś dla nich wykona.

To nie biznes, to są klienci.

Nie wiem, nie piłem alkoholu od dwóch tygodni.

Trzeba było od razu, syndrom odstawienia daje wtedy najgorsze objawy, trzymam kciuki że tym razem ci się uda.

somekind napisał(a):

Wiedząc ile realnie jesteśmy w stanie wykonać, wiedząc ile jest do zrobienia, możemy sensownie przewidzieć na kiedy coś dowieziemy.
Na tyle sensownie, że przez ponad 4 lata spóźniliśmy się 2 razy.
Mam porównanie z ludźmi, którzy estymują w dniach, i płaczą (także na tym forum), że nigdy nie dowożą.

Przecież nie wiesz ile jesteś w stanie realnie wykonać i dlatego robisz estymate, a na dodatek z jakąś warstwą dupochronową w postaci SP :D :D

Mam porównanie z ludźmi, którzy estymują w dniach, i płaczą (także na tym forum), że nigdy nie dowożą.

I sugerujesz że gdyby zaczęli stosować SP to nagle ich estymaty byłyby rzetelne?

Ciężko mi w to uwierzyć, serio.

Na tyle sensownie, że przez ponad 4 lata spóźniliśmy się 2 razy.

Powodów może być wiele:

Może jesteście utalentowani,
Może klepiecie króda,
Może mocno przeszacowujecie zadania,
Może ciągle robicie podobne rzeczy i setne dodanie buttona ciężko źle oszacować,
Może macie niskie attrition w zespole,
Może macie wybitnych reviewerów,
Może macie dobry zespół od QA/walidacji/testerów/whatever

A biznes jak wspomniałem wyżej operuje na kwartałach, raportach finansowych, planach wydawnicznych, road mapach, okazjach typu summer sale, winter sale, holidays, back to school, etc etc.

Pytasz jaki związek mają roadmapy i plany wydawnicze z oceną inżynierów nt. tego, czy dany scope jest do dowiezienia?

No taki, jak już pisałem w tym wątku - wiarygodność jest ogromnie istotna, szczególnie w biznesie, i jeżeli będziesz obiecywał cuda, a później się nie wyrabiał to cie (biznes) zjedzą na spotkaniu z inwestorami/radą nadzorczą i może będziesz mieć problem aby pozyskać finansowanie <lol>

W pracy zespołowej - zespół.

Robicie sobie brainstorming w np. 10 osób i np. patrzycie zadanie "ABC - dodaj button dupa" i każdy przydziela ile tam widzi SP do tego i bierzecie średnią?

WeiXiao napisał(a):

Przecież nie wiesz ile jesteś w stanie realnie wykonać i dlatego robisz estymate, a na dodatek z jakąś warstwą dupochronową w postaci SP :D :D

No i?

I sugerujesz że gdyby zaczęli stosować SP to nagle ich estymaty byłyby rzetelne?

Nie, bo oni by pewnie uznali, że jeden SP = 1 dzień i dalej robili tak samo.

Powodów może być wiele:

Może jesteście utalentowani,
Może klepiecie króda,
Może mocno przeszacowujecie zadania,
Może ciągle robicie podobne rzeczy i setne dodanie buttona ciężko źle oszacować,
Może macie niskie attrition w zespole,
Może macie wybitnych reviewerów,
Może macie dobry zespół od QA/walidacji/testerów/whatever

Nie mamy cruda, przycisków ani testerów.
Po prostu w przeciwieństwie do fanatyków estymacji w jednostkach czasu nie planujemy sprintu co do godziny, dzięki czemu niespodziewane problemy albo oczywiste czynności nie rozwalają całego planu.

Pytasz jaki związek mają roadmapy i plany wydawnicze z oceną inżynierów nt. tego, czy dany scope jest do dowiezienia?

No więc nasze oceny są trafne.
Biznes jest dziwny i woli dowiedzieć się, że coś nie zostanie dowiezione pół roku wcześniej niż dzień wcześniej.

Robicie sobie brainstorming w np. 10 osób i np. patrzycie zadanie "ABC - dodaj button dupa" i każdy przydziela ile tam widzi SP do tego i bierzecie średnią?

Tak, tylko dokładnie odwrotnie - bo nie mamy 10 osób, nie mamy zadań typu "dodaj przycisk", i nie liczymy średniej.
Estymowanie poszczególnych zadań to domena fanatyków estymacji czasowej.

U nas operujemy na poziomie user story, które mają opisy wraz z linkami do solution design (u fanatyków estymacji czasowej niespotykane - nie ma czasu na opisywanie zadań, bo zaplanowane na kodzenie godziny lecą).
Jeśli każdy rozumie co jest do zrobienia, to nie ma po co liczyć średniej, bo się po prostu zgadzamy.

somekind napisał(a):

Robicie sobie brainstorming w np. 10 osób i np. patrzycie zadanie "ABC - dodaj button dupa" i każdy przydziela ile tam widzi SP do tego i bierzecie średnią?

Tak, tylko dokładnie odwrotnie - bo nie mamy 10 osób, nie mamy zadań typu "dodaj przycisk", i nie liczymy średniej.
Estymowanie poszczególnych zadań to domena fanatyków estymacji czasowej.

już myślałam że pracujesz w firmie gdzie traktują Cię jak dorosłego.....

U nas operujemy na poziomie user story, które mają opisy wraz z linkami do solution design (u fanatyków estymacji czasowej niespotykane - nie ma czasu na opisywanie zadań, bo zaplanowane na kodzenie godziny lecą).
Jeśli każdy rozumie co jest do zrobienia, to nie ma po co liczyć średniej, bo się po prostu zgadzamy.

ale jednak nie , historyjkami karmią ;)

Fajnie się czyta takie komentarze od kogoś, kto permanentnie narzeka na pracę. :D

@somekind

Nie, bo oni by pewnie uznali, że jeden SP = 1 dzień i dalej robili tak samo.

Przecież to chyba oczywiste że pytam, czy gdyby zaczęli używać SP tak jak wy, to czy ich estymaty stałyby się rzetelne.

Nie mamy cruda, przycisków ani testerów.

Wymieniłem tam trochę więcej potencjalnych powodów ;)

Po prostu w przeciwieństwie do fanatyków estymacji w jednostkach czasu nie planujemy sprintu co do godziny, dzięki czemu niespodziewane problemy albo oczywiste czynności nie rozwalają całego planu.

Co to właściwie znaczy całego planu?

Masz np. 10 tasków na sprinta, jeden okazuje się źle oszacowany i jeden inżynier będzie z nim walczyć podczas aktualnego oraz następnego sprinta

Co tutaj zmienia jednostka estymacji?

To że estymujesz w godzinach - nie co do godziny, bo to sobie dopowiadasz, wcale nie oznacza że ktoś ci stoi za plecami i rozlicza co do godziny i uprawia jakiś mobbing gdy nie dowieziesz w określonym czasie.

U nas operujemy na poziomie user story, które mają opisy wraz z linkami do solution design (u fanatyków estymacji czasowej niespotykane - nie ma czasu na opisywanie zadań, bo zaplanowane na kodzenie godziny lecą).
Jeśli każdy rozumie co jest do zrobienia, to nie ma po co liczyć średniej, bo się po prostu zgadzamy.

Przecież to jest chyba jakiś mierny żart :D :D :D :D :D

No tak, gdy będziesz porównywał estymację SP robioną z sensownymi procesami i w dojrzałym zespole, i będziesz ją porównywał z estymacją w patologicznym środowisku

no to faktycznie możesz odnieść wrażenie że to SP dzięki jesteście tacy lean, agile, yada yada :D

Jeśli każdy rozumie co jest do zrobienia, to nie ma po co liczyć średniej, bo się po prostu zgadzamy.

No to opiszesz w końcu jak ten proces u ciebie wygląda, czy będziemy tak 10 postów pisać zanim się wygadasz? :D

A wiesz że są firmy/zespoły które w ogóle nie bawią się w żadne SP, słoneczka czy godziny i po prostu skupiają się na dowożeniu?

Zamiast chodzić po scrumach, retrospektywach, spotkaniach dot. estymowania masz po prostu ogarniętych leaderów/managerów którzy się na tym skupiają

WeiXiao napisał(a):

Masz np. 10 tasków na sprinta, jeden okazuje się źle oszacowany i jeden inżynier będzie z nim walczyć podczas aktualnego oraz następnego sprinta

Co tutaj zmienia jednostka estymacji?

Po pierwsze trudniej źle oszacować gdy masz jednostkę ujmującą więcej wymiarów niż tylko czas. Po drugie jednostka dająca miejsce na błędy pozwala je popełniać bez konsekwencji.
(Abstrahując już od tego, że to nie tak powinno wyglądać, że jedna osoba walczy z zadaniem przez dwa sprinty.)

To że estymujesz w godzinach - nie co do godziny, bo to sobie dopowiadasz, wcale nie oznacza że ktoś ci stoi za plecami i rozlicza co do godziny i uprawia jakiś mobbing gdy nie dowieziesz w określonym czasie.

No nie musi tego oznaczać, ale tak to zazwyczaj wygląda - wystarczy czytać, co ludzie piszą na tym forum. :)

Przecież to jest chyba jakiś mierny żart :D :D :D :D :D

Ale co, to że zanim coś zrobimy, to to projektujemy?
No, dla młodych i dynamicznych to pewnie faktycznie żart, bo po co ładować taczkę, skoro można z nią biegać.

no to faktycznie możesz odnieść wrażenie że to SP dzięki jesteście tacy lean, agile, yada yada :D

Nie uważam, że jesteśmy lean i agile dzięki SP. Bez nich też byśmy dawali radę.
SP nie są przecież dla nas tylko dla biznesu.

A wiesz że są firmy/zespoły które w ogóle nie bawią się w żadne SP, słoneczka czy godziny i po prostu skupiają się na dowożeniu?

I to też działa, nawet dość dobrze.

Wiem, pracowałem nawet w takich. Tylko pytałeś o SP, nie o ich brak.

No to opiszesz w końcu jak ten proces u ciebie wygląda, czy będziemy tak 10 postów pisać zanim się wygadasz? :D

1. Ktoś z zespołu robi solution design do danego ficzera. W ramach SD tworzy historyjki.
2. Podczas refinementu omawiamy SD, a później jako zespół estymujemy storiesy.
3. Jeśli głosy są różne, to rozmawiamy na temat tego - czemu ktoś uważa, że story jest łatwiejsze/trudniejsze. Zazwyczaj kończy się to jakimś konsensusem, ale jeśli ktoś się upiera na wyższy estymatę, to wpisujemy wyższą.

Takie spotkanie jest średnio raz na tydzień, zajmuje 1h.

@somekind

Po drugie jednostka dająca miejsce na błędy pozwala je popełniać bez konsekwencji.

1. Wielokrotnie w tym wątku napisałem, że zaletą SP jest ten cały dupochron, jednakże jeżeli potrzebujesz dupochronu, no to trochę smutno, no ale przecież dyskusja nie jest nt. Jak estymować gdy pracuje z szefem za plecami / gdy mam mobbing w pracy / itd.
   Serio, nie każdy potrzebuje uprawiać fikołki i politykę bo obawia się konsekwencji gdy nie wyrobi się z ficzerem :P
2. Godziny również są jednostką oferującą miejsce na pomyłkę, popularną taktyką jest po prostu zawyżanie estymat x2 itd :)

(Abstrahując już od tego, że to nie tak powinno wyglądać, że jedna osoba walczy z zadaniem przez dwa sprinty.)

Bo co?

Nie wszystko można dzielić w nieskończoność i porozbijać na zadanka, czasem po prostu jest do wykonania praca (a właściwie to zawsze jest do wykonania praca :D).

Lekką ręką mogę ci dać przykłady tasków które mogą zająć sprint, dwa czy może nawet więcej. I będzie w nich wartość

Analiza i naprawa jakiegoś buga typu race condition, crasha, buga w narzędziu z którego korzysta produkt np. baza, bug w libce/kompilatorze, etc.
Blogi techniczne wielu firm mają wiele przykładów tego typu rzeczy. Coś się chrzani na prodzie i ktoś musi do tego usiąść i to załatwić.

Feature również może brzmieć niewinnie, ale np. zależności typu zewnętrzne serwisy, toole, APIs, etc. mogą narobić problemów.

No nie musi tego oznaczać, ale tak to zazwyczaj wygląda - wystarczy czytać, co ludzie piszą na tym forum.

Tak, a jakbyś czytał Reddita w 2022 to byś wiedział że Facebook upada

Jak już wspomniałem - dyskusja nie jest nt. "Jak estymować gdy pracuje z szefem za plecami / gdy mam mobbing w pracy / itd"

Meta Platforms, Inc. (META) Stock

Nie uważam, że jesteśmy lean i agile dzięki SP. Bez nich też byśmy dawali radę.
SP nie są przecież dla nas tylko dla biznesu.

Raz piszesz że jednostki (SP/Godziny/etc) nie są dla ciebie, a dla biznesu,

a innym razem że

Biznesu nie obchodzą godziny ani dni., na zewnątrz wychodzi wynik w postaci dwutygodniowego okresu, w którym coś zostanie dostarczone.

No to jak to w końcu jest, bo wydajesz się być niezdecydowany

W ogóle czemu biznes miałby się interesować jak zarządzacie ryzykiem i estymatami w teamie?
Zespoły raczej powinny być autonomiczne, no chyba że... znowu wracamy do szefa za plecami? :D

Ale co, to że zanim coś zrobimy, to to projektujemy?
No, dla młodych i dynamicznych to pewnie faktycznie żart, bo po co ładować taczkę, skoro można z nią biegać.

Jeżeli masz takie dziecinady pisać, to po co właściwie się produkujesz?

Przecież dosłownie w następnym zdaniu jest wyjaśnione co jest miernym żartem - porównywanie SP i godzin na nierównych warunkach

Ktoś z zespołu robi solution design do danego ficzera. W ramach SD tworzy historyjki.
Podczas refinementu omawiamy SD, a później jako zespół estymujemy storiesy.
Jeśli głosy są różne, to rozmawiamy na temat tego - czemu ktoś uważa, że story jest łatwiejsze/trudniejsze. Zazwyczaj kończy się to jakimś konsensusem, ale jeśli ktoś się upiera na wyższy estymatę, to wpisujemy wyższą.

I widzisz? napisałem ci wcześniej że pewnie przeszacowujecie zadania i temu prawie zawsze dowozicie :P

WeiXiao napisał(a):

1. Wielokrotnie w tym wątku napisałem, że zaletą SP jest ten cały dupochron, jednakże jeżeli potrzebujesz dupochronu, no to trochę smutno, no ale przecież dyskusja nie jest nt. Jak estymować gdy pracuje z szefem za plecami / gdy mam mobbing w pracy / itd.
   Serio, nie każdy potrzebuje uprawiać fikołki i politykę bo obawia się konsekwencji gdy nie wyrobi się z ficzerem :P

O dupochronach można mówić, gdy ktoś Ci grozi. Jeśli nie ma zagrożenia, to nie ma mowy o dupochronie.
Estymowanie z uwzględnieniem ryzyka i nieprzewidzianych okoliczności, to nie jest dupochron tylko podstawa sensownego estymowania.

1. Godziny również są jednostką oferującą miejsce na pomyłkę, popularną taktyką jest po prostu zawyżanie estymat x2 itd :)

No, tylko często to x2 nie wystarcza. Do tego jak ktoś wymyśli, że task zajmuje 40 godzin, to zakłada później, że zrobi go w tydzień, co zazwyczaj nie będzie prawdą.

Lekką ręką mogę ci dać przykłady tasków które mogą zająć sprint, dwa czy może nawet więcej. I będzie w nich wartość

Analiza i naprawa jakiegoś buga typu race condition, crasha, buga w narzędziu z którego korzysta produkt np. baza, bug w libce/kompilatorze, etc.
Blogi techniczne wielu firm mają wiele przykładów tego typu rzeczy. Coś się chrzani na prodzie i ktoś musi do tego usiąść i to załatwić.

Co nie znaczy, że ma się tym zajmować jedna osoba.

Jak już wspomniałem - dyskusja nie jest nt. "Jak estymować gdy pracuje z szefem za plecami / gdy mam mobbing w pracy / itd"

Dyskusja jest o tym, po co szacować - o to pytałeś, czyż nie?

Raz piszesz że jednostki (SP/Godziny/etc) nie są dla ciebie, a dla biznesu,

a innym razem że

Biznesu nie obchodzą godziny ani dni., na zewnątrz wychodzi wynik w postaci dwutygodniowego okresu, w którym coś zostanie dostarczone.

No to jak to w końcu jest, bo wydajesz się być niezdecydowany

Biznes chce wiedzieć, czy ich pomysł może zostać zrealizowany w danym terminie i oczekuje tej odpowiedzi od inżynierów.

W ogóle czemu biznes miałby się interesować jak zarządzacie ryzykiem i estymatami w teamie?

Nie mam pojęcia czemu miałby.

@WeiXiao Ale masz jakieś argumenty przeciwko używaniu SP poza "mi się SP nie podobają"? Oczywiście nie musisz lubić akurat tego narzędzia, w przypadkach w których próbowałeś ich używać nie miały sensu, albo były użyte źle, albo w kompletnie niewłaściwym celu (np. dupochron, albo narzędzie do rozliczania Kazia).
Twierdzisz, że lepiej wyceniać taski w godzinach, ale czyich godzinach? Zespołu, Kazia, Zenka? To oczywiste, że jakieś zadanie może być zrobione przez juniora w 8 godzin, przez ogarniętego regulara w 2 godziny, a senior będzie się z tym bujał 2 tygodnie.
Nie wiem też jakim cudem ma to być dokładniejsze narzędzie szacowania pracochłonności, skoro sam piszesz:

popularną taktyką jest po prostu zawyżanie estymat x2 itd :)

Realnie "biznesu" kompletnie nie obchodzi ile zrobisz w sprincie, chociaż czasami mu się wydaje, że powinno go to interesować. Jeżeli masz projekt, który w 2 tygodnie można doprowadzić do stanu używalności, albo chociaż MVP, to nie ma co szacować, tylko to zrobić. Gorzej, jak masz coś, co zespół, czy zespoły będą robić 1-3 lata, trzeba ten projekt zabudżetować i ocenić, czy 36 miesięcy * 10 osób * 20k miesięcznie ma szansę się zwrócić.
W takich przypadkach wycena za pomocą abstrakcyjnych jednostek (SP, T-shirt size itp.) zaczyna mieć sens, bo jesteś w stanie to zrobić szybko i dostatecznie dobrze. W tydzień masz ten 3 letni projekt "wyceniony", dostajesz 20 000SP, albo 100 "koszulek" S, 50M, 30L i 2XL, zaczynasz to robić i po kolejnych 2 tygodniach dostajesz pierwsze informacje zwrotne ile ten SP/koszulka może trwać. Ludzie, którzy te szacunki robili mają dużo lepsze rozeznanie w tym co mają zrobić, po co, jakie są spodziewane problemy.
Sponsorowi projektu, dajesz informację "zaczęliśmy robić, mamy bardzo wstępne szacunki, że przy aktualnym tempie całość zajmie 30 miesięcy, co tydzień będziemy aktualizować prognozę. Już na tym etapie można zacząć rozkminy, czy aby na 100% wciśnięcie tam AI jest konieczne, czy może warto je jednak wywalić, jeżeli termin jest istotny zatrudnić więcej ludzi, albo jasno widać, że pomysł się nie spina i uwalamy projekt.

@piotrpo teraz mieszasz wycenianie całego projektu z pracowaniem w sprintach i wycenie zadań pojedynczych

@anonimowy Tak, mieszam to trochę z premedytacją. Dla mnie SP nie mają sensu w SCRUM (zresztą mało ma sens w tej metodyce), bo znowu, to czy ileś tam przypadkowo wybranych zadań zostanie zrealizowanych w 10, czy w 11 dni nie ma żadnego znaczenia, a spotkałem się z robieniem grubej dramy, że jakieś nic nieznaczące zadanie miało być zamknięte w piątek, a zostało zamknięte w poniedziałek i siądźmy wszyscy razem, żeby zastanowić się co było przyczyną tego niepowodzenia, zróbmy retro, RCA i się zastanówmy. Często prowadziło to do kompletnych patologii, gdzie zadania były dopychane kolanem, albo robiono jakąś magię w Jira, żeby sprint burndown chart wyszedł ładnie.

To nie ten temat, ale sposób na oszacowanie grubego projektu, który u mnie jakoś tam się sprawdzał, to podział na duże bloki (T-shirt), wycena kilku takich bloków w ramach normalnej pracy w SP, ekstrapolowanie tego na resztę, podzielenie na przez aktualne velocity i uzyskanie przewidywanej daty końca. Nie jest to ani doskonałe, ani super precyzyjne, ale inne metody były pod tym względem gorsze.