W dniu 2013-08-28 20:29, Wojciech Muła pisze:
> On Tuesday, August 20, 2013 7:58:56 AM UTC+2, Paweł Kierski wrote:
>> Na sprint na pewno trzeba wiedzieć, o następnym trzeba mieć pojęcie
>> w ramach zespołu. Co nie zwalnia PO od rozpisania backlogu na tyle,
>> na ile tylko jest w stanie. Lepiej, żeby "smoki" polegały na tym, że
>> nie wiemy w jakiej kolejności, niż nie wiemy nic w ogóle.
>
> Zero planu dalekosiężnego - mając specyfikację wiemy, co trzeba
> robić, przynajmniej w zarysie. Widać ścieżkę/ścieżki krytyczne.
>
> Nie wykorzystywaliśmy tej wiedzy, bo fetysz "inkrementu" kazał
> robić oderwane od siebie kawałki.

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.

>> Skoro było wiadomo, co zrobić, to skąd przestoje?
>
> 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.

>> Cel spotkania - to naprawdę trudna sztuka dobrze go zdefiniować, a potem
>> w trakcie trzymać się ścieżki. Pomaga określenie _przed_ spotkaniem
>> z jakim ustaleniem lub odpowiedzią na jakie pytanie chcemy wyjść ze
>> spotkania.
>
> 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-)

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