blog.testowka.pl

Archiwum wiadomości z Lipiec, 2012

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