blog.testowka.pl

Programowanie

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...

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...

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...

A mury runą, runą, runą…

opublikowany przez 13, Lip, 2012, w kategoriach Agile, Automatyzacja, CI, Programowanie, Scrum, Testowanie, XP, Zarządzanie

…i pogrzebią stary świat…

Tak wiem, że Kaczmarski miał niewiele wspólnego z wytwarzaniem oprogramowania. O jaki mur chodzi? Mur, który od lat budowaliśmy pomiędzy tzw. programistami i tzw. testerami. Często powstawały nawet fizyczne mury i bariery – chociażby odległość liczona w tysiącach kilometrów.

Od dawna już wiadomo, że zarządzanie poprzez konflikt (tutaj konflikt między testerami, a programistami) jest jedynie (o ile w ogóle) efektywne w krótkich okresach czasu – długofalowo niszczy motywacje i powoduje mnóstwo problemów wynikających z komunikacji. Programowanie (wytwarzanie oprogramowania) jest grą zespołową – zespół to nie tylko programiści. Zespół to też testerzy, zespół to także klienci, to czasem też docelowi użytkownicy – stawianie murów pomiędzy nimi powoduje jedynie wzrost złożoności i zwiększoną ilość problemów.

Cały ruch Agile czy metodyki takie jak Scrum, XP, Crystal heroicznie walczą z podziałami i sprowadzają się do zapewnienia odpowiednich interakcji pomiędzy ludźmi wytwarzającymi oprogramowanie. W efekcie powstają produkty wysokiej jakości.

Dlatego proszę oprócz fizycznych, technicznych i psychologicznych barier usuńmy też wszelkie inne spory i kłótnie. Męczą mnie już dyskusje na temat tego jakie testy powinien pisać/wykonywać tester a jakie programista? Czy to  na prawdę ma znaczenie?! Jeśli będziemy pracować razem, to prawdopodobnie osiągniemy dużo lepsze rezultaty. Co złego się stanie jeśli programista siądzie w parze z testerem i razem coś zakodują, albo przetestują?

Testowanie (czy to manualne, czy automatyczne) jest nieodłącznym elementem programowania. Bez testowania (jakiegokolwiek) oprogramowanie najprawdopodobniej nigdy by nie powstało. Bez programowania nie było by co testować. Cała idea inkrementalnego wytwarzania oprogramowania opiera się o nie dzielenie procesu wytwarzania oprogramowania na testowanie i kodowanie – robimy te rzeczy równolegle i ciągle.

Pisanie testów automatycznych jest równoznaczne z tworzenie tzw. kodu produkcyjnego. Gdy byłem na szkoleniu z Clean Code u Uncle Bob’a (Robert C. Martin) z wielkim oburzeniem mistrza spotkało się moje stwierdzenie, że rzadko tworzę kod produkcyjny, gdyż zajmuję się głównie automatyzacją testów. Testy automatyczne są kodem produkcyjnym – często dużo ważniejszym i bardziej wartościowym niż kod funkcjonalności aplikacji.

Nie stawiajmy więc sztucznych barier pomiędzy testowaniem a programowaniem – obydwie te czynności mają na celu dostarczenie produktu wysokiej jakości i na tym powinniśmy się skupić.

2 komentarze więcej...

Jakość to tylko efekt motywacji

opublikowany przez 11, Lip, 2012, w kategoriach Agile, Praca, Programowanie, Testowanie, Zarządzanie

Po raz kolejny zadaje sobie (i wszystkim na około) pytanie: czym tak na prawdę jest jakość? Jakość w oprogramowaniu ma wiele wymiarów, pisałem już o tym kilka razy. Bez względu jaką definicję jakości wybierzemy to problem z tym jak tą jakość zapewniać pozostaje niemal niezmienny.

Próby wprowadzania tzw. „metryk jakości” dają jakieś efekty – ale czy to jest zapewnianie jakości? Prędzej to „zapewnianie” ogranicza się do reagowania w sytuacjach, gdy jest już na prawdę źle – za późno na zapewnianie jakości. Może spróbujmy zadać sobie pytanie skąd w takim razie bierze się jakość?

