Andrzej Jarzabek wrote:

> On 21/05/2011 07:51, Michal Kleczek wrote:
>> Andrzej Jarzabek wrote:
>>>
>>> Dlatego testuje się przez _wszystkie_ iteracje. Np. jeśli masz release
>>> po trzech miesiącach od rozpoczęcia kodowania, to to, co masz w tym
>>> release jest już testowane od trzech miesięcy.
>>
>> Jak mozesz miec "juz przetestowana" calosc skoro wlasnie zakonczyles n-ta
>> iteracje i dolozyles funkcjonalnosc.
>
> Każda funkcjonalność jest testowana w każdej iteracji od momentu jej
> zaimplementowania, bo najpierw się pisze test, a potem implementację.
>
>> To sie da tak robic jak twoj zestaw testow da sie wykonac w ciagu 15
>> minut.
>
> To oczywiście zależy od produktu.
>
>> Taki zestaw testow to sobie w dupe
>> mozna wsadzic. _Realne_ testowanie to jest takie, ze _automatyczne_ (nie
>> manualne) testy trwaja na tyle dlugo, ze nie da sie tego robic "na
>> biezaco", bo wstrzymywaloby to zbyt dlugo prace programistow (np. kilka
>> dni).
>
> To zależy od produktu. Generalnie im więcej funkcjonalności, tym dłużej
> trwają testy, ale wiele produktów w stanie release można automatycznie
> przetestować przez noc, więc jeśli codziennie robisz build/integrację,
> to możesz go testować przez noc.
>
> Jeśli nie dasz rady zrobić wszystkich testów przez noc, to możesz
> wyizolować, które testy mają kiepski stosunek czasu do
> prawdopodobieństwa faila, i te testy robisz tylko raz na iterację. Jeśli
> dwa-trzy dni wystarczą, to w niektórych krajach jest takie coś, jak
> weekend.
>

Mam wrazenie, ze sie nie rozumiemy. Problem nie jest techniczny, tylko
_organizacyjny_ . Jeszcze raz:
1) NIE DA SIE przeprowadzic testow w krotkim czasie i przy niskim koszcie.
2) Jezeli sie da, to oznacza tylko tyle, ze nasze testowanie jest slabe i
wroc do p. 1)
3) To, ze testy trwaja dlugo i sa kosztowne powoduje, ze musimy w _procesie_
ten fakt uwzglednic

> Ostatecznie też nie jest tak, że jak się robią automatyczne testy, to
> programiści muszą siedzieć na rękach. Możesz spokojnie ustalić proces
> tak, że testy się wykonują, a programiści już kodują nowe testy i nowe
> ficzery.

Pisalem o tym - wtedy _musisz_ utrzymywac galezie, a przy krotkich
iteracjach musialoby byc ich nieoplacalnie duzo.

>
> Zakładając jednak, że masz mały zespół w którym jest najwyżej 9
> programistów, to zanim dojdziesz do etapu, gdzie automatyczne testy
> trwają tydzień, to upłynie sporo wody (to oczywiście zależy od specyfiki
> produktu, ale typowo tak jest). Ponieważ cały czas rewidujesz proces, to
> zanim do tego dojdzie zespół będzie mógł zdecydować, co z tym zrobić.
> OPcji jest kilka:
> * Zrównoleglić testy

jw. - problem nie jest techniczny (gdyby dalo sie przyspieszyc testy, to
bylyby juz przyspieszone - w koncu programisci robia wszystko najlepiej jak
potrafia)

> * Wydłużyć iterację (owszem, generalnie metodologie z krótką iteracją
> uznają, że w dojrzałych produktach w części przypadków wydłużenie
> iteracji ma sens)

O tym nizej.

> * Podzielić produkt

LOL - co to zmienia? Przeciez i tak _musisz_ wtedy zrobic testy
zintegrowanych _dwoch_ produktow jako calosci.

> * Zmienić proces tak, że między zakończeniem iteracji a "ready to
> release" trwa tydzień.
>

1. To to samo, co wydluzenie iteracji.
2. Tydzien to za krotko, bo przeciez zanim bedzie "ready to release" musisz
nie tylko przeprowadzic testy, ale tez poprawic bledy i przeprowadzic testy
jeszcze raz (takich cykli pewnie kilka).


