W dniu 2013-07-19 03:14, A.L. pisze:
> On Fri, 19 Jul 2013 01:38:36 +0100, Roman W
> <b...@g...pl> wrote:
>
>> On Thu, 18 Jul 2013 08:09:35 -0500, A.L. <a...@a...com> wrote:
>>> Wszsystkie "niowoczesne methodologie" typu Agile, Extreme
>> Programming
>>> itede maja jeden glowny cel: dupochron dla firmy robiacej soft.
>>
>> No więc ja pracuję w firmie ktora buduje cos czego nikt inny przedtem
>> nie zrobil, i wymagania wobec systemu zmieniają sie praktycznie co
>> tydzień w miarę jak uczymy sie nowych rzeczy o tym czego potrzeba
>> klientom, czego klienci myślą ze im potrzeba i jakie sa warunki
>> przyrodnicze w których to ma byc zrealizowane. I Agile jest w
>> zasadzie jedynym rozwiązaniem: żeby przeżyć i osiągnąć swoj cel,
>> firma nie moze reagować na zmianę wymagań i uwarunkowań z
>> parotygodniowym opóźnieniem potrzebnym na uzgodnienie aneksu do
>> umowy.
>>
>
> Jezeli macie klientow ktorzy sa gotowi placic za wasza nauke i
> pomylki, to nic tylko pogratulowac. Ale obawiam sie ze to raczej
> wyjatek niz regula

A może wręcz przeciwnie? Może wygrywają klienci, którzy gotowi są
zaryzykować kasę na użyteczny produkt, którego konkurencja jeszcze nie
ma?

--
Paweł Kierski
n...@p...net

do góry

On Fri, 19 Jul 2013 14:41:00 +0200, Paweł Kierski <n...@p...net>
wrote:

>W dniu 2013-07-19 03:14, A.L. pisze:
>> On Fri, 19 Jul 2013 01:38:36 +0100, Roman W
>> <b...@g...pl> wrote:
>>
>>> On Thu, 18 Jul 2013 08:09:35 -0500, A.L. <a...@a...com> wrote:
>>>> Wszsystkie "niowoczesne methodologie" typu Agile, Extreme
>>> Programming
>>>> itede maja jeden glowny cel: dupochron dla firmy robiacej soft.
>>>
>>> No więc ja pracuję w firmie ktora buduje cos czego nikt inny przedtem
>>> nie zrobil, i wymagania wobec systemu zmieniają sie praktycznie co
>>> tydzień w miarę jak uczymy sie nowych rzeczy o tym czego potrzeba
>>> klientom, czego klienci myślą ze im potrzeba i jakie sa warunki
>>> przyrodnicze w których to ma byc zrealizowane. I Agile jest w
>>> zasadzie jedynym rozwiązaniem: żeby przeżyć i osiągnąć swoj cel,
>>> firma nie moze reagować na zmianę wymagań i uwarunkowań z
>>> parotygodniowym opóźnieniem potrzebnym na uzgodnienie aneksu do
>>> umowy.
>>>
>>
>> Jezeli macie klientow ktorzy sa gotowi placic za wasza nauke i
>> pomylki, to nic tylko pogratulowac. Ale obawiam sie ze to raczej
>> wyjatek niz regula
>
>A może wręcz przeciwnie? Może wygrywają klienci, którzy gotowi są
>zaryzykować kasę na użyteczny produkt, którego konkurencja jeszcze nie
>ma?

Byc moze. Ale ja jeszcze takich nie widzialem

A.L.

do góry

On Thu, 18 Jul 2013 22:08:50 -0700 (PDT), Adam Klobukowski
<a...@g...com> wrote:

>On Thursday, 18 July 2013 15:09:35 UTC+2, A. L. wrote:
>> On Thu, 18 Jul 2013 04:47:22 -0700 (PDT), Adam Klobukowski
>>
>> <a...@g...com> wrote:
>>
>> >Nigdy nie napisałem że metodologia Agile jest najlepsza.
>>
>> >Tu nie chodzi o to że programiści źle zrozumieli. Zasadą metodyk Agile jest to że
wymagania są płynne i mogą się zmienić. Taka zmiana nie jest czymś negatywnym.
>>
>> No, ale to przeciez od zawsze bylo. Pisal sie ansksy do omowy i tak
>> dalej. Ale wszystko zalatwialo sie porzadnie a nei an "urrraaa"
>
>Od zawsze? Zmiana wymagań w klasyczynych metodach wytwarzania oprogramowania to
zawsze problem, bo założeniem jest że wymagania nie powinny się zmieniać. W Agile
nigdy, bo założenie jest że wymagania się zmienią.
>

Magia, magia, Panie Dzieju! W agile czas pracy programistow nic nie
kosztuje, a zmiany wprowadzaja sie w zerowym czasie, Magia, no po
prostu magia!!!

A.L.

do góry

On Fri, 19 Jul 2013 10:36:07 +0000 (UTC), "Stachu 'Dozzie' K."
<d...@g...eat.some.screws.spammer.invalid> wrote:

