Wpis z mikrobloga

W ogóle estymowanie pracy w deweloperce to jest rak.


@XanderPLXE: estymaty mają sens. Niestety przyjmowanie tylko jednej liczby, gdzie to powinno być zajmie tydzień ± kilka miesięcy to główny problem
  • Odpowiedz
I oczywiście Ania scrum masterka i jej z-----e teksty: czego dokładnie nie rozumiesz, kto ci może pomóc, dlaczego dałeś aż 15 story pointow?

Odpowiedz


@robert_blaszczykowski: ale jak mogłeś dać 15 SP skoro SP to liczby ciągu fibonnaciego?
1, 2, 3, 5, 8, 13, 21, 34 itd większych estymat raczej sie nie daje

jakies 15 SP to wygląda na wycenianie w godzinach czy man-dayach xD
  • Odpowiedz
@BlackpillMonster wy sobie sami estymujecie swoje taski? U nas osoba przypisana do taska robi krótkie streszczenie (co trzeba zrobić, plan implementacji, zakres testów/qa) i potem cały team głosuje. Dzięki temu nie ma narzekań i jakichś dziwnych 13sp przypisanych do 5sp taska
  • Odpowiedz
a co to sa te story pointy i jaka jest wartosc tej waluty ?


@lukenzi: Wartość, to około 4 roboczogodzin na 1SP, chociaż bardziej odpowiednie byłoby określenie - jak bardzo skomplikowane jest zadanie - im więcej SP - tym trudniejsze.
  • Odpowiedz
@nad__czlowiek: 15 sp w jednym teamie to nie to samo co 15 sp w innym.
Na chłopodni można przekładać jak już team przerobi te kilka/naście sprintów i wyrabia w miare stałą liczbe sp. A fibonacci, to nie przymus, można też używać skali liniowej.
  • Odpowiedz
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: ale właśnie dlatego to się nazwa "estymata". Tu nie chodzi o to, że każdy task musi być dokładnie oszacowany, a bardziej o to, że w przewidywalnym czasie (zwykle sprint) zespół wykona przewidywalny zakres pracy (sprint scope). Jeden task wyceniony na 13 okaże
  • Odpowiedz
Zgodnie ze sztuką, estymować powinien specjalista w dziedzinie, a wiadomo że robi to jakiś random, albo sami programiści, nawet juniorzy. ¯\(ツ)/¯


@XanderPLXE: Z którą sztuką, bo w scrumie, a zdaje się o tym mówi ten mem estymuje cały zespół?
  • Odpowiedz
@robert_blaszczykowski: Czytajac Ciebie mam flashbacki z tego jak zaczynalem 1.5 roku temu i mialem identyczne odczucia - po prostu nie wiedzialem czego nie wiem xD spoko, ze nie tylko ja tak mialem, bo pierwsze pol roku to byla deprecha straszna i nie raz mialem ochote to rzucic wpizu.
  • Odpowiedz
Zgodnie ze sztuką, estymować powinien specjalista w dziedzinie


@XanderPLXE: Tu też jest problem. Ja wycenię coś na 4 h, bo wiem, że mi zajmie 2 i kolejne 2 spędzę na Wykopie, ale jak będę akurat zajęty czymś innym i dam podwładnemu, to on to zrobi w 8 h.
  • Odpowiedz
@lukenzi: No ja nie jestem Scrum Masterem, więc ci nie powiem. Po prostu w trakcie wyceniania tasków kiedyś 1SP to przekładało się na około 4 godziny roboty w moim przypadku. Może w innych firmach jest inaczej.
Moim zdaniem to pozwala na ułożenie zadać w sprincie - godzin masz zawsze tyle samo, a zadań masz różną ilość. Na podstawie SP możesz sobie wybrać w łątwy sposób zadania, które weźmiesz do sprintu.
  • Odpowiedz
Coś o SP, czego wieszkość nie rozumie.
Jeśli estymata jest wyceniona na załóżmy 13SP (przyjmijmy ~2 sprinty), to znaczy tyle, że US jest za duży i trzeba go rozbić na mniejsze albo zespól nie rozumie co jest do zrobienia i przeestymowuje.
Tylko tyle i aż tyle.
  • Odpowiedz
@BlackpillMonster ja nie jestem programistą i kompletnie się na tym nie znam, ale do nadzoru projektu dali nam babkę, która kompletnie nie wie nad czym pracujemy, a na spotkaniach tracimy mnóstwo czasu przez jej pytania totalnie z d--y (co więcej, z biegiem czasu pytania są wciąż te same, jakby nic nie przyswajała, zero progresu). jej sposób myślenia jest taki, że jak jeden statek wiezie towar z USA przez dwa tygodnie, to
  • Odpowiedz
Jeśli estymata jest wyceniona na załóżmy 13SP (przyjmijmy ~2 sprinty)


@jakubyoker: ja nie rozumiem dlaczego jest osobna jednostka a nie uzywa sie juz dostepnych np. czas tylko jakis przelicznik
  • Odpowiedz