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.