On May 23, 12:43 pm, Michal Kleczek <k...@g...com> wrote:
> Andrzej Jarzabek wrote:
> > On 21/05/2011 07:51, Michal Kleczek wrote:
>
> > 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)

Odpowiem w twoim stylu:
1) DA SIĘ.
2) Jeśli się nie da z przyczyn organizacyjnych, to nasza organizacja
jest słaba.

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

Zazwyczaj wystarczą tagi. Po pierwsze dlatego, że bugi są rzadkie
(jeśli bugi są częste, to musisz zlikwidować przyczynę bugów).
Po drugie dlatego, że jednak nie każda iteracja to release, jeśli test
wyleci na iteracji, która nie jest do release, to nie musisz robić
brancha z tej iteracji, a nawet jeśli , to może być "short
lived" (naprawiasz buga żeby sprawdzić, czy jest naprawiony, mergujesz
i wyrzucasz). W praktyce ponieważ od wersji z bugiem minął najwyżej
tydzień, zazwyczaj możesz spokojnie oznaczyć daną iterację jako błędną
i naprawiać buga tylko w bieżącej.

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

Automatyczne testy robi komputer, jeśli te testy na jednym komputerze
trwają tydzień, to zazwyczaj można je zrównoleglić tak, żeby na trzech
komputerach robiły się przez weekend. Problem tylko taki, że trzeba
dokupić dwa komputery.

> > * Podzielić produkt
>
> LOL - co to zmienia? Przeciez i tak _musisz_ wtedy zrobic testy
> zintegrowanych _dwoch_ produktow jako calosci.

No ale wtedy masz trzy zespoły, które mają osobne cykle: zespół A,
zespół B i zespół C robiący integrację. Przy czym wtedy zespół A i B
releasują swój produkt do zespołu C, który dopiero releasuje
zintegrowany produkt do klienta.

Oczywiście to zwykle ma sens, jeśli przynajmniej jeden z tych
produktów ma jakąś użyteczność bez drugiego (np. drugi jest
opcjonalnym pluginem). Ale w praktyce często to właśnie ma sens.

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

To nie to samo, bo iteracja nadal trwa tydzień. Po prostu nie ostatnia
iteracja jest "ready to release", tylko jedna wstecz (zakładając, że
testowanie nie znalazło błędów).

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

Jeśli masz błędy. Jeśli masz nowy błąd co tydzień, to za dużo.
Oczywiście w momencie, kiedy znajdziesz błąd, to nie jesteś "ready to
release" tak długo, aż nie naprawisz błędu i nie przetestujesz
wszystkiego jeszcze raz, albo nie znajdziesz odpowiedniej iteracji
wstecz, kiedy błąd jeszcze nie występował (i nie przetestujesz jej z
uwzględnienim testu na znaleziony błąd, naturalnie). Przy czym ta
ostatnia sytuacja jest ekstremalna: jeśli błędu się nie da odpowiednio
szybko naprawić, a release jest absolutnie nieprzekładalny.

Oczywiście jak masz mandatory release, to możesz planować na tę
okoliczność wcześniej, np. miesiąc wcześniej robisz feature freeze (o
ile masz MMF) i cały wysiłek developerów kierujesz na pisanie nowych
testów, które puszczasz 24/7 i na exploratory testing.

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

Dostarczasz produkt klientowi. Jeśli masz być ready to release, ale w
testach wyleciał błąd, to nie jesteś ready to release i tyle. Jeżeli
przy tym nie było rzeczywistego release, to no harm done, poprawiasz
błąd i jedziesz dalej.

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

Być może.

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

No więc po to masz doświadczenie, żeby ocenić szansę takiego
zdarzenia. Również: starasz się naprawić bieżącą iterację, a nie
poprzednią. Jeśli potrzeba, to wycofujesz z tej iteracji tyle nowych
stories, ile potrzeba.

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

