On 16/08/2013 20:26, Wojciech Muła wrote:
> On Thursday, August 15, 2013 11:44:34 PM UTC+2, Andrzej Jarzabek wrote:
>>
>> Ej, to wy naprawdę interpretujecie w ten sposób, że jak jest napisane
>> ile godzin, to właśnie ma być tyle godzin i nie można tego zmienić na
>> retrospektywie?
>
> 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.

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

Teoria jest taka, że żeby w ogóle z dziesiątek czy setek możliwych
rzeczy, które da się zrobić, sensownie wybrać te, które zrobić warto,
trzeba mieć estymaty wartości i kosztów. Estymowanie wartości w scrumie
leży po stronie product ownera, estymata kosztów (głównie w postaci
roboczogodzin) po stronie zespołu. Jeśli zespół spędzi za dużo czasu na
estymowaniu kosztów, to zostanie mu mniej czasu na development - po
przekroczeniu pewnego progu nawet jeśli estymaty są dokładniejsze i
każda godzina poświęcona implementowaniu itemów jeest bardziej
produktywna, to ogólnie zespół jest mniej produktywny, bo spędza za dużo
czasu na estymowaniu.

Zarówno timebox na planowanie jak i zaangażowanie całego zespołu służą
temu, żeby z jednej strony kontrolować koszty estymacji, a z drugiej
strony w ramach tych kosztów mieć jak największą dokładność.

Oczywicie estymacja dlatego jest estymacją, że jest czasem błędna. To
normalne. Jeśli natomiast regularnie problemem jest to, że estymaty są
"z kosmosu" (i w związku z tym regularnie albo się nie wyrabiacie ze
sprintem, albo wam zostaje czas), to są od tego też przecież odpowiednie
środki. 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. Częstym powodem jest np. to, że backlog
items są za mało rozdrobnione.

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?

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

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

> Nawet jak biznes mówi, że czegoś potrzebuje
> na już, to się nie da: bo nie ma wyceny, bo nie było planowania, bo
> trzeba taski rozpisać, itd.
>
> Miałem kiedyś taką sytuację, że napisałem coś poza sprintem na prośbę prezesa
> i PO. Zespół miał gigantyczne pretensje - do mnie, do PO i prezesa rzecz jasna.
> To, że dzięki temu firma sprzedała kilka rzeczy już się nie liczyło. Świat
> postawiony na głowie.

Bardzo dużo softu się pisze w ten sposób, że normalny cykl release trwa
miesiące (powiedzmy pół roku), a nadzwyczajny (bug fixes, drobne
poprawki) tygodnie. Do takiego cyklu z grubsza przystosowany jest Scrum.

W takim układzie też się wbrew pozorom zdarza dość często, że prezes czy
inny kierownik wbiega z czymś, co jest niby bardzo ważne i trzeba zrobić
DO PIĄTKU, a potem i tak się okazuje, że ta bardzo ważna rzecz do
produkcji wchodzi pół roku później.

W przypadku Scrumu da się rzeczy zrobić relatywnie szybko w normalnym
toku - jeśli masz tygodniowe sprinty i w połowie tygodnia wyjdzie sprawa
nowego super istotnego ficzeru, to (zakładając, że zespół da radę ten
ficzer zaimplementować w ciągu tygodnia) można go mieć w produkcji
tydzień z hapiem później w poniedziałek (w zależności ile opsom zajmuje
rollout). To normalnie jest bardzo dobry wynik.

Jeśli to jest super super super ważny ficzer i nie można poczekać nawet
tego tygodnia, to istnieją w scrumie środki nazdywczajne, które można
wprowadzić dużym kosztem, ale jeśli to takie ważne, to chyba warto
poświęcić kilka zespołoroboczodni.

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

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ą. Miałem okazję
posłuchać się trochę temu, jak pracują zespoły gdzie faktycznie droga
"od pomysłu do przemysłu" może trwać tylko kilka dni, w trybie
continuous delivery lub continuous deployment i z ciekawych pomysłów
jako alternatywy do iteracji to jest agile'owa wersja kanbana. To wymaga
bardzo ścisłej dyscypliny testowej, bo implikacja jest taka, że każdy
udany build po commicie może być wdrożony do produkcji (lub
automatyczniee jest wdrażany).

>>> Zawsze dzielimy, ale tylko ze względów praktycznych - planning z PO +
>>> osobno rozpisywanie zadań i estymaty godzinowe. I np. to też krytykuję w
>>> SCRUM-ie, że programers zajmuje się analizą całości projektu. Idiotyczne
>>> marnotrawstwo czasu.
>>
>> To jest kilka godzin.
>
> 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?

> Jaki jest sens, żeby każdy wiedział, co trzeba zrobić w każdym tasku,
> skoro i tak w praktycy zajmie się nim kilka osób? U nas zadanie robi
> najczęściej jedna osoba, rzadziej 2, bardzo rzadko więcej ludzi.

Przy planowaniu taski się robi głównie po to, żeby wyłapać błędy we
wstępnej estymacji - rzeczy, których się nie przewidziało, zapomniało,
nie zauważyło. Angażuje się do tego cały zespół, bo im więcej ludzi, tym
większa szansa, że ktoś coś istotnego (wpływającego na estymację) zauważy.

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 stronybrakuje 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ć?

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