W dniu 2011-05-21 08:51, Michal Kleczek pisze:
[...]
>> W agile masz tę zaletę, że najdalej na początku danej iteracji, w której
>> to coś jest implementowane, customer potwierdził że tak, na pewno jest
>> potrzebne, a co więcej jest to jedna z najważniejszych rzeczy, jakie
>> zostały do zrobienia.
>
> I projekt trwa bez konca... Ew. konczy jak c2 (tak, tak - pierwszy projekt
> XP) - czyli przychodzi ktos z gory i go brutalnie przerywa.

Dokładnie tak 8-) Przerywamy, jeśli w tym momencie spodziewany wzrost
przychodów po dodaniu pewnej funkcjonalności jest mniejszy niż koszt
kolejnej iteracji. Zarabialiśmy na kolejnych wersjach, na następnej
nie zarobimy, więc zamykamy lub zawieszamy robotę. Bo może pojawić się
nowa potrzeba, dla której będzie warto dołożyć funkcjonalność.

>>> - a to znowu z
>>> tego powodu, ze prototypy robi sie najtaniej jak mozna i ich jakosc jest
>>> daleka od jakosci oczekiwanej od produktu koncowego. Nie ma tez sensu
>>> nawet
>>
>> Tu jest trochę fałszywe założenie, że taniej jest pisać kod niższej
>> jakości od kodu wysokiej jakości.
>
> Drozej jest?

Może być. Gdy w ramach prototypu klient chce zobaczyć jeszcze jedną
funkcjonalność, a w środku jest tyle sznurka i taśmy klejącej, że
w typ prototypie nie da się jej dodać bez gruntownej refaktoryzacji
albo i przepisania prototypu.

[...]
>> No moment, ale pracujemy przecież cały czas z klientem. Czyli jest
>> powiedzmy wczesne zebranie zespołu, na którym siedzi customer
>> representative, i jest rozmowa o tym, w jakiej technologii wykonać.
>> Jeśli pada propozycja C#, to raczej padnie pytanie, czy można na pewno
>> założyć, że produkt będzie pod .NET, a .NET jest tylko pod Windows
>> (istnienie Mono na potrzeby dyskusji pominiemy). Od przedstawiciela
>> klienta raczej będzie się w tym momencie wymagało potwierdzenia, że
>> można takie założenie poczynić no i oczywiście trafia to do bieżącej
>> dokumentacji projektu. Jeśli klient potem zmieni zdanie, to mu można w
>> tej sytuacji powiedzieć, że nie zrobimy albo że trzeba będzie to z
>> punktu widzenia terminów i kosztóww potraktować jako robienie od nowa.
>
> To byl tylko przyklad _jednej_ decyzji, ktora musisz podjac. Problem nie
> lezy w tym, ze kazdy taki problem jest trudny, tylko ze tych problemow jest
> duzo.
>
> Bo takich decyzji projektowych, ktore trzeba podjac na poczatku (zeby w
> ogole mozna bylo zaczac programowac) i ktorych odwrocenie bedzie pozniej
> kosztowne jest cale multum. Czynnikow, ktore je determinuja tez jest cale
> multum.
> Wiara w to, ze mozna je wszystkie podjac na podstawie lub w czasie
> polgodzinnej "rozmowy" z "customerem" jest doprawdy naiwna.

Nie wszystkie. Te, które są aktualnie potrzebne. Chyba wiem, gdzie jest
pies pogrzebany. Agile w naturalny sposób stosuje się w projektach,
w których nikt nie ma pojęcia, co będzie za pół roku. A klient chce
(bo wg niego warto - robi to świadomie) podjąć ryzyko tworzenia
oprogramowania tak, żeby jak najszybciej dotarło na rynek. Wszystkie te
ryzyka związane z tym, że gdzieś się potkniemy i będzie to kosztowało
w którymś momencie przepisywanie wszystkiego są znane i akceptowane.
Bo wartością tego projektu jest wypuszczenie na rynek produktu jak
najszybciej. Nawet, jeśli nie ma wszystkiego, a tylko krytyczne
funkcjonalności. Chodzi zazwyczaj o to, żeby przy założonym czasie tak
dopasować scope i jakość, żeby wyprzedzić konkurencję. Szczegółowa
analiza na początku spowalnia wydanie pierwszych wersji. Po za tym
trzeba elastycznie odpowiadać na to, co akurat konkurencja wypuszcza.
Być może będą to funkcjonalności, których nie wzięliśmy pod uwagę na
początku, ale użytkownikom się spodobały.

W projektach o bardzo dobrze zdefiniowanym i "sztywnym" scope, przy
założeniu pewnej jakości negocjujemy czas i koszt. Do tego dobra,
robiona od A do Z analiza nie tylko ma sens, ale jest konieczna.

--
Paweł Kierski
n...@p...net