Ale wszyscy siedzą w tym samym pokoju, jest daily standup, jest shared
code ownership, jest rotacja par, więc wszyscy wiedzą co inni robią. I
wszyscy wiedzą, że naprawianie buga jest priorytetem, a nowe stories
są na dalszym planie, więc jak się robi większy refactoring - przy
jednym bądź drugim - to się mówi że się robi i jak trzeba, to się
wycofuje story i odkłada na później. W najgorszym przypadku tracisz
tydzień pracy programistów pracujących nad nowymi stories (a przecież
starasz się, żeby takich było jak najmniej), ale po pierwsze to jest
rzadkie, po drugie ponieważ robota jest integrowana w "dziennych
porcjach", to w wielu przypadkach problem można rozwiązać tak, że na
standupie ci od naprawiania błędu mówią "znaleźliśmy przyczynę błędu,
trzeba będzie refaktoryzować to-a-to", a wtedy ci od nowego story
mówią "chwileczkę, bo my tam właśnie zrobiliśmy zmiany, może najpierw
zreintegrujemy". I potem może być rotacja par, i programiści od buga
tłumaczą swoim partnerom od story dlaczego jest bug i co trzeba
zrefaktoryzować, żeby naprawić, a programiści od story tłumaczą swoim
partnerom od buga jakie zrobili zmiany w tym, co tamci chcą
refaktoryzować i jak te zmiany wpływają na plany refaktoryzacji. I
albo się robi reintegrację brancha a potem refaktoryzuje, albo się
wywala brancha i traci jeden dzień roboty (w rzeczywistości nawet nie
tyle, bo zakodowanie tej samej story drugi raz to jest zazwyczaj mniej
pracy, niż kodowanie po raz pierwszy.

> A co jesli po poprawieniu tego bledu trafi sie nam nastepny podobny?

To masz skopany proces albo niekompetentnych programistów. Pamiętaj,
że przy TDD, jak znajdziesz buga, to starasz się napisać najpierw
automatyczny test, który wychwytuje tego _i podobne_ bugi i buga
zunajesz za naprawionego dopiero jak program przechodzi ten test.

Albo po prostu masz pecha, ale pecha się ma rzadko, jak masz często
pecha, to patrz punkt pierwszy.

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

Napiszesz test, który wyłapuje ten błąd. I produkcyjny kod
refaktoryzujesz agresywnie, ale testy bardzo ostrożnie, jeśli w ogóle.

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

Masz dwa aspekty procesu: żeby nie było0 bugów, i żeby wyłapać bugi,
jeśli one jednak będą. Jak robisz testy, to zakładasz, że bugi mogą
być, ale jak tworzysz cały proces, to możesz założyć, że bugi będą
rzadko: jak bugi są często, to nie dostosowujesz procesu do tego, że
bugi są często, tylko usuwasz przyczynę: poprawiasz pierwszą część
procesu, doszkalasz pracowników albo wywalasz debili z roboty (albo -
jeśli masz dobre serce i cię stać - przesuwasz ich na stanowiska,
gdzie nie będą szkodzić).

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

Teoretycznie. Ja widziałem poprawę procesu wpisaną w prawie każdy
proces, jaki widziałem, ale w praktyce poprawa się nie odbywała (lub
odbywała niemrawo), bo nie było odpowiednich praktyk. Z takimi
praktykami dopiero się spotkałem przy zetknęciu z agile, choć nie
wątpię, że gdzie indziej są też.

Poza tym spotkałem się też z tym, że proces akceptował, że bugi będą
relatywnie często i nie uznawano tego za powód do zmiany procesu.

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

A ty o tym wiesz, bo posiadasz wiedzę każdego specjalisty od
zarządzania jakością oraz znasz wszystkie projekty agile na tyle, żeby
zrobić root cause analysis każdego buga, jakiego kiedykolwiek w takim
projekcie znaleziono.

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

Są dwie rzeczy: masz klienta w postaci modelowego użytkownika
programu, "customer" w żargonie XP, który siedzi z zespołem i mówi,
jakie są wymagania klienta. I on nie musi zobaczyć żadnego produktu,
bo zanim ktokolwiek cokolwiek zrobi, to customer musi powiedzieć, jak
ma być. I zgodnie z tym, co mówi customer, pisane są testy, które
program musi przejść, żeby stać się produktem.

Nawet jeśli customer źle powie, to to, że siedzi z zespołem powoduje,
że zanim powstanie produkt, będzie mu pokazany prototyp.

Oczywiście czasem sie zdarza, że to, co mówi customer nie jest zgodne
z tym, czeg chcą stakeholderzy. To jest tak w ogóle problem, ale agile
ma na to odpowiedź w postaci wersji demo po każdej iteracji, która
jest pokazywana i dawana stakeholderom.

Poza tym są różne poziomy błędów, poczynając od błedu
programistycznego, typu użycie niezainicjowanej wartości, nieskończona
pętla, wywołanie niewłaściwej metody itd. To są przede wszystkim te
bugi, których ma w ogóle nie być.

Drugi poziom to błąd biznesowy, zrozumiały dla każdego, kto wie, do
czego program ma służyć. Nie zalicza się do pierwszej kategorii, bo
jest zgodny z intencją programisty, wynika z braku zrozumienia
dziedziny przez programistę. Przed takimi błędami broni cię kilka
praktyk, ale mogą się one jednak zdarzyć. Jeśli się zdarzą i zostaną
wyłapane na poziomie exploratory testing czy pokazywania customerowi
prototypu, to dodatkową obronę przed powtórzeniem się ich daje
napisanie testu.

Ostatnia kategoria to "błędy" które chociaż są doskonale sensowne z
punktu widzenia tego, co program ma robić, nie pokrywają się z
oczekiwaniami klienta. Tego rodzaju błędy w ogóle trudno klasyfikować
jako "bug", to są "features" tylko takie, których klient/odbiorca nie
chce. Przed tym broni cię uczestnictwo on-site customera i
cotygodniowe demo. czy one nie mają być w produkcie, to już zależy, co
nazwiesz produktem: na pewno nie maja być w wersji release, ale mogą
się zdarzyć w wersji demo lub w daily buildzie. Jeśli się zdarzą w
wersji demo, to po to właśnie wersja demo idzie do stakeholerów i po
to ona jest "ready to release", żeby stakeholder mógł w dowolnym
momencie stwierdzić, że features w tej wersji są takie właśnie, jak on
chce i w związku z tym on poprosi o release.

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

Z założenia robisz tak, żeby każdą iterację mieć przetestowaną na
koniec tej iteracji. Jeśli masz przetestowaną i nie ma bugów, to
jesteś "ready to release". Tutaj rozważam wyjątkową sytuację, kiedy
nie możesz zapuścić swojej suity testów na weekend i w związku z tym
musisz testować poprzednią iterację pracując nad następną. W takiej
sytuacji jesteś "ready to release" jedną iterację wstecz, o ile
przeszła testy. Jeśli znalazłeś buga i go nie naprawiłeś bądź nie
określiłeś, w której iteracji z przeszłości ten bug nie występuje, to
nie jesteś "ready to release" w ogóle. Ale to sytuacja wyjątkowa.

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

Taki, gdzie m i n są równe jeden. Znaczy: piszesz testy najpierw, więc
jeśli one znajdują jakieś błędy, to znajdą błędy w tej samej iteracji,
w której zostaje zaimplementowana funckjonalność. Jeśli znajdziesz
błąd w ten sposób, lub napisany później test znajdzie błąd, to resztę
iteracji poświęcasz na poprawienie błędu kosztem user stories. Dopóki
go nie poprawisz to nie jesteś ready to release i nie robisz żadnych
kolejnych iteracji.

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

Zazwyczaj tak, o to przecież chodzi.

> A jakosc produktu pozostaje bez zmian...

No właśnie, dochodzą nowe ficzery, a program ciągle równie bezbłędny
co wtedy, kiedy miał postać int main () {}

A jeśli chcesz powiedzieć, że dział QA w Indiach testujący 15 różnych
produktów zapewni lepsze testowanie niż TDD i testerzy siedzący z tobą
w pokoju, to moje doświadczenie wskazuje, że jest dokładnie
przeciwnie.

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

No i co ci przeszkadza ich mieć w zespole agile?

Nie mówiąc już o tym, że raczej powinieneś wymagać od programistów,
żeby się znali na testowaniu.

> I ci specjalisci zajmuja sie tylko przygotowaniem testow i testowaniem (bo na
> programowaniu sie nie znaja tak dobrze jak programisci).

Możesz ich sparować z programistami do pisania testów.

> Co wiecej - musisz im dac czas na przygotowanie testow.

Oczywiście, ale ten czas jest na początku developmentu, zanim
testowane ficzery zostaną zaimplementowane, a nie na końcu.

> Co wiecej - jak juz przygotuja testy, to kazda zmiana wymagan kolosalnie podraza
testowanie (bo
> trzeba zmieniac testy).

Ale dlaczego "kolosalnie"? Przy jakimkolwiek sensownym podejściu (nie
tylko agile) nie jest tak, że dowolna zmiana wymagań powoduje
konieczność zmiany wszystkich (czy nawet znacznej ilości) testów.
Wymaga konieczność zmiany tych testów, które dotyczą danej części
funkcjonalności. Jeśli zmiana w wymaganiach jest drastyczna, to
owszem, może tak być, ale wtedy powstaje pytanie, dlaczego asz
drastyczną zmianę wymagań. Często jest tak, że dzieje się tak z
przyczyn niezależnych i żaden proces cię przed tym nie ochroni - te
wymagania po prostu rzeczywiście się zmieniają. Wada waterfalla jest
taka, że musisz w tym momencie wyrzucić prawie wszystko, co zrobiłeś i
zacząć od nowa: od fazy zbierania wymagań.

> > Działało to bardzo dobrze.
>
> Wekdlug kogo? Zespolu czy zleceniodawcy? :)
> MSPANC

