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.