W dniu 2013-08-17 23:27, Wojciech Muła pisze:
> On Saturday, August 17, 2013 1:43:28 AM UTC+2, Andrzej Jarzabek wrote:
>>> Nie można zmienić w trakcie spotkania - timebox rzecz święta, right?
>>
>> W trakcie nie, ale jeśli generalnie wychodzi, że timebox za którki, to
>> na retrospektywie można postanowić, że się go wydłuży.
>
> No tak, tylko problem jest właśnie teraz! Po sprincie to już nie
> ma znaczenia.

Jeśli w to się zdarza w jednym sprincie, to cóż - flukutacja 8-) Ale
jeśli w drugim z rzędu, to trzeba coś zrobić, żeby w trzecim się nie
powtórzyło.

>
[...]
>> A tak swoją drogą, estymaty robicie w story pointach, roboczogodzinach
>> czy w czym?
>
> Dla story - w storypointach, po rozbiciu na taski już w roboczogodzinach.

Z ciekawości - do czego potem te szacowania się przydają? Czy na
podstawie tych cyferek podejmujecie jakiekolwiek decyzje? Pytam, bo
zrezygnowaliśmy z tego szacowania, bo storypoints dla historyjek
wystarczają nam póki co.

[...]
>>> Zespół liczy 7 osób, planning trwa w praktyce od 6-8 godzin. Wychodzi co
>>> najmniej tydzień pracy jednego programisty.
>>
>> Przy jakiej długości sprintu?
>
> 3-tygodnie

Czyli ok. 5%. To nie jest dużo.

>> Jeśli z jednej strony nie widzicie tej korzyści, uważasz, że ludzie na
>> planowaniu słyszą o nieistotnych dla nich detalach (o ile nie będą
>> danego taska implementować), a z drugiej strony brakuje wam czasu w
>> timeboxie, to może problem jest po prostu taki, że za bardzo wchodzicie
>> w szczegóły przy planowaniu tasków. Może "co trzeba zrobić w tasku"
>> wystarczająco określa "zmienić schemat bazy danych", a nie trzeba mówić,
>> co w nim konkretnie trzeba zmienić?
>
> Owszem, to może być powód, czasem jest za dużo dywagacji. A czasem
> jest n-ta godzina spotkania i wszyscy odlatują.

Z obserwacji - do godziny wszyscy dobrze działają. Do półtorej są
w stanie z niejakim wysiłkiem skupić uwagę. Potem koniecznie przerwa,
bo dalsze siedzenie ciurkiem to strata czasu. Aha - przerwy oczywiście
timeboxować trzeba 8-)

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