Wielokrotnie zastanawiając się nad kluczowymi czynnikami wpływającymi na jakość produktu dochodziłem do jednego wniosku – podstawą w procesie zapewniania jakości są ludzie. Nie mówię tutaj o specjalistach QA czy testerach, bo szczerze powiedziawszy oni akurat mają wbrew pozorom stosunkowo niewielki wpływ na jakość. Jakość jest implementowana od samego początku projektu i jest implementowana przez wszystkich ludzi, którzy w tym projekcie biorą udział. Idąc tym tropem można by wyciągnąć wniosek, że kluczowym elementem zapewniania jakości w oprogramowaniu jest zatrudnienie odpowiednich osób, które będą o jakość dbać na każdym kroku oraz danie tym osobom możliwości zapewniania jakości. Proste!

Nie do końca… Bob Marshall wysunął ostatnio teorię, że pierwotną przyczyną implementowania błędów w oprogramowaniu jest brak motywacji ludzi to oprogramowanie wytwarzających. Jeśli się temu bliżej przyjrzymy to bez problemu możemy przyznać mu rację.

Poniżej kilka standardowych powodów występowania błędów:

  • brak wiedzy programistów – tak technologicznej jak i domenowej,
  • niekompletne wymagania,
  • problemy komunikacyjne,
  • zbyt mało czasu,
  • inne problemy.

Spróbujmy przyjrzeć się każdemu z powyższych i zastanowić się jaki wpływ na uniknięcie takich błędów ma motywacja.

Brak wiedzy programistów (i innych osób zaangażowanych w projekt) – w rezultacie powstaje sporo błędów na poziomie implementacji. Dlaczego programiści nie posiadają wystarczającej (wystarczającej do zminimalizowania ilości implementowanych błędów, a nie do zaimplementowania funkcjonalności) wiedzy? Ja nie mam z tym większego problemu – jeśli czegoś nie wiem, albo nie jestem pewien to sprawdzam tak, by mieć pewność, że to co robię będzie najwyższej jakości. Spowodowane jest to wysoką motywacją do tego czym się zajmuje. Jeśli człowiek przychodzi do pracy po to by odsiedzieć swoje 8h i w tym czasie tylko zakodować to co od niego wymagają, a później najlepiej o tym zapomnieć, to ciężko tutaj mówić o zmotywowanym pracowniku. Znam co najmniej kilku programistów, w których kodzie na prawdę rzadko zdarzało nam się znajdywać błędy. Spowodowane było to pewnym perfekcjonizmem i motywacją do ciągłego rozwijania się i robienia rzeczy coraz lepiej. Nawet jeśli już udało nam się znaleźć błąd to szanse na to by podobny błąd został przez tą osobę w przyszłości zaimplementowany były wręcz zerowe. Niestety znam też „programistów”, którym 10 prawie identycznych błędów zdarzało mi się zgłosić w ciągu miesiąca pracując z nimi równolegle. To właśnie brak motywacji do nauki, zdobywania wiedzy, czy nawet uczenia się na własnych błędach jest główną przyczyną powstawania błędów i tworzenia bylejakości.

Niekompletne wymagania – to lubię, nie pamiętam ile razy już słyszałem: „to nie nasza wina, dali nam takie wymagania, od początku wiedzieliśmy, że to się nie uda, ale teraz mają to co chcą, więc w czym problem”. Pierwsze podstawowe pytanie: skoro wiedzieliście, że wymagania są złe, niekompletne, albo nie byliście pewnie o co tak na prawdę w nich chodzi to dlaczego nie poszliście do osób, które te wymagania tworzyły, albo tych dla których ten produkt tworzycie i nie zapytaliście ich o co tak na prawdę chodzi, lub nie przekonaliście ich do tego, że to nie ma sensu? Brak motywacji i wiążącego się z nią poczucia odpowiedzialności za produkt jest przyczyną tego, że tworzymy rzeczy źle, albo nawet złe rzeczy.

