On Dec 16, 12:22 am, A.L. <l...@a...com> wrote:
> On Sat, 10 Dec 2011 23:36:51 +0000, Andrzej Jarzabek
>
>
>
>
>
>
>
>
>
> <a...@g...com> wrote:
> >On 10/12/2011 22:24, Roman W wrote:
> >> On Dec 10, 9:34 pm, Andrzej Jarzabek<a...@g...com>
>
> >>> Jest trochę taki problem, że jak dokumentacja opisuje rzeczy niezgodne z
> >>> faktyczną rzeczywistością, to się na niej czas traci dwa razy: raz, jak
> >>> się ją pisze, drugi raz, jak się próbuje z niej skorzystać.
>
> >> Z regulay mozna wyodrebnic "rdzen" funkcjonalnosci, ktory sie raczej
> >> nie zmieni, i przynajmniej ten udokumentowac.
>
> >Niewątpliwie, jednak nie zawsze to jest potrzebne.
>
> >Oczywiście, że wiele rzeczy dokumentować trzeba. Dla produktu musi
> >powstać dokumentacja dla użytkownika końcowego, biblioteki czy inne
> >komponenty powinny mieć udokumentowane API, a wszystkie decyzje,
> >ustalenia i wnioski dotyczące funkcjonalności powinny być dokumentowane
> >na bieżąco. I przecież w Agile się tego nie kwestionuje. Przede
> >wszystkim odrzuca się tworzenie dokumentów, na podstawwie których
> >tworzony jest program: dokumentacji wymagań i "dokumentu projektowego"
> >czyli opisania całości struktury i jednostek kodu przed rozpoczęciem
> >implementacji. W dalszej kolejności odrzuca się w ogóle potrzebę
> >utrzymywania dokumentacji projektu kodu, nawet jeśli nie jest tworzony z
> >góry.
>
> Zwlaszcza dobrze sie to sprawdza przy pisaniu oprogramowania do
> sterowania statecznikami poziomymi samolotu F-16, albo zeby byc blizej
> ziemii, sterowania kolumna destylacyjna w Pertochemii Plockiej. Dobrze
> tez taka metode zatosowac przy pisaniu oprogramwoania stuerujacego
> kompresorami gazociagu magistralnego Jaroslaw-Wloclawek. Nie mowiac o
> zwyklym, prostym komputerku sterujacym silnikiem samochodowym

Być może, nie mam żadnych danych na ten temat.

> Cale wasze doswiadczenie, Panowie, pochodzi z "pierdykniecia bazki
> danych szlauchow i kaloszy dla Miejskiego Przedsiebiorstwa
> Kanalizacyjnego". Software bywa ze obsluguje inne problemy tez. Duzo
> bardziej skomplikowane. I takie ze jak sie pusci buga, to cos moze
> wybuchnac albo ktos moze zostac zabity

No też dlatego w wielu metodologiach agile stosuje się skuteczne
metody redukcji ilości bugów - znacznie bardziej skuteczne, niż
dokumentacja. Bo jeśli dokumentacja opisuje takie zachowanie programu,
przy którym nic nie wybucha i nikogo nie zabija, a sam program
zachowuje się inaczej, i w związku z tym wybucha i zabija, to dla
zabitych jednak jest niewielką pociechą, że w dokumencie było wszystko
OK.

do góry

Dnia Thu, 15 Dec 2011 18:22:41 -0600, A.L. napisał(a):

