blog.testowka.pl

Inne

Problemem są ludzie a nie software

opublikowany przez 28, Paź, 2013, w kategoriach Inne

195244498_01fbb73234_zJak często zdarzało wam się słyszeć, albo co gorsza mówić na przykład że:

W naszym projekcie nie da się automatyzować testów, nie robimy tego ze względu na zbyt dużą ilość legacy code.

albo:

TDD może i działa w projektach zaczynanych od zera, w naszym kodzie pisanie testów jednostkowych jest NIEMOŻLIWE

a może:

Tak, tak próbowaliśmy Continuous Integration, ale napotkaliśmy zbyt wiele problemów. Buildy były prawie cały czas zepsute, a jak ktoś dorzucił jeszcze swoje zmiany do zepsutego builda to naprawianie tego zajmowało wieki. Teraz wystarczy że nasz kod się kompiluje – testerzy odwalają kawał niezłej roboty.

To tylko kilka przykładów „wymówek” często używanych przez developerów po to by usprawiedliwić swoją niedbałość, niestaranność, brak profesjonalizmu czy nawet niekompetencje.

Mamy 2013 rok (już prawie 2014) jeśli nie stosujesz Continuous Integration to wyjdź ze swojego schronu atomowego i zobacz co dzieje się na około. O CI głośno było już 1999 roku – w IT to naprawdę dużo czasu.

Nie automatyzujesz testów – naprawdę uważasz, że jesteś w stanie efektywnie programować. Testy automatyczne to nie testowanie – to dostarczanie feedbacku. Naprawdę jesteś tak bystry żeby w złożonym środowisku rozwijanych przez siebie systemów mieć pewność, że nie wprowadzasz bugów? A może wcale nie jesteś bystry tylko klepiesz banalne aplikacje?

Nie no oczywiście, że w Twoim projekcie nie da się pisać testów jednostkowych. Pytanie tylko kto ten projekt doprowadził do takiego stanu? A może jednak się da – tylko jest to bardzo trudne? Może warto sięgnąć po jedną czy drugą książkę o pracy z legacy code i coś wreszcie z tym zrobić? Nie, nie musisz pytać o pozwolenie swojego managera – kod to Twoja działka. To Ty bierzesz za to odpowiedzialność. To Ciebie będą koledzy pokazywać palcem jeśli zacommitujesz zmiany niskiej jakości. Nie będą? Dla własnego dobra zmień kolegów – przez takich jak oni stoisz w miejscu.

Continuous Integration, Continuous Delivery, Test-Driven Development, Automatyzacja testów i wiele innych to nie są narzędzia – to są praktyki. Problemem w ich stosowaniu nie jest software z którym mamy do czynienia. Problemem są ludzie, którym brakuje dyscypliny, wiedzy i motywacji do jej zdobywania.

Problemy z softwarem można łatwiej lub trudniej rozwiązać. Gdy natomiast problemem są ludzie to jest już trochę trudniej.

11 komentarzy więcej...

Szkolenia finansowane przez UE – dlaczego ich nieznoszę?!

opublikowany przez 10, Paź, 2013, w kategoriach Praca

8474532085_6d010ee8d0_c
Jako trener czasami mam (wątpliwą) przyjemność prowadzić szkolenia finansowane z funduszy europejskich.

Wydawało by się, że dla większości uczestników takie szkolenia nie różnią się niczym od normalnych szkoleń. Z perspektywy trenera również nie powinno być żadnej różnicy. Niestety jest jednak zupełnie inaczej.

Szkolenia finansowane z funduszy UE przeważnie są dużo gorsze zarówno dla uczestników jak i trenerów. Niektórzy z Was zapewne powiedzą, że nie powinienem się wypowiadać na ten temat, gdyż przecież za to mi płacą – nieważne czy z konta firmy, w której szkole czy z funduszu otrzymanego z UE. Dla wielu jest to być może obojętne – dla mnie jednak nie. Nie przywykłem do dostarczania klientom byle czego, a właśnie tego oczekuje się ode mnie przeważnie, gdy szkolenie jest realizowane w ramach projektów unijnych.

Dlaczego tak jest?

Każde szkolenie to projekt – aby firma mogła dostać dofinansowanie do szkolenia musi najpierw napisać wniosek o dofinansowanie takiego szkolenia. Przeważnie odpowiedzialne za to są w firmach działy HR, tudzież zatrudnia się do tego zewnętrzną firmę. Wniosek taki musi spełniać szereg warunków. Między innymi musi się w nim zawierać cena szkolenia, jego nazwa, dokładny program, etc. Na tej podstawie firma ubiegająca się o dofinansowanie musi później zorganizować przetarg i wybrać najkorzystniejszą opcję – przeważnie tą, która jest najtańsza. Czasem zdarza się, że we wniosku zawarte zostały dodatkowe, bzdurne wymagania, które z góry eliminują wielu dostawców szkoleń.

