Most Sexiest Models of Florida on the Ramp (Video)

3 views
Skip to first unread message

Karina Malhotra

unread,
Nov 12, 2008, 1:44:11 AM11/12/08
to




~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For Excellent Mails of all kind
Click Here to Join Funzug in Just 3 Clicks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
**~*~*~*~*~*~**~**~*~*~*~*~*~**
Today's Top hits on Funzug:
**~*~*~*~*~*~**~**~*~*~*~*~*~**

top_florida.jpg
blepart2222222222222.gif
pillow_fight.jpg

Jakub Dziwisz

unread,
Nov 12, 2008, 2:18:33 AM11/12/08
to polish-agil...@googlegroups.com
Czesc,

z przykroscia zawiadamiam, ze Karina zostala usunieta z grupy. Jesli ktos ma ochote na wiecej spamu od niej, maila moge podac na priva ;).

A tak na serio, to przepraszam za smieci jakie poszly wczoraj.

Pozdrawiam,
Kuba.

Andy Brandt

unread,
Nov 12, 2008, 3:34:47 AM11/12/08
to polish-agil...@googlegroups.com
Hej!

No cóý, przynajmniej coú sić dziaůo. :)

Pozdrawiam,
Andy

2008/11/12 Jakub Dziwisz <dzi...@gmail.com>:

--
Regards,
Andy
http://www.codesprinters.com/
http://www.andybrandt.net/

Tomasz Staniak

unread,
Nov 12, 2008, 3:42:36 AM11/12/08
to polish-agil...@googlegroups.com
Przypomniała mi się dawna seria "webstandards", z (pół)nagimi
dziewczętami tłumaczącymi atrybuty CSS ;)

Teraz wypadałoby zrobić: "zwinne metodyki w praktyce: jak wykorzystać
user-stories w podrywie"

2008/11/12 Andy Brandt <akbr...@gmail.com>:

--
Tomasz Staniak

Jacek Rybicki

unread,
Nov 12, 2008, 5:53:07 AM11/12/08
to Polish Agile User Group
Zastanowiłem się, z punktu widzenia początkującego trenera, nad
wykorzystaniem metafory podrywu podczas przekazywania wiedzy. Jednak
przypomniałem sobie że do podobnych praktyk, jako uczestnik, odnosiłem
się bez entuzjazmu. Nie jest łatwo uniknąć oskarżenia o seksizm,
molestowanie czy wrażenia, że prezenter ma jakiś poważny brak.

Ale temat jest wart uwagi. Jakie metafory/porównania pracy z
praktykami Agile trafiają/trafiły do Waszego przekonania?

pozdrawiam,
Jacek

On 12 Lis, 09:42, "Tomasz Staniak" <nbw.desi...@gmail.com> wrote:
> Przypomniała mi się dawna seria "webstandards", z (pół)nagimi
> dziewczętami tłumaczącymi atrybuty CSS ;)
>
> Teraz wypadałoby zrobić: "zwinne metodyki w praktyce: jak wykorzystać
> user-stories w podrywie"
>
> 2008/11/12 Andy Brandt <akbra...@gmail.com>:
>
>
>
> > Hej!
>
> > No cóý, przynajmniej coú sić dziaůo. :)
>
> > Pozdrawiam,
> > Andy
>
> > 2008/11/12 Jakub Dziwisz <dziw...@gmail.com>:

Andy Brandt

unread,
Nov 12, 2008, 5:59:41 AM11/12/08
to polish-agil...@googlegroups.com
Witam!

Myślę, że bardzo efektywna jest metafora leżąca u podstaw nazwy Scrum
- wizja napierającego zespołu. Sęk w tym, że efektywna jest po
angielsku. W Polsce rugby jest nieznaną egzotyką - ja sam dowiedziałem
się w ogóle czegokolwiek na ten temat dopiero kiedy zetknąłem się ze
Scrumem i poza tą analogią rugby mnie kompletnie nie interesuje. Dalej
zatem szukam takiej metafory "na rynek Polski" - wspólnego napierania
zespołu.

