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

Wczoraj rozmawiając z kolegą zaproponowałem zrobienie prostej aplikacji.

Odpowiedział: „O ciekawe! Myśleliśmy już o tym – super pomysł…. Kiedyś mieliśmy „dni innowacji”, ale potem z czasem jakoś przestaliśmy je robić. Gdzie podziały się te pomysły?”

Zapewne jest wiele sposobów na podtrzymanie ekscytującej atmosfery w pracy.

Oczywiście potrzeba ludzi wkręconych i kochających to co robią. Ale Ci ludzie pozostawieni sami sobie z czasem popadną w rutynę, będą znali się na wylot, będą mieli swoje ulubione techniki i style pracy.

Naszemu zespołowi może pomóc: czytanie książek, blogów, Twittera i wyjazdy na konferencje. To zapewni przypływ świeżych pomysłów.

Ale skąd brać siły na ich wdrażanie w terenie, który jest dobrze zbadany i unormowany? Czasem, zwłaszcza z małymi rzeczami nie jest to problem: „Spróbujmy przez tydzień programować w parach.. Hmm, czemu nie?„.

Czasem nie jest to takie proste: „Spróbujmy wrzucać nasz soft na produkcje jednym kliknięciem myszki.. No co ty, to się nie uda, za dużo biurokracji, próbowaliśmy„. Każdy wie, że jest coś czego nie da się zrobić, ale przychodzi ktoś kto nie wie, że się nie da i robi to ! ” Albert Einstein. Jednym słowem potrzebujemy studenta .. Lub, kogoś z autorytetem i wiedzą że się da, bo zrobił to gdzie indziej: konsultanta.

Na chwilę obecną uważam, że by zapewnić przepływ świeżej krwi w zespole potrzeba: konsultantów, którzy są z zespołem od 3 do 6 miesięcy i studentów. Konsultanci wzbogacą zespół ideami z innych miejsc, w których byli. Studenci będą zadawać pytania. Wszystko to zachwieje ustalonym statusem quo i zapewni jakże potrzebny powiew świeżości.

Masz jakieś doświadczenia lub przemyślenia w tym temacie?

Daj znać innym

W telegraficznym skrócie:

Niedziela

• Warsztaty A user user manual z Chrisem Nodderem. Porady na temat tego jak tworzyć przyjazne i łatwe w użytkowaniu oprogramowanie + teoria na temat tego, jak zachowują się użytkownicy i dlaczego.

Poniedziałek

• Google prezentuje nowy język programowania – Dart

Wtorek

• TODO

 Środa

• TODO

Czwartek

• Warsztaty „Evolutionary Architecture – How to Make it Work” z Martinem Fowlerem i Rebeccom Parsons
• Warsztaty ”Influence Strategies for Practitioners” z Linda Rising

Piątek

• Warsztaty ”Maintaining and Evolving Legacy Systems” z Frankiem Buschmann

Ogólne komentarze i podsumowanie:

W tym roku do materiałów konferencyjnych dołączone zostały dwie małe książeczki: „The 3 pillars of personal effectiveness” oraz „Priming Kanban” - oryginalne i fajne posunięcie.

I tak na przykład w „Priming Kanban” wyczytałem, co robić gdy osiągamy limit „work in progress„. Jest to moment na dyskusję. Do wyboru mamy albo powiększyć limit (co będzie skutkować zwiększeniem czasu, jaki jest potrzeby by historyjka przewędrowała od „koncepcji” do „wdrożenia”) albo usprawnić/wspomóc „wąskie gardło”. Np. gdy „testowanie” jest wąskim gardłem, może jako programiści możemy zautomatyzować wrzucanie nowej wersji na środowisko testowe? Tak czy inaczej, osiągnięcie limitu „work in progress” jest pretekstem do dyskusji.

Konferencja to również męczące wydarzenie (pełno wrażeń, codziennie integracja), nie mniej z niecierpliwością czekam na kolejną konferencję organizowaną przez Trifork, QCon 2012 w Londynie

Daj znać innym

Koordynacją wolontariuszy zajmowałem się razem z drugim „Gregiem”. Myślę, że nasz duet w miarę dobrze się sprawdził, mi w każdym razie współpracowało się z Gregiem dobrze

Ciekawostka: W czasie organizacji ALE2011 była to normalna sytuacja (kilka osób odpowiedzialnych za jeden obszar, bez formalnego lidera). ALE2011 wprowadziło koncepcję „sof” (nawiązując do „Conference Chair”).

Podczas konferencji do zadań wolontariuszy należało: rejestracja uczestników, odpowiadanie na pytania w punkcie informacyjnym, pilnowanie czasu prezentacji, zbieranie feedbacku po prezentacji, pomoc w opiece na dziećmi, robienie zdjęć oraz reagowanie na nie przewidziane wydarzenia (np. wyczerpanie się baterii w mikrofonie).

Rekrutacja

Wolontariuszy próbowaliśmy rekrutować za pomocą Twittera, strony eventu, facebooka (bezpośrednie kontakty) i innych sieci społecznościowych. Wysłałem też e-maile do kilku uczelni w Berlinie oraz do Wrocławia. W sumie udało nam się z rekrutować 8 osób, z czego jedna się rozchorowała a druga „nie dawała znaku życia po rejestracji”.

W zespole wolontariuszy były 3 osoby z Berlina (Lina z Kolumbii, Budi i Melisa z Indonezji), 2 osoby z Brna (Petr i Michal) oraz Adam z Krakowa.

• Wszyscy zarejestrowani wolontariusze dowiedzieli się o możliwości bycia wolontariuszem bezpośrednio od kogoś, kogo znali.
• Z 8 zarejestrowanych wolontariuszy, 2 nie dotarło na event. By „bez problemu” poradzić sobie z zadaniami, jakie stały przed wolontariuszami potrzeba by około 14 osób.
• Deadline „rejestracji” wprowadzał zamieszanie. Wolontariusze nie byli pewni czy można się jeszcze rejestrować.
• Ekipa wolontariuszy była świetna
• Plakaty na uczelni! By dotrzeć do studentów, warto by było powiesić plakaty na uczelni. Niestety nie wszyscy śledzą Twittera i wchodzą na stronę konferencji

Daj znać innym