Niestety, gdy o wyborze szkolenia decyduje cena, to często dochodzi do przypadków w których, klient jedynie marnuje czas swoich pracowników. Tak na przykład już zdarzało mi się „poprawiać” po pewnym bardzo tanim szkoleniu ze Scrum. Jednym z warunków we wniosku napisanym przez firmę X, było to, że uczestnicy zdadzą egzamin PSM I. Ups, na kilkanaście osób po „bardzo tanim szkoleniu Scrum” nikt nie miał na egzaminie więcej niż 45% (na wymagane 80%). Firma musiała jednak coś z tym zrobić, gdyż to szkolenie było częścią dużego projektu, na który dostali dużo kasy z UE. Pieniądze te w przypadku niepowodzenia i niespełnienia wymagań projektowych musieli by zwrócić. Kolejnym ciekawym przykładem było „zaawansowane szkolenie z Selenium” (za 1000zł), na którym trener głównie pokazywał Selenium IDE. Zaawansowane nie?! Już więcej się z mojego kursu na stronie nauczycie ZA DARMO!!.

Brak analizy potrzeb – niestety z moich doświadczeń (na bazie naprawdę wielu zapytań, które do nas spływają) wynika, że firmy wnioskują o beznadziejne, nikomu niepotrzebne szkolenia. Często jest to sztuka dla sztuki. Zdarzają się nawet przypadki, gdzie taki program szkoleń dla danej firmy układa zupełnie zewnętrzna firma, której w zasadzie nie obchodzi to czego ich klient potrzebuje – najważniejsze, by zrobić jak najwięcej szkoleń i odciąć dla siebie procenty za pośrednictwo w realizacji.

Szkolenia, o które często wnioskują firmy przeważnie nijak mają się do ich potrzeb, a we wnioskach pisze się albo ogólnikowo, albo (przeważnie) wręcz odwrotnie wymienia się wszystko, co przyjdzie organizatorom do głowy. Na przykład kiedyś dostaliśmy zapytanie o szkolenie z: testowania w agile, automatyzacji testów (selenium, jmetter, soapui, junit i kilka innych), narzędzia w testowaniu (jira, mantis i kilka innych), zarządzania testami, TDD i jeszcze paru innych tematów. Początkowo myślałem, że mam problemy z czytaniem ze zrozumieniem i leży przede mną zapytanie o co najmniej 6-10 dni szkoleniowych – pomyślałem, że to może być niezły interes. Niestety myliłem się… Szkolenie miało być jedno i jednodniowe.

Oczywiście zdarzają się wyjątki od tej reguły.

Brak analizy rynku szkoleń – naprawdę w wielu przypadkach miałem do czynienia z zapytaniami o certyfikowane szkolenia Scrum, w których warunkiem było zrobienie takiego szkolenia za 1000 zł/dzień dla na przykład 16 osób – oczywiście cena z egzaminem. Prawda jest taka, że nawet przy dobrych chęciach i potężnym nadmiarze wolnego czasu nie opłacało by się to żadnemu profesjonalnemu trenerowi. (W przypadku PSM dola dla Scrum.org za uczestnika  + wysokie koszty licencji trenera spokojnie przekraczają dzienną stawkę, w przypadku „niezrzeszonych” trenerów cena egzaminu to 100$/osoba). Zdarzały się też zapytania o szkolenia w kwocie 300-400 zł za dzień – często w oddalonych od trenera miastach. No wybaczcie, ale spokojnie więcej jestem w stanie zarobić na etacie w korporacji – nie opłaca mi się tyłka ruszać. Podsumowując zapytania, które przychodzą są przeważnie znacznie poniżej cen rynkowych, dlatego jakość tego typu usług jest przeważnie wątpliwa.

Co możemy z tym robimy? – nie jest na szczęście tak, że wszystkich klientów, którzy wysyłają do nas zapytania opatrzone logotypem UE odsyłamy z kwitkiem. Czasem udaje nam się delikatnie nagiąć tematykę szkolenia tak, by w ramach wniosku zrealizować, coś czego firma potrzebuje – oczywiście na podstawie dogłębnej analizy potrzeb jaką musimy sami przeprowadzać. Czasami jest to jednak niemożliwe.

Bezsensowna papierkologia – szkolenia dofinansowane z UE wiążą się bezsensowną papierkologią. Zarówno dla organizatorów oraz trenerów jak i uczestników. Wypełnianie ankiet, pre-testów, post-testów, kolejnych ankiet i innych badziewi to przeważnie około godzina lub dwie z czasu szkolenia. Bardzo cenna godzina, podczas której można by zrealizować ciekawy materiał. Dodatkowo formalności po stronie trenera i organizatora szkolenia zajmują przeważnie około jednego dnia! Naprawdę nie opłaca mi się robić tych szkoleń tanio.

