On 17/08/2013 22:27, Wojciech Muła wrote:
> 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.

Weź pod uwagę, że planowanie ma tylko jeden cel - wybranie itemów do
realizacji w czasie sprintu. W tym celu się robi szacunki, żeby można
było określić, ile itemów się da zrobić, i w tym celu się planuje taski
- żeby wyłapać na wczesnym etapie rzeczy wpływające na extymaty (w jedną
i w drugą stronę). Wszystko, co tej decyzji nie służy trzeba wypchnąć
poza timebox planowania.

Oczywiście takie szacunki zawsze są obciążone jakimś ryzykiem błędu i
teoreytycznie można powiedzieć, że każdy dodatkowy czas poświęcony na
analizę i planowanie zadań może przynieść dodatkowe informacje. Pytanie
jednak, ile czasu warto poświęcać na planowanie czegoś, co potencjalnie
w ogóle nie będzie implementowane.

Jeśli na zasadzie wyjątku się zdarzy, że akurat ewidentnie poświęcenie
więcej czasu da istotną rewizję szacunku wpływającą znacząco na to, co
się da, a czego nie da zrobić, to można podejść do sprawy na dwa
sposoby. Po pierwsze, jeśli jest konsensus że warto, to można wyjątkowo
jednorazowo naruszyć timeboxa.

Z drugiej strony można zdecydować, że nie poświęci się dodatkowego czasu
i użyć takiej estymaty, jaką się ma, ewentualnie uwzględniając
istniejącą niepewność w wariancie pesymistycznym (jeśli wygląda na to,
że coś może zająć dwa razy tyle czasu, ale nie ma czasu, żeby zbadać czy
na pewno, to założyć, że zajmie; jeśli wygląda na to, że coś może
zamiast tygodnia zająć pięć minut, to założyć, że nie zajmie). Założenie
jest takie, że jeśli się akurat tę rzecz źle oszacuje to nic strasznego
się nie stanie, bo błędne estymaty zdarzają się dość często i tak, a
poprawność ich jest tylko statystyczna - jeśli jedne rzeczy
przeszacujesz, a inne niedoszacujesz, to w ramach sprintu powinno się
zwykle wyrównać. Jeśli systematycznie estymaty się mylą w jedną stronę,
to znowu kwestia do rozpatrzenia na retrospektywie - dlaczego?

Ostatecznie ponieważ jest to jednorazowe zdarzenie, to nie ma większego
znaczenia, na którą opcję się zdecydujecie. Na retrospektywie trzeba się
zastanowić czy nie wynikało to z błędów (np. że się zbyt wiele czasu
poświęcało na zbyt szczegółową analizę innych itemów, co niewiele
wnosiło do szacunków, i na inne itemy nie zostało czasu w ogóle lub
zostało bardzo niewiele). Wniosek też może być taki, że okoliczności po
prostu były wyjątkowe i wasz proces ich nie przewidział i nie powinien
być modyfikowany żeby je przewidywać, bo najprowadopodobiej się nie
powtórzą. Jeśli "wyjątkowe" okoliczności zaczynają się powtarzać, to
trzeba się zacząć zastanawiać nad zmianami.

> Ale główny problem jest taki, że czasem dopiero po rozgrzebaniu zadania
> widać, że estymata była kosmiczna. Część modułów naszego systemu nie była
> ruszana od dawna i często nawet osoby, które je pisały nie ma pojęcia
> ile będzie kosztowała zmiana.

Trzeba pamiętać, że szacowanie ani nawet realizacja zaplanowanych itemów
nie są celami same w sobie. Celem jest maksymalizacja wartości
dostarczonej klientowi i w tym celu PO musi mieć szacunki, żeby określić
co warto robić kosztem czego i w jakiej kolejności. Jeśli musisz
wszystko rozgrzebać, żeby mieć estymaty, to wartość dostarczona
klientowi cierpi, bo poświęcasz czas na rozgrzebywanie rzeczy, któóre
nie będą dostarczone klientowi (bo po rozgrzebaniu okaże się, że nie
warto), albo z kolei będziesz robić rzeczy, które są mało wartościowe w
stosunku do kosztów, bo koszty będą znane dopiero jak już dana rzecz
będzie w 3/4 gotowa.

Szcrum zakłada, że do pewnego momentu błędy w szacowaniu nie są takim
dużym problemem, bo po pierwsze, jak pisałem, przeszacowania i
niedoszacowania się znoszą i owszem, gdyby rzeczywiste koszty były od
razu znane, to priorytety mogłyby być inne, ale zazwyczaj nie aż na tyle
inne, żeby ponosić koszty przerywania tego, co już jest "rozgrzebane" i
ponownego planowania. A jeśli się okaże, że się w znaczący sposób nie
znoszą, to zawsze jest możliwość pójścia do PO i powiedzenia "są
komplikacje i nie wyrobimy się ze wszystkim, co zaplanowaliśmy, jakby
co, to z których itemów mamy zrezygnować" lub z drugiej strony "okazało
się, że przeszacowaliśmy i mamy dodatkowe zasoby, zróbmy dodatkowe
planowanie i wciągnijmy dodatkowe itemy do sprintu". Jedno i drugie nie
jest wielkim problemem, najważniejsze żeby zrobić to jak najszybciej,
jak tylko dodatkowa informacja jest dostępna.

>> Jeśli specyfika projektu jest faktycznie taka, że regularnie zdarzają
>> się super ważne rzeczy, które trzeba wdrożyć do produkcji w ciągu kilku
>> dni, to prawdopodobnie Scrum nie jest dobrą metodologią.
>
> Nie, to się zdarzyło jak dotąd raz.

No ale rozumiesz chyba, że nie ma sensu budować procesu wokół tego, co
zdarza się jeden raz?

> Owszem, to może być powód, czasem jest za dużo dywagacji. A czasem
> jest n-ta godzina spotkania i wszyscy odlatują.

Możesz konstruktywnie zaproponowac robienie przerw :)