Wideo Slajdy

To co szczególnie mi się spodobało to aplikacja opisana w 47 minucie. Nie udało mi się znaleźć jej w sieci, więc jak komuś się uda to proszę o info w komentarzach.

Aplikacja jest opisana następująco:

• Aplikacja zarządza muzyką, która leci w pomieszczeniu deweloperów
• Każdy może dodać swoją piosenkę do listy piosenek, które są puszczane
• Każdy może zagłosować, że dana piosenka mu się nie podoba. Nie będzie ona więcej puszczana. Po jakimś czasie lecą tylko takie piosenki, które wszystkim się podobają.
• Gdy Build nie przejdzie, zostaje natychmiast puszczona specjalna piosenka, np „Oops, I did it again”. Od razu wszyscy wiedzą, że build nie działa.
• Każdy może wybrać sobie swoją piosenkę. Po udanym check-in gdy Build przejdzie, zostaje ona puszczona na 20 sekund. W ten sposób od razu wiemy, że wszystko jest w porządku.

Daj znać innym

Ostatnio świadomie zdałem sobie sprawę z kliku analogi pomiędzy światem Agile a światem wodniaków.

W harcerstwie mamy zastęp, w agile mamy zespół. Jeśli mówimy o wodniakach, to mamy załogę, której jeszcze bliżej do zespołu zwinnego.  Tak jak zespół jest razem w projekcie tak załoga jest razem na jachcie. Podobnie jak załoga na jachcie musi współpracować by dopłynąć do celu tak i zespół musi wspólnie dążyć do realizacji projektu. Ktoś kto sprawdza się jako załoga na jachcie prawdopodobnie sprawdzi się również jako członek zespołu programistów.

Wiele wartości ze świata agile (jak i Craftsmanship) mamy również w harcerstwie

1. Ramię pręż słabość krusz i nie zawiedź w potrzebie
2. Podaj swą pomocną dłoń tym co liczą na ciebie
3. Zmieniaj świat, zawsze bądź sprawiedliwy i odważny
4. Śmiało zwalczaj wszelkie zło niech twym bratem będzie każdy

Fragment piosenki „Harcerskie ideały”

Na przykład w zacytowanym fragmencie doszukać się możemy

1. retrospekcje by dążyć do doskonałości

3. odwaga z XP

4.  refactoring, otwarta komunikacja

W swojej książce „Clean Code” Uncle Bob wprost nawiązuje do zasady skauta – „Zostaw miejsce biwaku w lepszym stanie niż je zastałeś” – gdy pisze o tym jak powinniśmy postępować z naszym kodem źródłowym.

Software craftsmanship a krzyż harcerski.

Zasady software craftsmanship (link) a symbolika krzyża (link).

Krąg
Lilijkę otacza krąg – symbol doskonałości do jakiej dąży harcerska rodzina. [..]. Inni dodają, że to oznaka ogromnej woli tworzenia kręgu, z którego promieniować będzie prawość myśli, słów i czynów.

W zasadach przeczytać możemy o tym, że Craftsman ciągle się uczy dążąc do doskonałości. W manifeście Software Craftsmanship jest o budowaniu społeczności profesjonalistów (tworzenie kręgu).

Promienie
Promienie biegnące od lilijki oznaczają dążenie harcerstwa do promieniowania na cały świat wartościami, radością, dobrem.

Z zasad Software Craftsmanship – dziele się wiedzą by wpływać pozytywnie na rozwój całej branży.

Węzeł
Węzeł na wieńcu, jak węzeł na chuście ma przypominać o obowiązku wypełnienia przynajmniej jednego dobrego uczynku dziennie.

Uncle Bob promuje zielone opaski na rękę, które przypominają o tworzeniu dobrego kodu. Mówi też by z każdym wprowadzeniem zmian do repozytorium kodu wiązał się choć jeden akt dobroci (poprawa nazwy zmiennej, wyciągnięcie metody).

Software craftsmanship a żeglarstwo.

Robotę trzeba wykonywać porządnie. To samo przekonanie podzielać będzie żeglarz i craftsman. W obu kontekstach nieprzykładanie się do jakości pracy pociągać może poważne konsekwencje. Źle sklarowane liny doprowadzić mogą do wywrotki jachtu. Niechlujnie napisany kod może zawierać błędy, które spowodują rozbicie się sondy kosmicznej sterowanej wadliwym oprogramowaniem.

Podsumowując: To ciekawe i nigdy bym nie przypuszczał jak lata spędzone w  6 Harcerskiej Drużynie Żeglarskiej wpłyną na moje wybory jako programista. Jak przekonania, które wypracowałem w młodości będą ciągle aktualne w innym kontekście. Mam wrażenie, że czuję agile właśnie dzięki harcerstwu.

Rodzice: Warto zachęcać wasze dzieci do spróbowania harcerstwa.

Młodsi: Wodniactwo to nie tylko świetna przygoda ale również prawdziwa szkoła życia!

