On Dec 19, 1:47 pm, Maciej Sobczak <s...@g...com> wrote:
> On Dec 19, 1:33 pm, Andrzej Jarzabek <a...@g...com>
> wrote:
>
> > > Ale musiałoby ich być dokładnie tyle, ile byłoby tej dokumentacji,
> > > której ma nie być.
>
> > Dokładnie.
>
> Nie tylko. Tych notatek z dyskusji też musi być dokładnie tyle samo
> (bo informacji nie da się zredukować). I tego właśnie nie rozumiem.

Jak byłem na studiach zawsze byli tacy ludzie, którzy na wykładach
notowali pełnymi zdaniami wszystko, co mówił profesor. Ich notatki
były bardzo przydatne na kolokwiach czy egzaminach, które odbywały się
kilka tygodni czy miesięcy po samym wykładzie, i cały rok miał je
skserowane.

Na ogół ludzie, jeśli przychodzą do kogoś z konkretnym problemem,
który trzeba wytłumaczyć, jeśli ten problem jest odpowiednio mały,
tłumaczenie trwa może z 10 minut (jak nie mniej), a wiedzę uzyskaną w
ten sposób zapisuje się w postaci sformalizowanej lub stosuje w
praktyce zaczynając bezpośrednio po samym tłumaczeniu i w ciągu
najwyżej kilku godzin, potrafią zapamiętać z owego tłumaczenia na
tyle, że notowanie dosłownie wszystkiego, co było powiedziane, nie
jest konieczne. Ja na przykład mam przed sobą teraz wynotowane rzeczy,
które mam w kolejce do zrobienia, w taki sposób, że dla osoby, która
nie wie o co chodzi, byłyby kompletnie niezrozumiałe. A dla mnie są
zrozumiałe, bo w ogóle poza tym wiem, co robię. Jeśli komuś co pół
godziny resetuje się kontekst i bez notatek nie wie, czy akurat robi
oprogramowanie do robota przemysłowego, czy do serwisu plotkarskiego
na WWW, to zapewne powinien nie pisać, programów, tylko natychmiast
zapisać sobie na ręce, żeby pójść na badania do neurologa.

> Tradycyjna metoda polega na tym, że się pisze dokumentację, w której
> zawarta jest wiedza nt. działania systemu. W agile piszemy notatki,
> których jest *tyle samo* (nieredukowalność informacji, sorry, nie ja
> stworzyłem świat). A przynajmniej w całej tej dyskusji nie padły żadne
> przesłanki do stwierdzenia, że mogłoby ich być mniej.

Padły.

> I teraz okazuje się, że pomimo faktu, że będzie ich tyle samo i będzie
> do tego potrzebny taki sam wysiłek pisarski, to musimy je koniecznie
> wyrzucić do kosza i to najdalej parę godzin po napisaniu. To bardzo
> ważne. Bo jeśli zapomnimy je wyrzucić i się zaczną nam zbierać, to
> klient zobaczy plik kartek i jeszcze pomyśli, że my tu jakąś
> dokumentację piszemy i okaże się, że król jest nagi a my wcale nie
> jesteśmy agile.

Jak chcesz je sobie kolekcjonować, to twoja sprawa. Tak samo jak
chcesz sobie w weekend zrobić tripa na peyotlu to twoja sprawa. Ale
jak z faktu, że je kolekcjonujesz zrobisz praktykę, że z nich
korzystasz więcej niż tydzień po napisaniu, to "bo tak mam w notatce,
o tutaj, mogę pokazać" jest równie dobrą odpowiedzią na pytanie
"dlaczego to jest tak zrobione", co "bo tak mi powiedział mój duch
totemiczny na tripie peyotlowym".

> Niech mi ktoś wytłumaczy, w czym napisanie notatek i wywalenie ich do
> kosza jest lepsze od napisania ich i spięcia w segretatorze.

