On Thursday, August 29, 2013 10:11:02 AM UTC+2, Paweł Kierski wrote:
> Inkrementacja nie musi oznaczać oderwanych kawałków. Przyrost wartości
> ze sprintu na sprint czasem może być mniej widoczny dla końcowego
> użytkownika, ale dla klienta może objawić się w następnych sprintach -
> mniejszymi kosztami zmian. Prowadzenie backlogu to na prawdę
> nietrywialne zadanie.

Inkrement to jest potencjalnie sprzedawalny produkt - tak to ujmują
w Scrum Guide. Więc nie ma możliwości np. napisania warstwy np. zapisu
do bazy, czy komunikacji sieciowej i zakończenia na tym sprintu.
Musi zaistnieć, coś co można pokazać klientowi, choćby to było skrajnie
idiotyczne.

> > Gdybyśmy robili "warstwowo" (co było oczywiste, że to jedyna
> > sensowna droga), to nie byłoby co pokazać na review - takie
> > słyszałem wyjaśnienia. No i się robiło "pionowo" i się
> > refaktoryzowało kod napisany sprint wcześniej.
>
> Zaraz - czy to znaczy, że przestoje wynikały z czekania na implementację
> elementów funkcjonalności w różnych warstwach? Jeśli tak, to albo
> zawiódł podział na zespoły (odpowiadały za oddzielne warstwy?), albo
> komunikacja między zespołami - wracamy do jakiegoś ogólnego widoku
> i planowania na poziomie między zespołami.

To był jeden zespół, który wziął sobie taki a nie inny zestaw tasków,
żeby dało się zaprezentować ów "inkrement". Mimo ewidentnego idiotyzmu
takiego podejścia - istniały "mniej" ważne taski, które można było
wykonać niezależnie. Ale one nie dawały inkrementu.

> > Znalazłem lepszy sposób - poszedłem późno spać, przez co przez
> > cały dzień byłem senny i przetrwałem spotkania w letargu.
>
> I masz pretensje, że Scrum nie chce działać? 8-)

Spotkania toczyły się spokojnie bez mojego aktywnego udziału. :)

w.