Problemy komunikacyjne – jak często zdarza się Wam wysłać maila z pytaniem do kogoś w tym samym pomieszczeniu (tudzież w zasięgu 50 metrów od Was)? Dlaczego tak jest? Dlaczego nie wstaniecie i nie podejdziecie do tej osoby by przedyskutować problem, zadać pytanie, wspólnie coś stworzyć – bez błędów, niedomówień, oraz czasu straconego na oczekiwanie na odpowiedź. Prosta zasada – nie po to mamy dwie nogi by 8h dziennie siedzieć przykutym do biurka! Znowu kwestia motywacji do tego by jak najlepiej i najszybciej wykonać zadanie – no bo po co skoro, można wysłać maila i czekać 2h na odpowiedź – w tym czasie można zrobić przecież tyle ciekawych rzeczy, jak przeglądanie facebooka, zakupy przez internet, czatowanie z sekretarką, i co tam jeszcze wymyślicie – ważne, że takie oczekiwanie przybliża nas do [tu wstaw „godzina przyjścia do pracy” + 8h]. To najprostszy przykład problemów komunikacyjnych. Oczywiście można by znaleźć ich znacznie więcej, ale każdy z nich można rozwiązać łatwiej bądź trudniej – pozostaje jedynie kwestia motywacji do tego by to zrobić. Kolejny problem to przekładanie relacji osobistych ponad relacje zawodowe – mi też się to wiele razy zdarzało i dopiero z perspektywy czasu mogę stwierdzić, jak bardzo wpływało to negatywnie na projekty, nad którymi pracowaliśmy. Będąc (stając się) profesjonalistą, dobrze zmotywowanym profesjonalistą uczymy się radzić sobie także z takimi problemami.

Zbyt mało czasu – w zasadzie powinienem pozostawić to bez komentarza, bo mamy już rok 2012 i powszechnie wiadomo na całym świecie, że nie robienie rzeczy szybciej oznacza robienie ich gorzej co w efekcie skutkuje poświęceniem większej ilości czasu na poprawki i ostatecznie okazuje się być znacznie dłużej niż początkowo planowano. A gdzie tu motywacja? Przede wszystkim to od nas zależy czy będziemy wystarczająco zmotywowani do tego by powiedzieć „NIE!”, gdy ktoś wymaga od nas implementowania bylejakości na wczoraj. Pisałem już o tym kilka razy – rynek pracy w branży IT jest teraz tak szeroki, że nie ma najmniejszego problemu ze zmienieniem pracodawcy, gdy obecny nam nie odpowiada. Umiejętność mówienia nie staje się coraz bardziej pożądaną cechą dobrego pracownika IT.

Inne problemy – jakiekolwiek przyczyny powstawania błędów w oprogramowaniu znajdziecie i wymienicie, powinniście zadać sobie pytanie dlaczego jeszcze tych przyczyn nie usunęliście i nie rozwiązaliście problemów? Wiem, fajnie jest narzekać i czekać, aż może ktoś coś zrobi ale dużo trudniej jest samemu wstać z miejsca i rozwiązać problem. Zawsze znajdzie się milion powodów przez które „nie da się”, pytanie tylko czy na prawdę się nie da i czy chociaż próbowaliście?

Zatem pozostaje temat jak motywować pracowników (pytanie, które słyszę prawie na każdej konferencji i szkoleniu) – prosta odpowiedź: Nie da się! Jedyne co możemy zrobić to stworzyć odpowiednie środowisko, w którym ludzie będą mogli być zmotywowani i czuć, że to co robią ma sens oraz jest częścią czegoś większego. Najważniejsze to nie przeszkadzać i nie niszczyć motywacji (co jest bardzo trudne). Kolejne wymaganie to zatrudnienie odpowiednich – zmotywowanych ludzi (tutaj też uwaga, bo de-motywacja jest  dużo bardziej zaraźliwa niż motywacja).

Powyższy post został zainspirowany rozmową z Bobem Marshallem oraz artykułem: „Bugs are a signal„, który wszystkim polecam!

1 komentarz więcej...

Dlaczego automatyzujemy testy?