>On 2013-07-19, slawek <h...@s...pl> wrote:
>> Użytkownik "Adam Klobukowski" napisał w wiadomości grup
>> dyskusyjnych:2be9313c-d656-4eed-b10a-0d32a7b43781@go
oglegroups.com...
>>
>>>Od zawsze? Zmiana wymagań w klasyczynych metodach wytwarzania
>>>oprogramowania to zawsze problem, bo założeniem jest że wymagania nie
>>>powinny się zmieniać. W Agile nigdy, bo >założenie jest że wymagania się
>>>zmienią.
>>
>> Czyli uważasz, że "koszt zmiany w Agile jest zerowy"?
>
>Nie widzę z czego taki wniosek wyciągnąłeś. Stosując wprost ten tok
>rozumowania: jeśli musisz jeść, to znaczy że jedzenie jest darmowe.
>
>W klasycznych metodach zmiana wymaga wynegocjowania załącznika do umowy,
>czyli trzeba zaprząc proces biznesowy, co *zawsze* zauważalnie podnosi
>koszt operacji[*].
>
>Agile zakłada, że skoro zmiany pojawiają się i pojawiać się będą, to
>trzeba je uczynić *tańszymi* niż do tej pory -- najprościej przez
>usunięcie procesu biznesowego z drogi.

Co to znaczy "usuniecie procesu biznesowego z drogi"?... Znaczy, praca
programisty nad zmianami nie kosztuje ani pieneidzy ani czasu?

A.L.

do góry

On Fri, 19 Jul 2013 08:45:08 +0200, Sebastian Biały
<h...@p...onet.pl> wrote:

>On 2013-07-19 03:08, A.L. wrote:
>>> wymagane, są podane jako przykład "dobrych" komentarzy. Jako zły rodzaj
>>> komentarza było pisanie kto napisał przy poszczególnych kawałkach kodu,
>>> przykład z książki "Added by Rick". No więc ja się zgadzam, że takie
>>> komentarze są bez sensu.
>> Mam watpliwosci. Kod jes twspolna wlasnoscia. Kazdy mzoe zrobic
>> zmiany. Jezeli zrobil zmiany, powinien te zmiany udokumentowac. KTO i
>> CO. Inaczej zrobi sie niekontrolowany burdel
>
>Tym burdelem zarządza skutecznie system kontroli wersji powiązany z
>jakąs bazą danych bugs i bazą danych testów. Zrzucanie tego zadania na
>programistów kończy się tak jak pliki nagłówkowe do mikrokontrolerów
>Atmela które są perfekcyjnym anty-przykładem. Co chwile inna permutacja
>fixów, wersji, numerków często identycznych, nieaktualnych komentarzy i
>ad-hoc poprawek która wynika z założenia że historia pliku przechowywana
>jest w nim i zarzadzana przez ludzi. Wyszła sieczka.
>
>W dużym kodzie jedyne co wzbudza zaufanie to automat CVS.

NIE.

Nie chce mi sie uzasadniac dlaczego, bo jestem juz zmeczony poziomem
nonsensu generowanego pzrez "specjalistow".

A.L.

do góry

On Fri, 19 Jul 2013 12:49:58 +0200, Sebastian Biały
<h...@p...onet.pl> wrote:

>On 2013-07-19 12:07, slawek wrote:
>>> Oczywiście że nie. Przeciez to może być fałszywy podpis. Nie zlicze
>>> ile razy w kodzie widziałem takie gówno:
>>> position -= 1 // move forward one step
>> To nie jest bez sensu - pojęcie "forward" niekoniecznie musi oznaczać
>> dodawanie (choć to mało intuicyjne).
>
>Tutaj bylo źle. Komentarz jak podpis pod obrazem wprowadza w błąd. I to
>trywializm do znalezienia w 30 sek. Teraz pomyśl co brak synchronizacji
>tego typu powoduje w bardziej skomplikowanych algorytmach. Widuje bardzo
>czesto rózne rzeczy takie jak return true; // failed ale też takie gdzie
>ktoś pisze elaborat na dwa ekrany po czym okazuje się że dziala zupełnie
>inaczej bo po drodze było kilku poprawiaczy.
>
>Dla mnie jedynym prawidłowym komentarzem jak coś działa w dynamicznie
>pisanym sofcie jest kod i unit test do niego.

Uhum. Jak kod jest na 10 linijek.

Kompletny nonsens

A.L.

do góry

