blog.testowka.pl

Archiwum wiadomości z Październik, 2012

Agileowe Pranie Mózgów!

opublikowany przez 10, Paź, 2012, w kategoriach Agile

Agileowe pranie mózgów czyli 4 dni niesamowitych konferencji: Agile By Example i Agile Eastern Europe.

W ubiegłym tygodniu odbyła się druga edycja konferencji Agile By Example w Warszawie. Miałem przyjemność zaprezentować kontrowersyjny(?) temat roli testera w projektach zwinnych. Slajdy znajdziecie poniżej.

Moja prezentacja została odebrana bardzo pozytywnie – o czym świadczą niesamowicie ciekawe rozmowy w kuluarach i przy wieczornym piwie.

Ogólnie całe wydarzenie oceniam jako bardzo udane – możliwość wymiany wiedzy z niesamowitymi osobami – zarówno prelegentami jak i uczestnikami to jest to co w konferencjach lubię najbardziej.

W pamięci utkwiły mi trzy prezentacje:

Keynote Growing Effective Teams, w którym Roy Osherove poruszył bardzo ciekawy temat różnych poziomów dojrzałości zespołów. Głównym punktem wartym zapamiętania jest to, że nie każdy zespół jest gotowy na coaching i czasem warto zacząć od tradycyjnego Command & Controll po to by ten zespół wychować.

Drugim prelegentem, który z pewnością zaciekawił mnie tematem swojej prelekcji był Marc Löffler. Prezentacja „From an idea to a product (in a regulated environement)” w której Marc pokazał w jaki sposób efektywnie używać technik takich jak Impact Mapping była dla mnie bardzo wartościowa i na pewno skorzystam z jego porad w codziennej pracy nie tylko w IT. Więcej o Impact Mapping znajdziecie tutaj: http://impactmapping.org/.

Bardzo cieszę się ze wszystkich case studies prezentowanych przez polskich prelegentów niemniej jednak najbardziej zapamiętałem prezentację „Visibility, Feedback, Continuous Integration and Fun”, w której Marek Kirejczyk przypomniał nam kilku najważniejszych w byciu Agile (i nie tylko) rzeczach.

Jak zwykle pierwszego dnia miało miejsce party, które w moim przypadku potrwało do późnych godzin nocnych. Wieczór wypełniony dyskusjami głównie z Marc’iem Löffler’em i Jasperem Sonnevelt’em nie zawsze na tematy tylko Agile’owe dał mi mnóstwo energii i zmotywował mnie przynajmniej na najbliższy czas do tego by dalej aktywie brać udział w wydarzeniach Agile’owych oraz by udzielać się w społeczności.

Z Agile By Example polecieliśmy do Kijowa na konferencję Agile Eastern Europe. Po drodze podczas przesiadki we Frankfurcie spotkaliśmy Nick’a Oostvogels’a z którym nie widziałem się od Agile Lean Europe w Berlinie – przypadkiem(?!) okazało się, że mamy miejsca w samolocie obok siebie. Pomimo zmęczenia po 2 dniach poprzedniej konferencji od razu włączyliśmy Nick’a do naszej dyskusji na tematy prezentowane podczas Agile By Example.

Co do samej konferencji w Kijowie – jest to największe tego typu wydarzenie w tej części Europy. Była to już 4 edycja i organizatorzy spisali się jak zwykle świetnie.

Odnośnie prelekcji większość była niesamowicie ciekawa – nie tylko ze względu na tematykę ale także na doświadczenie samych prelegentów. Organizatorom udało się ściągnąć na prawdę jednych z najlepszych praktyków Agile na świecie. Miałem niesamowitą przyjemność znaleźć się w tym gronie (nadal nie wiem jakim cudem :P) i wygłosić wykład na temat Radzenia sobie z Legacy Code  „Reversed Tests Pyramid – Dealing With Legacy Code”.

