Archiwum kategorii ‘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..

 

Strategia testowania projektu

czwartek, 5 Kwiecień 2012

Niedawno dokumentowaliśmy w pracy strategię testowania naszej aplikacji. Przy okazji zastanowiliśmy się jak wyglądałby „idealny” proces. W tym wpisie opiszę co wymyśliliśmy.

Nasz idealny proces powinien:

Kontekst naszego systemu:
  • Nasza aplikacja dostarcza API wykorzystywane przez inne systemy
  • Nasza aplikacja używa API innych systemów
  • Nasza aplikacja posiada webowy interfejs użytkownika
Idealny proces
  • Identyfikacja wymagań
    • Klient, programista i tester dokumentują wymagania w postaci historyjek
    • Do historyjek dodane są kryteria akceptacji. Ponieważ programista i tester pomagali klientowi w formułowaniu tych kryteriów, zostały zadane pytania na temat wyjątkowych przypadków (np. Co system powinien zrobić jeśli szesnastolatek próbuje kupić produkt o wartości powyżej 10tyś zł).
  • Implementacja
    • Programiści pracują w parach. Dzięki temu wyłapywane jest szybko wiele „ludzkich błędów” (wynikających np. ze zmęczenia, rozproszenia etc.)
    • Stosujemy TDD, co wpływa korzystnie na jakość wewnętrzną oprogramowania.
    • W wyniku stosowania TDD mamy całkowite pokrycie kodu testami jednostkowymi. Testy te dostarczają szybką informację zwrotną, gdy programista próbuje zmienić kod w sposób, który psuje jakąś inną istniejącą funkcjonalność.
    • Funkcjonalność naszego systemu dokumentujemy w postaci automatycznych scenariuszy. Testy te sprawdzają działanie całego naszego systemu, natomiast nie testują systemów z którymi nasz system się integruje. Jeśli nasz system A używa systemu B, to nasze testy nie będą korzystały z prawdziwego systemu B. Zamiast tego, napiszemy „sztuczną” wersję systemu B, która będzie działać w pamięci. Dzięki temu będzie wykonywać się szybko. (Dodatkowo, jeśli system B to system do płatności, to nie chcemy żeby w rezultacie wykonania naszych testów obciążone zostały prawdziwe karty kredytowe).
    • Jeśli implementowana przez nas funkcjonalność wymaga usług systemu zewnętrznego, to tworzymy sztuczną wersję tego systemu działającą w pamięci. By mieć pewność, że ta sztuczna wersja zachowuje się tak samo jak prawdziwy system tworzymy testy CDC. Testy te dokumentują kontrakt, jaki oczekujemy że system zewnętrzny nam dostarczy. Testy CDC powinny być włączone do systemu ciągłej integracji i powinny testować prawdziwy zewnętrzny system oraz naszą sztuczną wersję. Tworzony przez nas testy CDC są przydatne dla programistów tworzących systemy, z których usług korzystamy, ponieważ informują one ich gdy ich nowe zmiany nie są zgodne z kontraktem, który nasz system oczekuje względem ich systemu.
    • Po skończeniu implementacji para zaprosi kogoś z zespołu i pokaże mu działającą funkcjonalność (mini demo). W tym kroku mogą zostać szybko wykryte ewentualne braki lub błędy, które zostaną natychmiast poprawione.
  • Ciągła integracja
    • Po każdym commicie do repozytorium kodu uruchamiane są wszystkie testy jednostkowe, automatyczne scenariusze, testy CDC. W poprzednim kroku dowiedliśmy, że system działał na maszynie konkretnego programisty. Teraz mamy pewność że działa on również na innych komputerach (a więc wszystko co jest potrzebne do poprawnego działania systemu zostało dodane do repozytorium kodu).
    • Nasz system dostarcza usług innych systemom. Inne zespoły dostarczyły nam ich testy CDC i w ramach ciągłej integracji zostaną one również uruchomione. W ten sposób wiemy, że „nie psujemy” innych systemów.
  • Środowisko testowe – klon środowiska produkcyjnego
    • Te środowisko jest maksymalnie zbliżone w konfiguracji do środowiska produkcyjnego. Jeśli na produkcji nasza aplikacja jest zreplikowana na kilku serwerach, to tutaj również będzie to miało miejsce. Również jeśli nasza aplikacja korzysta z systemów zewnętrznych, to w tym środowisku będziemy używać ich „prawdziwych” (testowych) wersji. A propo wersji, wersje tych systemów będą takie same jak aktualnie na produkcji.
    • Nowa wersja naszej aplikacji będzie wgrywana w sposób automatyczny i w taki sam sposób w jaki będzie to miało miejsce na produkcji. Oznacza to, że w tym kroku przetestujemy naszą procedurę aktualizacji do nowej wersji.
    • By pomóc w automatycznej weryfikacji poprzedniego kroku użyjemy „testów dymnych„. Np. szybki automatyczny test sprawdzający, że jesteśmy w stanie się zalogować.
    • Na tym środowisku odbędą się manualne testy eksploracyjne. W przypadku znalezienia jakiś problemów wrócimy do kroku implementacji, gdzie dodamy brakujące testy jednostkowe lub scenariusze dokumentujące problem a następnie go naprawimy. Testy eksploracyjne skupiają się na „szukaniu dziury w całym” (głównie) w nowej funkcjonalności. Nie są to „nudne, powtarzalne” testy manualny, te zostały zautomatyzowane.
    • Gdy zespół uważa, że historyjka jest gotowa i działa, zostanie ona zaprezentowana klientowi.
  • Produkcja
    • W poprzednich krokach przeszły wszystkie testy automatyczne, zespół wykonał testy eksploracyjne a klient jest zadowolony. Za pomocą jednego kliknięcia wrzucamy naszą nową wersję na produkcję. W ramach tego kliknięcia jeszcze raz wykonają się automatyczne „testy dymne”.
    • Nasz zespół działa w modelu devops i  jesteśmy współodpowiedzialni za poprawne działania naszego systemu na produkcji.
    • W pokoju zespołu stoją monitory wyświetlające aktualny stan produkcji (np. natężenie ruchu). Nasz system potrafi sam się badać (health check) i sygnalizuje problem np. gdy nie może uzyskać połączenia z bazą danych.
    • Dodatkowo, co dziennie / raz na tydzień wysyłane są specjalne raporty, dokumentujące użycie systemu. Wszelkie anomalie pozwalają wychwycić ewentualne subtelne problemy.
    • Mamy stały dostęp do logów naszego systemu oraz automatyczny raport, który wyłapuje wszelkie „wyjątki” w logach.
  • Środowisko testowe dla zespołów integrujących się z naszym systemem
    • Poprzednio opisałem środowisko do testów eksploracyjnych. Inne zespoły również muszą testować ich systemy w zestawieniu z naszym systemem. Dostarczamy im wersję naszego systemu, która jest taka sama jak wersja aktualnie znajdującą się na produkcji. Dzięki temu inne zespoły nie mają potrzeby testowania „na produkcji”.