>> Jezeli takie testy maja sie odbywac "non stop", to oznacza, ze release'y
>> musisz robic w cyklach rownych dlugosci trwania testow. A jesli trafi ci
>> sie blad tzw. "krytyczny", ktory stopuje testowanie w polowie, to co
>> robisz?
>
> Od razu: "ready to release" nie oznacza "robisz release".
>
> Jeśli któryś test failuje, to dana iteracja nie jest "ready to release".
>

To w takim razie co oznacza "robisz release"?

>> Masz dwa wyjscia:
>> 1) Czekasz na kolejny release (co oznacza, ze przestajesz testowac _ten_
>> release)
>> 2) Robisz galaz rownolegla do biezacego developmentu i poprawiasz ten
>> blad i odpalasz testy od poczatku. Tyle, ze wtedy albo
>> a) nastepna iteracja nie jest testowana (bo pojawia sie zanim testy
>> poprzedniej sie skoncza) - co de facto oznacza po prostu wydluzenie
>> iteracji (a co jesli w drugim podejsciu znajdziemy drugi taki blad)
>> b) testujesz rownolegle dwie (lub wiecej) iteracje-releasy (jesli to w
>> ogole mozliwe) ze wszystkimi konsekwencjami utrzymywania wielu galezi,
>> mergy, regresji itd - i tak sie robi, ale zeby nie zapanowal chaos
>> releasy nie moga byc zbyt czesto
>
> Przede wszystkim tak: jeśli masz buga w danej iteracji, to naprawienie
> tego buga staje się absolutnym priorytetem. Jeśli ma to sens, to
> wsztrzymujesz pracę nad nowymi stories do czasu naprawienia buga,
> ewentualnie możesz wstrzmać część nowych prac i zabronić dodawania
> czegokolwiek, co ma potencjał do konfliktu z bugfixem.

LOL - czyli czegokolwiek, bo w momencie "test failure" wiemy tylko, ze jest
blad - nie znamy jego przyczyny i moze sie okazac, ze blad jest na tyle
powazny, ze musisz zrobic potezny refaktoring, zeby go naprawic.

> Jeśli nie chcesz
> tracić czasu i chcesz, żeby programiści nie zajmujący się naprawianiem
> buga pracowali nad swoimi stories, to mogą robić to na robiczym branchu.
>

I jak zrobia jakis refaktoring, to lezysz i kwiczysz, bo nie da sie pozniej
latwo (czytaj: tanio) zrobic merge'a. A co jesli po poprawieniu tego bledu
trafi sie nam nastepny podobny?

> Po drugie: jak naprawiasz buga, to naprawiasz go tak, żeby był
> naprawiony we wszystkich kolejnych iteracjach, a nie tylko w tej jednej,
> w której został znaleziony.

LOL - a niby jak zapewnic, zeby sie znowu nie pojawil skoro po drodze mozesz
zrobic dowolna rewolucje (refaktoring)? Powiesz programistom "nie
popelniajcie wiecej tego bledu"?

>
> Po trzecie: istotnym priorytetem jest to, żeby bugi były wyjątkiem, a
> nie regułą.

To banal.
Cala dyskusja o tym jaki powinien byc proces wynika z potrzeby minimalizacji
ilosci (szeroko rozumianych) bledow.

> Jeśli bugi są na tyle częste, że regularnie musisz opóźniać
> release, odwoływać demo lub ogłaszać, że dana iteracja nie jest "ready
> to release", to masz problem gdziee indziej. Robisz wtedy root cause
> analysis i zajmujesz się naprawą przyczyny tego stanu rzeczy.

To banal.
Poprawa procesu nie jest wylaczna domena "agile" (jesli w ogole jest domena
"agile").

Ale co najsmieszniejsze - kazdy specjalista od zarzadzania jakoscia, jak
zrobi "root cause analysis" w projekcie "agile" to mu wyjdzie, ze podstawowa
przyczyna bledow jest brak analizy wymagan i brak projektu.

Po drugie "agile" _z zalozenia_ akceptuje bledy w produkcie. W koncu zeby
klient mogl zglosic blad - czyli "niespelnienie wymagan klienta przez
produkt", to musi w ogole zobaczyc produkt, a w "agile" produkt mamy od
samego poczatku,

Zreszta na tym polega cale oszustwo "agile" - nie ma bledow, bo nie ma
wzgledem czego zweryfikowac, czy bledy sa, czy nie (czyli produkt robi to,
co robi, wiec nie ma bledow).

