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.