Pomysł na konferencję zrodził się w głowie koleżanki z pracy w pod koniec zeszłego roku. Jeszcze w grudniu mieliśmy pierwsze spotkanie organizacyjne i sformowaliśmy nieformalny zespół. Niecałe pół roku później 80 osób mogło uczestniczyć w wydarzeniu składającym się z 12 wykładów (w 2 ścieżkach) i godzinnego „open space”. Konferencje wystartowała w czwartek o 15 i zakończyła się po 19.

Pokrótce o naszym pomyśle na konferencję: W moim biurze pracuje sporo osób: ponad 800. Regularnie odbywają się jakieś małe eventy, na przykład co 2 tygodniowe wykłady na tematy techniczne organizowane przez zaangażowane osoby w różnych częściach organizacji.

„Problem” polega na tym, że na poszczególne eventy z reguły przychodzą zawsze „te same osoby” i eventy przyciągają osoby związane z organizatorem wydarzania. Na sesje grupy A przychodzą członkowie zespołu A, B i C, a na warsztaty grupy X przychodzą ludzie z X, Y i Z. Nie było niczego co przyciągnęłoby wszystkich. Nie było wydarzenia na temat techniczny na którym pojawili by się przedstawiciele zespołów A, B, C, X, Y i Z.

Tak powstał pomysł na konferencję: Stworzyć coś, co przyciągnie wszystkich i pozwoli się nam nawzajem poznać.

By zrealizować naszą wizję przyciągnęliśmy prezenterów z różnych części organizacji. Następnie zadbaliśmy o odpowiednią promocję: wysłaliśmy maile na najróżniejsze grupy dyskusyjne, stworzyliśmy plakaty i ulotki, które rozprowadziliśmy po budynku.

Konferencję rozpoczęliśmy ”ice breakerem”, gdzie ludzie mieli okazję się troszkę poznać. Następnie mieliśmy wykłady zorganizowane tak, by ludzie „zmuszeni” byli zobaczyć coś nie związanego z ich specjalizacją. Zamiast np. ścieżki technicznej i agielowej mieliśmy ścieżki mieszane. Najpierw dwa równoległe wykłady techniczne, później dwa równoległe wykłady na temat procesu. Sesje było ograniczone w czasie do 25 minut by zbytnio „nie zanudzić” uczestników.

Na koniec odbył się godzinny „open space”. Była to część konferencji gdzie uczestnicy sami decydowali o czym będą rozmawiać. Sesja ta bardzo się podobała i w jej wyniku powstało kilka konkretnych inicjatyw. Następnym razem na pewno poświęcimy tej części programu więcej czasu..

Komentarze uczestników i „menadżmentu” po konferencji były bardzo pozytywne i już myślimy o tym kiedy zorganizować kolejną jej edycję…

A propo „menadżmentu”. Wszyscy organizatorzy byli „szeregowymi pracownikami”. Konferencja została zorganizowana ”przez nas”. Konferencję organizowaliśmy pomiędzy naszymi normalnymi obowiązkami – spotkania odbywały się w czasie obiadów lub po pracy. Oczywiście gdy już mieliśmy konkretny pomysł co chcemy zrobić zaczęliśmy zabiegać o wsparcie naszych przełożonych, które w końcu uzyskaliśmy (co wymagało równoległych rozmów w kilku „częściach organizacji”).

W każdym razie przekaz jest taki: Jeśli masz pomysł na coś ciekawego – zrób to! Małymi kroczkami, krok po kroku, da się zbudować coś dużego

Zresztą, to nie pierwszy raz..

Daj znać innym

Format

Format Legacy Code Retreat został zaproponowany przez  J. B. Rainsbergera i jest podobny do „normalnego” Code Retreat – składa się z 6 sesji, w których pracujemy w parach i po każdej sesji kasujemy nasz kod. W przeciwieństwie jednak do normalnego Code Retreat nie zaczynamy od zera pisać „Grę w życie” a pracujemy już z dostarczonym kodem gry Trivia i naszym celem jest jego zrozumienie i bezpieczne zrefaktoryzowanie.

