On Dec 18, 4:25 pm, Andrzej Jarzabek <a...@g...com>
wrote:
> [...] Nie mam pojęcia, jakiej wielkości są projekty tworzenia
> baz danych szlayuchów i kaloszy, bo przyznam, że w tej akurat dziedzinie
> doświadczenia żadnego nie mam, ale takie wielkości projektów, o których
> mówię, to są np. market data systems, tradig platforms, order routing,
> algorithmic trading, securities finance, różne systemy middle i back
> office itd.

Nie mow mi, prosze, ze systemy do algorithmic trading czy derywatow
powstaja do dokumentacji, bo to jest totalna bzdura. Dokumentacja jest
potrzebna chocby do tego, zeby dostac akceptacje od dzialow risk
management i model validation.

RW

do góry

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

> Jeszcze raz - nie masz takiego etapu, że przez ileś tygodni czy miesięcy
> piszesz dokumentację (jakkolwiek nazwaną). User stories zaproponowane
> przez OSCR-ów są priorytetyzowane na początku każdej iteracji i według
> ich ważności i szacowanego czasu wykonania wybierany jest zestaw do
> wykonania w czasie następnej iteracji (np. tygodnia).

Swietnie. A jak taki system wyglada np. z punktu widzenia panstwowego
regulatora, czy firmy audytorskiej? Czytaja sobie te user stories?

RW

do góry

On 18/12/2011 17:11, Roman W wrote:
> On Dec 18, 4:25 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>> [...] Nie mam pojęcia, jakiej wielkości są projekty tworzenia
>> baz danych szlayuchów i kaloszy, bo przyznam, że w tej akurat dziedzinie
>> doświadczenia żadnego nie mam, ale takie wielkości projektów, o których
>> mówię, to są np. market data systems, tradig platforms, order routing,
>> algorithmic trading, securities finance, różne systemy middle i back
>> office itd.
>
> Nie mow mi, prosze, ze systemy do algorithmic trading czy derywatow
> powstaja do dokumentacji, bo to jest totalna bzdura. Dokumentacja jest
> potrzebna chocby do tego, zeby dostac akceptacje od dzialow risk
> management i model validation.

Nie mówię, mówię tylko, że powstają w zespołach znacznie mniejszych niż
50 osób.

Dodatkowo nie jest tak, że nie tworzy się dokumentacji. Nie tworzy się
(generalnie) dokumentacji dla developerów, według której wykonują oni
program. Tworzy się różne inne rodzaje dokumentacji, między innymi
dokumentację dla końcowego użytkownika, zatem można uznać, że tworzenie
innych, analogicznych rodzajów dokumentacji też mieści się w ramach
metodologii.

do góry

On 18/12/2011 17:13, Roman W wrote:
> On Dec 18, 4:54 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>
>> Jeszcze raz - nie masz takiego etapu, że przez ileś tygodni czy miesięcy
>> piszesz dokumentację (jakkolwiek nazwaną). User stories zaproponowane
>> przez OSCR-ów są priorytetyzowane na początku każdej iteracji i według
>> ich ważności i szacowanego czasu wykonania wybierany jest zestaw do
>> wykonania w czasie następnej iteracji (np. tygodnia).
>
> Swietnie. A jak taki system wyglada np. z punktu widzenia panstwowego
> regulatora, czy firmy audytorskiej? Czytaja sobie te user stories?

Jeśli są takie wymagania, to równolegle z kodem powstaje dokumentacja
zgodności z przepisami czy co tam. To się jakościowo (w sensie miejsca w
procesie) niczym nie różni od tworzenia dokumentacji dla końcowego
użytkownika. No chyba że się różni bo cośtam cośtam, np. jest ustawa
wymagająca stworzenia dokumentacji projektowej, wtedy oczywiście musisz
ją stworzyć, a czy wtedy ma sens stosować XP, to nie wiem.

do góry

