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.

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

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

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

> > Analogią raczej byłoby zamówienie stworzenia nowego modelu traktora.
> > Firma potrzebuje nowy model traktora, który będzie maił jakiś
> > specjalny ficzer, i dostaje taki model, tylko że po dostarczeniu
> > okazuje się, że ten model grzęźnie w błocie i jako taki jest
> > bezużyteczny. Wykonawca twierdzi, że dostarczony prototyp spełnia
> > wszystkie warunki zapisane w umowie, a jak zleceniodawca chce taki,
> > który nie grzęźnie, to on chętnie podpisze kolejną umowę na wersję
> > 2.0, tylko że będzie to kosztowało 50 milionów i zajmie kolejne dwa
> > lata.
>
> To zadna analogia. 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.

> 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. 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"? Że jeśli pierwszy protoyp grzęźnie w błocie, to spec od
traktorów zgłosi user story "wjeżdżam traktorem na błoto i chciałbym,
żeby on się nie zagrzebał" i przy planowaniu kolejnej iteracji i
odpowiednio określi jego ważność. I że zleceniodawca będzie wiedział,
że wykonawca pracuje nad jeżdżeniem po błocie, bo go jego
przedstawiciel o tym poinformuje.

> 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.
Produkcja seryjna to tłoczenie płytek. :)