Dnia Fri, 16 Dec 2011 11:05:53 -0600, A.L. napisał(a):

> 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"...
Twoje slowa:
"ja pracuje w projekcie sterowania przeplywem materialow, produktow i
finansow w dosyc duzej firmie globalnej, obecnej takze w Polsce."

To masz w Polsce z kim rozmawiac, czy nie?

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

Cale wasze doswiadczenie, Panowie, pochodzi z "pierdykniecia bazki
danych szlauchow i kaloszy dla Miejskiego Przedsiebiorstwa
Kanalizacyjnego"

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