On 22/05/2011 12:47, Maciej Sobczak wrote:
> On 21 Maj, 15:03, Andrzej Jarzabek<a...@g...com> wrote:
>
>>> Nie zapobiegam im ani testami z automata ani ręcznymi.
>>
>> Znaczy, nie robisz żadnych testów,
>
> Czytaj cały post zanim odpiszesz.

Skoro więce robisz testy, to chyba jednak czemuś one zapobiegają. Bo
chyba nie powiesz, że robisz je, bo lubisz poczucie beezpieczeństwa?

> Testy oczywiście są. Ale robię z nich fetyszu i nie stawiam ich w
> centrum procesu.

Ale ustawiasz chochoła, bo w agile/XP testowanie obejmuje niewielką
część praktyk. Akurat pisałem o tym, bo padła teza, że XP z konieczności
będzie wypuszczać źle przetestowane oprogramowanie, bo nie da się
testować w takim cyklu.

>> Nie tylko unit testy można odpalać z automata. Można automatycznie
>> testować całe systemy, nawet GUI.
>
> Nie, nie można.
> Tzn. nie twierdzę, że nie ma na świecie rozwiązań, które to obiecują
> (więc nie pokazuj mi linków do tych rozwiązań :-p ).
> Twierdzę tylko, że nie można.

Można. Wiem, bo akurat moja praca ma z tym związek i blisko współpracuję
z ludźmi, którzy to właśnie robią.

>>> Wybij sobie z głowy taki pomysł, że jakakolwiek (pseudo)metodologia
>>> pozwoli niedoświadczonym ludziom robić dobre projekty.
>>
>> Oczywiście! Stąd moje zastrzeżenie do waterfall, że te wszystkie
>> metodologie analizowania i projektowania to i tak machanie rękami wokół
>> tego, że szacunki opierają się na doświadczeniu osoby z odpowiednim
>> doświadczeniem.
>
> Ostatecznie tak to wygląda.

No i całe agile właśnie na tym polega, żeby przestać machać rękami,
oprzeć się na doświadczeniu i zabrać się do roboty.

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

Prawdę mówiąc uważam, że jest to kompletnie nieistotne z punktu widzenia
tego, czy te praktyki są dobre, czy nie. Oczywiście z punktu widzenia
klienta może to tak wyglądać, że jak ktoś mówi, że praktykuje
agile/XP/Scrum, to trzeba uważać i się dokładnie przyjrzeć temu, co tam
się właściwie praktykuje. Pewną zaletą agile jest założenie kompletnej
widoczności procesu dla stakeholderów. Tak więc jeśli nie ma tej
widoczności, to od razu masz sygnał, że coś z tym agile jest nie tak.

W przypadku projektów zlecanych zewnętrznie, ta widoczność powinna miec
postać "nasz człowiek siedzi z waszym zespołem i uczestniczy w zebraniach".

> I tak powstają niezliczone odmiany "procesów" agile
> - szybciej, niż można je uwiarygodnić przez faktyczne doświadczenie.

Shore&Warden na przykład powstało przez kumulację faktycznego
doświadczenia w wielu implementacjach XP.

do góry

On 22/05/2011 12:47, Maciej Sobczak wrote:
> On 21 Maj, 15:03, Andrzej Jarzabek<a...@g...com> wrote:
>

> 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 i to jest właśnie ten nieuchwytny czynnik
> ludzki.

Nie zgodzę się, proces ma też znaczenie. No i przede wszystkim od
procesu może zależeć, czy ci ludzie w ogóle znajdą się w jednym pokoju.

>> Ach, widzisz, tylko tak się składa, że istnieje taka szkoła
>> projektowania jak "simple design"/"incremental design", która mówi, że
> [...]
>> Robienie w tym momencie większego projektu uważam za błąd.
>
> A kto mówi, że on ma być większy? On ma być wystarczający. W
> szczególności brak projektu nie jest wystarczający.

W szczególności może być tak, że wystarczyć może zastanowienie się przez
chwilę przed rozpoczęciem pisania. Czy koncepcja w głowie programisty
powstała przez zastanawianie się przez 15 minut nazwiesz "projektem" czy
nie,to kwestia semantyki. Na pewno taki "projekt" nie jest sprzeczny z
agile.

