On 14/08/2013 19:12, Wojciech Muła wrote:
>
> Bawi mnie, że zmieniają pryncypia. Bo rzeczywistości nie
> da się zamknąć w 12-stronicowy SCRUM Guide. :)

Jakie pryncypia?

do góry

On Wednesday, August 14, 2013 11:06:15 PM UTC+2, Andrzej Jarzabek wrote:
> Poważnie jednak: jeśli cała reszta zespołu jest zadwolona, a ty jeden
> nie, ale też nie potrafisz zaproponować alternatywy, która by zespołowi
> odpowiadała, to może jednak problem jest taki, że nie pasujecie do
> siebie i po prostu nie powinniście być w jednym zespole?

Zespół nie jest jednorodny i w 100% zadowolony, oprócz tego za mała
firma, żebyśmy mieli duży wybór zespołów.

w.

do góry

On Wednesday, August 14, 2013 11:09:51 PM UTC+2, Andrzej Jarzabek wrote:
> > Ja się popłakałem ze śmiechu. Mówiłem kolegom, że SCRUM
> > zaczyna "odkrywać" rozwiązania znane od dziesięcioleci. :)
>
> Ale właściwie co takiego "odkrywa"? Ja w tych zmianach żadnych odkryc
> nie widzę.

To, że skoro już planujemy i jest to podstawą prac w sprincie,
to ograniczanie timeboxów ze względu na długość sprintu jest idiotyczne.
Miałem już wiele planingów, gdzie było "no, sprężajmy się, bo się
czas kończy". A potem zgrubna wycena na 5 pkt. stawała się w praniu 13 -
dramat.

Albo, że nie można zmieniać zespołów. To naturalne, że programiści
przechodzą między zespołami, bo np. projekt jest na ukończeniu i wystarczy
mniejszy skład do ustabilizowania programu, a w innym zespole właśnie
zaczynają poprawki po UAT i goni ich czas.

Położenie większego nacisku na stronę bizensową to istna rewolucja!
Moi scrumowi przyjaciele lubią mówić, że ich nie obchodzi sprzedaż. :)

> > w. (na nieszczęście [swoje] członek zespołu scrumowego)
>
> Chyba że to zespół scrumowy na zasadzie "fajnie by było nie dzielić
> planowania iteracji na dwa timeboxy, ale Święta Księga mówi, że trzeba,
> więc musimy nadal to robić, bo inaczej nie będziemy mieli Prawdziwego
> Scrumu i wszystko się zawali".

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.

w.

do góry

Użytkownik "Wojciech Muła" <w...@g...com> napisał w wiadomości
news:1eee8f09-d85d-4134-a6bf-1404cb67398d@googlegrou
ps.com...
On Wednesday, August 14, 2013 11:06:15 PM UTC+2, Andrzej Jarzabek wrote:

>Zespół nie jest jednorodny i w 100% zadowolony

Tak to tylko w erze.

do góry

On 15/08/2013 07:30, Wojciech Muła wrote:
>
> Zespół nie jest jednorodny i w 100% zadowolony, oprócz tego za mała
> firma, żebyśmy mieli duży wybór zespołów.

To ja się spytam tak - jak interpretujecie scrumowy "self organizing
team"? W Scrum Guide nie jest przecież napisane, jak to ma funkcjonować.

do góry

On 15/08/2013 07:46, Wojciech Muła wrote:
> On Wednesday, August 14, 2013 11:09:51 PM UTC+2, Andrzej Jarzabek wrote:
>>> Ja się popłakałem ze śmiechu. Mówiłem kolegom, że SCRUM
>>> zaczyna "odkrywać" rozwiązania znane od dziesięcioleci. :)
>>
>> Ale właściwie co takiego "odkrywa"? Ja w tych zmianach żadnych odkryc
>> nie widzę.
>
> To, że skoro już planujemy i jest to podstawą prac w sprincie,
> to ograniczanie timeboxów ze względu na długość sprintu jest idiotyczne.
> Miałem już wiele planingów, gdzie było "no, sprężajmy się, bo się
> czas kończy". A potem zgrubna wycena na 5 pkt. stawała się w praniu 13 -
> dramat.

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?

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?

> Albo, że nie można zmieniać zespołów. To naturalne, że programiści
> przechodzą między zespołami, bo np. projekt jest na ukończeniu i wystarczy
> mniejszy skład do ustabilizowania programu, a w innym zespole właśnie
> zaczynają poprawki po UAT i goni ich czas.

No więc znowu - jeśli nie traktujesz tego zmieniania składu zupełnie
dosłownie, to możesz w nim wyczytać taką mądrość, że jeśli przechodzisz
do fazy stabilizacji i zmniejszasz zespół, to lepiej to zrobić między
sprintami niż w trakcie.

> Położenie większego nacisku na stronę bizensową to istna rewolucja!
> Moi scrumowi przyjaciele lubią mówić, że ich nie obchodzi sprzedaż. :)

