W dniu 2013-08-16 21:26, Wojciech Muła pisze:
>> Pytanie jest takie - jeśli wam nie wystarczały np. cztery godziny przy
>> >dwutygodniowym sprincie, to znaczy, że osiem godzi dla miesięcznego
>> >sprintu powinno wystarczyć, ale się nie skaluje liniowo? I dlaczego nie?
>> >Przecież na dwa razy dłuższy sprint będzie do omówienia, wyszacowania i
>> >tak dalej dwa razy więcej itemów?
> Z moich obserwacji wynika, że tego nie da się przewidzieć. Być może
> wynika to ze specyfiki firmy, bo z jednej strony rozwijamy nowe systemy,
> ale mamy też na głowie kilka działających i musimy je utrzymywać oraz
> dodawać do nich nowe rzeczy.
>
> 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. Skoro są
sprinty, w których "tylko utrzymujemy", to wypada się zastanowić, czy
na pewno potrzeba w ogóle pracy nad tym projektem.

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

Zupełnie na koniec - jeśli coś jest trudne do oszacowania, to częściej
sprawdza się oszacowanie pesymistyczne.

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

do góry

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?

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

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

Silne założenie 8-) Ile czasu implementowaliście? Czy konsultanci
robili coś w rodzaju audytu po jakimś czasie?

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

Zgłaszacie te wątpliwości na retrospekcji? Jakieś wnioski z tych uwag?
Próbowaliście coś zmieniać, żeby było lepiej?

Tak naprawdę to te elementy stanowią o Agile - umiejętność poprawiania
się.

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.


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

do góry

W dniu 2013-08-18 23:36, Stachu 'Dozzie' K. pisze:
> 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.

Scrum zakłada, że kadra jest kompetentna również w zakresie
samoorganizacji. Że ludzie potrafią zauważyć, co mogą zrobić inaczej
i lepiej i mogą to zmienić. Sztywne są tylko ramy, w których
przeprowadzać zmiany tak, żeby dało się łatwo zaobserwować skutki tych
zmian.

Możliwe, że takie podejście da się stosować również w waterfallu, choć
tam może być trudniej z bezpośrednim stosowaniem. Bo jeśli mieliśmy złe
rozwiązania w fazie implementowania, to wnioski możemy zastosować
dopiero przy następnym projekcie (upraszczam oczywiście).

Pewnie to różni zespoły, które kończą projekty z sukcesem od tych,
którym nie wychodzi - potrafią uczyć się na swoich błędach, są świadomi
nie tylko co robią (merytoryczna zawartość projektu), ale i jak robią
(organizacja pracy).

Scrum pomaga o tyle, że w iteracjach można szybciej poprawiać błędy,
a "fetysze/ceremonie" zmuszają do zastanowienia się, co nie działa,
a co może działać lepiej.

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

do góry

W dniu 2013-08-17 23:27, Wojciech Muła pisze:
> 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.

Jeśli w to się zdarza w jednym sprincie, to cóż - flukutacja 8-) Ale
jeśli w drugim z rzędu, to trzeba coś zrobić, żeby w trzecim się nie
powtórzyło.

>
[...]
>> A tak swoją drogą, estymaty robicie w story pointach, roboczogodzinach
>> czy w czym?
>
> Dla story - w storypointach, po rozbiciu na taski już w roboczogodzinach.

Z ciekawości - do czego potem te szacowania się przydają? Czy na
podstawie tych cyferek podejmujecie jakiekolwiek decyzje? Pytam, bo
zrezygnowaliśmy z tego szacowania, bo storypoints dla historyjek
wystarczają nam póki co.

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

Czyli ok. 5%. To nie jest dużo.

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

Z obserwacji - do godziny wszyscy dobrze działają. Do półtorej są
w stanie z niejakim wysiłkiem skupić uwagę. Potem koniecznie przerwa,
bo dalsze siedzenie ciurkiem to strata czasu. Aha - przerwy oczywiście
timeboxować trzeba 8-)

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