W ogóle na szkoleniu w przyszłym tygodniu zamierzam zrobić "grę
skojarzeń" z agile - zobaczymy co wyjdzie, może być ciekawie.

Pozdrawiam,
Andy

2008/11/12 Jacek Rybicki <jack.r...@gmail.com>:

Daniel Drozdzewski

unread,
Nov 12, 2008, 6:30:27 AM11/12/08
to polish-agil...@googlegroups.com
2008/11/12 Andy Brandt <akbr...@gmail.com>:

> Witam!
>
> Myślę, że bardzo efektywna jest metafora leżąca u podstaw nazwy Scrum
> - wizja napierającego zespołu. Sęk w tym, że efektywna jest po
> angielsku. W Polsce rugby jest nieznaną egzotyką - ja sam dowiedziałem
> się w ogóle czegokolwiek na ten temat dopiero kiedy zetknąłem się ze
> Scrumem i poza tą analogią rugby mnie kompletnie nie interesuje. Dalej
> zatem szukam takiej metafory "na rynek Polski" - wspólnego napierania
> zespołu.
>
> W ogóle na szkoleniu w przyszłym tygodniu zamierzam zrobić "grę
> skojarzeń" z agile - zobaczymy co wyjdzie, może być ciekawie.

Tom DeMarco ma bardzo dobrą metaforę: Drużyna w projekcie
(niekoniecznie Agile czy Scrum) jest tak jak drużyna w przeciąganiu
liny.

I teraz moje dywagacje wokół metafory:
Liczy się nie tylko siła każdego zawodnika, ale także upewnianie się,
że ciagnięcie jest cykliczne i że wszycy ciągną w tym samym momenice
(co oczywiście generuje szczyty w sile przyłożonej do liny).
Ważne jest aby cykl ciągnięcia zgadzał się z cyklem drużyny
przeciwnej. Cykl = sprint czy też iteracja.
W software przeciwnicy to klienci - wiem że brzmi negatywnie. Bardzo
ważne jest aby tak na to nie patrzec i akcentowac ze dana drużyna jest
tak dobra, jak dobrzy są przeciwnicy. Nie jest sztuką grac i wygrac ze
słabym przeciwnikiem. Droga do doskonałości biegnie poprzez
przeciwników, którzy są warci potykania sie z nimi. Również w tej
metaforze ważne jest aby wszycy ciągnęli w tym samym kierunku. W
software daje nam to komunikacja i ciągłe upewnianie się, że podążamy
w jednym, dobrze zdefiniowanym celu (gol sprnitu).

Retrospekcja to rozmowa trenera w szatni po danym meczu.
Scrum master to ten członek drużyny, który krzyczy CIĄGNIJ! w ścisle
okreslonych momentach.


Najważniejsze jednak z metaforami jest, aby pamiętac, ze metafory
"ciekną", czyli że od czasu do czasu metafora nie będzie w stanie
wyjaśnic zjawiska, które staramy się metaforą opisac.
Podobnie dzieje się z abstrakcjami. Dobry artykuł Joel'a Spolsky'iego
o_O o prawie cieknących abstrakcji:
http://www.joelonsoftware.com/articles/LeakyAbstractions.html

Daniel

Jacek Rybicki

unread,
Nov 12, 2008, 9:16:15 AM11/12/08
to Polish Agile User Group
On 12 Lis, 12:30, "Daniel Drozdzewski" <daniel.drozdzew...@gmail.com>
wrote:
> Tom DeMarco ma bardzo dobrą metaforę: Drużyna w projekcie
> (niekoniecznie Agile czy Scrum) jest tak jak drużyna w przeciąganiu
> liny.
>

Przeciąganie liny? Nie polecam:
http://en.wikipedia.org/wiki/Ringelmann_effect

