27 lutego 2015

Lektura "Learning Agile" z O'Reilly dobrem projektowym

0 komentarzy
Polecono mi przeczytanie książki Learning Agile. Stronię od takich pozycji ze względu na ich zerowe przełożenie programistyczne, ale najwyraźniej przyszła pora zmienić podejście, bo za często domaga się ode mnie umiejętności zbudowania i poprowadzenia zespołów programistycznych.

W lekturze tej książki nie byłoby nic nadzwyczajnego, gdyby nie zbieżność wydarzeń, która sprowadziła czytanie w wolnej chwili do czytania w czasie służbowym jako pełnoprawne zadanie projektowe (!)

Zaintrygowany? Ja byłbym, a nawet jestem!

Dzisiejszy dzień rozpocząłem od pożegnania zespołu, który przez ostatnie tygodnie borykał się z dostarczaniem oprogramowania na czas. Mój czas dobiegł końca - zespół działa i jest gotowy do samodzielnego podejmowania decyzji z pomocą osób odpowiedzialnych za docelową postać wytwarzanego produktu. Można by o tym pisać całe tomy - kto, kiedy, dlaczego, po co, itp. - ale istota sprawy to aż kłujący w oczy brak doświadczenia mojego i zespołu w planowaniu i późniejszym realizowaniu założonego harmonogramu. W zasadzie nałożyły się na to młodość zespołu oraz brak myślenia startup'owego (w którym w moim wyobrażeniu zakłada się czas finansowania, a jego niedotrzymanie skutkuje natychmiastowym rozwiązaniem zespołu -- takie myślenie bardzo pomaga mi w podjęciu decyzji co jest aktualnie ważne i czy zespół ma dane zadanie robić).

Leżeliśmy na całego.

I wtem kolega z zespołu postanowił "wyposażyć" się we wspomnianą książkę Learning Agile. Super, ekstra i fajnie byłoby poczytać, ale jak tu poradzić sobie z "delivery" po nocach i jednocześnie czytaniem książki?! I tak sobie książka poleżała tydzień na moim biurku, a my jak w ukropie lataliśmy łatać dziury. Pewnie popełnialiśmy wszystkie możliwe błędy prowadzenia projektu informatycznego wytwarzania oprogramowania biorąc dowolną metodykę jego prowadzenia.

Już sama obecność książki dodawała nam jednak otuchy, że jak już wszystko się skończy, to po tym całym zamieszaniu przyjdzie w końcu czas, kiedy choćby nieznacznie, ale odetchniemy i będzie można upajać się zawartością książki ("nadzieja umiera ostatnia", co?)

Jakoś tak się złożyło, że z tym zespołem upajać się zawartością tej książki już nie będę, ale książka została ze mną.

Tego samego dnia pojawiłem się w innym zespole programistycznym, w którym metodyki lekkie agile brano poważniej pod uwagę i wytwarzanie "softu" jest u większości w DNA. Chce się go przez wszystkich, ale brakuje lidera agilisty, który przeprowadziłby zespół przez zaułki wdrażania tego narzędzia zgodnie ze sztuką. Przyjdzie pewnie borykać się nam z antywzorcami wdrażania agile nie raz i nie dwa. Bywa (chociaż wierzę, że ten wpis wzbudzi litość u kilku agilistów, którzy odezwą się z propozycją komercyjnej pomocy we wdrożeniu procesu - będę zobowiązany!)

Książka w mojej dłoni powędrowała do wszystkich osób w zespole, które wprawdzie wyraziły zainteresowanie agile i książką, ale niekoniecznie samym sposobem pozyskania odpowiedniej wiedzy w temacie czyli czytaniem. To kolejny zespół, który jest przeładowany zadaniami i ni jak nie można znaleźć miejsca na czytanie książki. Bywa.

Jako, że doświadczenia ostatnich 2 lat pokazują, że czeka mnie "kariera" osoby zestawiającej zespoły informatyczne celem uruchomienia linii produkcyjnej do wytwarzania oprogramowania, to ta właśnie książka okazuje się być lekturą obowiązkową dla mnie. Trafiłem z nią w końcu do pokoju podatnego na moje sugestie i w którym zgodziliśmy się na...podsumowania rozdziałów!

Okazuje się, że jakkolwiek samo czytanie książek nie jest pożądane przez kogokolwiek z zespołu programistycznego, to już wspomniane podsumowania w postaci listy najważniejszych rzeczy z kilkoma słowami wyjaśnienia, już tak. Można by potraktować to jako porażkę "systemu" edukacji informatycznej, ale dla mnie to była szansa zrobienia czegoś zamiast lamentowania i zrobienia niczego.

