On 23/05/2011 22:14, Maciej Sobczak wrote:
> On 23 Maj, 12:53, Andrzej Jarzabek<a...@g...com> wrote:
>
> [Większość wyciąłem, bo w sumie to się chyba zgadzamy, tylko różnie to
> nazywamy.]



>> I ja się w tym zgadzam, że _prawie_ zawsze dla każdego większego
>> programu, który będzie robiony dłużej niż 2 miesiące przez więcej niż
>> 1-2 osoby i ma szanse mieć dodawaną jakąś funkcjonalność, np. w
>> postaci kolejnych wersji, _jakieś_ testy automatyczne warto napisać.
>> Niezależnie od tego, czy się akurat stosuje agile, czy nie.
>
> No właśnie. Dlatego *jakieś* testy piszę i pomaga mi to w trzymaniu
> fasonu przy różnych zmianach. Ale nie nazywam tego "agile", bo robię
> to wybiórczo. Podobnie, *czasami* siadam do klawiatury z kimś, bo to
> sprzyja weryfikacji i dzieleniu wiedzy, ale nie nazywam tego extreme
> programming, bo to też robię wybiórczo. Itd.

To jest tak: agile to dość szerokie pojęcie, niekoniecznie określające
ilość i rodzaj testów czy żeby używać TDD. W ramach agile masz też takie
procesy jak Scrum, które mówią, że trzeba zebrać zespół w którym jest
odpowiednia ekspertyza i dać zespołowi decydować o tym, co i jak trzeba
robić, żeby wyprodukować kolejną iterację.

Z drugiej strony ja w projektach wielosobowych widzę pewną wartość w
ustaleniu pewnego procesu czy zbioru zasad, których wszyscy zgadzają się
początkowo trzymać, z zastrzeżeniem, że co jakiś czas robi się przegląd
tego, jak proces działa i podejmuje się decyzje o zmianie. Bo jednak
doświadczenia różnych ludzi są różne i oczekiwania też są różne i
czasami nawet indywidualnie jako tam słuszne decyzje bywają między sobą
niekompatybilne i rodzą problemy.

Dlatego też wydaje mi się, że ma sens opisywanie i publikowanie takich
szczegółowych metodologii jak XP i Shore&Warden w szczególności, gdzie
można kumulować doświadczenia z wielu projektów. Przy czym oczywiście
też się zgadzam, że "there is no silver bullet" i częścią dobrego opisu
powinno być szczere przyznanie gdzie dana metodologia się sprawdzi i
jakie są przeciwwskazania.

I z drugiej strony sądzę, że korzystanie z takich metodologii "as
written" (a przynajmniej próba takiego korzystania) ma sens, przy
założeniu oczywiście, że decyzję o tym podejmują ludzie z odpowiednim
doświadczeniem - najlepiej sami użytkownicy.

> Czyli nie róbmy fetyszu z narzędzi.

"[...]we have come to value individuals and interactions over processes
and tools [...]"
heh.

> Heh. Pracowałem kiedyś w Poważnym Projekcie (TM), który był widoczny i
> otwarty dla zleceniodawcy, ale tak jakoś wygodnie było mieć *dwa*
> systemy zgłaszania bugów - klient widział tylko jeden z nich, drugi
> był do użytku wewnętrznego. Powiedzmy, że ten proces dbał o zdrowie
> klienta, który widział tylko te bugi, które sam se odkrył.
> Jak to określiłeś - problem kulturowy.

No więc a propos tego, to w Shore&Warden jest interesująca sugestia,
żeby w ogóle nie utrzymywać bazy bugów.

do góry

On 24 Maj, 02:58, Andrzej Jarzabek <a...@g...com> wrote:

> No więc a propos tego, to w Shore&Warden jest interesująca sugestia,
> żeby w ogóle nie utrzymywać bazy bugów.

Heh? Fikcja z czapki.
Jakaś baza musi być. Czy to są "zadania", czy "bugi", to kwestia
nazw.

Nawet jeśli nie ma bazy typu JIRA czy FogBugz, to ta sama informacja
(np. informacja o tym, że kierownik projektu kazał Krzychowi zrobić X
a Krzychu to zrobił) i tak musi gdzieś zaistnieć, nawet jeśli jest to
w postaci historii maili w zespole.
Nie wyobrażam sobie projektu, gdzie takiej informacji nie ma.

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

