Paweł Kierski wrote:

> W dniu 2011-05-18 12:06, Michal Kleczek pisze:
> [...]
>> 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".
>
> Owszem. Ponieważ historycznie te banały zaczęły być stosowane
> w praktyce akurat dość daleko od produkcji oprogramowania.
>
> [...]
>> Moim zdaniem cale to "Agile" jest bardzo dobrym sposobem na wyludzanie
>> przez programistow pieniedzy bez ponoszenia najmniejszych konsekwencji
>> swoich dzialan. Ewentualnie (w lepszym przypadku) - usprawiedliwieniem
>> dla niekompetencji kierownictwa.
>
> Czy widziałeś "na żywo" działający zespół Agile? Choć przez tydzień?
>
> Gdyby tak było zawsze, to każda firma stosująca Agile by upadła. Bo
> programiści robiliby cokolwiek bez konsekwencji lub projekty
> prowadziłoby niekompetentne kierownictwo. A są firmy, które tego używają
> i działają. Być może nieoptymalnie - ale jak to sprawdzisz?
>

Tak zupelnie powaznie to mam spore watpliwosci czy sa firmy stosujace
metodyki "agile" w _calosci_ procesu produkcji oprogramowania. Jest to po
prostu niemozliwe, bo "metodyki agile" w ogole nie mowia o wielu istotnych
aspektach takiego procesu, koncentrujac sie tylko na jego drobnym wycinku.
Nie jest mozliwe stosowanie np. XP samego w sobie - wezmy przykladowo kilka
pytan, na ktore trzeba sobie odpowiedziec projektujac system:

0) czy w ogole potrzebujemy programowac? moze wystarczy kupic produkt z
polki? jesli tak to jaki? albo moze raczej kupic produkt(y) i go (je)
dostosowac lub zintegrowac?
1) potrzebujemy, czy tez nie RDBMS (jezeli tak to jaki) - to wariant 0)
2) w jakim jezyku (jezykach) programowania powinnismy stworzyc system (lub
poszczegolne podsystemy - a wczesniej - jakie podsystemy beda skladac sie na
nasz system?)
3) jakie oprogramowanie firm trzecich potrzebujemy (chociazby jaki(e) OS)
4) w jaki sposob (jesli w ogole) bedziemy integrowac nasz system z innymi
systemami - czy potrzebujemy np. ESB? jesli tak to jaki?
5) jak duzy zespol potrzebujemy?
6) jak bedziemy zarzadzac konfiguracja? jakich narzedzi do tego
potrzebujemy?
7) jak bedziemy zapewniac jakosc? czy potrzebujemy zakupic narzedzia /
sprzet / ludzi do stworzenia centrum testowego?
...) mozna tak dlugo

XP w ogole sie powyzszym nie zajmuje - raczej czyni niejawne zalozenie, ze
pewne decyzje sa juz podjete, infrastruktura istnieje itd, a teraz zostaje
juz tylko zajac sie pisaniem kodu.

>> 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
>
> Podstaw cokolwiek za "XP/Agile" i będziesz miał prawdziwe zdanie.
>

Nie rozumiem. Twierdze, ze wlasnie uzycie "XP/Agile" powoduje prawdziwosc
tego zdania. Wstawienie tam czegos innego moze (ale nie musi) tworzyc
prawdziwego zdania.

>> 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)
>
> Weźmy taki Scrum. Każda iteracja to umowa na wykonanie konkretnych
> funkcjonalności w konkretnym czasie. Selekcja funkcjonalności
> do kolejnej iteracji opiera się - niespodzianka! - na liczeniu ROI.
> Sortujemy po stosunku spodziewanego przyrostu wartości produktu do
> kosztu (z góry ustalonego) czasu pracy zespołu (+ ewentualne dodatkowe
> koszty).

Tyle, ze potrzebujemy wiedzy nie na temat 1 krotkiej iteracji, lecz _calego_
projektu, ktory planujemy. Jak mam wydac pieniadze na stworzenie produktu,
to chcialbym - z mozliwie duza pewnoscia - moc zalozyc ile wydam i ile
zyskam. Chociazby po to, zeby wiedziec czy w ogole mi sie oplaca zaczynac, a
nie po prostu kupic sobie nowy samolot albo pol wyspy na Karaibach.

>
>> 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
>
> Patrz odpowiedź do pkt. 1. A na marginesie przypominam, że Agile zakłada
> ciągłe doskonalenie procesu, czyli - niespodzianka! - zmiany.
>

Wybacz, ale Agile z usprawnianiem procesu ma tyle wspolnego, ze zaklada sie,
ze proces sie bedzie "zmienial". Toyota (lub firmy stosujace programy typu
TQM 6sigma itp) rowniez ciagle modyfikuje procesy, a nikt przy zdrowych
zmyslach nie powie ze stosuje "agile" - wrecz przeciwnie.

--
Michal