Z innych względów też nie podoba mi się wizja "krzyczenia w ściśle
określonych momentach". Dla mnie istotą jest komunikacja i to nie z
centrum na peryferia, czy też od jednostki do grupy, ale w całej
grupie.
Tak samo nie mogę zgodzić się z retrospekcją w modelu trener -
zawodnicy. Znów byłaby to komunikacja w jedną stronę. I nikt nie
pomyśli żeby trenerowi zwrócić uwagę na błędy, bo to jest naruszanie
reguł starszeństwa i podległości. A takich reguł nie chciałbym
wprowadzać.

O matko, podważam słowa DeMarco. A może tylko interpretację?

pozdrawiam,
Jacek

Daniel Drozdzewski

unread,
Nov 12, 2008, 10:04:57 AM11/12/08
to polish-agil...@googlegroups.com
2008/11/12 Jacek Rybicki <jack.r...@gmail.com>:

... tylko interpretację.
Efekt Ringelmana o którym wspominasz ma do czynienia z dyfuzją
motywacji, a nie brakiem komunikacji. Ponieważ jest to zjawisko
psychologiczne, podejrzewam, że zespół deweloperów jak i drużyna
ciągnąca linę, podlegną mu czy sie nam podoba czy też nie.
Przeciąganie liny jest dyscypliną zespołową i sukces/porażka zależą od
pracy indywidualistów w zespole. Co do komunikacji, to w takiej grze
zapewne zmysły każdego z uczestników służą do znacznej cześci
komunikacji. Widzę, że partner przede mną się pręży w cyklu
ciągnij-wyluzyj, więc ja też ciągnę synchronizując się z nim, zaś
partner za moimi plecami postępuje dokładnie jak ja. Trzymając linę w
garsci też sie czuje o co chodzi. Nie mniej jednak w każdej dobrej
orkiestrze dyrygent jest absolutnie niezbędnym ogniwem.
A to, że nie można trenerowi konstruktywnie wskazac pomyłek... zależy
od drużyny jak i od trenera. Zła drużyna, która nie stara się
polepszyc procesu, zły to trener który nie słucha.

W każdej metaforze możemy założyc, ze trener jest gburem i zawsze wie
najlepiej. Wcale nie załamuje to metafory, przynajmniej moim zdaniem,
wręcz przeciwnie. Zapewne drużyna z trenerem gburem nie jest tak
zgrana i dobra druzyna, jak ta, gdzie trener słucha zawodnikow. Co
więcej zawodnicy wolą grac w takich drużynach i są znacznie lepiej
zgranym zespołem.

...ale tak jak wspomniałem, każda metafora cieknie... wszystko
zależy, jak mocno staramy się załatac dziury. W przeciaganiu liny
ważne są buty... Jaki ich odpowiednik w zazadzaniu projektami IT? sam
widzisz, o co mi chodzi.

Pozdrawiam,

Daniel


>
> pozdrawiam,
> Jacek
>
>
> >
>

--
Daniel Drozdzewski

Jacek Rybicki

unread,
Nov 12, 2008, 1:24:54 PM11/12/08
to Polish Agile User Group
On Nov 12, 4:04 pm, "Daniel Drozdzewski"
<daniel.drozdzew...@gmail.com> wrote:
> ... tylko interpretację.
> Efekt Ringelmana o którym wspominasz ma do czynienia z dyfuzją
> motywacji, a nie brakiem komunikacji. Ponieważ jest to zjawisko
> psychologiczne, podejrzewam, że zespół deweloperów jak i drużyna
> ciągnąca linę, podlegną mu czy sie nam podoba czy też nie.

Podałem to dlatego, że użycie takiej metafory może zostać boleśnie
podważone, co szkodzi całości wykładu.

> Nie mniej jednak w każdej dobrej
> orkiestrze dyrygent jest absolutnie niezbędnym ogniwem.

Tutaj wychodzą nasze odmienne podejścia do zarządzania, prawdopodobnie
spowodowane różnymi warunkami w których pracujemy.
Wywnioskowałem to tylko na podstawie metafor, których używasz, więc
mogę się mylić.

