W ogóle estymowanie pracy w deweloperce to jest rak. Raz jest to często zgadywanka programistów, dwa wystarczy jakiś jeden p------y błąd i cała estymacja idzie w p---u.
@XanderPLXE: kiedyś słyszałem, że powinno się estymować na zasadzie "pomyśl ile to powinno zająć, następnie pomnóż przez 2 i podnieś o rząd wielkości". Czyli jak myślisz, że coś zajmie godzinę, to zajmie dwa dni. Jak myślisz, że 1 dzień, to będzie 2 tygodnie
@lukenzi: wyobraź sobie, że masz w zespole trzech programistów - juniora, mida i seniora wymiatacza. Estymowane zadanie junior będzie robił 8h, mid 4h, a senior 3h. Jak chciałbyś wycenić czas realizacji zadania przez zespół? Jak masz SP, to wiecie że takie zadanie to ok. 3SP (zamiast x godzin), zespół średnio w ciągu sprintu dowozi 30SP, no to wiecie że możecie takich zadań wziąć 10 i jest duża szansa że za
@BlackpillMonster: Co to **rwa są story pointy? Jakaś ocena scenariusza filmowego? Nawet jeżeli to jest szacowanie zadań programistycznych to dlaczego ma taką nazwe z d--y
@My5z0n: no ok, ale dalej zadanie za 3SP bedzie trwalo 8,4 albo 3h w zaleznosci od tego kto je dostanie. To sie pozniej przelicza tak, ze junior,mid,senior dowoza odpowiednio po 3,6,9 SP / sprint ?
a co to sa te story pointy i jaka jest wartosc tej waluty ?
@lukenzi: to jest próba udawania, że nie estymuje się w roboczogodzinach albo roboczodniach. Po czym project manager i tak przelicza to sobie na roboczodni w swoich excelku, i dalej przedstawia komuś nad sobą za ile dni będzie zrobione ( ͡°͜ʖ͡°)
@XanderPLXE: eee, na jedno wyjdzie, ekspert zrobi estymacje, taska przypiszą na jakiegoś mniej doświadczonego deva, ten walnie jakąś gafe bo nie wie tego, co wie ten mądrzejszy i już się plan rozjeżdża
@BlackpillMonster: Zasada jest prosta - jak myslisz, ze task zajmie 3 godziny, to dobry czas to 3 dni itp. Osoby nietechniczne maksymalnie powinny w HR pracować. Smutne, ale prawdziwe.
Przykładowo ogarnia żeby nam PO nie wrzucał tematów bokiem i ogarania wszelkie okołoprojektowe organizacyjne tematy.
@bydloszarewegierskie: To i tak dużo. U mnie scrum master pyta dlaczego nie można dorzucić jakiegoś tematu bo przecież jest on BARDZO WAŻNY i potrzebny na wczoraj (dzisiaj powstał task). ( ͡°͜ʖ͡°)
Zgodnie ze sztuką, estymować powinien specjalista w dziedzinie
@XanderPLXE: no nie do końca bo to nie on będzie robił tego taska, może sobie klepnąć aaa 3h a taska dostanie junior który tydzień będzie potrzebował, to nawet na story pointy będzie średnie
Największy problem Story Pointów jest taki, że jest to estymata, której nie da się zweryfikować nawet po fakcie - to jest jakiś absurd, że tego się używa. Oszacowaliście zadanie na 8 SP, zrobiliście, przetestowaliście i wdrożyliście. Teraz chcecie sprawdzić jak dokładnie udało się wyestymować to zadanie - no kurma, nie da się! Może to w rzeczywistości było 3, a może 21, nigdy się nie dowiesz!
ale jak mogłeś dać 15 SP skoro SP to liczby ciągu fibonnaciego?
@nad__czlowiek: poza tym nie robi sie wycen tak wysokich, bo to przekracza mozliwosci robocze osoby w ciagu springu 2tyg i dzieli sie na mniejsze kawalki by dowozic.
Osoby nietechniczne maksymalnie powinny w HR pracować. Smutne, ale
@IlawaNidzica: może to uproszczenie, może pracowała w firmie x przez 10 lat, a skończyła tę pracę na takim stanowisku. nie wnikałem, a przecież nie pójdę jej zapytać o to :) inna charakterystyczna cecha: używa nadmiernie korpo bełkotu. ciągle chce adresować różne problemy albo refajnować zadania i dzielić je na mniejsze inkrementy. słuchać się tego nie da.
@BlackpillMonster: Najlepsze są estymacje od dwóch programistów. Jeden wycenia na 10h pracy, a drugi na 30h i żaden nie ma racji, bo wychodzi 20h. Nie wiem kto w IT wymyślił, aby korzystać z estymacji czasowych, ale wiem, że to nie tak powinno wyglądać.
źródło: 96m2zm
Pobierz@XanderPLXE: kiedyś słyszałem, że powinno się estymować na zasadzie "pomyśl ile to powinno zająć, następnie pomnóż przez 2 i podnieś o rząd wielkości". Czyli jak myślisz, że coś zajmie godzinę, to zajmie dwa dni. Jak myślisz, że 1 dzień, to będzie 2 tygodnie
Jak masz SP, to wiecie że takie zadanie to ok. 3SP (zamiast x godzin), zespół średnio w ciągu sprintu dowozi 30SP, no to wiecie że możecie takich zadań wziąć 10 i jest duża szansa że za
@lukenzi: to jest próba udawania, że nie estymuje się w roboczogodzinach albo roboczodniach.
Po czym project manager i tak przelicza to sobie na roboczodni w swoich excelku, i dalej przedstawia komuś nad sobą za ile dni będzie zrobione ( ͡° ͜ʖ ͡°)
@bydloszarewegierskie: To i tak dużo. U mnie scrum master pyta dlaczego nie można dorzucić jakiegoś tematu bo przecież jest on BARDZO WAŻNY i potrzebny na wczoraj (dzisiaj powstał task). ( ͡° ͜ʖ ͡°)
@XanderPLXE: no nie do końca bo to nie on będzie robił tego taska, może sobie klepnąć aaa 3h a taska dostanie junior który tydzień będzie potrzebował, to nawet na story pointy będzie średnie
Oszacowaliście zadanie na 8 SP, zrobiliście, przetestowaliście i wdrożyliście. Teraz chcecie sprawdzić jak dokładnie udało się wyestymować to zadanie - no kurma, nie da się! Może to w rzeczywistości było 3, a może 21, nigdy się nie dowiesz!
@nad__czlowiek: poza tym nie robi sie wycen tak wysokich, bo to przekracza mozliwosci robocze osoby w ciagu springu 2tyg i dzieli sie na mniejsze kawalki by dowozic.
inna charakterystyczna cecha: używa nadmiernie korpo bełkotu. ciągle chce adresować różne problemy albo refajnować zadania i dzielić je na mniejsze inkrementy. słuchać się tego nie da.