W dniu 2013-08-30 22:55, Wojciech Muła pisze:
> 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.

Może za krótkie sprinty?

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

Spróbowałbym w takim razie z dłuższymi sprintami.

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

Wniosek - za duże zespoły? 8-)

--
Paweł Kierski
n...@p...net