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

do góry

Michal Kleczek <k...@g...com> napisał(a):

> Maciej Sobczak wrote:
>
> > On 21 Maj, 15:03, Andrzej Jarzabek <a...@g...com> wrote:
> >> Zgoda! I to nie jest tak, Ĺźe w agile nie ma planowania. Jest planowanie,
> >> i podstawą planowania jest to, że się zbiera osoby z odpowiednim
> >> doświadczeniem w jednym pomieszczeniu.
> >
> > Właśnie nie jestem o tym przekonany. Mam wrażenie, że agile stał się
> > wyjątkowo atrakcyjny właśnie dla młodego pokolenia, przez swoją mniej
> > lub bardziej jawnie wyrażoną obietnicę, że programowanie może być
> > znowu "cool". Każdy chce, żeby było cool, więc im bardziej coś
wygląda
> > cool, tym lepiej. I tak powstają niezliczone odmiany "procesów" agile
> > - szybciej, niż można je uwiarygodnić przez faktyczne doświadczenie.
> >
> > Problem w tym, że jeżeli już masz cały pokój ludzi z dużym
> > doświadczeniem, to właściwie nie ma znaczenia, jaki to będzie proces.
> > I tak to zrobią dobrze
>
> To, ze doswiadczony i dobry zespol zrobi cos "dobrze" to banal.
> Natomiast to, ze "nie ma znaczenia, jaki to proces" to nieprawda, bo proces
> wynika przeciez z doswiadczenia tych ludzi - to nie jest tak, ze oni maja
> przyczepiona nalepke "dobry" i cokolwiek zrobia to bedzie dobre, ale tak,
ze
> robia cos dobrze i stad bierze sie opinia o nich.
> I moja teza jest taka, ze im bardziej doswiadczony
> programista/projektant/inzynier tym bardziej postepuje zgodnie ze schematem:
> 1. Zastanow sie co w ogole jest do zrobienia
> 2. Jak juz wiesz to zastanow sie jak najefektywniej to zrobic
> 3. Jak juz wiesz to zrob
> I nie robi tego, "bo tak trzeba", tylko dlatego ze tak najefektywniej.
>

jesli chodzi o moj wlasny sposob podejscia to jest to z grubsza cos
jak: 'wszystko jedno byle do przodu'

w ramach zdobywania wiedzy ogolnej ciekawie sie roznymi tematami
w programowaniu ale przy praktycznym programowaniu tez moim sposobem
podejscia jest: nauczenie sie mozliwie waskiego minimum systemu przy
pomocy ktorego mozna dobrze zrobic to co chodzi mi po glowie
by zrobic - innym slowy wolalbym gruntownie nauczyc sie jakiejs
bazy a nie skakac po roznych bibliotekach z tygodnia na tydzien

generalne moim pogledem jest 'wszystko jedno'




--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

<f...@g...pl> napisał(a):

