On Dec 17, 4:30 pm, Roman W <b...@g...pl> wrote:

> Ja bym raczej powiedzial na chlopski rozum, ze dokumentacja definiuje
> co jest bugiem, a co nie.

Bingo.

> Jak programista Agile ma eliminowac bugi,
> kiedy nie wie, co jest prawidlowym zachowaniem budowanego systemu?

No właśnie. Bo jeśli program działa niezgodnie z istniejącą
dokumentacją, to coś należy poprawić. Ale jeżeli działa niezgodnie z
nieistniejącą dokumentacją, to projekt jest w ciemnej d*pie. I to jest
właśnie ta perspektywa, której się obawiam.

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

do góry

On Sat, 17 Dec 2011 19:12:18 +0000, Andrzej Jarzabek
<a...@g...com> wrote:

>On 17/12/2011 17:00, Roman W wrote:
>> On Dec 17, 3:58 pm, Andrzej Jarzabek<a...@g...com>
>> wrote:
>>
>>>> co jest bugiem, a co nie. Jak programista Agile ma eliminowac bugi,
>>>> kiedy nie wie, co jest prawidlowym zachowaniem budowanego systemu? "On-
>[...]
>>> Tak, generalnie polega to na tym, że programista rozmawia z OSCR tak
>>> długo, żeby zrozumieć co program ma robić, a jeśli nie jest w stanie
>>> zrozumieć czy ewentualne zachowanie jest prawidłowe, czy nie, to
>>> rozmawia z OSCR jeszcze trochę.
>>
>> A co jest rezultatem tej rozmowy? Notatki pisane olowkiem na serwetce,
>> watem mailowy w firmowym Outlooku, czy cos bardziej
>> ustrukturyzowanego?
>
>Przede wszystkim rezultatem tej rozmowy jest to, że programista wie, co
>jest prawidłowym zachowaniem budowanego systemu.

A jezeli programistow jest 50 i owi programisci nigdy bezposrednio nie
kontaktuja sie z faktycznym uzytkownikiem systemu?

A.L.

do góry

On Sat, 17 Dec 2011 14:27:30 -0800 (PST), Maciej Sobczak
<s...@g...com> wrote:

>On Dec 17, 4:30 pm, Roman W <b...@g...pl> wrote:
>
>> Ja bym raczej powiedzial na chlopski rozum, ze dokumentacja definiuje
>> co jest bugiem, a co nie.
>
>Bingo.
>
>> Jak programista Agile ma eliminowac bugi,
>> kiedy nie wie, co jest prawidlowym zachowaniem budowanego systemu?
>
>No właśnie. Bo jeśli program działa niezgodnie z istniejącą
>dokumentacją, to coś należy poprawić. Ale jeżeli działa niezgodnie z
>nieistniejącą dokumentacją, to projekt jest w ciemnej d*pie. I to jest
>właśnie ta perspektywa, której się obawiam.

Nie ma sie Pan co obawiac. To jest "metodologia Agile". Ponoc jedynie
sluszna.

Ciekawe jak "agilowcy" wyobrazaja sobie projekt w ktorym pracuje,
powiedzmy, 50 programistow, i owi programisci nigdy nie kontaktuja sie
z przyszlym uzytkownikiem systemu?

A.L.

do góry

On Dec 17, 4:58 pm, Andrzej Jarzabek <a...@g...com>
wrote:

> Tak, generalnie polega to na tym, że programista rozmawia z OSCR tak
> długo, żeby zrozumieć co program ma robić,

I to jest właśnie problem tej metodologii, bo zakłada ciągłość tego
procesu.

Otóż ja mam taki defekt[*], że jak ktoś coś do mnie mówi, to już po
kilku minutach nie pamiętam, o czym mówił na początku. Radzę sobię z
krótką listą zakupów, ale dłuższe opisy mi się urywają.

[*] Z obserwacji wynika, że nie tylko ja mam ten defekt. Akurat mamy
weekend - stań przed jakimś kościołem i zapytaj wychodzących ludzi o
czym było kazanie. Pamiętaj, że wszyscy słuchali tego samego, ale
zapytaj kilka różnych osób.
Dobre, nie?

Pytanie: jak długa jest rozmowa z tym - jak mu tam - OSCR, żeby
przekazać równoważnik kilkuset stron tekstu? Krócej, niż kazanie, czy
dłużej?

> a jeśli nie jest w stanie
> zrozumieć czy ewentualne zachowanie jest prawidłowe, czy nie, to
> rozmawia z OSCR jeszcze trochę.

No właśnie.
Otóż zaletą metodologii "dokumentacyjnych" jest to, że kiedyś,
ostatecznie, *można się rozejść*. Bo nawet jeśli się odbiorcy się
urwał wątek, to może sobie do niego wrócić we własnym zakresie i nie
potrzebuje "rozmawiać z OSCR jeszcze trochę".

