Pewnie bym nie napisał tego postu, gdyby mnie Michał nie namówił.
Ostatnie kilka miesięcy to czas, w którym generalizował mi się jeden wniosek, którego chyba nie chciałem przyjąć do wiadomości, choć z drugiej strony wydaje się być całkiem zrozumiały.
Jaka jest rzeczywistość projektowa w dużej części firm? Jest tzw. biznes tudzież klient, który nie wie czego chce i jednocześnie jest generatorem oraz sponsorem projektów. Zazwyczaj biznes dość nieprecyzyjnie określa zakres projektu, oczekując dość precyzyjnego oszacowania kosztów projektu. I tak zwane IT jakoś to szacuje (!). A później musi się z tego wywiązać. Oczywiście z czasem się okazuje, że jednak nie wszystko zostało uwzględnione w oszacowaniu oraz klient zmienił zdanie w międzyczasie, więc często nie ma szans na wykonanie projektu w czasie - pozostają nadgodziny lub przesunięcia terminów.
Ponieważ nastąpiło wyraźne niedoszacowanie, toteż nie "ma czasu" na dobre praktyki projektowe, a w zasadzie jest czas na wszelkie możliwe antywzorce programowania. W efekcie robi się coraz większy burdel i jest coraz gorzej. Można wylewać pomyje na biznes, jacy to są nierozgarnięci, niezorganizowani i nie wiedzą czego chcą... ale hola hola spójrzmy na siebie. Coraz więcej przykładów, z którymi się spotykam, prowadzi do następujących wniosków, odnośnie tego, co jest źródłem problemów... a raczej kto! Wiecie kto? Liderzy i/lub kierownicy, którzy wywodzą się z backgroundu technicznego, gdyż zwyczajnie sobie nie radzą w drapieżnym świecie biznesowym i tu się zaczynają problemy. Gdybym miał wymienić główne grzechy to byłyby one następujące:
* za bardzo ciągnie do technikaliów - a wiadomo, że jak pojawiają się trudne sytuacje, to wolimy się zajmować tym, co lepiej znamy; zatem w kryzysowym momencie lider techniczny, zamiast ratować zespół, projekt, rozwiązuje niezwykle istotny problem z najnowszym frameworkiem;
* procesy wytwórcze są mało istotne - niestety my, osoby techniczne, mamy mylne przekonanie, że jak będziemy mieli świetny koncept techniczny to reszta w projekcie sama się ułoży. Gówno prawda! Nic się samo nie układa. Trzeba się nieźle narobić, żeby utrzymać w ryzach zespół, klienta, projekt...;
* ulegamy biznesowi - powszechne tłumaczenie, dlaczego IT zgodziło się na realizację projektu, na który nie ma wystarczających zasobów oraz czasu, to że biznes naciska; tak kochani, jesteśmy za MIĘTCY, biznes rządzi, biznes wykłada pieniądze, my nie mamy nic do powiedzenia... bzdura, to zwykły brak asertywności i umiejętności szukania korzystnych dla obu stron rozwiązań; z drugiej strony rzadziej spotykana postawa NIE BO NIE, to też nie jest rozwiązanie;
* nie potrafimy rozwiązywać trudnych tematów personalnych - wielokrotnie widziałem ciągnące się miesiącami sytuacje, kiedy ktoś z zespołu się obraża, bo jego zdanie nie zostało uwzględnione lub gdy mu się zwraca uwagę, mało kto ma odwagę i umiejętności podjąć temat i rozwiązać problem;
* zamykamy się w boxach - lubimy jak nikt nam nie przeszkadza, gdy zaszywamy się w bezpiecznym kącie i klepiemy... do tego jeszcze słuchawki na uszy; kiedy stajemy się liderami, niestety ten nawyk pozostaje; bycie liderem to przede wszystkim interakcje i rozwiązywanie problemów - tego się nie da zrobić chowając się w boxie;
* brak informowania - złota zasada projektowania zwinnego mówi - podejmuj decyzje projektowe najpóźniej, kiedy to możliwe; wiele osób wzięło sobie to do serca, ale w innym kontekście - najczęściej informują o problemach w projekcie, najpóźniej kiedy to możliwe, a zazwyczaj wtedy jest już za późno...
sobota, 24 listopada 2012
środa, 5 września 2012
Zaufanie w zespole
Jedną z głównych wartości metodyk zwinnych jest zaufanie. Nie zawsze jest jasne co to oznacza.
Mały wycinek kluczowych spostrzeżeń z mojego notatnika na ten temat:
• Łatwo jest kierować niedoświadczonymi osobami (wtedy działa command-and-control), bo możemy im wmówić jak wygląda świat.
• Doświadczeni pracownicy, mają swoje doświadczenia, tak łatwo nie przyjmują tego co mamy do powiedzenia.
• Żeby z ludźmi bez względu na doświadczenie efektywnie współpracować, potrzebne jest Zaufanie (!), ono otwiera drogę do zadawania otwartych pytań, w efekcie daje możliwość poszukiwania lepszego niż obecny sposób działania.
• Czym jest zaufanie (przykład podstawowych zasad):
○ Zakładamy co do zachowań w 100% pozytywną intencję
○ Zakładamy, że wszelkie zadawane pytania, służą szukaniu rozwiązań (a nie np. znalezienia winnych) - pytania są wyrazem TROSKI. Ufamy w intencję rozmówcy, nawet jak rozmówca zadaje TRUDNE pytania.
○ Zakładamy, że zawsze odpowiadamy szczerze na pytania, nawet jeśli odpowiedź może wydawać się trudna.
Co najbardziej przeszkadza w pełnej zaufaniu szczerej rozmowie? Kiedy zakładasz, że "wiesz" jak to o czym rozmawiacie powinno zostać zrobione (jaki framework, jaki wzorzec, jaka klasa, jaki zestaw metod, jak to powinno wyglądać). Wtedy zamiast słuchać i dyskutować, dążysz za wszelką cenę, aby dowieść jedynej słuszności swojego rozwiązania. Być może uda Ci się wygrać tę bitwę, ale przegrasz całą wojnę. Zaufanie zostanie nadwyrężone lub zniszczone.
Jeśli między wami jest pewna zależność podległości, sprawa ma się tym gorzej. Jeśli jesteś kierownikiem, posłuchaj co ma do powiedzenia Twój podwładny. I dopiero ZADAJĄC PYTANIA sprawdzaj, czy jego koncepcja jest poprawna. Może będzie lepsza niż Twoja. A może nie. Dobre pytania dobrze to zweryfikują.
No dobra, ale po co jest to zaufanie? Nie można się bez niego obejść? Jeśli nie ma zaufania, wtedy naturalną kwestią jest zabezpieczanie swoich interesów (dupochrony, job security, czy różnego rodzaju gry projektowe http://mbartyzel.blogspot.com/2011/09/w-co-gra-sie-w-projektach.html). Tego typu aktywności prowadzą do niepożądanych efektów ubocznych (i straty czasu i wiarygodności).
Mały wycinek kluczowych spostrzeżeń z mojego notatnika na ten temat:
• Łatwo jest kierować niedoświadczonymi osobami (wtedy działa command-and-control), bo możemy im wmówić jak wygląda świat.
• Doświadczeni pracownicy, mają swoje doświadczenia, tak łatwo nie przyjmują tego co mamy do powiedzenia.
• Żeby z ludźmi bez względu na doświadczenie efektywnie współpracować, potrzebne jest Zaufanie (!), ono otwiera drogę do zadawania otwartych pytań, w efekcie daje możliwość poszukiwania lepszego niż obecny sposób działania.
• Czym jest zaufanie (przykład podstawowych zasad):
○ Zakładamy co do zachowań w 100% pozytywną intencję
○ Zakładamy, że wszelkie zadawane pytania, służą szukaniu rozwiązań (a nie np. znalezienia winnych) - pytania są wyrazem TROSKI. Ufamy w intencję rozmówcy, nawet jak rozmówca zadaje TRUDNE pytania.
○ Zakładamy, że zawsze odpowiadamy szczerze na pytania, nawet jeśli odpowiedź może wydawać się trudna.
Co najbardziej przeszkadza w pełnej zaufaniu szczerej rozmowie? Kiedy zakładasz, że "wiesz" jak to o czym rozmawiacie powinno zostać zrobione (jaki framework, jaki wzorzec, jaka klasa, jaki zestaw metod, jak to powinno wyglądać). Wtedy zamiast słuchać i dyskutować, dążysz za wszelką cenę, aby dowieść jedynej słuszności swojego rozwiązania. Być może uda Ci się wygrać tę bitwę, ale przegrasz całą wojnę. Zaufanie zostanie nadwyrężone lub zniszczone.
Jeśli między wami jest pewna zależność podległości, sprawa ma się tym gorzej. Jeśli jesteś kierownikiem, posłuchaj co ma do powiedzenia Twój podwładny. I dopiero ZADAJĄC PYTANIA sprawdzaj, czy jego koncepcja jest poprawna. Może będzie lepsza niż Twoja. A może nie. Dobre pytania dobrze to zweryfikują.
No dobra, ale po co jest to zaufanie? Nie można się bez niego obejść? Jeśli nie ma zaufania, wtedy naturalną kwestią jest zabezpieczanie swoich interesów (dupochrony, job security, czy różnego rodzaju gry projektowe http://mbartyzel.blogspot.com/2011/09/w-co-gra-sie-w-projektach.html). Tego typu aktywności prowadzą do niepożądanych efektów ubocznych (i straty czasu i wiarygodności).
piątek, 31 sierpnia 2012
Charyzma lidera
Ostatnio coraz więcej pracuję z liderami zespołów programistycznych i mocno mnie zastanawia temat dynamizmu i najczęściej idącej za nią charyzmy lidera.
Z czym najczęściej kojarzy się dynamizm - z osobą, która jest bardzo energiczna, bardzo szybko mówi, bardzo szybko myśli, działa. Tymczasem dostrzegam, że szczególnie w projektach programistycznym, większość liderów i to takich, KTÓRZY RZECZYWIŚCIE SĄ ŚWIETNI W TYM CO ROBIĄ, taka nie jest. A ludzi ich słuchają, podążają za nimi i skupiają ogromną ilość uwagi.
Kilka dni temu doświadczyłem następującej sytuacji, która w efekcie spowodowała olśnienie. Ponieważ ostatnio rekrutujemy intensywnie, toteż pewnego dnia brałem udział w procesie rekrutacyjnym dwóch osób. Jedna z nich była dość wyciszona, zrównoważona, zaś druga bardzo energiczna.
Co się okazało na spotkaniu - w tym drugim przypadku mimo ogromnej energii, wypowiadanych setek słów na sekundę, pozostali uczestnicy spotkania poczuli się szybko znużeni. Po piętnastu minutach już zwyczajnie odpływałem. Wysoka energia z czasem zmieniała się w monotonny (!) usypiający szum.
Druga osoba dość powoli odpowiadała na pytania, często zadawała pytania, tym samym wciągając nas w rozmowę. Dwie godziny minęły, nawet nie wiedziałem kiedy... i chciałem jeszcze.
- WTF? - pomyślałem. - JAK TO MOŻLIWE, ŻE ENERGICZNY GOŚĆ NAS ZNUŻYŁ, A MNIEJ ENERGICZNY, ZRÓWNOWAŻONY WCIĄGNĄŁ W TO, O CZYM MÓWIŁ I CO MÓWIŁ.
W pewnym momencie doznałem olśnienia! DYNAMIKA. To dynamika sprawia, że angażujemy się w to, co się dzieje. Tylko uwaga! Słowo dynamika jest tu bardzo niebezpieczne, bo niesie ze sobą potoczne niezbyt precyzyjne skojarzenie. Idąc za definicją DYNAMIKI dzwięku z wikipedii (http://pl.wikipedia.org/wiki/Dynamika_%28elektroakustyka%29) jest ona duża wtedy, kiedy raz jest cicho, raz głośno, idąc dalej - raz powoli, raz szybko. Dlatego ludzie charyzmatyczni to ludzie dynamiczni, co wcale nie oznacza, że głośni. Jedną ze sprytnych metod na uspokojenie niemowlaka jest włączenie mu czegoś jednostajnie głośnego (np. odkurzacza), dziecko łatwo usypia. Jednostajny hałas, głośność usypia!
Szczególnie w IT hałas nie ma to większego sensu, gdyż trzeba podejmować przede wszystkim racjonalne decyzje. JEŚLI CHCESZ ABY LUDZIE CIĘ SŁUCHALI Z CIEKAWOŚCIĄ, PODĄŻALI ZA TOBĄ, Z PEWNOŚCIĄ MUSISZ NAUCZYĆ MÓWIĆ I DZIAŁAĆ DYNAMICZNIE, I WCALE NIE OZNACZA TO, ŻE MUSISZ BYĆ GŁOŚNY, TRYSKAJĄCY POTOKIEM SŁÓW :)
Z czym najczęściej kojarzy się dynamizm - z osobą, która jest bardzo energiczna, bardzo szybko mówi, bardzo szybko myśli, działa. Tymczasem dostrzegam, że szczególnie w projektach programistycznym, większość liderów i to takich, KTÓRZY RZECZYWIŚCIE SĄ ŚWIETNI W TYM CO ROBIĄ, taka nie jest. A ludzi ich słuchają, podążają za nimi i skupiają ogromną ilość uwagi.
Kilka dni temu doświadczyłem następującej sytuacji, która w efekcie spowodowała olśnienie. Ponieważ ostatnio rekrutujemy intensywnie, toteż pewnego dnia brałem udział w procesie rekrutacyjnym dwóch osób. Jedna z nich była dość wyciszona, zrównoważona, zaś druga bardzo energiczna.
Co się okazało na spotkaniu - w tym drugim przypadku mimo ogromnej energii, wypowiadanych setek słów na sekundę, pozostali uczestnicy spotkania poczuli się szybko znużeni. Po piętnastu minutach już zwyczajnie odpływałem. Wysoka energia z czasem zmieniała się w monotonny (!) usypiający szum.
Druga osoba dość powoli odpowiadała na pytania, często zadawała pytania, tym samym wciągając nas w rozmowę. Dwie godziny minęły, nawet nie wiedziałem kiedy... i chciałem jeszcze.
- WTF? - pomyślałem. - JAK TO MOŻLIWE, ŻE ENERGICZNY GOŚĆ NAS ZNUŻYŁ, A MNIEJ ENERGICZNY, ZRÓWNOWAŻONY WCIĄGNĄŁ W TO, O CZYM MÓWIŁ I CO MÓWIŁ.
W pewnym momencie doznałem olśnienia! DYNAMIKA. To dynamika sprawia, że angażujemy się w to, co się dzieje. Tylko uwaga! Słowo dynamika jest tu bardzo niebezpieczne, bo niesie ze sobą potoczne niezbyt precyzyjne skojarzenie. Idąc za definicją DYNAMIKI dzwięku z wikipedii (http://pl.wikipedia.org/wiki/Dynamika_%28elektroakustyka%29) jest ona duża wtedy, kiedy raz jest cicho, raz głośno, idąc dalej - raz powoli, raz szybko. Dlatego ludzie charyzmatyczni to ludzie dynamiczni, co wcale nie oznacza, że głośni. Jedną ze sprytnych metod na uspokojenie niemowlaka jest włączenie mu czegoś jednostajnie głośnego (np. odkurzacza), dziecko łatwo usypia. Jednostajny hałas, głośność usypia!
Szczególnie w IT hałas nie ma to większego sensu, gdyż trzeba podejmować przede wszystkim racjonalne decyzje. JEŚLI CHCESZ ABY LUDZIE CIĘ SŁUCHALI Z CIEKAWOŚCIĄ, PODĄŻALI ZA TOBĄ, Z PEWNOŚCIĄ MUSISZ NAUCZYĆ MÓWIĆ I DZIAŁAĆ DYNAMICZNIE, I WCALE NIE OZNACZA TO, ŻE MUSISZ BYĆ GŁOŚNY, TRYSKAJĄCY POTOKIEM SŁÓW :)
Nie bądź zbyt szybki, zacznij myśleć!
Czasami sobie myślę, że świat obecnie stał się zbyt szybki. Wszystko wokół dzieje się tak szybko, iż wskakujemy na autopilot i przestajemy myśleć dlaczego i po co robimy dane zadanie, czy muszę je robić w taki sposób w jaki sobie wymyśliłem albo ktoś mi wymyślił.
Jest to tym bardziej niebezpieczne w pracy programisty, ze względu na wskakiwanie po kilkunasty minutach w stan transowy, wtedy to już stajemy się kompletnie bezmyślni...
Pewnie sobie mówisz: "Ale gość pierdzieli - przecież programowanie to ciągłe myślenie, wymyślanie koncepcji, rozwiązań, weryfikowanie, muszę powiązać ze sobą 10 bibliotek jednocześnie i uwzględniać wydajność mojego kodu. Cały czas do cholery muszę myśleć!"
Masz rację. Warto jednak rozróżnić kilka rzeczy, nad którymi musisz myśleć, aby zrobić to, co masz do zrobienia:
* dlaczego i po co robię TO - to jest kluczowe pytanie, szczególnie, jeśli pracujesz w zmiennym środowisku, gdzie zadania bombardują Cię z wielu stron (np. utrzymanie, ale też w dziale programistycznym, który dostaje "luźne" zlecenia z różnych departamentów), czy rzeczywiście jest to tak bardzo potrzebne, co się stanie z efektem pracy jak ją wykonam, czy jak odłożę to zadanie z determinacją, czy ktoś będzie wkurzony? A jeśli tak to dlaczego? Czy tylko dlatego, że nie zrobiłeś tego zadania, czy dlatego, że "czyjeś życie z tego powodu ucierpi"? Często nawet 30-40% zadań jest niepotrzebnych. Tak! A wiesz dlaczego? Bo Ci którzy je zlecają, nie MAJĄ CZASU, aby przemyśleć ich sensowność. Oczywiście to nieprawda, że nie mają czasu, oni go po prostu na to NIE POŚWIĘCAJĄ.
* jak chcę podejść do zrobienia tego CZEGOŚ - często to, co mamy do zrobienia, można zrobić na wiele różnych sposobów. Np. daną funkcjonalność, która polega na zebraniu złożonych informacji mogę zrealizować za pomocą jednego formularza lub kreatora. Daną usługę mogę zrobić za pomocą kilku ifów lub za pomocą wzorca Strategii. Czy warto sięgać po ten wzorzec lub jakieś inne niesamowicie elastyczne (i pozornie eleganckie) rozwiązanie, kiedy jeśli się dobrze zastanowić już nigdy nikt nie wróci do tego kodu. I przeciwnie czy warto wstawiać kilka ifów, jeśli wiadomo, że np. będą się pojawiać wraz z rozwojem aplikacji kolejne wersje algorytmów, które będą działały inaczej. Czy wtedy wzorzec Startegii nie będzie bardziej adekwatny?
* jak chcę TO wykonać - czyli jakich klas, jakich bibliotek, jakich konstrukcji użyć, jak to napisać.
W najlepszym przypadku, na autopilocie, odpowiadamy sobie co najwyżej na pytanie, jak chcę konkretnie TO wykonać. Wtedy wpadamy wir rozwiązywania problemów, przeskakiwania z jednego pomysłu do drugiego. Rozważania tysiąca szczegółów. Bo tak jest szybciej. Ale w tym przypadku szybko oznacza bezmyślnie. Robisz dużo i natychmiast, ale BEZ SENSU (no dobrze - bez przeanalizowania sensu samego zadania - HA!).
Nie bądź zbyt szybki, zacznij myśleć :)
Jest to tym bardziej niebezpieczne w pracy programisty, ze względu na wskakiwanie po kilkunasty minutach w stan transowy, wtedy to już stajemy się kompletnie bezmyślni...
Pewnie sobie mówisz: "Ale gość pierdzieli - przecież programowanie to ciągłe myślenie, wymyślanie koncepcji, rozwiązań, weryfikowanie, muszę powiązać ze sobą 10 bibliotek jednocześnie i uwzględniać wydajność mojego kodu. Cały czas do cholery muszę myśleć!"
Masz rację. Warto jednak rozróżnić kilka rzeczy, nad którymi musisz myśleć, aby zrobić to, co masz do zrobienia:
* dlaczego i po co robię TO - to jest kluczowe pytanie, szczególnie, jeśli pracujesz w zmiennym środowisku, gdzie zadania bombardują Cię z wielu stron (np. utrzymanie, ale też w dziale programistycznym, który dostaje "luźne" zlecenia z różnych departamentów), czy rzeczywiście jest to tak bardzo potrzebne, co się stanie z efektem pracy jak ją wykonam, czy jak odłożę to zadanie z determinacją, czy ktoś będzie wkurzony? A jeśli tak to dlaczego? Czy tylko dlatego, że nie zrobiłeś tego zadania, czy dlatego, że "czyjeś życie z tego powodu ucierpi"? Często nawet 30-40% zadań jest niepotrzebnych. Tak! A wiesz dlaczego? Bo Ci którzy je zlecają, nie MAJĄ CZASU, aby przemyśleć ich sensowność. Oczywiście to nieprawda, że nie mają czasu, oni go po prostu na to NIE POŚWIĘCAJĄ.
* jak chcę podejść do zrobienia tego CZEGOŚ - często to, co mamy do zrobienia, można zrobić na wiele różnych sposobów. Np. daną funkcjonalność, która polega na zebraniu złożonych informacji mogę zrealizować za pomocą jednego formularza lub kreatora. Daną usługę mogę zrobić za pomocą kilku ifów lub za pomocą wzorca Strategii. Czy warto sięgać po ten wzorzec lub jakieś inne niesamowicie elastyczne (i pozornie eleganckie) rozwiązanie, kiedy jeśli się dobrze zastanowić już nigdy nikt nie wróci do tego kodu. I przeciwnie czy warto wstawiać kilka ifów, jeśli wiadomo, że np. będą się pojawiać wraz z rozwojem aplikacji kolejne wersje algorytmów, które będą działały inaczej. Czy wtedy wzorzec Startegii nie będzie bardziej adekwatny?
* jak chcę TO wykonać - czyli jakich klas, jakich bibliotek, jakich konstrukcji użyć, jak to napisać.
W najlepszym przypadku, na autopilocie, odpowiadamy sobie co najwyżej na pytanie, jak chcę konkretnie TO wykonać. Wtedy wpadamy wir rozwiązywania problemów, przeskakiwania z jednego pomysłu do drugiego. Rozważania tysiąca szczegółów. Bo tak jest szybciej. Ale w tym przypadku szybko oznacza bezmyślnie. Robisz dużo i natychmiast, ale BEZ SENSU (no dobrze - bez przeanalizowania sensu samego zadania - HA!).
Nie bądź zbyt szybki, zacznij myśleć :)
czwartek, 26 kwietnia 2012
Wielkie kłamstwo o czystym kodzie i testach jednostkowych
Jest wiele osób przekonanych, że dla nich wstawanie wcześnie rano, na przykład o 5.00, to nierealna bajka. Że ich natura, ciało jest akurat tak skonstruowane, że to niemożliwe. Należałem kiedyś do tej grupy osób.
Kiedy znajdziesz powód, dla którego jest sens wstawać o tej porze (np. wstajesz rano, żeby napisać kilka stron książki, własnej książki, którą chcesz wydać) lub jeśli po prostu musisz (bo urodziło Ci się dziecko, i robi Ci pobudkę o tej porze), okazuje się, że można.
Powiem Ci jak to działa. Załóżmy, że przez kilka lat beztrosko studiujesz, gdzie wstawanie o wczesnej porze nie jest bynajmniej priorytetem. Albo jeszcze wcześniej w domu nikt Cie specjalnie nie poganiał do wcześniejszego wstawania. Zatem wstawanie później (7, 8, może nawet 9-ta) było w normie. Twój organizm i umysł wypracował w związku z tym wiele mechanizmów nawykowych, które wspierają taki sposób funkcjonowania (metabolizm, głębokość snu itp.). Staje się to "twoim sposobem funkcjonowania", niektórzy zaczynają wierzyć, że "już tak po prostu jest" lub że "tacy już są".
Oczywiście każda zmiana na krótką metę powoduje ból. Jeśli zaczynasz wstawać dwie godziny wcześniej niż zazwyczaj, będzie to ból. Dlatego musisz mieć silną motywację - po co to robić, dlaczego się narażać na dyskomfort, zrezygnowania z mięciutkiego fotela strefy komfortu. Inaczej nawyk bardzo szybko zwycięży.
Jeśli wmówiłeś sobie, że rano musisz zjeść śniadanie przed wyjściem i robisz to codziennie, autentycznie będziesz chory jeśli tego nie zrobisz. Jeśli sobie wmówiłeś, że rano w ogóle nie odczuwasz głodu (bo przynajmniej przez pewien okres swojego życia czas objadałeś się wieczorem, wtedy rano nie chce się jeść), to cokolwiek będziesz próbował jeść wcześnie rano, będzie przyprawiać Cię o mdłości.
Tak samo jest z powszechnie wyrażaną bajką, że nie ma czasu na pisanie czystego, czytelnego kodu i testowania jednostkowego (czy TDD, BDD). To kłamstwo, w które wierzy większość osób, bo takie wypracowali sobie nawyki - nigdy tak nie pisali albo raz na kilka godzin spróbowali i polegli. Więc dlaczego mają myśleć inaczej. W ich przestrzeni mentalnej nie ma miejsca na to, co nie jest nawykowe. Czas wyrwać się ze snu. Może zaboleć, ale równie dobrze może być niesamowitą przygodą w drodze do bycia P R O F E S J O N A L I S T Ą. Wybór należy do Ciebie.
Kiedy znajdziesz powód, dla którego jest sens wstawać o tej porze (np. wstajesz rano, żeby napisać kilka stron książki, własnej książki, którą chcesz wydać) lub jeśli po prostu musisz (bo urodziło Ci się dziecko, i robi Ci pobudkę o tej porze), okazuje się, że można.
Powiem Ci jak to działa. Załóżmy, że przez kilka lat beztrosko studiujesz, gdzie wstawanie o wczesnej porze nie jest bynajmniej priorytetem. Albo jeszcze wcześniej w domu nikt Cie specjalnie nie poganiał do wcześniejszego wstawania. Zatem wstawanie później (7, 8, może nawet 9-ta) było w normie. Twój organizm i umysł wypracował w związku z tym wiele mechanizmów nawykowych, które wspierają taki sposób funkcjonowania (metabolizm, głębokość snu itp.). Staje się to "twoim sposobem funkcjonowania", niektórzy zaczynają wierzyć, że "już tak po prostu jest" lub że "tacy już są".
Oczywiście każda zmiana na krótką metę powoduje ból. Jeśli zaczynasz wstawać dwie godziny wcześniej niż zazwyczaj, będzie to ból. Dlatego musisz mieć silną motywację - po co to robić, dlaczego się narażać na dyskomfort, zrezygnowania z mięciutkiego fotela strefy komfortu. Inaczej nawyk bardzo szybko zwycięży.
Jeśli wmówiłeś sobie, że rano musisz zjeść śniadanie przed wyjściem i robisz to codziennie, autentycznie będziesz chory jeśli tego nie zrobisz. Jeśli sobie wmówiłeś, że rano w ogóle nie odczuwasz głodu (bo przynajmniej przez pewien okres swojego życia czas objadałeś się wieczorem, wtedy rano nie chce się jeść), to cokolwiek będziesz próbował jeść wcześnie rano, będzie przyprawiać Cię o mdłości.
Tak samo jest z powszechnie wyrażaną bajką, że nie ma czasu na pisanie czystego, czytelnego kodu i testowania jednostkowego (czy TDD, BDD). To kłamstwo, w które wierzy większość osób, bo takie wypracowali sobie nawyki - nigdy tak nie pisali albo raz na kilka godzin spróbowali i polegli. Więc dlaczego mają myśleć inaczej. W ich przestrzeni mentalnej nie ma miejsca na to, co nie jest nawykowe. Czas wyrwać się ze snu. Może zaboleć, ale równie dobrze może być niesamowitą przygodą w drodze do bycia P R O F E S J O N A L I S T Ą. Wybór należy do Ciebie.
niedziela, 5 lutego 2012
No to jak to z tą architekturą - up-front design czy ewolucyjna architektura?
W jakim miejscu obecnie stoi architektura? Można powiedzieć, że mamy dwa klasyczne podejścia:
• klasyczne, które każe starannie zaplanować możliwie wiele szczegółów (up-front);
• zwinne, które każe podejmować decyzje najpóźniej, jak to możliwe i rozwijać architekturę poprzez refaktoring.
Jak to najczęściej się odbywa w projektach? W dużej części przypadków tworzy się projekt mniej lub bardziej szczegółowy (w stylu up-front) i tak już zostaje.
Z drugiej strony liczenie na to, że uda się rozwinąć dobrą architekturę tylko i wyłącznie organicznie, poprzez naturalną ewolucję, też zazwyczaj się nie udaje. W dużych projektach jest to wręcz niezwykle ryzykowne, gdyż prowadzi często do rozwiązań lokalnych, które w pewnym momencie należałoby całkowicie przepisać (co najczęściej się nie dzieje).
W praktyce zdecydowanie najlepiej sprawdza się mieszane podejście tzn. na początku projektu, releasu, iteracji, tworzy się koncept i projekt rozwiązania, który stanowi bazę i punkt odniesienia do prac projektowych. Nie musi, a nawet nie powinien być to niezwykle szczegółowy projekt. Z drugiej strony nie należy zakładać że to, co zostało wymyślone na początku, będzie doskonałym rozwiązaniem, dlatego w ramach prac projektowych, dokonujemy bieżącej lokalnej modyfikacji założeń projektowych poprzez refaktoryzację.
Dzięki temu uzyskujemy naturalny proces rozwoju architekury, z jednej strony jest ona wstępnie zaprojektowana, dzięki czemu nie stracimy czasu i zasobów na ewolucyjne błądzenie. Ewolucję wykorzystujemy, to poprawienia pierwotnego projektu. Jeśli powiążemy to z procesem Naturalnego Porządku refaktoryzacji to jesteśmy w domu! Więcej w kolejnych wpisach.
Szkic procesu wygląda następująco:
• klasyczne, które każe starannie zaplanować możliwie wiele szczegółów (up-front);
• zwinne, które każe podejmować decyzje najpóźniej, jak to możliwe i rozwijać architekturę poprzez refaktoring.
Jak to najczęściej się odbywa w projektach? W dużej części przypadków tworzy się projekt mniej lub bardziej szczegółowy (w stylu up-front) i tak już zostaje.
Z drugiej strony liczenie na to, że uda się rozwinąć dobrą architekturę tylko i wyłącznie organicznie, poprzez naturalną ewolucję, też zazwyczaj się nie udaje. W dużych projektach jest to wręcz niezwykle ryzykowne, gdyż prowadzi często do rozwiązań lokalnych, które w pewnym momencie należałoby całkowicie przepisać (co najczęściej się nie dzieje).
W praktyce zdecydowanie najlepiej sprawdza się mieszane podejście tzn. na początku projektu, releasu, iteracji, tworzy się koncept i projekt rozwiązania, który stanowi bazę i punkt odniesienia do prac projektowych. Nie musi, a nawet nie powinien być to niezwykle szczegółowy projekt. Z drugiej strony nie należy zakładać że to, co zostało wymyślone na początku, będzie doskonałym rozwiązaniem, dlatego w ramach prac projektowych, dokonujemy bieżącej lokalnej modyfikacji założeń projektowych poprzez refaktoryzację.
Dzięki temu uzyskujemy naturalny proces rozwoju architekury, z jednej strony jest ona wstępnie zaprojektowana, dzięki czemu nie stracimy czasu i zasobów na ewolucyjne błądzenie. Ewolucję wykorzystujemy, to poprawienia pierwotnego projektu. Jeśli powiążemy to z procesem Naturalnego Porządku refaktoryzacji to jesteśmy w domu! Więcej w kolejnych wpisach.
Szkic procesu wygląda następująco:
środa, 1 lutego 2012
Właściwość złożonych systemów
Dzisiaj rano jadąc samochodem do pracy natknąłem się na dużo dłuższy korek niż zwykle. "No tak, przy takim mrozie pewnie wszyscy jadą szczególnie ostrożnie" - pomyślałem i powoli się turlałem Trasą Łazienkowską. Po kilkunastu minutach, w pewnym momencie zauważyłem z daleka, że na jezdni w przeciwnym kierunku był wypadek i policja oraz pogotowie robiły, co swoje. Na moim pasie nic się szczególnego nie działo. Niby nic, a jednak... Kierowcy najzwyczajniej w świecie zwalniali, żeby zobaczyć co się dzieje na drugim pasie. Nikt się nie zatrzymywał, tylko patrzyli, co się dzieje. I z tego powodu fragment, który zazwyczaj przemierzałem w 5 minut, zajął mi tym razem 20 minut. Po przejechaniu tego punktu ruch znacząco przyspieszył i przebiegał normalnie.
Dlaczego o tym piszę? Od razu dostrzegłem analogię do projektów programistycznych :) Przedsięwzięcia programistyczne - ludzie, architektura, procesy - to złożony system. Często niewielkie zmiany, pozornie nieistotne elementy mają ogromny, kaskadowy wpływ na to co się dzieje w projektach.
Być może o jeden punkt decyzyjny za dużo, za mało, brak lub nadmiar dokumentacji, brak asertywności lub przyzwolenia o mówieniu o błędach, brak ścisłej współpracy lub zbyt swobodna współpraca bez ustalonych reguł mogą znacząco zmniejszać efektywność całego procesu. Warto o tym pamiętać!
W przypadku ruchu drogowego sytuacja jest nieco prostsza, bo łatwiej ją zmierzyć - jest to prędkość i czas przejazdu na tej samej trasie. Nie mamy tego luksusu w projektach, gdzie zazwyczaj to, co jest realizowane nie jest tak powtarzalne. Jednak możemy przybliżać się do oszacowania i porównywania. Szacując zadania oraz dodając relatywną miarę złożoności zadań (funkcjonalności).
Mniej formalną metodą są punkty (points, story points), które są jednostką względną, służącą raczej do porównania złożoności różnych funkcjonalności, niż do dokładnej analizy złożoności (która jest niezwykle pracochłonna, a i tak pozostanie tylko prognozą). Bardziej formalną metodą (gdzie dużo precyzyjniej należy argumentować podane szacowania) mogą być kilkuczynnikowe metody szacowania i pomiar zadań za pomocą punktów funkcyjnych.
Wtedy możemy obserwować czy nasza prędkość się zmienia, jak wprowadzane zmiany mają na nią wpływ.
Dlaczego o tym piszę? Od razu dostrzegłem analogię do projektów programistycznych :) Przedsięwzięcia programistyczne - ludzie, architektura, procesy - to złożony system. Często niewielkie zmiany, pozornie nieistotne elementy mają ogromny, kaskadowy wpływ na to co się dzieje w projektach.
Być może o jeden punkt decyzyjny za dużo, za mało, brak lub nadmiar dokumentacji, brak asertywności lub przyzwolenia o mówieniu o błędach, brak ścisłej współpracy lub zbyt swobodna współpraca bez ustalonych reguł mogą znacząco zmniejszać efektywność całego procesu. Warto o tym pamiętać!
W przypadku ruchu drogowego sytuacja jest nieco prostsza, bo łatwiej ją zmierzyć - jest to prędkość i czas przejazdu na tej samej trasie. Nie mamy tego luksusu w projektach, gdzie zazwyczaj to, co jest realizowane nie jest tak powtarzalne. Jednak możemy przybliżać się do oszacowania i porównywania. Szacując zadania oraz dodając relatywną miarę złożoności zadań (funkcjonalności).
Mniej formalną metodą są punkty (points, story points), które są jednostką względną, służącą raczej do porównania złożoności różnych funkcjonalności, niż do dokładnej analizy złożoności (która jest niezwykle pracochłonna, a i tak pozostanie tylko prognozą). Bardziej formalną metodą (gdzie dużo precyzyjniej należy argumentować podane szacowania) mogą być kilkuczynnikowe metody szacowania i pomiar zadań za pomocą punktów funkcyjnych.
Wtedy możemy obserwować czy nasza prędkość się zmienia, jak wprowadzane zmiany mają na nią wpływ.
Subskrybuj:
Posty (Atom)
