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.

> Przede wszystkim macie retrospektywę i na niej możecie używać
> takich technik jak root cause analysis, żeby identyfikować powody, dla
> których estymaty są błędne.

Dzięki, zanotowane.

> Częstym powodem jest np. to, że backlog items są za mało rozdrobnione.

Z tym nie ma problemu wg mnie. Mamy zresztą taką zasadę, że jak
wychodzi podczas planowania za dużo storypointów (u nas 21)
wówczas trzeba rozbić.

> Do stosowania dla przypadków, kiedy faktycznie nic nie wiadomo i koszty
> potencjalnie mogą być bardzo duże jest też rozwiązanie ekstremalne -
> bardzo kosztowne, ale pozwalające na dużo dokładniejszą estymację: spike
> solution - stosujecie to?

Tak, stosujemy. To się świetnie sprawdziło w paru przypadkach, np.
powstał proof of concept, który później dość niskim kosztem przekształciliśmy
na normalny kod.

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.

> A tak swoją drogą, estymaty robicie w story pointach, roboczogodzinach
> czy w czym?

Dla story - w storypointach, po rozbiciu na taski już w roboczogodzinach.

> > Mnie chodzi o podejście programistów: my se tu dłubiemy, a czy biznes
> > to sprzeda, to mamy w dupie.
>
> Naprawdę było takie zalecenie w poprzednich wersjach scrum guide?

Wg mnie wygodna nadinterpretacja. :)

> Już nie mówiąc o tym, że w wyjątkowych sytuacjach można czasem wyściubić
> nos poza Scrum Guide i podejść do sprawy tak normalnie, po ludzku
> "słuchajcie to jest ważna sprawa, ja rozumiem, że plan był robiony z
> założeniem, że Wojtek będzie z wami pracował, więc za chwilę usiądziemy
> i się razem zastanowimy co wykreślić. A jak się uda zrobić tę Super
> Ważną Rzecz, to w piątek idziemy do knajpy i firma stawia."

No to u nas zabrakło właśnie tego normalnego podejścia.

> 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. Częściej zdarzają się krytyczne
błędy z produkcji, ale z tym sobie radzimy już całkiem sensownie.
Po prostu jedna osoba przerywa swoją pracę i poprawia błąd. Wszyscy
wiemy, że może nie zrobić story, czy taska w sprincie, ale to jest
akceptowalne.

> > 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

> 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ą.

> >> Ja mam regularnie do czynienia z sytuacjami, gdzie traci się dni i tygodnie
> >> w związku z tym, że programiści nie rozumieją wymagań i istniejącej
> >> funkcjonalności. To jest dopiero marnotrawstwo.
> >
> > Macie jakieś sposoby na unikanie takich sytuacji?
>
> Wg. mnie bardzo dobrze sprawdza się właśnie spotkanie całego zespołu z
> Osobą, Która Wie O Co Chodzi i zadawanie pytań. Również byłem w
> projektach, kiedy kolaboracyjne "specification by example" sprawdzało
> się nieźle, niestety w projektach ze starym i zapuszczonym kodem bywa w
> praktyce kosztowne w realizacji (kiedy ciężko zautomatyzować testowanie
> funkcjonalności).

Dzięki.

w.