On Dec 18, 6:05 pm, Andrzej Jarzabek <a...@g...com>
wrote:

> > Dlatego dokumentację można np. powielić i dać do audytu. Nawet
> > równoległego, przez wielu obserwatorów. OSCR takich ficzerów nie ma.
>
> Acceptance tests mają takie ficzery.

Ale musiałoby ich być dokładnie tyle, ile byłoby tej dokumentacji,
której ma nie być.

Sęk w tym, że nie wszystko, co można napisać w dokumentacji, można
zdefiniować w formie testu. Zwłaszcza w sytemach, które opisuje się
pod kątem ich całościowego działania a nie pod kątem działania
pojedynczego programu - tak jest np. w systemach przemysłowych. Np.
"system ma liczyć przejeżdżające samochody". Jedno takie zdanie w
dokumentacji załatwia temat, którego implementacja obejmuje wiele
różnych aspektów, łącznie z hardwarem. Wykonawca z doświadczeniem wie,
jak to zrealizować.
Jak do tego zrobić acceptance test?

Albo np. chciałbym, żeby "procesor dźwięku robił pogłos taki jak w
znanej sali pewnej filharmonii". Znowu jedno zdanie. Jak do tego
zrobić acceptance test?

> >> Jeżeli działa niezgodnie z nieistniejącą dokumentacją, to nie przechodzi
> >> testów i nie może zostać zreleasowany.
>
> > Jakich testów? Tych, które powstały na podstawie nieistniejącej
> > dokumentacji i są z tą nieistniejącą dokumentacją niezgodne?
>
> Testów, które powstały na podstawie rozmowy z OSCR-em i zostały przez
> tego OSCR-a zatwierdzone.

Tak to można okienka dialogowe w programie księgowym robić. Systemów
przemysłowych ani nawet rozrywkowych w ten sposób nie widzę.

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

do góry

W dniu 2011-12-18 13:14, Andrzej Jarzabek pisze:

> Co do problemu 50 programistów, to XP i (w mniejszym stopniu) Scrum
> skalują się na wielkość zespołu do powiedzmy 12-16 programistów. Da się
> je zastosować do większych projektów, pod warunkiem, że da się podzielić
> zespół. To nie jest takie hop-siup, które można zrobić mechanicznym
> dzieleniem, bo każdy zespół musi mieć pewną autonomię i być właścicielem
> swojego codebase: w praktyce musi tworzyć oddzielny "produkt"
> (komponent), i w takiej sytuacji jeden zespół jest "klientem" drugiego,


Jednym słowem, najpierw trzeba wszytko dobrze i poprawnie wszytko
zaprojektować, następnie do klocków które nam powstały podesłać
programistów mówiąc 'róbta XP'.
Dobrze rozumiem? Bo sensowność mi umyka. Zwłaszcza, że wyrzucamy
pracowicie zrobiony projekt i nie kodujemy wg jego założeń, ale
wg tego, co druga grupa z nami konsultuje.
Nie znam sie, dlatego się pytam. Ale tak czasem wyglądały
'zespołowe projekty programistyczne' u moich znajomych;-)


pzdr
bartekltg

do góry

On Dec 18, 11:31 pm, Maciej Sobczak <s...@g...com> wrote:
> Tak to można okienka dialogowe w programie księgowym robić. Systemów
> przemysłowych ani nawet rozrywkowych w ten sposób nie widzę.

Mnie w ogole zastanawia, czemu w "starszych" dziedzinach przemyslu
(np. budownictwo czy petrochemia) koniecznosc stworzenia spojnego
calosciowego projektu jest *oczywista*, natomiast w IT ludziom sie
wydaje, ze mozna tworzyc duze systemy z klockow Lego.

RW

do góry

