Czy jest taka rzecz, którą gdybyś tylko miał siłę robić regularnie przez następny rok twój komfort życia uległby zdecydowanej poprawie?

Może myślisz o codziennych porannych ćwiczeniach a może o regularnej nauce języka obcego. Może jest to zupełnie coś innego.

Pewnie słyszałeś o technice stawiania sobie celów.. Stawiasz sobie za cel, by za rok przebiec maraton. Następnie planujesz kroki, które musisz wykonać by to zrobić.

A może zamiast osiągania celów wolisz rozwiązywać problemy? Wyobrażasz sobie siebie biegnącego maraton, a następne zastanawiasz się jakie problemy trzeba było pokonać by w efekcie móc zostać maratończykiem.

Prawie każdy zna jedną bądź drugą technikę. A jednak często brakuje nam wytrwałości.. Leń, który mieszka w każdym z nas dochodzi do głosu i sprawia, że zaniedbujemy to, co mieliśmy robić.

Istnieje jeszcze jeden sposób. (Przeczytałem o nim w internecie, szukaj: inevitability thinking)

Technika “nieuchronnej realizacji”. Dzięki niej osiągniesz to co jest dla Ciebie ważne

Zorganizuj swój świat tak, by motywował Cię do osiągnięcia celu.

Załóżmy, że chcesz codziennie rano ćwiczyć. Oto przykładowa rzecz, która mógłbyś zrobić:

• Spotkaj się z przyjacielem i powiedz mu o swoim celu.
• Daj mu na przechowanie motywującą Cię kwotę pieniędzy, na przykład 100zł. (a jeszcze lepiej czek)
• Powiedz,  że codziennie rano będziesz wysyłał mu e-mail z informacją o tym,  że wykonałeś ćwiczenia.
• Poproś go by, jeśli jakiegoś dnia nie znajdzie on informacji na temat Twoich ćwiczeń, natychmiast wydał powierzone mu pieniądze. Ma zrobić z nimi co chce, ale tak, by nie dało się ich odzyskać.

Możesz też po prostu obiecać, co zrobisz, jeśli zaniedbasz wyznaczony sobie cel. Osoba, której to obiecujesz musi być osobą, której nie chcesz zawieść i która będzie w stanie wyegzekwować od Ciebie to co przyrzekłeś.

Inna sytuacja: Nie możesz powstrzymać się od picia koli, a wiesz, że jest to niezdrowe.

• Pij kolę kiedy chcesz, ale:
• Nie możesz trzymać w domu żadnej koli. Jeśli masz ochotę napić się jej musisz kupić ją w sklepie.
• Możesz kupić tylko  jedną małą puszkę koli.
• Musisz udać się piechotą do sklepu oddalonego o 5km od miejsca gdzie przebywasz.

http://www.oredev.org/videos/the-lean-startup

Zaciekawił mnie fragment na temat Continuous Deployment. Eric Ries’a mówi, że zmiany, które commit’uje deweloper są automatycznie wdrażane na produkcje. Jednocześnie monitorowane są metryki biznesowe, np. liczba rejestracji. Jeśli jakaś metryka spadnie poniżej dopuszczalnej wartości zmiana jest automatycznie cofana a cały zespół jest informowany e-mailem, że wprowadzona zmiana wydaje się nie być zbyt korzystna. Feedback od klientów poniżej 1h

Czy wiecie o kimś w Polsce, kto się w to bawi? W szczególności, czy ktoś korzysta z Continuous Deployment?

Swoją drogą właśnie skończyła się konferencja organizowana przez Eric Ries’a http://www.sllconf.com/program. Widziałem, że w sieci są już nagrania.

By nasze sesje burz mózgów były skuteczniejsze powinniśmy sobie postawić za cel wymyślić co najmniej 3 złe pomysły. Dopóki tego nie zrobimy nie możemy zakończyć sesji.

Dzięki temu będziemy bardziej kreatywni a powiedzenie czegoś głupiego będzie świętowane (a nie piętnowane).

Ma sens?:)

Największą niedogodnością dla mnie była lokalizacja. Razem z Krzyśkiem mieliśmy zamiar dojechać autobusem i okazało się, że sugerowany na stronie organizatora autobus nie jeździł wczoraj (w ogóle rzadko w soboty jeździ..). Na szczęście uratował nas Adam, który podrzucił nas autem – jeszcze raz dzięki Nie mniej zgadzam się, że sama lokalizacja malownicza i ładna. Natomiast “kuchnia” za mała jak na tyle osób, ciężko było operować przy kawie i herbacie.