do góry

On 24/05/2011 22:34, Maciej Sobczak wrote:
> On 24 Maj, 02:58, Andrzej Jarzabek<a...@g...com> wrote:
>
>> No więc a propos tego, to w Shore&Warden jest interesująca sugestia,
>> żeby w ogóle nie utrzymywać bazy bugów.
>
> Heh? Fikcja z czapki.
> Jakaś baza musi być. Czy to są "zadania", czy "bugi", to kwestia
> nazw.
>
> Nawet jeśli nie ma bazy typu JIRA czy FogBugz, to ta sama informacja
> (np. informacja o tym, że kierownik projektu kazał Krzychowi zrobić X
> a Krzychu to zrobił) i tak musi gdzieś zaistnieć, nawet jeśli jest to
> w postaci historii maili w zespole.
> Nie wyobrażam sobie projektu, gdzie takiej informacji nie ma.

Nie no, oczywiście że nie postulują, żeby informacji nie było. Chodzi
raczej o to, że infrastruktura mająca na celu katalogowanie i
zarządzaniu dużą ilością otwartych bugów na raz jest uważana za
demoralizującą. Że w momencie, kiedy ilość otwartych bugów staje się tak
duża, że pojawia się potrzeba bazy typu JIRA, to znaczy, że robisz za
dużo bugów i zamiast zakładać bazę powinieneś zlikwidować przyczynę.
Oczywiście jak najbardziej nie przeszkadza to prowadzić ewidencji
zamkniętych bugów.

Jak wspommiałem, pomysł ten kwalifikuję jako "interesujący".

do góry

Maciej Sobczak <s...@g...com> napisał(a):

> On 24 Maj, 02:58, Andrzej Jarzabek <a...@g...com> wrote:
>
> > No wi=EAc a propos tego, to w Shore&Warden jest interesuj=B1ca sugestia,
> > =BFeby w og=F3le nie utrzymywa=E6 bazy bug=F3w.
>
> Heh? Fikcja z czapki.
> Jaka=B6 baza musi by=E6. Czy to s=B1 "zadania", czy "bugi", to kwestia
> nazw.
>
> Nawet je=B6li nie ma bazy typu JIRA czy FogBugz, to ta sama informacja
> (np. informacja o tym, =BFe kierownik projektu kaza=B3=A0Krzychowi zrobi=E6=
> X
> a Krzychu to zrobi=B3) i tak musi gdzie=B6 zaistnie=E6, nawet je=B6li jest =
> to
> w postaci historii maili w zespole.
> Nie wyobra=BFam sobie projektu, gdzie takiej informacji nie ma.
>

imo wogole takie zewnetrzne informacje (produkcja papierow nt samego
procesu produkcji) sa mniej wazne niz informacje bardziej 'wewnetrzne' -
dla glow ludzi danego projektu, informacje obejmujace znajomosc danego
api czy struktury danego programu ktory sie rozbudowywuje itp

mz dobre skutki moglo by przyniesc zarzadzanie owa 'wiedza wewnetrzna'
tj ta wiedza ktora musza znac ludzie ktorzy potrzebuja zrobic dany projekt;
zgromadznie jej - doskonaleni jej - dawanie jej sie do nauczenia -
wyeksponowanie w swietej gablocie

:/ ?

mi organiazowanie ludzi czy zarzadzanie nimi wieje ciezka groza
[i chyba bede musial odsskakac tego posta]
ale taki scroll of wizdom moze by uszedl? niewazne bell to w dzyń,
dzwoń to w dong


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 24 Maj, 23:45, Andrzej Jarzabek <a...@g...com> wrote:

> Nie no, oczywiście że nie postulują, żeby informacji nie było. Chodzi
> raczej o to, że infrastruktura mająca na celu katalogowanie i
> zarządzaniu dużą ilością otwartych bugów na raz jest uważana za
> demoralizującą. Że w momencie, kiedy ilość otwartych bugów staje się tak
> duża, że pojawia się potrzeba bazy typu JIRA, to znaczy, że robisz za
> dużo bugów i zamiast zakładać bazę powinieneś zlikwidować przyczynę.