On Dec 18, 9:55 pm, Roman W <b...@g...pl> wrote:
> On Sunday, 18 December 2011 21:41:30 UTC, Andrzej Jarzabek  wrote:
> > W ogóle nie podejmuję się oceniać wtę czy wewtę, zwracam tylko uwagę, że
> > różne firmy mogą działać różnie. Czy to, co pisałeś o zatwierdzaniu
> > dotyczy wszystkich firm, w tym różnych hedge fundów i innych proprietary
> > trading, czy raczej głównie banków?
>
> Dzial risk management jest w kazdej instytucji ktora handluje,
> przynajmniej "dla przyzwoitosci". Czy hedge fundy maja oddzielne
> dzialy model validation to nie wiem, byc moze nie wszystkie (w sumie
> moze sie tym zajmowac i risk management). Banki na pewno maja tego
> wiecej, bo regulatorzy patrza im (a przynajmniej staraja sie patrzec)
> na rece, ale jezeli hedge fund nie mialby zadnej niezaleznej kontroli
> nad systemami uzywanymi do handlowania i - rownie wazne - wyliczania
> zyskow i strat, to IMHO igraliby z ogniem. Byc moze sa jakies malutkie
> instytucje w ktorych wlasciciel sam wszystko sprawdza, ale nie
> wyobrazam sobie obracania duzymi pieniedzmi bez odpowiednich procedur
> kontrolnych.

No więc tak dla poddierżania razgawora, i abstrahując od kolesia z
którym rozmawiałem i firmy, w której pracuje, czy wyobrażasz sobie, że
mogłoby to działać w ten sposób:
* Koleś/kolesie od wymyślania modeli funkcjonuje/ą jako OSCR
* Modele funkcjonują jako user stories
* Po stworzeniu modelu koleś od wymyślania zanosi go do product ownera
* Product owner zajmuje się tym, żeby złożone u niego modele zostały
zatwierdzone gdzie trzeba
* Na początku każdej iteracji zetsraw zatwierdzonych gdzie trzeba
modeli jest brany jako pula user stories do zaplanowania?

do góry

Roman W wrote:

> On Dec 18, 11:31 pm, Maciej Sobczak <s...@g...com> wrote:
>> Tak to można okienka dialogowe w programie księgowym robić. Systemów
>> przemysłowych ani nawet rozrywkowych w ten sposób nie widzę.
>
> Mnie w ogole zastanawia, czemu w "starszych" dziedzinach przemyslu
> (np. budownictwo czy petrochemia) koniecznosc stworzenia spojnego
> calosciowego projektu jest *oczywista*, natomiast w IT ludziom sie
> wydaje, ze mozna tworzyc duze systemy z klockow Lego.

Jeśli w budownictwie wyprodukuje się jakiś klocek, to zwykle nie da się go
przerobić w klocek nieco inny (bo podczas przymierzania okazało się, że coś
jest nie tak).
W programowaniu modyfikacja klocka zazwyczaj jest wykonalna. I czasami może
być bardziej opłacalna, niż szczegółowe przewidywanie wszystkiego na samym
początku.

do góry

On Dec 18, 11:31 pm, Maciej Sobczak <s...@g...com> wrote:
> On Dec 18, 6:05 pm, Andrzej Jarzabek <a...@g...com>
> wrote:
>
> > > Dlatego dokumentację można np. powielić i dać do audytu. Nawet
> > > równoległego, przez wielu obserwatorów. OSCR takich ficzerów nie ma.
>
> > Acceptance tests mają takie ficzery.
>
> Ale musiałoby ich być dokładnie tyle, ile byłoby tej dokumentacji,
> której ma nie być.

Dokładnie.

> Sęk w tym, że nie wszystko, co można napisać w dokumentacji, można
> zdefiniować w formie testu.

Bywa. Dlatego też zasada nie jest taka, że się w ogóle nie produkuje
dokumentacji, tylko że dokumentuje się tylko to, czego absolutnie nie
da się zapisać w postaci testu lub kodu. Zaskakująco, jeśli w twoim
procesie na punkt "istotna właściwość systemu" masz reakcję nie
"trzeba to udokumentować" tylko "trzeba napisać

