On Dec 19, 12:43 pm, Roman W <b...@g...pl> wrote:
> On Dec 19, 11:02 am, Andrzej Jarzabek <a...@g...com>
> wrote:
>
> > * Modele funkcjonują jako user stories
>
> To nie sa user stories.

Dlaczego? Pytam poważnie i jak pisałem, nie znam się na tym, więc moje
dalsze dywagacje będą typu "jak mały Jasio sobie wyobraża", więc nie
śmiej się za bardzo, tylko naprostuj mnie błądzącego.

Otóż mały Jasio sobie wyobraża, że masz zasadniczo dwa podejścia do
architektury takiego programu. Pierwsze jest takie, że modele są
bezpośredio wbudowane w program i stanowią jego ficzery. Jeśli program
ma modele A, B i C, a chce się mieć model D, to zespół tworzący
program musi zmienić ten program. W takim przypadku modele funkcjonują
jako user stories - to, że nie mają takiego formatu jak typowe user
stories, że nie są napisane z punktu widzenia "użytkownika" nie ma
większego znaczenia - po prostu taka specyfika branży. Istotne jest
to, że na początku każdego tygodnia możemy wyłożyć na stół listę
modeli, które można zaimplementować (co również oznacza, że mają
odpowiednie stempelki) i zadać pytania "które z nich chcemy
zaimplementować w pierwszej kolejności?" i "ile z nich zdążymy
zaimplementować w tym tygodniu?"

Druga możliwość, którą mały Jasio sobie wyobraża, jest taka, że
program do algo przyjmuje modele zadane przez użytkownika, które mogą
być podane jako jakieś pliki konfiguracyjne, programy napisane w DSL-u
albo jakieś dll-ki pisane przez quantów czy kogo tam w C++ czy w czym
tam. W takiej sytuacji ludzie tworzący modele są użytkownikami
programu, raczej niż jego twórcami. Problem akceptacji konkretnych
modeli przez odpowiednie działy jest problemem owych użytkowników, a
user stories są "chciałbym użyć w modelu danej xyz, ale w tej chwili
nie ma takiego parametru, proszę mi go dodać", "proszę o dodanie do
DSL-a wsparcia dla funkcji eliptycznych", "chciałbym pisać modele w
Javie" itd.

> > * 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.

Nie mam pojęcia, jakie są zadania tradera w takim zespole, ale w
agile'owym żargonie product owner jest osobą, która decyduje o
funkcjonalności programu. Jeśli tą funkcjonalnością są konkretne
modele, to product owner musi decydować, które ze wszystkich modeli
zaproponowanych przez quantów czy kogo tam, zostaną zaimplementowane,
a które nie, i w jakiej kolejności. W związku z tym małemu Jasiowi
wydawałoby się, że taka osoba byłaby w naturalny sposób zainteresowana
tym, które modele będą zatwierdzone a zatem chciałaby decydować, które
i w jakiej kolejności będą zatwierdzane przez dział zatwierdzania.

Jeśli mały Jasio się myli, i to z reguły zadaniem quantów (czy kogo
tam) wymyślających owe modele jest zatwierdzenie ich w odpowiednich
działach, to niewiele zmienia: zainteresowany quant wymyśla model,
dokumentuje go w takim zakresie, jak wymagają tego działy
zatwierdzania, w ciągu tygodnia biega za stempelkami, a przy iteration
planning kładzie na stół te modele, które udało mu się zatwierdzić (i
na których mu jeszcze zależy).

Z drugiej strony jeśli masz zespół złożony z n quantów, którzy sami
wymyślają, co program ma robić, sami zabiegają o zatwierdzenie tego, a
następnie sami to implementują, oraz tradera, którego rolą jest
polityczne naciskanie na to lub owo, to prawdopodobnie stosowanie XP
nie ma sensu. Możnaby się ewentualnie zastanowić nad Scrumem z
odpowiednio dobranymi praktykami.