On 16/08/2013 22:25, Wojciech Muła wrote:
>
> A w biznesie liczy się sprzedaż i tylko sprzedaż. Nikt nam nie patrzy
> w pokrycie testami, prędkości w sprincie, ani inne tego typu bzdury.

Znaczy uważasz, że w biznesie lepiej wyprodukować za dwa i pół miliona i
sprzedać za dwa, niż wyprodukować za pół miliona i sprzedać za milion?

do góry

On 8/16/2013 11:25 PM, Wojciech Muła wrote:
> On Friday, August 16, 2013 10:51:23 PM UTC+2, Marek Borowski wrote:
>> Nie. IMO To Ty starasz sie przedstawic polska burdelowa rzeczywistosc
>> jako normalnosc. Male firmy tak dzialaja i nawet sobie radza ale przez
>> to zawsze beda male. Pewne zasady maja glebszy sens.
>
> 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.

> A w biznesie liczy się sprzedaż i tylko sprzedaż. Nikt nam nie patrzy
Tiaaa, i dlatego tak duzo gowna na rynku.

> w pokrycie testami, prędkości w sprincie, ani inne tego typu bzdury.
>
Ale to sie przeklada na jakosc a na to klient juz patrzy.

> Oczywiście nie twierdzę, że wolna amerykanka jest ok. Definition
> of done jest potrzebne. Potrzebna jest kontrola jakości, testy
> automatyczne i manualne, aktualna dokumentacja, itd. Ale też trzeba
> używać zdrowego rozsądku, co w moim odczuciu SCUM dość skutecznie
> utrudnia.
>
No nie wiem, odnosze wrazenie ktytykujesz metodyke na podstawie
jej pojedynczych przypadkow niepoprawnego uzycia. Nie sadzisz ze
problem lezy gdzie indziej ?


>>> Jaki jest sens, żeby każdy wiedział, co trzeba zrobić w każdym tasku,
>>
>> Dla niektorych ma to bardzo duzy sens. Np. Ja nie bylbym w stanie
>> pracowac nad fragmentem nie wiedzac jaka spelnia role w calosci.
>
> Jednak większość takiej wiedzy nie potrzebuje i stąd właśnie marnotrawstwo
> czasu. Ja wcale nie neguję tego, że zespół potrzebuje wiedzieć co robi
> i po co. Fajnie to wiedzieć na początku, ale jak pracujesz n-ty miesiąc
> nad tym samym systemem, to chyba nie potrzebujesz co 2 tygodnie przypomnienia
> o co chodzi? :)
No nie. Ale to oznacza, iz spotkania sa zle prowadzone a nie ze sa zle
jako takie.


Pozdrawiam

Marek

do góry

On Saturday, August 17, 2013 1:43:28 AM UTC+2, Andrzej Jarzabek wrote:
> > Nie można zmienić w trakcie spotkania - timebox rzecz święta, right?
>
> W trakcie nie, ale jeśli generalnie wychodzi, że timebox za którki, to
> na retrospektywie można postanowić, że się go wydłuży.

No tak, tylko problem jest właśnie teraz! Po sprincie to już nie
ma znaczenia.

> Przede wszystkim macie retrospektywę i na niej możecie używać
> takich technik jak root cause analysis, żeby identyfikować powody, dla
> których estymaty są błędne.

Dzięki, zanotowane.

> Częstym powodem jest np. to, że backlog items są za mało rozdrobnione.

Z tym nie ma problemu wg mnie. Mamy zresztą taką zasadę, że jak
wychodzi podczas planowania za dużo storypointów (u nas 21)
wówczas trzeba rozbić.

> Do stosowania dla przypadków, kiedy faktycznie nic nie wiadomo i koszty
> potencjalnie mogą być bardzo duże jest też rozwiązanie ekstremalne -
> bardzo kosztowne, ale pozwalające na dużo dokładniejszą estymację: spike
> solution - stosujecie to?

Tak, stosujemy. To się świetnie sprawdziło w paru przypadkach, np.
powstał proof of concept, który później dość niskim kosztem przekształciliśmy
na normalny kod.

Ale główny problem jest taki, że czasem dopiero po rozgrzebaniu zadania
widać, że estymata była kosmiczna. Część modułów naszego systemu nie była
ruszana od dawna i często nawet osoby, które je pisały nie ma pojęcia
ile będzie kosztowała zmiana.

> A tak swoją drogą, estymaty robicie w story pointach, roboczogodzinach
> czy w czym?

Dla story - w storypointach, po rozbiciu na taski już w roboczogodzinach.