> Michal Kleczek <k...@g...com> napisał(a):
>
> > Maciej Sobczak wrote:
> >
> > > On 21 Maj, 15:03, Andrzej Jarzabek <a...@g...com> wrote:
> > >> Zgoda! I to nie jest tak, Ĺźe w agile nie ma planowania. Jest
planowanie,
> > >> i podstawą planowania jest to, że się zbiera osoby z odpowiednim
> > >> doświadczeniem w jednym pomieszczeniu.
> > >
> > > Właśnie nie jestem o tym przekonany. Mam wrażenie, że agile stał
się
> > > wyjątkowo atrakcyjny właśnie dla młodego pokolenia, przez swoją
mniej
> > > lub bardziej jawnie wyrażoną obietnicę, że programowanie może być
> > > znowu "cool". Każdy chce, żeby było cool, więc im bardziej coś
> wygląda
> > > cool, tym lepiej. I tak powstają niezliczone odmiany "procesów" agile
> > > - szybciej, niż można je uwiarygodnić przez faktyczne doświadczenie.
> > >
> > > Problem w tym, że jeżeli już masz cały pokój ludzi z dużym
> > > doświadczeniem, to właściwie nie ma znaczenia, jaki to będzie
proces.
> > > I tak to zrobią dobrze
> >
> > To, ze doswiadczony i dobry zespol zrobi cos "dobrze" to banal.
> > Natomiast to, ze "nie ma znaczenia, jaki to proces" to nieprawda, bo
proces
> > wynika przeciez z doswiadczenia tych ludzi - to nie jest tak, ze oni maja
> > przyczepiona nalepke "dobry" i cokolwiek zrobia to bedzie dobre, ale tak,
> ze
> > robia cos dobrze i stad bierze sie opinia o nich.
> > I moja teza jest taka, ze im bardziej doswiadczony
> > programista/projektant/inzynier tym bardziej postepuje zgodnie ze
schematem:
> > 1. Zastanow sie co w ogole jest do zrobienia
> > 2. Jak juz wiesz to zastanow sie jak najefektywniej to zrobic
> > 3. Jak juz wiesz to zrob
> > I nie robi tego, "bo tak trzeba", tylko dlatego ze tak najefektywniej.
> >
>
> jesli chodzi o moj wlasny sposob podejscia to jest to z grubsza cos
> jak: 'wszystko jedno byle do przodu'
>
> w ramach zdobywania wiedzy ogolnej ciekawie sie roznymi tematami
> w programowaniu ale przy praktycznym programowaniu tez moim sposobem
> podejscia jest: nauczenie sie mozliwie waskiego minimum systemu przy
> pomocy ktorego mozna dobrze zrobic to co chodzi mi po glowie
> by zrobic - innym slowy wolalbym gruntownie nauczyc sie jakiejs
> bazy a nie skakac po roznych bibliotekach z tygodnia na tydzien
>
> generalne moim pogledem jest 'wszystko jedno'
>

oczywiscie nie ma to niemal nic wspolnego z poprzenim tematem
'organizacja pracy zespolu' (na ktorym sie nie znam i ktory mnie
jakos specjalnie nie interesuje bo jak wspomnialem mnie raczej
obchodzi programowanie samo w sobie a nie programowanie na rynku)

- tutaj watek sie jednak rozdzielil na temat czy i jak poszczegolny
grupowicz organizuje sobie robote i czy jest zwolennikiem jakiegos
konkretnego podejscia





--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

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.

do góry

On May 23, 2:31 pm, " " <f...@g...pl> wrote:
>   <f...@g...pl> napisał(a):
>
> > generalne moim pogledem jest 'wszystko jedno'
>
> oczywiscie nie ma to niemal nic wspolnego z poprzenim tematem
> 'organizacja pracy zespolu' (na ktorym sie nie znam i ktory mnie
> jakos specjalnie nie interesuje bo jak wspomnialem mnie raczej
> obchodzi programowanie samo w sobie a nie programowanie na rynku)

Nie przejmuj się, na rynku to ty możesz co najwyżej pietruszkę
sprzedawać.

do góry

Andrzej Jarzabek <a...@g...com> napisał(a):

> On May 23, 2:31=A0pm, " " <f...@g...pl> wrote:
> > =A0 <f...@g...pl> napisa=B3(a):
> >
> > > generalne moim pogledem jest 'wszystko jedno'
> >
> > oczywiscie nie ma to niemal nic wspolnego z poprzenim tematem
> > 'organizacja pracy zespolu' (na ktorym sie nie znam i ktory mnie
> > jakos specjalnie nie interesuje bo jak wspomnialem mnie raczej
> > obchodzi programowanie samo w sobie a nie programowanie na rynku)
>
> Nie przejmuj si=EA, na rynku to ty mo=BFesz co najwy=BFej pietruszk=EA
> sprzedawa=E6.

