W dniu 2013-08-16 21:26, Wojciech Muła pisze:
>> Pytanie jest takie - jeśli wam nie wystarczały np. cztery godziny przy
>> >dwutygodniowym sprincie, to znaczy, że osiem godzi dla miesięcznego
>> >sprintu powinno wystarczyć, ale się nie skaluje liniowo? I dlaczego nie?
>> >Przecież na dwa razy dłuższy sprint będzie do omówienia, wyszacowania i
>> >tak dalej dwa razy więcej itemów?
> Z moich obserwacji wynika, że tego nie da się przewidzieć. Być może
> wynika to ze specyfiki firmy, bo z jednej strony rozwijamy nowe systemy,
> ale mamy też na głowie kilka działających i musimy je utrzymywać oraz
> dodawać do nich nowe rzeczy.
>
> Więc czasem tylko utrzymujemy i wtedy tak naprawdę nie ma co obgadywać,
> kończymy szybko. Ale jak przychodzą nowe rzeczy, wówczas nierzadko nie
> wystarcza czasu, nawet jak rozciągniemy spotkanie na maksa i się streszczamy.
> Zresztą planowanie jest w wielu przypadkach bez sensu, ponieważ bez
> jakiegoś rozpoznania tematu przez programistów estymaty są z kosmosu.

Czyli klasyka - brakuje wizji na poziomie trochę wyższym. Skoro są
sprinty, w których "tylko utrzymujemy", to wypada się zastanowić, czy
na pewno potrzeba w ogóle pracy nad tym projektem.

Na estymaty z kosmosu znam dwie główne metody - uczyć się estymować oraz
robić proof of concept. Niektórzy twierdzą, że to nie ortodoksyjne, ale
w skrajnych przypadkach, gdy temat jest kompletnie nieznany robimy
sprint wcześniej badanie tematu. Siada jedna osoba i dwa, góra trzy dni
szuka rozwiązań, próbuje projektować, pisać jakieś mockupy, czy co tam
jeszcze potrzebne do odpowiedzi na pytanie "ile to będzie kosztowało?".
Rezultatem takiego zadania jest odpowiedź, np. "już nie między 5 a 40,
ale między 20 a 40".

Zupełnie na koniec - jeśli coś jest trudne do oszacowania, to częściej
sprawdza się oszacowanie pesymistyczne.

--
Paweł Kierski
n...@p...net