Witam,

Czy istnieje jakakolwiek grupa dyskusyjna
o Agile w polskim Usenet?
Serwer z którego korzystam nic takiego nie listuje.

Pozdrawiam,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org

do góry

W dniu 2013-07-12 11:39, Mateusz Łoskot pisze:
> Witam,
>
> Czy istnieje jakakolwiek grupa dyskusyjna
> o Agile w polskim Usenet?
> Serwer z którego korzystam nic takiego nie listuje.

Chyba za młoda sprawa (szczególnie w Polsce), żeby się na Usenet
zapała...

Ale może grupa Agile Warsaw Cię zainteresuje?
http://agilewarsaw.com/
https://groups.google.com/forum/#!forum/agile-warsaw

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

do góry

On Fri, 12 Jul 2013 10:39:32 +0100, Mateusz ?oskot
<m...@l...net> wrote:

>Witam,
>
>Czy istnieje jakakolwiek grupa dyskusyjna
>o Agile w polskim Usenet?
>Serwer z którego korzystam nic takiego nie listuje.
>
>Pozdrawiam,

Czy to ta "metodologia" strwszczajaca sie do "code first, think
later"?...

A.L.

do góry

Użytkownik "A.L." napisał w wiadomości grup
dyskusyjnych:4jvvt8p4ef2l0gb9jogcapbodg39g686cp@4ax.
com...

>Czy to ta "metodologia" strwszczajaca sie do "code first, think
>later"?...
>
>A.L.

Nie do końca da się to tak streścić.

Ostatnio czytałem książkę pewnego dość znanego "agilistyka". Upierał się on,
że pisanie w kodzie źródłowym np. kto jest autorem i jakie są ograniczenia
licencyjne jest "fuj". Nie polimeryzuję z tym poglądem, po prostu w drodze
dedukcji z tej przesłanki wynikałoby że 99% kodu źródłowego jest "fuj".
Nawet a zwłaszcza ten "sweterkowy", z GPL.

Zaciekawiły mnie też testy: jak przetestować, że np. f(x,y) zwraca poprawne
wyniki? Dla przykładu takie dzielenie: 1/1, 2/1, 1/2, 0/1, 1/0, 0/0
wystarczy sprawdzić? Biorąc pod uwagę tylko 1E38 liczb (circa zakres
singli), mamy 1E76 wartości do sprawdzenia, co przy prędkości 1000
teraflopsów zajmie... trochę dłużej niż będzie istniał Wszechświat.
(Intel/CPU/Pentium/FDIV-bug)

Jest też ciekawe kto, przy zmianie specyfikacji zamówienia generowanej przez
kupującego program, płaci za ekstra wysiłek? Z podręczników Agilizmu wynika,
że to jest free (tj. płaci swoim czasem/zasobami firma softwareowa), ze
zdrowego rozsądku wynikałoby że ???

do góry

On Tuesday, 16 July 2013 19:51:09 UTC+2, slawek wrote:
> Zaciekawiły mnie też testy: jak przetestować, że np. f(x,y) zwraca poprawne
> wyniki? Dla przykładu takie dzielenie: 1/1, 2/1, 1/2, 0/1, 1/0, 0/0
> wystarczy sprawdzić? Biorąc pod uwagę tylko 1E38 liczb (circa zakres
> singli), mamy 1E76 wartości do sprawdzenia, co przy prędkości 1000
> teraflopsów zajmie... trochę dłużej niż będzie istniał Wszechświat.
> (Intel/CPU/Pentium/FDIV-bug)

Pierwsze testy powinny sprawdzać czy cokolwiek się liczy oraz warunki brzegowe. W
późniejszym okresie dodaje się testy na dane wejściowe które wygenerowały błędy.

> Jest też ciekawe kto, przy zmianie specyfikacji zamówienia generowanej przez
> kupującego program, płaci za ekstra wysiłek? Z podręczników Agilizmu wynika,
> że to jest free (tj. płaci swoim czasem/zasobami firma softwareowa), ze
> zdrowego rozsądku wynikałoby że ???

Metodologie Agile (bo jest ich wiele) zakładają że w projekcie, aktywnie bierze
udział reprezentant klienta. Jednocześnie krótkie okresy iteracji projektu powodują
dobrą widoczność zaawansowania. Zmianę wymagań można rozegrać na wiele sposobów, ale
podstawową zasadą Agile jest to że wymagania się zmieniają. W momencie zmiany,
reprezentant klienta dowiaduje się czy trzeba coś zmienić w już wykonanych elementach
i albo to zaakceptuje (i przez to dodatkowy budżet) albo nie. Nie mam w tym mowy aby
firma tworząca system robiła coś za darmo.