On Friday, 19 July 2013 15:54:30 UTC+2, A. L. wrote:
> On Thu, 18 Jul 2013 22:08:50 -0700 (PDT), Adam Klobukowski
>
> <a...@g...com> wrote:
>
> >On Thursday, 18 July 2013 15:09:35 UTC+2, A. L. wrote:
>
> >> On Thu, 18 Jul 2013 04:47:22 -0700 (PDT), Adam Klobukowski
>
> >>
> >> <a...@g...com> wrote:
>
> >>
> >> >Nigdy nie napisa�em �e metodologia Agile jest najlepsza.
> >>
>
> >> >Tu nie chodzi o to �e programi�ci �le zrozumieli. Zasad� metodyk Agile
jest to �e wymagania s� p�ynne i mog� si� zmieni�. Taka zmiana nie jest
czymďż˝ negatywnym.
>
> >>
> >> No, ale to przeciez od zawsze bylo. Pisal sie ansksy do omowy i tak
> >> dalej. Ale wszystko zalatwialo sie porzadnie a nei an "urrraaa"
> >
>
> >Od zawsze? Zmiana wymagaďż˝ w klasyczynych metodach wytwarzania oprogramowania to
zawsze problem, bo za�o�eniem jest �e wymagania nie powinny si� zmienia�. W
Agile nigdy, bo za�o�enie jest �e wymagania si� zmieni�.
>
>
> Magia, magia, Panie Dzieju! W agile czas pracy programistow nic nie
> kosztuje, a zmiany wprowadzaja sie w zerowym czasie, Magia, no po
> prostu magia!!!

Uprzejmie proszę i wskazać gdzie napisałem że przy użyciu metodyki Agile czas pracy
programistów nic nie kosztuje a zmiany wprowadzają się same.

Agile to procesy nastawione na to że zmiany będą. Klasyczne metody to procesy
nastawione na to że zmian nie będzie. Koszty zmian będą prawi zawsze, zmiany są
praktycznie zawsze. Jak myślisz, jaki proces będzie oszczędniejszy, zoptymalizowany
pod ewentualne zmiany, czy taki który zmian nie przewiduje?

AdamK

do góry

On 2013-07-19 15:59, A.L. wrote:
>> Dla mnie jedynym prawidłowym komentarzem jak coś działa w dynamicznie
>> pisanym sofcie jest kod i unit test do niego.
> Uhum. Jak kod jest na 10 linijek.

Kod może być i na tysiące linijek o ile jego działanie opisane jest
testami. I który w przypadku watpliwości mogę przedebugować. Bo testy to
jedyna *pewna* dokumentacja projektu, szczególnie z wesołych metodyk
pisania byle jak.

do góry

On 2013-07-19, A.L <a...@a...com> wrote:
> On Fri, 19 Jul 2013 10:36:07 +0000 (UTC), "Stachu 'Dozzie' K."
><d...@g...eat.some.screws.spammer.invalid> wrote:
>
>>On 2013-07-19, slawek <h...@s...pl> wrote:
>>> Użytkownik "Adam Klobukowski" napisał w wiadomości grup
>>> dyskusyjnych:2be9313c-d656-4eed-b10a-0d32a7b43781@go
oglegroups.com...
>>>
>>>>Od zawsze? Zmiana wymagań w klasyczynych metodach wytwarzania
>>>>oprogramowania to zawsze problem, bo założeniem jest że wymagania nie
>>>>powinny się zmieniać. W Agile nigdy, bo >założenie jest że wymagania się
>>>>zmienią.
>>>
>>> Czyli uważasz, że "koszt zmiany w Agile jest zerowy"?
>>
>>Nie widzę z czego taki wniosek wyciągnąłeś. Stosując wprost ten tok
>>rozumowania: jeśli musisz jeść, to znaczy że jedzenie jest darmowe.
>>
>>W klasycznych metodach zmiana wymaga wynegocjowania załącznika do umowy,
>>czyli trzeba zaprząc proces biznesowy, co *zawsze* zauważalnie podnosi
>>koszt operacji[*].
>>
>>Agile zakłada, że skoro zmiany pojawiają się i pojawiać się będą, to
>>trzeba je uczynić *tańszymi* niż do tej pory -- najprościej przez
>>usunięcie procesu biznesowego z drogi.
>
> Co to znaczy "usuniecie procesu biznesowego z drogi"?... Znaczy, praca
> programisty nad zmianami nie kosztuje ani pieneidzy ani czasu?

Najpierw myśl, potem pytaj i komentuj. Skąd wytrzasnąłeś pomysł, że
*nie kosztuje*? Bo nie z powyższej wypowiedzi.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2013-07-19, A.L <a...@a...com> wrote:
>>> Jezeli macie klientow ktorzy sa gotowi placic za wasza nauke i
>>> pomylki, to nic tylko pogratulowac. Ale obawiam sie ze to raczej
>>> wyjatek niz regula
>>
>>A może wręcz przeciwnie? Może wygrywają klienci, którzy gotowi są
>>zaryzykować kasę na użyteczny produkt, którego konkurencja jeszcze nie
>>ma?
>
> Byc moze. Ale ja jeszcze takich nie widzialem

Bo widzisz dość wąski wycinek gospodarki (i pod względem działalności,
i pod względem rozmiaru instytucji). Sam niedawno opisałeś, z kim
przez ostatnie paręnaście lat współpracowałeś.

--
Secunia non olet.
Stanislaw Klekot

do góry