On 19/05/2011 17:58, Przemek O. wrote:
> W dniu 2011-05-19 18:35, Andrzej Jarzabek pisze:
>
> Nie będę się tłukł z pokrętną logiką. Jeśli coś jest wymagane i obie
> strony o tym wiedzą to musi być to wpisane w umowę lub dokument
> określający zakres zlecenia.

I co, np. jeśli masz specyfikacje programu z GUI, to masz wpisane w
wymagania że program nie może reagować na polecenia uużytkownika z
opóźniniem większym niż ileśtam sekund? Że napisy nie mogą być białe na
białym? Że serwer nie może startować przez trzy dni?

>> zakłada, że zrobi traktor, który nie grzęźnie, ale gdyby były jednak z
>> tym trrudności, to nie musi renegocjować umowy i nie musi płacić kar
>> za opóźnienia - wiedząc, że jest takie wymaganie _może_ jednak
>> próbowac renegocjować umowę na swoją korzyść (np. wydłużając termin
>> albo zwiększając cenę za enchancement).
>
> Po pierwsze pisz po polsku. Po drugie z czego miały by wynikać te
> trudności? Chyba z niekompetencji zleceniobiorcy. Ale to już jego problem.

Proszę bardzo: umawiasz się na program biorący dane z jakiegoś
zewnętrznego źródła (nie związanego z twoim zleceniodawcą) i
przetwarzające je w jakiś sposób. Trudność może polegać na tym, że
specyfikacja źródła danych może zawierać informacje które są
niedokładne, niekompletne lub wręcz nieprawdziwe. W związku z tym
wypełnienie wymagań na przetwarzanie może wymagać wielokrotnie większej
pracy niż by wynikało z pierwotnej analizy opartej na specyfikacji. W
dodatku uzyskanie brakującej informacji może zająć czas, który trudno z
góry przewidzieć - bo np. zależy od tego, jak sprawnie te informacje
będzie w stanie uzyskać support dostawcy danych. A wszystkiego tego
dowiadujesz się dopiero jak napiszesz program i zaczniesz go testować na
rzeczywistych danych.

>> zleceniodawca może dostać pierwszy release na trzy miesiące przed
>> terminem i zacząć już na nim zarabiać, a my obiecujemy w dalszej
>
> Zakładając że da się wykroić interesującą zleceniodawcę część.

W przypadku większego programu często się da.

>> kolejności zająć się tym, co wypadło. I customer representative i
>> tygodniowe iteracje z wersją demo są również po to, żeby zleceniodawca
>> wiedział, że nie jest robiony w bambuko.
>
> Jeśli coś wypadło i okazuje się że zleceniodawca na pierwszym wydaniu
> może zarabiać, to zleceniobiorca zrobił go już w bambuko i wcisnął
> dodatkowe funkcje których nie potrzebuje do zarabiania. Racja?

Nie racja. Dodatkowe funkcje są do zarabiania jeszcze więcej.

>> Bo każdy porządny developer ma Oracle Machnine wpiętą w slota PCI.
>
> Wiesz, jeśli się robi z nastawieniem "agile" w wydaniu do którego
> próbujesz mnie przekonać to faktycznie powinien.
> Ale mając doświadczenie, porządną analizę wymagań oraz projekt. Nie
> potrzebuje jej, bo może oszacować zarówno koszt jak i termin wykonania.
> Że nie wspominając już o tym, czy w ogóle jest w stanie wykonać to zadanie.

Oczywiście, że można oszacować. Tylko że jest różnica między
oszacowaniem a rzeczywistością.

>> W interesie zleceniobiorcy jest również znać notowania giełdy na
>> przyszły tydzień, i żeby mu diamenty z nieba do ogródka spadały.
>
> ??? Sugerujesz że nie da się oszacować kosztów i terminu wykonania

Sugeruję, że "oszacować" to nie to samo, co "znać". W interesie byłoby
oczywiście znać koszta i terminy, ale oszacowanie nie daje ci tego, że
je _znasz_.

> projektu. No patrz, genialny jestem bo od wielu lat mi się to udaje. I
> najczęściej stosuje projekty kaskadowe lub kaskadowe z iteracjami. Żyje
> chyba we własnym świecie, tylko dlaczego mi za to płacą???

No popatrz, a mnie się wiele razy udało trafnie oszacować bez
udokumentowanej analizy i projektu. I widziałem jak innym się to też
udaje, więc chyba to nie dlatego, że jestem taki genialny. A skoro można
trafnie oszacować bez analizy i projektu, i można trafnie oszacować z
analizą i projektem, to znaczy, że pod względem przydatności do
szacowania czasu i kosztów analiza i projekt są bezużyteczne.

Tak, oczywiście możesz twierdzić, że analiza i projekt dają
dokładniejsze, bardziej zgodne z rzeczywistością oszacowanie. Ale po
pierwsze należałoby to uzasadnić, a tutaj dowód anegdotyczny nie jest
żadnym argumentem. W ogóle trudno tutaj o jednoznaczne przesłanki w
jedną i w drugą stronę, bo jest bardzo dużo zmiennych.

Natomiast nawet gdyby przewidywania były rzeczywiście dokładniejsze, to
pytanie czy na tyle dokładniejsze, żeby korzyści z tego równoważyły
koszta wykonania analizy i projektu. Moim zdaniem (ale też nie twierdzę,
że mam na to jakieś dowody) jest tak, że osoba lub zebranie osób z
odpowiednim doświadczeniem jest w stanie najwyżej w pół godziny trafnie
oszacować koszt i czas na podstawie prezentacji wizji i zadania kilku
kluczowych pytań (zakładając, że jest pod ręką ktoś, kto będzie potrafił
na nie kompetentnie odpowiedzieć). Jeśli szacowanie na podstawie analizy
będzie nawet dokładniejsze, to różnica będzie minimalna, bo analiza nie
bierze pod uwagę czynników takich jak powyżej.

>> Ja przecież nie zakładam, że zleceniobiorca wie z góry. Ja zakładam,
>> że nikt nie wie z góry.
>
> Czego nie wie? Banialuki opowiadasz. Zleceniodawca nie wie co potrafi?

Nie wie ile czasu zajmie i ile będzie kosztować.

> Bierze projekty w ciemno?

Co to znaczy "w ciemno"? Jeśli chodzi o to, czy podejmuje ryzyko, że
zajmie nie tyle, ile mu się wydaje, że zajmie, albo będzie kosztować nie
tyle, ile mu się wydaje, że będzie kosztować, albo że w ogóle się nie
będzie dało zrobić, to owszem, podejmuje takie ryzyko. Zawsze w biznesie
podejmuje się jakieś ryzyko.