> Zwłaszcza w sytemach, które opisuje się
> pod kątem ich całościowego działania a nie pod kątem działania
> pojedynczego programu - tak jest np. w systemach przemysłowych. Np.
> "system ma liczyć przejeżdżające samochody". Jedno takie zdanie w
> dokumentacji załatwia temat, którego implementacja obejmuje wiele
> różnych aspektów, łącznie z hardwarem. Wykonawca z doświadczeniem wie,
> jak to zrealizować.
> Jak do tego zrobić acceptance test?

Nie jestem wykonawcą z doświadczeniem, to po pierwsze, po drugie nie
da się odpowiedzieć na takie pytanie bez kontekstu. Zakładając
przykładowo, że masz jakiś system, który liczy przejeżdżające
samochody na podstawie wejścia z jakichś sensorów, to można budować
testy w oparciu o rzeczywiste lub symulowane dane z tych sensorów.
Oczywiście od różnych czynników będzie zależało, czy tych test case'ów
będzie kilka (0 samochodów, 1 samochód, 2 samochody, 5 samochodów, 137
samochodów), czy np. będą to dziesiątki tysięcy filmów zebranych z
kamer drogowych w całym kraju, z brzegowymi przypadkami typu kawalkada
5 motocykli albo furmanka. W każdym razie sam fakt, że system ma
liczyć przejeżdżające samochody, który w dokumentacji jest wyrażony
samym tylko zdanie "system ma liczyć przejeżdżające samochody", w
suicie acceptance tests jest wyrażony samym tylko istnieniem testu czy
grupy testów o nazwie "liczPrzejeżdzająceSamochody".

> Albo np. chciałbym, żeby "procesor dźwięku robił pogłos taki jak w
> znanej sali pewnej filharmonii". Znowu jedno zdanie. Jak do tego
> zrobić acceptance test?

Bardzo prosto: dajesz OSCR-owi do odsłuchania ileś tam dźwięków
przetworzonym z takim pogłosem, on ci potwierdza, że to brzmi jak
odpowiednia filharmonia, piszesz test, który przetwarza dźwięk tym
efektem i sprawdza, czy wyjście się zgadza. Nazywasz test
"testujPogłosZeZnanejSaliWFilharmoniiWKoluszkach". W momencie kiedy
test ci failnie, zanosisz wyprodukowane nową wersją programu sample do
OSCR-a i pytasz go, czy nadal brzmią jak znana sala w Koluszkach.

> > Testów, które powstały na podstawie rozmowy z OSCR-em i zostały przez
> > tego OSCR-a zatwierdzone.
>
> Tak to można okienka dialogowe w programie księgowym robić. Systemów
> przemysłowych ani nawet rozrywkowych w ten sposób nie widzę.

Przez "przemysłowe" rozumiesz staerowanie jakimiś maszynami w fabryce
czy coś takiego? Nie znam się na tym, ale chętnie dowiem się dlaczego
tak uważasz.

Jeśli chodzi o "rozrywkowe", to na pewno wiem, że testy automatyczne,
jak i różne metodologie agile, stosuje się przy tworzeniu gier
komputerowych - chyba się kwalifikują jako 'rozrywka'? Jeśli chodzi o
jakieś rzeczy typu oprogramowanie do wieży hifi, to znowu - nie mam
zdania, ale chętnie usłyszę dlaczego to miałoby nie działać.

do góry

On Dec 19, 11:02 am, Andrzej Jarzabek <a...@g...com>
wrote:
> No więc tak dla poddierżania razgawora, i abstrahując od kolesia z
> którym rozmawiałem i firmy, w której pracuje, czy wyobrażasz sobie, że
> mogłoby to działać w ten sposób:
> * Koleś/kolesie od wymyślania modeli funkcjonuje/ą jako OSCR

Na ogol modele wymyslaja i implementuja w kodzie te same osoby.
Dawanie modeli numerycznych czystym programistom czesto prowadzi do
kupy smiechu.

> * Modele funkcjonują jako user stories

To nie sa user stories.

> * Po stworzeniu modelu koleś od wymyślania zanosi go do product ownera
> * Product owner zajmuje się tym, żeby złożone u niego modele zostały
> zatwierdzone gdzie trzeba

