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.