Generalnie właśnie z tego powodu od teraz cena wszystkich szkoleń, które prowadzę wzrasta o 20% dla przetargów z logiem UE.

No dobrze, ale co możemy z tym zrobić? – no to sobie ponarzekaliśmy… Przydało by się coś konstruktywnego jednak. Mam zatem dla Was propozycję – jeśli będziecie chcieli napisać wniosek o szkolenie finansowane przez UE dajcie nam znać. Zupełnie za darmo porozmawiamy z Wami i pomożemy Wam przynajmniej wybrać tematykę takiego szkolenia, która będzie odpowiadała Waszym potrzebom i możliwościom. Piszcie na szkolenia@codesprinters.com . W takich przypadkach mogę nawet odpuścić wspomniane 20% :).

———————————————————–
UPDATE: Powyższy wpis wywołał kilka komentarzy (niestety off-line więc ich tutaj dosłownie nie przytoczę). Dla tych dla których powyższe nie było wystarczająco jasne – nie chodziło mi o to, że szkolenia finansowane przez UE są ZAWSZE ZŁE i BEZWARTOŚCIOWE. Powyższy post jest jedynie przestrogą i wskazówką jak nie należy tego robić. W wielu przypadkach, dla wielu organizacji dofinansowania tego typu to jedyny sposób na to, by w ogóle jakiekolwiek szkolenia w organizacji zorganizować. Generalnie chodzi mi tylko o to, by robić to z rozsądkiem i nie wyrzucać pieniędzy i czasu w błoto.

6 komentarzy więcej...

O tym jakie to „ciekawe” i „unikatowe” oferty pracy mamy na rynku…

opublikowany przez 12, Wrz, 2013, w kategoriach Inne, Praca

worksucks

Wszelkiej maści rekruterzy i head hunterzy coraz częściej zapełniają folder ze spamem w mojej skrzynce pocztowej. Na portalach społecznościowych typu Golden Line i LinkedIn korespondencja tego typu stanowi przeważającą większość wiadomości, które otrzymuję.

Dlaczego z reguły na nie nie odpowiadam? Ponieważ nie chce pracować dla firmy, która traktuje ludzi jak zasoby – jeśli nie zadają sobie trudu by samemu dotrzeć do potencjalnych pracowników, to raczej nie będzie im później na nich zależało. Pomijam już kwestie tego, że jakość takich usług zazwyczaj (pewnie nie zawsze) pozostawia wiele do życzenia. Jak ktoś, kto nie zna mojej firmy może znaleźć mi odpowiednich pracowników, których ja sam bym zatrudnił.

Niestety tego typu handel żywym towarem staje się coraz bardziej popularny na całym świecie. Jest na szczęście też coraz więcej inicjatyw które stanowczo walczą z tego typu bezsensownym marnotrawieniem ludzkiego potencjału.

Piszę tutaj nie tylko jako teoretyk ale też praktyk, który miał (nie) przyjemność korzystać z takich usług zarówno jako rekrutowany jak i ten, który postanowił spróbować skorzystać z usług firmy zajmującej się rekrutacją do wyszukania i pozyskania odpowiednich pracowników – w ramach eksperymentu (który kosztował nas bardzo dużo niestety).

Poniżej prezentuje jedną z wiadomości jakie otrzymałem na Golden Line oraz moje komentarze:

Witam Panie Wiktorze,

W imieniu dyrektora personalnego, globalnego lidera rozwiązań informatycznych, poszukuję do nowoczesnego centrum w Krakowie, osób na stanowisko: Tester Oprogramowania.

Ofertę wyróżnia:

-Bardzo ciekawa praca oparta o najnowsze technologie
-Możliwość udziału w innowacyjnych projektach
-Rozwój wiedzy i kompetencji poprzez zaprojektowaną ścieżkę kariery
-Rozbudowany pakiet szkoleń wprowadzających, obejmujący szkolenia techniczne, technologiczne oraz z umiejętności miękkich
-Przyjazna atmosfera w pracy
-Dostęp do prywatnej opieki medycznej
-Karta Benefit MultiSport
-Bardzo dobre warunki finansowe, w granicach 5 – 8 tys zł brutto

Wymagania:

-Wykształcenie wyższe techniczne
-Podstawowa znajomość relacyjnych baz danych i SQL
-Znajomość zagadnień z zakresu testowania aplikacji i zapewniania jakości
-Znajomość zagadnień z zakresu metod analizy strukturalnej i obiektowej
-Znajomość języka angielskiego
-Zdolność uczenia się i wykorzystywania doświadczeń
-Komunikatywność

Czytając tego maila miałem ochotę zanegować wszystko co było w nim napisane, a więc po kolei:

W imieniu dyrektora personalnego, globalnego lidera rozwiązań informatycznych, poszukuję do nowoczesnego centrum w Krakowie, osób na stanowisko: Tester Oprogramowania.

Co to za lider, który wstydzi się podać swoją nazwę? To tani chwyt, który pozwala rekruterowi nawiązać pierwszy kontakt. Pamiętajcie, ze rekruterzy to sprzedawcy, a sprzedawcy są od tego żeby wcisnąć nam coś czego nie potrzebujemy. Jak czegoś na prawdę potrzebujemy to sami potrafimy to znaleźć i zdobyć. Nie jesteśmy przecież upośledzeni – przecież pracujemy w IT, no nie?

Ciekawe ponadto dlaczego pan rekruter myśli, że mógłbym z moim doświadczeniem być zainteresowany pracą jako Tester Oprogramowania. Ciekawe czy w ogóle zapoznał się z moim profilem.

Ofertę wyróżnia:

O nie wątpię, że wyróżnia… A właściwie… to wątpię… Mniej więcej to samo jest w każdej ofercie…

-Bardzo ciekawa praca oparta o najnowsze technologie

Ciekawe jakie to technologie? Java, C#, Ruby on Rails? To wszystko to nie jest nic nowego? Jak już ktoś pisze o najnowszych technologiach to lepiej by było, gdyby podał o jakie technologie chodzi. Przy okazji (zakładając, że faktycznie są to najnowsze technologie) wzrosły by sznase na znalezienie kogoś, kto daną technologią się interesuje.

-Możliwość udziału w innowacyjnych projektach

Ciekawe co ogłoszeniodawca rozumie przez innowacje? To temat rzeka.

-Rozwój wiedzy i kompetencji poprzez zaprojektowaną ścieżkę kariery

Fajnie, że ktoś wie lepiej ode mnie co jest dla mnie dobre i z góry zaprojektował moją ścieżkę kariery. Poza tym nie rozumiem jak zaprojektowana ścieżka kariery ma się do rozwoju wiedzy i kompetencji?

-Rozbudowany pakiet szkoleń wprowadzających, obejmujący szkolenia techniczne, technologiczne oraz z umiejętności miękkich

Czytam to i myślę sobie: czyli macie tak poplątane procesy i badziewny produkt, że potrzebne są szkolenia wprowadzające by móc cokolwiek z nim zrobić? Dodatkowo uważacie, że problem leży w umiejętnościach miękkich jak na przykład radzenie sobie ze stresem, rozwiązywanie konfliktów – zwłaszcza z managerami, o i może motywacja! 

A może się mylę i chodzi o to, że i tak nie liczą na to, że zatrudnią kogoś kto wie cokolwiek i z góry zakładają, że trzeba będzie kogoś takiego od zera wszystkiego nauczyć.

-Przyjazna atmosfera w pracy

Czy szanowny rekruter był w tej firmie, pracował tam i wie, że taka właśnie atmosfera tam panuje?

-Dostęp do prywatnej opieki medycznej
-Karta Benefit MultiSport

O super, ale to akurat dzisiaj już chyba nie wyróżnia ofert pracy. Może się mylę…

-Bardzo dobre warunki finansowe, w granicach 5 – 8 tys zł brutto

O! Pierwszy pozytyw, wreszcie w ofertach podają widełki finansowe! Po przeliczeniu 3500-5500 na rękę. Chyba całkiem nieźle jak na stanowisko Tester Oprogramowania.

Dobrze – przejdźmy do wymagań:

-Wykształcenie wyższe techniczne

Ups, niestety nie spełniam tego wymagania, więc odpadam. Jest na pierwszym miejscu, więc pewnie jest to najważniejsze. Niestety mam 8 lat doświadczenia w branży i ledwo skończyłem 26 lat. Nie było czasu na studia, które poza papierkiem w obecnej rzeczywistości nic by mi nie dały. Jakie szczęście, że są firmy które bardziej cenią doświadczenie niż papier.

-Podstawowa znajomość relacyjnych baz danych i SQL

Co to znaczy „podstawowa”? Znam SQL, potrafię kilka zapytań stworzyć jeśli będzie trzeba.

-Znajomość zagadnień z zakresu testowania aplikacji i zapewniania jakości

Skoro przyszli do mnie z ofertą pracy jako tester oprogramowania to chyba wybrali właśnie mnie na podstawie tego, że wedle ich oceny mam jakieś umiejętności z tego zakresu.

-Znajomość zagadnień z zakresu metod analizy strukturalnej i obiektowej

„Analiza strukturalna” – za cholerę nie wiem o co chodzi – pytam więc Google. Wyniki, to fizyka, chemia, geodezja – czy oni na pewno szukają testera? Może chodziło o programowanie strukturalne i obiektowe?