Według mnie, oczywiście.

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

No, na dzień dobry wykonuje ją przez całe swoje dorosłe życie przed
rozpoczęciem projektu (lub odpowiednio dużą jego część) - na tej
zasadzie zostaje wytypowany do tej roboty. Po drugie wykonuje tę pracę
wtedy, kiedy pracując u zleceniodawcy bierze udział w decyzji o tym,
że należy zamówić program który robi to-a-to (albo przynajmniej ma
widoczność tego procesu). W końcu wykonuje tę pracę siedząc z zespołem
- jego praca to nie tylko komunikowanie wymagań, ale także
uzupełnianie swojej wiedzy co do tego, jakie wymagania są: czy to
kontaktując się ze swoim menedżerem, rozmawiając z analitykami, czy
robiąc risercz. Ale oczywiście ta ostatnia faza to wierzchołek góry
lodowej, zaczyna się od tego, że prosisz zleceniodawce o wytypowanie
osoby która się zna na temacie i rozumie co jest potrzebne. Jeśli
zleceniodawca (czy inny stakeholder) tego nie zrobi, to narzekasz tak
długo aż zrobi, albo kończysz współpracę.

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

Nie mamy. Popadasz w absurd. To, że bierzesz do zespołu robiącego CAD
do mostów kogoś, to przez pięć lat studiował inżynierię mostów a potem
przez 10 lat pracował przy projektowaniu mostów, nie znaczy, że masz
analysis phase trwającą 15 lat.

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