AdamK

do góry

On 16/07/2013 18:51, slawek wrote:
>
> Ostatnio czytałem książkę pewnego dość znanego "agilistyka". Upierał się
> on, że pisanie w kodzie źródłowym np. kto jest autorem i jakie są
> ograniczenia licencyjne jest "fuj". Nie polimeryzuję z tym poglądem, po
> prostu w drodze dedukcji z tej przesłanki wynikałoby że 99% kodu
> źródłowego jest "fuj". Nawet a zwłaszcza ten "sweterkowy", z GPL.

Kto tak napisał? I jak to argumentował?

W korpora

> Zaciekawiły mnie też testy: jak przetestować, że np. f(x,y) zwraca
> poprawne wyniki? Dla przykładu takie dzielenie: 1/1, 2/1, 1/2, 0/1, 1/0,
> 0/0 wystarczy sprawdzić? Biorąc pod uwagę tylko 1E38 liczb (circa zakres
> singli), mamy 1E76 wartości do sprawdzenia, co przy prędkości 1000
> teraflopsów zajmie... trochę dłużej niż będzie istniał Wszechświat.
> (Intel/CPU/Pentium/FDIV-bug)

Mylisz testowanie z formalną weryfikacją. Ideą testowania (tak w ogóle,
nie tylko w agile) jest to, że sprawdzenie działania programu na próbie
danych testowych zmniejsza prawdopodobieństwo błędnego działania.
Dopisując kolejne przypadki prawdopodobieństwo zmniejszasz coraz
bardziej, i dla konkretnego przypadku twoim zadaniem jest wykombinować,
jaki zestaw przypadków wybrać żeby uzyskać pożądaną równowagę między
prawdopodobieństwem wyłapania błędu a kosztem napisania i uruchamiania
testów.

Skoro piszesz o testowaniu funkcji, to być może masz na myśli unit
testing. Otóż unit testy to rodzaj tzw. white box testing, są pisane na
podstawie wiedzy jak wewnętrznie działa to, co jest testowane. W tym
przypadku jako programista piszący testy wiesz, jakiego algorytmu
będziesz używał do implementacji dzielenia i na tej podstawie możesz
wymyśleć przypadki, dla których istnieje największe ryzyko, że mogą nie
działać. Jeśli nie potrafisz wymyśleć takich przypadków, a ryzyko jest
nadal nieakceptowalne, to musisz się zastanowić nad innymi formami
weryfikacji, może inne rodzaje testów, może formalny dowód poprawności.
I w tym tak samo powinieneś policzyć koszty, bo jeśli wymagasz tak
wysokiego stopnia pewności, o jakim piszesz, to weryfikacja może być
bardzo kosztowna i może tego programu w ogóle się nie opłaca pisać.

> Jest też ciekawe kto, przy zmianie specyfikacji zamówienia generowanej
> przez kupującego program, płaci za ekstra wysiłek? Z podręczników
> Agilizmu wynika, że to jest free (tj. płaci swoim czasem/zasobami firma
> softwareowa), ze zdrowego rozsądku wynikałoby że ???

Których podręczników? W tych podręcznikach, które znam, zaleca się
stosowanie kontraktu typu time&materials, wtedy nie ma tego problemu -
klient chce zmiany specyfikacji, robi się szacunek kosztu tej zmiany i
klient decyduje, czy woli płacić za to, czy za co innego, czy też
przestać płacić i odebrać produkt taki, jaki jest. Z czytanych przeze
mnie podręczników to akurat na ten temat więcej jest w "The Scrum Field
Guide" Mitcha Lacy'ego. Wiele opisów czy książek o agile w ogóle się tym
nie zajmuje, bo decydowanie kto płaci i jak się formułuje kontrakty to
nie jest stricte problem inżynierii oprogramowania.

do góry