Nope. Product owner na ogol jest traderem, ktory nie chce miec nic
wspolnego z zatwierdzaniem modelu. Co najwyzej moze naciskac
politycznie, zeby dany model zostal zatwierdzony, z roznym skutkiem.

> * Na początku każdej iteracji zetsraw zatwierdzonych gdzie trzeba
> modeli jest brany jako pula user stories do zaplanowania?

Natomiast XP programming mozna by IMHO stosowac wewnatrz grupy quantow
implementujacych modele, przy zalozeniu za jakas dokumentacja jednak
powstaje, rowniez przed rozpoczeciem kodowania.

RW

do góry

On Dec 19, 11:55 am, Wojciech Jaczewski <w...@o...pl> wrote:
> Roman W wrote:
> > On Dec 18, 11:31 pm, Maciej Sobczak <s...@g...com> wrote:
> >> Tak to można okienka dialogowe w programie księgowym robić. Systemów
> >> przemysłowych ani nawet rozrywkowych w ten sposób nie widzę.
>
> > Mnie w ogole zastanawia, czemu w "starszych" dziedzinach przemyslu
> > (np. budownictwo czy petrochemia) koniecznosc stworzenia spojnego
> > calosciowego projektu jest *oczywista*, natomiast w IT ludziom sie
> > wydaje, ze mozna tworzyc duze systemy z klockow Lego.
>
> Jeśli w budownictwie wyprodukuje się jakiś klocek, to zwykle nie da się go
> przerobić w klocek nieco inny (bo podczas przymierzania okazało się, że coś
> jest nie tak).

No popatrz, a jak zmienialem drzwi/okna/pokrycie dachu to poszlo bez
problemu. Bo sa rozne standardy, ktore sie egzekwuje na etapie
projektowania, ktore ludziom niesamowicie ulatwiaja potem prace, jak
chca cos w konstrukcji zmienic.

> W programowaniu modyfikacja klocka zazwyczaj jest wykonalna. I czasami może
> być bardziej opłacalna, niż szczegółowe przewidywanie wszystkiego na samym
> początku.

Ja bym powiedzial ze jest raczej na odwrot: brak calosciowego
planowania w IT na ogol prowadzi do powstania systemow, ktore sa
bardzo sztywne i ciezkie do zmiany. Bo nikomu sie nie chcialo
pomyslec, jak zaprojektowac calosc tak, zeby bylo elastyczna. Z
wymiennych klockow Lego tez mozna zbudowac konstrukcje
niemodyfikowalna.

RW

do góry

On Dec 19, 12:54 am, bartekltg <b...@g...com> wrote:
> W dniu 2011-12-18 13:14, Andrzej Jarzabek pisze:
>
> > Co do problemu 50 programistów, to XP i (w mniejszym stopniu) Scrum
> > skalują się na wielkość zespołu do powiedzmy 12-16 programistów. Da się
> > je zastosować do większych projektów, pod warunkiem, że da się podzielić
> > zespół. To nie jest takie hop-siup, które można zrobić mechanicznym
> > dzieleniem, bo każdy zespół musi mieć pewną autonomię i być właścicielem
> > swojego codebase: w praktyce musi tworzyć oddzielny "produkt"
> > (komponent), i w takiej sytuacji jeden zespół jest "klientem" drugiego,
>
> Jednym słowem, najpierw trzeba wszytko dobrze i poprawnie wszytko
> zaprojektować, następnie do klocków które nam powstały podesłać
> programistów mówiąc 'róbta XP'.

Nie wiem, co rozumiesz przez "dobrze i poprawnie wszystko
zaprojektować". Jeśli "wszystko" oznacza faktycznie wszystko, tzn.
cały system, każdy z jego komponentów, każdy z podkomponentów tych
komponentów i tak dalej przez wszystkie poziomy, to odpowiedź brzmi
"nie". W wielu przypadkach nie potrzebujesz literalnie wszystkiego
(albo nawet w grubym przybliżeniu wszystkiego) projektować, żeby
stworzyć listę czterech czy pięciu "loosely coupled" komponentów, z
których składać się będzie system - a o tylu mowa, skoro dzielimy 50-
osobowy zespół na zespoły maksymalnie 16-osobowe (licząc tylko
programistów), przy czym być może mamy jeden zespół nie tworzący
żadnego komponentu tylko zajmujący się integracją produktu.