Nasz event poprowadzony został przez Martina Klose, który świetnie spisał się w roli facylitatora. Rozpoczęliśmy od krótkiego wprowadzenia, gdzie Martin omówił „4 rules of simple design” i algorytm refaktoryzacji legacy kodu. Z ciekawostek, event prowadzony był po angielsku, z czego bardzo się cieszę, jako że byłem jedyną osobą która nie potrafiłaby pracować po niemiecku..

Fajnym motywem podczas rozpoczęcia dnia było ćwiczenie, które wykonaliśmy by „szybko się poznać” w grupie. Martin polecił nam ustawić się w szeregu, gdzie na jednym końcu były osoby, które uważały się za wymiataczy w TDD a na drugim końcu, osoby, które dopiero rozpoczynały swoją przygodę z TDD. Następnie Martin zasugerował by osoby początkujące pracowały w ciągu dnia z osobami doświadczonymi.

• Sesja 1 – Zapoznanie z kodem
• Pierwsze starcie z kodem. W tej sesji rozpoczęliśmy pisanie testu charakteryzacyjnego i zajęło nam to praktycznie cały dostępny czas (przy czym prawie 10 minut zmarnowaliśmy na skonfigurowanie JUnita, który z jakiegoś powodu nie chciał dodać się do projektu, ech…). Dev z którym pracowałem w parze nigdy nie pisał w Javie, także trochę czasu spędziliśmy również na wytłumaczenie podstawowych rzeczy na temat Javy.
• Sesja 2
• Martin sugeruje wszystkim zastosowanie techniki Golden Master. Sprowadza się to mniej więcej do tego co robiłem w poprzedniej sesji, więc z moim nowym dev partnerem ruszamy do kodowania. Po parunastu minutach mamy już gotowy test, który porównuje wykonanie programu z naszą „złotą kopią”. Jesteśmy pewni siebie i wtedy pojawia się Martin z pytaniem „Skąd wiecie, że wasz test jest wystarczający?” „Jaką macie pewność, że pokrywa on wszystko to, co robi kod?”. Jako stary wyjadacz „testowania mutacyjnego” nie daję się zbić z tropu i przystępujemy do „testowania” naszego testu poprzez celowe wprowadzanie błędów do kodu produkcyjnego i obserwowanie czy nasz test to wykrywa. Martin miał rację.. Są pewne modyfikacje, których nasz test nie wyłapuje. Resztę sesji spędzamy na udoskonalaniu naszego testu.
• Sesja 3
• W tej sesji skupiliśmy się na refakoryzacji kodu. Konkretnie poprawialiśmy czytelność (łatwość zrozumienia) instrukcji warunkowych, np. „if (roll % 2 != 0)” na „if(canLeavePenatlyBoxAfter(roll)”

• Sesja 4
• Refaktoryzacja kodu małymi kroczkami. Reguły: Ustaw timer na 2 minuty. Pracuj z kodem i wrzucaj swoje zmiany do repozytorium kodu. Jeśli w ciągu 2 minut nie zdążysz wrzucić niczego do repo, cofnij swoje zmiany do momentu ostatniego commitu w repo i rozpocznij od nowa. Po drugim razie, gdy dopadł nasz timer, pracowaliśmy w naprawdę malutkich kroczkach i w sumie daliśmy radę! Generalnie, im częściej wrzucamy nasze zmiany do repo tym lepiej (mniej konfliktów, częstszy feedback), także myślę że ćwiczenie wykonane w tej sesji było wartościowe.
• Sesja 5
• Celem tej sesji było zidentyfikowanie fragmentów kodu, które dało się zamienić w „pure functions„. Podczas tej sesji pracowałem w Rubym (wszystkie poprzednie były w Javie) i odczułem na własnej skórze, jak wspaniałe wsparcie do refactoringu ma Java.. (Np. IDE w Javie było dużo sprytniejsze w znajdywaniu duplikacji w kodzie). Jedną z zalet „wyciąganych” przez nas funkcji było to, że można je było stosunkowo łatwo przetestować.
• Sesja 6
• W czasie tej sesji, po zidentyfikowaniu i stworzeniu kilku „pure functions” mieliśmy przyjrzeć się im bliżej i zastanowić się, gdzie można by je przenieść – jednym słowem, zaczęliśmy „wyciągać klasy”. Cały schemat refactoringu można opisać mniej więcej tak:
• Extract method
• Replace fields with parameters to the method
• Make method static
• Test the method
• Find a new home for the method, move to (and maybe create) new class
• Alternatywnym sposobem, wypróbowanym przez niektórych uczestników było zastosowanie refaktoringu „pull up” i przeciągnięcie pewnych funkcjonalności do „nowej” klasy bazowej, a następnie zastosowanie refakoryzacji „replace inheritance with delegation” – coś, co mam w najbliższym czasie przetestować.

Scala

Po trzeciej sesji mieliśmy długi lunch, w czasie którego rozmawiałem o Scali. Temat, który mnie interesował to testowanie i jak w podejściu funkcyjnym radzimy sobie z problematycznymi zależnościami kodu, takimi jak baza danych czy odwołania do innych systemów. W podejściu obiektowym, używamy w tym celu „mocków’. Z tego co zrozumiałem, w Scali ważnym pojęciem jest kompozycja funkcji, i właśnie odpowiednio korzystając z kompozycji możemy „wstrzykiwać” albo prawdziwą funkcję, która pobiera dane z bazy danych, albo funkcję „testową”, która tylko udaję bazę danych. I tak testowanie takiego systemu sprowadza się do przetestowania funkcji, z których składa się nasz system na poziomie jednostkowym, a następnie przetestowanie całego systemu (złożonej funkcji), gdzie być może niektóre funkcje zastąpione są zmienikami na potrzeby testów.

Organizacja

Jeśli chodzi o organizację tym razem kupiliśmy małe śniadanie w piekarni a na obiad poszliśmy do restauracji – wyszło to dużo taniej niż zamawianie kateringu.

Generalnie, bardzo nam się podobało i już myślimy o kolejnym evencie, może w czerwcu?

Zachęcam Cię do organizacji Legacy Code Retreat w swoim mieście!

Ps. Zdjęcia z wczoraj można zobaczyć tutaj..

Daj znać innym

Nasz idealny proces powinien:

• Zapewniać szybką informację zwrotną na temat jakości.
• Kierować się zasadą „jakości wbudowanej w proces„.

Ps. Jakiś czas temu opisałem na tym blogu różne rodzaje testów automatycznych.

Daj znać innym

W maju opowiem o tym Coding Dojo na żywo na konferencji XP2012!

Najpierw we wtorek rano przedstawię „Experience report: Coding Dojos @ Nokia” gdzie opowiem dlaczego mamy dojo, jak to się wszystko zaczęło,  jak nasze dojo wygląda i czego się nauczyliśmy a propo prowadzenia dojo. Następnie w środę po południu poprowadzę dojo, gdzie teorię zastosujemy w praktyce.

Mam nadzieję, do zobaczenia na XP2012 w Malmo !

Daj znać innym

Slajdy z wykładów są tutaj a w ciągu kilku miesięcy powinny zacząć pojawiać się nagrania wideo na infoq.com

Moje wrażenia / notatki..

Kompromis – wszystkie nasze decyzje wiążą się z kompromisami. Ważne jest, by być świadomym na jaki kompromis idziemy.

Erlang - konferencję rozpocząłem warsztatami z podstaw Erlanga. Jeśli chciałbyś dowiedzieć się więcej na temat języka zajrzyj tutaj.

Bardzo podobała mi się prezentacja na temat Wooga. Wooga tworzy gry na Facebooka i są drudzy na świecie. Chłopaki używają tam (między innymi) Erlanga i Rubiego. Każdy zespół opiekuje się jedną grą. W szczególności ciekawy i bliski sercu wydał mi się ich system wartości:

• Małe zespoły lepsze niż duże
• Współpraca pomiędzy zespołami lepsza niż współzawodnictwo
• Wszechstronnie uzdolnieni pracownicy lepsi niż specjaliści
• Zmniejszanie nakładu pracy lepsze niż zmniejszanie kosztów
• Innowacyjność lepsza niż zmniejszanie ryzyka

Wrażenie po warsztacie z retrospekcji: W Nokii robimy to całkiem dobrze – wiedza prezentowana na warsztacie zgadzała się z naszą praktyką.

Jeśli chodzi o wprowadzanie zmian to poruszone zostały między innymi te kwestie:

10 sekundowy build - Mamy rok 2012, build twojego pojedynczego projektu powinien trwać nie więcej niż 10 sekund (w tym kompilacja i wszystkie testy).

We wtorek wieczorem odwiedziłem XTC gdzie miałem okazję posłuchać o 7 letnim projekcie  XP. Warto było – słuchało się jak gawędy przy ognisku.

Moją uwagę przykuła również sesja na temat długiego projektu w Sky. Początkowo bardzo udany, projekt ten przeszedł przez fazę stagnacji, gdzie zespół co prawda dostarczał regularnie historyjki, ale energia w zespole znacznie spadła. Ludzie przestali np. regularnie praktykować programowanie w parach. Nie było już słychać tak dużo konwersacji w pokoju zespołu, ludzie siedzieli z nosami w monitorach. Padło określenie „delivery zombi”. Opisywana sytuacja brzmiała trochę znajomo, przypomniał mi się mój post na podobny temat. Jednym ze składników antidotum było ponowne określenie wizji i wyznaczenie celów biznesowych. Pomogło również „wstrzyknięcie” świeżej, zmotywowanej krwi w postaci nowego, zmotywowanego członka zespołu.

Na razie tyle

Daj znać innym

W skrócie: Opisany zespół, miał największą wydajność i najmniej bugów gdy:

• Historyjki były dewelopowane przez programistów o najmniejszej wiedzy domenowej (w obszarze danej historyjki)
• Historyjki były dewelopowane przez pary, które same wybierały nad czym chcą pracować
• Historyjki nie były przypisane konkretnym osobą, cały zespół był odpowiedzialny za historyjkę
• Pary rotowały co ~2 godziny. (Osoba która była dłużej w parze opuszcza parę).

Daj znać innym

Ponieważ to jakie praktyki najlepiej się sprawdzą zależy od naszego kontekstu, zacząłem od opisania sytuacji mojego zespołu.

Zespół w którym jestem jest

• mały (~7 osób)
• wszyscy siedzimy w jednym pokoju
• mamy wewnętrznego klienta / product ownera. Siedzi z nami na tym samym piętrze i ma dla nas czas
• tworzymy ważny, ale wewnętrzny system

Dla każdej praktyki powiedziałem:

• na czym polega
• dlaczego/po co ją stosujemy
• „dobre rady”

Oto lista praktyk, które aktualnie stosujemy w moim zespole:

Codziennie

• Stand-up
• Pair programming
• TDD
• Continuous Integration
• Continuous Delivery
• Story wall / Story lifecycle
• Work in progress limits
• Information radiators
• Learning huddle

Raz na tydzień

• Coding dojo
• Team lunch
• Dev-ops stand-up

Raz na dwa tygodnie

• 1-1 feedback

Raz na miesiąc

• Retrospekcja

Około raz na 3 miesiące

• Incepcja
• Estymacja
• Story mapping
• Persony

Na żądanie / Wg potrzeby

• Technical spike
• Demo / Show case
• Public code review
• Team charter

A jakie praktyki stosuje Twój zespół?

Daj znać innym

Wideo można zobaczyć tutaj: Refactoring of test

Filmik trwa 5 minut podczas których:

1. Rozbijam jeden duży test na kilka mniejszych (by testy były łatwiejsze do zrozumienia, a gdy nie przechodzą by dokładnie było wiadomo co nie działa)
2. Zamieniam assertEquals na assertThat (naturalniej się czyta)
3. Zastępuje komentarze opisowymi nazwami testów (by samo zerknięcie do raportu w ciągłej integracji wystarczyło do zorientowania się, co się dzieje)

Daj znać innym

W roku 2011

Udało mi się:

• W lutym zostać magistrem – uff!
• Pracować w świetnym zespole!
• Nauczyć się nowych rzeczy o testowaniu.
• Pojechać jako wolontariusz na QCon w Londynie, XP w Mardycie i GOTO w AArhus
• Być koordynatorem wolontariuszy w czasie konferencji ALE w Berline
• Zorganizować razem z Markusem lipcowe CodeRetreat w Berlinie
• Zorganizować i poprowadzić razem z Markusem CodeRetreat w Berlinie w ramach światowego dnia CodeRetreat w grudniu
• Prowadzić w Nokii cotygodniowe Coding Dojo
• Poprowadzić mały warsztat na temat „1-1 feedback” dla innego zespołu w Nokii. Poprowadzić Extreme Startup w ramach dojo.
• Zapisać się i wygłosić 3 mowy w berlińskim klubie Toastmasters
• Uczestniczyć w kilku spotkaniach #xtcb (Extreme Tuesday Berlin)
• Rozpocząć naukę Scali i Rubiego
• Zostać certyfikatowanym programistą Springa
• Przeczytać: Release It, Presentation Zen, The Clean Coder, Managment 3.0, Kanban, Specification By Example, Lean Startup i rozpocząć kilka innych książek.
• Poeksperymentować z Kanbanem.
• Założyć konto na githubie

• Czytać 1 książki na miesiąc
• Pojechać na Agile2011 do stanów ani wziąć udział w Agile Testing Days w Berlinie
• Zostać prelegentem na konferencji
• Nauczyć się niemieckiego na tyle, by móc biernie uczestniczyć w spotkaniach prowadzonych po niemiecku.

W roku 2012 chciałbym:

• Pracować z ludźmi, od których mogę się bardzo dużo i szybko uczyć (tak jak to było w roku 2011)
• Pojechać jako wolontariusz na QCon i wziąć udział w 2 innych dużych konferencjach (XP? GOTO? ALE?)
• Zorganizować coś otwartego w Nokii, np. co 2 tydzień robić otwarte Coding Dojo dla ludzi z poza firmy
• Co najmniej raz w miesiącu brać udział w spotkaniu społeczności w Berlinie
• Wziąć udział w CodeRetreat jako uczestnik
• Wygłosić 6 mów w Toastmasters. Wziąć udział w konkursie na najlepszą mowę w klubie.
• Czytać jedną książkę na miesiąc
• Spopularyzować refactor-my-code step by step
• Poprowadzić wykład dla studentów
• Założyć anglojęzycznego bloga
• Nauczyć się biegle innego języka niż Java (Ruby?).
• Oglądać co najmniej jedną prezentację na tydzień (np. z infoq, ted)
• Spróbować wcielić w życie koncepcję lunch with a stranger w pracy.
• Zorganizować mini konferencję w pracy.
• Stworzyć „continuous delivery pipeline” dla projektu, w którym teraz pracuję
• Certyfikować się w jakieś kolejnej technologii

Jakie są Twoje plany na rok 2012?

Daj znać innym

Pomyślałem, super by było, gdyby ktoś mi pokazał jak napisać to lepiej.. „Refactor my code”.. Po krótkim googlowaniu okazało się, że jest już taki serwis: http://refactormycode.com/

O ile nazwa jest już zajęta .. to mój pomysł miał jeszcze jeden istotny składnik. Założyłem, że ważne jest by „mój” kod nie tylko został poprawiony, ale żeby został poprawiony w małych kroczkach z wytłumaczeniem „dlaczego”, tak bym mógł się nauczyć i następnym razem sam napisać coś porządnie..

W gruncie rzeczy, to marzy mi się „coding dojo” rozproszone w czasie i przestrzeni. Piszę kod, który zapewne może zostać napisany lepiej. Chciałbym abyś wziął ten kod i w małych kroczak go ulepszył. Po każdym kroczku zrób commit i wyjaśnij co i dlaczego zrobiłeś.

Prototyp tego co mam na myśli dość szybko udało mi się stworzyć przy pomocy githuba.

https://github.com/dziemid/refactormycode

Napisałem  dość brzydką wersję String Calculatora , którą następnie trochę  poprawiłem .. Nie mniej wersja końcowa nie jest aż tak ciekawa jak sam proces jej tworzenia, gdzie każdy mały kroczek został udokumentowany.

Pomysł został podchwycony przez Martina, która zrefaktoryzował mój kod krok po kroku (tutaj jeden z jego kroków w raz z moim komentarzem).

Dziś wrzuciłem kolejny kod do poprawienia: Grę w życie w Javie. Kod jest napisany średnio. Miejscami jest brzydki, niektóre klasy są w ogóle niepotrzebne, inne klasy robią rzeczy, które być może powinny być gdzie indziej.

Zachęcam Cię do zrobienia „Fork”a i zrefaktoryzowania tego kodu krok po kroku. W każdym commicie napisz co i dlaczego robisz. W ten sposób razem stworzymy coding dojo rozproszone w czasie i przestrzeni

Daj znać innym