do góry

On 17/08/2013 22:51, Wojciech Muła wrote:
> On Saturday, August 17, 2013 8:46:40 PM UTC+2, Marek Borowski wrote:
>
> 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.

W Scrumie nie ma tylko w tym sensie, że Scrum nie pisze że trzeba ani
jak trzeba. Ale też nie wyklucza takiego planowania. Przede wszystkim PO
skądś bierze backlog items i na jakiejś podstawie je priorytetyzuje
Scrum nie opisuje tego procesu z założeniem, że PO wie jak to robić, a
zespół developerski nie musi być w to zaangażowany, ale jest dość
oczywistym, że jednym ze źródeł tych rzeczy może być długoterminowy plan.

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

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

Tylko że tak naprawdę pokrycie testami służy w równiej mierze
użyteczności, co jakości (zakładając, że jakość jakaś jednak musi być),
a prędkość w sprincie to służyt jednak wyłącznie użyteczności a nie
jakości. Scrum jako taki do problemu jakości nie odnosi się w ogóle -
zakłada się, że w zespole developerskim po prostu są ludzie potrafiący
tworzyć oprogramowania o takiej jakości, jaka jest wymagana (ewentualnie
że zbadają temat i się douczą, ewentualnie że jak się okaże, że taka
jakość jest nie do osiągnięcia w tym zespole, to się to okaże w miarę
szybko i ubije się cały projekt minimalizująć straty).

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

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.

do góry

On 2013-08-19, Paweł Kierski <n...@p...net> wrote:
>> 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.
[...]
> Scrum pomaga o tyle, że w iteracjach można szybciej poprawiać błędy,
> a "fetysze/ceremonie" zmuszają do zastanowienia się, co nie działa,
> a co może działać lepiej.

Nie nie nie. To nie o to chodziło. Nie mówię, że ceremonie w Scrumie
mają być czymś złym. Mówię, że sama metodyka nie zastąpi kompetentnej
kadry, więc trzymanie się bardzo sztywno zapisanego z góry zestawu
regułek (czy to scrumowego, czy pochodzącego z waterfalla, czy z innego
ITIL-a) nie ma wielkiego sensu.

Programy nie powstają z metodyki, tylko z programowania. Znacznie
łatwiej o sensowny program u ludzi znających się na programowaniu,
którzy nie stosują żadnej metodyki niż u kretynów stosujących dowolną
metodykę.

Przez robienie fetyszu z metodyki rozumiem spisywanie ksiąg czy innych
dokumentów o procesach zamiast przyjrzenia się, co z tego rzeczywiście
pomaga zespołowi.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2013-08-19, Paweł Kierski <n...@p...net> wrote:
> 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?

Jak rozumiem, nie chodzi o *zabranianie*, tylko o *niewymaganie*.
Skoro nie jest wymagane, to wiele zespołów nie będzie tego robić nadal
tytuując się zgodynmi ze Scrumem (nie wiem jak jest z Wojtkowym).
Ergo: metodyka nie jest kompletna.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Monday, 19 August 2013 08:42:46 UTC+1, Stachu 'Dozzie' K. wrote:
> On 2013-08-19, Paweł Kierski <n...@p...net> wrote:
>
> Jak rozumiem, nie chodzi o *zabranianie*, tylko o *niewymaganie*.
> Skoro nie jest wymagane, to wiele zespołów nie będzie tego robić nadal
> tytuując się zgodynmi ze Scrumem (nie wiem jak jest z Wojtkowym).
> Ergo: metodyka nie jest kompletna.

A ktoś twierdził, że jest? Twórcy Scrumu? Jeśli ci wasi konsultanci tak
twierdzili, to chyba nawet nie przeczytali dobrze Scrum Guide:

"Scrum is not a process or a technique for building products; rather, it is a
framework within which you can employ various processes and techniques."