On 18/12/2011 16:25, Andrzej Jarzabek wrote:
> On 18/12/2011 15:40, A.L. wrote:
>
> Jak rozumiem dla kolegi duży projekt to jest taki,w którym pracuje 50
> programistów i więcej. Więc ja powtórzę - te metodologie sie stosuje, i
> moje doświadczenia dotyczą niedużych projektów - mniej więcej od 6 do 20
> programistów. Nie mam pojęcia, jakiej wielkości są projekty tworzenia
> baz danych szlayuchów i kaloszy, bo przyznam, że w tej akurat dziedzinie
> doświadczenia żadnego nie mam, ale takie wielkości projektów, o których
> mówię, to są np. market data systems, tradig platforms, order routing,
> algorithmic trading, securities finance, różne systemy middle i back
> office itd.

Żeby nie było niedopowiedzeń: nie chciałem bynajmniej zasugerować, że
osobiście pracowałem przy tych wszystkich rzeczach, że mam w nich
wszystkich doświadczenie pozwalające na dobór właściwej metodologii i
tak dalej. Jedynie moge powiedzieć, że moje doświadczenie mówi, że każdą
z tych rzeczy można robić w zespole, w którym jest mniej niż 15-20
programistów.

Chodziło po prostu o ustalenie, co kolega A.L. ma na myśli mówiąc "duży
projekt" a "baza danych szlauchów i kaloszy". Jeśli dla A.L. te
wszystkie rzeczy to "bazy szlauchów i kaloszy" to ja nie mam z tym
problemu - mogę nawet spokojnie powiedzieć, że moje doświadczenia są
również z baz danych szlauchów i kaloszy, a z prawdziwymi dużymi
projektami (50 i więcej programistów) nigdy nie miałem do czynienia.

do góry

On 18/12/2011 17:11, Roman W wrote:
>
> Nie mow mi, prosze, ze systemy do algorithmic trading czy derywatow
> powstaja do dokumentacji, bo to jest totalna bzdura. Dokumentacja jest
> potrzebna chocby do tego, zeby dostac akceptacje od dzialow risk
> management i model validation.

BTW: moje doświadczenie z systemami algo, jakiekolwiek żadne by ono nie
było, dotyczyło nie programów tworzonych w banku, tylko w software
house, który sam nie trejdował tylko sprzedawał to oprogramowanie.

BTW2: rozmawiałem ostatnio z programistą robiącym HFT w hedge fundzie
(czy czymś w tym stylu) i on mówił, że jako senior z doświadczeniem może
sobie wprowadzić model z palca i nimt mu tego nie musiał zatwierdzać.

do góry

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

> BTW: moje doświadczenie z systemami algo, jakiekolwiek żadne by ono nie
> było, dotyczyło nie programów tworzonych w banku, tylko w software
> house, który sam nie trejdował tylko sprzedawał to oprogramowanie.

I nie bylo dokumentacji, tylko "user stories"?

>
> BTW2: rozmawiałem ostatnio z programistą robiącym HFT w hedge fundzie
> (czy czymś w tym stylu) i on mówił, że jako senior z doświadczeniem może
> sobie wprowadzić model z palca i nimt mu tego nie musiał zatwierdzać.

Nie wroze im swietlanej przyszlosci.

RW

do góry

On 18/12/2011 20:47, Roman W wrote:
> On Dec 18, 7:38 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>
>> BTW: moje doświadczenie z systemami algo, jakiekolwiek żadne by ono nie
>> było, dotyczyło nie programów tworzonych w banku, tylko w software
>> house, który sam nie trejdował tylko sprzedawał to oprogramowanie.
>
> I nie bylo dokumentacji, tylko "user stories"?

Nie wiem co było, jak mówię, mój kontakt z tym zespołem był właściwie
żaden. Wiedziałem tylko jaki produkt robili i ilu ch było.

Natomiast jeśli była dokumentacja, to raczej żaden dział w banku nie
zatwierdzał dokumentacji, na podstawie której developerzy tworzyli
produkt. Jeśli już, to dostawali dokumentację, która była dostarczana
odbiorcy razem z programem, a tworzenie takiej dokumentacji jest jak
najbardziej kompatybilne z XP czy innymi metodologiami agile.