Jest różnica pomiędzy zarządzaniem, a przewodnictwem. Podeprę się
tutaj metaforą Stephena Covey'a: jeżeli ludzie wycinają dżunglę, to
musi być ktoś, kto wdrapuje się na drzewo i sprawdza czy rąbią
właściwy las i musi być ktoś na ziemi, kto pilnuje czy ludzie się nie
przemęczają i czy narzędzia są ostre, ogólnie rozwiązuje doraźne
problemy.
No ale czy warto siedzieć cały czas na drzewie i wrzeszczeć "tak, to
ten las"? Zwracam też uwagę, że ten na ziemi wykonuje funckję
usługową. Dostarcza usługi polegającej na rozwiązywaniu problemów.

Porównania do dyrygenta i trenera rugby są dla mnie sprzeczne z moim
wyobrażeniem pracy w grupie. Jeżeli ludzie przyzwyczają się do tego,
że ktoś nimi dyryguje, to pozbywają się odpowiedzialności za (co
najmniej) wszystko poza ich działką. Zdaję sobie sprawę, że zdolność
do podejmowania decyzji jest niezbędna w grupie. Jednak staram się,
aby taka decyzja nie musiała mieć jednego źródła. Czy wyobrażasz
sobie, że inna osoba w Twojej grupie w naturalny sposób przejmuje
funkcje lidera? Jeżeli jest taka opcja, to aktualny lider nie jest
osamotniony w rozwiązywaniu problemów. Jest szansa, że jeżeli podejmie
nienajlepszą decyzję, to dostanie informację zwrotną, a może nawet
bardziej pasujące rozwiązanie.

Taki poważny temat pod tak niepoważnym tytułem wątku :)

> ...ale tak jak wspomniałem, każda metafora cieknie...  wszystko
> zależy, jak mocno staramy się załatac dziury. W przeciaganiu liny
> ważne są buty... Jaki ich odpowiednik w zazadzaniu projektami IT? sam
> widzisz, o co mi chodzi.

Bardzo podoba mi się ta metafora "przeciekania" :) Dzięki za wskazanie
artykułu Joel'a, nie wszystkie jego pomysły czytam i czasem
przepuszczam takie perełki.

A buty? "Powiedz mi z czym kojarzą Ci się buty bandy spoconych facetów
(lub kobiet oczywiście) a powiem Ci kim jesteś" ;)
Buty są czymś co przynosimy ze sobą i na czym musimy polegać. Mogą być
to zatem narzędzia, których używamy, praktyki, które stosujemy. Czy
użycie nowych, dynamicznych, interpretowanych butów da nam lepszą
przyczepność na rynku niż gdy użyjemy chodaków natywnie wbijających
się w podłoże? W co lepiej zainwestować? W nowe buty czy dodatkowe
treningi zespołu? Ależ się przyczepiłem.

>
> Pozdrawiam,
>
> Daniel

pozdrawiam,
Jacek

Andy Brandt

unread,
Nov 13, 2008, 3:58:15 AM11/13/08
to polish-agil...@googlegroups.com
Witam!

Czytam tą dyskusję i mam wrażenie, że metafory traktujecie jako coś
więcej niż są. Metafory to po prostu pewne obrazki mające ułatwić
przekazanie pewnego mentalnego znaczenia innym. Rozbieranie ich na
drobne kawałki i analizowanie w szczegółach nie ma sensu. Metafora to
taki mentalny piktogram - zerkasz na niego i wiesz o co chodzi, bez
analizowania każdej kreski.

Pozdrawiam,
Andy

2008/11/12 Jacek Rybicki <jack.r...@gmail.com>:
>

--

Daniel Drozdzewski

unread,
Nov 14, 2008, 11:18:03 AM11/14/08
to polish-agil...@googlegroups.com
2008/11/13 Andy Brandt <akbr...@gmail.com>:

> Witam!
>
> Czytam tą dyskusję i mam wrażenie, że metafory traktujecie jako coś
> więcej niż są. Metafory to po prostu pewne obrazki mające ułatwić
> przekazanie pewnego mentalnego znaczenia innym. Rozbieranie ich na
> drobne kawałki i analizowanie w szczegółach nie ma sensu. Metafora to
> taki mentalny piktogram - zerkasz na niego i wiesz o co chodzi, bez
> analizowania każdej kreski.
>
> Pozdrawiam,
> Andy

Andy,

Masz rację co do brnięcia zbyt głęboko w metafory. Dzięki za zwrócenie uwagi!
Dobrze, że ktoś potrafi spojrzec szerzej na sprawy.

Daniel

--
Daniel Drozdzewski

Jacek Rybicki

unread,
Nov 14, 2008, 1:47:53 PM11/14/08
to Polish Agile User Group

On Nov 13, 9:58 am, "Andy Brandt" <akbra...@gmail.com> wrote:
> Witam!
>
> Czytam tą dyskusję i mam wrażenie, że metafory traktujecie jako coś
> więcej niż są. Metafory to po prostu pewne obrazki mające ułatwić
> przekazanie pewnego mentalnego znaczenia innym. Rozbieranie ich na
> drobne kawałki i analizowanie w szczegółach nie ma sensu. Metafora to
> taki mentalny piktogram - zerkasz na niego i wiesz o co chodzi, bez
> analizowania każdej kreski.
>
> Pozdrawiam,
> Andy

Andy,
Dałem sobie trochę czasu na przemyślenia i zgodzę się z Tobą co do
jednego, że doszło do przesady. To mi przypomniało sytuację, jak to
manager ze strony klienta, bardzo dobrze operujący słowem, na jednym
ze spotkań tak rozbudowywał metaforę, że doprowadził do irytacji
swojego szefa.
Jednak grzebanie się w tym temacie zwróciło moją uwagę na pewne sprawy
i przyczyniło się do powstania kilku pomysłów.

Co do samych metafor, to zastanów się jeszcze raz. To jakich obrazków
(=tysiąc słów) używasz powinno odpowiadać temu co chcesz przekazać,
więc ich właściwy dobór jest bardzo ważny. Chcę szybko się
komunikować, więc często używam metafor. Zastosowanie metafory z rugby
czy baseball'u nie jest w naszej kulturze najlepsze, więc trzeba się
adaptować. Masz gotowe rozwiązania? Chętnie czegoś się nauczę. Ale
przenieśmy rozmowę do innego wątku.

pozdrawiam,
Jacek

Tomasz Staniak

unread,
Nov 14, 2008, 3:28:10 PM11/14/08
to polish-agil...@googlegroups.com
> Co do samych metafor, to zastanów się jeszcze raz. To jakich obrazków
> (=tysiąc słów) używasz powinno odpowiadać temu co chcesz przekazać,
> więc ich właściwy dobór jest bardzo ważny. Chcę szybko się
> komunikować, więc często używam metafor. Zastosowanie metafory z rugby
> czy baseball'u nie jest w naszej kulturze najlepsze, więc trzeba się
> adaptować. Masz gotowe rozwiązania? Chętnie czegoś się nauczę. Ale
> przenieśmy rozmowę do innego wątku.

IMHO nie ma czegoś takiego jak gotowe rozwiązania. Paradoksalnie, może
się okazać, że osoba której tłumaczysz scrum kibicuje Budowlanym Łódź
i doskonale zna się na rugby; do innej z kolei może trafić np
porównanie test driven development z przygodnym seksem. Poszukiwanie
idealnej metafory samo w sobie jest skazane na porażkę bo ludzie są
różni. I z tej perspektywy, również jestem zdania, że dyskusja zaszła
za głęboko w tej materii :) I raczej punktem wyjścia jest nie tyle to,
co chcesz przekazać ile to, do kogo chcesz dotrzeć :)

A tak w temacie, ale poza sprawą: do mnie osobiście najlepiej trafiają
antyprzykłady, nie metafory.


--
Tomasz Staniak

Reply all
Reply to author
Forward
0 new messages