do góry

W dniu 2013-08-19 09:39, Stachu 'Dozzie' K. pisze:
> On 2013-08-19, Paweł Kierski <n...@p...net> wrote:
>>> 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.
> [...]
>> Scrum pomaga o tyle, że w iteracjach można szybciej poprawiać błędy,
>> a "fetysze/ceremonie" zmuszają do zastanowienia się, co nie działa,
>> a co może działać lepiej.
>
> Nie nie nie. To nie o to chodziło. Nie mówię, że ceremonie w Scrumie
> mają być czymś złym. Mówię, że sama metodyka nie zastąpi kompetentnej
> kadry, więc trzymanie się bardzo sztywno zapisanego z góry zestawu
> regułek (czy to scrumowego, czy pochodzącego z waterfalla, czy z innego
> ITIL-a) nie ma wielkiego sensu.
>
> Programy nie powstają z metodyki, tylko z programowania. Znacznie
> łatwiej o sensowny program u ludzi znających się na programowaniu,
> którzy nie stosują żadnej metodyki niż u kretynów stosujących dowolną
> metodykę.

100% zgody.

> Przez robienie fetyszu z metodyki rozumiem spisywanie ksiąg czy innych
> dokumentów o procesach zamiast przyjrzenia się, co z tego rzeczywiście
> pomaga zespołowi.
>

Właśnie Scrum jest czymś takim - spisaną księgą, która mówi jak ramowo
może wyglądać proces (nie każdemu będzie pasował - w utrzymaniu lepiej
sięgnąć np. po Kanban).

Ale przede wszystkim mówi właśnie to: przyglądajcie się co iterację, co
w procesie pomaga zespołowi i wdrażajcie poprawki tak samo, jak
budujecie produkt - od najbardziej potrzebnych kawałków. Tyle, że
retrospekcja, ponieważ jest na końcu iteracji może wydawać się najmniej
potrzebną... A tu właśnie jest klucz do poprawnego działania zespołu.

Może lepiej spojrzeć tak: przed planowaniem robimy retrospekcję, która
jest de facto planowaniem zmian organizacyjnych.

Scrum mówi tylko tyle, że retrospekcja powinna być, a co w niej się
pojawi, to sprawa tak samo lokalna, jak tworzony produkt.

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

do góry

Użytkownik "Paweł Kierski" <n...@p...net> napisał w wiadomości
news:kuso9u$36q$1@somewhere.invalid...
>W dniu 2013-08-19 09:39, Stachu 'Dozzie' K. pisze:
>> On 2013-08-19, Paweł Kierski <n...@p...net> wrote:
...
>> Programy nie powstają z metodyki, tylko z programowania. Znacznie
>> łatwiej o sensowny program u ludzi znających się na programowaniu,
>> którzy nie stosują żadnej metodyki niż u kretynów stosujących dowolną
>> metodykę.
>
> 100% zgody.

ale to przestarzałe spojrzenie

teraz zbieramy najlepszych gości z całego zespołu
i na dzien dobry ich zwalniamy (AL) :))))

Potem zatrudniamy (frr)-ów i w ramach tworzenia np. systemu HR
robimy strzelankę ( wybór celu na spotkaniu grupowym)
jak klient kaprysi -że nie o to chodziło - to mu tłumaczymy - że to
odstrzeliwania zbyt zdolnych pracowników. I , że niech sprawdzi
bo ludzie z HR będą zadowoleni z tego rozwiązania :))))


Trzeba spojrzeć na tę metodologię jako na optymalizacje gradientową
w sytuacji niokreślonego wyraźnie celu ( klient nie wie co chce)
i w sytuacji zmiennej funkcji - sytuacja u klienta i u nas sie zmienia
bardzo dynamicznie. Nie ma co narzekać.Czasy sa dynamiczne
to i metody muszą być odpowiednie :))))

pozdrawiam

do góry