>
> Biorąc pod uwagę powyższe, zazwyczaj możesz zrobić tak, że wyrzucasz
> builda z poprzedniej iteracji i pracujesz nad naprawieniem buga w
> bieżącej iteracji, zachowując wszystkie stories, które są już zakończone
> i decydując case-by-case o tym, czy stories które są zaplanowane lub w
> trakcie będziesz nadal próbował zrealizować w aktualnej iteracji, czy
> odłożysz do następnej. Jeśli nie masz kompletnie spierdzielonego
> procesu, to naprawienie buga znalezionego w n-tej iteracji powoduje, że
> n+1 iteracja nie ma buga, więc jesteś ready to release.
>

Aha - rozumiem, ze to nie jest tak, ze na koniec kazdej iteracji
oprogramowanie _z zalozenia_ ma byc "ready to release"?
To w takim razie robi nam sie proces kaskadowy - mamy n iteracji, w ktorych
implementujemy "user stories" i potem m iteracji, w ktorych poprawiamy bledy
znalezione w testach i doprowadzamy do stanu "ready to release".

Moze najpierw sie zdecyduj, jaki proces jest "agile".

>
>>> Jak się robi porządnie, to się ma przeznaczone zasoby tylko do
>>> testowania danego produktu. Jak go nie testujesz, to te zasoby leżą
>>> odłogiem i kosztują z grubsza tyle samo.
>>
>> Normalnie (nie "agile") tobi sie to tak, ze masz oddzielny zespol tzw. QA
>> (moze byc nawet outsourcing), ktory obsluguje ci kilka produktow. Taki QA
>> nie kiwnie nawet palcem, jak mu nie dasz analizy wymagan, bo niby na
>> jakiej podstawie ma przygotowac testy?
>
> Tu znowu raczej niż się zastanawiać co jest a co nie jest "agile",
> odniosę się do konkretnej metodologi Shore&Warden. Otóż w niej zakłada
> się, że zespół nie pracuje z oddzielnym działem QA, tylko sam robi
> testowanie swojego produktu.

LOL - Dzieki temu wszystkie testy "przechodza".

A jakosc produktu pozostaje bez zmian...

> Ma w związku z tym swoich testerów i swoje
> zasoby do testowania.
>
> Jeśli chodzi o to, jak jest "normalnie" to też bywa różnie: ja
> pracowałem w dużej firmie (spółka akcyjna z indeksu FTSE100), wcale nie
> w procesie agile, ale właśnie na takiej zasadzie, że mieliśmy testowanie
> tylko wewnętrzne, nie było żadnego działu QA.

Nie chodzi o to, zeby byl formalnie odrebny dzial QA, tylko o to, ze
testowanie to jest tak szeroka dzialka, ze potrzebujesz miec _specjalistow_
od testow _innych_ niz programisci (bo programista o testowaniu w porownaniu
do specjalisty od testow guzik o testowaniu wie - jest 4 ligi nizej). I ci
specjalisci zajmuja sie tylko przygotowaniem testow i testowaniem (bo na
programowaniu sie nie znaja tak dobrze jak programisci).
Co wiecej - musisz im dac czas na przygotowanie testow. Co wiecej - jak juz
przygotuja testy, to kazda zmiana wymagan kolosalnie podraza testowanie (bo
trzeba zmieniac testy).

> Działało to bardzo dobrze.

Wekdlug kogo? Zespolu czy zleceniodawcy? :)
MSPANC

>
>>> Agile proponuje dokładniejszą specyfikację uzyskać w ten sposób, że
>>> programista jak nie wie co dalej robić, to rozmawia z customerem (lub
>>> analitykiem) i on mu to specyfikuje.
>>
>> O! pojawia sie analityk... Czy to nadal jeszcze "agile"?
>
> Czemu nie? W Shore&Warden jest opisana rola analityka w zespole. Poza
> tym to jest "lub analityk", czy faktycznie analityk jest potrzebny
> zależy od projektu.
>
>> A skad "analityk" wie, co chce klient? Pewnie robi "analize"? To ja
>> zapytam - kiedy robi te analize? Bo przeciez musi byc "on site" z
>> programistami, zeby mogl z nimi "rozmawiac" - znaczy "analize" wykonal
>> wczesniej. Cos mi pachnie "kaskada".
>
> No więc ja się nie dziwię, że masz takie dziwne wyobrażenie, skoro nie
> wyłapałeś i nie doczytałeś kluczowej sprawy: klient siedzi on site z
> programistami i ewentualnymi analitykami. Konkretnie masz rolę tzw.
> "customer representative" lub "on-site customer" (w żargonie XP skrótowo
> nazywanego customerem), która z definicji jest osobą rozumiejącą i
> mogącą podejmować decyzje co do tego, jak program ma być używany. W
> przypadku programu robionego na zewnętrzne zlecenie powinien to
> zazwyczaj być faktycznie przedstawiciel zleceniodawcy (ewentualnie ktoś,
> komu zleceniodawca w tej kwestii ufa).