Oszczędzasz miejsce na biurku? Mniej trzeba wysiłku i czasu, żeby
wyrzucić kartkę do śmieci, niż żeby ją wpiąć do segregatora? Przede
wszystkim zaleta jest taka, że nie skorzystasz z tej notatki wtedy,
kiedy będzie ona nieaktualna, i kiedy zaimplementowanie tego, co jest
w niej zapisane wprowadzi buga do systemu, którego usunięcie zajmie
kupę czasu i pracy. Oczywiście możesz wpinać te notatki do skoroszytu
i nigdy więcej z nich nie korzystać, ale w takim razie niech mi ktoś
wytłumaczy, w czym spinanie notatek w segregatorze, z których się
nigdy nie skorzysta, jest lepsze od wyrzucania ich do śmieci?

> Pomijając fakt, że w kontekście biznesowym wyrzucanie *czegokolwiek*
> do kosza to czysta głupota i zwykle się srogo mści w późniejszym
> terminie.
> To nie jest żadna metodologia, to jest usankcjonowana
> nieodpowiedzialność.

Tu masz rację. Powinno się wrzucać do niszczarki.

> > Bywa. Dlatego też zasada nie jest taka, że się w ogóle nie produkuje
> > dokumentacji, tylko że dokumentuje się tylko to, czego absolutnie nie
> > da się zapisać w postaci testu lub kodu.
>
> Acha - czyli niektóre notatki zachowujemy w segregatorze. Wyrzucamy
> (koniecznie!) tylko te, dla których udało nam się napisać acceptance
> test.

Nic nie zachowujemy. Tworzymy normalną dokumentację.

> > Zakładając
> > przykładowo, że masz jakiś system, który liczy przejeżdżające
> > samochody na podstawie wejścia z jakichś sensorów, to można budować
> > testy w oparciu o rzeczywiste lub symulowane dane z tych sensorów.
>
> Ale klienta równo wali, czy to liczenie robi program, czy hardware,

Klient jest zamawiającym program.

> czy krasnoludki. I w ogóle jaki sensor?

Toż mówię - brak kontekstu. Przykładowo założyłem sobie, że program ma
liczyć samochody na podstawie danych z sensora. Oczywiście może sobie
liczyć samochody w bazie danych czy cośtam, ale bez kontekstu nie
jestem ci w stanie powiedzieć, jak to się testuje.

> Właśnie w tym jest problem, że systemy przemysłowe opisuje się
> całościowo, bo tylko w całości one są potrzebne. Wydzielanie granicy
> pomiędzy sensorami a programem, jest sztucznym krokiem, który z punktu
> widzenia klienta nic nie wnosi - dlatego nie wierzę, że OSCRowi będzie
> się chciało robić taki test. OSCR tego nie widzi. On widzi samochody.

Masz w takim razie niewłaściwego OSCR-a. Nie wiem jakie standardy są w
tej branży, ale klientem zespołu produkującego oprogramowanie nie
będzie właściciel fabryki samochodów, tylko zespół produkujący sprzęt,
ewentualnie zespół integrujący sprzęt z oprogramowaniem.

> W ogóle mam wrażenie, że agile wraz z całą swoją kulturą testowania
> jest bardzo nakierowany na założenie, że produktem jest jakiś program.

Heloł, bo to jest metodologia tworzenia oprogramowania, a nie
metodologia budowy robotów.

> Pewnie działa to jakość w kontekście np. serwisu internetowego, ale w
> większej skali produktem nie jest program, tylko system, w którym
> granice pomiędzy jego technicznymi składnikami (np. sensor vs.
> program) są niewidoczne dla klienta. I na tym się agile wyłoży.

Nie wyłoży się, tylko ty źle rozumiesz słowo "produkt". "Produkt" to
niekoniecznie jest to, co firma sprzedaje. XP się sprawdza kiedy
zespół produkujący sprzęt zamawia oprogramowanie w innej firmie lub w
dziale software tej samej firmy.