I tu zaczęło się moje zdumienie, bo owe podsumowywania zaproponowano umiejscowić na Wiki zespołu! Pomysł nabrał rumieńców projektowych i stał się dobrem zespołu. Odpalono zadanie w JIRA na potrzeby tego przedsięwzięcia i czytanie książki stało się sprawą ważną, bo zgodną z dyrektywą odgórną, która mocno podkreślała wdrożenie agile, a w zespole poszanowanie i stosowanie jego zasad.

W ten sposób czytanie książki Learning Agile stało się zadaniem projektowym.

Zdumiony? Ja wciąż jestem. I nie mogę uwierzyć, jak niewiele trzeba, aby z często niechcianego obowiązku nauki po pracy, zrobić pełnoprawne zadanie projektowe ku szczęśliwości wszystkich zaangażowanych. Ostatecznie nie powinno być stratnych takiej decyzji - ja "zaliczę" książkę, wiedzę przekażę zespołowi w postaci podsumowań w stylu notatek na blogu, aby w ten sposób zainicjować proces przyswajania wiedzy metodyk lekkich prowadzenia projektów w zespole programistycznym. Ja jestem in plus, zespół również, a szefostwo dostaje produkt wysokiej jakości i terminowo (przynajmniej teoretycznie). Cudo!

Docelowo pewnie czeka nas zaproszenie do zespołu praktyka, który przedstawi nam, co i jak się stosuje w praktyce, ale przyczółek zmian już wyczuwam. Idzie ku dobremu!

Matt, zlituj się, pomógłbyś nam trochę i pojawił na kilku spotkaniach u nas w biurze, co? Wskazałbyś innych ekspertów w temacie, a my oddamy się do Twojej/ich dyspozycji. Może Tomek i Mateusz mogliby również wesprzeć nasze starania? 

Ogłoszenie parafialne: kolejne zespoły, które doświadczą mojej obecności w roli członka zespołu, mogą liczyć na permanentną indoktrynację agile'ową, którą na początku zdobędę lekturą książki "Learning Agile" oraz z życia doświadczając praktycznie mechaniki prowadzenia zespołów programistycznych. Na chwilę obecną mam na swoim koncie 3 przypadki zmontowania zespołu i zestawienia linii produkcyjnej w roli lidera, co daje mi jedynie mgliste pojęcie o problemie. Nie poprzestaję jednak.

07 lutego 2015

Ochy i echy o GeeCON TDD -- polecam!

0 komentarzy
Wciąż nie mogę uwierzyć, jak bardzo pomysł 30-minutowego wystąpienia może być uczący! Organizatorzy GeeCON TDD mają głowę na karku -- 30 minut na prezentację to dokładnie tyle, ile należy poświęcić na przekazanie właściwej porcji wiedzy jako prelegent i utrzymać cierpliwość słuchaczy. Możnaby powiedzieć, że w ten oto sposób efektywnie “oderano” mi prawo do dywagacji i dowcipkowania na tematy różne podczas występiania. Gratuluję doskonałego pomysłu!

Dziękuję organizatorom również za zaproszenie do wystąpienia w roli prelegenta z tematem "Translating Requirements into Executable Software Specification with specs2".

Dziękuję organizatorom Łukaszowi, Adrianowi, Idzie, Adamowi za wspaniałą atmosferę podczas konferencji!


Kolejny raz skorzystałem z reveal.js, co polecam początkującym w branży wystąpień publicznych lub efektywnego przekazywania wiedzy - zamiast artykułu czy wpisu na blogu można użyć medium w postaci slajdów. Jeśli zastanawiasz się, jak zacząć w temacie - chociażby miało się skończyć wyłącznie na przygotowaniu slajdów - pisz. Chętnie pomogę.

GeeCON stał się marką i każda inicjatywa spod tego parasola to wydarzenie wielkiego formatu. Zaczęło się od konferencji stricte javowej, aby później stać się konferencją o tematach z branży programowania i zarządzania projektami, aby ostatni pomysł skoncentrować wokół testowania (bez przywiązywania go do konkretnego języka czy biblioteki). Tym razem owe 30 minut i tematyka sięgająca poza JVM pozwoliła mi na doświadczenie nowych doznań - ludzie jakby nowi i raczej w większości dużo młodsi (i raczej nie doświadczeniem).

Miło było spotkać się ze znajomymi z branży i mieć sposobność poznania ludzi spoza mojego środowiska programistycznego. Cieszę się, że GeeCON sięga po nowe obszary, bo dzięki temu dochodzi do spotkania osób wcześniej niemających wiele okazji do choćby minimalnej interakcji i wymiany doświadczeń. Kolejny raz GeeCON staje się platformą inspiracji i wymiany doświadczeń dla polskiej sceny informatycznej. Gratulacje wytrwałości!