> On Sat, 10 Dec 2011 23:36:51 +0000, Andrzej Jarzabek
> <a...@g...com> wrote:
>
>>On 10/12/2011 22:24, Roman W wrote:
>>> On Dec 10, 9:34 pm, Andrzej Jarzabek<a...@g...com>
>>>>
>>>> Jest trochę taki problem, że jak dokumentacja opisuje rzeczy niezgodne z
>>>> faktyczną rzeczywistością, to się na niej czas traci dwa razy: raz, jak
>>>> się ją pisze, drugi raz, jak się próbuje z niej skorzystać.
>>>
>>> Z regulay mozna wyodrebnic "rdzen" funkcjonalnosci, ktory sie raczej
>>> nie zmieni, i przynajmniej ten udokumentowac.
>>
>>Niewątpliwie, jednak nie zawsze to jest potrzebne.
>>
>>Oczywiście, że wiele rzeczy dokumentować trzeba. Dla produktu musi
>>powstać dokumentacja dla użytkownika końcowego, biblioteki czy inne
>>komponenty powinny mieć udokumentowane API, a wszystkie decyzje,
>>ustalenia i wnioski dotyczące funkcjonalności powinny być dokumentowane
>>na bieżąco. I przecież w Agile się tego nie kwestionuje. Przede
>>wszystkim odrzuca się tworzenie dokumentów, na podstawwie których
>>tworzony jest program: dokumentacji wymagań i "dokumentu projektowego"
>>czyli opisania całości struktury i jednostek kodu przed rozpoczęciem
>>implementacji. W dalszej kolejności odrzuca się w ogóle potrzebę
>>utrzymywania dokumentacji projektu kodu, nawet jeśli nie jest tworzony z
>>góry.
>
> Zwlaszcza dobrze sie to sprawdza przy pisaniu oprogramowania do
> sterowania statecznikami poziomymi samolotu F-16, albo zeby byc blizej
> ziemii, sterowania kolumna destylacyjna w Pertochemii Plockiej. Dobrze
> tez taka metode zatosowac przy pisaniu oprogramwoania stuerujacego
> kompresorami gazociagu magistralnego Jaroslaw-Wloclawek. Nie mowiac o
> zwyklym, prostym komputerku sterujacym silnikiem samochodowym
>
> Cale wasze doswiadczenie, Panowie, pochodzi z "pierdykniecia bazki
> danych szlauchow i kaloszy dla Miejskiego Przedsiebiorstwa
> Kanalizacyjnego". Software bywa ze obsluguje inne problemy tez. Duzo
> bardziej skomplikowane. I takie ze jak sie pusci buga, to cos moze
> wybuchnac albo ktos moze zostac zabity
>
> A.L.

Co nie znaczy, ze zwykly blad technika w najprostszej fabryce mydla, ktory
ustawil gorny prog jakiegos czujnika czegos za wysoko i tez moze pierdyknac
i zabic niejednego...
Skad w Tobie tyle 'nienawisci'?
Ktos, kto pierdyknie bazke dla wodociagow tez moze narazic firme/klienta na
straty, a i na zagrozenie zycia.
Opusc sie z tej Ameryki i osiadz wsrod ludzi.
Odnosze wrazenie, ze bronisz sie atakiem, chociaz nikt Ciebie nie
atakuje...

do góry

On Fri, 16 Dec 2011 17:44:55 +0100, Jacek <a...@o...pl> wrote:

>Dnia Thu, 15 Dec 2011 18:22:41 -0600, A.L. napisał(a):
>
>> On Sat, 10 Dec 2011 23:36:51 +0000, Andrzej Jarzabek
>> <a...@g...com> wrote:
>>
>>>On 10/12/2011 22:24, Roman W wrote:
>>>> On Dec 10, 9:34 pm, Andrzej Jarzabek<a...@g...com>
>>>>>
>>>>> Jest trochę taki problem, że jak dokumentacja opisuje rzeczy niezgodne z
>>>>> faktyczną rzeczywistością, to się na niej czas traci dwa razy: raz, jak
>>>>> się ją pisze, drugi raz, jak się próbuje z niej skorzystać.
>>>>
>>>> Z regulay mozna wyodrebnic "rdzen" funkcjonalnosci, ktory sie raczej
>>>> nie zmieni, i przynajmniej ten udokumentowac.
>>>
>>>Niewątpliwie, jednak nie zawsze to jest potrzebne.
>>>
>>>Oczywiście, że wiele rzeczy dokumentować trzeba. Dla produktu musi
>>>powstać dokumentacja dla użytkownika końcowego, biblioteki czy inne
>>>komponenty powinny mieć udokumentowane API, a wszystkie decyzje,
>>>ustalenia i wnioski dotyczące funkcjonalności powinny być dokumentowane
>>>na bieżąco. I przecież w Agile się tego nie kwestionuje. Przede
>>>wszystkim odrzuca się tworzenie dokumentów, na podstawwie których
>>>tworzony jest program: dokumentacji wymagań i "dokumentu projektowego"
>>>czyli opisania całości struktury i jednostek kodu przed rozpoczęciem
>>>implementacji. W dalszej kolejności odrzuca się w ogóle potrzebę
>>>utrzymywania dokumentacji projektu kodu, nawet jeśli nie jest tworzony z
>>>góry.
>>
>> Zwlaszcza dobrze sie to sprawdza przy pisaniu oprogramowania do
>> sterowania statecznikami poziomymi samolotu F-16, albo zeby byc blizej
>> ziemii, sterowania kolumna destylacyjna w Pertochemii Plockiej. Dobrze
>> tez taka metode zatosowac przy pisaniu oprogramwoania stuerujacego
>> kompresorami gazociagu magistralnego Jaroslaw-Wloclawek. Nie mowiac o
>> zwyklym, prostym komputerku sterujacym silnikiem samochodowym
>>
>> Cale wasze doswiadczenie, Panowie, pochodzi z "pierdykniecia bazki
>> danych szlauchow i kaloszy dla Miejskiego Przedsiebiorstwa
>> Kanalizacyjnego". Software bywa ze obsluguje inne problemy tez. Duzo
>> bardziej skomplikowane. I takie ze jak sie pusci buga, to cos moze
>> wybuchnac albo ktos moze zostac zabity
>>
>> A.L.
>
>Co nie znaczy, ze zwykly blad technika w najprostszej fabryce mydla, ktory
>ustawil gorny prog jakiegos czujnika czegos za wysoko i tez moze pierdyknac
>i zabic niejednego...
>Skad w Tobie tyle 'nienawisci'?