> > Mnie chodzi o podejście programistów: my se tu dłubiemy, a czy biznes
> > to sprzeda, to mamy w dupie.
>
> Naprawdę było takie zalecenie w poprzednich wersjach scrum guide?

Wg mnie wygodna nadinterpretacja. :)

> Już nie mówiąc o tym, że w wyjątkowych sytuacjach można czasem wyściubić
> nos poza Scrum Guide i podejść do sprawy tak normalnie, po ludzku
> "słuchajcie to jest ważna sprawa, ja rozumiem, że plan był robiony z
> założeniem, że Wojtek będzie z wami pracował, więc za chwilę usiądziemy
> i się razem zastanowimy co wykreślić. A jak się uda zrobić tę Super
> Ważną Rzecz, to w piątek idziemy do knajpy i firma stawia."

No to u nas zabrakło właśnie tego normalnego podejścia.

> Jeśli specyfika projektu jest faktycznie taka, że regularnie zdarzają
> się super ważne rzeczy, które trzeba wdrożyć do produkcji w ciągu kilku
> dni, to prawdopodobnie Scrum nie jest dobrą metodologią.

Nie, to się zdarzyło jak dotąd raz. Częściej zdarzają się krytyczne
błędy z produkcji, ale z tym sobie radzimy już całkiem sensownie.
Po prostu jedna osoba przerywa swoją pracę i poprawia błąd. Wszyscy
wiemy, że może nie zrobić story, czy taska w sprincie, ale to jest
akceptowalne.

> > Zespół liczy 7 osób, planning trwa w praktyce od 6-8 godzin. Wychodzi co
> > najmniej tydzień pracy jednego programisty.
>
> Przy jakiej długości sprintu?

3-tygodnie

> Jeśli z jednej strony nie widzicie tej korzyści, uważasz, że ludzie na
> planowaniu słyszą o nieistotnych dla nich detalach (o ile nie będą
> danego taska implementować), a z drugiej strony brakuje wam czasu w
> timeboxie, to może problem jest po prostu taki, że za bardzo wchodzicie
> w szczegóły przy planowaniu tasków. Może "co trzeba zrobić w tasku"
> wystarczająco określa "zmienić schemat bazy danych", a nie trzeba mówić,
> co w nim konkretnie trzeba zmienić?

Owszem, to może być powód, czasem jest za dużo dywagacji. A czasem
jest n-ta godzina spotkania i wszyscy odlatują.

> >> Ja mam regularnie do czynienia z sytuacjami, gdzie traci się dni i tygodnie
> >> w związku z tym, że programiści nie rozumieją wymagań i istniejącej
> >> funkcjonalności. To jest dopiero marnotrawstwo.
> >
> > Macie jakieś sposoby na unikanie takich sytuacji?
>
> Wg. mnie bardzo dobrze sprawdza się właśnie spotkanie całego zespołu z
> Osobą, Która Wie O Co Chodzi i zadawanie pytań. Również byłem w
> projektach, kiedy kolaboracyjne "specification by example" sprawdzało
> się nieźle, niestety w projektach ze starym i zapuszczonym kodem bywa w
> praktyce kosztowne w realizacji (kiedy ciężko zautomatyzować testowanie
> funkcjonalności).

Dzięki.

w.

do góry

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, a
dla dużych projektów to tragedia. Przeżyliśmy takie cudo
i to była jakaś kosmiczna pomyłka.

> > A w biznesie liczy się sprzedaż i tylko sprzedaż. Nikt nam nie patrzy
>
> Tiaaa, i dlatego tak duzo gowna na rynku.

Pracuję w firmie, która nie tworzy oprogramowania pudełkowego,
czy usługi dla wszystkich, lecz programy na zamówienie, więc tu
klient jest jeden i ma ostateczny głos.

> > w pokrycie testami, prędkości w sprincie, ani inne tego typu bzdury.
>
> Ale to sie przeklada na jakosc a na to klient juz patrzy.

Może mamy specyficznych klientów, ale aż tak bardzo nie patrzą.
Raczej na użyteczność dla firmy, zdają sobie sprawę z możliwości
pojawienia się błędu.

Oczywiście zaznaczam, że to nie oznacza zlania tematu jakości,
żeby ktoś nie wyciął tego z kontekstu i nie dorobił teorii. :)

> No nie wiem, odnosze wrazenie ktytykujesz metodyke na podstawie
> jej pojedynczych przypadkow niepoprawnego uzycia. Nie sadzisz ze
> problem lezy gdzie indziej ?