To nic nie zmienia. Przeciez to nie jest tak, ze "customer representative"
wszystko wie, bo doznal objawienia. On musi wykonac jakas _prace_ zeby
"wszystko wiedziec". Ja sie pytam - kiedy ma ja wykonac w procesie "agile"?
Na biezaco? Jezeli tak, to by oznaczalo, ze na poczatku projektu on tez nic
nie wiedzial - wiec po co komu taki "customer representative"?
A jezeli nie na biezaco, tylko wczesniej - to mamy model kaskadowy.

Im dluzej z toba dyskutuje, tym mniej sensu i logiki widze w tym calym
"agile".

>
>>> Jako metodę dokładniejszej
>>> weryfikacji proponuje się pokazanie customerowi działającego prototypu i
>>> spytanie czy właśnie o to chodziło.
>>
>> To "prototypu", czy tez "produktu"? Bo jezeli "prototypu" to po ch...
>> tracic pieniadze na np. "pair programming" zeby go przygotowac?
>
> Żeby potem nie tracić pieniędzy na przepisywanie jeszcze raz programu,
> który działa i robi to, co trzeba.
>

No, ale "refaktoring" przeciez na tym polega.
Naprawde, gubie sie w tej pokretnej logice "agile".

> Jeśli spodziewasz się, że szansa na to, że jakakolwiek znacząca część
> funkcjonalności prototypu trafi do produkcji, to można pisać go jako
> throwaway code, który nie musi być programowany parami.
>
>>> Przecież to, co jest w specyfikacji też potencjalnie nie jest nikomu
>>> potrzebne. Na szybko z co najmniej dwóch powodów:
>>> a) było potrzebne w momencie tworzenia specyfikacji, ale już nie jest
>>> b) nigdy nie było potrzebne, ale analityk popełnił błąd i wpisał, bo
>>> uznał że potrzebne.
>>
>> Obydwa przypadki sprowadzaja sie do tego, ze popelniono blad w trakcie
>> analizy wymagan. Oczywiscie - zdarza sie. Ale to nie jest tak, ze skoro
>> analiza wymagan jest trudna, to po prostu nie robmy analizy wymagan, za
>> to "robmy produkt i zobaczymy czy bedzie dobry" (co jak rozumiem
>> proponuje "agile").
>
> Czemu nie? Jeśli z powodu błędów korzyści z analizy nie równoważą
> kosztów, to nie robisz analizy.
>

Ja bym jednak po prostu poprawial analize. Moze poczytal troche literatury,
moze poszedl na szkolenia, moze zatrudnil dobrych analitykow na miejsce
polowy (po jednym z pary) programistow...

>>> 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...
>
> Co to znaczy "bez końca"? Jeśli to, że po otrzymaniu wersji 1.0
> zleceniodawca płaci i zamawia 1.1, 1.2 etc. ad infinitum, to super.

Dla kogo? Dla zleceniodawcy? Musialby byc szalencem, zeby "super" dla niego
oznaczalo placic darmozjadom bez konca.
I nie wciskaj mi kitu o "zarabianiu" czy tez "odnoszeniu korzysci" przez
klienta z niepelnego produktu.
Jesli klient (firma branzy A) mowi "potrzebuje produktu X zeby zarabiac", a
programista przychodzi i mowi mu "nie dam ci X tylko Y bo przeciez Y ci
wystarczy do zarabiania" to znaczy, ze programista zna sie lepiej na
zarabianiu w branzy A. Ja to nazywam "pycha" - Moze wiec otworzy firme
branzy A zamiast sie zajmowac programowaniem?

