On 19/07/2013 01:13, A.L. wrote:
> On Thu, 18 Jul 2013 06:55:29 -0700 (PDT), Maciej Sobczak
> <s...@g...com> wrote:
>
>>
>>> Zasadą metodyk Agile jest to że wymagania są płynne i mogą się zmienić.
>>
>> Tak. Ale jednocześnie niejawnie sugeruje, że te zmiany są tanie. Tymczasem nie są.
>
>
> Zmiany tanie nie sa. Potwierdzam.
>
> Gdy sie umawia z klientem na wykonanie projektu, to trzeba wiedziec
> ile projekt bedzie kosztowal.

Nie da się wiedzieć. Można się umówić, że wykonawca dostarczy program w
terminie według specyfikacji i że zapłacimy mu dwa miliony, to tylko
idiota może wierzyć, że znaczy to, że "projekt będzie kosztował dwa
miliony". Nawet zakładając, że wykonawca wywiąże się w 100% z umowy.

Tzn. faktycznie projekt może kosztować dwa miliony, ale tylko pod
warunkiem, że przyjmiemy możliwość (a nawet wysokie prawdopodobieństwo),
że za te dwa miliony dostaniemy software, którego nie będziemy mogli używać.

> Ustala sie to na podstaawie dokumentu
> wysylanago pzrez klienta do potencjalnych wykonawcow. gdzie sa
> wyspecyfikowane wymagania dotyczace projektu. Firmy wyceniaja i klient
> wybiera firme ktora chce. Niekoniecznie najtansza. Normalka.

Jest to jedna z możliwości, nie jedyna.

> Teraz, jak sie podpisze kontrakt, to jest obopolne porozumienie ze a)
> klient nie bedzei wymagal wiecej niz jest w kontrakcie, ani inaczej
> niz jest w kontrakcie b) dostawca dostarczy produkt zgodznie ze
> specyfikacja, w budzecie i w czasie.
>
> Wszelkie zmiany dotyczace zakresu projektu natychmiast rodza pytanie:
> "kto za to zaplaci". Bo wykonawcanei widzi powodu - tej dodatkowej
> funkcjonalnosci nie bylo w specyfikacji. Dodatkowo, takie extra
> wymagania naruszaja "timing" projektu - projektu nei da sie wykonac na
> czas, a za opoznienia moga byc kary umowne. Wiec co bedzie z tymi
> karami?
>
> Obie wysokie strony musza sie dogadac - w sparwie pieniedzy i w
> sprawie terminow.

Ale też taki układ niekoniecznie jest korzystny dla zleceniodawcy.
Przede wszystkim dlatego, że wykonawca ma w tym momencie wszelkie
powody, żeby wydoić z niego ile się da - w kwestii terminów i w kwestii
kosztów, żeby więcej zarobić i żeby zredukować swoje ryzyko. Jeśli np.
przy pierwotnych negocjacjach proponował termin będący dwukrotnością
szacowaneo czasu projektu i rentowność na poziomie 100%, to już
szacując, że poprawka będzie kosztowała dwa tysiące i zajmie tydzień,
powie zleceniodawcy że zrobi ją za dodatkowe 20 tysięcy i przesunięcia
terminu o sześć tygodni.

Ponieważ ilość poprawek nie może być znana z góry, odpowiedź na pytanie
"jeśli się umówimy na dwa miliony i dwa lata, to za ile pieniędzy i za
ile czau będziemy mieli system, którego używanie będzie miało sens"
brzmi "nie wiadomo, może za dwa lata i dwa miliony, ale to raczej mało
prawdopodobne; może to będą cztery lata i dziesięć milionów, a może
takiego systemu nie dostaniemy nigdy, i nawet nie będziemy mieli kogo
pozwać".

To nie jest tak, że z time and materials nie wiadomo ile będzie trwało i
kosztowało, a z fixed price, fixed scope wiadomo. Tak czy inaczej nie
wiadomo.

Z Agile różnica jest taka, że rzeczy są robione poczynając od
najbardziej wartościowych, dąży się do tego, żeby klient jak najszybciej
dostał coś, co się nadaje do użytku, i że jeśli uważa, że szacunki
podawane przez wykonawce są zawyżane, to może zakończyć współpracę i
wziąć to, co jest.

> Byc moze w sytuacji gdy caly projekt polega na "pierdyknieciu bazki
> szlauchow i kaloszy dla Miejskiego Przedsiebiorstwa Kanalizacyjnego" i
> jest robiony pzrez pojedynczego junior developera, mozna sobie
> swobodnie agilowac. Ale obawiem sie ze nawet Przedsiebiorstwo
> Kanalizacyjne nie wmontowaloby sie w projekt bez ustalenia ile
> kosztuje i kiedy bedzie zrobiony.

W jakim sensie "ustalenia"? Jeśli ustalenie nie musi mieć podkładki w
postaci umowy, to przecież ktośtam może ustalić.

Zresztą przy umowie typu time and materials też można to bardzo łatwo
ustalić. Na przykład iteracja trwająca tydzień kosztuje dwadzieścia
tysięcy, pierwszy release plan jest na dwadzieścia pięć iteracji,
zakłada się więc, że całość projektu będzie trwała pięćdziesiąt
iteracji, więc ustalono, że projekt będzie kosztował milion i będzie
zrobiony za rok.

> I na pewno Pzredsiebiorstwo
> Kanalizacyjne nie wydeleguje swojego pracownika zeby siedzial z owym
> deweloperem i patrzal mu na rece. Parcownicy Pzredsiebiorstwa
> Kanalizacyjnego musza sie bowiem zajmowac kanalizacja

Zaopatrzenie przedsiębiorstwa w bazę szlauchów i kaloszy to też częśc
zajmowania się kanalizacją.

> Zeby bylo konkretnie - bylem swiadkiem projektu w ktorym dodanie pol
> strony do specyfikacji kosztowalo zleceniodawce cwierc miliona
> dolarow. I nie bylo to nic takiego nadzwyczajnego

I dlatego klient nie będący idiotą może właśnie woleć Agile - żeby
uniknąć takiej sytuacji.