Jak szybko możemy wrzucić prostą zmianę na produkcję?
Wyobraźmy sobie, że nasz system akceptował tylko rejestracje od użytkowników powyżej 21 roku życia. Klient chce to zmienić na 18 lat. Jak szybko w „bezpieczny” sposób możemy to zmianę wprowadzić? Korzystając z procesu powyżej mogłoby to wyglądać tak:
  • Klient tworzy historyjkę „Jako nowy użytkownik systemu chcę mieć możliwość zarejestrowania się gdy mam 18 lat”. Tester i programista nie widzą problemów. Czas trwania, 10 minut.
  • Dwóch programistów od razu zabiera się do pracy. Zmiana w jednym miejscu z 21 na 18. Czas trwania 10 minut, w tym uaktualnienie testów jednostkowych i scenariuszy.
  • Po wrzuceniu zmiany do repozytorium kodu uruchomienie wszystkich testów i scenariuszy. Czas trwania 5 minut.
  • Wrzucenie na środowisko testowe. Demo dla klienta. Czas trwania, 10 minut. Klient jest zadowolony.
  • Wrzucenie na produkcję za pomocą jednego kliknięcia. Czas trwania, poniżej 1 minuty.
Czas trwania od pomysłu do wersji używanej przez użytkowników – mniej niż 40 minut! Mniej niż godzina w aplikacji która integruje się z innymi systemami i jest używana przez inne systemy! Ponieważ nasz proces stworzył sieć bezpieczeństwa (np. testy CDC) i mamy tak duży stopień automatyzacji, proste zmiany jesteśmy wprowadzać w sposób bezpieczny fenomenalnie szybko!
To co opisałem powyżej „to nasz wymarzony” proces. Jak bardzo proces rzeczywisty różni się od tego powyżej? Nie aż tak bardzo.. Usprawnienia musimy wprowadzić:
  • na etapie „środowiska testowego” (bardziej je zautomatyzować i upodobnić do produkcyjnego)
  • Mamy dodatkową fazę testów „end-to-end” wykonywaną przez zewnętrzny zespół testerów. Z tej fazy chcemy zupełnie zrezygnować (zastąpiona przez automatyczne testy CDC i testy eksploracyjne wykonywane przez nasz zespół).
  • Położyć większy nacisk na testy CDC, w tym zachęcić naszych klientów do dostarczenia takowych.
Ciekaw jestem, czy u Ciebie proces wygląda podobnie do opisanego powyżej? A może jest zupełnie inny?

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

Opowiem o Coding Dojo w Malmo!

czwartek, 5 Kwiecień 2012

O Coding Dojo które mamy w pracy pisałem już na tym blogu (Coding Dojo, Coding Dojo 2).

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 !

 

QCon 2012

środa, 14 Marzec 2012

To już mój trzeci QCon! : )

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
Warsztat z „wprowadzania zmian” i warsztat z retrospekcji. We wtorek dwa warsztaty prowadzone przez Rachel. Reachel poprowadziła warsztaty w bardzo dobry sposób. W szczególności podobało mi się jak przed każdym ćwiczeniem tłumaczyła co i dlaczego będziemy robić. (tak jak to jest zalecane w tej książce )

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:

  • zanim zaproponujesz rozwiązanie – zamień się w słuch. Najpierw zrozum problem, dopiero potem sugeruj.
  • wczuj się w drugą stronę – co jest dla nich ważne? dlaczego mieliby zrobić tak, jak proponujesz?
  • świeć przykładem
  • znajdź sprzymierzeńców, osoby zainteresowane tym co chcesz zrobić (nie koniecznie w swoim zespole)
  • by zbadać poparcie dla inicjatywy możesz użyć „głosowanie dłonią”. Pięć palców – w pełni popieram i będę aktywnie wspierał inicjatywę. Pięść – weto!
  • Stwórz mapę sił które pomagają / przeszkadzają we wprowadzeniu twojej zmiany. Czy możesz coś zrobić by zwiększyć oddziaływanie sił pozytywnych lub/i zneutralizować działanie sił negatywnych?
  • bądź cierpliwy – wprowadzanie zmian trwa długo

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