Szarym od mżawki świtem Mon, 19 Aug 2013 08:29:48 +0200, Paweł Kierski
wyrzucił pustą ćwiartkę i oznajmił:

> W dniu 2013-08-17 23:51, Wojciech Muła pisze:
>> On Saturday, August 17, 2013 8:46:40 PM UTC+2, Marek Borowski wrote:
>>>> To nie jest "burdelowa" rzeczywistość, tylko biznes. Żeby coś sprzedać
>>>> trzeba mieć co pokazać. To, że wykonałem dodatkową pracę poza zespołem
>>>> i wbrew zasadom dało realną korzyść firmie. Gdy początkowo zespół wziął się
>>>> za wycenę zgodnie ze scrumowym rytuałem, to estymata wyszła jakieś 15-20
>>>> osobodni pracy. Z czego samo planowanie na wejściu zeżarło 5 osobodni...
>>>> tragedia.
>>>
>>> Swietnie. Jedna rzecz mozna zrobic ad-hoc. A teraz wyobraz sobie ze
>>> wszystko robisz bez planowania i na zasadzie ze na wczoraj - bo tak to
>>> sie konczy.
>>
>> I tak w SCRUM-ie nie ma planowania długoterminowego,
>
> Bzdura. Co tego zabrania?

Nikt i nic tego nie zabrania. Ale znaczna część filozofii Agile opiera się
na negacji Waterfalla i to w myśleniu zerojedynkowym, stąd spora część
wyznawców tak właśnie postępuje. Skoro w Waterfall istniało długoterminowe
planowanie, architektura i ciągłe ulepszanie, to przecież w naszym nowym
cudownym Agile tego być nie może. Bo to wszystko jest "legacy".

Całość mi przypomina zachowanie nastolaków na dłuższych wakacjach, i to
zarówno wśród części ludzi z mojego własnego niewielekiego w sumie doświadczenia,
ale też w blogach cytowanych tu na grupie. Większość piewców koncentruje
się na tępieniu "legacy" i wszystkiego co im się nie podoba przy okazji,
a tylko mniejsza część przypomina, że jednak potrzebny jest Technical
Produkt Owner, architekci, dłuższy plan czy szerszy obraz - problem polega
na tym, że mało kto dyskutuje z tym na podstawie samego Agile. Z mojej wiedzy
wynika, że role takie jak TPO czy PO może pełnić w Agile ta sama osoba lub
nawet jeden z deweloperów, ale kto by słuchał coachów Agile jak ma
się pod ręką linkę do Wspaniałego Bloga, który co prawda reprezentuje
Agile dla ubogich, ale za to jest w sieci i można dać linka.

Na dodatek konkretne techniki takie jak Scrum z założenia mają być
elastycznie dopasowywane do konkretnego projektu, więc część rozumie
to jako "twórzmy nowy wspaniały świat i odrzućmy wszystko co legacy".
Taki SCRUM bez uwzględniania niczego poza bierzącą iteracją może
jest i fajny, ale to nie jest Agile. Prędzej czy później odzywają się
potrzeby dopracowywania organizacji, zarządzania czasem, pilnowania
procesów - sorry, nie pamiętam wszystkich Scrumowych nazw na te
same rzeczy w wersji Agile, chyba Retrospekcja i parę innych.

>> a
>> dla dużych projektów to tragedia. Przeżyliśmy takie cudo
>> i to była jakaś kosmiczna pomyłka.
>
> Brak długoterminowej wizji to dopiero tragedia. Po to jest, "po nowemu"
> mówiąc, Backlog Refinement.

Ostatecznie wszystko weryfikuje rynek. Dane z rynku UK, gdzie podaje się
wysokość wynagrodzeń w ogłoszeniach:

http://www.itjobswatch.co.uk/jobs/uk/agile%20softwar
e%20development.do#salary_trend

Z jednej strony popularność Agile ro?śnie - podobnie do popularności JavaScriptu -
a z drugiej wynagrodzenia minimalnie maleją *)

*) Uwzględniając cały rynek z tym słowem kluczowym, czyli wliczając manadżerów
i coachów

--
Edek

do góry