Mam masę przypadków z praktyki (nie o wszystkim chcę i mogę pisać),
stąd wyciągam wnioski. Firma była przez jakiś czas pod opieką
konsultantów z zewnątrz, którzy SCRUM-a pomagali implementować, więc
zakładam, że używamy go dobrze albo przynajmniej bez kardynalnych
błędów w sztuce.

> > Jednak większość takiej wiedzy nie potrzebuje i stąd właśnie marnotrawstwo
> > czasu. Ja wcale nie neguję tego, że zespół potrzebuje wiedzieć co robi
> > i po co. Fajnie to wiedzieć na początku, ale jak pracujesz n-ty miesiąc
> > nad tym samym systemem, to chyba nie potrzebujesz co 2 tygodnie przypomnienia
> > o co chodzi? :)
>
> No nie. Ale to oznacza, iz spotkania sa zle prowadzone a nie ze sa zle
> jako takie.

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

w.

do góry

On 2013-08-17, Marek Borowski <m...@x...com> wrote:
>> Oczywiście nie twierdzę, że wolna amerykanka jest ok. Definition
>> of done jest potrzebne. Potrzebna jest kontrola jakości, testy
>> automatyczne i manualne, aktualna dokumentacja, itd. Ale też trzeba
>> używać zdrowego rozsądku, co w moim odczuciu SCUM dość skutecznie
>> utrudnia.
>>
> No nie wiem, odnosze wrazenie ktytykujesz metodyke na podstawie
> jej pojedynczych przypadkow niepoprawnego uzycia. Nie sadzisz ze
> problem lezy gdzie indziej ?

Prawdę mówiąc w ten sposób można zdyskwalifikować wszystkie nieudane
projekty jako nieprawidłowe użycie agile/scruma, a przecież nie o to
chodzi.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 17/08/2013 22:27, Wojciech Muła wrote:
> On Saturday, August 17, 2013 1:43:28 AM UTC+2, Andrzej Jarzabek wrote:
>>> Nie można zmienić w trakcie spotkania - timebox rzecz święta, right?
>>
>> W trakcie nie, ale jeśli generalnie wychodzi, że timebox za którki, to
>> na retrospektywie można postanowić, że się go wydłuży.
>
> No tak, tylko problem jest właśnie teraz! Po sprincie to już nie
> ma znaczenia.

Weź pod uwagę, że planowanie ma tylko jeden cel - wybranie itemów do
realizacji w czasie sprintu. W tym celu się robi szacunki, żeby można
było określić, ile itemów się da zrobić, i w tym celu się planuje taski
- żeby wyłapać na wczesnym etapie rzeczy wpływające na extymaty (w jedną
i w drugą stronę). Wszystko, co tej decyzji nie służy trzeba wypchnąć
poza timebox planowania.

Oczywiście takie szacunki zawsze są obciążone jakimś ryzykiem błędu i
teoreytycznie można powiedzieć, że każdy dodatkowy czas poświęcony na
analizę i planowanie zadań może przynieść dodatkowe informacje. Pytanie
jednak, ile czasu warto poświęcać na planowanie czegoś, co potencjalnie
w ogóle nie będzie implementowane.

Jeśli na zasadzie wyjątku się zdarzy, że akurat ewidentnie poświęcenie
więcej czasu da istotną rewizję szacunku wpływającą znacząco na to, co
się da, a czego nie da zrobić, to można podejść do sprawy na dwa
sposoby. Po pierwsze, jeśli jest konsensus że warto, to można wyjątkowo
jednorazowo naruszyć timeboxa.

Z drugiej strony można zdecydować, że nie poświęci się dodatkowego czasu
i użyć takiej estymaty, jaką się ma, ewentualnie uwzględniając
istniejącą niepewność w wariancie pesymistycznym (jeśli wygląda na to,
że coś może zająć dwa razy tyle czasu, ale nie ma czasu, żeby zbadać czy
na pewno, to założyć, że zajmie; jeśli wygląda na to, że coś może
zamiast tygodnia zająć pięć minut, to założyć, że nie zajmie). Założenie
jest takie, że jeśli się akurat tę rzecz źle oszacuje to nic strasznego
się nie stanie, bo błędne estymaty zdarzają się dość często i tak, a
poprawność ich jest tylko statystyczna - jeśli jedne rzeczy
przeszacujesz, a inne niedoszacujesz, to w ramach sprintu powinno się
zwykle wyrównać. Jeśli systematycznie estymaty się mylą w jedną stronę,
to znowu kwestia do rozpatrzenia na retrospektywie - dlaczego?