Przede wszystkim to nie dyskutujesz ze mną, tylko z chochołem.

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

Nie polega.

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

Ale jeśli zrobisz to wszystko, a analiza nie poprawi się w ogóle albo
poprawi się nieznacznie, to właśnie wywaliłeś milion dolarów i
prawdopodobnie mocno upośledziłeś zdolność swojej organizacji do
produkcji dalszego oprogramowania.

Twoja wiara, że to, co powyżej przyniesie zauważalną poprawę niczym
się nie różni od wiary, że z XP będzie lepiej.

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

Zwykle jest tak, że jak się umówiło i zapłaciło i dostało wersję 1.2,
to można zrezygnować z kupowania dlaszych wersji. Jeśli ktoś się
zgodził dożywotnio kupować wszystkie upgrade'y, to może jeszcze zawsze
się odkuć na tym, że pomoże przelać żonie byłego afrykańskiego
dyktatora 40 milionów dolarów.

> I nie wciskaj mi kitu o "zarabianiu" czy tez "odnoszeniu korzysci" przez
> klienta z niepelnego produktu.

I nie wciskaj mi kitu, że waterfallem da się w skończonym czasie
wyprodukować działający soft.

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

A jeśli klient przychodzi i mówi "potrzebuję produktu X żeby
zarabiać", a wykonawca mówi "zrobię X w 18 miesięcy" a po trzech
latach mówi "nie ma X bo mój analityk popełnił błąd. Na pocieszenie
mogę zapewnić, że już u mnie nie pracuje." - to jak to nazwać?

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