Hej, Morze, moje Morze,
Wdzięczny Ci jestem bardzo,
Toś Ty mnie wychowało,
Toś Ty mnie wychowało,
Szkołęś mi dało twardą.

Fragment: Morze, moje morze

Daj znać innym

W skrócie: Jest to cały dzień programowania w parach ćwicząc Test-Driven Development. Nacisk kładziony jest na to jak pracujemy (w przeciwieństwie do tego nad czym pracujemy). Słowo klucz: kata

Czym moje warsztaty różniły się od prawdziwych „CodeRetreat”?

• Były to warsztaty zamknięte (tylko dla pracowników)
• Były zorganizowane w dzień roboczy (a nie w sobotę)
• Odbyło się tylko 5 sesji (a nie 6-7)
• Nie poszliśmy na koniec do pubu

Z informacji zwrotnej uzyskanej od uczestników wynika, że warsztaty się podobały

Zresztą proszę poczytać co mieli do powiedzenia uczestnicy:

Na pewno ten czas spędziłem ciekawie. Programowanie w parach pokazało, że każdy może wnieść od siebie coś nowego, rzucić światło na pewne aspekty, których się nie dostrzegało. W każdej sesji rodziły się nowe pomysły i podejścia do rozwiązania wciąż tego samego problemu. Była to dobra okazja do wymiany doświadczeń a także do praktycznego wykorzystania TDD. Polecam każdemu wzięcie udziału w takich warsztatach. Uważam, że jest to czas dobrze wykorzystany. - Michał

Ciekawe i dobrze przygotowane szkolenie. Dużym plusem jest to, że szkolenie to jest w formie warsztatów. Forma ta pomaga wymieniać doświadczenie i uczyć się od siebie nawzajem, co uważam, za największą wartość, jaką wyniosłem. Poza tym, była to dobra zabawa. – Janek

Pierwszy raz uczestniczyłem w tego typu warsztatach i muszę przyznać, że jestem miło zaskoczony.
Kilkukrotne rozwiązywanie jednego problemu  (prostego swoją drogą), ale z różnymi osobami prowadziło do różnych ciekawych wyników.
Programowanie w parach ma w sobie moc, bez względu na to, czy programuje się z kimś słabszym czy lepszym – oto jeden z moich wniosków po tych warsztatach.
Warsztaty przygotowane dosyć rzetelnie, zarówno od strony technicznej ( sala, komputery ), jak i merytorycznej – całkiem sporo wiedzy zostało przekazane – wiedzy, która według mnie powinien posiadać każdy programista.
Jednym słowem – brawo Grzegorz! Wyszło świetnie, pomimo że pierwszy raz organizowałeś tego typu zajęcia. Mirek

Dziękuję za możliwość wzięcia udziału w warsztatach. Bardzo podobała mi się ich forma i zróżnicowanie doświadczenia uczestników. Choć byłem w mojej ocenie najmniej zaawansowanym uczestnikiem warsztatów poradziłem sobie z pomocą kolegów i koleżanek z zadaniem jakie mieliśmy do wykonania. Samo zadanie również było bardzo interesujące i wciągające. Czas podczas warsztatów upływał niemiłosiernie szybko lecz mimo to w kolejnych krokach udawało się dochodzić co raz to dalej. Warsztaty uświadomiły uczestnikom, a na pewno mi, że jeżeli chcę tworzyć poprawny kod to bez wątpienia powinienem wychodzić o tworzenia testów, a kończyć na implementacji (przekonałem się do tego już podczas drugiej sesji). Uważam, że osoba przygotowująca warsztaty zachowała się profesjonalnie i swoją postawą zachęcała do działania. Chciałbym, aby takie warsztaty były organizowane cyklicznie i uważam, że warto zainteresować nimi większy odsetek pracowników mających możliwość wykorzystania tej wiedzy w codziennej pracy.
Jeszcze raz dziękuję za ciekawy dzień pracy. Grzesiek

Wydarzenie było dość kameralne – uczestniczyło w nim 6 osób + ja.  Programowaliśmy w Javie.

Przez pierwsze 3 sesje byłem obserwatorem. Było to o tyle fajne, że mogłem podglądać co robią ludzie i na retrospekcjach po sesjach poruszać tematy dotyczącego tego, co widziałem że działo się u innych.

Ostatnie 2 sesje sam aktywnie kodowałem w parze i o ile pozwoliło mi to poczuć na własnej skórze to co robili uczestnicy, to bardzo utrudniło dawanie wskazówek odnoszących się do tego co działo się w innych parach.

Na retrospekcjach poruszaliśmy temat związane z:

• Różnymi pomysłami na zakodowanie rozwiązania
• Jak pisać czysty kod
• Jak efektywnie programować w parach (np. ping-pong programming)
• Test-driven development, TDD as you meant it

Warsztaty zaczęliśmy, krótkim wstępem, gdzie