Ostatecznie ponieważ jest to jednorazowe zdarzenie, to nie ma większego
znaczenia, na którą opcję się zdecydujecie. Na retrospektywie trzeba się
zastanowić czy nie wynikało to z błędów (np. że się zbyt wiele czasu
poświęcało na zbyt szczegółową analizę innych itemów, co niewiele
wnosiło do szacunków, i na inne itemy nie zostało czasu w ogóle lub
zostało bardzo niewiele). Wniosek też może być taki, że okoliczności po
prostu były wyjątkowe i wasz proces ich nie przewidział i nie powinien
być modyfikowany żeby je przewidywać, bo najprowadopodobiej się nie
powtórzą. Jeśli "wyjątkowe" okoliczności zaczynają się powtarzać, to
trzeba się zacząć zastanawiać nad zmianami.

> Ale główny problem jest taki, że czasem dopiero po rozgrzebaniu zadania
> widać, że estymata była kosmiczna. Część modułów naszego systemu nie była
> ruszana od dawna i często nawet osoby, które je pisały nie ma pojęcia
> ile będzie kosztowała zmiana.

Trzeba pamiętać, że szacowanie ani nawet realizacja zaplanowanych itemów
nie są celami same w sobie. Celem jest maksymalizacja wartości
dostarczonej klientowi i w tym celu PO musi mieć szacunki, żeby określić
co warto robić kosztem czego i w jakiej kolejności. Jeśli musisz
wszystko rozgrzebać, żeby mieć estymaty, to wartość dostarczona
klientowi cierpi, bo poświęcasz czas na rozgrzebywanie rzeczy, któóre
nie będą dostarczone klientowi (bo po rozgrzebaniu okaże się, że nie
warto), albo z kolei będziesz robić rzeczy, które są mało wartościowe w
stosunku do kosztów, bo koszty będą znane dopiero jak już dana rzecz
będzie w 3/4 gotowa.

Szcrum zakłada, że do pewnego momentu błędy w szacowaniu nie są takim
dużym problemem, bo po pierwsze, jak pisałem, przeszacowania i
niedoszacowania się znoszą i owszem, gdyby rzeczywiste koszty były od
razu znane, to priorytety mogłyby być inne, ale zazwyczaj nie aż na tyle
inne, żeby ponosić koszty przerywania tego, co już jest "rozgrzebane" i
ponownego planowania. A jeśli się okaże, że się w znaczący sposób nie
znoszą, to zawsze jest możliwość pójścia do PO i powiedzenia "są
komplikacje i nie wyrobimy się ze wszystkim, co zaplanowaliśmy, jakby
co, to z których itemów mamy zrezygnować" lub z drugiej strony "okazało
się, że przeszacowaliśmy i mamy dodatkowe zasoby, zróbmy dodatkowe
planowanie i wciągnijmy dodatkowe itemy do sprintu". Jedno i drugie nie
jest wielkim problemem, najważniejsze żeby zrobić to jak najszybciej,
jak tylko dodatkowa informacja jest dostępna.

>> Jeśli specyfika projektu jest faktycznie taka, że regularnie zdarzają
>> się super ważne rzeczy, które trzeba wdrożyć do produkcji w ciągu kilku
>> dni, to prawdopodobnie Scrum nie jest dobrą metodologią.
>
> Nie, to się zdarzyło jak dotąd raz.

No ale rozumiesz chyba, że nie ma sensu budować procesu wokół tego, co
zdarza się jeden raz?

> Owszem, to może być powód, czasem jest za dużo dywagacji. A czasem
> jest n-ta godzina spotkania i wszyscy odlatują.

Możesz konstruktywnie zaproponowac robienie przerw :)

do góry

W dniu niedziela, 18 sierpnia 2013 04:06:17 UTC+2 użytkownik Stachu 'Dozzie' K.
napisał:

> Prawdę mówiąc w ten sposób można zdyskwalifikować wszystkie nieudane
> projekty jako nieprawidłowe użycie agile/scruma, a przecież nie o to
> chodzi.

Jest gorzej. Agile reklamuje się przez kontrast do "dawnych" metodyk (czyli do
waterfalla), gdzie jak wiadomo projekty się nie udawały. Problem w tym, że dokładnie
na takiej samej zasadzie zamiast twierdzić, że waterfall jest do dupy (i w związku z
tym agile jest dobry) można uznać, że waterfall jest dobry, tylko że go źle stosowano
w tych konkretnych projektach, które się nie udały. Ale wtedy główna linia
marketingowa agile przestałaby istnieć.