Jeśli chodzi o program konferencji to uczestniczyłem w ścieżce “ludzie”. Sesje były na poziome, chciałbym napisać tutaj tylko o jednej.

10 tips that ScrumMasters should know, (but probably don’t!) prowadzone przez Nigel Baker’a. Zgadzam się z tym co można było przeczytać na Twiterze (#agiletuning) – Nigel to świetny mówca. Naprawdę potrafi przemawiać Ciekaw jestem, gdzie się tego uczył? A może ma tak ‘od urodzenia’?:) Słychać też było, że zna się na skutecznej komunikacji – jego pytanie “To kto zada pierwsze pytanie?:)” nie umknęło mojej wyczulonej na takie chwyty uwadze

Poniżej lista tego co zapamiętałem z tej prezentacji, nie koniecznie w kolejności jaką podał Nigel (notowałem już po wykładzie)

• ScrumMaster to praca na cały etat. Strażak to strażak, nie zajmuje się rano roznoszeniem poczty jako listonosz. Tak samo powinno być ze SM, powinien on cały swój czas poświęcić pracy dla teamu.
• Stałe tempo. Nasze projekty to nie sprinty, raczej maratony. Tygodniowy sprint może być zbyt morderczym tempem prowadzącym do wycieńczenia pracowników. I nie tylko o pracowników chodzi – jakość produktu znacznie spada gdy pracownicy są przemęczeni.
• Texas holdem (poker) na żywo versus texas holdem w internecie. Brak komunikacji na żywo rodzi dysfunkcje społeczne (trole, nie szkoda nam zrobić komuś na złość). Jeśli pracujemy w teamie rozproszonym musimy włożyć dużo więcej wysiłku w to, by ludzie byli traktowanie i zachowywali się jak ludzi, niż musimy pracując z teamem, który siedzi razem.
• Mieć i stosować “Definition of Done”
• Nigdy nie dokładać dodatkowych dni na koniec sprintu (by dokończyć historyjki)
• Każdy sprint ma na celu dostarczenie produktu. Nie ma czegoś takiego jak “design sprint”, “technical debt sprint”, “sprint 0″
• Daily Scrum (stand up) jest dla teamu, nie dla SM
• Pamiętać o budowaniu zespołu. Wyjście razem na pizze jest fajne, ale to nie wystarczy by zbudować zespół.
• SM nie może być policjantem. Jeśli będziesz zachowywał się jak policjant ludzie zaczną ci kłamać (taaaak, oczywiście że wczoraj był stand up)

Tyle zanotowałem, coś ważnego przeoczyłem?:)