moglbym ja sprzedac komus kto karmi osly, (to nie jest komplement)


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 23/05/2011 17:24, f...@g...pl wrote:
> Andrzej Jarzabek<a...@g...com> napisał(a):
>
>>> obchodzi programowanie samo w sobie a nie programowanie na rynku)
>>
>> Nie przejmuj si=EA, na rynku to ty mo=BFesz co najwy=BFej pietruszk=EA
>> sprzedawa=E6.
>
> moglbym ja sprzedac komus kto karmi osly, (to nie jest komplement)

Uuuu, widzę, że trafiłem na Mistrza Ciętej Riposty.

do góry

On 23/05/2011 17:06, Andrzej Jarzabek wrote:
>
> Nie przejmuj się, na rynku to ty możesz co najwyżej pietruszkę
> sprzedawać.

Mój poprzedni posting był bardzo niestosowny i chciałbym przeprosić
sprzedawców pietruszki tudzież innych pracowników straganów, za
sugestię, że osobnik podpisujący się wieloma pseudonimami mógłby
wykonywać ich zawód. Z całą pewnością ich ciężka i pożyteczna praca
wymaga wielu talentów i umiejętności, których ów osobnik nie posiada,
np. elementarnych zdolności interpersonalnych.

do góry

Andrzej Jarzabek <a...@g...com> napisał(a):

> On 23/05/2011 17:24, f...@g...pl wrote:
> > Andrzej Jarzabek<a...@g...com> napisał(a):
> >
> >>> obchodzi programowanie samo w sobie a nie programowanie na rynku)
> >>
> >> Nie przejmuj si=EA, na rynku to ty mo=BFesz co najwy=BFej pietruszk=EA
> >> sprzedawa=E6.
> >
> > moglbym ja sprzedac komus kto karmi osly, (to nie jest komplement)
>
> Uuuu, widzę, że trafiłem na Mistrza Ciętej Riposty.
>

(fi donc !)
niejeden padalec zaznal juz ostrza mej szpady


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 23 Maj, 12:53, Andrzej Jarzabek <a...@g...com> wrote:

[Większość wyciąłem, bo w sumie to się chyba zgadzamy, tylko różnie to
nazywamy.]

> Agile mówi mniej więcej tyle, że należy pisać testy, które sprawdzają,
> czy program działa. To, jakie dokładnie te testy mają być i co
> obejmować pozostawia się do decydowania odpowiednim członkom zespołu.
>
> I ja się w tym zgadzam, że _prawie_ zawsze dla każdego większego
> programu, który będzie robiony dłużej niż 2 miesiące przez więcej niż
> 1-2 osoby i ma szanse mieć dodawaną jakąś funkcjonalność, np. w
> postaci kolejnych wersji, _jakieś_ testy automatyczne warto napisać.
> Niezależnie od tego, czy się akurat stosuje agile, czy nie.

No właśnie. Dlatego *jakieś* testy piszę i pomaga mi to w trzymaniu
fasonu przy różnych zmianach. Ale nie nazywam tego "agile", bo robię
to wybiórczo. Podobnie, *czasami* siadam do klawiatury z kimś, bo to
sprzyja weryfikacji i dzieleniu wiedzy, ale nie nazywam tego extreme
programming, bo to też robię wybiórczo. Itd.
Czyli nie róbmy fetyszu z narzędzi.

> Osobiście też nie jestem przekonany, czy pełna widoczność procesu jest
> zawsze dobrym rozwiązaniem, być może jest tak, że czasem słuszniejszym
> podejściem jest "nikt nie chce wiedzieć, jak się robi kiełbasę".

Heh. Pracowałem kiedyś w Poważnym Projekcie (TM), który był widoczny i
otwarty dla zleceniodawcy, ale tak jakoś wygodnie było mieć *dwa*
systemy zgłaszania bugów - klient widział tylko jeden z nich, drugi
był do użytku wewnętrznego. Powiedzmy, że ten proces dbał o zdrowie
klienta, który widział tylko te bugi, które sam se odkrył.
Jak to określiłeś - problem kulturowy.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry