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.