>> BTW2: rozmawiałem ostatnio z programistą robiącym HFT w hedge fundzie
>> (czy czymś w tym stylu) i on mówił, że jako senior z doświadczeniem może
>> sobie wprowadzić model z palca i nimt mu tego nie musiał zatwierdzać.
>
> Nie wroze im swietlanej przyszlosci.

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?

do góry

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.

RW

do góry

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

> > Zaraz, zaraz. Pisałeś na początku, że dokumentacji ma nie być. Teraz
> > piszesz, że ma być?
>
> Jeśli wynotowanie sobie czegoś podczas rozmowy na kartce papieru to już
> "dokumentacja" to się nie zrozumieliśmy.

To kiedy coś jest "dokumentacją"?
Czy napisanie czegoś na wiki się liczy?

> Nie, nie ma żadnych N miesięcy na pisanie notetek

A jak nie zdążą?

> i nie ma wpinania
> notatek do segregatora.

A jak się rozsypią?

> Notatki służą do tego, żeby pomiędzy rozmową z
> OSCR-em a zakodowaniem uzyskanej informacji rozmawiający nie zapomniał.
> Ten czas, to bardzo rzadko więcej niż dzień, nigdy więcej niż 3-4 dni.

Sorki, ale to nie działa. W 3-4 dni to sobie można okienko dialogowe
napisać a nie określić działanie większego systemu w jakimkolwiek jego
pionowym wycinku.

> Jeszcze raz - nie masz takiego etapu, że przez ileś tygodni czy miesięcy
> piszesz dokumentację (jakkolwiek nazwaną). User stories zaproponowane
> przez OSCR-ów są priorytetyzowane na początku każdej iteracji

Zaraz, zaraz. Czyli OSCRy muszą *najpierw* zaproponować te user
stories, żeby mogli je priorytetyzować. Powiedzmy, że tych historyjek
jest Bardzo Dużo (tm). Ile czasu trwa ich "zaproponowanie"? Czym się
różni "zaproponowanie" dużej ilości historyjek od napisania dużej
ilości use-casów (na przykład) w formie dokumentacji? Nadal jest to N
miesięcy, tyle że się fajniej nazywa. I nadal te user stories razem
wzięte (chyba jednak lepiej je spiąc do segregatora) to jest
dokumentacja.
Dlatego nie widzę postępu.

No, chyba że OSCRy strzelają po kilka historyjek co tydzień i tak aż
do końca projektu. Nadal jednak będzie tego M stron i nadal ich
napisanie zajmie N czasu, nawet jeśli się je zaraz po napisaniu
wyrzuca do kosza.
Dlatego nie widzę postępu.

> Z kolei w ciągu tego tygodnia
> mogą zostać stworzone nowe stories, które dla klienta będą ważniejsze
> niż te, które są już w backlogu.

Czyli co tydzień OSCR może zmienić ogólną wizję i doprowadzić do
stworzenia produktu, który jest zbiorem niepowiązanych ze sobą
funkcjonalności. Coś jak odkurzacz z odtwarzaczem mp3 i ekspresem do
kawy.
W przypadku napisania dokumentacji z góry jest szansa to dostrzec.

> Przede wszystkim czas - czas życia notatki mierzony jest raczej w
> godzinach,

Nie bardzo. Wtedy nie ma szansy dostrzec, że robimy odkurzacz z mp3,
bo przy pisaniu notatki o mp3 poprzednia historyjka o odkurzaniu jest
już w koszu. A potem OSCR powie, że nic takiego nie mówił. I jak mu
udowodnić, że pieprzy, skoro sami powyrzucaliśmy wszystkie notatki do
kosza?

Sorki, ale nie widzę tej teorii w praktyce. Nawet nie chciałbym się w
czymś takim znaleźć, ani jako wykonawca, ani jako klient.

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

do góry