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