Ja nie mam zabnej nienawisci. Ja sie wysmiewam z niekompetencji i
opowiadania bzdur.

>Ktos, kto pierdyknie bazke dla wodociagow tez moze narazic firme/klienta na
>straty, a i na zagrozenie zycia.

Dlatego potzrebne sa "wymagania" i "zalozenia projektowe" Oraz projekt
i dokumentacja.

>Opusc sie z tej Ameryki i osiadz wsrod ludzi.

Niby dlaczego? W Polsce nie mam z kim rozmawiac, bo nikt sie nei
zajmuje tym co robie. Mimo ze to do robie jest podstawa dzialania
dosyc duzej firmy. Poczekam jeszcze ze 100 lat az polska
"dociagnie"...

>Odnosze wrazenie, ze bronisz sie atakiem, chociaz nikt Ciebie nie
>atakuje...

Nikt mnie nie atakuje, ale jakos nie moge siedziec cicho gdy opowiada
sie publicznie bzdury...

A.L.

do góry

On Fri, 16 Dec 2011 08:24:20 -0800 (PST), Andrzej Jarzabek
<a...@g...com> wrote:

>On Dec 16, 12:22 am, A.L. <l...@a...com> wrote:
>> On Sat, 10 Dec 2011 23:36:51 +0000, Andrzej Jarzabek
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> <a...@g...com> wrote:
>> >On 10/12/2011 22:24, Roman W wrote:
>> >> On Dec 10, 9:34 pm, Andrzej Jarzabek<a...@g...com>
>>
>> >>> Jest trochę taki problem, że jak dokumentacja opisuje rzeczy niezgodne z
>> >>> faktyczną rzeczywistością, to się na niej czas traci dwa razy: raz, jak
>> >>> się ją pisze, drugi raz, jak się próbuje z niej skorzystać.
>>
>> >> Z regulay mozna wyodrebnic "rdzen" funkcjonalnosci, ktory sie raczej
>> >> nie zmieni, i przynajmniej ten udokumentowac.
>>
>> >Niewątpliwie, jednak nie zawsze to jest potrzebne.
>>
>> >Oczywiście, że wiele rzeczy dokumentować trzeba. Dla produktu musi
>> >powstać dokumentacja dla użytkownika końcowego, biblioteki czy inne
>> >komponenty powinny mieć udokumentowane API, a wszystkie decyzje,
>> >ustalenia i wnioski dotyczące funkcjonalności powinny być dokumentowane
>> >na bieżąco. I przecież w Agile się tego nie kwestionuje. Przede
>> >wszystkim odrzuca się tworzenie dokumentów, na podstawwie których
>> >tworzony jest program: dokumentacji wymagań i "dokumentu projektowego"
>> >czyli opisania całości struktury i jednostek kodu przed rozpoczęciem
>> >implementacji. W dalszej kolejności odrzuca się w ogóle potrzebę
>> >utrzymywania dokumentacji projektu kodu, nawet jeśli nie jest tworzony z
>> >góry.
>>
>> Zwlaszcza dobrze sie to sprawdza przy pisaniu oprogramowania do
>> sterowania statecznikami poziomymi samolotu F-16, albo zeby byc blizej
>> ziemii, sterowania kolumna destylacyjna w Pertochemii Plockiej. Dobrze
>> tez taka metode zatosowac przy pisaniu oprogramwoania stuerujacego
>> kompresorami gazociagu magistralnego Jaroslaw-Wloclawek. Nie mowiac o
>> zwyklym, prostym komputerku sterujacym silnikiem samochodowym
>
>Być może, nie mam żadnych danych na ten temat.
>
>> Cale wasze doswiadczenie, Panowie, pochodzi z "pierdykniecia bazki
>> danych szlauchow i kaloszy dla Miejskiego Przedsiebiorstwa
>> Kanalizacyjnego". Software bywa ze obsluguje inne problemy tez. Duzo
>> bardziej skomplikowane. I takie ze jak sie pusci buga, to cos moze
>> wybuchnac albo ktos moze zostac zabity
>
>No też dlatego w wielu metodologiach agile stosuje się skuteczne
>metody redukcji ilości bugów - znacznie bardziej skuteczne, niż
>dokumentacja. Bo jeśli dokumentacja opisuje takie zachowanie programu,
>przy którym nic nie wybucha i nikogo nie zabija, a sam program
>zachowuje się inaczej, i w związku z tym wybucha i zabija, to dla
>zabitych jednak jest niewielką pociechą, że w dokumencie było wszystko
>OK.