Ale już nikt przecież nie będzie zwracał uwagi na to, co mówisz, bo w
całym środowisku masz reputację półgłówka, który nie potrafi na
swojego przedstawiciela wyasygnować kogoś, kto się zna na tym, co
robisz.

> Przeciez jak np. zleceniodawca to dajmy na to hurtownia win roznych, to
> zatrudnia ona specjalistow od "win roznych", a nie od programowania.

Zatrudnia - mam nadzieję - również specjalistów od prowadzenia
hurtowni win różnych.

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

No ale to jest akurat rzecz o której programiści powinni wiedzieć. To
nie jest przecież tak, że podatność na ataki SQL to specyfika
programów do hurtowni win różnych.

I też nie jest - od razu zaznaczę - tak, że agile czy XP powoduje, że
można prowadzić działalność "produkcja oprogramowania na zamówienie"
która jest w stanie z powodzeniem zrealizować każde zlecenie,
poczynając od wsparcia dla hurtowni win różnych a kończąc na systemie
sterującym rakietą cruise.

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

Ale każdy projekt tak ma: jeśli release jest po 12 miesiącach, to na
tworzenie tego, co stworzono w 11 miesięcy wydano mniej pieniędzy niż
na stworzenie release, w 10 miesięcy wydano jeszcze mniej i tak dalej.
Z tego, że na wersję alfa, która masz powiedzmy po 7 miesiącach,
wydano znacznie mniej pieniędzy, niż ostatecznie zostanie wydane na
wersję release, nie znaczy, że nie wolno tworzyć release przez
rozbudowanie alfy, tylko trzeba koniecznie alfę wyrzucić do kosza i
pisać od nowa.

No, czyba że tak się właśnie robi w waterfall, ale w takim razie się
nie dziwię, że projekty waterfall się nigdy nie kończą.

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

Zrobi się.

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

Nie napisałem. A "taniej zrobić" to nie to samo, co "taniej napisać
kod".

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

Śmiem twierdzić, ze to smutna obrona kaszaniarza, który w każdym
programie dłuższym od "hello world" posadzi trzy bugi.

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

Wiesz co? Nie chce mi się tłumaczyć. Poczytaj sobie jakąś książkę,
albo co.

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

Nie. Zwolennicy agile twierdzą, że lepiej napisać raz a dobrze. Tylko
że analiza i projekt bardzo często ci nie powiedzą, jak jest dobrze,
więc zrobisz analizę, projekt, napiszesz raz, okaże się, że jednak nie
jest dobrze, więc zrobisz następną analizę, następny projekt, następną
implementację, okaże się, że znowu nie jest dobrze, wywalisz
analityków, pół roku będziesz szukał następnych, zrobisz następną
analizę itd.

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

Chyba jak masz skomplikowany design, co jest nieuchronną konsekwencją
robienia projektu przez n miesięcy.

> Albo wybor zlej biblioteki GUI.

Refaktoryzacja oczywiście jest możliwa. Co więcej, w tym momencie
refaktoryzacja będzie polegała na tym, żeby napisać kod tak, żeby w
miarę łatwo można było dokonywac kolejnych podmian GUI.

[...]
> Albo, albo, albo...

Refaktoryzacja na wszystkie te rzeczy jest praktycznie możliwa.

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

Sorki, ale to bzdura.

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

Nie było. Było, że nie jest zawsze drogi. To, że czasem refaktoring
jest drogi jakościowo nie różni się niczym od tego, że czasem analiza
lub projekt są błędne.

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

Bzdura. Refaktoryzacja to nie "wyrzucenie". Prototypu się z reguły nie
wyrzuca, tylko robi z niego lepszy prototyp i tak dalej aż prototyp
będzie na tyle dobry, że będzie można go skierować do produkcji.