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?

do góry

On Dec 16, 5:24 pm, Andrzej Jarzabek <a...@g...com>
wrote:

> No też dlatego w wielu metodologiach agile stosuje się skuteczne
> metody redukcji ilości bugów - znacznie bardziej skuteczne, niż
> dokumentacja.

Dokumentacja nie służy do redukcji ilości bugów, więc to, że jakieś
tam metody redukują tą ilość skuteczniej niż dokumentacja nie może
prowadzić do żadnych sensownych wniosków. W szczególności nie do
takich, że dokumentacji może nie być.

Twój sposób myślenia można porównać do czegoś takiego: istnieją
metody, które redukują zużycie paliwa w samochodzie znacznie
skuteczniej, niż mapa drogowa, więc hip-hip-hura wypieprzamy z
samochodu wszystkie mapy.

Dwa najlepsze projekty jakie w życiu zrobiłem powstały najpierw na
papierze, od którego do implementacji była prosta ciągła linia
(ciągłość tej linii to również doświadczenie programisty, więc nie
znaczy to, że na papierze była każda linijka kodu - ale było
wystarczająco dużo, żeby przy implementacji nie było już żadnych
pytań).
Nie wiem, na ile jakość tych projektów była związana z faktem
istnienia tej dokumentacji, ale rezygnację z tego etapu to pomysł z
kategorii "Świat według Kiepskich".

W tym roku na pewnej konferencji w ramach anegdoty słyszałem coś
takiego:

"Agile: hit your customers in the head with unfinished versions until
they surrender."

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On 12/17/2011 02:32 AM, Andrzej Jarzabek wrote:
> On 16/12/2011 21:09, Roman W wrote:
>> On Dec 16, 4:24 pm, Andrzej Jarzabek<a...@g...com>
>> wrote:
>>>
>>> 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.
>>
>> To moze opisz zastosowanie metody Agile do oprogramowania, dla
>> przykladu, sterujacego respiratorem na OIOM.
>
> Zależy od konkretnej metody, ale w skrócie to będzie polegać na tym, że
> zaczyna się od zgromadzenia zespołu ...

... i wyboru narzędzi oraz odpowiedniej metodologii ...

Edek

do góry

On 17/12/2011 03:07, A.L. wrote:
> On Sat, 17 Dec 2011 01:20:59 +0000, Andrzej Jarzabek
> <a...@g...com> wrote:
[...]
>> Nie. W szczególności np. w extreme programming jest wprost powiedziane,
>> że wymyśla to ktoś nie będący programistą. Jeśli kolega kiedyś zechce
>> dowiedzieć się czegoś o tym, proponuję na początek zapoznać się z
>> hasłami "on-site customer" (lub "customer representative") i "product
>> owner". Oczywiście jeśli kolega nadal woli się wypowiadać w tematach, o
>> których nie ma pojęcia, to będzie to niekonieczne - w takiej sytuacji
[...]
> I co?.. .Ta dokumentacja stoi na polce a programisci robia swoje? BEz
> cztrania dokumentacji? I programuja na podsatwie objawinia Ducha
> Swietego?...

Nie potrzeba objawienia Ducha Świętego, skoro są product owner i on-site
customer.

do góry

Dnia Sat, 17 Dec 2011 06:27:47 +0100, Jacek napisał(a):
> 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?

Drogi kolego,
AL nie musi znać nikogo, to wszyscy muszą "znać" A.L,
a i wtedy nie są godni mu klawiatury trzymać.
A tak poważnie, to radziłbym odpuścić sobie; to dość
oczytany troll, ale jednak troll.

Pozdrawiam,
Waldek

do góry

On 17/12/2011 08:53, Maciej Sobczak wrote:
> On Dec 16, 5:24 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>
>> No też dlatego w wielu metodologiach agile stosuje się skuteczne
>> metody redukcji ilości bugów - znacznie bardziej skuteczne, niż
>> dokumentacja.
>
> Dokumentacja nie służy do redukcji ilości bugów, więc to, że jakieś

Nie zgodzę się, ale nie będę się kłócił. Zakładając, że masz rację, tym
bardziej bzdurny jest argument, że program do sterowania statecznikiem
musi powstawać na podstawie dokumentacji, bo jak będzie miał bugi, to
może kogoś zabić.

> Twój sposób myślenia można porównać do czegoś takiego: istnieją
> metody, które redukują zużycie paliwa w samochodzie znacznie
> skuteczniej, niż mapa drogowa, więc hip-hip-hura wypieprzamy z
> samochodu wszystkie mapy.

Na takiej zasadzie można powiedzieć, że da się zrezygnować z mapy
drogowej, skoro jest GPS.

