To Receive such mails right in your InBox, type your E-mail Address
in the Box below and Click Subscribe to Funzug Mails button now.
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/
Teraz wypadałoby zrobić: "zwinne metodyki w praktyce: jak wykorzystać
user-stories w podrywie"
2008/11/12 Andy Brandt <akbr...@gmail.com>:
--
Tomasz Staniak
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>:
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
... 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
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>:
>
--
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
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