Coś jak wydrukowane kazanie.

Możliwość rozejścia się jest kluczowa dla postępu projektu. Bez tej
możliwości albo masz zastój (znaczy: odbiorca "rozmawia jeszcze
trochę" w nieskończoność), albo urwaną treść. Osobiście nie widzę
siebie w rozmowie na temat czegoś, co na papierze ma kilkaset stron.

Napisanie dokumentacji służy przekazaniu wiedzy i jest to proces,
który może być zarówno kompletny, jak i obustronnie potwierdzony.
Minimalizacja bugów, jeśli w ogóle występuje, jest tu procesem
pobocznym a nie celem samym w sobie. Celem minimalizacji bugów może
być np. zastosowanie metod formalnych. Albo unit testy. Albo voo-doo.
Albo co tam kto umie i czemu ufa, zależnie od budżetu i lokalnej
kultury. Jednak żadna z tych metod nie wyklucza użycia dokumentacji,
która służy tylko (i aż!) do skompletowania procesu przekazywania
wiedzy.
Dlatego nie ma problemu, żeby zrobić dokumentację *oraz* unit testy
(przykładowo).

Problem z agile polega na tym, że przekazywanie wiedzy oparte jest na
machaniu rękami i jest to najsłabsze ogniwo z powodów powyżej. A
ponieważ to ogniwo jest na początku procesu, to dalej buduje się na
gównianych fundamentach i stąd te ciągłe dema i walenie klienta po
głowie niedokończonymi wersjami.
Pominięcie dokumentacji *nie jest tańsze*. Tak przynajmniej wynika z
moich obserwacji.

Oczywiście, robiłem też projekty bez dokumentacji. Jak również takie
bez testów. Albo nawet bez kawy. Takie bez klienta też. Wszystko
zależnie od potrzeb.

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

do góry

On 17/12/2011 20:02, Roman W wrote:
> On Dec 17, 7:12 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>>
>>> A co jest rezultatem tej rozmowy? Notatki pisane olowkiem na serwetce,
>>> watem mailowy w firmowym Outlooku, czy cos bardziej
>>> ustrukturyzowanego?
>>
>> Przede wszystkim rezultatem tej rozmowy jest to, że programista wie, co
>> jest prawidłowym zachowaniem budowanego systemu.
>
> Systemu jako calosci? Czyli jednak dokumentacja.

Systemu jako całości lub danego kawałka. Wiedza to nie jest to samo, co
dokumentacja.

>> Jeśli chodzi o
>> artefakty, to może to być "user story" (czy inny "change control ticket)
>> - jeśli objaśnienie się kwalifikuje, będzie to prawdopodobnie jeden lub
>> kilka testów (acceptance test, unit tests),
>
> Ale to opisuje wycinek systemu.

Łącznie wszystkie te opisy opisują cały system. Tak samo jak z
dokumentacją wymagań zresztą: składa się zwykle z jakichś rozdziałów,
które opisują wycinki systemu.

>> no i przede wszystkim będzie
>> to działający kod, który robi właśnie to, co trzeba.
>
> Nie, bedzie to kod przechodzacy kilka testow. To nie to samo.

Jednak nie tylko przechodzący kilka testów, bo jego forma się bierze
stąd, że programista _rozumie_ co program ma robić, a nie z tego, że
widział kod testów i dostaje zadanie napisania kodu je przechodzącego.

To, że 100% gwarancji na poprawność kodu nie ma, to osobna sprawa -
dokumentacja też przecież takiej gwarancji nie daje.

>>> Czy uwazasz, ze 100% funkcjonalnosci mozna udokumentowac w formie
>>> testu?
>>
>> Nawet jeśli można udokumentować 99%, to praktycznie różnica jest niewielka.
>
> Czyli uwazasz, ze osiagalne jest "99%" (czyli prawie kompletny opis)?
> Tak/nie.

Ostrożnie powiem, że to zależy od dziedziny, a ja się na wielu
dziedzinach nie znam. Ale na ogół uważam, że tak właśnie jest - między
odpowiednio ekspresywnie napisanymi testami a odpowiednio ekspresywnie
napisanym kodem da się wyrazić to, co zazwyczaj się wyraża w
dokumentacji - równie dobrze jak w dokumentacji.

>>> Zalozmy, ze projekt zawiera biblioteke numeryczna. Czy wystarczy
>>> "acceptance test", czy nie nalezy rowniez udokumentowac algorytmow,
>>> ktore biblioteka ma implementowac?
>>
>> Nie wiem konkretnie jak jest z bibliotekami numerycznymi.
>
> Jest tak, ze nie wystarczy wiedziec, ze biblioteka przechodzi X
> testow, zeby ocenic, czy design jest poprawny czy nie. Testy moga
> sprawdzic skonczona liczbe przypadkow, ale wymagania stawiane
> bibliotekom numerycznym jest ciezko zawrzec calkowicie w formie
> testow.
> Np. wymaganie moze brzmiec "procedura X ma implementowac algorytm
> calkujacy Grubiediewa". Jak to sprawdzisz unit testem?

Po pierwsze - tak w ogóle - testy to nie tylko unit testy.

Po drugie w innych działkach, i przypuszczam, że tutaj tak samo, wybór
algorytmu wynika z pewnym właściwości całkowania tym algorytmem, które
są rzeczywistym wymaganiem. I te właściwości można jak najbardziej testować.

Poza sprawdzeniem obserwowalnych właściwości zachowania programu,
istotne właściwości implementacji zamiast zapisywać w dokumentacji można
często zapisać w kodzie. Trochę żartobliwie mogę powiedzieć, że to, co
napisałeś da się zapisać tak:

double X (args) {
return calkujAlgortymemGrubiediewa(args);
}

>> Jeśli chodzi o
>> to, że wykorzystujesz jakieś algorytmy z literatury i chcesz
>> udokumentować fakt, że stosujesz algorytm Kamionnego-Łomonosowa z
>> artykułu "Zastosowanie metod numerycznych przy wykopywaniu ziemniaków"
>> publikowanego w miesięczniku Kołchoźnik nr 8/51? No to może faktycznie
>> należy dać przypis w komentarzu.
>
> A jesli algorytm nie zostal nigdzie opublikowany?

To co napiszesz w dokumencie? Że funkcja całkuje algorytmem, który nie
został nigdzie opublikowany? Takie coś to można napisać w komentarzu.

Jeśli chodzi o opis działania samego algorytmu, to programiści dysponują
znakomitym narzędziem właśnie do tego, jakim są wysokopoziomowe języki
programowania.

Oczywiście jeśli masz taką sytuację, że wymyślasz własny algorytm i
musisz np. formalnie udowodnić jego poprawność, to może i najlepiej to
zrobić w postaci dokumentu. Ale jak często zdarzają się tak naprawdę
takie sytuacje?

>>> A jezeli zmieni dzialanie programu w aspekcie nie objetym testami?
>>
>> To dobrze, że przynajmniej zdaje sobie sprawę, że zmieni.
>
> Skad ma zdawac sobie sprawe? Przeciez nie ma dokumentacji, moze uznac,
> ze zmiana w kodzie nie zmieni istotnych aspektow dzialania programu,
> bo... unit testy przechodza.

Po pierwsze może się po prostu wziąć z analizy "jakie będą konsekwencje
jeśli zmienię program w ten sposób". Jeśli programiście mylnie się
wydaje, że zachowanie programu się nie zmieni, to dokumentacja w niczym
tu nie pomoże. Jeśli programista jest w stanie stwierdzić, że zachowanie
programu się zmieni, to powinien być też w stanie stwierdzić, że nie ma
testów testujących aspekt który się zmieni, więc jest w stanie uruchomić
całą procedurę "dlaczego nie ma na to testów".

Po drugie tak w ogóle ten scenariusz nie różni się za bardzo od
sytuacji, kiedy zmiany wprowadzone przez programistę powodują zmianę
działania programu w aspekcie nie objętym dokumentacją.

>> sytuacji, skoro aspekt nie jest objęty testami, to prawdopowodnie należy
>> go objąć testami. No chyba że OSCR powie, że ten aspekt jest nieistotny,
>> to wtedy nie ma problemu.
>
> Ale skad programista ma *wiedziec*, ze zmiana ktora chce wprowadzic w
> kodzie jest istotna i powinna byc skonsultowana z OSCR, skoro nie ma
> dokumentacji? Ma trzymac OSCR non-stop przy sobie? A jesli nad
> projektem pracuje wiecej niz 1 programista, to ile osob ze strony
> klienta ma je nadzorowac?

Zakłada się, że programista ma jakąś inteligencję i powinien na
podstawie rozmów z OSCR nabyć wiedzy i rozumienia na temat tego, jak
program ma działać i dlaczego właśnie tak.

Poza tym dąży się do tego, żeby zmiany funkcjonalne praktycznie zawsze
były objęte istniejącymi testami. Jeśli coś nie jest objęte testem, a
może być istotne, to się testy dodaje i potem one już są.

do góry

On 17/12/2011 22:51, Maciej Sobczak wrote:
> On Dec 17, 4:58 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>
>> Tak, generalnie polega to na tym, że programista rozmawia z OSCR tak
>> długo, żeby zrozumieć co program ma robić,
>
> I to jest właśnie problem tej metodologii, bo zakłada ciągłość tego
> procesu.
>
> Otóż ja mam taki defekt[*], że jak ktoś coś do mnie mówi, to już po
> kilku minutach nie pamiętam, o czym mówił na początku. Radzę sobię z
> krótką listą zakupów, ale dłuższe opisy mi się urywają.

Sprzedam ci niezły patent: notatki.

do góry

On Dec 17, 10:51 pm, Maciej Sobczak <s...@g...com> wrote:
> Napisanie dokumentacji służy przekazaniu wiedzy i jest to proces,
> który może być zarówno kompletny, jak i obustronnie potwierdzony.

Nie tylko przekazaniu, ale i sformalizowaniu. Wiele razy mialem tak,
ze koncepcja ktora tlukla mi sie po glowie nabierala ostateczna forme
dopiero kiedy przelewalem ja "na papier". Spisanie planu dzialania
pozwala zobaczyc w nim luki i niedociagniecia, ktore w rozmowie ustnej
albo emailowej moga umknac uwadze. Taniej i szybciej jest poprawic
blad na papierze niz w kodzie.

RW

do góry

On Dec 18, 1:36 am, Andrzej Jarzabek <a...@g...com>
wrote:
> On 17/12/2011 20:02, Roman W wrote:
> > Systemu jako calosci? Czyli jednak dokumentacja.
>
> Systemu jako całości lub danego kawałka. Wiedza to nie jest to samo, co
> dokumentacja.

Dokumentacja to sformalizowana, usystematyzowana wiedza.

> > Ale to opisuje wycinek systemu.
>
> Łącznie wszystkie te opisy opisują cały system. Tak samo jak z
> dokumentacją wymagań zresztą: składa się zwykle z jakichś rozdziałów,
> które opisują wycinki systemu.

Wiesz, rownie dobrze mozna by argumentowac, ze rozsypana na podlodze
kupka srubek i sprezynek to jest tak jak zegarek, bo i to i to sklada
sie z jakichs srubek i sprezynek. Ale jakos jedno powie mi ktora
godzina, a drugie nadaje sie tylko do zmiecenia szczotka.

>
> >> no i przede wszystkim będzie
> >> to działający kod, który robi właśnie to, co trzeba.
>
> > Nie, bedzie to kod przechodzacy kilka testow. To nie to samo.
>
> Jednak nie tylko przechodzący kilka testów, bo jego forma się bierze
> stąd, że programista _rozumie_ co program ma robić, a nie z tego, że
> widział kod testów i dostaje zadanie napisania kodu  je przechodzącego.

To co widzial? mial objawienie? czy moze cos, gasp, przeczytal?

RW

do góry

On Dec 18, 1:46 am, Andrzej Jarzabek <a...@g...com>
wrote:
> On 17/12/2011 22:51, Maciej Sobczak wrote:
>
> > On Dec 17, 4:58 pm, Andrzej Jarzabek<a...@g...com>
> > wrote:
>
> >> Tak, generalnie polega to na tym, że programista rozmawia z OSCR tak
> >> długo, żeby zrozumieć co program ma robić,
>
> > I to jest właśnie problem tej metodologii, bo zakłada ciągłość tego
> > procesu.
>
> > Otóż ja mam taki defekt[*], że jak ktoś coś do mnie mówi, to już po
> > kilku minutach nie pamiętam, o czym mówił na początku. Radzę sobię z
> > krótką listą zakupów, ale dłuższe opisy mi się urywają.
>
> Sprzedam ci niezły patent: notatki.

Jezeli Koles A przelewa wiedze do glowy kolesia B, to czesto lepiej
jest, zeby forme pisemna wiedzy nadal koles A, bo on sie w tym lepiej
orientuje niz B. Dlatego na studiach oprocz notatek miales rowniez
podreczniki i konspekty.

RW

do góry

On Sun, 18 Dec 2011 01:36:16 +0000, Andrzej Jarzabek
<a...@g...com> wrote:

>
>
>Jeśli chodzi o opis działania samego algorytmu, to programiści dysponują
>znakomitym narzędziem właśnie do tego, jakim są wysokopoziomowe języki
>programowania.


Dupy zawracanie. Oczywiscie, latwo bedzie odcyfrowac taka rzecz jak
"algorytm pivotingu" algorytmu Simplex przegladajac 150 tysiecy linii
C jego implemenatcji.

Drodzy Panowie, znow obracacie sie kolo paradygmatu "bazki danych
szlauchow i kaloszy" i "systemow" pisanych pzrez jednego programiste w
pare wieczorow. Jeszcze raz: w duzych projektach programista nei
rozmawia z klientem, w ogole nie widzi go na oczy, a "klient" to nie
pojedyncza osoba a duza na ogol organizacja. Bez odpowiedniej
formalizacji procesu projektowania i dokumentowania wymagan dla
programisty ow programista nei mialby zielonego pojacia co
programowac, a projekt skutkowalby tym samym czym skutkowala proba
bucowy Wiezy Babel

A.L.

do góry