blog.testowka.pl

Inne

Gemba Walk w IT – robimy to źle?

opublikowany przez 25, Sty, 2016, w kategoriach Inne

Ostatnio wdałem się przypadkiem w bardzo ciekawą dyskusję z Michaelem Feathersem na Twitterze. Micheal sprowokował mnie do dyskusji stwierdzeniem:

Gemba is the place where value is created. In manufacturing the genba is the factory floor. In a software org, it’s the code.

Gemba Walk to sposób na odkrywanie problemów. Zgodnie z definicją chodzi o to, by osoby decyzyjne przebywały od czasu do czasu w miejscu gdzie tworzona jest wartość – w miejscu pracy, wśród ludzi (lub maszyn) wytarzających tą wartość. W ten sposób osoby decyzyjne poznają naturę problemów z jakimi boryka się ich organizacja i są w stanie je skutecznie rozwiazywać  W fabryce miejscem takim jest hala produkcyjna. Pozostaje pytanie co jest takim miejscem w organizacji bazującej na wytwarzanym oprogramowaniu?

W całym tym naszym Agile ciągle powtarzamy, że chodzi o to, żeby zbliżyć IT do biznesu. Wynika to między innymi z potrzeby przezwyciężenia  Prawa Conwey’a, które mówi o tym, że organizacje projektujące systemy, budują rozwiązania, które są odzwierciedleniem struktur komunikacyjnych tych organizacji. Jak zatem to robimy i dlaczego źle? Wszystkie te nasze Scrumy i inne metody zakładają, że trzeba zbliżyć developerów do biznesu. Trzeba rozmawiać z biznesem na temat produktów i domeny biznesowej, tak aby developerzy lepiej rozumieli biznes.

Jako Agile Coach czy Scrum Master moja praca sprowadzała się zazwyczaj do sprawienia by developerzy zobaczyli trochę szerszą perspektywę niż ich kawałek kodu i jednocześnie by biznes zrozumiał o co chodzi w tym developmencie. I zazwyczaj to wystarczało by znacząco poprawić efektywność stosowanych procesów.

A co jeśli to jest niewystarczające? A co jeśli można by osiągnąć znacznie więcej? A co gdybyśmy spróbowali zrobić to wszystko w drugą stronę, a najlepiej w obie i nie tylko ciągać developerów do biznesu, ale też biznesowi pokazać kod? W końcu w Gemba Walk chodzi o to, by to osoby decyzyjne poruszały się po miejscu, gdzie tworzona jest wartość. O ile developerzy owszem mają wpływ na wiele decyzji i sporo ich mniej lub bardziej świadomie podejmują to jednak przeważnie więcej decyzji podejmowanych jest w biznesie.

Co by się stało gdybyśmy pokazali biznesowym osobom decyzyjnym nasz kod, albo przynajmniej architekturę aplikacji? Co by było gdybyśmy co tydzień poświęcali godzinę na przeprowadzenie naszego CEO przez kawałek kluczowego dla naszej aplikacji kodu?  Ile problemów mogli byśmy w ten sposób wykryć?

No dobra, może nie od razu CEO ale może ktoś inny z biznesu powinien od czasu do czasu przejrzeć nasz kod… Jak często zdarza się wam, że nazewnictwo klas czy metod użyte w kodzie nijak się ma do języka stosowanego w biznesie? Jak często coś takiego prowadziło do nieporozumień? Jak często mówicie, że czegoś nie da się zrobić w waszej aplikacji, gdyż model aplikacji zupełnie nie odpowiada modelowi biznesowemu waszej organizacji?

 

 

 

 

Dodaj komentarz więcej...

Szukamy QA!

opublikowany przez 21, Maj, 2015, w kategoriach Inne, Praca, Testowanie

Przez długi czas w Pragmatic Coders pracowaliśmy bez QA. Później mieliśmy testera po stronie klienta. W obydwu przypadka radziliśmy sobie całkiem dobrze. Teraz jednak stwierdziliśmy, że chcielibyśmy radzić sobie jeszcze lepiej.

Datego…

Poszukujemy osoby na stanowisko Quality Assurance Engineer, która wniesie dodatkową wartość do naszego zespołu.

Jeśli:

  • jesteś przyzwyczajony do pracy od 8 do 16 i nie wyobrażasz sobie tego jak można inaczej (nie tolerujesz wychodzenia z pracy kiedy się chce i pracy zdalnej jeśli ma się na to ochotę),
  • masz certyfikat ISTQB Advanced Level i posiadasz szerokie doświadczenie w stosowaniu omawianych tam praktyk,
  • jesteś ekspertem w pracy w ciągłym konflikcie z developerami i potrafisz ten konflikt efektywnie wykorzystywać do tego, by zapewnić jak najwyższą jakość,
  • Agile dla Ciebie jest fajny, ale zdajesz sobie sprawę z tego, że w praktyce lepiej jest jednak napisać plan testów, przypadki testowe i scenariusze,
  • masz bogate doświadczenia jako Test Manager i z łatwością zbudujesz dla nas dział testów w skład którego wejdą Twoi nowi podwładni,
  • masz doświadczenie w automatyzacji testów i wiesz, że automatyzacja ma sens tylko jeśli funkcjonalności są już stabilne i nie będą się zmieniać,
  • potrafisz sukcesywnie odseparować swoje życie od pracy (bo przecież praca to smutny obowiązek, ale jednak konieczny by móc się poza nią rozwijać),
  • jesteś prawdziwym ekspertem w wykonywaniu scenariuszy testowych, a Twoje raporty z testów i zgłoszenia błędów są zawsze bardzo starannie opisane i nie wyobrażasz sobie by można to było robić inaczej,
  • wiesz jak efektywnie wtestować jakość w oprogramowanie – znasz wiele praktyk, które na to pozwalają i wiesz jak je wdrożyć w życie,
  • potrafisz efektywne komunikować się z programistami używając wyłacznie Jiry (i/lub innego bugtrackera),

…jeśli spełniasz powyższe wymagania… to… raczej nie masz czego u nas szukać… No chyba, że szukasz terapii szokowej…

W innych przypadkach daj nam znać – chętnie porozmawiamy o Twoim doświadczeniu! Nie liczy się dla nas piękne CV i dekady doświadczeń w korpo – prawdziwa wiedza i doświadczenie oraz chęć i umiejętność szybkiego uczenia się – to jest to, co jest dla nas najważniejsze!

Więcej informacji i faktyczne wymagania znajdziecie tutaj.

Wiemy, że poprzeczka jest dosyć wysoko, ale nasz zespół w tej chwili potrzebuje osób, które faktycznie nie będą zostawały z tyłu w tym szybko zmieniającym sie i rozwijającym środowisku. W każdym razie postaramy się w miarę możliwości dać szansę każdemu kto spełnia przynajmniej kilka z wymienionych wymagań.

Widełki (bo przecież trzeba): 3000-8000 PLN (netto)
Zasady są proste – wynagrodzenie zależy od ilości spełnianych wymagań.

Miejsce pracy: Kraków
Umowa o Dzieło/Zlecenie lub B2B.

Jeśli macie jakieś pytania to dajcie znać.

 

 

1 komentarz więcej...

Jeśli nie wiadomo o co chodzi…

opublikowany przez 10, Lut, 2015, w kategoriach Praca, Programowanie, Testowanie, Zarządzanie

…to chodzi o pieniądze…

Konkretnie o stawki w widełkach płacowych w ogłoszeniach o pracę. Już któryś raz spotkałem się z opinią, że ogłoszenia o pracę dla developerów/testerów/etc. powinny zawierać widełki płacowe. Oczywiście się z tym zgadzam. Ale ostatnio na grupie poświęconej testowaniu oprogramowania na Facebooku pojawił się też pomysł by widełki te nie były zbyt szerokie. Z perspektywy (dosyć świeżego) pracodawcy to mnie to troszeczkę ukłuło.

Co jeśli ktoś płaci ludziom faktycznie pomiędzy 2k a 10k PLN i to faktycznie zależy od umiejętności danej osoby? W Pragmatic Coders szukamy zarówno doświadczonych wymiataczy jak i osób ambitnych lecz jeszcze z niewielkim doświadczeniem, które maja duży potencjał. Ponadto zdarza się, że sporo osób z najwyższymi oczekiwaniami finansowymi (pytamy o to zanim zaprosimy kogoś na rozmowę) wypada dużo słabiej na rozmowach niż osoby z oczekiwaniami z pierwszej połowy widełek.
 
Sami zatrudniamy ludzi i stawki są naprawdę różne (może nie aż tak rozjechane, ale jednak) i faktycznie jest to w dużej mierze zależne od ich umiejętności. A raczej od tego jak dobrze wypadną na rozmowie/podczas rozwiązywania zadań rekrutacyjnych.
Jeśli chciałbym wrzucić widełki typu 8-10k to musiał bym podziękować większości kandydatów, których zatrudniliśmy bo najzwyczajniej ich umiejętności nie były dla nas tyle warte. Nie wiem też ile osób doszło by do wniosku, że są po prostu „za słabe” na takie pieniądze i by do nas nie napisało. Niemniej jednak dzięki temu, że nasze widełki są szersze pracujemy teraz z ludźmi z dużym potencjałem, których pensje odpowiadają ich umiejętnościom.
 
To co proponuję wszystkim malkontentom, którzy narzekają na brak czy niedokładność widełek to aby podawali swoje oczekiwania finansowe w przesyłanych CV. Wystarczy zrobić tam dopisek, żeby pracodawcy nie zawracali nam głowy jeśli uważają, że na podstawie CV/profilu na linkedIn/20 minut rozmowy przez telefon nasze umiejętności nie są dla nich tyle warte, lub jeśli w ogóle nie są w stanie tyle zapłacić komuś na tym stanowisku. Z mojego doświadczenia – takie coś w zasadzie eliminowało temat pieniędzy podczas dalszych rozmów lub było to dogadywane z różnym skutkiem na samym początku komunikacji. I pisze to zarówno z perspektywy kandydata jak i pracodawcy. 
 
Oczywiście moja propozycja nie wyklucza potrzeby widełek w ogłoszeniach. To tylko pewna propozycja rozszerzenia netykiety dla wspólnego dobra pracodawców i kandydatów. 
 
Z trzeciej strony jeśli dla kogoś jedynym powodem do tego by z nami współpracować miała by być kasa, to nie jestem przekonany czy wszyscy będziemy docelowo z takiego układu zadowoleni.
Osobiście gdy, kiedyś szukałem pracy to uważałem, że podanie moich oczekiwań płacowych na początku kontaktów (w CV, pierwszym mailu, przez telefon) to po prostu pragmatyczna oszczędność czasu osoby rekrutujące ale także przede wszystkim MOJEGO… Także szczerze polecam taki sposób komunikacji – także z nami gdybyście programowaniem w Pythonie byli zainteresowani.

4 komentarze więcej...

Podsumowanie Quality Excites 2014

opublikowany przez 02, Cze, 2014, w kategoriach Coaching, Jakość, Konferencje, Testowanie

qe

W sobotę miała miejsce już trzecia edycja darmowej konferencji Quality Excites 2014 w Gliwicach, organizowanej przez firmę Future Processing. Uczestniczyłem w tym wydarzeniu jako prelegent po raz trzecie – dzięki temu miałem okazję od samego początku przyglądać się temu jak rozwija się samo wydarzenie jak i firma je organizująca.

Może zacznijmy od organizatorów – nie wiem za wiele o FP bo nigdy tam nie pracowałem, ale znam tych ludzi i wiem, że jakość ma dla nich znaczenie. Teraz odwiedzając ich biuro mogłem zobaczyć postępy jakie poczynili. Gdy dwa lata temu byłem tam po raz pierwszy to w miejscu obecnego kompleksu biurowego była dziura w ziemi. W tej chwili stoi tam nowoczesny kompleks biurowy z kantyną, siłownią, centrum spa, zjeżdżalniami(!) i wieloma innymi fajnymi rzeczami wspierającymi kreatywną pracę. Niewiele jest w naszym kraju firm zdających sobie sprawę z tego, że ich największym kapitałem są ludzie i ich wiedza, a do tego jeszcze inwestujących w ten kapitał nie ilościowo ale jakościowo.

O samej konferencji można by napisać wiele. Zacznę od tego, że jest to jedyna (znana mi) konferencja w tym kraju, na której testerzy i programiści mówią tym samym językiem. Jest to wydarzenie skierowane zarówno do testerów, programistów, managerów, analityków poświęcone jednemu – bardzo ważnemu tematowi: szerokiej jakości oprogramowania. W programie znalazły się prezentacje zarówno o testowaniu, automatyzacji testów, wymaganiach, metrykach jak i praktykach  i narzędziach developerski. A wisienką na torcie był wykład o tym Kim jest Agile Coach według Krysitana Kaczora zamykający konferencję.