On 12/07/2013 13:06, Paweł Kierski wrote:
> W dniu 2013-07-12 11:39, Mateusz Łoskot pisze:
>>
>> Czy istnieje jakakolwiek grupa dyskusyjna
>> o Agile w polskim Usenet?
>> Serwer z którego korzystam nic takiego nie listuje.
>
> Chyba za młoda sprawa (szczególnie w Polsce), żeby się na Usenet
> zapała...
> Ale może grupa Agile Warsaw Cię zainteresuje?
> http://agilewarsaw.com/
> https://groups.google.com/forum/#!forum/agile-warsaw

Dzięki Paweł, poczytam.

Pozdrawiam,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org

do góry

On Tue, 16 Jul 2013 23:19:04 -0700 (PDT), Adam Klobukowski
<a...@g...com> wrote:

>On Tuesday, 16 July 2013 19:51:09 UTC+2, slawek wrote:
>> Zaciekawiły mnie też testy: jak przetestować, że np. f(x,y) zwraca poprawne
>> wyniki? Dla przykładu takie dzielenie: 1/1, 2/1, 1/2, 0/1, 1/0, 0/0
>> wystarczy sprawdzić? Biorąc pod uwagę tylko 1E38 liczb (circa zakres
>> singli), mamy 1E76 wartości do sprawdzenia, co przy prędkości 1000
>> teraflopsów zajmie... trochę dłużej niż będzie istniał Wszechświat.
>> (Intel/CPU/Pentium/FDIV-bug)
>
>Pierwsze testy powinny sprawdzać czy cokolwiek się liczy oraz warunki brzegowe. W
późniejszym okresie dodaje się testy na dane wejściowe które wygenerowały błędy.
>
>> Jest też ciekawe kto, przy zmianie specyfikacji zamówienia generowanej przez
>> kupującego program, płaci za ekstra wysiłek? Z podręczników Agilizmu wynika,
>> że to jest free (tj. płaci swoim czasem/zasobami firma softwareowa), ze
>> zdrowego rozsądku wynikałoby że ???
>
>Metodologie Agile (bo jest ich wiele) zakładają że w projekcie, aktywnie bierze
udział reprezentant klienta. Jednocześnie krótkie okresy iteracji projektu powodują
dobrą widoczność zaawansowania. Zmianę wymagań można rozegrać na wiele sposobów, ale
podstawową zasadą Agile jest to że wymagania się zmieniają. W momencie zmiany,
reprezentant klienta dowiaduje się czy trzeba coś zmienić w już wykonanych elementach
i albo to zaakceptuje (i przez to dodatkowy budżet) albo nie. Nie mam w tym mowy aby
firma tworząca system robiła coś za darmo.

To jest mniej wiecej takie pisanie jak to ze komunizm jest najlepszym
ustrojem na swiecie. Utopia, znaczy. Juz ja widze klienta ktory placi
dodatkowo za to ze programisci cos na odwrot zrozumieli.

Ci co wymyslaja takie rzeczy, nigdy nei widzieli z bliska ani
pzremyslu, ani klienta. Nie wiedza ze soft robi sie na podstawie
umowy, a kazde odstepstwo od umowy musi byc negocjowane i zawarte w
rozszerzeniu do umowy, i jezeli wina lezy po stronie firmy
programistycznej, klient nei zaplaci. Mozna sie w razie czego spotkac
w sadzie. O czym prasa fachowa od czasu do czasu donosi

A.L.

do góry

On 2013-07-17, A.L <a...@a...com> wrote:
> On Tue, 16 Jul 2013 23:19:04 -0700 (PDT), Adam Klobukowski
><a...@g...com> wrote:
>
>>On Tuesday, 16 July 2013 19:51:09 UTC+2, slawek wrote:
>>> Zaciekawiły mnie też testy: jak przetestować, że np. f(x,y) zwraca poprawne
>>> wyniki? Dla przykładu takie dzielenie: 1/1, 2/1, 1/2, 0/1, 1/0, 0/0
>>> wystarczy sprawdzić? Biorąc pod uwagę tylko 1E38 liczb (circa zakres
>>> singli), mamy 1E76 wartości do sprawdzenia, co przy prędkości 1000
>>> teraflopsów zajmie... trochę dłużej niż będzie istniał Wszechświat.
>>> (Intel/CPU/Pentium/FDIV-bug)
>>
>>Pierwsze testy powinny sprawdzać czy cokolwiek się liczy oraz warunki brzegowe. W
późniejszym okresie dodaje się testy na dane wejściowe które wygenerowały błędy.
>>
>>> Jest też ciekawe kto, przy zmianie specyfikacji zamówienia generowanej przez
>>> kupującego program, płaci za ekstra wysiłek? Z podręczników Agilizmu wynika,
>>> że to jest free (tj. płaci swoim czasem/zasobami firma softwareowa), ze
>>> zdrowego rozsądku wynikałoby że ???
>>
>>Metodologie Agile (bo jest ich wiele) zakładają
[...]
> To jest mniej wiecej takie pisanie jak to ze komunizm jest najlepszym
> ustrojem na swiecie. Utopia, znaczy. Juz ja widze klienta ktory placi
> dodatkowo za to ze programisci cos na odwrot zrozumieli.
>
> Ci co wymyslaja takie rzeczy, nigdy nei widzieli z bliska ani
> pzremyslu, ani klienta. Nie wiedza ze soft robi sie na podstawie
> umowy, a kazde odstepstwo od umowy musi byc negocjowane i zawarte w
> rozszerzeniu do umowy

