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.