> Dwa najlepsze projekty jakie w życiu zrobiłem powstały najpierw na
> papierze, od którego do implementacji była prosta ciągła linia
> (ciągłość tej linii to również doświadczenie programisty, więc nie
> znaczy to, że na papierze była każda linijka kodu - ale było
> wystarczająco dużo, żeby przy implementacji nie było już żadnych
> pytań).

A ja z kolei uczestniczyłem w kilku projektach, gdzie tworzenie
napodstawie dokumentacji powodowało opóźnienia, funkcjonalność
niedopasowaną do rzeczywistych potrzeb, a nawet bugi.

> Nie wiem, na ile jakość tych projektów była związana z faktem
> istnienia tej dokumentacji, ale rezygnację z tego etapu to pomysł z
> kategorii "Świat według Kiepskich".

Myślenie, że skoro coś ci się dobrze sprawdziło, to inne rozwiązania nie
mogą się sprawdzać równie dobrze albo nawet lepiej, to wnioskowane z
kategorii "Świat według Kiepskich".

> W tym roku na pewnej konferencji w ramach anegdoty słyszałem coś
> takiego:
>
> "Agile: hit your customers in the head with unfinished versions until
> they surrender."

To się nazywa "demo". I dlaczego niby bicie po głowie niedokończoną
wersją jest lepsze od bicia dokumentacją wymagań? W projekcie A.L. ten
dokument ma dziewięćset ileśtam stron - oberwanie czymś takim w głowę
może być nieprzyjemne.

do góry

Waldek M. <w...@l...localdomain> napisał(a):

> Dnia Sat, 17 Dec 2011 06:27:47 +0100, Jacek napisał(a):
> > 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?
>
> Drogi kolego,
> AL nie musi znać nikogo, to wszyscy muszą "znać" A.L,
> a i wtedy nie są godni mu klawiatury trzymać.
> A tak poważnie, to radziłbym odpuścić sobie; to dość
> oczytany troll, ale jednak troll.
>

powiedział tylko nie zauwazyl (jak zawsze w przypadku
od trollowych przezywaczy) ze pojecie trola bardziej
podchodzi pod niemerytoryczne wstawki dokladnie takiego
rodzaju ;-)

innymi slowy 'troll to czlowiek wyzywajacy innych od
trolli' -> (to taka zawijajaca sie strzalka) latwo ich
poznac po tym ze nazywaja innych trollami (to taka
ichnia zabawa)



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

> powiedział tylko nie zauwazyl (jak zawsze w przypadku
> od trollowych przezywaczy) ze pojecie trola bardziej
> podchodzi pod niemerytoryczne wstawki dokladnie takiego
> rodzaju ;-)

> innymi slowy 'troll to czlowiek wyzywajacy innych od
> trolli' -> (to taka zawijajaca sie strzalka) latwo ich
> poznac po tym ze nazywaja innych trollami (to taka
> ichnia zabawa)

choć mi osobiście okreslenie troll wogole nie
podchodzi jest ono niesprecyzowane i dlatego
wlasnie mz podchodzi od trollowym przezywaczom

czasami bardziej odpowiada mi natomiast
okreslenie 'mówiący koń'


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On Dec 17, 9:56 am, Andrzej Jarzabek <a...@g...com>
wrote:

> To się nazywa "demo". I dlaczego niby bicie po głowie niedokończoną
> wersją jest lepsze od bicia dokumentacją wymagań? W projekcie A.L. ten
> dokument ma dziewięćset ileśtam stron - oberwanie czymś takim w głowę
> może być nieprzyjemne.

To wracajac do tematu respiratora, jak wyglada "wersja demo" w takim
wypadku? Testuja wersje alpha kodu na jednym z programistow?

RW

do góry

On Dec 17, 8:53 am, Maciej Sobczak <s...@g...com> wrote:
> Dokumentacja nie służy do redukcji ilości bugów, więc to, że jakieś
> tam metody redukują tą ilość skuteczniej niż dokumentacja nie może
> prowadzić do żadnych sensownych wniosków. W szczególności nie do
> takich, że dokumentacji może nie być.

Ja bym raczej powiedzial na chlopski rozum, ze dokumentacja definiuje
co jest bugiem, a co nie. Jak programista Agile ma eliminowac bugi,
kiedy nie wie, co jest prawidlowym zachowaniem budowanego systemu? "On-
site customer representative" mu o tym za kazdym razem powie? Przeciez
to wiaze programiscie rece -- z kazda zmiana w kodzie musi leciec do
"on site customer representative", bo a nuz zmiana ktora chce
wprowadzic w kodzie zmieni zachowanie systemu w sposob ktory jest
nieakceptowalny dla OSCR - a programista sam tego sprawdzic nie ma
gdzie, bo czniamy dokumentacje.

RW

do góry