Wpis z mikrobloga

@spec_IT: z życia wzięte to story pointsy są najbardziej bezsensownym i niemiardodajnym systemem mierniczym jaki można wymyślić, bo rozumiesz, to jest taki system, specjalnie wymyślony, żeby nie mieć odzwierciedlenia w żadnych realnych jednostkach, a przy tym nie niesie nawet ujednoliconego poziomu trudności - no wymyślili to geniusze innymi słowy :)

niektóre teamy robią normalną konwersję na poziom skomplikowania i/lub przewidywany czas wykonania:
1/2 - trywialne zadanie na mniej więcej jedną dniówkę
@spec_IT: okreslasz skomplikowanie zadania. Jak wiesz ze np masz story tylko z dodaniem tabeli to jest to np 3. Bo sa jeszcze prostsze rzeczy. A jak dochodzi do tego prosty CRUD to masz już 5. Jeżeli dojdziesz do wniosku ze to jest jeszcze bardziej wymagajace to dajesz 8. Jak wchodzisz na 13 to już jest spory sygnal ze albo story jest nie jasne, albo za duze i PO powinien z waszą
@spec_IT: wycenianie w story pointach jest #!$%@? i czasochłonne ale możliwe.

Zacznijcie od kart do planowania "planning poker". Jako pierwsze bierzecie backlog i dyskutujecie przy tym ile może zająć czasu wykonanie danej czynności, czy widzicie jakieś przeszkody itp. Przypisujecie wyceny zakładając że 1SP = napisanie majla / 15 min kodzenia. 2SP = 1h zmiana itp. Jeżeli masz problem z wyceną jakiegoś zadania to przyrównaj czy jest cięższe czy łatwiejsze od zadania
@spec_IT jak scrum master i zespół jest zaangazowany to moim zdaniem taka wycena jest mega fajna, szczególnie że podnosi często rozmowę o złożoności danego taska, często każdy złożoność widzi inaczej i wtedy trzeba zagrać pokera. Po kilku iteracjach sama wycena jest szybka i nieskomplikowana, początki bywają różne
@spec_IT: najlepiej odpowiedział ci @aseeon_
ludzie naczytali się jakichś poradników z dupy pisanych przez osoby, które nie rozumieją sensu scruma i skupiają się na takich fetyszach jak storypointy, burndown chart, planning poker, historyjki w postaci "jako x chcę y żeby z" czy oklepana formułka daily. Nikt mi nigdy nie wytłumaczył racjonalnie dlaczego używa się skali fibonacciego. SP potem mogą być używane jako bat na zespół przez management (zespół X dostarczył w
@elberet: nie estymujesz godzin bo nie jestes w stanie ich konkretnie podac. Estymujesz niewiedze, watpliwosci, zlozonosc zadania etc... uwazam to za lepsze i bardziej miarodajne jak podawanie suchych godzin, ale to potrzebuje rowniez stalego zespolu zeby velocity sie unormowalo i strzaly nie byly z dupska.