I to pisze wielki A.L., który widział wszystko w przemyśle w tej swojej
hameryce. Najwyraźniej mało widziałeś, staruszku. Bywa i tak, że klient
(duży) chce, żeby firma programistyczna (duża) wytwarzała mu produkt
zgodnie z którąś metodyką agile, co jak najbardziej jest zapisane
w umowie. Nawet ja, smarkacz i gówniarz przy tobie, widziałem takie
rzeczy. Bo wiesz, negocjowanie załącznika do kontraktu jest bardzo
kosztownym procesem biznesowym i zwyczajnie się nie opłaca przy
przeniesieniu przycisku z miejsca na miejsce. No i nie wszystko da się
zawrzeć w specyfikacji (bo będzie miała nie *dziesiąt czy nawet *set
stron, tylko kilkanaście milionów). Twierdzenie, że wszystko da się
a priori uregulować i zawrzeć w umowie -- to dopiero jest utopijne
myślenie.

> i jezeli wina lezy po stronie firmy
> programistycznej, klient nei zaplaci. Mozna sie w razie czego spotkac
> w sadzie. O czym prasa fachowa od czasu do czasu donosi

Prasa fachowa donosi też od czasu do czasu o nieudanych wdrożeniach
w metodykach nie-agile. Co z tego wynika?

--
Secunia non olet.
Stanislaw Klekot

do góry

On Wed, 17 Jul 2013 20:17:45 +0000 (UTC), "Stachu 'Dozzie' K."
<d...@g...eat.some.screws.spammer.invalid> wrote:

>I to pisze wielki A.L., który widział wszystko w przemyśle w tej swojej
>hameryce.

Kompleksy masz?..

>Najwyraźniej mało widziałeś, staruszku.

Wystarczajaco.

>Bywa i tak, że klient
>(duży) chce, żeby firma programistyczna (duża) wytwarzała mu produkt
>zgodnie z którąś metodyką agile, co jak najbardziej jest zapisane
>w umowie.


Klienat gowno obchodzi na pgol jaka metodyka bedzie wykonywany
projekt. Projekt ma byc dobrze, wedle umowy i na czas.

>Nawet ja, smarkacz i gówniarz przy tobie, widziałem takie
>rzeczy. Bo wiesz, negocjowanie załącznika do kontraktu jest bardzo
>kosztownym procesem biznesowym i zwyczajnie się nie opłaca przy
>przeniesieniu przycisku z miejsca na miejsce.

Ja nie jestem w biznesie robienia przyciskow. Chyba jednak mowimy o
roznych rzeczach.

> No i nie wszystko da się
>zawrzeć w specyfikacji (bo będzie miała nie *dziesiąt czy nawet *set
>stron, tylko kilkanaście milionów).

Pewnei ze nie.

> Twierdzenie, że wszystko da się
>a priori uregulować i zawrzeć w umowie -- to dopiero jest utopijne
>myślenie.
>

Ale myslenie Agilowcow zw umowa W OGOLE niepotrzebna to tez promach.

>> i jezeli wina lezy po stronie firmy
>> programistycznej, klient nei zaplaci. Mozna sie w razie czego spotkac
>> w sadzie. O czym prasa fachowa od czasu do czasu donosi
>
>Prasa fachowa donosi też od czasu do czasu o nieudanych wdrożeniach
>w metodykach nie-agile. Co z tego wynika?

Ze klient - nasz pan

A.L.

do góry