Tematem przewodnim sobotniej konferencji Warsjawa 2009 były metodyki lekkie i tylko takie prezentacje zostały zakwalifikowane. Do grupy szczęśliwców, którzy mogli przedstawić swój punkt widzenia na sprawy Agile/Scrum byli (w kolejności występowania): Łukasz Lenart, Paweł Lipiński, Krzysztof Jelski, Tomasz "szimano" Szymański i Tomasz Łasica.Pojawiłem się w budynku Elki PW w trakcie trwania przerwy na pizzę - około 13tej. Pierwsze wrażenia bardzo pozytywne - tłok na piętrze, co mogło być spowodowane liczbą uczestników lub niewielkich rozmiarów korytarzem. Niestety nie policzyłem uczestników, ale zaryzykowałbym 100kę. Było wystarczająco dużo jak na sobotę i niecałkiem techniczną konferencję. Widać było zainteresowanie Scrumem. Tematy były praktyczne i panowie Tomki nie pozostawili złudzeń, że znają się na rzeczy.
Najpierw, co mi się podobało. Podobało mi się móc wysłuchać o Scrumie w przysłowiowych "żołnierskich słowach". Krótko i treściwie. Każdy z prelegentów miał 30 minut na przedstawienie tematu i 15 minut dyskusji. Akurat. Tomek Ł. skorzystał nawet z pomocy kawek, które zapalały się po przekroczeniu kwadransu. Ciekawy pomysł. Nie dłużyło się wcale, a nawet, mimo, że byłem jedynie na 2 wystąpieniach (szimano i Tomka Łasicy), miałem wrażenie, że prezentacje pojawiają się i znikają, i nie wiedząc kiedy, było po wszystkim. Było ciekawie, czasowo dopasowane, więc dla mnie idealnie. Organizacyjnie super! Łukasz Lenart, który wraz z grupą wolontariuszy (wybaczcie nie wspomnę z imienia i nazwiska, bo pamiętam tylko Agnieszkę i to tylko dlatego, że później jeszcze wystąpiła na wtorkowym 54. spotkaniu Warszawa JUG i tak się jakoś utrwaliło) zorganizował konferencję zrobił to dokładnie, jak było trzeba. Napoje były, pizza też i mini-aula również. Oświetlenie, nagłośnienie i ekran dopasowane. Logistyka na medal. Sponsorzy również dopisali i na scenie pojawili się Pragmatists oraz SoftwareMill.
Wracając do naszych prelegentów - Tomków, o tym co dobre już było. Byli merytoryczni, ale nie obyło się bez jednego drobnego minusu. U obu nie podobało mi się "mówienie do monitora". Kontakt wzrokowy z uczestnikami był, ale niewielki w porównaniu z tym z komputerem. Dało się odczuć, że bardziej zależało im na przedstawieniu tematu bez wpadek, tak jak przygotowali sobie na komputerach niż na kontakcie z publicznością. Niewielka to strata, gdy merytorycznie wypadają doskonale, ale znacznie łatwiej zadaje się pytania prelegentowi, który wręcz prowokuje do nich patrząc na uczestników. I to byłoby tyle z wpadek. Jedna, niewielka wielkiej różnicy nie robi, więc odbiór obu oceniam na wysoki (do perfekcji brakuje właśnie tego wzrokowego kontaktu).
Co mnie jednak nieprzyjemnie wzbudziło w kontekście przedstawiania Scruma, to fakt, że podkreśla się go jako metodykę niesformalizowaną, a aż roi się w nim od formalizmów - podział ról, etapów w projekcie i ta przedziwna mania utrzymywania nazewnictwa angielskojęzycznego. Nie nalegam na zaprzestanie korzystania z niego, gdzie brakuje polskiego odpowiednika, ale wprowadzanie nowego nowym (językiem) może zakończyć się znacznie mniejszym powodzeniem niż mówienie w języku zrozumiałym dla słuchaczy-nowicjuszy. Weźmy na przykład taki sprint - raczej kojarzy się z uciążliwym biegiem po wygraną i nie oddaje lekkości tego terminu (zakładając, że w Scrumie jako metodyce lekkiej wszystko jest lekkie). Dlaczego nie korzystać jednocześnie ze sprintu i okresu produkcji, aby w ten sposób przybliżyć znaczenie tego pierwszego? Jeszcze z samym sprintem można przywyknąć, bo kilkakrotnie padło na konferencji, że nazwa sprint odpowiada trudowi, jaki wkłada się w każdy ze sprintów, aby zrealizować zakładany plan, ustalony wspólnie z właścicielem produktu czy też Scrum Masterem (nie pamiętam dokładnie z kim to się ustala, chyba z oboma). Padło nawet, że po 4tym czy jeszcze kolejnym można odczuć trudy sprintów. Nie rozumiem tego do końca, bo w końcu pracujemy znacznie więcej niż 6-7h zakładane jako dzień w Scrumie, więc dobrze spędzone godziny powinny być kojące niż wykańczające? Bardziej nieprzemawiającymi do mnie terminami były (świadomie używam ich formy mówionej) toking stik, tajmboksowanie, assajnowanie, łajtbord i beklog. Nie twierdzę, że nie nasuwają skojarzeń, ale tylko nieznacznie. Czy nie lepiej byłoby używać słownictwa bardziej bliskiego słuchaczom, aby nowy temat przedstawiać "starymi" terminami/słowami, które niosą tą samą informację, ale przemawiają do nas dosadniej, np. pałeczka/różdżka rozmówcy, harmonogramowanie, przypisywanie, tablica, lista zadań, itp. Akurat idealnie odpowiadają terminom angielskim, ale chodzi mi raczej o przybliżenie słuchacza korzystając z bardziej zrozumiałego dla niego słownictwa. Mam wrażenie, że przez to całe słownictwo wokół Scruma tworzy się pewna aura tajemniczości, która niepotrzebnie wpływa niekorzystnie na zrozumienie, o co w tym wszystkim chodzi. Ma być lekko, a przez to słownictwo nie jest. Nasunęła mi się nawet myśl, że Scrumowcy to "językowi inwalidzi". Jakby się wszyscy uparli na to angielskie słownictwo?!
Co mnie "ujęło za serce" w Scrumie to położenie nacisku na odpowiedzialność jednostki w zespole. W razie niesubordynacji nie wskazuje się winnych, ale odbiera im się możliwość popełnienia ich kolejnym razem. Zamiast winienia, że Iksiński zatwierdza zmiany, które skutkują złamaniem budowania aplikacji (nie wykonaniem kompilacji czy brakiem spełnienia testów jednostkowych), do systemu kontroli wersji wprowadza się "zaporę" w postaci automatycznie wykonywanych testów, kompilacji, itp. i tylko ich spełnienie potwierdza zmianę. Zamiast stać i krytykować wzbogaca się środowisko o narzędzia, które wiele robią za nas. Tak jak powinno być. Wcześniej czy później, Iksiński zrozumie swój błąd i się nauczy, że zmiany należy zatwierdzać do repozytorium jedynie po poprawnym zbudowaniu/przetestowaniu aplikacji lokalnie. Jakość wzrasta samoistnie.
W Scrumie występują karty, którymi przypisujemy wagę każdego z omawianych funkcjonalności, które wejdą do sprintu. Gra w karty świadczy, że Scrum kładzie nacisk na luźną atmosferę pracy, ale jednocześnie wprowadza tyle nowej nomenklatury i nakłada ramy odpowiedzialności, że trudno w to uwierzyć, że wciąż nazywa się go lekkim. Może gdyby nie naciskano tak często na ową lekkość Scruma, miałbym do tego mniej uszczypliwy stosunek.
Miałem jeszcze okazję przejrzeć nagranie z Łukaszem Lenartem w roli organizatora podczas wystąpienia otwierającego konferencję i jako prelegenta w kolejnym wystąpieniu. Bardzo ciekawie przeprowadzona prezentacja z dużą dawką sportu. Zrozumiałem różnicę między uczestniczeniem w spotkaniu na żywo. Tego się nie da odtworzyć podczas odsłuchiwania. Brawo Łukasz za pomysł!
24. listopada, w ramach wtorkowych spotkań Warszawa JUG, będzie miał miejsce Eclipse DemoCamp 2009. Spróbujemy odtworzyć atmosferę Warsjawy, bo jak dla mnie wyznaczyła ciekawą formułę spotkań - 30/15. Zresztą taki postulat pojawił się po Warsjawa Eclipse DemoCamp 2009, więc dlaczego nie spróbować ponownie?! Chętni do pomocy przy organizacji DemoCampa proszeni o kontakt na grupie Warszawa JUG. Każda pomoc mile widziana. Finansowanie mamy zapewnione przez Eclipse Foundation, ale wartoby również skorzystać z możliwości promocji polskich firm informatycznych. Znacie takowe, które byłyby zainteresowane wystawieniem swojego logo na stronie Eclipse.org, konferencji i w trakcie, piszcie. W końcu tyle, ile sami zrobimy, tyle będziemy mieli. Tym razem zadbam, aby w relacjach pojawiły się nazwiska zaangażowanych :)
