Dlatego estymowanie przez poziom trudności jest lepsze a te czasowe to jest patola mid managmentu
Łatwe zadanie można zrobić w 2 godziny ale można się też tydzień męczyć i mówię tu o uczuciwej pracy.
@keksoa: no ale do czego niby przydaje się wtedy takie estymowanie? Co to komu daje że masz 3 proste, 1 średnie i 1 trudne zadanie? Estymowanie czasu ma powiedzieć czy albo na kiedy wyrobimy się z
@gardziok: To co masz dowieść powinno się ustalać w trakcie planowania na przyszły sprint a estymacja jest dla zespołu. Możesz mieć łatwe zadanie ale siermiężne jak dopisanie testów, dajesz niskie ST i takie zadanie może sobie wziąć junior i klepać przez tydzień. Trudne zadanie może wymagać dużej wiedzy, bierze je sobie senior i juniora do przyuczenia na przykład.
Takie typowe utrzymanie powinno być robione w kambanie, szefuńcio sobie wrzuca pilne
@gardziok: i ważne jest to że ficzer jest dostarczany jako zespół dlatego w scrumie powininienes mieć małe zespoły. To nie jest tak co też się zdarza że na planowaniu wszystko jest zrzucane na jedną czy dwie ogarnięte osoby.
Jak ficzer nie jest dostarczony to masz retro i kminisz dlaczego się nie udało.
@gardziok: praktyczny przykład masz system płatności i pojawia się wymaganie obsługa blika. Tworzony jest sprint sprint którego celem jest dodanie działającej obsługi płacenia blikiem z poziomu API.
Masz zespół 2,3 kuców i oni wraz z resztą ludzi rozpisuja zadania i ustalaja że sprint będzie trwał półtora miesiąca, koniec sprintu to ta działająca funkcjonalność.
Mija ten czas. Masz retro, jak ficzer udaje się wdrożyć to ludzie dają sobie kudosy i kminisz
@gardziok: w trakcie tego sprintu kuce mogą stwierdzić że oni nie chcą robić daily i tak naprawdę mają do tego prawo bo właśnie to jak wewnętrznie jest zorganizowana praca to sprawa tych kuców a nie jakiegoś kołnierzyka. I o tym mówi scrum i agile
- estymaty są czasowe a nie powinny być, taka jest idea że nie podajesz daty tylko poziom trudności
@keksoa: najlepiej jak taki developerek powie na daily że dziś coś skończy i mu się to nie udaje. Następnego dnia kodzi jak szalony byleby zdążyć na daily by powiedzieć że udało mu się zrobić to co powiedział. Wszystko po to by na daily usłyszeć "aha, ok to kto następny?". Niektórzy programiści stają
@gardziok: masz zespol 20 osob na backendzie i mozesz na przyklad stwierdzic, ze 3 osoby robia sprint a, 5 osob robi sprint b a reszta robi w kambanie i lata bledy. jak robota jest dobrze zorganizowana, co jest rzadkie, to w taki latwy sposob mozna sie "skalowac" horyzontalnie, ale to wymaga: - dobrego architekta, DDD sie klania, wydzielenie subdomen, kontekst blablabla - dobrego PO ktory rozumie i projekt i klienta
Niektórzy programiści stają się takim dozorcą niewolników a konkretnie samego siebie xD
@Ilirian: i o to dokladnie chodzi, i taki jest praktyczny cel. bo jak masz tablice to po cholere masz codziennie mowic co robiles? widac doskonale jak jakies zadanie wisi za dlugo w kolumnie in progress i nie trzeba wcale codziennych spotkan. mozna sie zapytac przez teamsy albo umawiajac jakies mniejsze spotkanie
ustalaja że sprint będzie trwał półtora miesiąca, koniec sprintu to ta działająca funkcjonalność.
@keksoa: na jakiej podstawie to niby ustalają? To jest właśnie estymowanie czasu. Patrzy się na to co jest do zrobienia i estymuje ile czasu to zajmie. W Twoim przykładzie półtora miesiąca. Mam wrażenie, że jak większość scrum masterów próbujesz zaklinać rzeczywistość, że nie powinno się estymować czasu. Albo że nie jest to potrzebne. Jest to potrzebne biznesowi,
Mam wrażenie, że jak większość scrum masterów próbujesz zaklinać rzeczywistość, że nie powinno się estymować czasu. Albo że nie jest to potrzebne. Jest to potrzebne biznesowi, bo ktoś musi decydować czy opłaca się inwestować w dany ficzer, albo do planowania budżetu albo musi wiedzieć na kiedy może coś obiecać klientom.
@gardziok: tak i ludzie estymuja czasowo bo biznes wymaga, efektem sa obsuwy, w korporacjach sa absurdalne wrecz, o rok, widzialem
@gardziok: no ale to dziala, elon mask od 10 lat gada ze za rok bedzie autonomiczny samochod, gdyby uczciwie powiedzial ze nie wie to by kasa nie splynela ale to akurat obrzydliwa i nieracjonalna czesc ludzkiej natury ktora no jest i nic nie zmienisz.
@keksoa: Problem ze scrumem jest to, że często jest źle wprowadzany, a ludzie traktują go jako przykrą konieczność i wszystkie te meetingi są o kant d--y rozbić bo retro sprowadza się do tego, że na 10 osób odzywają się 4.
@Bzikacz: dlatego zespol musi byc maly, w szkole tak samo sie dzialo jak grupa byla za duza, jak masz 2-4 osoba grupe to duzo trudniej byc anonimowym i sie na przyklad #!$%@?, niz jak masz 10 osobowa, zreszta nie da sie przeprowadzac fajnych spotkan w tak duzej grupie.
@keksoa: o to właśnie chodzi w estymatach, że nigdy nie są dokładne. Taka ich natura. Estymowanie czasu ma tą zaletę, że po fakcie jesteś w stanie sprawdzić o ile się pomyliłeś i wyciągnąć wnioski. A jak estymujesz w story pointach, poziomach trudności albo rozmiarach koszulek to po fakcie nie możesz stwierdzić że "estymowaliśmy na 5 punktów a w rzeczywistości było 6,3".
@keksoa Zgoda, z mojego doświadczenia dodałbym; zespół działa zwinnie, albo próbuje a całe otoczenie kładzie na to lagę, chroniczny brak product ownera lub niekomptentny PO plus to nastawienie do pracy 'w projekcie', a nie 'z produktem'; ogólnie jeżeli produkt nie przynosi kasy do firmy, to jest c--j a nie scrum zazwyczaj
"estymowaliśmy na 5 punktów a w rzeczywistości było 6,3"
@gardziok: Ale o to właśnie chodzi, żeby dev podczas rzucania "estymaty" nie zawracał sobie głowy takimi drobiazgami - z punktu widzenia przewidywania złożoności 5.0 SP czy 6.3 SP to ta sama klasa problemu. Stąd też pomysł na użycie liczb z ciągu Fibonacciego.
A jeszcze lepsze jest wycenianie w rozmiarach koszulek albo rasach psów - bo tu nie trzeba wielkiej mądrości, żeby
Jak dobrze, że rodzice uchronili nas przed takimi zarobkami wyganiając od kompa i zmuszając do nauki. Dzięki temu dzisiaj możemy się cieszyć pracą kołchoźnika, którą uwielbiamy robić( ͡°͜ʖ͡°) #heheszki
![Luksusowy pstryczek z PRL [Adam Śmiałek]](https://wykop.pl/cdn/c3397993/61419f4724102fa29499d7a9d89fa296769b112f9fb14417eb12d5a3613852fb,q80.jpg)
#pracait #programista15k
@keksoa: no ale do czego niby przydaje się wtedy takie estymowanie? Co to komu daje że masz 3 proste, 1 średnie i 1 trudne zadanie?
Estymowanie czasu ma powiedzieć czy albo na kiedy wyrobimy się z
Takie typowe utrzymanie powinno być robione w kambanie, szefuńcio sobie wrzuca pilne
Jak ficzer nie jest dostarczony to masz retro i kminisz dlaczego się nie udało.
Masz zespół 2,3 kuców i oni wraz z resztą ludzi rozpisuja zadania i ustalaja że sprint będzie trwał półtora miesiąca, koniec sprintu to ta działająca funkcjonalność.
Mija ten czas. Masz retro, jak ficzer udaje się wdrożyć to ludzie dają sobie kudosy i kminisz
@keksoa: najlepiej jak taki developerek powie na daily że dziś coś skończy i mu się to nie udaje. Następnego dnia kodzi jak szalony byleby zdążyć na daily by powiedzieć że udało mu się zrobić to co powiedział. Wszystko po to by na daily usłyszeć "aha, ok to kto następny?". Niektórzy programiści stają
- dobrego architekta, DDD sie klania, wydzielenie subdomen, kontekst blablabla
- dobrego PO ktory rozumie i projekt i klienta
@Ilirian: i o to dokladnie chodzi, i taki jest praktyczny cel. bo jak masz tablice to po cholere masz codziennie mowic co robiles? widac doskonale jak jakies zadanie wisi za dlugo w kolumnie in progress i nie trzeba wcale codziennych spotkan. mozna sie zapytac przez teamsy albo umawiajac jakies mniejsze spotkanie
@keksoa: na jakiej podstawie to niby ustalają? To jest właśnie estymowanie czasu. Patrzy się na to co jest do zrobienia i estymuje ile czasu to zajmie. W Twoim przykładzie półtora miesiąca.
Mam wrażenie, że jak większość scrum masterów próbujesz zaklinać rzeczywistość, że nie powinno się estymować czasu. Albo że nie jest to potrzebne. Jest to potrzebne biznesowi,
@keksoa: brzmi jak przepis na nie zrobienie niczego
@gardziok: tak i ludzie estymuja czasowo bo biznes wymaga, efektem sa obsuwy, w korporacjach sa absurdalne wrecz, o rok, widzialem
@Bzikacz: dlatego zespol musi byc maly, w szkole tak samo sie dzialo jak grupa byla za duza, jak masz 2-4 osoba grupe to duzo trudniej byc anonimowym i sie na przyklad #!$%@?, niz jak masz 10 osobowa, zreszta nie da sie przeprowadzac fajnych spotkan w tak duzej grupie.
@gardziok: Ale o to właśnie chodzi, żeby dev podczas rzucania "estymaty" nie zawracał sobie głowy takimi drobiazgami - z punktu widzenia przewidywania złożoności 5.0 SP czy 6.3 SP to ta sama klasa problemu. Stąd też pomysł na użycie liczb z ciągu Fibonacciego.
A jeszcze lepsze jest wycenianie w rozmiarach koszulek albo rasach psów - bo tu nie trzeba wielkiej mądrości, żeby