Jeśli "wszystko zaprojektować" znaczy "zaprojektować system jako
całość" - bez wdawania się w szczegóły, to tak.

Jeśli według ciebie "zaprojektować dobrze i poprawnie" znaczy "na
najwyższym możliwym poziomie abstrakcji", czyli powiedzmy narysować na
tablicy pięć prostokątów, reprezentujących logiczne komponenty
projektowanego systemu, wypunktować w każdym w kilku punktach po
jednym zdaniu czym te komponenty mają się zajmować, i ewentualnie
połączyć je jakimiś kreskami czy strzałkami oznaczającymi zależności,
to tak, należy "zaprojektować dobrze i poprawnie". Ale też właśnie XP
(i Agile jakoś tam w ogólności) twierdzi, że takie projektowanie jest
właśnie dobre i poprawne i tak należy robić.

Jeśli "zaprojektować dobrze i poprawnie" dla ciebie oznacza co innego,
to przykro mi, nie potrafię odpowiedzieć na to pytanie, bo umiem
czytać w myślach.

> Bo sensowność mi umyka. Zwłaszcza, że wyrzucamy
> pracowicie zrobiony projekt i nie kodujemy wg jego założeń, ale
> wg tego, co druga grupa z nami konsultuje.

Jaki projekt? Jeśli chodzi o ten projekt, na którym narysowano
prostokąt i napisano w nim powiedzmy "interfejs do systemu SWIFT", to
niby dlaczego zespół robiący interfejs do systemu SWIFT miałby go
wyrzucić?

Uprzedzając: zanim napiszesz, że "czasem się nie da bez zrobienia
dużego, szczegółowego projektu, stwierdzić, jak można sensownie
podzielić system na komponenty tworzone przez autonomiczne zespoły",
to odpowiem - być może czasem się nie da. W takich przypadkach po
prostu nie należy stosować XP. Z mojego doświadczenia wynika, że w
bardzo wielu przypadkach się da, a nawet że często jest to i tak
robione, nawet jeśli nie stosuje się żadnej metodologii agile. To
raczej monolityczne zespoły z 50 programistami są rzadkością, nawet
przy tworzeniu względnie dużych systemów.

do góry

On Dec 19, 1:33 pm, Andrzej Jarzabek <a...@g...com>
wrote:

> > > Acceptance tests mają takie ficzery.
>
> > Ale musiałoby ich być dokładnie tyle, ile byłoby tej dokumentacji,
> > której ma nie być.
>
> Dokładnie.

Nie tylko. Tych notatek z dyskusji też musi być dokładnie tyle samo
(bo informacji nie da się zredukować). I tego właśnie nie rozumiem.
Tradycyjna metoda polega na tym, że się pisze dokumentację, w której
zawarta jest wiedza nt. działania systemu. W agile piszemy notatki,
których jest *tyle samo* (nieredukowalność informacji, sorry, nie ja
stworzyłem świat). A przynajmniej w całej tej dyskusji nie padły żadne
przesłanki do stwierdzenia, że mogłoby ich być mniej.
I teraz okazuje się, że pomimo faktu, że będzie ich tyle samo i będzie
do tego potrzebny taki sam wysiłek pisarski, to musimy je koniecznie
wyrzucić do kosza i to najdalej parę godzin po napisaniu. To bardzo
ważne. Bo jeśli zapomnimy je wyrzucić i się zaczną nam zbierać, to
klient zobaczy plik kartek i jeszcze pomyśli, że my tu jakąś
dokumentację piszemy i okaże się, że król jest nagi a my wcale nie
jesteśmy agile.

