markone_dev napisał(a):
Biznes interesuje ile coś zajmie i ile będzie kosztować. Tyle. A cały Agile mają głęboko w pupie ¯_(ツ)_/¯
I wszystko, idealnie podsumowanie całego agile. EOT. +1 !
7
2
bagietMajster napisał(a):
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ę.
Niee, muszą wiedzieć co jak jest trudne, żeby ocenić trudność kilku user story między sobą, porównać też ich spodziewane dostarczone wartości, i na tej podstawie stwierdzić którą zrobić najpierw. W Agile nie ma żadnego "przenoszenia" na jednostkę czasu.
markone_dev napisał(a):
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.
No tak. Większość biznesów nie jest Agile.
markone_dev napisał(a):
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.
Ja powiem tak - Agile to jest (chyba) najlepszy sposób na dostarczanie oprogramowania (nie faux-Agile, tylko prawdziwy Agile). Są na to twarde dane i staty. Ergo, każdy kto nie nie jest Agile, trochę jakby wytwarzał soft z jedną ręką zawiązaną za plecami.
To powiedziawszy - jeśli nie jesteś Agile, to faktycznie story pointy nie mają sensu. Wszystkie zalecenia i praktyki Agile mają sens, tylko wtedy kiedy jesteś Agile.
markone_dev napisał(a):
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.
Tak. Tylko przewagą SP nad czasem jest to że są bezjednostkowe, i tutaj leży ich siła.
Ludzie nie są dobrzy w ocenianiu absolutnych wartości (ile co konkretnie zajmie), ale dużo lepiej sobie radzą z porównywaniem wartości (która z tych user story zajmie więcej).
markone_dev napisał(a):
Powtórzę. Biznes interesuje ile coś zajmie i ile będzie kosztować. Tyle. A cały Agile mają głęboko w pupie ¯_(ツ)_/¯
No ja wiem - większość biznesów nie jest Agile.
2
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?
@KamilAdam Jak czytałem scrum-guid to odnosiłem wrażenie że tekst to jedna wielka psychologiczna sztuczka mająca z manipulować osoby sztywnymi typami osobowości(mającymi tedecje zajmowania się zarządzeniem i anwansowaniem w biurokracji) tak żeby nie były nie znośne dla osób mających kreatywne osobowości(mające tedecje do kodowania i bycia w tym dobry) i vice versa.
W każdym dziale masz jakiś początek o sprawdzaniu, kontroli itp. - co spowoduje że uwaga takiego zarządcy będzie przyciągnięta- tylko po to żeby że później określać granice tej kontroli i oddelegowywać sprawy programistów(scrum teamu).
Jak dla mnie główną funkcja SP w magicznych jednostkach i magicznej nie liniowej skali, jest to żeby ograniczyć mikrozarządzanie, w taki sposób by osoba podążająca od linijki za regułami to kupiła.
4
Riddle napisał(a):
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.
Przecież ich nie obchodzi jak coś jest trudne, ale mają mieć informacje ile muszą wyłożyć kasy na x czasu pracy. Chodzi o konkrety. Zarządy myślą, że praca programistów to to samo co robota na taśmie, że da się ładnie w Excela włożyć ile można towaru wyprodukować. (Ofc w webdevie poziom skomplikowania jest ten sam, ale i tak jest to rng)
6
Ja estymuję na oko a potem nikt na to nie patrzy. Do tego mniej więcej są SP.
Jeśli ktoś robi dramę wokół SP .... Łohoho to czas szukać nowej pracy.
3
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.
Czym się różni estymata w SP od estymaty w godzinach?
w obu przypadkach jest to estymata, a ile faktycznie wyjdzie godzin na zrobienie jest niezmienne.
Idea za story pointami była taka żeby dało się priorytetyzować zadania
Priorytet, a złożoność to różne rzeczy.
Możesz mieć złożone zadanie o niskim priorytecie (np. czasochłonny refaktor którego ROI jest niewielki)
Jak i również możesz mieć krótkie zadania o wysokim priotytecie (np. hotfix)
Ludzie nie są dobrzy w ocenianiu absolutnych wartości (ile co konkretnie zajmie), ale dużo lepiej sobie radzą z porównywaniem wartości (która z tych user story zajmie więcej).
Tak, ciężej jest trafić ile dokładnie coś zajmie niż trafić co więcej.
To tak jakbyś na giełdzie obstawiał kierunek (spadek/wzrost) vs grał opcje terminowe. Te drugie jest o wiele ciężej trafić, dlatego potencjał zarobkowy jest o wiele większy.
Jednakże złe rzeczy porównujesz, bo nie chodzi o ocenienie co więcej zajmie, a +- ile coś zajmie.
2
Jakby mi ktoś w pracy powiedział że SP estymują czas to bym go wyśmiał 
I wywalił
Do estymacji czasu używamy czasu. Do estymacji złożoności używamy SP, t-shirtów, porównania do zadań, sposobów jest tyle ile ludzi.
Jeśli używamy SP i mamy w zespole scrum mastera, to powinien on liczyć takie rzeczy i dawać wyraźną statystykę zespołowi i PO że nie dowieziemy albo możemy nie dowieźć takiego zestawu zadań, celu czy czegoś bo tak to wygląda jak się weźmie pod uwagę velocity i może nam to zająć tyle a tyle czasu.
Jeśli tego nie robi to jest do zwolnienia.
Jak nie mamy scrum mastera, to fajnie jakby PO się orientował i zespół miał to na uwadze przy planowaniu jak szybko wypalamy punkty i czy wypalimy te story pointy które założyliśmy.
To, że na większości scrumowych i managerskich stanowiskach są idioci, a zespoły bawią się w to tylko dlatego bo dyrektorzy kazali zagilować i zescrumować naszą firmę, to już w ogóle inna patologia.
1
Jakby mi ktoś w pracy powiedział że SP estymują czas to bym go wyśmiał
Pośrednio czy bezpośrednio?
No bo jeżeli w zespole/u mistrza młyna panuje jakieś przeliczenie że "JeDen EsPe To Dwie GoDzInY" no to pośrednio SP są estymacją czasową
2
WeiXiao napisał(a):
Jakby mi ktoś w pracy powiedział że SP estymują czas to bym go wyśmiał
Pośrednio czy bezpośrednio?
No bo jeżeli w zespole panuje jakieś przeliczenie że "JeDen EsPe To Dwie GoDzInY" no to pośrednio jest estymacją czasową
W jaki tylko sposób mógłbym. Albo sam bym się zwalniał. Ale przed tym można zrobić mediację czyli po prostu pouczyć wszystkich na czym to polega. Myślałem, że chodzi ci o zwolnienie
W jakikolwiek sposób. SP nie może być powiązane z czasem bo to psuje statystykę.
I nie jestem żadnym adwokatem scruma. Uważam to za sektę. Ale są tam pewne koncepty (pewnie wyniesione z XP), które są fajne i przydatne i mentalnie w miarę proste do ogarnięcia. Między innymi SP wspomagają zespoły w których developerzy boją się estymować godzinowo albo robią to źle (odczuwają presję czasu i jakieś emocje, nie mają dobrej struktury pracy albo pracują zrywczo). Mamy fajną abstrakcję na skalę trudności czegoś co trzeba zrobić i przemnażamy ją przez historyczny średni czas wykonywania. Daje to bardzo dobry punkt wyjściowy dla estymat na cały zespół (czyli tak jak mówi scrum, pracujemy jako zespół a nie jednostka). Prościej się nie da naprawdę.
No ale jeśli wpadasz do projektu i tam są ludzie którzy mają to przeliczenie to trzeba ich palnąć w łeb i wyjaśnić, że to zło.
2
w których developerzy boją się estymować godzinowo albo robią to źle (odczuwają presję czasu i jakieś emocje
Nie wiem, nigdy nie miałem jakiegoś mentalnego oporu z takimi estymacjami.
A jeżeli nie miałem pewności to rozbijałem na mniejsze zadania co do których miałem większą pewność, lub robiłem ocenę ryzyka.
A na koniec dnia prawie zawsze i tak w ***ju miałem to ile więcej mi zejdzie, bo coś innego robiłem szybciej i się amortyzowało
2
WeiXiao napisał(a):
w których developerzy boją się estymować godzinowo albo robią to źle (odczuwają presję czasu i jakieś emocje
Nie wiem nigdy nie miałem jakiegoś mentalnego problemu z takimi estymacjami.
A jeżeli nie miałem pewności to rozbijałem na mniejsze zadania co do których miałem większą pewność, lub robiłem ocenę ryzyka.
Nie każdy jest odporny na presję. Z mojego doświadczenia ludzie bardzo słabo radzą sobie z estymacjami godzinowymi, to jest coś co klaruje się wraz z doświadczeniem i raczej u osób, które są zorganizowane w sposobie pracy i się nie obijają, nie rozpraszają (nie każdy taki jest).
Złe estymacje często są ukrywane przez zespoły bo developerzy siedzą poza godzinami żeby coś dokończyć na koniec sprintu albo jakiś ważny deadline biznesowy. Tacy potem się wypalają i mają gorszy performance i do tego cały zespół cierpi bo nierealne estymacje stają się normą.
Ogólnie root cause jest to bardziej people problem i zagadnienie z zarządzania ludźmi. SP są takim mechanizmem który poprawnie implementowany w zespole scrumowym, ma dać stałą ilość nakładu pracy która jest bezpieczna dla zespołu i pewne poczucie co można w danym okresie czasu zrealizować.
2
Pomiając bezsens SP i ogólnie estymowania...
SP nie jest jednostką czasu, tylko jednostką "czegoś" złożoności, niepewności, pracochłonności zadania. Wartość czasową, w postaci velocity otrzymuje on po fakcie. Czyli jak zespół przez pół roku, co 2 tygodnie wrzuca jakieś tam szacunki w sp i wiadomo, że średnio co sprint "dowiezie" 50 SP, czasami 40, czasami 60 itd. to można na tej podstawie wyliczyć co będzie za 2 tygodnie. W dłuższej perspektywie i tak nie ma sensu liczyć, a że liczy się jedynie co będzie za rok, a nie co będzie za 2 tygodnie, to można sobie odpuścić szacowanie.
3
clonazepam napisał(a):
Jakby mi ktoś w pracy powiedział że SP estymują czas to bym go wyśmiał
I wywaliłDo estymacji czasu używamy czasu. Do estymacji złożoności używamy SP, t-shirtów, porównania do zadań, sposobów jest tyle ile ludzi.
Jeśli używamy SP i mamy w zespole scrum mastera, to powinien on liczyć takie rzeczy i dawać wyraźną statystykę zespołowi i PO że nie dowieziemy albo możemy nie dowieźć takiego zestawu zadań, celu czy czegoś bo tak to wygląda jak się weźmie pod uwagę velocity i może nam to zająć tyle a tyle czasu.
"i może nam to zająć tyle a tyle czasu." - no to trochę brzmi jakbyśmy koniec końców wracali jednak ile czasu nam coś zajmie, nie?
"Jakby mi ktoś w pracy powiedział że SP estymują czas to bym go wyśmiał" - no dlatego nikt tego nie mówi. Wszyscy grają w tą grę i bawimy się dalej :D
1
Ąowski napisał(a):
clonazepam napisał(a):
Jakby mi ktoś w pracy powiedział że SP estymują czas to bym go wyśmiał
I wywaliłDo estymacji czasu używamy czasu. Do estymacji złożoności używamy SP, t-shirtów, porównania do zadań, sposobów jest tyle ile ludzi.
Jeśli używamy SP i mamy w zespole scrum mastera, to powinien on liczyć takie rzeczy i dawać wyraźną statystykę zespołowi i PO że nie dowieziemy albo możemy nie dowieźć takiego zestawu zadań, celu czy czegoś bo tak to wygląda jak się weźmie pod uwagę velocity i może nam to zająć tyle a tyle czasu.
"i może nam to zająć tyle a tyle czasu." - no to trochę brzmi jakbyśmy koniec końców wracali jednak ile czasu nam coś zajmie, nie?
Masz cały wątek osób które tłumaczą, czemu to nie jest jednostka czasu, a jedynie parametr używany do statystyk. Statystyk, które mogą określić ile coś nam zajmie czasu, jeśli ktoś umie ją robić.
2
clonazepam napisał(a):
Ąowski napisał(a):
clonazepam napisał(a):
Jakby mi ktoś w pracy powiedział że SP estymują czas to bym go wyśmiał
I wywaliłDo estymacji czasu używamy czasu. Do estymacji złożoności używamy SP, t-shirtów, porównania do zadań, sposobów jest tyle ile ludzi.
Jeśli używamy SP i mamy w zespole scrum mastera, to powinien on liczyć takie rzeczy i dawać wyraźną statystykę zespołowi i PO że nie dowieziemy albo możemy nie dowieźć takiego zestawu zadań, celu czy czegoś bo tak to wygląda jak się weźmie pod uwagę velocity i może nam to zająć tyle a tyle czasu.
"i może nam to zająć tyle a tyle czasu." - no to trochę brzmi jakbyśmy koniec końców wracali jednak ile czasu nam coś zajmie, nie?
Masz cały wątek osób które tłumaczą, czemu to nie jest jednostka czasu, a jedynie parametr używany do statystyk. Statystyk, które mogą określić ile coś nam zajmie czasu, jeśli ktoś umie ją robić.
Tak, rozumiem, nie twierdzę, że jest to jednostką czasu. Rozumiem, że zamysł jest inny.
Ale czy nie jest to koniec końców, nie jest to mapowane na czas i do tego ludzie tego używają w większości przypadków? (chociaż w tym co napisałeś rozumiem, że po prostu to mapowanie na czas odbywa się później niż większość osób, łącznie ze mną, tu zakłada)
" a jedynie parametr używany do statystyk. Statystyk, które mogą określić ile coś nam zajmie czasu, jeśli ktoś umie ją robić." - jakie są pozostałe parametry w takim razie? Nie pytam oczywiście o wszystkie, ale jakieś przykłady, może pomoże mi to zrozumieć.
Kolejna sprawa, w jakim celu takie statystyki prowadzić w takim razie? Oprócz tego, że mogą one określić ile coś nam zajmie czasu? Pytam niezłośliwie, chętnie się dowiem, nie twierdzę, że miałem albo mam rację. Moje wypowiedzi bazowały na moim dotychczasowym doświadczeniu.
5
clonazepam napisał(a):
Masz cały wątek osób które tłumaczą, czemu to nie jest jednostka czasu, a jedynie parametr używany do statystyk. Statystyk, które mogą określić ile coś nam zajmie czasu, jeśli ktoś umie ją robić.
A na koniec dnia przychodzi biznes/klient i pyta na kiedy i za ile. Klient ma gdzieś jakich metryk używasz do estymowania zadań i czy jesteś Agile czy nie. Klient chce znać harmonogram, kamienie milowe i cenę. Więc koniec końców musisz mieć jakąś metrykę, której użyjesz do wyceny czasowej i kosztowej projektu. A jak mu tego nie powiesz to znajdzie innego dostawcę.
Typowy scenariusz, przychodzi klient i mówi że chce jakiś tam moduł dorobić i chce wiedzieć ile czasu to zajmie i ile będzie kosztowało. Zespół siada, analizuje, rozbija zadanie na historyjki, estymuje z grubsza historyjki w SP i zadowolony wychodzi ze spotkania. Co mówisz klientowi?
4
Ąowski napisał(a):
clonazepam napisał(a):
Ąowski napisał(a):
clonazepam napisał(a):
Jakby mi ktoś w pracy powiedział że SP estymują czas to bym go wyśmiał
I wywaliłDo estymacji czasu używamy czasu. Do estymacji złożoności używamy SP, t-shirtów, porównania do zadań, sposobów jest tyle ile ludzi.
Jeśli używamy SP i mamy w zespole scrum mastera, to powinien on liczyć takie rzeczy i dawać wyraźną statystykę zespołowi i PO że nie dowieziemy albo możemy nie dowieźć takiego zestawu zadań, celu czy czegoś bo tak to wygląda jak się weźmie pod uwagę velocity i może nam to zająć tyle a tyle czasu.
"i może nam to zająć tyle a tyle czasu." - no to trochę brzmi jakbyśmy koniec końców wracali jednak ile czasu nam coś zajmie, nie?
Masz cały wątek osób które tłumaczą, czemu to nie jest jednostka czasu, a jedynie parametr używany do statystyk. Statystyk, które mogą określić ile coś nam zajmie czasu, jeśli ktoś umie ją robić.
Tak, rozumiem, nie twierdzę, że jest to jednostką czasu. Rozumiem, że zamysł jest inny.
Ale czy nie jest to koniec końców, nie jest to mapowane na czas i do tego ludzie tego używają w większości przypadków? (chociaż w tym co napisałeś rozumiem, że po prostu to mapowanie na czas odbywa się później niż większość osób, łącznie ze mną, tu zakłada)" a jedynie parametr używany do statystyk. Statystyk, które mogą określić ile coś nam zajmie czasu, jeśli ktoś umie ją robić." - jakie są pozostałe parametry w takim razie? Nie pytam oczywiście o wszystkie, ale jakieś przykłady, może pomoże mi to zrozumieć.
Kolejna sprawa, w jakim celu takie statystyki prowadzić w takim razie? Oprócz tego, że mogą one określić ile coś nam zajmie czasu? Pytam niezłośliwie, chętnie się dowiem, nie twierdzę, że miałem albo mam rację. Moje wypowiedzi bazowały na moim dotychczasowym doświadczeniu.
Czas uzyskujesz pośrednio poprzez informację jak dużo story pointów udaje się zrealizować w danym okresie czasu całemu zespołowi, bądź nawet lepiej - ile średnio czasu zajmują nam zadania wycenione na tyle a tyle story pointów przez jakiś okres czasu. Musisz mieć do tego zespół, który ma podobne spojrzenie na wycene (to się szybko samo wyrównuje podczas prowadzenia refinementu).
Jakie zalety ma używanie SP w całym procesie scrum? Wg mnie przynajmniej te:
- Uśrednianie względem wszystkich osób w zespole (ewentualnej) statystyki czasu potrzebnego na zadania oraz parametru złożoności co broni przed nadgorliwymi oraz niesłownymi, niedoświadczonymi osobami i ich złym szacowaniem trudności zadania.
- Daje nam szansę zauważyć problemowe zadania gdy wychodzimy poza skalę (8 SP, 13 SP) i ich porcjowanie
- Oddziela złożoność od czasu, dzięki czemu możemy szybko zauważyć spowolnienie w wydajności zespołu który w teorii powinien tak samo reagować na podobny nakład pracy. Można zauważyć to już w czasie sprintu, że nie uda nam się go dokończyć, dzięki czemu możemy reagować i negocjować dowiezienie części wstępnie zakładanego celu - czyli uniknięcie porażki.
- Pozwala zaplanować dalszą strategię na podstawie mierzalnych statystyk (a nie instytutu danych z d...) i prowadzić negocjacje co do planów produktowych z key stakeholderami w taki sposób, by zespół nie musiał stresować się deadlineami i mógł dowozić rzeczy bez presji oraz w należytym standardzie.
1
@clonazepam
Odpowiem w poście nie komentarzu.
Ale w czym przeszkadzają tu SP? bo nie rozumiem. Możesz obliczyć sobie wszystko i odpowiedzieć klientowi.
Na podstawie czego mam obliczyć? SP w których estymują programiści? Przecież SP nie powinno się przekładać na czas. A może mam olać estymacje zespołu, wystawić palec za okno i wpisać liczby z d**y które mi przyjdą do głowy?
Programista za to nie odpowiada tylko zarządzający nim.
Lol.
3
Ąowski napisał(a):
Ale czy nie jest to koniec końców, nie jest to mapowane na czas i do tego ludzie tego używają w większości przypadków? (chociaż w tym co napisałeś rozumiem, że po prostu to mapowanie na czas odbywa się później niż większość osób, łącznie ze mną, tu zakłada)
Na koniec i tak wszystko się mapuje na pieniądze, To może od razu robić wycenę w $$$?
" a jedynie parametr używany do statystyk. Statystyk, które mogą określić ile coś nam zajmie czasu, jeśli ktoś umie ją robić." - jakie są pozostałe parametry w takim razie? Nie pytam oczywiście o wszystkie, ale jakieś przykłady, może pomoże mi to zrozumieć.
Pokrycie testami, liczba błędów, czas poprawienia błędu, koszty utrzymania środowisk, liczba wykrywanych luk bezpieczeństwa i czas ich łatania, liczba US na sprint. Wolę podejście, że szukam narzędzia (np. wskaźnika) do rozwiązania problemu, a nie szukam problemu, bo ktoś wymyślił jakiś wskaźnik. Większość problemów w korpo wynika z tego, że ktoś wyciągnął z d...y jakiś wskaźnik, dołożył do niego wartość referencyjną, jaka mu się wydaje słuszna i jeżeli był na odpowiednio wysokim stanowisku, to całą robota leży, bo trzeba coś zredukować, albo podbić.
Kolejna sprawa, w jakim celu takie statystyki prowadzić w takim razie? Oprócz tego, że mogą one określić ile coś nam zajmie czasu? Pytam niezłośliwie, chętnie się dowiem, nie twierdzę, że miałem albo mam rację. Moje wypowiedzi bazowały na moim dotychczasowym doświadczeniu.
Bo ktoś, gdzieś kiedyś wziął założenia agile, poszedł z ofertą konsultingu przy wdrażaniu tych szczytnych idei w korpo, a pierwszym pytaniem było "ale skąd wiemy, czy zespół, który bierze kasę faktycznie coś robi?". Realnie, to istnienie tych numerków, wskaźników, procedur, procesów pozwala na dostarczenie biznesowi wrażenia, że płonący burdel, nie płonie aż tak bardzo i nie jest aż tak bardzo burdelem. Poczucie kontroli nad chaosem redukuje liczbę napadów paniki.
9
piotrpo napisał(a):
Na koniec i tak wszystko się mapuje na pieniądze, To może od razu robić wycenę w $$$?
Ciekawy pomysł aczkolwiek w większości firm raczej nie przejdzie, bo mało kto chce, żeby programiści wiedzieli ile klient płaci za godzinę :D
1
clonazepam napisał(a):
Czas uzyskujesz pośrednio poprzez informację jak dużo story pointów udaje się zrealizować w danym okresie czasu całemu zespołowi, bądź nawet lepiej - ile średnio czasu zajmują nam zadania wycenione na tyle a tyle story pointów przez jakiś okres czasu. Musisz mieć do tego zespół, który ma podobne spojrzenie na wycene (to się szybko samo wyrównuje podczas prowadzenia refinementu).
Rozumiem co chcesz przekazać, ale wciąż mam wrażenie, że w większości sprowadza się to przeliczania tych punktów na czas w którymś momencie.
Moje obecne rozumienie jest takie, że jest to pewna abstrakcja przy użyciu, której ludziom powinno łatwiej się pracować czy estymować.
Z tym, że w większości ludzie widzą to mapowanie i raczej nie dają się przekonać, żeby myśleć o story pointach, a nie o czasie - i to nie tylko programiści, w poprzedniej firmie w której pracowałem ludzie zarządzający projektem również byli za tym, żeby gdzieś na boku, podczas estymacji, każdy miał karteczkę, która mówi ile punktów to ile czasu.
Może idea wielka, ale może po prostu nie jest zbyt praktyczna skoro nikt jej nie chce używać lub zrozumieć?
1
Ale macie problemy. Estymacja jest ważna i tylko dureń tego nie rozumie więc tego nie będę tłumaczył.
A to, że jest wyceniane w SP a potem przeliczane na czas w niektórych w firmach (w celu dostarczenia terminów klientowi np.) to tylko ułatwienie.
Wygodniej mi ocenić 10 różnych tasków na 5 (łącznie 50) zamiast zastanawiać się ile zajmie dany task. Skoro jeden zajmie 3 dni, drugi zajmie 5 dni, inny zajmie 4 dni (bo to tylko estymata). To zamiast pisać 3-5 dni przy każdym tasku daję 5 SP.
Tak samo z prostymi zadaniami, jedno zajmie 1h, drugie 15minut, trzecie 2 godziny. Zamiast to rozdrabniać dajemy każdemu 1 SP i problem z głowy. U mnie w zespole estymacja zajmowała 5 minut na 20 zadań i każdy był zadowolony.
Czasem dodanie prostego przycisku może być problematyczne a biznes o tym nie wie - informujemy go przez SP i tyle
8
anonimowy napisał(a):
Ale macie problemy. Estymacja jest ważna i tylko dureń tego nie rozumie więc tego nie będę tłumaczył.
Estymacja tasków w sprincie to albo nonsens albo kompletna strata czasu i tylko dureń tego nie rozumie więc tego nie będę tłumaczył.
A to, że jest wyceniane w SP a potem przeliczane na czas w niektórych w firmach (w celu dostarczenia terminów klientowi np.) to tylko ułatwienie.
Wygodniej mi ocenić 10 różnych tasków na 5 (łącznie 50) zamiast zastanawiać się ile zajmie dany task. Skoro jeden zajmie 3 dni, drugi zajmie 5 dni, inny zajmie 4 dni (bo to tylko estymata). To zamiast pisać 3-5 dni przy każdym tasku daję 5 SP.
W tym przypadku faktycznie nie ma mowy o stracie czasu - widać natomiast kompletny bezsens tego procederu.
Wbijcie sobie bota, który każdemu taskowi da 1SP, albo 5SP, ewentualnie losowo -> wyjdzie na to samo.
4
W tym przypadku faktycznie nie ma mowy o stracie czasu - widać natomiast kompletny bezsens tego procederu.
Wbijcie sobie bota, który każdemu taskowi da 1SP, albo 5SP, ewentualnie losowo -> wyjdzie na to samo
PO do mnie - Kamil, ale nie może być tak iż każdy task którego nie rozumiesz estymujesz na 3 SP XD
Zaraz po tym powiedziałem 5 SP
0
jarekr000000 napisał(a):
Estymacja tasków w sprincie to albo nonsens albo kompletna strata czasu i tylko dureń tego nie rozumie więc tego nie będę tłumaczył.
Nie zamierzam się zastanawiać, kto jest durniem, a kto nie. Natomiast fakt faktem, że jeśli ogarniętemu programiście dasz tydzień na zadanie, które da się skończyć w cztery dni to będzie on to robił tydzień. A jak mu dasz dwa tygodnie - to będzie robił je więcej niż tydzień.
Estymacje w sprintach to właśnie takie szacowanie złożoności zadania - jak coś jest trudne to dostaje więcej SP, jak coś jest proste to mniej. Dzięki temu mniej-więcej wiadomo, ile trudnych, a ile prostych rzeczy da się wciągnąć. Oczywiście estymacje nie są potrzebne gdy zespół jest ogarnięty i każdy robi swoje, ale świat nie jest kolorowy i często jest tak, że ludzie potrzebują takiej informacji w stylu "to nie jest takie trudne, nie powinno zająć ci długo".
3
KamilAdam napisał(a):
To czemu od początku nie można estymować w dniach i to takich normalnych gdzie występują liczny 4 i 6?
Bo ludzie nie potrafią estymować w godzinach - zazwyczaj mocno zawyżają swoje umiejętności, pomijają zewnętrzne czynniki mające wpływ na pracę, i w efekcie podają zaniżone estymacje.
Po prostu jednostka czasu nie niesie ze sobą wszystkich informacji potrzebnych do opisania tego, ile czasu zadanie może zająć.
KamilAdam napisał(a):
Ważnych taskow oczywiście nie robiłem bo wszyscy oczywiście wiedza iż najważniejsze jest wykonanie sprintu
No skoro takie rzeczy się dzieją, to wygląda na to, że PO nie wie na czym polega jego praca.
ledi12 napisał(a):
Bo scrum to patologia. Wielokrotnie mówiono i udowadniano, że estymacje w scrumie nie działają.
Ale kto i gdzie to udowodnił? I czy gdzieś działają?
bagietMajster napisał(a):
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ć.
To znaczy tyle, że pracujesz w patologii, i scrum tu nie ma wiele do rzeczy. Scrum nie wymaga ani dwóch dni spotkań, ani mergowania w ostatni dzień (to w ogóle jest jakaś aberracja).
clonazepam napisał(a):
Mamy fajną abstrakcję na skalę trudności czegoś co trzeba zrobić i przemnażamy ją przez historyczny średni czas wykonywania.
I to jest chyba główny problem - przeciętny programista nie ma pojęcia o tym, czym jest abstrakcja.
Ąowski napisał(a):
Rozumiem co chcesz przekazać, ale wciąż mam wrażenie, że w większości sprowadza się to przeliczania tych punktów na czas w którymś momencie.
Możesz policzyć miarę statystyczną na bazie rzeczywistych wartości, po wykonaniu pracy. Przeliczanie punktów na czas przed wykonaniem pracy sensu nie ma.
Z tym, że w większości ludzie widzą to mapowanie i raczej nie dają się przekonać, żeby myśleć o story pointach, a nie o czasie - i to nie tylko programiści, w poprzedniej firmie w której pracowałem ludzie zarządzający projektem również byli za tym, żeby gdzieś na boku, podczas estymacji, każdy miał karteczkę, która mówi ile punktów to ile czasu.
To pewnie ludzie, którzy ruszają wargami przy czytaniu i patrzą na dźwignię skrzyni biegów podczas jazdy samochodem. Nie przejmowałbym się nimi.
KamilAdam napisał(a):
W tym przypadku faktycznie nie ma mowy o stracie czasu - widać natomiast kompletny bezsens tego procederu.
Wbijcie sobie bota, który każdemu taskowi da 1SP, albo 5SP, ewentualnie losowo -> wyjdzie na to samoPO do mnie - Kamil, ale nie może być tak iż każdy task którego nie rozumiesz estymujesz na 3 SP XD
Zaraz po tym powiedziałem 5 SP
No to jest kolejna patologia, znowu nie związana ze scrumem - czemu ktoś chciał wyceniać zadania, którego ktoś w zespole nie rozumie?
3
Czy ktokolwiek tutaj czytał jakąkolwiek książkę o Agile, czy może jednak wasze opinie się opierają tylko na tym co usłyszeliście w pracy i zabawie w głuchy telefon?
Estymacja tasków w jednostce czasu (godziny, dni, tygodnie) nie ma sensu i mija się z celem. Cały sens story pointów jest taki że to jest bezjednostkowa wartość. Mają służyć do tego żeby porównać skomplikowanie dwóch feature'ów (np 3 vs. 5) bez podania absolutnego czasu, obietnic, terminów czy deadline'ów, bo to w ogóle nie jest po to. Story pointy nie są po to żeby na ich podstawie szacować czas wykonania, i każdy kto prosi/wymaga jakiś czasowych estymacji stosuje faux-agile.
5
Riddle napisał(a):
Czy ktokolwiek tutaj czytał jakąkolwiek książkę o Agile, czy może jednak wasze opinie się opierają tylko na tym co usłyszeliście w pracy i zabawie w głuchy telefon?
Estymacja tasków w jednostce czasu (godziny, dni, tygodnie) nie ma sensu i mija się z celem. Cały sens story pointów jest taki że to jest bezjednostkowa wartość. Mają służyć do tego żeby porównać skomplikowanie dwóch feature'ów (np 3 vs. 5) bez podania absolutnego czasu, obietnic, terminów czy deadline'ów, bo to w ogóle nie jest po to. Story pointy nie są po to żeby na ich podstawie szacować czas wykonania, i każdy kto prosi/wymaga jakiś czasowych estymacji stosuje faux-agile.
No ładnie w książce przeczytałeś. Nijak się to ma do rzeczywistości i tego w jaki sposób SP są używane.
Klasyczny Agile. W teorii inny w praktyce inny. Jak religia.
3
Czitels napisał(a):
No ładnie w książce przeczytałeś. Nijak się to ma do rzeczywistości i tego w jaki sposób SP są używane.
No nie wiem o jakiej "rzeczywistości" mówisz, bo normalnie zespoły z tego korzystają w taki sposób jak opisałem, jest to powszechnie stosowane. Jeśli w Twojej "rzeczywistości" tak nie jest, to widocznie miałeś nieszczęście trafić do firm które stosują faux-agile.
Czitels napisał(a):
Klasyczny Agile. W teorii inny w praktyce inny. Jak religia.
Agile po prostu działa lepiej niż alternatywy (ale prawdziwe agile, a nie faux-agile). Nie chodzi o czyjąś preferencję, albo o to w co ktoś wierzy - chodzi o to co działa, chodzi o rezultat. I zespoły które są agile, po prostu dostarczają więcej i szybciej, niż zespoły które w których np są takie cyrki jakie są opisane w tym wątku.
Dookoła Agile jest dużo mitów i miskoncepcji - że trzeba mieć sprinty, że trzeba mieć spotkania, daily, jiry, etc. Sporo wynika z braku edukacji tego czym agile jest i jak go wprowadzić. Ja tutaj obwiniam o to grę w głuchy telefon. Że jeśli ktoś mówi o Agile, to mówi skrótami, zamiast odesłać kogoś do źródła, ten ktoś potem też mówi większą ilością skrótów, potem kolejna osoba jeszcze większą, i cały pomysł się rozmywa - Martin Fowler opisuje to "semantic diffusion", gdzie jakiś pomysł jest przekazywany z ust do ust (Gdzie nikt nie sprawdza orginału), to pomysł karykaturuje się w jakąś inną wersję - i tak właśnie Agile przerodził się w faux-agile (Tak samo TDD się przerodziło w "po prostu testy", devops się przerodził w "serwer na aws", a mikroserwisy w "dużo kontenerów w k8s").
Agile to nic innego jak reagowanie na zmiany, startowanie z punktu wyjścia że się jest w błędzie, wpuszczenie minimalnej wersji (kilka godzin max), danie klientowi, zebranie feedbacku, iteratywne podejście, developowanie małymi krokami. Cała ta otoczka, ze sprintami, daily, scrumem, jirą, to są rzeczy które są nałożone na doczepkę już później.