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