opublikowany przez 21, Cze, 2012, w kategoriach Agile, Automatyzacja, CI, Programowanie, Testowanie, XP

Mamy różne rodzaje testów. Jeśli chodzi o testerów to najczęściej zajmują się oni automatyzacją testów funkcjonalnych GUI czy też testami typu end-to-end.

Warto się zastanowić po co tworzymy takie testy automatyczne? Jeśli robimy to wyłącznie by przyspieszyć testowanie, to nie jest to najlepsza odpowiedź. Celem tworzenia takich testów powinno być poprawianie jakości – może nie bezpośrednio ale ogólnie testy automatyczne powinny przyczyniać się do poprawy jakości. Robię to poprzez dostarczanie szybkiej – dużo szybszej niż tester manualny informacji zwrotnej na temat działania produktu, a przede wszystkim na temat tego czy programista wprowadzając zmiany niczego nie zepsuł. Jest to niezwykle istotne zwłaszcza, gdy mamy do czynienia z systemami typu legacy – kaszana bez wyraźnej, przejrzystej architektury i testów jednostkowych. Systemy tego typu maja to do siebie że bardo trudne, o ile wręcz niemożliwe jest przetestowanie ich przy użyciu testów jednostkowych. Tworzenie unit testów do już istniejącego kodu, napisanego przed testami jest bardzo czasochłonne (swoją drogą to jeden z powodów dla którego niektórzy mówią, że pisanie testów jest strasznie kosztowne i czasochłonne). Kod który nigdy nie był pisany z myślą o testach jednostkowych, które będą go testowały często jest po prostu nietestowalny.

By móc poprawiać jakość naszego produktu musimy być w stanie poprawiać kod i jego jakość. Niestety bez szybkiej informacji na temat tego czy kod działa  – na przykład w postaci unit testów nie mamy nigdy pewności czy nasze zmiany niczego nie popsują, a co za tym idzie brakuje nam  odwagi by cokolwiek zmieniać i poprawiać. Pętla się zamyka – nie możemy zmienić nie testowalnego kodu tak by był testowalny bez obawy o to, ze czegoś nie popsujemy. Błędne koło się zamyka a dług technologiczny ciągle rośnie.

Jednym ze sposobów jest wdrożenie testów typu end-to-end które traktują testowany system jak „black box” lub „gray box”, do którego mają dostęp tylko w odpowiednich miejscach. Takie testy mają niestety kilka wad – na przykład są wolne i trudne w utrzymaniu.

Powyższe problemy to jeden z wielu powodów stosowania w projektach tzw. piramidy testów, która zakłada, że będziemy tworzyć jak najwięcej testów jednostkowych, trochę mniej testów funkcjonalnych i akceptacyjnych, a testów typu end-to-end nie będziemy tworzyć wcale, lub będą to tylko skrajne przypadki.

Takie podejście sprawdza się idealnie, rozpoczynamy projekt od zera i od samego początku postępujemy według wyżej wymienionych zasad. Niestety rzeczywistość jest inna. Na początku projektów informatycznych mało kto przejmuje się automatyzacja w ogóle, o testach jednostkowych i TDD już nawet nie wspomnę. Testy automatyczne wdraża się przeważnie dopiero, gdy zaczyna się już robić na prawdę niedobrze, a dług technologiczny daje o sobie znać na każdym kroku. W ten sposób powstają właśnie systemy typu legacy.

Gdy kilka miesięcy temu na konferencji 33rd degree podczas jednej z prezentacji Uncle Bob powiedział coś w stylu: „Nie piszcie testów end-to-end – one są złe”, a ja zobaczyłem bezmyślnie przytakujące głowy setek programistów siedzących na sali pomyślałem sobie: „Cholera – ostatnie 2 lata prowadzonej przez nas indoktrynacji w dziedzinie automatyzacji testów w naszym kraju właśnie trafił szlag…”. Miałem o to spory żal do Bob’a, który zresztą na niego wylałem w postaci bardzo długiej dyskusji na temat legacy code etc. Bob oczywiście na myśli miał projekty typu green-field, gdzie zaczynamy od zera. Oczywiście bardzo dobrze, że skorzystał ze swojego autorytetu i może przynajmniej kilka osób do tego przekonał, dzięki czemu w przyszłości będzie znacznie mniej systemów przepełnionych legacy code. Ale co z projektami, które już istnieją i które nadal trzeba rozwijać? To właśnie w takich projektach pracuje większość testerów (domyślcie się dlaczego).