No tak. A to JAK sie steruje kolumna destylacyjna to oczywiscie
wymysla "Agile programmers" czy "extreme programmers". Ssac palec albo
patrzac w sufit.

ja pracuje w projekcie sterowania przeplywem materialow, produktow i
finansow w dosyc duzej firmie globalnej, obecnej takze w Polsce.
Dokumentacja "wymagan projektowych" (requirements) ma ponad 3 tysiace
stron; kazdy rozdzial zakonczony jest szczegolowum opisem "acceptance
test. Oczywiscie, "agile programmers" taka dokumentacja jest w ogole
nie potzrebna. Pierdykna se bazke danych. Bo pewnie uzytkownik i tak
nie wie co mu jest potzrebne.

A.L.

do góry

Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał w
wiadomości grup
dyskusyjnych:a72d9c2d-94c5-400a-a252-c757e3d38ea7@e2
g2000vbb.googlegroups.com...
> A ponieważ jest jedynym człowiekiem na Ziemi, który się zna na
> temacie, to należy go nakłonić do jak najszybszego spisania jak
> największego kawałka swojej wiedzy.

Tak, takie rzeczy też się robi - i potem te spisane kawałki to się nazywa
nawet "książki" czy jakoś tak.

do góry

On Dec 16, 4:24 pm, Andrzej Jarzabek <a...@g...com>
wrote:
> On Dec 16, 12:22 am, A.L. <l...@a...com> wrote:
>
>
>
>
>
>
>
>
>
> > On Sat, 10 Dec 2011 23:36:51 +0000, Andrzej Jarzabek
>
> > <a...@g...com> wrote:
> > >On 10/12/2011 22:24, Roman W wrote:
> > >> On Dec 10, 9:34 pm, Andrzej Jarzabek<a...@g...com>
>
> > >>> Jest trochę taki problem, że jak dokumentacja opisuje rzeczy niezgodne z
> > >>> faktyczną rzeczywistością, to się na niej czas traci dwa razy: raz, jak
> > >>> się ją pisze, drugi raz, jak się próbuje z niej skorzystać.
>
> > >> Z regulay mozna wyodrebnic "rdzen" funkcjonalnosci, ktory sie raczej
> > >> nie zmieni, i przynajmniej ten udokumentowac.
>
> > >Niewątpliwie, jednak nie zawsze to jest potrzebne.
>
> > >Oczywiście, że wiele rzeczy dokumentować trzeba. Dla produktu musi
> > >powstać dokumentacja dla użytkownika końcowego, biblioteki czy inne
> > >komponenty powinny mieć udokumentowane API, a wszystkie decyzje,
> > >ustalenia i wnioski dotyczące funkcjonalności powinny być dokumentowane
> > >na bieżąco. I przecież w Agile się tego nie kwestionuje. Przede
> > >wszystkim odrzuca się tworzenie dokumentów, na podstawwie których
> > >tworzony jest program: dokumentacji wymagań i "dokumentu projektowego"
> > >czyli opisania całości struktury i jednostek kodu przed rozpoczęciem
> > >implementacji. W dalszej kolejności odrzuca się w ogóle potrzebę
> > >utrzymywania dokumentacji projektu kodu, nawet jeśli nie jest tworzony z
> > >góry.
>
> > Zwlaszcza dobrze sie to sprawdza przy pisaniu oprogramowania do
> > sterowania statecznikami poziomymi samolotu F-16, albo zeby byc blizej
> > ziemii, sterowania kolumna destylacyjna w Pertochemii Plockiej. Dobrze
> > tez taka metode zatosowac przy pisaniu oprogramwoania stuerujacego
> > kompresorami gazociagu magistralnego Jaroslaw-Wloclawek. Nie mowiac o
> > zwyklym, prostym komputerku sterujacym silnikiem samochodowym
>
> Być może, nie mam żadnych danych na ten temat.
>
> > Cale wasze doswiadczenie, Panowie, pochodzi z "pierdykniecia bazki
> > danych szlauchow i kaloszy dla Miejskiego Przedsiebiorstwa
> > Kanalizacyjnego". Software bywa ze obsluguje inne problemy tez. Duzo
> > bardziej skomplikowane. I takie ze jak sie pusci buga, to cos moze
> > wybuchnac albo ktos moze zostac zabity
>
> No też dlatego w wielu metodologiach agile stosuje się skuteczne
> metody redukcji ilości bugów - znacznie bardziej skuteczne, niż
> dokumentacja. Bo jeśli dokumentacja opisuje takie zachowanie programu,
> przy którym nic nie wybucha i nikogo nie zabija, a sam program
> zachowuje się inaczej, i w związku z tym wybucha i zabija, to dla
> zabitych jednak jest niewielką pociechą, że w dokumencie było wszystko
> OK.