Niech mi ktoś wytłumaczy, w czym napisanie notatek i wywalenie ich do
kosza jest lepsze od napisania ich i spięcia w segretatorze.

Pomijając fakt, że w kontekście biznesowym wyrzucanie *czegokolwiek*
do kosza to czysta głupota i zwykle się srogo mści w późniejszym
terminie.
To nie jest żadna metodologia, to jest usankcjonowana
nieodpowiedzialność.

> > Sęk w tym, że nie wszystko, co można napisać w dokumentacji, można
> > zdefiniować w formie testu.
>
> Bywa. Dlatego też zasada nie jest taka, że się w ogóle nie produkuje
> dokumentacji, tylko że dokumentuje się tylko to, czego absolutnie nie
> da się zapisać w postaci testu lub kodu.

Acha - czyli niektóre notatki zachowujemy w segregatorze. Wyrzucamy
(koniecznie!) tylko te, dla których udało nam się napisać acceptance
test.

Sorki, nie kupuję tego.

> Zakładając
> przykładowo, że masz jakiś system, który liczy przejeżdżające
> samochody na podstawie wejścia z jakichś sensorów, to można budować
> testy w oparciu o rzeczywiste lub symulowane dane z tych sensorów.

Ale klienta równo wali, czy to liczenie robi program, czy hardware,
czy krasnoludki. I w ogóle jaki sensor?
Właśnie w tym jest problem, że systemy przemysłowe opisuje się
całościowo, bo tylko w całości one są potrzebne. Wydzielanie granicy
pomiędzy sensorami a programem, jest sztucznym krokiem, który z punktu
widzenia klienta nic nie wnosi - dlatego nie wierzę, że OSCRowi będzie
się chciało robić taki test. OSCR tego nie widzi. On widzi samochody.

W ogóle mam wrażenie, że agile wraz z całą swoją kulturą testowania
jest bardzo nakierowany na założenie, że produktem jest jakiś program.
Pewnie działa to jakość w kontekście np. serwisu internetowego, ale w
większej skali produktem nie jest program, tylko system, w którym
granice pomiędzy jego technicznymi składnikami (np. sensor vs.
program) są niewidoczne dla klienta. I na tym się agile wyłoży.

> > Albo np. chciałbym, żeby "procesor dźwięku robił pogłos taki jak w
> > znanej sali pewnej filharmonii". Znowu jedno zdanie. Jak do tego
> > zrobić acceptance test?
>
> Bardzo prosto: dajesz OSCR-owi do odsłuchania ileś tam dźwięków
> przetworzonym z takim pogłosem, on ci potwierdza, że to brzmi jak
> odpowiednia filharmonia, piszesz test, który przetwarza dźwięk tym
> efektem i sprawdza, czy wyjście się zgadza.

Złapałeś się. :-) W przypadku pogłosu z filharmonii wyjście za każdym
razem się może nie zgadzać (i na tym polega jego urok) a stwierdzenie,
że coś brzmi tak samo jak coś innego jest subiektywne. Ten problem nie
dotyczy tylko akustyki, jest cała masa takich miejsc. Np. ekspres do
kawy ma robić dobrą kawę. Znowu nie ma jak zrobić acceptance testu.

> Przez "przemysłowe" rozumiesz staerowanie jakimiś maszynami w fabryce
> czy coś takiego?

Tak.

> Nie znam się na tym, ale chętnie dowiem się dlaczego
> tak uważasz.

Właśnie dlatego, że w takich systemach ich działanie opisuje się
całościowo. Agile jest za bardzo intruzywny i za bardzo zakłada, że
klient będzie chciał być zaangażowany (poprzez OSCRów) w definiowanie
tak drobno określonch szczegółów implementacyjnych.

> Jeśli chodzi o "rozrywkowe", to na pewno wiem, że testy automatyczne,
> jak i różne metodologie agile, stosuje się przy tworzeniu gier
> komputerowych - chyba się kwalifikują jako 'rozrywka'?

A tutaj to akurat ja się nie znam. Może profesor fir będzie wiedział.

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

do góry