Łatwo znaleźć rozwiązanie dla systemów już istniejących, gdy uświadomimy sobie, że celem testowania nie jest tylko testowanie samo w sobie ale też poprawa jakości. Podstawowym celem wdrożenia testów automatycznych jest zapewnienie możliwości wprowadzania bezpiecznych zmian – podobnie jak celem testów regresyjnych (które przypadkiem powstają przy wdrożeniu automatyzacji) jest dostarczenie informacji zwrotnej na temat tego, czy nasze zmiany nie wprowadziły błędów w istniejącej już funkcjonalności. Aby móc cokolwiek zmieniać tworzymy takie testy które dadzą nam przynajmniej ogólna informację na temat tego czy funkcjonalność która zmieniamy nie uległa popsuciu z punktu widzenia użytkownika.

W skrócie tworzymy odwróconą piramidę testów – z dużą ilością testów end-to-end i funkcjonalnych. Dzięki temu możemy zmieniać kod aplikacji i poprawiać jego jakość (refaktoryzować, zmieniać architekturę etc.) sprawiając, że staje się on testowalny także na niższych poziomach. Za każdą zmianą idzie dopisywanie nowych testów jednostkowych (a nawet to zmiany sterowane są pisaniem testów jednostkowych jak w TDD). Po pewnym, czasie mamy testowalny system z przejrzystą architekturą, w której każdą warstwę możemy przetestować oddzielnie, a GUI i logika w nim ograniczone są do minimum. To jest dobry moment by zacząć pozbywać się naszych testów typu end-to-end. Tak! Właśnie tak! Cały czas tworzyliśmy testy typu end-to-end z myślą o tym, że za chwilę je usuniemy. Największym kosztem podczas utrzymywania testów są duplikacje – więc jeśli tworzymy testy jednostkowe, które w przybliżeniu testują to samo co nasze testy end-to-end to oczywistym staje się potrzeba usunięcia tych, które są bardziej kosztowne i mniej wartościowe – end-to-end. W ten sposób stopniowo obracamy naszą piramidę testów i zaczyna ona powoli wyglądać tak jak powinna.

Celem całej naszej pracy nie jest zwiększenie pokrycia testami – co w podanym przykładzie mogło by doprowadzić do pokrycia nawet powyżej 100% (oczywiście zależy jak liczonego) – pytanie czy taka metryka cokolwiek nam mówi poza tym, że straciliśmy dużo czasu? Prawdziwym celem jest poprawa jakości, jakości na najniższym poziomie, zapewnienie poczucia bezpieczeństwa podczas wprowadzania zmian, wydzielenie odpowiednich modułów i domen w naszej aplikacji, odseparowanie modelu o danych, logiki od interfejsu użytkownika, itd.

Powyżej opisałem jeden (jak dotąd z pośród sprawdzonych przeze mnie w praktyce, jedyny działający) z kilku sposobów radzenia sobie z długiem technologicznym.

4 komentarze więcej...

Znalazłem wąskie gardło – i co dalej?

opublikowany przez 03, Lut, 2011, w kategoriach Agile, Programowanie, Testowanie, Zarządzanie

