Wpisy otagowane ‘agile’

Mini konferencja w pracy

piątek, 18 Maj 2012

Pod koniec kwietnia odbyła się wewnętrzna konferencja w mojej pracy. Był to jeden z moich celów na ten rok - hura! udało się go zrealizować :)

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..

Legacy Code Retreat Berlin

poniedziałek, 16 Kwiecień 2012

W ostatnią sobotę miało miejsce pierwsze berlińskie Legacy Code Retreat (w sile 16 uczestników). Pomogłem trochę w jego organizacji, głównie jednak wziąłem w nim udział jako uczestnik. W tym poście opiszę swoje wrażenia.

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..

 

Artykuł o programowaniu w parach

niedziela, 15 Styczeń 2012

W piątek miałem okazję przeczytać bardzo ciekawy artykuł o programowaniu w parach.

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ę).
W  podobny sposób pracowałem w czasie swojej praktyki w Pinesoft. Po 2 pełnych cyklach Pomodoro rotowaliśmy pary. Praca była bardzo intensywna, ale mega satysfakcjonująca.
Gdy uda mi się przekonać mój obecny zespół, wypróbujemy powyższy system z rotowaniem par po pełnym cyklu pomodoro (około 2h).
A Ty jakie masz doświadczenia z pair programmingiem?

Praktyki stosowane w moim zespole

niedziela, 15 Styczeń 2012

W ramach „Poranku z Nokią i z SEnSem” poprowadziłem na PWr skierowany do studentów  wykład o praktykach stosowanych w moim zespole.

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:

(więcej…)

Powiew świeżości

sobota, 29 Październik 2011

Jak uniknąć stagnacji, rutyny, braku nowości itp. w pracy?

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?