Oprócz wykładów, równolegle odbywały się niesamowicie ciekawe warsztaty prowadzone przez praktyków z Future Processing. Najciekawsze były oczywiście rozmowy w kuluarach i podczas afeter party. Spotkałem wielu starych znajomych i poznałem jeszcze więcej nowych. Zaskakująco miło mi, gdy ktoś w rozmowie odnosi się do tematów, o których mówiłem na poprzednich konferencjach i innych wydarzeniach. To znaczy, że to co robię ma jakieś znaczenie i nie ginie w przestrzeni – zostaje w głowach przynajmniej jednostek, które z sukcesami stosują tą wiedzę w praktyce.

Future Processing z Quality Excites byli chyba pierwsi jeśli chodzi o niekomercyjne wydarzenia tego typu, organizowane na taką skalę. Na szczęście tego typu imprez oraz różnych mniej lub bardziej lokalnych grup entuzjastów jakości przybywa co przekłada się na realne postępy w dziedzinie jakości oprogramowania.

Na koniec jeszcze kilka słów na temat wspomnianego wykładu Krystiana Kaczora – już dawno nie widziałem wykładu na interesujący mnie temat, z którym bym się tak bardzo zgadzał. Sam jakiś czas temu miałem podobne przemyślenia – więcej tu i tu. Tym bardziej cieszę się, że Krystian dołączył do naszego zespołu trenerów w Code Sprinters.

18 komentarzy więcej...

Quality Excites – się kręci…

opublikowany przez 17, Mar, 2014, w kategoriach Jakość, Konferencje, Testowanie

qe

Jak co roku zachęcam Was do wzięcia udziału w Quality Excites. Miałem przyjemność uczestniczyć w Quality Excites od samego początku kiedy to w 2012 roku zostałem zaproszony jako jeden z kilku prelegentów. Od tamtego czasu wydarzenie rozrosło się i stało się jednym z najważniejszych miejsc na mapie i w kalendarzu naszego krajowego testowania i jakości oprogramowania. Co roku staram się jak mogę wspierać inicjatywę oraz dzielić się z uczestnikami swoim doświadczeniem.

W tym roku jakością będziemy się ekscytować 31 maja jak zawsze w Gliwicach.

Jeśli chcieli byście podzielić się jakimś ciekawym tematem to Call For Papers już wystartowało i potrwa do końca marca. Szczerze zachęcam do zgłaszania prezentacji, gdyż wiem, że wielu czytelników mojego bloga ma się czym pochwalić! (Poza tym ileż można ciągle oglądać te same twarze – w tym moją :P).

Swoją drogą jeśli sami nie czujecie się na siłach by coś opowiedzieć to może chcieli byście bym ja odpowiedział na jakieś Wasze pytania albo szerzej omówił któryś z tematów prezentowanych przeze mnie na blogu lub gdzieś indziej? Nie to żebym sam nie miał pomysłów, ale zawsze lepiej się opowiada mając świadomość, że gdzieś tam na widowni jest przynajmniej jedna osoba, którą dany temat interesuje :).

Zapraszam do podzielenia się propozycjami pod postem lub na facebooku.

4 komentarze więcej...

7 Grzechów Automatyzacji Testów

opublikowany przez 13, Lut, 2014, w kategoriach Inne

temptation

1. Wiara w cuda

Zbyt często automatyzacja jest postrzegana jako złote lekarstwo na problemy związane z niską jakością oprogramowania, która przejawia się poprzez dużą ilość defektów. Niektórym wydaje się, że jeśli przyspieszymy proces testowania poprzez jego zautomatyzowanie to od razu auto-magicznie będziemy popełniać mniej błędów. Warto jednak pamiętać o tym, że o ile automatyzacja szybciej pokaże nam widoczne objawy problemów z jakością naszego oprogramowania to tych problemów nie rozwiąże. Jak już pisałem wielokrotnie automatyzacja jedynie na poziomie testów end-to-end to za mało. Takie testy to jedynie początek, wstęp do refaktoryzacji mającej na celu poprawę jakości kodu.

2. Skróty nie zawsze są krótszą drogą

Nagrywanie i odtwarzanie testów automatycznych jest pokusą, której wielu początkującym praktykom automatyzacji ciężko jest się oprzeć. O ile samo wytworzenie takich skryptów może być faktycznie względnie szybkie i łatwe, o tyle ich późniejsze utrzymywanie bardzo szybko przeradza się w koszmar. Przeważnie po zmianie funkcjonalności okazuje się, że łatwiej było by nagrać wszystkie testy od nowa niż poprawić już istniejące. Chciwość nie jest najlepszym doradcą przy wyborze narzędzi do testów, co wcale nie znaczy, że trzeba wybierać te drogie i komercyjne – wręcz przeciwnie, darmowe rozwiązania open source, mocno wspierane przez community często okazują się być bardziej użyteczne od tych płatnych.

