On Sat, 17 Dec 2011 06:27:47 +0100, Jacek <a...@o...pl> wrote:

>Dlaczego generalizujesz i mowisz o wszystkich uczestnikach tej grupy?
>Czyzbys znal ich wszystkich?

Nie, ja mowie o tych ktorych wypowiedzi komentuje. A oceniam ich po
tym czo pisza. Latwo odroznic tych ktorym sie tak wydaje,
doswiadczenie maja nijakie a cale "wiedze" wyczytalki z roznych
programistycznych forow, od tych ktorzy maja doswiadczenie prawdziwe.
Przemyslowe. Tacy tez tu pisuja.

A.L.

do góry

On 17/12/2011 15:30, Roman W wrote:
> On Dec 17, 8:53 am, Maciej Sobczak<s...@g...com> wrote:
>> Dokumentacja nie służy do redukcji ilości bugów, więc to, że jakieś
>> tam metody redukują tą ilość skuteczniej niż dokumentacja nie może
>> prowadzić do żadnych sensownych wniosków. W szczególności nie do
>> takich, że dokumentacji może nie być.
>
> Ja bym raczej powiedzial na chlopski rozum, ze dokumentacja definiuje
> co jest bugiem, a co nie. Jak programista Agile ma eliminowac bugi,
> kiedy nie wie, co jest prawidlowym zachowaniem budowanego systemu? "On-
> site customer representative" mu o tym za kazdym razem powie? Przeciez
> to wiaze programiscie rece -- z kazda zmiana w kodzie musi leciec do
> "on site customer representative", bo a nuz zmiana ktora chce
> wprowadzic w kodzie zmieni zachowanie systemu w sposob ktory jest
> nieakceptowalny dla OSCR - a programista sam tego sprawdzic nie ma
> gdzie, bo czniamy dokumentacje.

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

Na podstawie takiej rozmowy programista razem z OSCR tworzą acceptance
test, który weryfikuje istotne askpekty funkcjonalności. Jeśli
programista zmieni program tak, że przestaje przechodzić testy, które
wcześniej przechodził, to może skonsultować się z OSCR w kwestii
ustalenia, czy testy są błędne i należy je zmodyfikować.

do góry

On 17/12/2011 15:27, Roman W wrote:
> On Dec 17, 9:56 am, Andrzej Jarzabek<a...@g...com>
> wrote:
>
>> To się nazywa "demo". I dlaczego niby bicie po głowie niedokończoną
>> wersją jest lepsze od bicia dokumentacją wymagań? W projekcie A.L. ten
>> dokument ma dziewięćset ileśtam stron - oberwanie czymś takim w głowę
>> może być nieprzyjemne.
>
> To wracajac do tematu respiratora, jak wyglada "wersja demo" w takim
> wypadku? Testuja wersje alpha kodu na jednym z programistow?

Nie mam pojęcia jak się testuje respiratory, ale podejrzewam, że jednak
nie na żywym organiźmie. Ja nawet nie mam pojęcia co takie
oprogramowanie do respiratora robi. Jeśli jest to coś na zasadzie

while(true) {
wait(delay);
breathe_in();
wait(delay);
breathe_out();
}

to może faktycznie nie ma sensu stosować jakiejkolwiek metodologii, ale
i dokumentacja projektowa wydaje się zbędna. Jeśli ma jakąś bardziej
skomplikowaną logikę, to przypuszczalnie da się ją jakoś testować i
demonstrować.

do góry

On Dec 17, 3:58 pm, Andrzej Jarzabek <a...@g...com>
wrote:
> On 17/12/2011 15:30, Roman W wrote:
>
> > On Dec 17, 8:53 am, Maciej Sobczak<s...@g...com>  wrote:
> >> Dokumentacja nie służy do redukcji ilości bugów, więc to, że jakieś
> >> tam metody redukują tą ilość skuteczniej niż dokumentacja nie może
> >> prowadzić do żadnych sensownych wniosków. W szczególności nie do
> >> takich, że dokumentacji może nie być.
>
> > Ja bym raczej powiedzial na chlopski rozum, ze dokumentacja definiuje
> > co jest bugiem, a co nie. Jak programista Agile ma eliminowac bugi,
> > kiedy nie wie, co jest prawidlowym zachowaniem budowanego systemu? "On-
> > site customer representative" mu o tym za kazdym razem powie? Przeciez
> > to wiaze programiscie rece -- z kazda zmiana w kodzie musi leciec do
> > "on site customer representative", bo a nuz zmiana ktora chce
> > wprowadzic w kodzie zmieni zachowanie systemu w sposob ktory jest
> > nieakceptowalny dla OSCR - a programista sam tego sprawdzic nie ma
> > gdzie, bo czniamy dokumentacje.
>
> 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?

>
> Na podstawie takiej rozmowy programista razem z OSCR tworzą acceptance
> test, który weryfikuje istotne askpekty funkcjonalności.