W trakcie konferencji spotkałem się z osobami, które zawsze mają wiele wartościowego do powiedzenie i nawet, jeśli wciąż jeszcze nie zrozumieli, że język programowania Scala jest…ekhm…najlepszy, to warto ich wysłuchać i porozmawiać. Dobrze było spotkać Łukasza i Adama (z poznańskiej części organizacyjnej GeeCON), AdrianaAdę (z części krakowskiej), Diablo (również znaną jako Dominika i też z Krk), Szymona i Piotrka (z załogi toruńskiej), Jacka (Pzn), Kubę K. (Waw), Jakuba M. (Pzn), Kubę M. (Gdn). Nie mógłbym pominąć przyjemności uściśnięcia dłoni Steve'owi Freemanowi oraz Nata Pryce.

Ślę również obiecane pozdrowienia dla zespołu IT Kontrakt! Życzę powodzenia GFT (dawniej Rule Financial) w ekspansji na południe (z wyrazami ubolewania, że do uruchomienia oddziału w Gdańsku jednak nie doszło).

Ufam, że do zawiązania poznańskiej grupy miłośników języka Scala pod przewodnictwem Radka (Gallera) z pomocą Konrada z Allegro dojdzie i publicznie deklaruję swoją pomoc, aby taki pomysł doszedł do skutku. Radek, jak się powiedziało A, to trzeba powiedzieć i B! Powołanie grupy to pierwszy etap i później przy ustalonych regularnych spotkaniach już będzie z górki. Pomożemy!

Dziękuję Kubie Kubryńskiemu za krótkie acz treściwe wprowadzenie do Spring Boot -- chwila z mądrym i czułem jak staję się mądrzejszy. Nie przyjdzie mi użyć tego narzędzia w najbliższej przyszłości, ale wiedzieć, do czego służy, nigdy nie zawadzi. Sugeruję rozważyć serię spotkań, które przybliżyłyby Spring Boota szerszej publiczności. Rozważ to koniecznie! Może seria nagrań na YouTube lub vimeo?

Podczas konferencji dowiedziałem się o istnieniu firmy Comarch w Poznaniu. Otrzymałem wstępne zaproszenie do współpracy w promocji Scali, więc jeszcze o nich usłyszymy na łamach tego bloga. I nie mógłbym zapomnieć o Anecie z Comarch, która niedługo również wejdzie w temat programowania w języku Scala, bo…licencja IntelliJ IDEA czeka. I ja na pull requesty na GitHubie również.

Wygląda na to, że firma CommerceOne z Łukaszem i Jackiem to całkiem ciekawa firma w Poznaniu. Historia powołania firmy na pewno. Technologicznie jeszcze mają dużo do nadrobienia, ale wierzę, że z takim składem osobowym, to wyłącznie kwestia czasu. Trochę szkoda Espeo,  ale skoro stawiają na PHP, to…ich dni są policzone. Ble.

Dzięki PSI za podarunki i test ze znajomości Javy! Nie było lekko, co należy wyłącznie zrzucić na barki dawno nie używanej przeze mnie Javy. Gadżety czekają na rozdanie podczas kolejnego spotkania scalowego w Warszawie. Więcej na stronie @WarszawScaLa.

Szymon przypomniał mi o pomyśle nagrywania wstępniaków scalowych z kimś. Trzeba to wdrożyć w lutym! Dzięki Szymon za przypominajkę. Hmmm, momento, czyżby liczył, że to właśnie jego zaproszę?! Ciekawa oferta! Oczekuj kontaktu w sprawie.

Podsumowując, konferencję GeeCON TDD wstawiam do kalendarza jako imprezę wartą udziału. Polecam ją jako dobry wstępniak do różnorodnych technologii i technik informatycznych. Swoje wystąpienie uważam za przyzwoite, a pomysł 30 minut na występ określam za strzał w dziesiątkę - wystarczający na przekazanie dostatecznej informacji, aby zaintrygować tematem. Bardzo, bardzo dobry pomysł warty podtrzymania (i skopiowania przy innych imprezach)! 30 minut to dokładnie tyle, ile się należy o temacie i bez dodatków w stylu slajd o mnie czy dowcipów (co podobno Kubie ze slajdem o mnie się nie bardzo udało).

Dziękuję organizatorom i uczestnikom za bardzo miłą atmosferę i zapraszam na kolejną edycję. Sztandarowy produkt — konferencja GeeCON 2015 — już 13-15 maja 2015 w Krakowie. Do zobaczenia!