On May 18, 11:06 am, Michal Kleczek <k...@g...com> wrote:
>
> Z tego by wynikalo, ze "Agile" w ogole nic nie mowi na temat tego jak robic
> oprogramowanie oprocz garsci banalow w stylu "rob tylko rzeczy niezbedne" i
> "poprawiaj proces".

Zacząć by należało od tego, że "Agile" to nie jest jakiś konkretna
receptura, proces czy metodologia, tylko zbiór ogólnych pomysłów. W
ramach tych pomysłów istnieją mniej lub bardziej konkretne metodologie
i procesyy realizujące te metodologie, które są "agile" (przymiotnik,
nie rzeczownik).

Dalej, jeśli chodzi o samą koncepcję Agile, to jej banalność jest w
oku patrzącego, natomiast prawda jest taka, że często się tych
pomysłów nie stosuje.

Te pomysły to przede wszystkim położenie nacisku na bezpośrednią
komunikację, np. że raczej warto włozyć wysiłek w to, żeby z zespołem
siedział ktoś dobrze rozumiejący dziedzinę, niż żeby ktoś taki
przygotował szczegółową dokumentację. Że lepiej poświęcić czas na
napisanie prototypu, niż na stworzenie dokumentu projektowego. Żeby
nie bać się poprawiać śmierdzącego kodu na zasadzie "działa, więc
lepiej nie ruszać", że w bardzo wielu przypadkach nie da się dokładnie
ustalić z góry wymagań itd.


> > *) Największą karą i motywacją bywa świadomość, że coś się spieprzyło
> > w sposób absolutnie oczywisty.
>
> Jasne - programista przezyje niewyslowione katusze przezywajac porazke
> belkoczac po kolejnym glebszym.
> Inwestor natomiast zapozna sie z komornikiem.
>
> Moim zdaniem cale to "Agile" jest bardzo dobrym sposobem na wyludzanie przez
> programistow pieniedzy bez ponoszenia najmniejszych konsekwencji swoich
> dzialan.

A w nie-Agile jakie ponoszą konsekwencje? Mogą zostać wyrzuceni z
pracy? No to w Aglie tak samo mogą.

> Ewentualnie (w lepszym przypadku) - usprawiedliwieniem dla
> niekompetencji kierownictwa.
> To, ze (top) management w organizacjach kupuje tego rodzaju pomysly jest dla
> mnie troche niepojete. Jest kilka mozliwosci:
> 1) najbardziej prawdopodobne jest to, ze XP/Agile stosuje sie w projektach o
> tak malym znaczeniu i koszcie, ze tak naprawde wszystko jedno jak sie to
> robi, zas zarzadzanie mozna powierzyc jakiemus matolowi bo nawet jak
> spieprzy to nic nie nie stanie

Znam firmę żyjącą ze sprzedawania algorithmic trading platforms
produkowanych w ten sposób.

> 2) management to byli programisci, ktorzy nie maja pojecia o liczeniu
> pieniedzy/ROI itp. Nie moga oni awansowac zbyt wysoko i zajmowac sie czyms
> wazniejszym, bo firma poszlaby z torbami placac za oprogramowanie, ktore
> nigdy nie jest skonczone, dlatego patrz p. 1)
> 3) biznes jest taki dobry, ze przychody sa nieporownywalnie wieksze niz
> koszt ciaglego placenia za oprogramowanie i nie ma najmniejszej motywacji,
> zeby cokolwiek w tej dzialce zmieniac

W bardzo wielu przypadkach realia i tak są takie, że jak się chce
prowadzić biznes, to trzeba ciągle zmieniać oprogramowanie i w związku
z tym ciągle za to płacić. Bo nowa funkcjonalność, bo konkurencja, bo
systemy, z którym się łączymy zmieniają format danych, bo przepisy
itd. W rzeczywistości prawie wszystkie firmy produkujące
oprogramowanie, czy stosują agile czy nie, właśnie z tego żyją.

Jeśli natomiast mówimy o "skończeniu" w sensie dostarczenia pierwszej
wersji produkcyjnej dla klienta, to właśnie przecież jedną z koncepcji
około-agile jest to, żeby "skończyć" jak najszybciej: zamiast w
pierwszym kroku identyfikować wszystko, co klient chce mieć i wpisać
to do wymagań i dalej planować development tak, żeby w miarę
możliwości wszystkie wymagania dostarczyć w wersji 1.0, to starać się
zidentyfikować minimalny zestaw funkcjonalności, przy której produkt
jest w ogóle użyteczny dla klienta, i starać się zrobić wersję 1.0 z
taką funkcjonalnością, ale za to w dwa miesiące.