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