3. Kod testów nie jest przecież kodem produkcyjnym

Pisząc testy automatyczne musimy pamiętać o zasadach Clean Code tak samo jak powinniśmy o nich pamiętać pisząc kod funkcjonalności. Należy wziąć pod uwagę to, że kod testów będzie zmieniał się najprawdopodobniej tak często jak kod funkcjonalności o ile nie częściej, dlatego przestrzeganie zasad czystego kodu oraz stosowanie wzorców projektowych z pewnością zwróci się w postaci czasu zaoszczędzonego podczas późniejszych modyfikacji.

4. Testowanie End-To-End to za mało

Automatyzacja testów powinna odbywać się na każdym poziomie. Testowanie tylko na poziomie testów akceptacyjnych end-to-end czyli odwracanie klasycznej piramidy testów bardzo szybko prowadzi do jej destabilizacji i przewrócenia. Pomimo tego co zalecam zawsze podczas refaktoryzacji legacy code należy pamiętać o tym, że odwrócona piramida testów musi być sztucznie podpierana by się utrzymać. Dlatego by nasz wysiłek miał sens należy jak najszybciej wykorzystywać to co dają nam testy wysokiego poziomu i szybko budować podstawy piramidy.

5. Automatyzujmy wszystko

Jak często widzieliście projekty pod tytułem „Automatyzacja wszechświata”? Pamiętajmy, że im więcej testów napiszemy tym więcej będziemy ich musieli później utrzymywać. Co w takim razie testować? Z pewnością krytyczne funkcjonalności biznesowe wymagają pokrycia testami. Warto testować też to co się często zmienia. Oczywiście, że można przetestować wszystko – tylko po co? Im więcej testów tym więcej czasu będziemy czekać na informację zwrotną przy ich uruchomieniu. To co nie jest krytyczne powinno być oczywiście przetestowane na poziomie jednostkowym ale już niekoniecznie w testach end-to-end.

6. Automatyzacja to działka testerów

Klientami i głównymi użytkownikami testów automatycznych – nawet tych na poziomie testów akceptacyjnych są przede wszystkim programiści. Dlatego też powinni być oni zaangażowani w proces tworzenia tychże testów. Testy end-to-end nie mogą istnieć w zupełnym oderwaniu od tego co się aktualnie dzieje w kodzie funkcjonalności. Organizacje opierające swój development na konflikcie pomiędzy działem testów a działem programistów nie mają racji bytu we współczesnym środowisku wytwarzania oprogramowania. Coraz więcej organizacji (także tych dużych i wydawało by się skostniałych) rezygnuje w ogóle osobnych działów testowania i łączy testerów z programistami w zespoły wskroś-funkcjonalne.

7. Testy automatyczne nie wymagają ciągłej pracy

Automatyzacja testów to proces ciągły wymagający ciągłej uwagi i opieki. Podobnie jak wytwarzanie nowych funkcjonalności, automatyzacja testów również potrzebuje innowacji i ciągłych udoskonaleń. Czas poświęcony na dobrze zrobioną automatyzację zawsze się zwraca, ale nie zawsze od razu. Czasem trzeba trochę poczekać aż efekty będą widoczne. Albo właśnie nie będą widoczne efekty braku automatyzacji. Także decydując się na automatyzację testów zapomnij o pochwałach i spektakularnych sukcesach – możesz za to liczyć na minimalizacje ilości spektakularnych porażek.

3 komentarze więcej...

Podsumowanie 2013 roku

opublikowany przez 30, Gru, 2013, w kategoriach Praca

Rok 2013 dobiega końca więc pora na krótkie podsumowanie i refleksję nad tym co w tym roku udało mi się osiągnąć i czym myślę że warto się pochwalić. Podsumowanie podzieliłem na kilka kategorii.

Rok 2013 w liczbach

  • 324 uczestników moich szkoleń – liczone są zarówno szkolenia komercyjne jak i darmowe szkolenia i warsztaty dla społeczności. To by tłumaczyło dlaczego mam problemy z zapamiętywaniem imion. Nie liczę tutaj osób, które coachowałem.
  • 38 dni coachingu i doradztwa dla 4 klientów – niesamowite doświadczenia i wyzwania. Począwszy od walki z korporacyjną rzeczywistością a skończywszy na wdrażaniu Continuous Delivery.
  • 13 konferencji na których miałem przyjemność występować, szerzyć wiedzę, inspirować, drażnić, rzucać wyzwania, siać zamęt i czasem obrażać :).