-Znajomość języka angielskiego

Heloł mai nejm iz aj perfekt spik englisz. 

-Zdolność uczenia się i wykorzystywania doświadczeń

Wydawało mi się, że każdy człowiek (i ie tylko jest do tego zdolny) – widocznie się myliłem.

-Komunikatywność

Tą zdolność, też chyba każdy z nas posiada.

Ciekawa oferta – wysłał bym CV. Szkoda tylko, że go nie posiadam – wszystkie informacje na mój temat potrzebne do rekrutacji są na moim profilu na LinkedIn.

Generalnie ogłoszenie nudne jak flaki z olejem. Jak przerażająca większość ogłoszeń. Nie to żebym sam nigdy takich nie tworzył, ale teraz już wiem, że to nuda.

Także drodzy pracodawcy jeśli szukacie ciekawych i wartościowych ludzi to musicie oferować ciekawą i wartościową pracę – taka praca musi być też odpowiednio opisana by zainteresować właściwe osoby.

Jeśli szukacie ludzi, którym będzie zależeć na waszej firmie i waszych produktach to wam też musi zależeć na tych ludziach i ich odpowiednim wyborze. Dlatego nie zlecajcie tak ważnej dla całej organizacji sprawy komuś z zewnątrz.

14 komentarzy więcej...

Czy potrzebujesz Agile Coacha?

opublikowany przez 10, Wrz, 2013, w kategoriach Agile, Coaching, Kanban, Praca, Scrum, XP, Zarządzanie

2536358399_88e6544fa9_o
Po raz kolejny utwierdziłem się w przekonaniu, że ludzie nie czytają, nie tylko moich książek, czy mojego bloga… Ludzie nie czytają w ogóle, albo czytają bardzo mało rzeczy związanych z ich pracą. Utwierdziłem się w sposób najprostszy – pytając około 35 osób czy czytają… Ludzie nie czytają i nie jeżdżą na konferencje bo najzwyczajniej nie mają na to czasu przez pracę. Często przez to, że ich praca jest nieefektywna muszą pracować więcej, by osiągnąć oczekiwane rezultaty. Pracując więcej nie mają czasu na to, by poczytać o tym jak pracować efektywniej…

I w sumie bardzo dobrze… Bo ja czytam… Bo ja piszę książki… Bo ja jeżdżę na konferencje i czasem tam coś opowiadam… Publikuję czasem coś na blogu ale przede wszystkim czytam blogi innych… Poświęcam dużo czasu na naukę nowych rzeczy, ale też na przemyślenia związane z praktycznym zastosowaniem tego co już umiem… Eksperymentuje z nabytą wiedzą stosując ją w praktyce… Ciągle nabywam coraz więcej doświadczenia związanego z tymi tematami… Bardzo różnorodnego doświadczenia dzięki pracy dla bardzo różnych klientów… Klientów w różnym kontekście, w różnym środowisku, w różnych technologiach i w różnych branżach… Rozmawiam z ludźmi, dzielę się swoim doświadczeniem ale też korzystam z doświadczeń innych…

Właśnie to wszytko, właśnie to, że ja MAM na to czas i że swój czas na to właśnie poświęcam jest głównym powodem tego, że bardziej opłaca Ci się zatrudnić mnie jako Agile Coacha, jako Mentora, jako Trenera, jako Doradce, niż samemu poświęcać nieskończoną ilość godzin na wyszukiwanie i zdobywanie tej wiedzy i doświadczenia. Jest to również bardziej opłacalne niż samodzielne popełnianie błędów – zwłaszcza tych kosztownych i tych, które ja już wcześniej miałem okazję popełnić, lub zaobserwować gdzieś indziej.

Poza tym ja lubię to robić. Robię to z pasją. Nie traktuję tego nawet jak pracę – jest to bardziej moje hobby…

Dość tej autopromocji! Generalnie chodzi o to, że zdobywanie wiedzy to również ciężka praca wymagające wielu poświęceń, a już na pewno dużej ilości poświęconego czasu. Czasem można jednak zdać się na kogoś, kto już tą wiedzę posiada, albo ma czas na to, by zdobyciu tej konkretnej wiedzy się poświęcić…

8 komentarzy więcej...

Czemu ludzie nie czytają?

opublikowany przez 09, Lip, 2013, w kategoriach Agile, książki, Programowanie, Zarządzanie

Przez ostatnich kilka lat miałem do czynienia z wieloma zespołami developerskimi. Niektóre z nich radziły sobie z często nieprzychylną rzeczywistością pracy w IT lepiej niż inne.