>
> Jeśli masz sytuację, że customer uniemożliwia dostarczenie nawet MMF
> przez ciągłe zmiany wymagań na kompletnie odmienne, to jest pewien
> problem. Ale też nie jest to problem nie do przejścia: tutaj działa to,
> że masz customera on-site i feedback loop: w pierwszej kolejności pytasz
> "no dobra, tydzień temu mówiłeś tak, zrobiliśmy z tego story, dałeś to
> jako priorytet, a teraz mówisz, że jest śmak, o co chodzi?"
>
> No i może być faktycznie tak, że nie jest to jakiś celowy sabotaż, tylko
> np. albo się pomylił, albo nastąpiła jakaś obiektywna zmiana
> okoliczności (powiedzmy dostawca zewnętrznych danych zmienił definicję
> jednego z pól). Ale w takim przypadku idziesz do zleceniodawcy i
> tłumaczysz, że są obiektywne trudności i trzeba wydłużyć termin i
> zapłacić ekstra.
>
> Zleceniodawca ma zaufanie, że faktycznie tak jest, bo:
> * customer mu to potwierdza,
> * customer jest jego pracownikiem,
> * customer został zatrudniony na podstawie tego, że rozumie wymagania i
> * że zleceniodawca mu ufa, ponadto
> * customer rozmawia z innymi specjalistami w swojej firmie i oni
> potwierdzają, że faktycznie tak jest.
>
> Oczywiście jeśli wychodzi, że customer jest niekompetentny, to też to
> zgłaszasz stakeholderom i wtedy jest to oczywista wina zleceniodawcy, że
> wyasygnował niekompetentną osobę jako swojego przedstawiciela.

Ja bym wyrzucil takiego wykonawce na zbity pysk i w calym srodowisku
rozglosil, zeby go nikt wiecej nie zatrudnial, bo to naciagacz.

Przeciez jak np. zleceniodawca to dajmy na to hurtownia win roznych, to
zatrudnia ona specjalistow od "win roznych", a nie od programowania.
Potem sie konczy tak, ze zleceniodawca mowi: "nie bylo takiego user story,
ze system ma byc odporny na ataki typu SQL injection - jak chcesz miec bez
SQL injection to musimy refaktoryzowac, a ty zaplacisz za 3 dodatkowe
iteracje".


[ciach]
>> Jest roznica, miedzy "prototypem" i "dzialajacym programem". Wytworzenie
>> "prototypu" jest nieporownywalnie _tansze_ niz wytworzenie "dzialajacego
>> programu".
>
> Zgadza się. Ale niekoniecznie dlatego, że wytworzenie danego kawałka
> funkcjonalności jest nieporównywalnie tańsze, przede wszystkim dlatego,
> że prototyp nie ma pełnej funkcjonalności i dlatego, że nie jest tak
> skrupulatnie testowany.

Wlasnie.
A bardziej ogolnie - wydano na jego wytworzenie mniej pieniedzy.
Wbrew pozorom samo napisanie kodu programu w IDE jest drobnym ulamkiem
kosztow wytworzenia wysokiej jakosci produktu.

> Pisanie czytelnego, przejrzystego kodu zgodnie z
> coding standards nie jest samo w sobie znacząco droższe od pisanie
> spaghetti code.
>

Patrz wyzej - to po prostu nie ma znaczenia. Nie ma sensu rozpatrywac
"pisania kodu" samego w sobie w oderwaniu od innych czynnosci ktore trzeba
wykonac, zeby powstal produkt wysokiej jakosci.
Od samego pisania kodu zgodnie z "coding standards" program nie zrobi sie
lepszy.

>>> Tu jest trochę fałszywe założenie, że taniej jest pisać kod niższej
>>> jakości od kodu wysokiej jakości.
>>
>> Drozej jest?
>
> Mniej więcej tak samo drogo.
>

No sam przed chwila napisales, ze jest taniej, bo nie trzeba testowac.
Ta pokretna logika "agile"...

>>> Może być tańsze tylko o tyle, że
>>> możesz do tego wykorzystywać słabszych programistów którym gorzej
>>> płacisz,
>>
>> Albo, ze dobry programista robi "na kolanie" prototyp w 15 min, zeby go
>> pokazac i omowic, po czym wyrzucic.
>
> Może tak być, ale dobry programista nawet pisząc na kolanie tworzy
> porządny kod bez bugów.
>