On Monday, 19 August 2013 13:32:49 UTC+2, Edek wrote:
> Szarym od mżawki świtem Mon, 19 Aug 2013 08:29:48 +0200, Paweł Kierski
>
> wyrzucił pustą ćwiartkę i oznajmił:
>
> > W dniu 2013-08-17 23:51, Wojciech Muła pisze:
>
> >> On Saturday, August 17, 2013 8:46:40 PM UTC+2, Marek Borowski wrote:
> >>>> To nie jest "burdelowa" rzeczywistość, tylko biznes. Żeby coś sprzedać
> >>>> trzeba mieć co pokazać. To, że wykonałem dodatkową pracę poza zespołem
> >>>> i wbrew zasadom dało realną korzyść firmie. Gdy początkowo zespół wziął się
> >>>> za wycenę zgodnie ze scrumowym rytuałem, to estymata wyszła jakieś 15-20
> >>>> osobodni pracy. Z czego samo planowanie na wejściu zeżarło 5 osobodni...
> >>>> tragedia.
> >>>
> >>> Swietnie. Jedna rzecz mozna zrobic ad-hoc. A teraz wyobraz sobie ze
> >>> wszystko robisz bez planowania i na zasadzie ze na wczoraj - bo tak to
> >>> sie konczy.
> >>
> >> I tak w SCRUM-ie nie ma planowania długoterminowego,
> >
> > Bzdura. Co tego zabrania?
>
> Nikt i nic tego nie zabrania. Ale znaczna część filozofii Agile opiera się
> na negacji Waterfalla i to w myśleniu zerojedynkowym, stąd spora część
> wyznawców tak właśnie postępuje. Skoro w Waterfall istniało długoterminowe
> planowanie, architektura i ciągłe ulepszanie, to przecież w naszym nowym
> cudownym Agile tego być nie może. Bo to wszystko jest "legacy".

Bzdura.

Metody Agile dają się stosować bezproblemowo na wyższym poziomie zarządzania, a im
wyższy poziom tym planowanie bardziej długoterminowe.

AdamK

do góry

W dniu 2013-08-19 13:32, Edek pisze:
> Szarym od mżawki świtem Mon, 19 Aug 2013 08:29:48 +0200, Paweł Kierski
> wyrzucił pustą ćwiartkę i oznajmił:
>
>> W dniu 2013-08-17 23:51, Wojciech Muła pisze:
>>> On Saturday, August 17, 2013 8:46:40 PM UTC+2, Marek Borowski wrote:
>>>>> To nie jest "burdelowa" rzeczywistość, tylko biznes. Żeby coś sprzedać
>>>>> trzeba mieć co pokazać. To, że wykonałem dodatkową pracę poza zespołem
>>>>> i wbrew zasadom dało realną korzyść firmie. Gdy początkowo zespół wziął się
>>>>> za wycenę zgodnie ze scrumowym rytuałem, to estymata wyszła jakieś 15-20
>>>>> osobodni pracy. Z czego samo planowanie na wejściu zeżarło 5 osobodni...
>>>>> tragedia.
>>>>
>>>> Swietnie. Jedna rzecz mozna zrobic ad-hoc. A teraz wyobraz sobie ze
>>>> wszystko robisz bez planowania i na zasadzie ze na wczoraj - bo tak to
>>>> sie konczy.
>>>
>>> I tak w SCRUM-ie nie ma planowania długoterminowego,
>>
>> Bzdura. Co tego zabrania?
>
> Nikt i nic tego nie zabrania. Ale znaczna część filozofii Agile opiera się
> na negacji Waterfalla

Tak.

> i to w myśleniu zerojedynkowym

Nie.

>, stąd spora część
> wyznawców tak właśnie postępuje. Skoro w Waterfall istniało długoterminowe
> planowanie, architektura i ciągłe ulepszanie, to przecież w naszym nowym
> cudownym Agile tego być nie może. Bo to wszystko jest "legacy".
>
> Całość mi przypomina zachowanie nastolaków na dłuższych wakacjach, i to
> zarówno wśród części ludzi z mojego własnego niewielekiego w sumie doświadczenia,
> ale też w blogach cytowanych tu na grupie.

