Podążając za namową uczestników iteracji pierwszej Agile Underground w Krakowie zdecydowałem się rozpocząć spisywanie i prowokowanie do dyskusji na temat problemów związanych z wprowadzaniem agile'owych praktyk w warunkach bojowych.
Zdecydowałem się zorganizować tę serię tak jak prezentację/dyskusję podczas Agile Underground. Każdy wpis będzie dotyczył jednej miny. Mina jak to mina, ma tendencję efektownie wybuchać gdy się na nią wejdzie, w czym związane są zwykle pewne obrażenia, czasem poważne, nawet krytyczne. O ile analogie w inżynierii oprogramowania do tej pory wyrządziły raczej więcej szkód niż pożytku to tę analogie uważam za trafną i nieszkodliwą. Miny, które zamierzam tutaj przedstawiać, mogą być powodem poważnych kłopotów podczas realizacji projektów, komplikacji pracy zespołów lub ich rozpadu. Niektóre takie miny są niegroźne w skutkach bezpośrednich, ale za to napsują tyle powietrza wkoło, że potem nikt nie chce słyszeć o kolejnym projekcie tymi dziwnymi metodami.
Zdecydowana większość opisów i przemyśleń bierze początek w mojej praktyce zawodowej, ale również jest owocem moich rozmów na różnych forach czy konferencjach, w szczególności z dr Lechem Madeyskim z Politechniki Wrocławskiej, moim serdecznym kolegą z którym napisałem kiedyś artykuł na konferencję, który z kolei stał się podstawą do rzeczonej prezentacji na Agile Underground.
Co bystrzejsi czytelnicy zdążyli się już zorientować, że do prowadzenia bloga wybrałem nasz język ojczysty. Przyczynę dlaczego tak wybrałem wyjawię w odpowiednim czasie ;). Wiem jednak, że będę tego żałował bo pewnie już przy pierwszym wpisie będę się skręcał wymyślając tłumaczenia angielskich sformułowań, więc bardzo proszę Was o wyrozumiałość, gdy będę po polsku odmieniał słowo agile czy bez tłumaczenia używał terminu Stand-Up Meeting czy Daily Scrum. Bo wybaczcie ale zwinny to był mój kot, dopóki mojej żony pies go nie przegonił z mieszkania. Są rzeczy, których tłumaczenia bym nie przeżył.
Pierwszy wpis obiecuję już w ten weekend. Bardzo będę się starał trzymać pewną rytmikę wpisów, bo wiem że taka regularność będzie dobra dla obu stron, jednak dziać się to raczej będzie w moim tzw. czasie wolnym, czyli gdy uśpiłem już i dzieci i żonę, a udało mi się przy tym samemu nie zasnąć. Chciałbym obiecać przynajmniej jeden wpis na 2 tygodnie. Myślę, że na tyle mogę się zadeklarować.
Subskrybuj:
Komentarze do posta (Atom)
8 komentarzy:
Gratuluję :) I zapewniam wsparcie moralne :-)
Poradnik sapera... brzmi znajomo:) Ale z tym "młodym", to bym nie przesadzał ;)
Bardzo chętnie poczytam i może dorzucę swoje trzy grosze :-)
Jeśli masz już w planach jakąś listę min, to fajnie byłoby gdybyś ją zamieścił w najbliższym poście jaka taką zapowiedź (kolejność oczywiście nieistotna)... No chyba, że miny będą wybuchały niespodziewanie (jak to miny)
a Wy nie macie nic innego do roboty w sobotni wieczór? :)))
spoko, Bartosz, "młodego" jak najbardziej, po pierwsze ja czuję się młodo, po drugie to choć znam swoją wartość to w skali tego co sie w inżynierii oprogramowania działo do tej pory moje wysiłki są kroplą w oceanie
Marcin, myślałem o tym by dać taka listę ale zastanawiałem się czy to się komuś przyda, skoro prosisz to jakąś taką wstępną zrobię, bo nie wątpię, że jeszcze nowe miny odkryję do czasu jak opiszę te z dotychczasowej listy ;)
Listę min popieram w całej rozciągłości:)
BTW zastanawiam się nad relacją pomiędzy eksploracyjno-adaptacyjnym uczeniem się na błędach, a tym, że saper (podobno) myli się tylko raz...
To ukierunkowuje nasz tok myślenia na dociekanie istnienia "strefy buforowej"... ? ;-)
Pamiętaj o tym, że kropla drąży skałę, a relatywnie (biorąc pod uwagę uwarunkowania... geograficzne, to jeśli nie jednym z prekursorów, to i tak jesteś starym wyjadaczem).
czy saper raz sie myli? jak mówiłem metafora to bardzo niebezpieczne narzędzie, sam widzisz, może prowadzić do zupełnie błędnych wniosków, moim zdaniem nie jest problemem używanie metafor tylko rozumienie jakie są granice zastosowania konkretnej metafory, i tak w tym przypadku długość życia sapera, niekoniecznie odpowiada okresowi zatrudnienia informatyka w danej firmie ;) albo raczej
a "strefa buforowa" jest ograniczona tylko cierpliwością Twojego szefa .. albo klienta ;)))
Ostrzegam, że będę się starał prowokować ożywioną dyskusję ;-)
Zawsze myślałem, że możliwość jednej i zarazem ostatniej pomyłki sapera to obiektywne uwarunkowanie -i z uwagi na konsekwencje -niemożliwe do powtórzenia (przynajmniej w tym samym miejscu - no chyba, że mamy bufor w postaci rozmytej odpowiedzialności, wyrozumiałego klienta, czy duży kredyt zaufania od szefa). Dlatego nie wiem, czy możemy powiedzieć, że to jest metafora... czy saper asekurowany w ten sposób jest dalej saperem, czy też posługiwanie się tą metaforą na użytek wewnętrzny - stymulowanie psychiki - ma na celu większą wewnętrzną mobilizację - poprzez wyobrażanie sobie, że stoi w sytuacji podbramkowej, a każdy błąd to prawdopodobny koniec jego kariery ? ;-)
A propos metafor to czytam obecnie świetną książkę Garteha Morgana o tym jak poszczególne metafory wpływały na kosntruowanie organizacji i zarządzanie nimi "na przestrzeni dziejów". Jest to świetne zaobrazowanie historii zarządzania począwszy od nurtu mechanistycznego i "naukowego zarządzania", poprzez organizacje jako ekosystemy, mózgi (samorganizacja i zdolność do nauki oraz uczenia się jak się uczyć - skąd my to znamy :P), kultury, systemy polityczne, psychiczne więzienia, przepływ i transformacja, wreszcie narzędzia dominacji.
Morgan zauważa, że metafory używamy wtedy, kiedy usiłujemy zrozumieć jakis fragment rzeczywistości za pomocą innego jej fragmentu. Metafora stwarza zarys naszego zrozumienia w sposób charakterystyczny, ale cząstkowy; daje zawsze jednostronny pogląd na daną sprawę (poprzez abstrahowanie od kontekstu).
:D
Prześlij komentarz