To moze opisz zastosowanie metody Agile do oprogramowania, dla
przykladu, sterujacego respiratorem na OIOM.

RW

do góry

On 16/12/2011 17:10, A.L. wrote:
>
> No tak. A to JAK sie steruje kolumna destylacyjna to oczywiscie
> wymysla "Agile programmers" czy "extreme programmers". Ssac palec albo
> patrzac w sufit.

Nie. W szczególności np. w extreme programming jest wprost powiedziane,
że wymyśla to ktoś nie będący programistą. Jeśli kolega kiedyś zechce
dowiedzieć się czegoś o tym, proponuję na początek zapoznać się z
hasłami "on-site customer" (lub "customer representative") i "product
owner". Oczywiście jeśli kolega nadal woli się wypowiadać w tematach, o
których nie ma pojęcia, to będzie to niekonieczne - w takiej sytuacji
oczywiście gratuluję dobrego samopoczucia.

> ja pracuje w projekcie sterowania przeplywem materialow, produktow i
> finansow w dosyc duzej firmie globalnej, obecnej takze w Polsce.

Rozumiem, że są to materiały i produkty, które przy nieprawidłowym
przepływie mogą wybuchnąć i/lub kogoś zabić?

> Dokumentacja "wymagan projektowych" (requirements) ma ponad 3 tysiace
> stron; kazdy rozdzial zakonczony jest szczegolowum opisem "acceptance
> test. Oczywiscie, "agile programmers" taka dokumentacja jest w ogole
> nie potzrebna. Pierdykna se bazke danych. Bo pewnie uzytkownik i tak
> nie wie co mu jest potzrebne.

_Programistom_ nie jest potrzebna. Ale metodologie agile (te
funkcjonujące w rzeczywistym świecie, nie w wyobraźni kolegi) z reguły
nie zakładają, że oprogramowanie jest tworzone wyłącznie przez programistów.