Bardzo często na wszelkiego rodzaju szkoleniach z metodyk i zarządzania projektami mówi się o tak zwanych wąskich gardłach, niestety bardzo rzadko ktokolwiek wspomina o tym co należy zrobić, gdy takie wąskie gardło już znajdziemy.
Żeby lepiej ugryźć ten temat przeanalizujmy potencjalny sposób przyspieszenia prac w projekcie – próba zwiększenia efektywności na każdym z etapów wytwarzania oprogramowania. Wielu managerów skupia się na tym by poszczególne zespoły, członkowie zespołów zwiększały swoją efektywność przez co dążą do zwiększenie efektywności całkowitej pracy nad projektem. Jeśli praca na wszystkich etapach przebiega równomiernie (nie mamy istotnych wąskich gardeł) zwiększenie wydajności w każdym etapie spowoduje zasadnicze przyspieszenie prac w całym projekcie. Niestety wystarczy już jedno wąskie gardło by pomimo zwiększenia efektywności na wszystkich innych etapach skutecznie spowolnić pracę w całym projekcie (zakładając względnie równomierny wzrost efektywności na każdym etapie, zwiększenie efektywności na etapie będącym wąskim gardłem niczego nie zmieni, gdyż nadal będzie to wąskie gardło).

Zastanówmy się może skąd się biorą wąskie gardła. Najczęstszą przyczyną powstawania wąskich gardeł jest niedobór zasobów (pracowników, technologi, wiedzy) na jednym z etapów projektu i/lub nadmiar w innych częściach zespołu/projektu. Niektóre zadania po prostu wymagają znacznie więcej czasu niż inne – np. wymyślenie i zaimplementowanie skomplikowanego algorytmu szyfrującego jest trudniejsze i bardziej czasochłonne niż zdefiniowanie wymagań dla takiego algorytmu.

Istnieje wiele różnych sposobów wykrywania wąskich gardeł, jednym z nich jest np. tablica kanbanowa z wprowadzonymi limitami zadań znajdujących się w poszczególnych fazach produkcji. Różne inne sposoby monitoringu, nadzoru pracy, monitorowania postępów, mierzenia czasu pracy etc. także bywają pomocne przy lokalizowaniu wąskich gardeł.

Dobrze dajmy na to, że już znaleźliśmy wąskiego gardło:
Załóżmy że mamy zespół składający się z 4 programistów i jednego testera. Zastosowaliśmy tablicę kanbanową z limitami odpowiedni 4 zadania w develompencie i 1 zadanie w fazie testowania w tym samym czasie (przydział naturalny – badania pokazują, że ludzie są najefektywniejsi gdy pracują nad jednym zadaniem – jednowątkowo). Okazuje się, że programiści (jako zespół) znacznie szybciej kończą swoje zadania niż tester jest w stanie je przetestować. Średnio czas zaprogramowania funkcjonalności okazał się dwukrotnie dłuższy niż czas jej przetestowania co w efekcie spowodowało, że tester miał dwa razy więcej zadań niż mógł przetestować.
Pobawmy się w dosyć śmieszną pseudo matematykę, żeby lepiej zobrazować problem.

Na tym etapie dokonano pewnych zmian, które miały na celu zwiększyć wydajność pracy każdego z członków zespołu o 50% – wdrożenie się udało. Zobaczmy więc jak wygląda sytuacja po zwiększeniu efektywności. Dzięki temu rozwiązaniu teraz tester mógł przetestować trzy zadania w tym samym czasie co wcześniej dwa, niestety tym samym programiści byli w stanie dostarczyć o połowę więcej zadań do testów niż poprzednio przez co wąskie gardło nadal pozostało wąskim gardłem.