Cóż - obok pojawiły się stwierdzenia, że koniec końców najwięcej zależy
od ludzi, metodyka może im pomóc, ale nie zastąpi rozsądku.

> Większość piewców koncentruje
> się na tępieniu "legacy" i wszystkiego co im się nie podoba przy okazji,
> a tylko mniejsza część przypomina, że jednak potrzebny jest Technical
> Produkt Owner, architekci, dłuższy plan czy szerszy obraz - problem polega
> na tym, że mało kto dyskutuje z tym na podstawie samego Agile. Z mojej wiedzy
> wynika, że role takie jak TPO czy PO może pełnić w Agile ta sama osoba lub
> nawet jeden z deweloperów, ale kto by słuchał coachów Agile jak ma
> się pod ręką linkę do Wspaniałego Bloga, który co prawda reprezentuje
> Agile dla ubogich, ale za to jest w sieci i można dać linka.
>
> Na dodatek konkretne techniki takie jak Scrum z założenia mają być
> elastycznie dopasowywane do konkretnego projektu, więc część rozumie
> to jako "twórzmy nowy wspaniały świat i odrzućmy wszystko co legacy".
> Taki SCRUM bez uwzględniania niczego poza bierzącą iteracją może
> jest i fajny, ale to nie jest Agile. Prędzej czy później odzywają się
> potrzeby dopracowywania organizacji, zarządzania czasem, pilnowania
> procesów - sorry, nie pamiętam wszystkich Scrumowych nazw na te
> same rzeczy w wersji Agile, chyba Retrospekcja i parę innych.

Scrum w opisie wydaje się być bardzo prosty. Jedną z pułapek jest próba
upraszczania go jeszcze bardziej i brak zrozumienia, że im prostsze
i im mniej reguł, tym bezwzględniej należy je stosować. A jednocześnie
korzystać (z głową) z elastyczności tam, gdzie reguły się kończą.

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

do góry

On Monday, August 19, 2013 8:17:58 AM UTC+2, Paweł Kierski wrote:
> > Więc czasem tylko utrzymujemy i wtedy tak naprawdę nie ma co obgadywać,
> > kończymy szybko. Ale jak przychodzą nowe rzeczy, wówczas nierzadko nie
> > wystarcza czasu, nawet jak rozciągniemy spotkanie na maksa i się streszczamy.
> > Zresztą planowanie jest w wielu przypadkach bez sensu, ponieważ bez
> > jakiegoś rozpoznania tematu przez programistów estymaty są z kosmosu.
>
> Czyli klasyka - brakuje wizji na poziomie trochę wyższym.

Błędna diagnoza. Oczekiwanie na decyzje klientów. Wyobraź sobie, że
liczą każdą złotówkę. :)

> Skoro są sprinty, w których "tylko utrzymujemy", to wypada się
> zastanowić, czy na pewno potrzeba w ogóle pracy nad tym projektem.

Akurat to nasz główny produkt, który jest na produkcji od kilku lat.
Nie można go olać, to nie opensource. :)

> Na estymaty z kosmosu znam dwie główne metody - uczyć się estymować oraz
> robić proof of concept. Niektórzy twierdzą, że to nie ortodoksyjne, ale
> w skrajnych przypadkach, gdy temat jest kompletnie nieznany robimy
> sprint wcześniej badanie tematu. Siada jedna osoba i dwa, góra trzy dni
> szuka rozwiązań, próbuje projektować, pisać jakieś mockupy, czy co tam
> jeszcze potrzebne do odpowiedzi na pytanie "ile to będzie kosztowało?".
> Rezultatem takiego zadania jest odpowiedź, np. "już nie między 5 a 40,
> ale między 20 a 40".

Były takie pomysły, ale zostały - mówiąc efemistycznie - chłodno przyjęte. :)

w.

do góry

On Monday, August 19, 2013 8:29:48 AM UTC+2, Paweł Kierski wrote:
> > I tak w SCRUM-ie nie ma planowania długoterminowego,
>
> Bzdura. Co tego zabrania?

SCRUM niewprost. Dobrze pamiętam ten idiotyzm ze szkolenia - jest
sens planowania na sprint, może dwa, później tylko zgrubnie,
a dalej są smoki.