Napiszę teraz co nie co o sesji Software Craftsmanship, Beyond The Hype. Sesję poprowadził Corey Haines, który bardzo dosłownie potraktował idee “Journeyman” i jak możemy się dowiedzieć (http://www.coderetreat.com/) rok 2009 spędził podróżując po stanach ucząc programowania w parach w zamian za wikt i opierunek.

Jeśli nie słyszałeś jeszcze o Software Craftmanship, tutaj możesz przeczytać manifest. Jeśli agile jest o tym jak dostarczać oprogramowanie wysokiej jakości, to Software Craftmanship jest o tym jak kształcić deweloperów o wysokich kwalifikacjach.  Corey opowiadał o tym, co w ostatnim czasie działo się w środowisku i tak:

• Rozpowszechniła się idea Code Katas
• Temat jest poruszany na konferencjach, np. ścieżka w czasie QCon
• Coderetreat - może warto coś takiego zorganizować we Wrocławiu? Corey podróżuje z tym teraz po świecie, więc można by go spróbować zaprosić.
• Powstają User Groups – btw, mamy jakieś aktywne grupy w Polsce?
• Craftsman Swaps – firmy wymieniają się pracownikami, na tydzień lub dwa. Pracownicy mogą zobaczyć jak podchodzi się do wytwarzania oprogramowania w innych “warsztatach”. Ktoś słyszał o czymś takim w Polsce?
• Craftsman Journeys – Tak jak Corey, ludzie zaczynają ruszać na dłuższe podróże, podczas których spotykają się z deweloperami z różnych zakątków świata, kodując razem z nimi i wymieniając się doświadczeniem i technikami.
• Craftsman Spikes – firmy dają możliwość chętnym, przyjść i popracować u siebie przez parę dni. Np studenci mogą przyjść ze swoim problemem i nauczyć się czegoś od praktykujących deweloperów.

Właśnie skończyłem czytać rozdział 6 i chciałbym tutaj zamieścić tłumaczenie podsumowania tego rozdziału.

Obiekty prezentują zachowania (funkcje) i ukrywają dane – to sprawia, że łatwo jest dodawać nowe rodzaje obiektów bez potrzeby zmiany zachowań (funkcji) istniejących obiektów. Kolejną konsekwencją jest to, że trudniej jest dodać nowe zachowanie do istniejących obiektów (wszystkie obiekty muszą się zmienić).

Struktury danych prezentują dane i nie mają żadnego znaczącego zachowania (funkcji). To sprawia, że łatwo jest dodać nowe zachowanie obsługujące istniejące struktury danych, ale trudniej dodać nowe struktury danych (bo wszystkie funkcje muszą się zmienić).

W każdym systemie będziemy chcieli czasem mieć elastyczność w dodawaniu nowych typów danych, więc wybierzemy obiekty dla tej części systemu. Kiedy indziej, będziemy chcieli łatwości w dodawaniu nowych funkcji i dla tej części systemu wybierzemy struktury danych i procedury.  Dobry inżynier oprogramowania rozumie powyższe sprawy i bez uprzedzeń wybiera podejście, które najlepiej rozwiąże dany problem.
Co wy na to? Sam muszę to przemyśleć, na razie sugerowanie użycia struktur danych i procedur
wydaje mi się trochę podejrzane, ale z drugiej strony? ..

W TDD pracujemy w cyklach RED GREEN REFACTOR. Kiedy pierwszy raz spotkałem się z tym podejściem jednym z problemów było znalezienie odpowiedzi na pytanie: “Co i jak poprawiać w kodzie?“.

Jeśli też stawiasz sobie te pytanie, polecam Ci książkę Clean Code – można się z niej dowiedzieć wiele przydatnych rzeczy.

Tutaj znalazłem podsumowanie rozdziału 17, gdzie zebrane są wszystkie “heurystyki” i “brzydkie zapachy” związane z kodem.

Napisałem prościutki plugin do Eclipsa, który wyświetla listę tych heurystyk w okienku, dając nam możliwość sprawdzenia naszego kodu pod kątem tych heurystyk (oczywiście najpierw trzeba je znać i rozumieć)  – taka ściągawka. Jeśli jesteś ciekawy tego pluginu, daj znać na maila lub w komentarzach, wyśle  Ci

Streszczenie treści.. Programowanie w parach działa bo:

• Kiedykolwiek “oświeciło” cię samo zadania komuś pytania? Podobny efekt występuje podczas rozmów programistów w czasie programowania w parach.
• Kojarzysz eksperyment z liczeniem piłek do kosza?*. Często nie widzimy tego, czego nie szukamy lub co nie wydaje nam się być istotne (uliczni magicy korzystają z tego od dawna). Gdy pracujemy w parze i popełnimy błąd (ale go przeoczymy) jest duża szansa, że nasz partner go wychwyci.
• Para nawzajem się nakręca w korzystaniu z dobrych praktyk. Piszemy testy, refactorujemy bo inaczej “zawiedziemy” partnera. Poza tym, partner sam z siebie będzie wywierał pozytywną presję.  A dlaczego korzystamy ze złych praktyk? Np można powiedzieć, że code & fix jest podobne do grania na jednorękim bandycie. Jednoręki bandyta to jedna z najbardziej uzależniających gier w kasynie.
• Zespół wymienia i dyskutuje doświadczenia.

* Jeśli nie kojarzysz tego eksperymentu, obejrzyj ten filmik http://viscog.beckman.illinois.edu/flashmovie/15.php. Możesz go zobaczyć tylko raz, twoim zadaniem jest policzyć ile razy piłka została podana pomiędzy uczestnikami w białych koszulkach. Gdy już będziesz znał wynik, odwiedź tą stronę http://free.mailinfo.com/web/reality/step2.htm.

Opisuje ona model problemów, które mogą zaistnieć w zespole, który wydaje mi się bardzo sensowny.

Model ten omawia 5 problemów, przy czym z problemu na poziomie niższym wynikają problemy na poziomach wyższych i mamy tak (od dołu do góry)

• Brak zaufania
• Obawa przed konfliktem
• Brak zaangażowania
• Unikanie odpowiedzialności (również chodzi o zwracanie uwagi innym)
• Nieprzejmowanie się wynikami

Książka w bardzo przystępny sposób opisuje te zagadnienia (historyjka) oraz daje wskazówki jak sobie z nimi radzić. Polecam