Gdy pracuję z zespołami, czy to w formie coachingu i mentoringu organizacyjnego  czy szkoleń to oprócz codziennej pracy, ćwiczeń i warsztatów zasilam ich zawsze pokaźną wiedzą linków do artykułów i nagrań które wiem, że mogą być pomocne w ich pracy. Często czas, który mogę poświęcić zespołom jest zbyt krótki, bym sam przekazywał im wszystko to co w tych artykułach i nagraniach jest zaprezentowane. Poza tym nawet jeśli ten czas już mamy to szkoda go marnować na rzeczy, które można z łatwością samemu przeczytać i zrozumieć – warto skupić się na tym co faktycznie jest problematyczne i jednocześnie charakterystyczne dla danego zespołu, na tym do czego rozwiązań nie znajdzie się w standardowych książkach i na blogach. Oprócz artykułów przesyłam też często fragmenty książek (tylko odrobinę spiracone)…

Od jakiegoś czasu wszyscy uczestnicy moich szkoleń dostają też darmowy dostęp do mojej książki (dzięki temu nie muszę już wielu tematów omawiać – wystarczy, że powiem, że tam to jest).

Przez ostatnich kilka miesięcy zdarzyło mi się przeprowadzić w sumie około dziesięciu warsztatów z Legacy Code Retreat z różnymi zespołami. Potrzeba takich warsztatów wynikała głównie z tego, że uczestnicy na co dzień pracowali właśnie z Legacy Code.

Praktycznie za każdym razem zadawałem pytanie, o to skąd uczestnicy czerpią wiedzę na temat tego jak pracować z takim kodem i jak go poprawiać. Odpowiedzi były co najmniej niepokojące – przeważnie było to „znikąd”.  Około 100 developerów (czyli większość pytanych) z kilku firm  walczy od kilku lat z kupą badziewnego kodu ,ale nie robi nic lub prawie nic by rozwijać się w kierunku tego jak sobie z takim problemem poradzić. Zapytałem czy czytali jakieś książki na ten temat – tylko kilka osób na sto czytało na przykład „Working Effectively with Legacy Code” (Michael Feathers). Kilka innych osób również słyszało, że książki takie jak wspomniana istnieją ale… nie mieli czasu by je przeczytać – nie mieli czasu bo ciągle muszą walczyć z gaszeniem pożarów i pracą z badziewnym kodem.

Przeczytanie wspomnianej książki i sumienne przerobienie na prawdziwym kodzie (swoim własnym najlepiej) zalecanych tam sposobów pracy z Legacy Code pozwoliłoby z pewnością na wyjście ze stanu ciągłego gaszenia pożarów i biegania z pustymi taczkami. Oczywiście potrzeba by było czasu aby to osiągnąć, ale metody wspomniane przez Michaela są wręcz skierowane do tych, którzy nie mogą sobie pozwolić na zatrzymanie rozwoju produktu po to by poprawiać jego jakość.

Jurgen Appelo od dłuższego już czasu na swoim blogu pomiędzy merytorycznymi wpisami publikuje listy subiektywnie najlepszych książek w różnych kategoriach. Listy powstały między innymi na bazie tego co Jurgen przeczytał. Jego książka „Management 3.0” jest niczym innym jak zbiorem najbardziej trafnych i praktycznych teorii zawartych w setkach innych książek. Jurgen te książki przeczytał, następnie sprawdził najbardziej obiecujące teorie w praktyce po czy stworzył, a w zasadzie zebrał zbiór praktyk nazywanych obecnie jako Management 3.0.

Internet jest praktycznie nieograniczonym źródłem wiedzy na prawie wszystkie tematy. Wystarczy tylko po tą wiedzę sięgnąć. Nie potrzeba żadnych szkoleń i warsztatów.

Przyznam się szczerze, że od kilku lat prowadzę szkolenia ale sam nie byłem na żadnym szkoleniu nigdy. Tzn. nie po to by się na nim czegoś specjalnego dowiedzieć czy nauczyć – czasem zdarzało mi się uczestniczyć w szkoleniach moich znajomych trenerów by podejrzeć jak oni to robią i dać im jakiś feedback. Może czasem przy okazji udało mi się podchwycić jakieś ciekawe tricki szkoleniowe. Ale wiedzę merytoryczną zdobywałem głównie z książek, artykułów, konferencji i nagrań. Oczywiście ta wiedza to za mało by uczyć innych – potrzeba było jeszcze wielu tysięcy godzin praktyki i prób (często nieudanych) stosowania zdobytej wiedzy w realnym świecie i prawdziwej pracy.

To nie jest tak, że szkolenia nie są potrzebne w ogóle. Ja zawsze staram się, by moje szkolenia pomogły uczestnikom rozpocząć samorozwój. Tak na przykład przygotowując warsztaty z automatyzacji testów zdaliśmy sobie sprawę, że największym problemem, gdy sami się tego uczyliśmy kilka lat wcześniej było przekroczenie pewnej wysokiej bariery wejścia jaką było na przykład postawienie działającego środowiska do testów, czy też opanowanie podstaw programowania obiektowego.