Wdrożyliśmy to z całą konsekwencją. Nie była znana ścieżka
krytyczna, były przestoje, był niepotrzebny "zaplanowany"
refaktoring. Mimo, że od samego początku było dokładnie
wiadomo, co musi być zrobione, a zmian od klienta było
niewiele i raczej kosmetycznych.

> > Jeśli ja narzekałem, że tych spotkań jest za dużo i są za długie
> > i nie mają sensu, to można było powiedzieć, że jestem malkontentem
> > i spokojnie olać temat.
>
> > Ale jak to samo zaczynają mówić koledzy-fani scruma, to coś jest na
> > rzeczy. :)
>
> Zgłaszacie te wątpliwości na retrospekcji? Jakieś wnioski z tych uwag?
> Próbowaliście coś zmieniać, żeby było lepiej?
> [...]
> Jednym z typowych błędów jest zmniejszanie wagi przykładanej do
> retrospekcji i płynących z niej wniosków. A z ceremoniami jak z myciem
> zębów: raz odpuścić to nic takiego dla zębów. Gorzej dla myjącego -
> nabiera przekonania, że odpuszczać sobie można.

Wydaje mi się, że retrospektywy są w porządku, zgłaszamy
uwagi, podejmujemy jakieś kroki (często skutecznie). Ale
sam problem nadmiaru i celowości spotkań jest wbudowany
w scruma. :)

w.

do góry

W dniu 2013-08-19 19:12, Wojciech Muła pisze:
> On Monday, August 19, 2013 8:17:58 AM UTC+2, Paweł Kierski wrote:
>>> Więc czasem tylko utrzymujemy i wtedy tak naprawdę nie ma co obgadywać,
>>> kończymy szybko. Ale jak przychodzą nowe rzeczy, wówczas nierzadko nie
>>> wystarcza czasu, nawet jak rozciągniemy spotkanie na maksa i się streszczamy.
>>> Zresztą planowanie jest w wielu przypadkach bez sensu, ponieważ bez
>>> jakiegoś rozpoznania tematu przez programistów estymaty są z kosmosu.
>>
>> Czyli klasyka - brakuje wizji na poziomie trochę wyższym.
>
> Błędna diagnoza. Oczekiwanie na decyzje klientów. Wyobraź sobie, że
> liczą każdą złotówkę. :)
>
>> Skoro są sprinty, w których "tylko utrzymujemy", to wypada się
>> zastanowić, czy na pewno potrzeba w ogóle pracy nad tym projektem.
>
> Akurat to nasz główny produkt, który jest na produkcji od kilku lat.
> Nie można go olać, to nie opensource. :)

Czyli są sprinty, w których nie ma nic do roboty poza utrzymaniem, bo
backlog pusty, a klient nic do niego nie zdążył dodać? Przy okazji - jak
duże (w porównaniu do mocy zespołu) jest obciążenie samym utrzymaniem?
Może to znaczy, że zespół może zacząć zajmować się innym projektem, co
najwyżej pozostawiając małą rezerwę na utrzymanie?

>> Na estymaty z kosmosu znam dwie główne metody - uczyć się estymować oraz
>> robić proof of concept. Niektórzy twierdzą, że to nie ortodoksyjne, ale
>> w skrajnych przypadkach, gdy temat jest kompletnie nieznany robimy
>> sprint wcześniej badanie tematu. Siada jedna osoba i dwa, góra trzy dni
>> szuka rozwiązań, próbuje projektować, pisać jakieś mockupy, czy co tam
>> jeszcze potrzebne do odpowiedzi na pytanie "ile to będzie kosztowało?".
>> Rezultatem takiego zadania jest odpowiedź, np. "już nie między 5 a 40,
>> ale między 20 a 40".
>
> Były takie pomysły, ale zostały - mówiąc efemistycznie - chłodno przyjęte. :)

Czyli jest pomysł na zmniejszenie "zdupności" estymat, ale go olewamy,
bo tak - bez sprawdzenia? A jednocześnie duże rozjazdy w estymatach
pozostają problemem? A jakieś inne pomysły były?

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

do góry

