Andrzej Jarzabek wrote:

> On May 18, 2:19 pm, Michal Kleczek <k...@g...com> wrote:
>> Andrzej Jarzabek wrote:.
>>
>> > A co zrobi, jeśli nie znajdzie dostawcy, który się na takie kary
>> > zgodzi (i o którym z dużym prawdopodobieństwem da się powiedzieć, że
>> > będzie wypłacalny)?
>>
>> Bedzie tak dlugo podnosil wynagrodzenie az:
>> a) znajdzie sie dostawca
>> b) stwierdzi ze sie nie oplaca i/lub znajdzie substytut
>
> No i w praktyce substytutem będzie wzięcie ryzyka na siebie.
>

Nie wiem jak "wziecie ryzyka" moze byc substytutem (zamiennikiem) produktu.

>> Jesli chodzi o wyplacalnosc dostawcy to przyjeta praktyka jest wymog
>> roznego rodzaju zabezpieczen finansowych. Jak dostawcy na takie nie stac,
>> to znaczy ze jest gowniany i wspolpraca z nim jest ryzykowna. Jezeli i
>> tak go wybieramy, to znaczy, ze stac nas na takie ryzyko.
>
> No i tak samo jest z agile: jak je wybieramy, to znaczy, że stac nas
> na takie ryzyko. Albo i nie stać, rzecz jasna.

Tyle, ze przy "agile" nie kupujemy produktu tylko _prace_ - to tu jest
roznica, a nie w sposobach zabezpieczania potencjalnych roszczen.

>
>> > Powszechnie wiadomo, ż projekty informatyczne
>> > często mają opóźnienia i że warunki są często renegocjowane. Wykonawcy
>> > oprogramowania, zwłaszcza jeśli mowa o dużych firmach, raczej nie będą
>> > chętne do brania na siebie ryzyka gigantycznych strat w przypadku
>> > kiedy okaże się, że czegośtam w praktyce nie da się zaimplementować.
>>
>> Dlatego tez istnieje cos takiego jak analiza wymagan, studium
>> wykonalnosci i inne metody pozwalajace zminimalizowac ryzyko wystapienia
>> takiego przypadku.
>
> Tylko że wtedy ponisimy takie ryzyko, że metody moga być kosztowne i
> czasochłonne, a minimalizacja mało efektywna.
>

Oczywiscie. Ale i tak jest taniej niz robic produkt do momentu az juz
bedziemy pewni, ze sie nie da.

>> Gdyby takich metod nie bylo to nikt by sie nie podjal budowy mostu
>> sredniej wielkosci (bo sa to metody dotyczace zarowno IT jak i innych
>> przedsiewziec). Te metody maja jedna rzecz wspolna - najpierw sie mysli,
>> potem sie robi - taki waterfall.
>
> Mosty mają swoją specyfikę, a oprogramowanie swoją. Jakby takie metody
> można było przyłożyć do wszystkiego, to można by było mieć
> przedsięwzięcie na zasadzie:
> "potrzebuję wiedzieć czy P=NP" albo
> "czy da się faktoryzować w czasie wielomianowym", albo
> "udowodnić/obalić hipotezę Riemanna",
> a kiedyś jeszcze - Wielkie Twierzenie Fermata.
> I dla każdego z tych problemów możnaby zrobić analizę i studium
> wykonalności, które by powiedziały jaki jest wymagany budżet, ilu
> matematyków trzeba wynająć i ile im to czasu zajmie. Uważasz, że tak
> się da?

To jest sprowadzenie ad absurdum, ktore nie ma IMO w tej dyskusji
zastosowania, bo projekty IT w przemysle nie sa badaniami naukowymi
(oczywiscie poza centrami badan). Podobnie jak budowa mostu nie jest
projektem majacym na celu wynalezienie antygrawitacji by przenosic pojazdy
ponad rzeka.

[ciach]
>> Jezeli klient nie wyartykuuje, ze traktor ma jezdzic
>> po blocie i w nim nie grzeznac, to dostanie traktor, ktory byc moze
>> bedzie, a byc moze nie bedzie grzeznac.
>
> No ale ponieważ oprócz grzęźnięcia w błocie jest milion innych
> problemów, które spowodują, że traktor będzie bezużyteczny, i ponieważ
> w praktyce spisując umowę zleceniodawca będzie w stanie sobie
> wyobrazić i zawrzeć klauule najwyżej na 100 tysięcy takich powodów, to
> pozostanie jeszcze 900 tysięcy sposobów, żeby traktor był kompletnie
> bezużyteczny, mimo że w 100% zgodny z umową:
> być może będzie a być może nie będzie grzęznąć
> silnik byc może się zatrze a byc może nie zatrze po dwóch minutach
> pracy
> chłodnia byc może będzie, a być może nie będzie cieknąć
> opony być może się nie stopią, a być może się stopią w temperaturze
> powyżej 30 stopni.
> itd. itp.
> Patrząc na to w ten sposób, zleceniodawca może się co najwyżej modlić
> i liczyć na cud, że 100% zgodny z umową produkt będzie się w ogóle
> nadawał do eksploatacji.
>

No a jednak jak kupujesz samochod to nic takiego sie nie dzieje. Rozumiem,
ze zanim go kupisz, to wspolpracujesz z dealerem na zasadzie "agile".

>> Sek w tym, ze metody "agile" zakladaja, ze
>> najpierw nalezy zrobic w pelni funkcjonalny traktor i za niego zaplacic,
>> a potem zobaczyc czy sie nada.
>
> Ale to jest przecież nieprawda. Agile (np. XP) zakłada, że
> zleceniodawca wyśle swojego speca od traktorów żeby siedział z
> zespołem projektującym traktor i z jednej strony mówił projektantom,
> że to jest jednak bardzo wazna sprawa, żeby traktor nie grzęzł w
> błocie.

No to albo klient powie o jakims wymaganiu albo nie powie - sugerujesz ze
"agile" jakos magicznie wplywa na klienta, ze powie?

> Zakłada, że po dwóch tygodniach będzie demo, gdzie zamawiający
> będzie mógł zobaczyć pierwszy prototyp i spytać "a po błocie to to
> pojedzie"?

Nie rozumiem po co klient ma placic za stworzenie demo traktora tylko po to,
zeby powiedziec, ze traktor ma jezdzic po blocie. Taniej by bylo po prostu
sie zastanowic po co nam ten traktor i jak go bedziemy uzywac.

>> Normalni ludzie, jak nie sa pewni czego chca to robia _prototyp_ (lub
>> serie prototypow). Ale nikt nie wymaga (w odroznieniu od agile), zeby
>> prototyp byl w pelni funkcjonalny - bo po co za to placic? (zreszta to
>> juz wtedy nie jest prototyp).
>
> Ale cały development oprogramowania, to tworzenie prototypów.

To jest wlasnie teza propagowana przez zwolennikow "agile". Ja sie z nia nie
zgadzam - i _nigdy_ nie wdrazam produkcyjnie prototypu (podobnie jak nie
kupuje prototypu samochodu, zeby jechac nim na wakacje).

--
Michal