Michal Kleczek <k...@g...com> napisał(a):

> 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.
>

Z tego jak ja kojarze te sprawy to 'agile' bierze sie ze spostrzezenia
ze programistyczni maniacy w stanie mani koduja wielokrotnie szybciej
i lepiej niz programisci odwalajacy kodowanie w trybie biurowym - >

( tak ze nie mysl ze agile jest po to by 'oszukiwac biznes'
jest odwrotnie, agile jest po to, by programowac wiecej i bardziej)

-> i to jest chyba raczej prawda - ale tacy maniacy zdarzaja dzis moge
powiedziec chyba dosyc rzadko (kiedys wydawalo mi sie ze jest ich
wiecej, a i mnie samemu takie maniackie napady zdarzaja sie ostatnimi
czasy dosyc malo, i stawiam raczej na spokojna wiedze i niezbedny
odpoczynek: wydajnosc i jakosc niezwykle spada z przemeczenia, nie ma
bata, potrzebne jest duzo czasu i duzo wiedzy i nauki




--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/