On May 18, 3:39 pm, Michal Kleczek <k...@g...com> wrote:
> 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.

OK, nie zrozumieliśmy się. W takim razie:
c) bierze na siebie ryzyko

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

No tak, tylko że przy nie-agile kupujesz produkt, którego nie ma i być
może nigdy nie będzie. Przy agile (powiedzmy) kupujesz konkretnie
pracę polegającą na tworzeniu konkretnego produktu, który być może
powstanie, a być może nie. W obywdyu przypadkach ryzyko polega na tym,
że produkt może nie powstać, lub powstać w innej formie, niż byśmy to
chcieli. Agile proponuje metodę aktywnego zarządzania tym ryzykiem. Bo
ogólnie prawidłowość jest taka, że jeśli znajdziesz kogoś, kto się
zgodzi pokryć 100% twoich strat w oprzypadku niedostarczenia produktu
i dać 100% gwarancję, to ten ktoś również poda cenę, która pochłonie
100% oczekiwanych zysków z eksploatacji programu.


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

Jeśli się faktycznie nie da. Owszem, takie właśnie jest twoje ryzyko:
zamówisz program, którego w ogóle się nie da zrobić w użytecznej
postaci i wtpoisz trochę kasy. Ale jeśli odsiejesz te propozycje,
gdzie na pierwszy rzut oka doświadczony członek zespołu od razu powie
"tego się nie da zrobić" lub chociaż "nie byłbym taki pewien, czy to
się rzeczywiście da zrobić", to jednak ryzyko tego, że się nie będzie
dało zrobić _w żadnej użytecznej postaci_ nie jest takie znowu duże.
Pomijając projekty typowo badawcze, przeszkodą w tworzeniu
oprogramowania raczej nie jest to, że czegos się obiektywnie 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.

A tworzenie oprogramowania nie jest budową mostu.

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

A mówimy o kupowaniu seryjnie produkowanych samochodów, czy zleceniu
wykonania unikatowego egzemplarza pod moje wymagania? Bo tego drugiego
nigdy nie robiłem. A jeśli chodzi o to pierwsze, to jak kupuję np.
program do obróbki video i mam do wyboru dwa, jeden robiony metodą
agile a drugi waterfall, to też nie jest tak, że w pierwszym przypadku
zgodze się płacić co miesiąc, po dwóch miesiącach dostanę wersję którą
będę mógł robic jakąkolwiek obróbkę, a potem mój przedstawiciel będzie
mówił programistom co bym jeszcze chciał, a w drugim przypadku napisze
listę czego bym chciał, a za miesiąc mi powiedzą ile muszę zapłacić i
za ile dostanę program. Raczej w obydwu przypadkach sprzedawca sięgnie
na półkę i poda mi pudełko - kompletnie bez różnicy, czy wezmę ten
agile czy nie agile.

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

Nie powie o wszystkich wymaganiach na początku, przy zawieraniu umowy,
bo o wszystkich się nie da powiedzieć.

Natomiast jak robisz agile i pokazujesz mu projekt albo prototyp,
który jakiegoś konkretnego wymagania nie spełnia, to jest spora
szansa, że na jakimś etapie klient to zauwazy i 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.

Pewnie, że taniej i pewnie, że to trzeba i tak zrobić. Problem tylko
taki, że samo zastanownienie się w żaden sposób nie zapobiegnie przed
dostarczeniem przez wykonawcę traktora, który grzęźnie w błocie.

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

Przecież zanim ten model samochodu, którym jedziesz na wakacje, został
wdrożony do produkcji, to producent zbudował prototyp nie różniący się
niczym od modelu seryjnego. Tutaj analogią stakeholdera nie jesteś ty,
tylko kierownictwo firmy produkującej samochód zlecające nowy model w
biurze projektowym.

Poza tym cała analogia samochodowa jest bzdurna.