Od tego od zawsze była rola product ownera. I o tym też się w
literaturze scrumowej od dawna mówiło (o maksymalizacji wartości
klienta), tyle tylko, że scrum guide zawsze opisywał bardzo ogólny
framework, a strona biznesowa jest inna w zależności od tego czy robisz
produkt do sprzedaży, na zamówienie, na potrzeby wewnętrzne, a nawet czy
robisz bazę szlauchów czy kaloszy.

>> Chyba że to zespół scrumowy na zasadzie "fajnie by było nie dzielić
>> planowania iteracji na dwa timeboxy, ale Święta Księga mówi, że trzeba,
>> więc musimy nadal to robić, bo inaczej nie będziemy mieli Prawdziwego
>> Scrumu i wszystko się zawali".
>
> 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. 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.

do góry

On Thursday, August 15, 2013 11:44:34 PM UTC+2, Andrzej Jarzabek wrote:
> > To, że skoro już planujemy i jest to podstawą prac w sprincie,
> > to ograniczanie timeboxów ze względu na długość sprintu jest idiotyczne.
> > Miałem już wiele planingów, gdzie było "no, sprężajmy się, bo się
> > czas kończy". A potem zgrubna wycena na 5 pkt. stawała się w praniu 13 -
> > dramat.
>
> 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?

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

> > Położenie większego nacisku na stronę bizensową to istna rewolucja!
> > Moi scrumowi przyjaciele lubią mówić, że ich nie obchodzi sprzedaż. :)
>
> Od tego od zawsze była rola product ownera. I o tym też się w
> literaturze scrumowej od dawna mówiło (o maksymalizacji wartości
> klienta), tyle tylko, że scrum guide zawsze opisywał bardzo ogólny
> framework, a strona biznesowa jest inna w zależności od tego czy robisz
> produkt do sprzedaży, na zamówienie, na potrzeby wewnętrzne, a nawet czy
> robisz bazę szlauchów czy kaloszy.

Mnie chodzi o podejście programistów: my se tu dłubiemy, a czy biznes
to sprzeda, to mamy w dupie. 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.

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

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.

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

w.

do góry

On 8/16/2013 9:26 PM, Wojciech Muła wrote:
> On Thursday, August 15, 2013 11:44:34 PM UTC+2, Andrzej Jarzabek wrote:
> Mnie chodzi o podejście programistów: my se tu dłubiemy, a czy biznes
> to sprzeda, to mamy w dupie. 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.
>
Nie. IMO To Ty starasz sie przedstawic polska burdelowa rzeczywistosc
jako normalnosc. Male firmy tak dzialaja i nawet sobie radza ale przez
to zawsze beda male. Pewne zasady maja glebszy sens.

>>> 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.
>
> Jaki jest sens, żeby każdy wiedział, co trzeba zrobić w każdym tasku,
Dla niektorych ma to bardzo duzy sens. Np. Ja nie bylbym w stanie
pracowac nad fragmentem nie wiedzac jaka spelnia role w calosci.

Pozdrawiam

Marek

do góry

On Friday, August 16, 2013 10:51:23 PM UTC+2, Marek Borowski wrote:
> Nie. IMO To Ty starasz sie przedstawic polska burdelowa rzeczywistosc
> jako normalnosc. Male firmy tak dzialaja i nawet sobie radza ale przez
> to zawsze beda male. Pewne zasady maja glebszy sens.

To nie jest "burdelowa" rzeczywistość, tylko biznes. Żeby coś sprzedać
trzeba mieć co pokazać. To, że wykonałem dodatkową pracę poza zespołem
i wbrew zasadom dało realną korzyść firmie. Gdy początkowo zespół wziął się
za wycenę zgodnie ze scrumowym rytuałem, to estymata wyszła jakieś 15-20
osobodni pracy. Z czego samo planowanie na wejściu zeżarło 5 osobodni...
tragedia.

A w biznesie liczy się sprzedaż i tylko sprzedaż. Nikt nam nie patrzy
w pokrycie testami, prędkości w sprincie, ani inne tego typu bzdury.

Oczywiście nie twierdzę, że wolna amerykanka jest ok. Definition
of done jest potrzebne. Potrzebna jest kontrola jakości, testy
automatyczne i manualne, aktualna dokumentacja, itd. Ale też trzeba
używać zdrowego rozsądku, co w moim odczuciu SCUM dość skutecznie
utrudnia.

> > Jaki jest sens, żeby każdy wiedział, co trzeba zrobić w każdym tasku,
>
> Dla niektorych ma to bardzo duzy sens. Np. Ja nie bylbym w stanie
> pracowac nad fragmentem nie wiedzac jaka spelnia role w calosci.

Jednak większość takiej wiedzy nie potrzebuje i stąd właśnie marnotrawstwo
czasu. Ja wcale nie neguję tego, że zespół potrzebuje wiedzieć co robi
i po co. Fajnie to wiedzieć na początku, ale jak pracujesz n-ty miesiąc
nad tym samym systemem, to chyba nie potrzebujesz co 2 tygodnie przypomnienia
o co chodzi? :)

w.

do góry

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

do góry