Studio Pragmatists

To, że jestem fanem TDD wie pewnie każdy kto czyta ten blog. Za szczególnie dobrą jego formę uznaję BDD. W kodzie, który powstaje u nas w firmie staramy się stosować to podejście – nazewnictwo wyrażające intencję twórcy, testy pisane w formie przykładów (często z wykorzystaniem promowanego przez Szczepana Fabera szablonu //given //when //then), skupienie na celu powstawania kodu. Niedawno do naszego zespołu projektowego dołączyli nowi programiści (pracownicy naszego klienta) nieposiadający doświadczenia w TDD. Pierwsze o co zapytali to szczegółowa dokumentacja kodu. Nasze przekonywanie, że testy są kompletne i dokładnie dokumentują kod nie spotkały się ze specjalnym zrozumieniem z ich strony Doszedłem więc do wniosku, że gdybyśmy mogli wygenerować z naszych testów dokumentację – nawet tylko w formie listy funkcjonalności oferowanych przez nasz kod – to pewnie ich opory byłyby znacząco mniejsze. A że akurat prowadziłem tygodniowe szkolenie poza Warszawą (miałem więc codziennie parę wolnych godzin po pracy), postanowiłem napisać narzędzie, które pomogłoby w tworzeniu testów tak, by:

Cały zeszły tydzień byłem we Wrocławiu i prowadziłem szkolenie a potem coaching w zakresie TDD. Przypomniałem tam sobie jak bardzo lubię uczyć ludzi TDD. To szczególny czas. Gdy zaczynamy szkolenie większość uczestników to całkiem przyzwoici programiści. Często z paroletnim doświadczeniem, paroma lub nawet paronastoma większymi lub mniejszymi projektami za sobą. Są wśród nich tacy, dla których programowanie to tylko praca, są też tacy, którzy spędzają tak każdą wolną chwilę. Są przekonani, że TDD to dobry pomysł, ale są też sceptycy przychodzący sprawdzić kto ma rację. Dzięki temu takie szkolenia to dla mnie wyzwania by spełnić wszystkich oczekiwania, wymagające kreatywności i dobrego przygotowania, pozwalające mi wciąż się uczyć i poprawiać swój warsztat. Szkolenia z TDD to jednak głównie okazja dla uczestników, by z dobrych programistów stać się świetnymi. To oczywiście nie staje się w dzień ani tydzień, ale takie szkolenie jest świetnym początkiem takiej zmiany.
Bardzo lubię patrzeć, jak umiejętności uczestników zmieniają się z ćwiczenia na ćwiczenie. Pierwszy dzień to zwykle poznanie nowych technik. Pierwsze próby myślenia “wspak” – od testów do implementacji. Powoli jednak okazuje się, że takie podejście ma swoje zalety. Najpierw uczestnicy dostrzegają jak wygodnie jest posiadanie testów przy refaktoryzacji. Później doceniają coding by example - myślenie o funkcjonalnościach w kontekście przykładów użycia kodu. Każde następne ćwiczenie idzie szybciej od poprzedniego, z większym skupieniem na tym o co kod ma robić a nie jak.
Fajnie jest patrzeć jak taki sposób tworzenia kodu, początkowo idący dość ciężko, pod koniec szkolenia nie sprawia już uczestnikom takich problemów, daje za to dużo satysfakcji. Patrzeć jak dużo można nauczyć się w tak krótkim czasie i o jak wiele można poprawić swój warsztat w ciągu tych paru dni. Dla mnie to przyjemne doświadczenie kontaktu z ludźmi, którzy chcą się uczyć i okazja do poprawiania umiejętności trenerskich. A na sam koniec to nieskromne uczucie zadowolenia gdy przeglądam wyniki ankiet od uczestników

Pierwsze AgileCE jest już historią. Kto nie był, niech żałuje. Poziom merytoryczny tej konferencji był naprawdę wysoki. Ale po kolei.

Co się udało:

• Świetne miejsce, idealnie dopasowane do liczby osób
• Paul Klipp, organizator, reagował natychmiastowo i efektywnie na wszystkie niespodzianki
• Były naprawdę ciekawe rozmowy kuluarowo-openspace’owe
• Byli świetni prelegenci
• Nie było tłumu
• Kawa, ciasteczka i owoce dostępne cały czas
• Spotkałem dużo interesujących ludzi, spędziłem masę czasu na rozmowach
• Inicjatywa Agile Warsaw
• Masa inspiracji i myśli
• Świetne piwo w nocy

Co można poprawić w przyszłym roku:

• inna restauracja na obiad dla prelegentów – czekanie 2.5 godziny na obiad i 1.5 na piwo to troszeczkę za dużo, ale może to jakaś Krakowska tradycja
• openspace powinien być  dodatkowo a nie w trakcie wykładów – ciężko zrezygnować z fajnego wykładu na rzecz fajnej rozmowy
• może jeszcze parę osób ze stolicy by się wybrało? 
• poza proponowaniem hotelu można było znaleźć jakiś hostel w okolicy – nie każdy chce wydać na poleżenie w łóżku przez parę godzin więcej niż za dwudniową konferencję… można by wtedy wracać “w kupie” z nocnego piwa

A teraz na czym byłem:

• Keynote w wykonaniu Rachel Davies
  Rachel mówiła o ważności retrospektyw w życiu zespołu – ich wpływie na jakość produktów, motywację zespołu. Ważna rzecz dla nas: akcje z retrospektywy powinny mieć właściciela i ew. czas wykonania. Dzięki temu zespół o nich nie zapomni. Rachel mówiła też o wliczaniu akcji z retrospektyw do backlogu, by były widoczne i liczone do prędkości zespołu. Mówiła też o ich wycenianiu, ale to mnie nie przekonało – wiele z naszych akcji nie sposób wyrazić w żadnej mierze złożoności.
• ScrumFluenca pana Jensa Korte. Jens przedstawił główne myśli i źródła, które wpłynęły na powstanie Scrum’a. Zrobił OGROMNĄ mapę zależności, która jest faktycznie bardzo ciekawa. Niestety Jens nie dał rady językowo i ciężko go było słuchać. No i może nie do końca dla mnie była ta prezentacja, bo trochę się znudziłem.
• Monika Konieczny mówiła o ważności komunikacji w zespołach programistycznych. Brałem udział w symulacji pieczenia tortu z niejasnymi wymaganiami co faktycznie było fajne i w amerykańskim stylu prowadzenia prezentacji. Monika mówiła o altergames – grach symulacyjnych, które mogą pomóc zespołowi w zrozumieniu problemu. Ciekawe i przyjemne w słuchaniu. Szkoda, że Monika nie odniosła się do innych ruchów związanych z grami w światku agile’owym (np. agile fairytales).
• Potem gadałem z Pawłem Brodzińskim w temacie agile: mindset or just a toolbox. Chyba nikt nikogo nie przekonał, ale przy okazji poruszyliśmy chyba z 20 innych tematów – było naprawdę ciekawie.
• Ranek następnego dnia zajęła Zuzana Sochova z tematem kultury agile’owej w organizacjach, które tak tworzą oprogramowanie. 
• Potem głównie rozmawiałem na korytarzu i w openspace’sie o tworzeniu jakiejś inicjatywy zwinnej w Warszawie, Agile Coach Camp na który się wybieram na przełomie kwietnia i maja i parę innych tematów.
• Ostatnim wykładem był The Sword and Other Tales w wykonaniu dwóch panów z Anglii, w czasie którego mówili o praktykach w radzeniu sobie z różnymi problemami u nich w zespole. Cała prezentacja była w stylu low-tech (slajdami były zdjęcia z obrazków na whiteboardzie). Panowie cały czas grali (w sensie teatralnym) i prezentacja była naprawdę wciągająca.

Całość oceniam zdecydowanie wysoko. Zarówno merytorycznie jak i organizacyjnie. Gratulacje dla organizatorów! Już czekam na przyszły rok.

Pod koniec tego tygodnia odbędzie się w Krakowie konferencja Agile Central Europe (w skrócie AgileCE). Będę miał przyjemność opowiedzieć tam przy okazji wykładu Being an agile nearshore team o tym jak budowaliśmy nasz zespół, wprowadzaliśmy zwinne praktyki, o zdarzeniach jakie mieliśmy w relacjach z klientem i jak sobie z nimi radziliśmy. Wszystkich zainteresowanych serdecznie zapraszam!

Ponadto rozpoczęliśmy właśnie ostatni tydzień przed zamknięciem rejestracji na szkolenie TDD. Wszystkich chętnych poznania technik związanych z tworzeniem oprogramowania przy pomocy testów zapraszamy. Gwarantujemy ogrom wiedzy i masę ćwiczeń!

Na te wiosenne święta życzymy Wam wszystkim chwili rozkojarzenia i odpoczynku.

       ,`.
       ,’` |        _.-.
      ,`   |      ,’,’ /
      :    |    ,’,’  ;
         :   / /   /
           `.’ (  ,’
       ,”     _  `.
     ,’      (o_)  `
  . (,.)   _.–     :
-..`/(  .-’_..-    `|
 .-’,`. `-._       ;
     `._           /__
     ,’:)-.._   _.(:::`.
     |’         / /`:::|
   ,’ :       : :   `:|
  /   : |       | |    
 :    | |       : :..—.:
 |    | ;       ,`._`-.|_ `.
 |    |’      ,’._  `. `. |_
 |    :      /`-. `.  `. `.  :
 :        : __java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
 `. `.  `. ;at java.util.ArrayList.BunnyCheck
         |.  / at javax.swing.AbstractBunny.fireActionPerformed
  |     `.at javax.swing.plaf.basic.BunnyHandler.: `. __     /
  ’ ` at java.awt.Component.processBunnyEvent .:::::  `. /   ,’
    .::::::::::-..’_..-’




Uuuups! Przepraszamy za królika. U nas działał. Widać trzeba go było jednak zrobić za pomocą TDD…