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

do góry

On Wednesday, August 28, 2013 10:37:03 PM UTC+2, Andrzej Jarzabek wrote:
> > Mieliśmy "release planning", ale nie do tego projektu.
> >
> > Wg mnie to jest wchodzenie w buty analityka, co jest kompletnie
> > bez sensu.
>
> W jakim sensie?

W takim, że podczas release planningu zespół programistów wykonuje
prace analityczne. Raz, że nie ma kompetencji, dwa, że robi to w
ograniczonym czasie.

Czyste marnowanie czasu programistów.

> Uważasz, że programiści nie potrzebują wiedzieć do czego
> służy produkt, jaka jest przewidywana funkcjonalność, jaki jest plan
> wprowadzenia do produkcji?

Wystarczy wiedza ogólna, a jak ktoś potrzebuje znać szczegóły,
to niech sobie przeczyta specyfikację.

> > Osoby z oficjalnymi certyfikatami, pracujący dla dużych firm IT. Naprawdę
> > Andrzeju, to nie ludzie z ulicy. :)
>
> Nie ma czegoś takiego, jak "oficjalny certyfikat" Scrum. Każdy,
> dosłownie każdy może wystawiać "certyfikaty Scrum".

A scrum.org prowadzony przez twórcę Scruma jest koszerny?
I certyfikaty przez nich wydawane są coś warte?

w.

do góry

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.

do góry

On 30/08/2013 21:41, Wojciech Muła wrote:
> On Wednesday, August 28, 2013 10:37:03 PM UTC+2, Andrzej Jarzabek wrote:
>>> Mieliśmy "release planning", ale nie do tego projektu.
>>>
>>> Wg mnie to jest wchodzenie w buty analityka, co jest kompletnie
>>> bez sensu.
>>
>> W jakim sensie?
>
> W takim, że podczas release planningu zespół programistów wykonuje
> prace analityczne. Raz, że nie ma kompetencji, dwa, że robi to w
> ograniczonym czasie.

No ale w release planning wcale nie chodzi o to, żeby programiści
wykonywali pracę analityków. Chodzi o to, żeby wiedzieli jaki jest plan
- kiedy biznes chciałby zrobić release i co z grubsza powinno się w nim
znaleźć i żeby ewentualnie mogli zwrócić uwagę na problemy, zadać
pytania itd.

>> Uważasz, że programiści nie potrzebują wiedzieć do czego
>> służy produkt, jaka jest przewidywana funkcjonalność, jaki jest plan
>> wprowadzenia do produkcji?
>
> Wystarczy wiedza ogólna, a jak ktoś potrzebuje znać szczegóły,
> to niech sobie przeczyta specyfikację.

Ale dlaczego uważasz, że release planning odbywa się na poziomie
"szczegółów" a nie "wiedzy ogólnej"? W XP idea jest właśnie taka, że na
release planning ustala się do poziomu user stories lub nawet grubiej.

Osobnym pytaniem jest na jakim poziomie operuje analityk i specyfikacja
przez niego tworzona. Często analitycy znają się na dziedzinie programu,
rozumieją potrzeby biznesowe, widzieli kilka programów wykonujących
podobne funkcje, ale niekoniecznie znają się dobrze na inżynierii
oprogramowania, w sensie jak projektować funkcjonalność, usability,
bezpieczeństwo, administrację produktem - i przede wszystkim jak radzić
sobie z problemem wieloznaczności specyfikacji pisanej w języku
naturalnym. Dlatego też często zlecenie analitykowi pisanie specyfikacji
na poziomie "jeśli użytkownik zrobi to, to program zrobi to" jest nie
tylko kosztowne pod względem czasu pracy analityków, ale też wytworzone
w ten sposób specyfikacje bywają bardzo problematyczne.

>>> Osoby z oficjalnymi certyfikatami, pracujący dla dużych firm IT. Naprawdę
>>> Andrzeju, to nie ludzie z ulicy. :)
>>
>> Nie ma czegoś takiego, jak "oficjalny certyfikat" Scrum. Każdy,
>> dosłownie każdy może wystawiać "certyfikaty Scrum".
>
> A scrum.org prowadzony przez twórcę Scruma jest koszerny?
> I certyfikaty przez nich wydawane są coś warte?

Zatrudniliście scrum.org do wdrażania Scrumu?

Moja odpowiedź jest taka, że nie mam podstaw, żeby się konkretnie
wypowiadać o tej czy innej firmie, ale właśnie jedynym sensownym
indykatorem tego, co jest sensowne, jest firmowanie tego przez kogoś,
kogo się uważa za sensowną osobę mówiącą sensowne rzeczy (w książkach, w
artyułach, na konferencjach). Osobiście nie jestem jakimś szczególnie
wielim fanem Scruma i nie siedzę bardzo w tym środowisku siedzę, więc
oprócz samych Schwabera i Sutherlanda kojarzę tylo Mike'a Cohna (z
ludzi, których uważam za sensownych). Przy czym w takich przypadkach
trzeba uważać na "degrees of separation" - jeśli zatrudniasz (dajmy na
to) scrum.org do wdrożenia u siebie Scruma to masz dobrą szansę na
sensowną usługę, jeśli robisz u nich certyfikację to pewnie masz dobrą
szansę na sensowny kurs z którego wiele możesz wynieść; jeśli zarudniasz
konsultantów, którzy są certyfikowani przez scrum.org to może masz nieco
lepszą szansę że zrobią to sensownie, niż w przypadku ludzi z ulicy, ale
za bardzo bym na to nie liczył.

do góry

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

do góry