Wylewanie dziecka z kąpielą. Proponuję wprowadzić regułę do "procesu":
lista bugów ma się zmieścić na ekranie szefa projektu. Nie przeszkadza
to w użyciu narzędzi typu JIRA/FogBugz/etc., wręcz przeciwnie - bo w
końcu w czymś trzeba tą listę wyświetlić, żeby się przekonać, czy na
pewno się mieści na ekranie. :-)

Zmodyfikowałbym ten pomysł w ten sposób: używaj prostych narzędzi
katalogujących bugi, bo skomplikowane są niepotrzebne. I to,
ironicznie, jedynie potwierdza moje zdanie: nie róbmy fetyszu z
narzędzi. Ale też nie róbmy sobie jaj z rzetelności zawodowej.
*Prosty* katalog bugów/zadań jest jak najbardziej wskazany, chyba w
każdym projekcie.

> Jak wspommiałem, pomysł ten kwalifikuję jako "interesujący".

A ja go kwalifikuję jako farmazon i utwierdzam się w przekonaniu, że
agile to próba kreowania nowych buzzwordów bez istotnej wartości
dodanej - zwłaszcza, jeśli większość tych haseł to pomysły, czego nie
robić. Takie budowanie bez betoniarki...

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

do góry

W dniu 2011-05-25 14:16, Maciej Sobczak pisze:
> On 24 Maj, 23:45, Andrzej Jarzabek<a...@g...com> wrote:
>
>> Nie no, oczywiście że nie postulują, żeby informacji nie było. Chodzi
>> raczej o to, że infrastruktura mająca na celu katalogowanie i
>> zarządzaniu dużą ilością otwartych bugów na raz jest uważana za
>> demoralizującą. Że w momencie, kiedy ilość otwartych bugów staje się tak
>> duża, że pojawia się potrzeba bazy typu JIRA, to znaczy, że robisz za
>> dużo bugów i zamiast zakładać bazę powinieneś zlikwidować przyczynę.
>
> Wylewanie dziecka z kąpielą. Proponuję wprowadzić regułę do "procesu":
> lista bugów ma się zmieścić na ekranie szefa projektu. Nie przeszkadza
> to w użyciu narzędzi typu JIRA/FogBugz/etc., wręcz przeciwnie - bo w
> końcu w czymś trzeba tą listę wyświetlić, żeby się przekonać, czy na
> pewno się mieści na ekranie. :-)

Kanban postuluje m.in. to właśnie. Jeśli liczba zadań w określonym
stanie przekracza wartość krytyczną dla danego stanu, to cały wysiłek
zespołu jest skierowany na zmniejszenie liczby zadań w tym stanie.
W szczególności liczba zadań w stanie "bug". Wystarczy ustalić limit
bugów na liczba osób w zespole /2 i na jednej stronie raczej się
zmieści.

> Zmodyfikowałbym ten pomysł w ten sposób: używaj prostych narzędzi
> katalogujących bugi, bo skomplikowane są niepotrzebne. I to,
> ironicznie, jedynie potwierdza moje zdanie: nie róbmy fetyszu z
> narzędzi.

Dlatego w wielu wypadkach kartka i długopis oraz tablica korkowa
z post-itami sprawdza się najlepiej 8-)

> Ale też nie róbmy sobie jaj z rzetelności zawodowej.
> *Prosty* katalog bugów/zadań jest jak najbardziej wskazany, chyba w
> każdym projekcie.

Choćby po to, żeby wiedzieć, ile ich mamy. Bez takiej wiedzy to
kompletny "Czy leci z nami pilot?".

>> Jak wspommiałem, pomysł ten kwalifikuję jako "interesujący".
>
> A ja go kwalifikuję jako farmazon i utwierdzam się w przekonaniu, że
> agile to próba kreowania nowych buzzwordów bez istotnej wartości
> dodanej - zwłaszcza, jeśli większość tych haseł to pomysły, czego nie
> robić. Takie budowanie bez betoniarki...

Podejrzewam, że ideą było skrócenie maksymalnej liczby bugów do 1.
Fajne, ale nierealne.

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

do góry