Jeśli ktoś to dobrze wytłumaczy i przerobi się kilka przykładów to staje się to banalne, a dalsza nauka jest już przyjemnością i wynika głównie z praktyki bo powyższe podstawy wystarczają by zacząć praktycznie pisać testy automatyczne. Tak oto stworzyliśmy trzydniowe warsztaty podczas których stosujemy metody przyspieszonego uczenia i stawiamy duży nacisk na praktykę. Oferujemy też drugi stopień warsztatów dla tych, którzy potrzebują przeskoczyć kolejne poprzeczki.

Waszą Drodzy Czytelnicy niewątpliwą i godną podziwu zaletą jest to, że w ogóle czytacie cokolwiek – bo przecież czytacie chociażby tego bloga. Pytanie czy Wasi koledzy i koleżanki z pracy również to (albo cokolwiek innego w tej tematyce) czytają. Proponuje byście ich zapytali czy czytają, co czytają i dlaczego nie czytają?

Być może czytacie bo w waszym środowisku się po prostu czyta – tzn wszyscy wokół Was czytają i dlatego czytacie. Być może w powietrzu wokół Was da się wyczuć zapach ciągłej potrzeby rozwoju i nauki.

A może jesteście jedynie odosobnionymi, czytającymi  i pragnącymi rozwoju jednostkami w tłumie ludzi, którzy po prostu przychodzą na 8 godzin do pracy by odsiedzieć swoje i zarobić na chleb.

Jeśli należycie do tej drugiej grupy, to proponuje byście spróbowali zachęcić, czy też zarazić innych wokół was wirusem powodującym głód wiedzy i ciągłego rozwoju. Jeśli się to Wam nie uda to… dla własnego dobra lepiej zmieńcie pracę…

Z moich obserwacji wynika, że jednym z głównych problemów organizacji IT w obecnym świecie są ludzie, którzy z różnych powodów zaprzestali się rozwijać. Podzielił bym ich na dwie grupy: pierwsza to Ci, którzy w ogóle nie wiedzą, że jakikolwiek rozwój jest możliwy i potrzebny, a druga to tacy, którzy zrobili już (za)szybką karierę i wydaje im się, że wiedza, którą posiadają jest już wystarczająca i nie więcej nie potrzebują.

Mi osobiście wydaje się, że rozwijać się trzeba zawsze – jeśli przestajemy się rozwijać to nasze życie przestaje mieć sens. A jak jest z Wami?

5 komentarzy więcej...

Zwinne pisanie książki

opublikowany przez 19, Cze, 2013, w kategoriach Inne

Mniej więcej półtora roku temu wpadłem na pomysł napisania książki. Pierwsze pytanie – o czym ma być ta książka? Pomysłów było kilka – niektóre z nich postanowiłem sprawdzić na tym właśnie blogu. Co to znaczy sprawdzić? Napisałem kilka notek i słuchałem waszych opinii. Kolejnym testem było kilka prelekcji na konferencjach powiązanych z tematami, o których wcześniej już pisałem na blogu i które spotkały się z największą popularnością.

Padło na temat problemów i mitów w Agile – powstał nawet cały cykl wpisów tutaj. Z problemami przy transformacji organizacji w kierunku Agile spotkał się chyba każdy, kto kiedykolwiek takiej transformacji próbował. Z moich obserwacji wygląda na to, że większość prób transformacji Agile niestety kończy się niepowodzeniem. Postanowiłem zatem opisać najczęściej spotykane przeze mnie problemy.

Dobrym pomysłem okazała się organizacja spotkań z cyklu Bring Your Own Problem, dzięki którym utwierdziłem się, że problemy, z którymi się spotykałem w swojej pracy doradcy nie są niczym nadzwyczajnym i dotyczą niemal każdej organizacji.

Zaczęło się pisanie. Ale pisać do szuflady to stanowczo za mało. Chciałem pokazać swoje szkice kolegom po fachu, po to by dali mi jakiś feedback na temat tego co napisałem i jak to wygląda. Pierwszą wersję wysłałem miedzy innymi do Marcina (razem prowadzimy szkolenia z automatyzacji i BDD) – zapytał on, jeszcze nie czytając tego co podesłałem dlaczego nie wydałem tego co mam? Na co czekam?

Ale jak to?! Jak wydać coś co jest jeszcze nieskończone, ba, coś co zawiera błędy? Marcin uśmiechnął się i zapytał – a czego uczysz ludzi na tych swoich szkoleniach? „Release early, realease often”. Pomysł wydawania nieukończonych książek – w sposób inkrementalny nie jest niczym nowym. Między innymi tak powstawały klasyki, o których uczą w szkołach. Na przykład „Potop” Sienkiewicza czy „Lalka” B. Prusa, które w odcinkach ukazywały się w prasie. Obecnie dzięki internetowi możemy łatwiej i szybciej dotrzeć do czytelników – nie tylko poprzez blogi ale także dzięki aplikacjom takim jak Leanpup.