Czy uwazasz, ze 100% funkcjonalnosci mozna udokumentowac w formie
testu?
Zalozmy, ze projekt zawiera biblioteke numeryczna. Czy wystarczy
"acceptance test", czy nie nalezy rowniez udokumentowac algorytmow,
ktore biblioteka ma implementowac?

> Jeśli
> programista zmieni program tak, że przestaje przechodzić testy, które
> wcześniej przechodził, to może skonsultować się z OSCR w kwestii
> ustalenia, czy testy są błędne i należy je zmodyfikować.

A jezeli zmieni dzialanie programu w aspekcie nie objetym testami?

RW

do góry

On 12/17/2011 06:00 PM, Roman W wrote:
>> > Na podstawie takiej rozmowy programista razem z OSCR tworzą acceptance
>> > test, który weryfikuje istotne askpekty funkcjonalności.
> Czy uwazasz, ze 100% funkcjonalnosci mozna udokumentowac w formie
> testu?
> Zalozmy, ze projekt zawiera biblioteke numeryczna. Czy wystarczy
> "acceptance test", czy nie nalezy rowniez udokumentowac algorytmow,
> ktore biblioteka ma implementowac?
>
>> > Jeśli
>> > programista zmieni program tak, że przestaje przechodzić testy, które
>> > wcześniej przechodził, to może skonsultować się z OSCR w kwestii
>> > ustalenia, czy testy są błędne i należy je zmodyfikować.
> A jezeli zmieni dzialanie programu w aspekcie nie objetym testami?
>

Oj tam, oj tam, znalazł się bluźnierca przeciwko testom. Jesteś
za mało Agile ;)

Edek

do góry

On Dec 17, 5:17 pm, Edek <e...@g...com> wrote:
> Oj tam, oj tam, znalazł się bluźnierca przeciwko testom. Jesteś
> za mało Agile ;)

Kiedy tylko slysze argument "jezeli X nie dziala, to znaczy ze uzywasz
za malo/jestes za malo X", w glowie dzwoni mi taki ostrzegawczy
dzwoneczek.

RW

do góry

On 2011-12-17, Roman W <b...@g...pl> wrote:
> On Dec 17, 5:17 pm, Edek <e...@g...com> wrote:
>> Oj tam, oj tam, znalazł się bluźnierca przeciwko testom. Jesteś
>> za mało Agile ;)
>
> Kiedy tylko slysze argument "jezeli X nie dziala, to znaczy ze uzywasz
> za malo/jestes za malo X", w glowie dzwoni mi taki ostrzegawczy
> dzwoneczek.

Spodziewam się, że tu powinien dzwonić na okoliczność ironii.

--
Secunia non olet.
Stanislaw Klekot

do góry

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. 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), no i przede wszystkim będzie
to działający kod, który robi właśnie to, co trzeba.

>> Na podstawie takiej rozmowy programista razem z OSCR tworzą acceptance
>> test, który weryfikuje istotne askpekty funkcjonalności.
>
> Czy uwazasz, ze 100% funkcjonalnosci mozna udokumentowac w formie
> testu?

Nawet jeśli można udokumentować 99%, to praktycznie różnica jest niewielka.

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

>> Jeśli
>> programista zmieni program tak, że przestaje przechodzić testy, które
>> wcześniej przechodził, to może skonsultować się z OSCR w kwestii
>> ustalenia, czy testy są błędne i należy je zmodyfikować.
>
> A jezeli zmieni dzialanie programu w aspekcie nie objetym testami?

To dobrze, że przynajmniej zdaje sobie sprawę, że zmieni. W takiej
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.

do góry

On Dec 17, 7:04 pm, "Stachu 'Dozzie' K."
<d...@g...eat.some.screws.spammer.invalid> wrote:
> On 2011-12-17, Roman W <b...@g...pl> wrote:
>
> > On Dec 17, 5:17 pm, Edek <e...@g...com> wrote:
> >> Oj tam, oj tam, znalazł się bluźnierca przeciwko testom. Jesteś
> >> za mało Agile ;)
>
> > Kiedy tylko slysze argument "jezeli X nie dziala, to znaczy ze uzywasz
> > za malo/jestes za malo X", w glowie dzwoni mi taki ostrzegawczy
> > dzwoneczek.
>
> Spodziewam się, że tu powinien dzwonić na okoliczność ironii.

Wiem, ale i tak chcialem napisac o dzwoneczku.

RW

do góry

On Dec 17, 7:12 pm, 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.

Systemu jako calosci? Czyli jednak 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.

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

>
> >> Na podstawie takiej rozmowy programista razem z OSCR tworzą acceptance
> >> test, który weryfikuje istotne askpekty funkcjonalności.
>
> > 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.

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

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

>
> >> Jeśli
> >> programista zmieni program tak, że przestaje przechodzić testy, które
> >> wcześniej przechodził, to może skonsultować się z OSCR w kwestii
> >> ustalenia, czy testy są błędne i należy je zmodyfikować.
>
> > 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.

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

RW

do góry