On May 25, 1:16 pm, Maciej Sobczak <s...@g...com> wrote:
> On 24 Maj, 23:45, Andrzej Jarzabek <a...@g...com> wrote:
>
> > Nie no, oczywiście że nie postulują, żeby informacji nie było. Chodzi
> > raczej o to, że infrastruktura mająca na celu katalogowanie i
> > zarządzaniu dużą ilością otwartych bugów na raz jest uważana za
> > demoralizującą. Że w momencie, kiedy ilość otwartych bugów staje się tak
> > duża, że pojawia się potrzeba bazy typu JIRA, to znaczy, że robisz za
> > dużo bugów i zamiast zakładać bazę powinieneś zlikwidować przyczynę.
>
> Wylewanie dziecka z kąpielą. Proponuję wprowadzić regułę do "procesu":
> lista bugów ma się zmieścić na ekranie szefa projektu. Nie przeszkadza
> to w użyciu narzędzi typu JIRA/FogBugz/etc., wręcz przeciwnie - bo w
> końcu w czymś trzeba tą listę wyświetlić, żeby się przekonać, czy na
> pewno się mieści na ekranie. :-)

No więc oni uważają, że to zdecydowanie za dużo. Pół żartem mogę
powiedzieć, że masz tak dużo, bo nie stosujesz TDD.

Z tego co rozumiem, to w S&W przez większość czasu powinienes nie mieć
żadnych bugów w ogóle (o których wiesz). Jeśli masz regularnie więcej
niż jednego otwartego buga, to powinieneś najpierw poprawić wszystkie
bugi, potem zlikwidować przyczynę bugów, a potem dopiero dokładać nową
funkcjonalność.

Przy czym jeszcze raz przypomnę, że to jest metodologia dostosowana do
małych zespołów i się nie skaluje.

> > Jak wspommiałem, pomysł ten kwalifikuję jako "interesujący".
>
> A ja go kwalifikuję jako farmazon i utwierdzam się w przekonaniu, że
> agile to próba kreowania nowych buzzwordów bez istotnej wartości
> dodanej - zwłaszcza, jeśli większość tych haseł to pomysły, czego nie
> robić. Takie budowanie bez betoniarki...

Po pierwsze to jednak nieprawda, że większość to pomysły, czego nie
robić. W konkretnych metodologiach jest bardzo dużo o tym, co właśnie
należy robić i jak: planowanie, customer involvement, TDD, coding
standards, refaktoryzacja, programowanie parami, continuous
integration, informative workspace, root cause analysis, retrospektywy
itd. itp.

Jeśli chodzi o to, czy to buzzwordy, to może to tak wyglądać w
dyskusji usenetowej, ale przecież nie będę przepisywał książki. Piszę
np. TDD bez wyjasniania o co chodzi, bo zakładam, że dyskutant wie, a
jak nie wie, to sobie wygugla. Ale oczywiście samo TDD to temat na
osobną książkę, i też niejedna została napisana - mam właśnie w ręku
"Growing Object-Oriented Software Guided by Teses" Steve'a Freemana i
Nata Pryce'a.

do góry

On May 25, 1:56 pm, Paweł Kierski <n...@p...net> wrote:
> W dniu 2011-05-25 14:16, Maciej Sobczak pisze:
>
> > Wylewanie dziecka z kąpielą. Proponuję wprowadzić regułę do "procesu":
> > lista bugów ma się zmieścić na ekranie szefa projektu. Nie przeszkadza
> > to w użyciu narzędzi typu JIRA/FogBugz/etc., wręcz przeciwnie - bo w
> > końcu w czymś trzeba tą listę wyświetlić, żeby się przekonać, czy na
> > pewno się mieści na ekranie. :-)
>
> Kanban postuluje m.in. to właśnie. Jeśli liczba zadań w określonym
> stanie przekracza wartość krytyczną dla danego stanu, to cały wysiłek
> zespołu jest skierowany na zmniejszenie liczby zadań w tym stanie.
> W szczególności liczba zadań w stanie "bug". Wystarczy ustalić limit
> bugów na liczba osób w zespole /2 i na jednej stronie raczej się
> zmieści.
[...]
> Podejrzewam, że ideą było skrócenie maksymalnej liczby bugów do 1.
> Fajne, ale nierealne.

Shore&Warden proponują właśnie ustalenie tej liczby na 1. Co do
realności, to twierdzą, że uzyskanie tego jest uwarunkowane
stosowaniem odpowiednich praktyk, przede wszystkim TDD.

