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.