Wydarzenia warte odnotowania 2013

  • Pierwsze prawie darmowe szkolenie Scrum – eksperyment się powiódł. Udało się zorganizować darmowe szkolenie, przyszło ponad 25 osób i wszyscy zobligowali się do zrobienia czegoś dla społeczności w zamian za szkolenie. To z pewnością nie ostatnie takie wydarzenie. Mało tego jest też plan jak przerobić to na coś bardziej regularnego i jeszcze bardziej wartościowego. Wielkie podziękowania dla blogerów i użytkowników twittera, którzy wsparli całą akcję i pomogli ją nagłośnić! To jest potencjał który też warto by było jakoś wykorzystać!
  • Pierwsze Coach Retreat w Krakowie – zapoczątkowaliśmy nowy cykl spotkań. Następne najprawdopodobnie już w lutym. Już teraz zapraszam.

Niektóre konferencje w których uczestniczyłem

O ile częściej w konferencjach głównie uczestniczę jako prelegent niż uczestnik to poniżej wymieniłem kilka konferencji ocenianych z perspektywy (również) uczestnika, które moim zdaniem zasłużyły na wspomnienie:

  • Agile By Example – ta konferencje w tym roku zaskoczyła mnie najbardziej. Zaskoczyła pozytywnie, gdyż pokazała mi, że stan naszego krajowego IT nie jest taki zły jak jeszcze kilka lat temu. Obudziliśmy się z letargu i powoli zaczynamy nadążać za zachodem.
  • ALE 2013 – w tym roku w Bukareszcie podczas ALE poznałem kolejnych wspaniałych ludzi, którzy zainspirowali mnie do dalszego działania i rozwoju!
  • SQA Days – pozytywne zaskoczenie dotyczące tego jak aktywna i duża jest społeczność IT na Ukrainie. W kontekście obecnej sytuacji w tym kraju gorąco kibicuję im w tym by udało im się osiągnąć stan pozwalający na dalszy rozwój społeczności oraz wiedzy w IT (cokolwiek by to nie miało być).
  • TestingCup 2013 – pierwsze w Polsce mistrzostwa w testowaniu oprogramowania. Bardzo ciekawe wydarzenie – polecam wszystkim kolejne edycje. Pozytywny sygnał że w świecie testerskim też coś (co prawda powoli ale) się dzieje.

Szkolenia w których uczestniczyłem warte odnotowania

Ja ogólnie rzadko uczestniczę w szkoleniach, a jeśli już to są to przeważnie szkolenia znajomych, którzy zapraszają mnie bym pomógł im usprawnić ich metody i warsztaty. Niemniej jednak w tym roku byłem na kilku warsztatach i jeden z nich zasłużył z pewnością na wyróżnienie:

  • Warsztaty Coach’s Mindset – prowadzone przez Lynn Skotnitsky. Te warsztaty delikatnie ale znacząco odmieniły mój sposób postrzegania otoczenia. Wiedza, która do tej pory pomimo tego, iż dosyć bogata to jednak mocno teoretyczna nagle nabrała większego sensu, a jej wykorzystywanie w praktyce stało się dla mnie wręcz naturalnym.

Inne 

Tutaj to, co nie pasuje do pozostałych kategorii:

  • Organizacja ALE 2014 – po długich bojach i dzięki wielkiemu zaangażowaniu społeczności Agile z całego kraju udało się wywalczyć organizację ALE 2014 w Krakowie! To duża szansa dla nas jak praktyków Agile by nie tylko zaprezentować się przed innymi ale także zaczerpnąć wiedzy od innych praktyków z całej Europy.
  • W tym roku ukazały się też moje dwie książki „Mity i Problemy w Agile” opisująca doświadczenia zebrane z transformacji Agile, szkoleń, coachingów oraz spotkań różnych społeczności a także  „Agile Transformacje” na podstawie pracy z zespołem Futbolowo.pl

Powyżej tylko kilka z naprawdę wielu wartych odnotowania wydarzeń, które miały miejsce w tym roku. A wam co przychodzi do głowy? Zachęcam do dyskusji na facebooku.

Dodaj komentarz więcej...