Dlaczego ty uważasz, że jest to nierealne? (Nie mówię, że ja uważam
inaczej, po prostu jestem ciekaw).

> Dlatego w wielu wypadkach kartka i długopis oraz tablica korkowa
> z post-itami sprawdza się najlepiej 8-)

No więc oczywiście sugestia braku bazy bugów nie dotyczyła tablicy
korkowej. Tablica korkowa to "informative workspace", a fakt, że masz
buga to najbardziej istotna informacja, jaka może być.

> > Ale też nie róbmy sobie jaj z rzetelności zawodowej.
> > *Prosty* katalog bugów/zadań jest jak najbardziej wskazany, chyba w
> > każdym projekcie.
>
> Choćby po to, żeby wiedzieć, ile ich mamy. Bez takiej wiedzy to
> kompletny "Czy leci z nami pilot?".

Jeśli zwykle nie masz bugów, czasem masz jednego, a naprawdę wyjątkowo
masz więcej, to chyba nie potrzebujesz "bazy bugów"?

do góry

W dniu 2011-05-25 15:15, Andrzej Jarzabek pisze:
> On May 25, 1:56 pm, Paweł Kierski<n...@p...net> wrote:
>> W dniu 2011-05-25 14:16, Maciej Sobczak pisze:
>>
>>> Wylewanie dziecka z kąpielą. Proponuję wprowadzić regułę do "procesu":
>>> lista bugów ma się zmieścić na ekranie szefa projektu. Nie przeszkadza
>>> to w użyciu narzędzi typu JIRA/FogBugz/etc., wręcz przeciwnie - bo w
>>> końcu w czymś trzeba tą listę wyświetlić, żeby się przekonać, czy na
>>> pewno się mieści na ekranie. :-)
>>
>> Kanban postuluje m.in. to właśnie. Jeśli liczba zadań w określonym
>> stanie przekracza wartość krytyczną dla danego stanu, to cały wysiłek
>> zespołu jest skierowany na zmniejszenie liczby zadań w tym stanie.
>> W szczególności liczba zadań w stanie "bug". Wystarczy ustalić limit
>> bugów na liczba osób w zespole /2 i na jednej stronie raczej się
>> zmieści.
> [...]
>> Podejrzewam, że ideą było skrócenie maksymalnej liczby bugów do 1.
>> Fajne, ale nierealne.
>
> Shore&Warden proponują właśnie ustalenie tej liczby na 1. Co do
> realności, to twierdzą, że uzyskanie tego jest uwarunkowane
> stosowaniem odpowiednich praktyk, przede wszystkim TDD.
>
> Dlaczego ty uważasz, że jest to nierealne? (Nie mówię, że ja uważam
> inaczej, po prostu jestem ciekaw).

To co napisałeś obok wyjaśnia sprawę. Realne może jest w bardzo małym
zespole i małym projekcie. W dużym intensywność testowania i używania
może łatwo doprowadzać do sytuacji więcej niż jednego wykrytego błędu.
Niezależnie od TDD, bo tu zgadzam się Maciejem - nie da się za pomocą
TDD zapewnić takiego odsiania błędów.

>> Dlatego w wielu wypadkach kartka i długopis oraz tablica korkowa
>> z post-itami sprawdza się najlepiej 8-)
>
> No więc oczywiście sugestia braku bazy bugów nie dotyczyła tablicy
> korkowej. Tablica korkowa to "informative workspace", a fakt, że masz
> buga to najbardziej istotna informacja, jaka może być.
>
>>> Ale też nie róbmy sobie jaj z rzetelności zawodowej.
>>> *Prosty* katalog bugów/zadań jest jak najbardziej wskazany, chyba w
>>> każdym projekcie.
>>
>> Choćby po to, żeby wiedzieć, ile ich mamy. Bez takiej wiedzy to
>> kompletny "Czy leci z nami pilot?".
>
> Jeśli zwykle nie masz bugów, czasem masz jednego, a naprawdę wyjątkowo
> masz więcej, to chyba nie potrzebujesz "bazy bugów"?