W dniu 2013-08-19 19:28, Wojciech Muła pisze:
> On Monday, August 19, 2013 8:29:48 AM UTC+2, Paweł Kierski wrote:
>>> I tak w SCRUM-ie nie ma planowania długoterminowego,
>>
>> Bzdura. Co tego zabrania?
>
> SCRUM niewprost. Dobrze pamiętam ten idiotyzm ze szkolenia - jest
> sens planowania na sprint, może dwa, później tylko zgrubnie,
> a dalej są smoki.

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.

> Wdrożyliśmy to z całą konsekwencją. Nie była znana ścieżka
> krytyczna, były przestoje, był niepotrzebny "zaplanowany"
> refaktoring. Mimo, że od samego początku było dokładnie
> wiadomo, co musi być zrobione, a zmian od klienta było
> niewiele i raczej kosmetycznych.

Skoro było wiadomo, co zrobić, to skąd przestoje?

>>> Jeśli ja narzekałem, że tych spotkań jest za dużo i są za długie
>>> i nie mają sensu, to można było powiedzieć, że jestem malkontentem
>>> i spokojnie olać temat.
>>
>>> Ale jak to samo zaczynają mówić koledzy-fani scruma, to coś jest na
>>> rzeczy. :)
>>
>> Zgłaszacie te wątpliwości na retrospekcji? Jakieś wnioski z tych uwag?
>> Próbowaliście coś zmieniać, żeby było lepiej?
>> [...]
>> Jednym z typowych błędów jest zmniejszanie wagi przykładanej do
>> retrospekcji i płynących z niej wniosków. A z ceremoniami jak z myciem
>> zębów: raz odpuścić to nic takiego dla zębów. Gorzej dla myjącego -
>> nabiera przekonania, że odpuszczać sobie można.
>
> Wydaje mi się, że retrospektywy są w porządku, zgłaszamy
> uwagi, podejmujemy jakieś kroki (często skutecznie). Ale
> sam problem nadmiaru i celowości spotkań jest wbudowany
> w scruma. :)

Właśnie nie jest - jedną z uwag może być stwierdzenie, że któreś że
spotkań może mieć poprawioną efektywność. Choćby przez jego skrócenie.
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.

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

do góry

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.

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

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

w.

do góry

On Monday, August 19, 2013 9:28:45 AM UTC+2, Andrzej Jarzabek wrote:
> Jeśli chodzi o komunikowanie takich planów i zaangażowanie w nie zespołu
> developerskiego, to w praktyce bardzo często się uzupełnia Scrum
> praktykami wziętymi np. z XP, i jedną z takich praktyk jest "release
> planning".

Mieliśmy "release planning", ale nie do tego projektu.

Wg mnie to jest wchodzenie w buty analityka, co jest kompletnie
bez sensu.

> Ja bym był ostrożny z takimi założeniami. Każdy może świadczyć usługi
> konsultacji we "wdrożeniu Scrum", i faktycznie większość firm i ludzi
> świadczących takie usługi to hochsztaplerzy.

Osoby z oficjalnymi certyfikatami, pracujący dla dużych firm IT. Naprawdę
Andrzeju, to nie ludzie z ulicy. :)

w.

do góry

On 28/08/2013 19:55, Wojciech Muła wrote:
> On Monday, August 19, 2013 9:28:45 AM UTC+2, Andrzej Jarzabek wrote:
>> Jeśli chodzi o komunikowanie takich planów i zaangażowanie w nie zespołu
>> developerskiego, to w praktyce bardzo często się uzupełnia Scrum
>> praktykami wziętymi np. z XP, i jedną z takich praktyk jest "release
>> planning".
>
> 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? Uważasz, że programiści nie potrzebują wiedzieć do czego
służy produkt, jaka jest przewidywana funkcjonalność, jaki jest plan
wprowadzenia do produkcji?

>> Ja bym był ostrożny z takimi założeniami. Każdy może świadczyć usługi
>> konsultacji we "wdrożeniu Scrum", i faktycznie większość firm i ludzi
>> świadczących takie usługi to hochsztaplerzy.
>
> 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".

Również to, że duża firma coś robi nijak nie świadczy o jakości tego czegoś.

do góry