Poszukajmy więc alternatyw…
Niestety mamy ograniczony budżet i nie możemy pozwolić sobie na zatrudnienie większej liczby osób.
Widzimy, że mamy za dużo programistów a za mało testerów, może więc powinniśmy jednego z programistów w razie potrzeby wykorzystywać jako testera, chwilowo zmniejszy to ilość dostarczanych funkcjonalności i tym samym pozwoli na przyspieszenie etapu testowania – wąskie gardło będzie odrobinę szybsze, może nawet całkowicie zniknie – super – udało się. Ale zaraz, teraz jeden z programistów stał się testerem – coś tu jest nie tak – przecież płacimy temu gościowi za programowanie a nie za testowanie, on sam pewnie też to dosyć szybko zauważy i zapewne jego morale spadną, a w rezultacie może nawet zmieni pracę bo nikt nie chcę pracować dla pracodawcy, który nie wywiązuje się z zawartych umów, a w jego umowie jasno było napisane, że jest programistą a nie testerem. (evil: A niech się zwalnia – w jego miejsce zatrudnimy testera 😉
Kolejnym sposobem na zlikwidowanie wąskiego gardła mogło by być spowolnienie pracy programistów. TAK – SPOWOLNIENIE! Ale jak to?! Przecież w zarządzaniu chodzi o zwiększanie efektywności, przyspieszanie, dostarczanie produktu na czas etc. Otóż nie zawsze, efektywność okazuje się być bez znaczenia w miejscach nie będących wąskim gardłem [Cockburn 2008]. Jeśli już mamy wąskie gardła, to zwiększenie efektywności w innych miejscach w niczym nam nie pomoże, wręcz przeciwnie może spowodować jeszcze większe straty np. wzrost frustracji testerów spowodowany nadmiarem zadań i nierealnymi terminami, konflikty pomiędzy testerami a resztą zespołu spowodowane naciskami ze strony tych drugich na szybsze wykonywanie zadań testerskich, mniejsza dokładność testów w celu przetestowania większej ilości funkcjonalności itd.

Co zatem należy zrobić?
Jeśli mamy już sytuację jak opisaną powyżej to warto zastanowić się nad tym dlaczego praca testerów zajmuje tyle czasu i co zrobić by ją przyspieszyć. Żeby przeanalizować ten problem trzeba by sięgnąć do korzeni – po co jest testowanie? Testowanie służy odnalezieniu błędów. Dlaczego testujemy? Testujemy, gdyż zakładamy że dostarczona funkcjonalność zawiera błędy. Z powyższej toku myślowego wynika, że jednym ze sposobów rozwiązania problemu wąskiego gardła z powyższego przykładu mogło by być dostarczanie do testów funkcjonalności o wyższej jakości. Jak to zrobić? Sposobów jest wiele – począwszy od dbania o jakość od samego początku np. poprzez zastosowanie TDD co także zwiększy pokrycie kodu testami automatycznymi dzięki czemu zmniejszy się czas testów regresyjnych, skończywszy na poświęceniu większej uwagi planowaniu i zrozumieniu wymagań przez programistów, czy też zastosowanie wielu innych dobrych praktyk programistycznych takich jak na przykład Code Review. Zastosowanie któregoś z powyższych rozwiązań niesie ze sobą podwójne korzyści: programiści muszą poświęcić więcej czasu na pisanie testów, planowanie, analizę, dzięki czemu wąskie gardło testerskie nie zapycha się, a także wzrasta jakość kodu i funkcjonalności, przez co zmniejsza się ilość poprawek i re-testów, dzięki czemu tester ma więcej czasu. Kolejnym bardzo ważnym aspektem takiego rozwiązania jest także wzrost zaufania testerów do produktów dostarczanych przez programistów (czasem bywa to zgubne, niemniej jednak w większości przypadków skutkuje polepszeniem atmosfery, lepszą komunikacją i ostatecznie większą ilością sukcesów).

Powyższy opis problemu i propozycja jego rozwiązania dotyczyły wąskiego gardła na etapie testowania, ale zasada jest dosyć ogólna – nie należy zwiększać efektywności w miejscach które nie są wąskimi gardłami (może to np. dotyczyć sytuacji gdy 7 programistów okupuje jednego DBA – wtedy też należy programistów zmusić do przeprowadzania analizy problemów po ich stronie, a do DBA kierowania tylko próśb o podjęcie ostatecznych decyzji w rozpracowanych wcześniej problemach, lub próśb o pomoc w sytuacjach krytycznych). Oczywiście jeśli nie ma wąskich gardeł, lub wszystkie zlikwidowaliśmy możemy dalej pracować nad równomiernym wzrostem efektywności pamiętając o tym by nie stworzyć kolejnych newralgicznych punktów w naszym procesie.

Warto też pamiętać o wąskich gardłach przy budowaniu budżetu projektu, czy też zatrudnianiu nowych pracowników.

3 komentarze więcej...