Kwestia nazewnictwa. Dzięki brakowi wyjaśnienia podstawowych pojęć (tu
"baza bugów") wyglądało, jakbyście z Maciejem mieli różne zdanie.
A śmiem twierdzić, że jest wręcz przeciwnie - jest miejsce, gdzie bugi
są spisane i obaj się zgadzacie co do konieczności istnienia takiego
miejsca. Jakkolwiek je nazwać 8-)

Ogólnie mam wrażenie, że cała dyskusja agile vs. waterfall sprowadza się
do takich właśnie nieporozumień. Gdyby wyraźnie powiedzieć, że np.:
- waterfall to proces iteracyjny z niewielką liczbą iteracji (być może
jedną),
- w iteracjach agile istnieje faza analizy (być może uproszczona,
gdzie ryzyko tego uproszczenia jest wkalkulowane w koszty)
to okazałoby się, że mówimy o tym samym procesie różniącym się pewnymi
parametrami.

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

do góry

On May 25, 2:27 pm, Paweł Kierski <n...@p...net> wrote:
> W dniu 2011-05-25 15:15, Andrzej Jarzabek pisze:
>
> To co napisałeś obok wyjaśnia sprawę. Realne może jest w bardzo małym
> zespole i małym projekcie. W dużym intensywność testowania i używania
> może łatwo doprowadzać do sytuacji więcej niż jednego wykrytego błędu.

No, ten pomysł jest podany w ramach bardzo konkretnej metodologii
opisanej w książce, ale wydał mi się tak radykalny, że nawet przy tych
założeniach moją pierwszą myślą było "ciekawe, czy to się w praktyce
da zrobić?"

> Niezależnie od TDD, bo tu zgadzam się Maciejem - nie da się za pomocą
> TDD zapewnić takiego odsiania błędów.

Nie no, nie jest to zależne od TDD, bo TDD jednak podobno zdecydowanie
pomaga w redukcji ilości bugów, więc teoria jest taka, że z TDD jest
to możliwe w takim małym zespole, a bez TDD nawet w małym będzie
trudne. Co generalnie (przynajmniej jeśli chodzi o drugą część tego
zdania) potwierdza moje obserwacje.

> > Jeśli zwykle nie masz bugów, czasem masz jednego, a naprawdę wyjątkowo
> > masz więcej, to chyba nie potrzebujesz "bazy bugów"?
>
> Kwestia nazewnictwa. Dzięki brakowi wyjaśnienia podstawowych pojęć (tu
> "baza bugów") wyglądało, jakbyście z Maciejem mieli różne zdanie.
> A śmiem twierdzić, że jest wręcz przeciwnie - jest miejsce, gdzie bugi
> są spisane i obaj się zgadzacie co do konieczności istnienia takiego
> miejsca. Jakkolwiek je nazwać 8-)

No więc jeszcze raz: chodziło o narzędzie do zarządzania bugami ze
szczególnym uwzględnieniem bugów w danej chwili otwartych. W
szzególności to może wyglądać też tak, że masz bazę 'user stories',
którą utrzymuejsz, bo czasem trzeba przy danej story napisać trochę
więcej, niż się zmieści na karteczce, czasem implementacja danej story
odkładana jest na kilka iteracji do przodu i głupio by było w tym
czasie zgubić kartki. Więc taka baza ma sens. Ale jak cię korci, żeby
tej bazy używać też do bugów, lub mieć drugą taką do bugów, to
powinieneś się jednak powstrzymać, bo (jak głosi metodologia) nie
będzie ci potrzebna, a co gorsza działa demoralizująco.

> Ogólnie mam wrażenie, że cała dyskusja agile vs. waterfall sprowadza się
> do takich właśnie nieporozumień. Gdyby wyraźnie powiedzieć, że np.:
>   - waterfall to proces iteracyjny z niewielką liczbą iteracji (być może
> jedną),
>   - w iteracjach agile istnieje faza analizy (być może uproszczona,
> gdzie ryzyko tego uproszczenia jest wkalkulowane w koszty)
> to okazałoby się, że mówimy o tym samym procesie różniącym się pewnymi
> parametrami.

No ale te parametry robią różnicę, jest taki moment, kiedy ilość
przechodzi w jakość - np. czy dana faza trwa dwa miesiące, czy jest
trimeboxowana na 15 minut.

do góry