Moje pierwsze zaskoczenie miało miejsce już na samym początku, gdy zorientowałem się, że sala w której miałem prezentować (największa ze wszystkich) pomimo 3 równolegle odbywających się prelekcji jest wypełniona w co najmniej 70%. Jak widać temat legacy code jest powszechnym problemem nie tylko w Polsce. Po prelekcji zebrała się spora grupa ludzi zadających pytania, co było dla mnie największą nagrodą. Slajdy znajdziecie poniżej – podobny temat będę prezentował na Test Warez w Poznaniu.

No ale dosyć o mnie! To co mi najbardziej utkwiło w pamięci to dwa keynoty w wykonaniu Henrika Kniberga w których opowiadał między innymi o praktycznym zastosowaniu Scrum. Nagrania powinny być wkrótce dostępne na http://agileee.org.

Niezwykle inspirujący był keynote zamykający konferencję, w którym Steve Keil przekonał nas do tego kwestionować wszystko co zostało nam narzucone bo to, że robimy coś tak jak robimy od dłuższego czasu wcale nie znaczy, że jest to najbardziej optymalny sposób.

Oprócz keynotów chyba najbardziej podobała mi się prezentacja Piotrka Żołnierka z Polski, który opowiadał o tym jak zorganizował swoją firmę na podobieństwo gangów motocyklowych ze Stanów Zjednoczonych. Piotrek Burdyło również w swojej prelekcji kwestionował potrzebę zarządzania i kontroli dlatego szybko polscy prelegenci zostali okrzyknięci anarchistami…

Hej! To ja i Alistair - ten w zielonym

Warsztaty z (nie ukrywam moim mistrzem) Alistair’em Cockburn’em, podczas których przećwiczyliśmy pragmatyczne rozbijanie wymagań na jak najmniejsze historyjki, po czym wymagania te implementowaliśmy (coś trochę jak TDD bez testów) przypomniały i jak ważny jest pragmatyzm we wszystkim co robimy.

Prelekcje i warsztaty to nie wszystko oczywiście najważniejsze były rozmowy w kuluarach, podczas bankietu oraz after-party. Narodziło się kilka genialnych pomysłów w naszych głowach i zapewne o niektórych z nich wkrótce się dowiecie. Między innymi wraz z innymi prelegentami z Polski poczyniliśmy pierwsze kroki mające na celu zjednoczenie i zmobilizowanie polskiego środowiska Agile.

W skrócie: kolejny raz utwierdziłem się w przekonaniu, że warto spędzać nawet swój wolny czas na tego typu eventach. Polecam wszystkim tego rodzaju sposób samodoskonalenia się i rozwoju.

Obiecane prezentacje poniżej… Jeśli macie jakieś uwagi odnośnie moich prelekcji lub konferencji – w komentarzach jest dużo miejsca dla wszystkich.

Dodaj komentarz więcej...

To nie proces ale ludzie odnoszą sukcesy

opublikowany przez 02, Paź, 2012, w kategoriach Agile, Kanban, Praca, Programowanie, Scrum, XP, Zarządzanie

Zaczynają mnie męczyć licytacje (w których jeszcze do niedawna zdarzało mi się uczestniczyć) o to, który proces, która metodyka jest lepsza, dzięki której metodyce osiągniemy większe sukcesy. Propagatorzy i zwolennicy różnych mniej lub bardziej zwinnych podejść do wytwarzania oprogramowania prześcigają się w wynajdowaniu przeróżnych case-studies, które miały by być materiałem dowodowym potwierdzającym, że to właśnie metodyka X a nie Y jest lepsze i dzięki niej „projekty” kończyły się sukcesem. Czy Kanban jest lepszy od Scrum, czy na odwrót? Które praktyki z XP dają lepsze efekty? Waterfall vs Agile? Testowanie manualne vs Automatyzacja (…chyba się zapędziłem 🙂 )? I tak dalej…

Moje doświadczenie pokazuje natomiast, że to nie żadna metodyka czy proces były kluczowym czynnikiem sukcesu w projektach, w których uczestniczyłem, lecz ludzie, którzy do tego sukcesu doprowadzali. Na przykład oprogramowanie – projekty które realizowaliśmy w Code Sprinters nie odnosiły sukcesów dlatego, że używaliśmy Scrum, stosowaliśmy programowanie w parach, pisaliśmy testy automatyczne i staraliśmy się wszędzie stosować TDD… Osiągaliśmy sukcesy dlatego, że my – ludzie, którzy wytwarzali ten software potrafili do tych sukcesów doprowadzić. Scrum, TDD, Pair Programming, Testy automatyczne etc. to były tylko narzędzia, bardzo pomocne narzędzia, które w sprawnych, doświadczonych rękach były odpowiednio wykorzystywane.

Jeśli rzeźbiarz nie rzeźbi z pasją, nie ma talentu i nie ma pojęcia w temacie obróbki materiału w którym rzeźbi to bez względu na to jak dobre dłuto mu damy rzeźba arcydziełem raczej nie będzie”

Podobnie z oprogramowaniem. Jeśli tego co robimy nie robimy z pasja to niestety efekty naszej pracy będą co najwyżej średnie. Jeśli nie posiadamy wystarczającej wiedzy na temat technologii, którą stosujemy i ciągle nie wzbogacamy tej wiedzy to z pewnością nie unikniemy wielu błędów. Nawet jeśli metody i procesy są tylko(?) narzędziami to wcale nie znaczy, że możemy o nich zapomnieć. Umiejętne posługiwanie się narzędziami jest kluczowe – czym byłby rzeźbiarz bez dłuta, albo taki, który tym dłutem posługiwać się nie potrafi.

Odpowiedni ludzie, którym zapewniamy odpowiednie warunki do pracy to jest właśnie to co sprawia, że różnego typu narzędzia (metodyki, procesy, praktyki, technologie, etc.) działają tak jak powinny i w efekcie prowadzą do sukcesów.

Udowadnianie że metoda X jest lepsza od Y nie ma najmniejszego sensu. Wszelkie porównania także są bezcelowe, gdyż nie sposób zapewnić odpowiednio laboratoryjnych warunków, by jakiekolwiek miarodajne testy przeprowadzić. Nawet tan sam zespół będzie lepiej pracował używając danego zestawu narzędzi nie dlatego, że narzędzia są lepsze ale dlatego, że akurat te narzędzia bardziej do tego zespołu pasują.

Kiedyś, ktoś zapytał mnie na jakiejś konferencji czy Agile jest dla każdego – a jeśli nie to co zrobić z tymi, którzy do tego modelu nie pasują. Osoba pytająca była managerem w organizacji, która przymierzała się do Agile. Moją odpowiedzią było pytanie: „Jakie jest najważniejsze zadanie managera w organizacji? Takie, które ma zasadniczy wpływ na wszystkie inne decyzje np. o procesach i metodykach?”. Podstawą jest stworzenie zespołu i dobór odpowiednich osób do odpowiedniej pracy.

Niestety chyba powoli o tym zapominamy – zbyt często managerowie są zatrudniani do już istniejących zespołów, lub są wyłaniani z tychże zespołów drogą awansu. Często manager ma związane ręce w kwestii doboru osób do zespołu. A to właśnie odpowiedni dobór osób do wykonywania danego rodzaju pracy jest kluczowy. Pomijam już fakt, że sam proces doboru jest bardzo trudny i często pomimo najlepszych starań kończy się pomyłkami.

Co by się stało gdybyśmy nagle naszym programistom kazali budować domy?”

A co jeśli programistom php każemy od jutra pisać kod w C, albo na odwrót. Co jeśli ludziom z piętnastoletnim doświadczeniem w korporacyjnych procesach predykcyjnych nagle każemy przesiąść się do małych wskroś-funkcjonalnych zespołów pracujących w sposób czysto empiryczny.

Niektórzy programiści może i dom wybudują – ale raczej nie wszyscy są do tego zdolni…

Dodaj komentarz więcej...