Czyli oficjalna wersja jest taka:

1. Waterfall jest do dupy, a dowodem na to jest fakt, że niektóre projekty prowadzone
w ten sposób się nie udały.
Zapamiętajcie: projekt w waterfallu się nie udał -> waterfall jest zły.

2. Agile to nie waterfall, więc agile jest dobre - a to, że jakieś projekty się w
agile nie udają oznacza tylko tyle, że agile jest tam źle stosowany.
Zapamiętajcie: projekt w agile się nie udał -> agile było źle stosowane.

Nie żebym był złośliwy...

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On 2013-08-18, Maciej Sobczak <s...@g...com> wrote:
> W dniu niedziela, 18 sierpnia 2013 04:06:17 UTC+2 użytkownik Stachu 'Dozzie' K.
napisał:
>
>> Prawdę mówiąc w ten sposób można zdyskwalifikować wszystkie nieudane
>> projekty jako nieprawidłowe użycie agile/scruma, a przecież nie o to
>> chodzi.
>
> Jest gorzej. Agile reklamuje się przez kontrast do "dawnych" metodyk
> (czyli do waterfalla), gdzie jak wiadomo projekty się nie udawały.
> Problem w tym, że dokładnie na takiej samej zasadzie zamiast
> twierdzić, że waterfall jest do dupy (i w związku z tym agile jest
> dobry) można uznać, że waterfall jest dobry, tylko że go źle stosowano
> w tych konkretnych projektach, które się nie udały. Ale wtedy główna
> linia marketingowa agile przestałaby istnieć.

Zgadza się. Dla mnie (fakt: nie zawodowego programisty) metodyki
wytwarzania oprogramowania to coś jak ITIL ("biblioteka dobrych
praktyk IT") w utrzymaniu i administracji systemami.

Robienie fetyszu ze zbiorów procedur (metodyk wytwarzania softu czy
metodyki administracji) to próba zastąpienia kompetentnej kadry procesem
biznesowym. To się nie ma prawa udać, jeśli kadra nie wykonuje
doskonale automatyzowalnych czynności.

[...]
> Nie żebym był złośliwy...

>:->

--
Secunia non olet.
Stanislaw Klekot

do góry

On 18/08/2013 22:21, Maciej Sobczak wrote:
>
> Czyli oficjalna wersja jest taka:
>
> 1. Waterfall jest do dupy, a dowodem na to jest fakt, że niektóre
> projekty prowadzone w ten sposób się nie udały.

Nieprawda. Dowód jest całkiem inny. Nie udające się projekty bywają
skutkiem dodupności waterfalla.

Zresztą oczywiście ta dodpuność jest kontekstowa, są sytuacje, gdzie
waterfall jest najlepszym możliwym rozwiązaniem i tam jak najbardziej
może być tak, że projekt upada, bo waterfall jest źle zastosowany.

do góry

On Sun, 18 Aug 2013 14:21:48 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>W dniu niedziela, 18 sierpnia 2013 04:06:17 UTC+2 użytkownik Stachu 'Dozzie' K.
napisał:
>
>> Prawdę mówiąc w ten sposób można zdyskwalifikować wszystkie nieudane
>> projekty jako nieprawidłowe użycie agile/scruma, a przecież nie o to
>> chodzi.
>
>Jest gorzej. Agile reklamuje się przez kontrast do "dawnych" metodyk (czyli do
waterfalla), gdzie jak wiadomo projekty się nie udawały. Problem w tym, że dokładnie
na takiej samej zasadzie zamiast twierdzić, że waterfall jest do dupy (i w związku z
tym agile jest dobry) można uznać, że waterfall jest dobry, tylko że go źle stosowano
w tych konkretnych projektach, które się nie udały. Ale wtedy główna linia
marketingowa agile przestałaby istnieć.
>
>Czyli oficjalna wersja jest taka:
>
>1. Waterfall jest do dupy, a dowodem na to jest fakt, że niektóre projekty
prowadzone w ten sposób się nie udały.
>Zapamiętajcie: projekt w waterfallu się nie udał -> waterfall jest zły.
>
>2. Agile to nie waterfall, więc agile jest dobre - a to, że jakieś projekty się w
agile nie udają oznacza tylko tyle, że agile jest tam źle stosowany.
>Zapamiętajcie: projekt w agile się nie udał -> agile było źle stosowane.
>
>Nie żebym był złośliwy...

Peoblem jak sadze polega na tym ze wterfall to byla metodologia, a
agile to religia...

A.L.

do góry