LOL - jezeli "metodyka agile" na takich zalozeniach sie opiera to jest to od
poczatku "death march".

Smiem twierdzic, ze jezeli jakis czlowiek twierdzi, ze na kolanie w 15
minute potrafi napisac cokolwiek poza "hello world" bez bugow - to nie jest
dobrym programista. Bo jedna z rzeczy, ktore wyrozniaja dobrych programistow
jest _pokora_ .

>>> Poza tym do wyrównywania (w górę) poziomu kodu masz takie praktyki jak
>>> coding standards, collective code ownership i pair programming (lub code
>>> review).
>>
>> Ale po co je stosowac do czegos, co i tak zaraz przepiszemy od nowa?
>
> Żeby nie tracić czasu i pieniędzy na pisanie od nowa.
> I jeszcze raz:
> oczywiście, czasem lepiej nie stosować i potem ewentualnie pisać od
> nowa. XP obejmuje też takie przypadki.

No ale przeciez "agile" wlasnie zaklada ciagle pisanie od nowa - czym innym
jest "refaktoring"???
Wlasnie przeciez o tym dyskutujemy: zwolennicy "agile" twierdza, ze lepiej
jest napisac szybko i potem przepisywac/refaktoryzowac. Przeciwnicy - ze
lepiej napisac raz a dobrze (ale zeby tak zrobic, to trzeba wczesniej
wykonac iles tam czynnosci czyli analize/projekt).

Ach, ta pokretna logika "agile".

>
>>>> jezeli np. na poczatku podejmiemy decyzje o tworzeniu tego
>>>> oprogramowania dajmy na to w C# (bo zespol uznal, ze tak najlepiej) a
>>>> potem okaze sie, ze klient zapomnial nam powiedziec o tym, ze to ma
>>>> dzialac na Solarisie (z jakichs tam powodow), to jak niby mamy zrobic
>>>> "refaktoring" nie przepisujac tego oprogramowania w calosci???
> [...]
>> 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.
>
> Nie takich problemów (że refactoring jest praktycznie niemożliwy) jest
> bardzo mało. Spróbuj wymyśleć jakiś inny przykład, niż zmiana języka.

Podzial na moduly (oddzielnie budowane i wersjonowane biblioteki) i
definicja interfejsow miedzy nimi - refaktoryzacja interfejsow jest
_cholernie_ droga (wiem, bo przerabialem to).

Albo wybor zlej biblioteki GUI.

Albo nieuwzglednienie faktu, ze system musi byc rozproszony.

Albo nieuwzglednienie faktu, ze trzeba obslugiwac i18n.

Albo: robisz GUI "przegladarkowe", a okazuje sie, ze musisz obslugiwac
"disconnected client".

Albo: dowiadujesz sie, ze system wymaga RBAC, bo do czesci funkcji/danych
nie wszyscy moga miec dostep.

Albo, albo, albo...

Tak generalnie:
trzeba zrozumiec, ze _kazdy_ refaktoring to ponoszenie dwa razy kosztow
wykonania tego samego.

>
> (Niech zgadnę: zleceniodawca powiedział, że chce program do księgowości
> a potem się okazuje, że zapomniał dodać, że właściwie to on ma sterować
> promem kosmicznym)
>
>> 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.
>
> Przecież nie półgodzinnej rozmowy, tylko ciągłej pracy z. I w sumie nie
> tak łatwo o przykład takiej decyzji, której odwrócenie np. po tygodniu
> jest "bardzo kosztowne".

Oczywiscie, ale twoje twierdzenie bylo takie, ze refaktoring jest tani
_zawsze_.
Ach, ta pokretna logika "agile".

> Jedno, co mi przychodzi na myśl, to konieczność
> zakupu już na początku jakichś bardzo drogich narzędzi czy systemów,
> mówimy o wydatku rzędu setek tysięcy dolarów (dla - przypominam -
> najwyżej kilkunastoosobowego zespołu). Bo wyrzucenie nawet całego kodu,
> który w pierwszym tygodniu napiszą programiści nie jest "kosztowne",

Oczywiscie. I dlatego wlasnie nie ma sensu, zeby zbyt wczesnie ponosic
koszty "pair programming", "coding standards", "unit testing" itd itp, bo to
co zrobimy _z zalozenia_ jest do wyrzucenia i sluzy tylko jako _prototyp_ .

--
Michal