> > Bardzo prosto: dajesz OSCR-owi do odsłuchania ileś tam dźwięków
> > przetworzonym z takim pogłosem, on ci potwierdza, że to brzmi jak
> > odpowiednia filharmonia, piszesz test, który przetwarza dźwięk tym
> > efektem i sprawdza, czy wyjście się zgadza.
>
> Złapałeś się. :-) W przypadku pogłosu z filharmonii wyjście za każdym
> razem się może nie zgadzać (i na tym polega jego urok)

Ja nie mówię, o pogłosie z filharmonii, tylko o programowym filtrze,
który nadaje wejściu brzmienie jak pogłos z filharmonii - bo to
testujemy.

> a stwierdzenie,
> że coś brzmi tak samo jak coś innego jest subiektywne.

Program ci produkuje jakiś waveform, który odtworzony na danym
sprzęcie jakoś tam brzmi. Jeśli ten sam waveform na tym samym sprzęcie
raz brzmi, a raz nie brzmi jak pogłos z filharmonii, to nie jesteś w
stanie na ten sprzęt zrobić programowego filtra, który brzmi jak
pogłos z filharmonii.

Ale wiesz co? Jest odpowiednia metoda na zrobienie tego, o co chodzi:
w ogóle nie robić żadnego oprogramowania, tylko wstawić mniej-więcej
żeby działało parę oporników i kondensatorów, dać złote styki,
przegrzane kable, tytanową obudowę, hebanowe pokrętła, nóżki z rogu
nosorożca, dać egzemplarz albo dwa recenzentowi z odpowiedniego
czasopisma w zamian żeby napisał "zamknąłem oczy i poczułem się
zupełnie jakbym stał w słynnej sali imienia Pimcickiego w filharmonii
w Koluszkach" i jeszcze koniecznie "aksamitne basy i jedwabiste
soprany" - sukces murowany. Testowanie faktycznie niepotrzebne.

> Ten problem nie
> dotyczy tylko akustyki, jest cała masa takich miejsc. Np. ekspres do
> kawy ma robić dobrą kawę. Znowu nie ma jak zrobić acceptance testu.

No sorki, może się nie znam, ale program do ekspresu do kawy nie jest
żadną sztuczną inteligencją z zaszytym systemem ekspertowym "koneser
kawy" i wykrywaczem nastroju właściciela na podstawie "flucutation of
the pupil" i "involuntary dilationof the iris", tylko coś, co leci
przez jakiś prosty program, odmierza tyle a tyle wody, podgrzewa przez
tyle a tyle czasu itd. Jeśli przy tym samym programie i tych samych
warunkach wejściowych program robi raz dobrą, a raz niedobrą kawę, to
raczej nie z oprogramowaniem jest problem.

> > Nie znam się na tym, ale chętnie dowiem się dlaczego
> > tak uważasz.
>
> Właśnie dlatego, że w takich systemach ich działanie opisuje się
> całościowo.

Znaczy nie ma takiego etapu, gdzie określa się, jak się ma zachowywać
oprogramowanie w kategoriach sygnałów sterowania sprzętem?

> Agile jest za bardzo intruzywny i za bardzo zakłada, że
> klient będzie chciał być zaangażowany (poprzez OSCRów) w definiowanie
> tak drobno określonch szczegółów implementacyjnych.

Agile nie zakłada przede wszystkim, że "klient" to jest ten, co kupuje
coś w przedsiębiorstwie produkującym oprogramowanie.

> > Jeśli chodzi o "rozrywkowe", to na pewno wiem, że testy automatyczne,
> > jak i różne metodologie agile, stosuje się przy tworzeniu gier
> > komputerowych - chyba się kwalifikują jako 'rozrywka'?
>
> A tutaj to akurat ja się nie znam. Może profesor fir będzie wiedział.

Fir ma wiedzieć, co masz na myśli pisząc "systemy rozrywkowe"?