• Każdy miał szansę się przedstawić
• Przedstawiłem plan dnia
• Opowiedziałem trochę skąd pomysł (QCon i wykład Corey’a Haines)
• Powiedziałem klika słów o Software Craftsmanship (care, practice, learn, share), manifest
• Przytoczyłem klika wskazówek na temat tego, jak programować w parach.
• Przypomniałem zasady TDD
• Omówiłem zasady „Gry w życie”

W czasie przerwy obiadowej przejrzeliśmy slajdy Sharpening the Tools

Code Retreat we Wrocławiu

Ponieważ warsztaty uważam za udane, myślę że warto zorganizować prawdzie „CodeRetreat” dla Wrocławia. Jeśli ktoś jest zainteresowany to proszę o kontakt.

Co jest niezbędne by to urzeczywistnić?

• Duża sala, gdzie wygodnie można siedzieć i kodować w parach przy laptopach.  (sponsor)
• Uczestnicy z laptopami
• Termin

Więc nie potrzeba chyba aż tak dużo?:)

A co mogłoby wydarzenie uczynić jeszcze fajniejszym

• Dodatkowe monitory, by wygodnie pracowało się na laptopach
• Obiad ufundowany przez sponsora
• Dostęp do neta
• Na zakończenie wyjście integracyjne, ufundowane przez sponsora

Jeśli ktoś ma pomysł jak powyższe rzeczy zdobyć a tym samym urzeczywistnić Wrocławskie CodeRetreat proszę o info w komentarzach

Linki:

• http://coderetreat.ning.com/profiles/blogs/how-to-run-a-coderetreat
• http://www.coderetreat.com/
• http://www.agileminds.be/workshop/2010/coderetreat/index.html

Daj znać innym

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.

Daj znać innym

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?:)

Daj znać innym

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

Daj znać innym

Technika jest bardzo prosta.

• Ustal co chcesz zrobić i nastaw timer na 25 minut.
• W czasie tego 25 minut intensywnie pracuj (wyłącz poczte, gg, poproś aby Ci nie przerywano).
• Po upływie 25 minut nastaw timer na 5 minut przerwy.
• W czasie przerwy, zajmij się czymś zupełnie nie związanym z pracą. Kawa, toaleta, spacer po biurze.
• Zrób 4 takie cykle. Po 4 cyklu przerwa powinna być dłuższa, np 20 minut.

Prawda, że proste?

Strona na której można dowiedzieć się jeszcze więcej.

Jedną z zalet jest wzrost Twojej produktywności. Gdy robisz przerwę, Twoja podświadomość dalej pracuje nad rozwiązaniem problemu z którym walczyłeś i jednocześnie gdy wracasz do zadania, patrzysz na nie z pewnym dystansem.

Super się to sprawdza podczas kodowania. Jeśli używasz TDD to przerwanie pracy gdy timer każe też nie będzie problemem, bo test szybko pozwoli Ci odświeżyć kontekst gdy wrócisz do zadania.

Już po pierwszej iteracji stosowania pomidorów zaczęliśmy estymować zadania właśnie używając tej jednostki. Naturalne też było stawianie „kropek” po każdym zakończonym pomidorze na karteczce reprezentującej zadanie, dzięki czemu mogliśmy śledzić dokładność naszych estymacji.

Daj znać innym

Właśnie kończę czytać Agile Coaching. Bardzo podoba mi się ta książka i mogę ją polecić każdemu, kto jest zainteresowany niesieniem pomocy zespołowi jako trener.

Jedną z ciekawostek znalezionych w tej książce jest http://toastmasters.org/

ToastMasters jest to społeczność, która organizuje spotkania na których ćwiczy publiczne przemawianie. Istnieje grupa we Wrocławiu i mam zamiar dowiedzieć się czegoś więcej na ten temat. Myślę, że pojawię się na następnym spotkaniu

Daj znać innym

Niestety nie pamiętam źródła, więc jeśli kojarzysz to proszę dopisz w komentarzach.

Jeśli chcesz ocenić jakiś pomysł lub spojrzeć na sprawę z różnych stron zastosuj ten prosty szablon:

• Co się stanie gdy X
• Co się nie stanie gdy X
• Co się stanie gdy nie X
• Co się nie stanie gdy nie X

Na przykład: Mam możliwość pójść na ciekawe spotkanie, ale jest ono w tym samym terminie co moje zajęcia na uczelni.

• Co się stanie gdy pójdę na spotkanie?

Dowiem się ciekawych rzeczy z pierwszej ręki na interesujący mnie temat.

• Co się nie stanie gdy pójdę na spotkanie?

Nie oddam w terminie zadania na zajęciach.

• Co się stanie gdy nie pójdę na spotkanie?

Nie poznam osób, które będą na tym spotkaniu.

• Co się nie stanie gdy nie pójdę na spotkanie?

Nie dostanę gorszej oceny na koniec semestru.

Czy jest ktoś, kto jeszcze tego nie znał?

Daj znać innym