Tak też zrobiłem i ja. Mniej więcej dwa miesiące temu ukazała się pierwsza wersja mojej książki: „Mity i problemy w Agile”. Chciałem tylko sprawdzić czy ktokolwiek w ogóle to przeczyta i da mi jakikolwiek feedback. Zainteresowanie przerosło moje oczekiwania – nie dość, że dosyć szybko około 100 osób pobrało książkę, to kilkoro czytelników napisało bardzo wartościowe maile ze swoimi uwagami i doświadczeniami odnośnie tego o czym piszę.

Książka początkowo była dostępna za darmo – teraz też możecie ją pobrać za free używając kodu rabatowego „testowka”. Nawet pomimo tego, że można było pobrać książkę za darmo niektórzy czytelnicy zdecydowali się za nią zapłacić, ponadto byli też tacy, którzy po darmowym pobraniu książki i jej przeczytaniu płacili za nią – co dodatkowo motywuje mnie do dalszego pisania i rozwijania publikacji.

Możecie znaleźć książkę tutaj https://leanpub.com/problemywagile – będę wdzięczny za jakikolwiek feedback, czy to na maila czy na twitterze z tagiem #problemywagile, czy bezpośrednio pod książką.

Darmowe kody będą jeszcze działały przez jakiś czas także spieszcie się z pobieraniem!

Wkrótce kolejne wersje książki do których Ci, którzy już ją pobrali będą mieli oczywiście darmowy dostęp.

3 komentarze więcej...

Developerzy są jacyś inni…

opublikowany przez 10, Gru, 2012, w kategoriach Inne

Developer – dziwna istota spędzająca przynajmniej jedną trzecią swojego  życia przed ekranem komputera. Developer – magik które zwykłe literki na ekranie potrafi zaczarować w taki sposób, że stają się mniej lub bardziej ruchomymi obrazami. Developer – szaman zaklinacz zaklinający pliki z kodem źródłowym* (taka księga z zaklęciami) tak by wykonywały jego polecenia i na ekranie komputera wyświetlały dokładnie to czego potrzebuje. Developer – ufoludek posiadający nadzwyczajne moce pozwalające na manipulowanie tymi wszystkimi dziwnymi urządzeniami wykorzystującymi tzw. software.

Developer na co dzień pracuje ze złymi, choć czasem mało rozgarniętymi posłańcami piekieł nazywanymi managerami. Problem z managerami polega na tym iż dawno, dawno temu potężny zły czarownik nazywany rewolucja przemysłowa obdarował ich mocą zarządzania developerami. Od tamtej pory developerzy z całego świata są niewolnikami tejże mocy i muszą spełniać najdziwniejsze i nierzadko bezsensowne zachcianki managerów. Niedobrzy managerowie nie dość, że nękają biednych developerów to jeszcze czasem niemalże siłą wciągają niektórych z nich do swojej sekty mianując ich managerami.

Kilku developerów zbuntowało się. Niektórzy z nich niestety przeszli na ciemną stronę mocy i założyli własne firmy, w których powoli pod wpływem niewyjaśnionej siły stawali się managerami. Na szczęście pozostała garstka renegatów – buntowników nazywanych freelancerami. Ich życie jest często dużo trudniejsze niż życie normalnego developera niemniej jednak są oni wyzwoleni spod mocy managerów.

Kto zrozumie developera? Pewnie tylko inny developer.

A teraz na serio. Pracując jako niezależny Coach miałem przyjemność poznać na prawdę wielu niesamowitych developerów. Nie zawsze było też tak źle z managerami – niektórzy z nich wspaniale wspierają developerów w ich codziennej pracy. Developerzy kimkolwiek są, są troszeczkę inni niż „normalni” ludzie. Pracując z nimi zawsze mam nieodparte wrażenie, że znajduje się wśród ludzi niezwykle inteligentnych, znających się na tym co robią, lubiących to co robią i wykonujących swoją pracę z pasją (oczywiście zdarzały się też wyjątki potwierdzające tą regułę). Ludzie ci nie potrzebowali kontroli a co najwyżej pomocy w usuwaniu przeszkód powstrzymujących ich od wykonywania ich pracy dobrze. Właśnie na tym polega rola managera w Agile. Manager jest facilitatorem (nie znam polskiego odpowiednika tego słowa) – jego główne zadanie to ułatwianie pracy developerom bo to oni produkują wartość. Ci ludzie są zbyt mądrzy i inteligentni by nimi zarządzać! Aczkolwiek czasem potrzebują pomocy…

1 komentarz więcej...