do góry

On 16/12/2011 20:50, slawek wrote:
>
> Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał w
> wiadomości grup
> dyskusyjnych:a72d9c2d-94c5-400a-a252-c757e3d38ea7@e2
g2000vbb.googlegroups.com...
>
>> A ponieważ jest jedynym człowiekiem na Ziemi, który się zna na
>> temacie, to należy go nakłonić do jak najszybszego spisania jak
>> największego kawałka swojej wiedzy.
>
> Tak, takie rzeczy też się robi - i potem te spisane kawałki to się
> nazywa nawet "książki" czy jakoś tak.

No i oczywiście pisanie książek jest chwalebnym zajęciem. Ale agile
raczej dotyczy tworzenia programów komputerowych.

do góry

On 16/12/2011 21:09, Roman W wrote:
> On Dec 16, 4:24 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>>
>> No też dlatego w wielu metodologiach agile stosuje się skuteczne
>> metody redukcji ilości bugów - znacznie bardziej skuteczne, niż
>> dokumentacja. Bo jeśli dokumentacja opisuje takie zachowanie programu,
>> przy którym nic nie wybucha i nikogo nie zabija, a sam program
>> zachowuje się inaczej, i w związku z tym wybucha i zabija, to dla
>> zabitych jednak jest niewielką pociechą, że w dokumencie było wszystko
>> OK.
>
> To moze opisz zastosowanie metody Agile do oprogramowania, dla
> przykladu, sterujacego respiratorem na OIOM.

Zależy od konkretnej metody, ale w skrócie to będzie polegać na tym, że
zaczyna się od zgromadzenia zespołu złożonego z programistów, kolesi
wiedzących bardzo dużo o respiratorach, oraz kolesia, który wie, co ma
robić program sterujący respiratorem i jest władny podejmować decyzje co
do tego, jak ten konkretny program ma działać. Całą resztę robi się
normalnie zgodnie z przyjętą metodologią, można oczywiście napisać o tym
książkę, ale już ktoś to zrobił. Kwestie specyficzne dla akurat
sterowania respiratorem zależą od tego, co powiedzą kolesie, którzy się
znają na respiratorach - ja akurat nie jestem w stanie tego przewidzieć,
bo sam się na respiratorach nie znam.

do góry

On Sat, 17 Dec 2011 01:20:59 +0000, Andrzej Jarzabek
<a...@g...com> wrote:

>On 16/12/2011 17:10, A.L. wrote:
>>
>> No tak. A to JAK sie steruje kolumna destylacyjna to oczywiscie
>> wymysla "Agile programmers" czy "extreme programmers". Ssac palec albo
>> patrzac w sufit.
>
>Nie. W szczególności np. w extreme programming jest wprost powiedziane,
>że wymyśla to ktoś nie będący programistą. Jeśli kolega kiedyś zechce
>dowiedzieć się czegoś o tym, proponuję na początek zapoznać się z
>hasłami "on-site customer" (lub "customer representative") i "product
>owner". Oczywiście jeśli kolega nadal woli się wypowiadać w tematach, o
>których nie ma pojęcia, to będzie to niekonieczne - w takiej sytuacji
>oczywiście gratuluję dobrego samopoczucia.
>
>> ja pracuje w projekcie sterowania przeplywem materialow, produktow i
>> finansow w dosyc duzej firmie globalnej, obecnej takze w Polsce.
>
>Rozumiem, że są to materiały i produkty, które przy nieprawidłowym
>przepływie mogą wybuchnąć i/lub kogoś zabić?
>
>> Dokumentacja "wymagan projektowych" (requirements) ma ponad 3 tysiace
>> stron; kazdy rozdzial zakonczony jest szczegolowum opisem "acceptance
>> test. Oczywiscie, "agile programmers" taka dokumentacja jest w ogole
>> nie potzrebna. Pierdykna se bazke danych. Bo pewnie uzytkownik i tak
>> nie wie co mu jest potzrebne.
>
>_Programistom_ nie jest potrzebna.

I co?.. .Ta dokumentacja stoi na polce a programisci robia swoje? BEz
cztrania dokumentacji? I programuja na podsatwie objawinia Ducha
Swietego?...

A.L.

do góry