> Dla przykładu, mój ostatni projekt na papierze nie zawierał formalnych
> diagramów. Były ze dwa (!) obrazki w stylu prezentacji power pointa,
> ale ani kawałka UMLa ani niczego podobnego. Był za to *dokładniejszy*
> opis protokołu oraz interakcji w skali makro, była też bardziej
> dokładna analiza konsekwencji różnych fakapów, bo projekt
> dotyczył systemu krytycznego. Całość była napisana tak, żeby inny
> senior, niezwiązany z projektem ale poproszony o ocenę, powiedział, że
> się przekonał.

Ale też nikt nie mówi, że nie należy takich projektów robić na
"papierze" (czy to by oznaczało dokument w wordzie z diagramem w visio
czy rysunek na flip chart'ie.

> Ja wcale nie sugeruję tutaj żadnego RUPa czy czegoś w tym stylu.

No popatrz, a są tacy, którzy nawet proponują pełnego waterfalla.

> Twierdzę natomiast, że wystartowanie od razu z wersją demo jest słabe
> i zwiększa ryzyko, że na wersji demo się skończy. Twierdzę też, że TDD
> jest słabe, bo rzeczy naprawdę ważnych nie potrafi uchwycić.

1. TDD to nie tylko unit testy.
2. Automatyczne (i inne) testy potrafią wychwicić naprawdę ważne rzeczy.
Nie wszystkie ważne rzeczy, ale przynajmniej niektóre ważne rzeczy.
Jeśli tobie się nie zdarzyło, to możesz mi uwierzyc na słowo.
3. Agile/XP to nie tylko TDD.
4. Czasem lepiej skończyć na wersji demo niż po kilku miesiącach
usłyszeć, że to nie jest to, o co chodziło.

do góry

>> Zbyt wielu.
>>
>> KK
>
> Zbyt wielu - NIEKOMPETENTNYCH
>
> Kompetentnych - zbyt malo.
>
> Dlatego mimo pol tuzina owtartch pozycji i chyba z 50 interviews
> pozycje sa ciagle nieobsadzone
>
> A.L.

Chyba cos tu nie gra.
Programista to atraktyjna praca ale
byc moze czesto niewystarczajaco atraktyjna
dla tych co sie do niej nadaja?

> My nei potzrebujemy malp od testow. Potzrebujemy specjalisotw. jak by
> nie bylo w Ameryce glupio, to jescze nei syszalem zeby kogos
> przyjmowali na podstawie testow. Moze w zlych miejscach bylem.

> facio ma umiec rozwiazywac problemy a nie miec wkuta skladnie C++ czy
> czegos tam

Mysle ze skoro firma ma problemy ze znalezieniem
specjalistow to powinna zainwestowac w ludzi
ktorzy sie do tego potencjalnie nadaja.
Zainwestowac czyli pozwolic im na rozwoj zawodowy
w takim stopniu w jakm maja wyc wyspecjalozowani.
Przeciez to takie proste.
Jednak firm praktycznie nie chce inwestowac w ludzi
mimo ze mialo by to sens.

Jednak tak to juz bywa ze zbyt wiele osob na stanowiskach managerskich
ma znacznie lepsze samopoczucie aby twierdzic ze wszyscy pozostali to
idioci niz ruszyc glowa od czasu do czasu.
Glupota a moze egoizm.

do góry

On 22 Maj, 14:39, Andrzej Jarzabek <a...@g...com> wrote:

> Skoro więce robisz testy, to chyba jednak czemuś one zapobiegają. Bo
> chyba nie powiesz, że robisz je, bo lubisz poczucie beezpieczeństwa?

Robię je tam, gdzie (jak sądzę) ich użyteczność jest większa, niż ich
koszt. To oznacza, że czasami ich nie robię a w szczególności czasami
od nich nie zaczynam. Czyli traktuję testy tak, jak młotek i każde
inne *narzędzie*, któro czasem jest odpowiednie a czasem nie.
I dlatego nie mam zaufania do żadnej metody, która stawia testowanie
(albo jakiekolwiek inne narzędzie) w centrum uwagi albo je wręcz
wymusza.

Dwa skrajne przykłady z działki, którą zajmowałem się ostatnio
najwięcej (systemy rozproszone):

1. Jak piszę serializator, to używam TDD, bo serializator jest na to
idealnym miejscem. Zaczynam od protokołu i danych testowych, od
najprostszych do bardziej wyuzdanych i najpierw piszę test a potem
odpowiedni kod serializatora, z drobnymi iteracjami. Np. gdybym miał
pisać funkcję do kowersji ASCII->Morse, to też bym tak zrobił (osobne
iteracje na każdą literkę), bo to ma wtedy sens.

2. Jak mam wymaganie, że w układzie publish-subscribe jitter u każdego
odbiorcy ma być niezależny od awarii (zawieszenia, zgon, itp.) innych
odbiorców, to *nie* używam TDD ani w ogóle nie robię na to żadnego
testu. Tego typu wymagania można sensownie spełnić nie przez jakąś tam
refaktoryzację, tylko przez odpowiednią *konstrukcję*, czyli to ma
najpierw zadziałać na papierze. Automatycznego testu nie ma sensu
robić, bo jest to zbyt kosztowne (albo w praktyce w ogóle niemożliwe)
w stosunku do efektu. Takie rzeczy testuję przy użyciu paczki czipsów,
czyli robię testowy system, który wizualizuje mi się na ekranie, kładę
nogi na stole i przy ostatnim czipsie wiem, czy działa poprawnie.
Prawie zawsze działa, bo prawie zawsze mam dobrą konstrukcję, która
wynika z dobrego projektu na papierze.
Inne wymaganie, któro traktuję podobnie, to np. "ruch komunikatów ma
być płynny". Itd.
Jak ktoś chce pisać na to testy (albo nawet TDD), to będę za niego
trzymał kciuki.
Jeśli jakaś metodologia zmuszałaby mnie do robienia automatycznych
testów do tego typu wymagań, to ta metodologia jest do dupy. A
ponieważ właśnie takie wymagania są najciekawsze i z takimi mam
najwięcej do czynienia, to agile/xp/łotewer byłby dla mnie jedynie
obciążeniem. Oops - a podobno miał być wybawieniem od poprzednich
obciążających metodologii. There is no silver bullet.

> >> Nie tylko unit testy można odpalać z automata. Można automatycznie
> >> testować całe systemy, nawet GUI.
>
> > Nie, nie można.
>
> Można. Wiem, bo akurat moja praca ma z tym związek i blisko współpracuję
> z ludźmi, którzy to właśnie robią.

Etam. Dla mnie wymagania na GUI to np.:

1. w aplikacji do obsługi kont emerytalnych GUI ma być *przyjazne dla
starszych osób*

2. w aplikacji typu sklep GUI ma *umacniać postrzeganie marki i
sprzyjać tzw. konwersji*, czyli kierować odwiedzającego w stronę
zakupów

Jeżeli pod pojęciem testowania GUI rozumiesz sprawdzenie, czy
naciśnięcie przycisku wywołuje podpiętą do niego funkcję, to mówimy o
różnych rzeczach. Ja mówię o tym, że nie da się automatycznie testować
GUI; przypuszczam, że być może da się testować *display*, ale mały z
tego pożytek.

> W przypadku projektów zlecanych zewnętrznie, ta widoczność powinna miec
> postać "nasz człowiek siedzi z waszym zespołem i uczestniczy w zebraniach".

"Nasz człowiek nie ma czasu i w ogóle to wyjeżdża/awansował/łotewer.
Przyślijcie jak skończycie."

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

do góry

On 22/05/2011 23:19, Maciej Sobczak wrote:
> On 22 Maj, 14:39, Andrzej Jarzabek<a...@g...com> wrote:
>
>> Skoro więce robisz testy, to chyba jednak czemuś one zapobiegają. Bo
>> chyba nie powiesz, że robisz je, bo lubisz poczucie beezpieczeństwa?
>
> Robię je tam, gdzie (jak sądzę) ich użyteczność jest większa, niż ich
> koszt. To oznacza, że czasami ich nie robię a w szczególności czasami
> od nich nie zaczynam. Czyli traktuję testy tak, jak młotek i każde
> inne *narzędzie*, któro czasem jest odpowiednie a czasem nie.
> I dlatego nie mam zaufania do żadnej metody, która stawia testowanie
> (albo jakiekolwiek inne narzędzie) w centrum uwagi albo je wręcz
> wymusza.

A ja się jeszcze nigdy nie spotkałem przy żadnym większym produkcie
kompercyjnym żeby nie było procesu wymuszającego testy.

> najpierw zadziałać na papierze. Automatycznego testu nie ma sensu
> robić, bo jest to zbyt kosztowne (albo w praktyce w ogóle niemożliwe)
> w stosunku do efektu. Takie rzeczy testuję przy użyciu paczki czipsów,
> czyli robię testowy system, który wizualizuje mi się na ekranie, kładę
> nogi na stole i przy ostatnim czipsie wiem, czy działa poprawnie.

A możesz wyjaśnić, dlaczego tych danych, które wizualizujesz nie da się
przetestować automatycznie? To, o czym pisałeś nie da się powiązać z
jakąś mierzalną np. statystyczną właściwością danych?

> Jeśli jakaś metodologia zmuszałaby mnie do robienia automatycznych
> testów do tego typu wymagań, to ta metodologia jest do dupy. A
> ponieważ właśnie takie wymagania są najciekawsze i z takimi mam
> najwięcej do czynienia, to agile/xp/łotewer byłby dla mnie jedynie
> obciążeniem. Oops - a podobno miał być wybawieniem od poprzednich
> obciążających metodologii. There is no silver bullet.

Być może nie jest dostosowana do tego, co robisz. XP na przykład jest
pomyślane pod kątem programu, który ewoluuje, czy to dlatego, że
wymagania zmieniają się w trakcie developmentu, czy dlatego, że robi się
kolejne wersje z nową funkcjonalnością. Dodatkowo obejmuje programy
tworzone w wieloosobowych zespołach. TDD jest m. in. po to, żeby dlasze
modyfikacjee nie spowodowały regresji względem tych wymagań.

>> Można. Wiem, bo akurat moja praca ma z tym związek i blisko współpracuję
>> z ludźmi, którzy to właśnie robią.
>
> Etam. Dla mnie wymagania na GUI to np.:
>
> 1. w aplikacji do obsługi kont emerytalnych GUI ma być *przyjazne dla
> starszych osób*
[...]

Jeśli GUI robi coś innego, niż założyłeeś, że ma robić, to raczej nie
będzie przyjazne dla kogokolwiek.

Od tego, żeby "modelowe" GUI (z którym zgodność GUI rzeczywistego
sprawdzają testy) było takie jak trzeba to masz inne praktyki.

> Jeżeli pod pojęciem testowania GUI rozumiesz sprawdzenie, czy
> naciśnięcie przycisku wywołuje podpiętą do niego funkcję, to mówimy o
> różnych rzeczach. Ja mówię o tym, że nie da się automatycznie testować
> GUI; przypuszczam, że być może da się testować *display*, ale mały z
> tego pożytek.

Tak, automatyczne testowanie GUI to sprawdzanie czy naciśnięcie
przycisku powoduje pokazanie się odpowiedniego okienka, czy w gridzie są
odpowiednie dane itd. Pożytek z tego jest duży.

"Display" to monitor do komputera. Pewnie je jakoś testują w fabryce,
może i nawet automatycznie, ale przyznam się, że na tym się kompletnie
nie znam.

>> W przypadku projektów zlecanych zewnętrznie, ta widoczność powinna miec
>> postać "nasz człowiek siedzi z waszym zespołem i uczestniczy w zebraniach".
>
> "Nasz człowiek nie ma czasu i w ogóle to wyjeżdża/awansował/łotewer.
> Przyślijcie jak skończycie."

Jeśli robisz na zamówienie zewnętrznego klienta, to domyślnie wymagasz
obecności tego człowieka i wpisujesz to do umowy. Jeśli nie da się
wpisać do umowy, to nie stosujesz agile (a przynajmniej XP).

Alternatywa jest taka, że klient ufa, że twoi specjaliści rozpoznają
jego potrzeby biznesowe i że ty będziesz te potrzeby implementował tak,
żeby zmaksymalizować wartość programu dla niego, i to zaufanie też ma
odzwierciedlenie w umowie.

do góry

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.

--
Michal

do góry

On 23 Maj, 08:43, Michal Kleczek <k...@g...com> wrote:

> To, ze doswiadczony i dobry zespol zrobi cos "dobrze" to banal.

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

Tak, to dobre podsumowanie. Oczywiście rozpędziłem się ze
stwierdzeniem, że nie ma znaczenia jaki to proces (sam bym sobie
zaprzeczył, skoro jestem sceptykiem wobec jednego z nich).

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

do góry

On 23 Maj, 08:01, Andrzej Jarzabek <a...@g...com> wrote:

> A ja się jeszcze nigdy nie spotkałem przy żadnym większym produkcie
> kompercyjnym żeby nie było procesu wymuszającego testy.

Ależ proces może sobie wymuszać. I testy są. Za wyjątkiem miejsc,
gdzie ich nie ma i wszyscy te miejsca omijają milczeniem, bo ani
zleceniodawca ani wykonawca nie wie, jak się zabrać za ich testowanie.
Jak w przykładowym "ruch komunikatów ma być płynny".
Właśnie dlatego odbiór projektu wcale nie polega na uruchomieniu
testów "z automata".
Skoro widziałeś większe produkty komercyjne, to przypomnij sobie, jak
wyglądał ich odbiór. Dry-runs, "wygrzewanie", mniej lub bardziej
ochotniczy beta-testerzy, itd. I na koniec jeszcze okres gwarancyjny.
Te wszystkie rzeczy istnieją i są praktykowane właśnie dlatego, że
testy z automata to pikuś, nawet jeśli masz 100% pokrycia.

Nikt nie kupuje samochodu na podstawie kwitu z automatycznej stacji
diagnostycznej.

> > Automatycznego testu nie ma sensu
> > robić, bo jest to zbyt kosztowne (albo w praktyce w ogóle niemożliwe)
> > w stosunku do efektu. Takie rzeczy testuję przy użyciu paczki czipsów,
> > czyli robię testowy system, który wizualizuje mi się na ekranie, kładę
> > nogi na stole i przy ostatnim czipsie wiem, czy działa poprawnie.
>
> A możesz wyjaśnić, dlaczego tych danych, które wizualizujesz nie da się
> przetestować automatycznie? To, o czym pisałeś nie da się powiązać z
> jakąś mierzalną np. statystyczną właściwością danych?

Oczywiście, że się da. Z wieloma mierzalnymi miarami, zwłaszcza z ROI
(Return On Investment). Ta miara mówi, że nie ma sensu tego robić,
nawet jeśli teoretycznie jest to możliwe. Dlatego nie robię i nie dam
sobie tego wcisnąć "bo agile tak mówi" (a "Słowacki wielkim poetą
był").

Inne przykłady:

1. Jakiś czas temu jeden z naszych grupowych kolegów (Sebastian Biały?
bardzo przepraszam, jeśli nie pamiętam dokładnie) pokazywał efekty
swojego programu do wyostrzania zdjęć. Wyniki są fantastyczne.
Obstawiam, że nie robił tego przez TDD. Nie interesuje mnie, czy
jakość tych algorytmów da się powiązać z czymkolwiek mierzalnym, bo
*to nie ma sensu*. Miarą jakości jest tutaj opad szczęki a nie test "z
automata".

2. Algorytm pogłosowy dla muzyków. Albo automatyczny aranżer w stylu
wczesny japoński jazz alternatywny. TDD? Bez jaj.

Takich przykładów oczywiście jest więcej. A ponieważ informatyka służy
do poprawiania nam życia, to takich wymagania są praktycznie w każdym
systemie, może poza projektami studenckimi typu "napisać AVL".
Oczywiście te wszystkie systemy w skali mikro składają się z
drobiazgów, które da się pojedynczo objąć przez TDD, ale to jest skala
mikro i żabia perspektywa. Dla takich wymagań ostatecznym arbitrem od
strony konsumenta nie są testy z automata, tylko jazda próbna, albo
paczka czipsów.

Są też projekty, które można i warto jak najpełniej formalizować
(najczęściej ogólnie rozumiane sterowanie procesami fizycznymi) - tam
nie ma miejsca na elementy psychologiczne w ocenie jakości a działanie
systemu da się dobrze opisać matematycznie. Ale uwaga, bo to jest
ciekawe: właśnie w takich projektach waterfall sprawdza się bardzo
dobrze.

Paru gości usiłuje pogodzić nurt agile z realiami systemów krytycznych
(które zwykle dotyczą sterowania), dobre hasło to "Continuous
Certification":

http://www.open-do.org/

ale z tego co wiem, to bardzo opornie im to idzie.

[...]

> Tak, automatyczne testowanie GUI to sprawdzanie czy naciśnięcie
> przycisku powoduje pokazanie się odpowiedniego okienka, czy w gridzie są
> odpowiednie dane itd. Pożytek z tego jest duży.

A taki np. mBank nie potrafi nawet zaakceptować wartości, którą sam
wyświetla (np. jeśli na koncie jest "1 234,56", to nie można tego
przelać przez copy-paste).
Może robią automatycznie testy tego "GUI". A może nie robią. Nie ma to
znaczenia, bo testy tego typu mają złą granulację.

(to tylko przykład tego, że testy GUI nie działają na odpowiednim
poziomie)

> "Display" to monitor do komputera.

"Display" w tym sensie, w jakim to użyłem, to ogół środków
technicznych służących do wyświetlenia czegoś. JButton należy do tej
grupy.

> Alternatywa jest taka, że klient ufa, że twoi specjaliści rozpoznają
> jego potrzeby biznesowe i że ty będziesz te potrzeby implementował tak,
> żeby zmaksymalizować wartość programu dla niego, i to zaufanie też ma
> odzwierciedlenie w umowie.

No właśnie. Nie mówmy "robimy agile, więc będzie dobrze". Mówmy
"potrafimy rozpoznać Twoje potrzeby, więc będzie dobrze". Jedno i
drugie to prymitywny marketing, ale przynajmniej w tym drugim
przypadku stajemy się odpowiedzialnymi właścicielami końcowego efektu/
klęski i nie zwalamy tego na jakiś proces.

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

do góry

W dniu 2011-05-23 00:19, Maciej Sobczak pisze:
> On 22 Maj, 14:39, Andrzej Jarzabek<a...@g...com> wrote:
>
>> Skoro więce robisz testy, to chyba jednak czemuś one zapobiegają. Bo
>> chyba nie powiesz, że robisz je, bo lubisz poczucie beezpieczeństwa?
>
> Robię je tam, gdzie (jak sądzę) ich użyteczność jest większa, niż ich
> koszt. To oznacza, że czasami ich nie robię a w szczególności czasami
> od nich nie zaczynam. Czyli traktuję testy tak, jak młotek i każde
> inne *narzędzie*, któro czasem jest odpowiednie a czasem nie.
> I dlatego nie mam zaufania do żadnej metody, która stawia testowanie
> (albo jakiekolwiek inne narzędzie) w centrum uwagi albo je wręcz
> wymusza.
>

Cieszę się że niewątpliwie dobry zajmuje takie stanowisko, uwazam je za
realistyczne.

Do serii przykładów wrzucę algorytm z wyceny środków trwałych, zależnie
od zbieżności dat było niemożliwe odwiedzić wszystkie odnogi algorytmu.
Kompetentne zaprojektowanie zestawu danych, który by to sprowokował,
wymagało by geniusza programistyczno-księgowego i kupe jego czasu, a nie
konserwujące go juniora programisty jakim wtedy byłem.
Akurat rzecz była w języku w praktyce interpretowanym choć pozornie
kompilowanym (Clipper)

Algorytm oczywiście miał poprawki, wydawało się wersję, testowało
"życie" czyli klient. Szybko wypadł z oferowanych systemów, na mocno
średni projekt nie dało mu się nabudować jakości.

do góry

On May 23, 8:55 am, Maciej Sobczak <s...@g...com> wrote:
> On 23 Maj, 08:01, Andrzej Jarzabek <a...@g...com> wrote:
>
> Właśnie dlatego odbiór projektu wcale nie polega na uruchomieniu
> testów "z automata".

Ale też nikt nie mówi, że tak musi być. "Ready to release" nie
oznacza, że klient może sobie wziąć dowolne demo iteracji i używać
jako wersji release. W skrócie chodzi o to, żeby mógł po każdym demo
powiedzieć "robimy z tego release" i nie usłyszeć "ale ten ficzer w
demo nie jest dokończony i nie nadaje się do releasowania,
potrzebujemy jeszcze x tygodni na development." "Ready to release"
oznacza tyle, że po każdej iteracji, jeśli sobie klient tego zażyczy,
możesz uruchomić procedurę "release" z twoim demem jako "release
candidate". Ta procedura, w zależności od potrzeb, może obejmować
jakiś user acceptance testing i trwać tyle, ile koniecznie potrzeba,
żeby trwała i nie dłużej.

Z drugiej strony proces powinien (i różne metodologie agile tego też
wymagają) minimalizować szanse, że release się nie powiedzie. Do tego
służą praktyki mające na celu redukcję ilości bugów, ale do tego też
służy TDD.

> Skoro widziałeś większe produkty komercyjne, to przypomnij sobie, jak
> wyglądał ich odbiór. Dry-runs, "wygrzewanie", mniej lub bardziej
> ochotniczy beta-testerzy, itd. I na koniec jeszcze okres gwarancyjny.
> Te wszystkie rzeczy istnieją i są praktykowane właśnie dlatego, że
> testy z automata to pikuś, nawet jeśli masz 100% pokrycia.

Nie dlatego, że "pikuś", tylko dlatego, że pewnych rzeczy jednak nie
testują. Co do tego się przecież zgadzamy.

Co do gwarancji, to jest to jakby temat kompletnie ortogonalny do
Agile.

> Nikt nie kupuje samochodu na podstawie kwitu z automatycznej stacji
> diagnostycznej.

Stwierdzam, że nie będę dalej dyskutował z metaforami motoryzacyjnymi.

> > A możesz wyjaśnić, dlaczego tych danych, które wizualizujesz nie da się
> > przetestować automatycznie? To, o czym pisałeś nie da się powiązać z
> > jakąś mierzalną np. statystyczną właściwością danych?
>
> Oczywiście, że się da. Z wieloma mierzalnymi miarami, zwłaszcza z ROI
> (Return On Investment). Ta miara mówi, że nie ma sensu tego robić,
> nawet jeśli teoretycznie jest to możliwe. Dlatego nie robię i nie dam
> sobie tego wcisnąć "bo agile tak mówi" (a "Słowacki wielkim poetą
> był").

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.

> Inne przykłady:
>
> 1. Jakiś czas temu jeden z naszych grupowych kolegów (Sebastian Biały?
> bardzo przepraszam, jeśli nie pamiętam dokładnie) pokazywał efekty
> swojego programu do wyostrzania zdjęć. Wyniki są fantastyczne.
> Obstawiam, że nie robił tego przez TDD. Nie interesuje mnie, czy
> jakość tych algorytmów da się powiązać z czymkolwiek mierzalnym, bo
> *to nie ma sensu*. Miarą jakości jest tutaj opad szczęki a nie test "z
> automata".
>
> 2. Algorytm pogłosowy dla muzyków. Albo automatyczny aranżer w stylu
> wczesny japoński jazz alternatywny. TDD? Bez jaj.

Ale jeśli taki program ma być stosowany w środowisku produkcyjnym, to
oprócz powodowania opadu szczęki powinien zwykle posiadać odpowiednią
stabilność i niezawodność i do tego właśnie służy TDD. Jeśli wiesz
(dla jakiegoś tam poziomu pewności 'wiesz') że twój program poprawnie
liczy macierze, że się nie wywala po kliknięciu w buttona, że dla
wszystkich kombinacji ustawień generuje poprawny plik JPEG, to możesz
mniej uwagi poświęcić sprawdzianiu takich pierdół, a więcej na
testowanie opadu szczęki.

> Takich przykładów oczywiście jest więcej. A ponieważ informatyka służy
> do poprawiania nam życia, to takich wymagania są praktycznie w każdym
> systemie, może poza projektami studenckimi typu "napisać AVL".
> Oczywiście te wszystkie systemy w skali mikro składają się z
> drobiazgów, które da się pojedynczo objąć przez TDD, ale to jest skala
> mikro i żabia perspektywa. Dla takich wymagań ostatecznym arbitrem od
> strony konsumenta nie są testy z automata, tylko jazda próbna, albo
> paczka czipsów.

Ale są to też rzeczy, które mają mniejszą szansę pierdyknięcia z
tygodnia na tydzień, mimo że wcześniej przez ileś-tam tygodni działały
prawidłowo.

Poza tym w samej naturze takich problemów często leży to, że istnieją
kombinacje ustawień, dla których kopara nie opada. Np. jeśli weźmiesz
dowolny program z funkcją wyostrzania zdjęć przy pomocy "unsharp
mask", to tam masz dwa albo trzy suwaki i dla niektórych ustawień tych
suwaków efekt zdecydowanie nie jest przyjemny. Ale it's not a bug,
it's a feature. Natomiast gdyby dla nirktórych ustawień suwaków
program się wywalał, to byłby bug.

> Są też projekty, które można i warto jak najpełniej formalizować
> (najczęściej ogólnie rozumiane sterowanie procesami fizycznymi) - tam
> nie ma miejsca na elementy psychologiczne w ocenie jakości a działanie
> systemu da się dobrze opisać matematycznie. Ale uwaga, bo to jest
> ciekawe: właśnie w takich projektach waterfall sprawdza się bardzo
> dobrze.

A czasami (często) jest tak, że jesteś gdzieś pomiędzy. Na przykłąd że
wiadomo, że wartość pozycji liczy się w określony sposób, ale zawsze
jest możliwość, że będzie trzeba dodać dodatkowe pole, albo trzeba
będzie obsłużyć nowy rodzaj transakcji itd.

> Paru gości usiłuje pogodzić nurt agile z realiami systemów krytycznych
> (które zwykle dotyczą sterowania), dobre hasło to "Continuous
> Certification":
>
> http://www.open-do.org/
>
> ale z tego co wiem, to bardzo opornie im to idzie.

Dzięki za linka, ale na tej dziedzinie nie znam się kompletnie i nie
mam nic do powiedzenia.

> > Tak, automatyczne testowanie GUI to sprawdzanie czy naciśnięcie
> > przycisku powoduje pokazanie się odpowiedniego okienka, czy w gridzie są
> > odpowiednie dane itd. Pożytek z tego jest duży.
>
> A taki np. mBank nie potrafi nawet zaakceptować wartości, którą sam
> wyświetla (np. jeśli na koncie jest "1 234,56", to nie można tego
> przelać przez copy-paste).
> Może robią automatycznie testy tego "GUI". A może nie robią. Nie ma to
> znaczenia, bo testy tego typu mają złą granulację.

Jeśli wiesz, że masz taki problem, to napisanie testu GUI który to
sprawdzi nie powinno być problematyczne (zakładając że już masz
jakikolwiek sensowny framework do testowania GUI). Do odkrycia, że
masz w ogóle taki problem to służą inne praktyki (w tym wypadku
zapewne exploratory testing).

> > "Display" to monitor do komputera.
>
> "Display" w tym sensie, w jakim to użyłem, to ogół środków
> technicznych służących do wyświetlenia czegoś. JButton należy do tej
> grupy.

Ja użyłem GUI w sensie komponentu, który zawiera te wszystkie buttony
i oprogramowanie reakcji na operacje użytkownika. I tak, chodziło mi o
testy czy jak klikniesz tego czekboksa to się pojawią takie suwaki, a
jak wciśniesz ten przycisk, to wyskoczy taki dialog. I nie, to nie są
niepotrzebne testy, bo brak odpowiedniego zachowania dyskwalifikuje
program do release, natomiast prawdopdobieństwo takich bugów w
większym i dłużej trwającym projekcie jest zdecydowanie nie-
epsilonowe. W dodatku dokładne ręczne przetestowanie rozbudowanego GUI
zajęłoby wieki, więc się testowanie części opcji "pomija milczeniem" -
co się prędzej czy później kończy wypuszczeniem buga do produkcji.

> > Alternatywa jest taka, że klient ufa, że twoi specjaliści rozpoznają
> > jego potrzeby biznesowe i że ty będziesz te potrzeby implementował tak,
> > żeby zmaksymalizować wartość programu dla niego, i to zaufanie też ma
> > odzwierciedlenie w umowie.
>
> No właśnie. Nie mówmy "robimy agile, więc będzie dobrze". Mówmy
> "potrafimy rozpoznać Twoje potrzeby, więc będzie dobrze". Jedno i
> drugie to prymitywny marketing, ale przynajmniej w tym drugim
> przypadku stajemy się odpowiedzialnymi właścicielami końcowego efektu/
> klęski i nie zwalamy tego na jakiś proces.

Jak już pisałem, aspekt marketingowy mnie nie interesuje. Interesuje
mnie, czy te praktyki są dobre.

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ę".
Wydaje mi się, że decydują o tym skomplikowane czynniki kulturowe,
jednego klienta widocznośc uspokoi, inny powie, że oczywiście chce
mieć widoczność, ale jak ją będzie miał, to tylko będzie nerwowy i
będzie przeszkadzał w realizacji celu. I dlatego też wydaje mi się, że
jak się wchodzi w wariant z widocznością, to dobrze klientowi
wytłumaczyć, co się właściwie zamierza stosować. I oczywiście będziesz
miał klientów, których szczegóły nie będą interesować, ale zapytają,
czy ktoś już gdzieś z powodzeniem to zastosował. I tu właśnie wchodzi
aspekt marketingowy "stosujemy popularny proces sixsigma/CMMI/XP/Scrum/
Lean/RUP/wujwijeszczeco", w przypadku niektórych klientów jest to
potrzebne do stworzenia zaufania na początku. Tylko że niezależnie od
tego, uważam, że jak masz proces kijowy, to zaufanie się prędzej czy
później posypie (a raczej prędzej), natomiast jeśli chodzi o taktyki
celowego robienia klienta w bambuko, to mnie one również nie
interesują.

do góry