Wątek przeniesiony 2024-01-26 23:49 z Kariera przez flowCRANE.
Czemu wycieniany taski w jakiś sloneczkach, kwiatuszkach i innych SP? Skoro story point wskazuje trudność zadania to czemu określa się ile dany zespół dowiezie ich na sprint? Czyżby to gadanie że sp to nie estymata czasowa była tylko po to żeby 5 dni później rzutować te wszystkie SP jednak na czas?
Dla mnie estymacja w SP to jeden wielki bubel po to żeby menago w kalkulatorze wyliczył kiedy dojedzie projekt a ynteligentni devowie nie mówili w jednostce czasowej bo jeszcze się zestresuje.
tak, tylko co możemy zrobić z tą wiedzą?
BTW często tickety są estymowane w SP a manago między sobą estymują wysokopoziomowe epici w rozmiarach koszulek i potem dochodzi mapowanie rozmiarów na SP XD
Wcielę się role adwokata diabła 
Zespoły się zmieniają w czasie i pod względem osobowym i technicznym (usprawnienia, dług technologiczny) i na podstawie SP można takie tendencje wychwycić
Nie wszyscy są na tym samym poziomie, jedni pracują wolniej inni szybciej. Dla ciebie 1SP może być ~1 dzień, a dla juniora/nowego w zespole 3 dni.
SP są proxy metryka, którą ciężko koncepcyjnie oddzielić od czasu 
Jak chcesz mieć spokój od klienta na dwa tygodnie, to ciężko nie zauważyć użyteczności SP 
U mnie w byłej firmie SP były spoko, tylko kilka sprintów zajęło doszlifowanie intuicji wyceny. po tych kliku sprintach wiedzieliśmy że średnio backendowiec spali na sprint 5SP, tester 6SP a frontendowiec 4SP (liczby przykładowe, ale były różne bo każdy miał inną intucję wyceny) i wtedy serio planowanie wychodziło. Wszyscy byli zadowoleni, menago bo wiedział ile kiedy zrobimy i my bo nie było spiny + można było świadomie wrzucać refactoring jak np. testerzy mieli akurat urlop.
We wszystkich firmach w których pracowałem chyba żaden programista nie brał tego na poważnie i wszyscy chcieli to koniecznie przeliczyć na czas. W jednych po prostu przeliczaliśmy na czas, w innych nie wolno było, bo to nie tak działa, ale każdy w głowie wiedział swoje.
Jeśli to ma sens, to prawie nikt go nie zna.
Wydaje mi się, że większość (łącznie z firmami w których pracowałem) robi te wyceny storypointowe, bo taka moda i tyle.
Obecnie wyceniamy tylko mniej więcej, żeby PM/PO wiedział czy zajmie nam coś dzień czy raczej kilka dni (ale jeśli się okaże, że jednak estymata była zła, to też nikogo nie pyta dlaczego ani nic z tych rzeczy, bardzo luźno). Ogólnie praca w scrumie to takie przedszkole, przesuwamy jakieś karteczki, próbujemy się na siebie nie obrażać. Czasem mam wrażenie, że sami siebie traktujemy nawzajem jakbyśmy byli jacyś niedorozwinięci :D
no ale koniec końców, płacą, i to całkiem nieźle, więc można się powygłupiać trochę :D
Ąowski napisał(a):
We wszystkich firmach w których pracowałem chyba żaden programista nie brał tego na poważnie i wszyscy chcieli to koniecznie przeliczyć na czas. W jednych po prostu przeliczaliśmy na czas, w innych nie wolno było, bo to nie tak działa, ale każdy w głowie wiedział swoje.
Widzę to dokładnie w ten sam sposób. Można się bawić w ciągi fibonacciego zamiast estymacji czasowych, ale i tak gdzieś tam na górze jest klient i PM który musi wiedzieć na kiedy ficzery będą dowiezione żeby przedstawić harmonogram klientowi, więc finalnie SP i tak będą musiały być przełożone w ten czy inny sposób na czas i tak. Można się z tym kłócić, że to złe podejście, że nie działa, obrażać, wyzywać innych, że się nie znają i nie umieją w Scrum, ale tak wygląda biznes. Klienci, zwłaszcza duzi nie lubią niepewności i zwykle oczekują konkretów.
markone_dev napisał(a):
Ąowski napisał(a):
We wszystkich firmach w których pracowałem chyba żaden programista nie brał tego na poważnie i wszyscy chcieli to koniecznie przeliczyć na czas. W jednych po prostu przeliczaliśmy na czas, w innych nie wolno było, bo to nie tak działa, ale każdy w głowie wiedział swoje.
Widzę to dokładnie w ten sam sposób. Można się bawić w ciągi fibonacciego zamiast estymacji czasowych, ale i tak gdzieś tam na górze jest klient i PM który musi wiedzieć na kiedy ficzery będą dowiezione żeby przedstawić harmonogram klientowi, więc finalnie SP i tak będą musiały być przełożone w ten czy inny sposób na czas i tak. Można się z tym kłócić, że to złe podejście, że nie działa, obrażać, wyzywać innych, że się nie znają i nie umieją w Scrum, ale tak wygląda biznes. Klienci, zwłaszcza duzi nie lubią niepewności i zwykle oczekują konkretów.
To czemu od początku nie można estymować w dniach i to takich normalnych gdzie występują liczny 4 i 6?
Przykład: PM/Manager uważa że z jakiegoś powodu spadła efektywność zespołu i pragnie przekonać klienta za trzeba poświęcić trochę czasu na spłacanie długu technicznego. A jakie narzędzie ma taki PM/Manager żeby przekonać klienta?
"Patrz John, to wykres SP/sprint z ostatnich 6 miesięcy. Wykres zaczyna dołować w tej okolicy kiedy przycisnęliśmy deadline i zespół poszedł na skróty w paru miejscach. Jak chcemy wrócić do dobrego tempa musimy teraz to spłacić".
Mnie przekonał
KamilAdam napisał(a):
markone_dev napisał(a):
Ąowski napisał(a):
We wszystkich firmach w których pracowałem chyba żaden programista nie brał tego na poważnie i wszyscy chcieli to koniecznie przeliczyć na czas. W jednych po prostu przeliczaliśmy na czas, w innych nie wolno było, bo to nie tak działa, ale każdy w głowie wiedział swoje.
Widzę to dokładnie w ten sam sposób. Można się bawić w ciągi fibonacciego zamiast estymacji czasowych, ale i tak gdzieś tam na górze jest klient i PM który musi wiedzieć na kiedy ficzery będą dowiezione żeby przedstawić harmonogram klientowi, więc finalnie SP i tak będą musiały być przełożone w ten czy inny sposób na czas i tak. Można się z tym kłócić, że to złe podejście, że nie działa, obrażać, wyzywać innych, że się nie znają i nie umieją w Scrum, ale tak wygląda biznes. Klienci, zwłaszcza duzi nie lubią niepewności i zwykle oczekują konkretów.
To czemu od początku nie można estymować w dniach i to takich normalnych gdzie występują liczny 4 i 6?
A kto powiedział, że nie można?
https://www.scrum.org/resources/scrum-guide
Story pointy -> służą szacowaniu złożoności zadania. W tym rozpoznawaniu gdy zadania są za duże.
Złożoność zadań w całym sprincie powinna się uśrednić. Suma SP dowiezionych to tak zwane "velocity" zespołu.
Velocity pozwala planować ile pracy można będzie "dowieść" w następnym sprincie.
Tyle teoria. Dla mnie to takie samie chmyku tamyku jak teologia. A linkowany Scrum Guide ma w sobie tyle samo faktów co Biblia.
Ostatnio pojawiła sie metoda estymacji metodą koszulkową: M, S, L, XL i XXL. Jak to się przekłada na velocity nie mam pojęcia. Generalnie raz pracowałem z tym podejściem i było "zespół bierze zadania do sprintu aż poczuje że jest już wystarczająco dużo" lub "nawalimy z zapasem" w zależności od scrum mastera/managera.
Jak to dobrze że ostatnie już prawie 6 lat nie pracuję w żadnym Scrumie, tylko w podejściu opartym na zaufaniu, pracy i dowożeniu na produkcje. Gdzie JIRA służy jako "otwarty backlog" z listą tasków posortowanych priorytetami. Obecnie używam JIRA jako kanban board'a mam otwarty "wieczny sprint" tylko po to żeby Agile Board mógł dobrze działać.
Czas Scruma dobiega końca, Agile skompromitowało się, no ale to nie było prawdziwe Agile...
Panie Areczku ja wiem że już więcej SP nie zmieścicie, ale to pilny bug i trzeba go rozwiązać. Poza tym, czemu robi Pan taska na 3 SP już drugi dzień???
Pinek napisał(a):
Panie Areczku ja wiem że już więcej SP nie zmieścicie, ale to pilny bug i trzeba go rozwiązać. Poza tym, czemu robi Pan taska na 3 SP już drugi dzień???
To mi przypomina prace z poprzedniego projektu gdzie dzień po zaplanowaniu wszystkiego wpadały ważne taski spoza sprintu
Ważnych taskow oczywiście nie robiłem bo wszyscy oczywiście wiedza iż najważniejsze jest wykonanie sprintu
Bo scrum to patologia. Wielokrotnie mówiono i udowadniano, że estymacje w scrumie nie działają. A na pewno nie w sposób w jaki oczekuje tego PM. SP i inne pierdoły to już w ogóle jakieś odklejki, których żaden poważny człowiek nie bierze na poważnie. Jak już estymować to po ludzku - W dniach, godzinach itp.
markone_dev napisał(a):
To czemu od początku nie można estymować w dniach i to takich normalnych gdzie występują liczny 4 i 6?
A kto powiedział, że nie można?
Byłem w takim jednym zespole. Potrafili się kłócić kilkanaście minut czy wpisać 3 czy 5 :-) (w zdzirze)
W końcu nie wytrzymałem i pokazałem dowód istnienia czwórki. (liczba większa niż 3, a mniejsza niż 5). Nie wszystkich ten dowód przekonał :-(
Estymacje to jeszcze nie są takie złe. Najgorsze są sprinty, sprint goale i sraczka, żeby wszystko dowieźć przed końcem. Obecnie robimy apke, której release na proda będzie za pół roku, a i tak zawsze jest spina, żeby wszystko dowieźć przed końcem 2-tygodniowego sprintu. Wiadomo, różnica jednego czy dwóch dni jest kolosalna, szczególnie że u nas praca jest bardziej w stylu waterfalla niż scruma. Ale cza zrobić przed kliknięciem rozpocznij nowy sprint, żeby velocity i inne gówna się zgadzały, których oficjalnie nikt nie przegląda ani nie porównuje.
jarekr000000 napisał(a):
Byłem w takim jednym zespole. Potrafili się kłócić kilkanaście minut czy wpisać 3 czy 5 :-) (w zdzirze)
Coś nade mną czuwa, bo przez 12 lat pracy w firmach produktowych i konsultingowych nie miałem "szczęścia" używać SP, a raz nawet się przeciwstawiłem jak jeden dev wpadł na ten genialny pomysł, bo wiedziałem że PO będzie mnie pytał o to jak te SP przekładają się na dni i godziny.
jarekr000000 napisał(a):
W końcu nie wytrzymałem i pokazałem dowód istnienia czwórki. (liczba większa niż 3, a mniejsza niż 5).
I tak trzeba żyć. Przywróćmy normalność estymacji zadań 
KamilAdam napisał(a):
markone_dev napisał(a):
Ąowski napisał(a):
We wszystkich firmach w których pracowałem chyba żaden programista nie brał tego na poważnie i wszyscy chcieli to koniecznie przeliczyć na czas. W jednych po prostu przeliczaliśmy na czas, w innych nie wolno było, bo to nie tak działa, ale każdy w głowie wiedział swoje.
Widzę to dokładnie w ten sam sposób. Można się bawić w ciągi fibonacciego zamiast estymacji czasowych, ale i tak gdzieś tam na górze jest klient i PM który musi wiedzieć na kiedy ficzery będą dowiezione żeby przedstawić harmonogram klientowi, więc finalnie SP i tak będą musiały być przełożone w ten czy inny sposób na czas i tak. Można się z tym kłócić, że to złe podejście, że nie działa, obrażać, wyzywać innych, że się nie znają i nie umieją w Scrum, ale tak wygląda biznes. Klienci, zwłaszcza duzi nie lubią niepewności i zwykle oczekują konkretów.
To czemu od początku nie można estymować w dniach i to takich normalnych gdzie występują liczny 4 i 6?
Można. Jak trzeba, to można. Moda jednak jest taka, że ma być scrum/agile/story pointy etc.
sprint goale
Eh, już zapomniałem. Najgorsza patologia. W sprincie jest 10 niepowiązanych ze sobą ticketow ale trzeba wymyślić jaki jest cel. Wiec bierze się największy ticket i wpisuje iż on jest celem XD
Idealnie stosowane SP nie szacuje czasu tylko złożoność zagadnienia.
Na podstawie długo zbieranych metryk i po stabilizacji szacowania SP w zespole scrumowym można szacować czas na zadania o określonej złożoności i jak dobrze zespół będzie sobie z nimi radził (wypalał punkty).
https://www.atlassian.com/agile/project-management/velocity-scrum
A ja pójdę o krok dalej. Najlepiej mi się pracowało w projektach w których scruma nie było. Jak było zrobione to było. Zdarzały się zadania z większym priorytetem i deadline, ale nadal w niczym to nie przeszkadzało i ludzie dowozili. Skąd taka kolej rzeczy? Być może z faktu, że bezsensownie przepalany czas na scrumowe ceremonie było pożytkowany na realną pracę.
ledi12 napisał(a):
A ja pójdę o krok dalej. Najlepiej mi się pracowało w projektach w których scruma nie było. Jak było zrobione to było. Zdarzały się zadania z większym priorytetem i deadline, ale nadal w niczym to nie przeszkadzało i ludzie dowozili. Skąd taka kolej rzeczy? Być może z faktu, że bezsensownie przepalany czas na scrumowe ceremonie było pożytkowany na realną pracę.
Warto też zaznaczyć że taka organizacja pracy nie oznacza że nie można sobie pograć w gry czy porobić czegoś innego. Można bo wtedy doliczasz to per task. A tymczasem w scrumie mam 2 dni spotkań (nie da się w jeden dzień bo część ma tak wypchany kalendarz) w których czekam od spotkania do spotkania i robie jakieś [CIACH!] w domu lub gram. Potem mam 7 dni pracy (potencjalnej, zazwyczaj bliżej 4-5) na jakieś rzeczy bo w ostatni dzień to się tylko merguje i czeka na koniec. Ilość przepalonych dni co dwa tygodnie to na pierwszy rzut oka 3 ale jeszcze w międzyczasie mamy jakieś inne spotkania więc bliżej 4. Czyli praktycznie 40% czasu co dwa tygodnie idzie do śmieci. Nawet moje lenistwo by mi nie pozwoliło aż tak się opier#alać.
Jeśli traktujesz SP jako coś w stylu: 3 to "przeciętnie złożone zadanie", 2 to nieco mniej,. 5 to trochę więcej. Druga rzecz to jeśli rozjazd jest o 1 punkt to średnią wziąć, zaokrąglić w górę i tyle(to i tak relatywna złożoność). Dopytywać można jednej osoby krótko jeśli wszyscy dali 3 a ktoś dał 1 albo 5.
Łatwiej powiedzieć: zadanie jest średnio złożone, niż 3 dni i jeszcze się wykłócać że można w 2 dni to zrobić bo coś tam.(a potem jednak nie dowiezione)
No i istotą jest to, że manager sobie liczy ile było dni w sprincie i ile zostało dowiezione SP i sobie dalej wyciąga z tego wnioski ale devów to nie obchodzi.(i aktualizuje to co sprint). Np. ile mniej więcej dowożą na sprint.
Generalnie te estymacje dniowe też są relatywne i w teorii lepiej niż upychać coś w "1 dzień" lepiej powiedzieć "jest mało złożone" i niech sobie manager wyciąga wnioski na podstawie przeszłych sprintów.
Tylko, że niestety managerowie dopytują nawet przy małych rozjazdach a chodzi o to, żeby na to nie tracić czasu bo i tak to jest relatywne/zbliżone.
Teoretycznie to ma sens, praktycznie często wykonanie jest złe.
Czemu wycieniany taski w jakiś sloneczkach, kwiatuszkach i innych SP?
Nie wiem czemu w tym wyceniacie, ja tak ani nie robiłem, ani nie robię.
Imo to bez sensu, już nawet godziny są lepsze :D
bagietMajster napisał(a):
Czemu wycieniany taski w jakiś sloneczkach, kwiatuszkach i innych SP?
Bo bujając się na firmowej huśtawce w przerwie między grą w piłkarzyki a kolejną kawką łatwiej myśleć o słoneczkach i kwiatuszkach niż o smutnych godzinach przypominających nam o twardej rzeczywistości. Normalny element systemu pracy stworzonego dla niedojrzałych emocjonalnie.
bagietMajster napisał(a):
Czemu wycieniany taski w jakiś sloneczkach, kwiatuszkach i innych SP? Skoro story point wskazuje trudność zadania to czemu określa się ile dany zespół dowiezie ich na sprint? Czyżby to gadanie że sp to nie estymata czasowa była tylko po to żeby 5 dni później rzutować te wszystkie SP jednak na czas?
Dla mnie estymacja w SP to jeden wielki bubel po to żeby menago w kalkulatorze wyliczył kiedy dojedzie projekt a ynteligentni devowie nie mówili w jednostce czasowej bo jeszcze się zestresuje.
Idea za story pointami była taka żeby dało się priorytetyzować zadania. Cały pomysł był taki ze nadaje się bezjednostkową wartość jakiemuś user story, dzięki temu osoba decyzyjna rozumie ich trudność, a jednocześnie ona sama wie jaką wartość może dostarczyć konkretną user story, sama w głowie robi sobie rachunek jaką wartość chce dostarczyć za daną ilość tej wartości bezjednostkowej, i układa backlog z priorytetami.
Ma to jakiś sens.
To co pisze @benoni12, to jest dokładnie to jak to miało działać.
Natomiast to co pisze @markone_dev i @Ąowski:
markone_dev napisał(a):
Ąowski napisał(a):
We wszystkich firmach w których pracowałem chyba żaden programista nie brał tego na poważnie i wszyscy chcieli to koniecznie przeliczyć na czas. W jednych po prostu przeliczaliśmy na czas, w innych nie wolno było, bo to nie tak działa, ale każdy w głowie wiedział swoje.
Widzę to dokładnie w ten sam sposób. Można się bawić w ciągi fibonacciego zamiast estymacji czasowych, ale i tak gdzieś tam na górze jest klient i PM który musi wiedzieć na kiedy ficzery będą dowiezione żeby przedstawić harmonogram klientowi, więc finalnie SP i tak będą musiały być przełożone w ten czy inny sposób na czas i tak. Można się z tym kłócić, że to złe podejście, że nie działa, obrażać, wyzywać innych, że się nie znają i nie umieją w Scrum, ale tak wygląda biznes. Klienci, zwłaszcza duzi nie lubią niepewności i zwykle oczekują konkretów.
To jest takie nie-agile'owe podejście do programowania, gdzie wymaga się od programistów, testerów czy produkt ownerów estymacji czasowej lub terminów. Jak ktoś Cię zmusza do podania terminu albo daty, to nie jesteś Agile niestety.
Jak nie masz Agile-mindset to ciężko żeby agile-owe praktyki (story point) działały.
SP jest tylko dla menadżmentu, żeby myśleli, że wiedzą ile coś zajmie oraz żeby kontrolować koderów. Z punktu widzenia programistów jest to totalnie bezużyteczna a nawet toksyczna rzecz.
Czitels napisał(a):
SP jest tylko dla menadżmentu, żeby myśleli, że wiedzą ile coś zajmie oraz żeby kontrolować koderów.
Ja myślę, że byłoby prościej gdyby wiedzieli ile czasu zajmie konkretne zadanie/feature xD
Czitels napisał(a):
SP jest tylko dla menadżmentu, żeby myśleli, że wiedzą ile coś zajmie oraz żeby kontrolować koderów. Z punktu widzenia programistów jest to totalnie bezużyteczna a nawet toksyczna rzecz.
Nie "żeby wiedzieli ile coś zajmie", tylko żeby widzieli jak trudne coś jest.
some_ONE napisał(a):
Ja myślę, że byłoby prościej gdyby wiedzieli ile czasu zajmie konkretne zadanie/feature xD
Byłoby , gdyby ktoś był w stanie to podać - ale nikt nie umie dobrze zgadnąć ile jakiś feature zajmie. Jak dla mnie słowa "estimate" oraz "guess" są tutaj podobne. Estimate to po prostu strzały.
Zgadzam się że faux-agile to jest mega słaba rzecz, i nie fajnie się pracuje w czymś takim - to jest udręka. Tylko ze to nie jest wina agile - to wina osób które wprowadziły jakąś karykaturę Agile, zamiast "the real thing".
Riddle napisał(a):
Nie "żeby wiedzieli ile coś zajmie", tylko żeby widzieli jak trudne...
I muszą wiedzieć co jak trudne jest żeby to przenieść na jednostkę czasu. Podtrzymuję @Czitels, prościej byłoby im dać ta jednostkę.
Riddle napisał(a):
Natomiast to co pisze @markone_dev i @Ąowski:
markone_dev napisał(a):
Ąowski napisał(a):
We wszystkich firmach w których pracowałem chyba żaden programista nie brał tego na poważnie i wszyscy chcieli to koniecznie przeliczyć na czas. W jednych po prostu przeliczaliśmy na czas, w innych nie wolno było, bo to nie tak działa, ale każdy w głowie wiedział swoje.
Widzę to dokładnie w ten sam sposób. Można się bawić w ciągi fibonacciego zamiast estymacji czasowych, ale i tak gdzieś tam na górze jest klient i PM który musi wiedzieć na kiedy ficzery będą dowiezione żeby przedstawić harmonogram klientowi, więc finalnie SP i tak będą musiały być przełożone w ten czy inny sposób na czas i tak. Można się z tym kłócić, że to złe podejście, że nie działa, obrażać, wyzywać innych, że się nie znają i nie umieją w Scrum, ale tak wygląda biznes. Klienci, zwłaszcza duzi nie lubią niepewności i zwykle oczekują konkretów.
To jest takie nie-agile'owe podejście do programowania, gdzie wymaga się od programistów, testerów czy produkt ownerów estymacji czasowej lub terminów. Jak ktoś Cię zmusza do podania terminu albo daty, to nie jesteś Agile niestety.
Niestety, ale większość biznesów i klientów nie jest i nie będzie Agile w dosłownym tego znaczeniu, dlatego SP w 95% projektów będą przeliczane na czas. Po prostu tego oczekują klienci i taki jest biznes.
Dlatego uważam, że w dużej większości projektów SP się nie sprawdzą bo cały biznes opiera się o dwa parametry: Czas i Pieniądz. dlatego nie ma sensu zawracać sobie tym głowy i estymować w dniach i godzinach.
Riddle napisał(a):
some_ONE napisał(a):
Ja myślę, że byłoby prościej gdyby wiedzieli ile czasu zajmie konkretne zadanie/feature xD
Byłoby , gdyby ktoś był w stanie to podać - ale nikt nie umie dobrze zgadnąć ile jakiś feature zajmie. Jak dla mnie słowa "estimate" oraz "guess" są tutaj podobne. Estimate to po prostu strzały.
Dokładnie to samo jest z SP, dlatego często dochodzi do sporów czy zadanie wycenić na 3, 5 czy 7 SP bo sam zespół nie umie tego poprawnie wyestymować, a w biznesie liczy się czas i pieniądze, a nie zabawy programistów.
Estymaty nie ważne w czym, mają to do siebie, że są tylko szacunkami. Nie ważne czy estymujemy w SP, godzinach, czy rozmiarach koszulki. To są i będą tylko szacunki, które należy uwzględnić w harmonogramie projektu innymi słowy wziąć poprawkę na ewentualne niedoszacowanie lub przeszacowanie.
Powtórzę. Biznes interesuje ile coś zajmie i ile będzie kosztować. Tyle. A cały Agile mają głęboko w pupie ¯_(ツ)_/¯