blog.testowka.pl

Kolejny post o metrykach – w odpowiedzi na pytania

opublikowany przez 20, Wrz, 2013, w kategoriach Agile, Testowanie, Zarządzanie

4324373384_a4c0d68189_z

We wczorajszej notce nawiązałem do wpisu na testerzy.pl dotyczącego mierzenia jakości pracy testera.

Dla mnie jedyną z pozoru sensowną metryką spośród wspomnianych w artykule z odnośnika wydaje się być mierzenie stosunku ilości błędów, które wyszły na produkcję do tych, które zostały wykryte – niemniej jednak w ten sposób nie mierzymy efektywności testerów tylko raczej ich nieefektywność.

O metrykach wszelkiego rodzaju wspomniałem już w książce „Mity i problemy w Agile”. Nie zrozumcie mnie źle, nie uważam, że wszystkie metryki są bezwartościowe. Uważam, że niektóre z nich są bez sensu, a inne powodują większe szkody niż dostarczają wartości.

Zawsze, gdy ktoś atakuje mnie metryką zadaje proste pytanie po co chce daną rzecz mierzyć? O ile pytanie jest proste z odpowiedzią na nie bywa już różnie. Przeważnie okazuje się, że albo zamierzony cel jest bez sensu, albo można go osiągnąć w inny, mniej bolesny i kosztowny sposób.

Tak, mniej kosztowny! Metryki są kosztowne! „Ludzie zawsze robią to co jest w nich wzmacniane” – to podstawy psychologii i socjologii. Metryki są wzmocnieniem. Jeśli wzmacniamy w testerach potrzebę raportowania jak największej ilości błędów to wkrótce utoniemy pod sterami raportów, dla których będziemy musieli opracować nowe metody zarządzania defektami. Gdy, zaczniemy mierzyć ilość błędów na produkcji, to strach przed wydaniem stanie się na tyle paraliżujący, że na pytanie o jakość produktu testerzy zawsze będą odpowiadać, że jest niewystarczająca. Takie informacje są bezwartościowe dla każdego managera – nawet Test Managera.

W odpowiedzi na poprzedni wpis na blogu Radek z testerzy.pl napisał.

Dzięki za wspomnienie naszej publikacji.
Warto dodać, że sam wspomniałeś, że środowisko Agile i małe projekty to środowisko „normalne”. Nie odpowiadasz na podstawowe pytanie.
Co ma zrobić tester / kierownik testów, kiedy pracuje w „nienormalnym” (w twojej opinii) środowisku, a jego wpływ na metody wytwarzania oprogramowania, technologie, wielkość produktu jest żaden? Ma zmienić pracę i pójść do organizacji z wdrożonym Agile?
Czy instytucja bankowa, która kupuje całościowy system wsparcia działania ma uruchamiać drobne funkcjonalności? Jakby w takimi wypadku wyglądał i ile by trwał start AliorBanku?
Jak wyobrażasz sobie, że osoba z 40 letnim doświadczeniem biznesowym, Pani Halina z księgowości (bez świadomości modeli wytwarzania oprogramowania) usiądzie z programistą w jednym zespole i razem coś zbudują? A co jeśli takich osób trzeba zaangażować 40?

Zadane przez Radka pytania są bardzo trafne, dlatego zdecydowałem, że zasłużyły sobie na osobny wpis na blogu.

Moje odpowiedzi poniżej:

Warto dodać, że sam wspomniałeś, że środowisko Agile i małe projekty to środowisko „normalne”. Nie odpowiadasz na podstawowe pytanie.
Co ma zrobić tester / kierownik testów, kiedy pracuje w „nienormalnym” (w twojej opinii) środowisku, a jego wpływ na metody wytwarzania oprogramowania, technologie, wielkość produktu jest żaden? Ma zmienić pracę i pójść do organizacji z wdrożonym Agile?

W sumie zastanawiam, się czy normalne to dobre słowo? W końcu normalne to nie odbiegające od normy. Jeśli za normę przyjmiemy większość tego co dzieje się na świecie to… nie – projekty Agile nie są normalne! Natomiast jeśli weźmiemy pod uwagę zdrowy rozsądek…

Jak napisałem wczoraj Waterfall działa świetnie dla „dużych projektów”. I to wcale nie był sarkazm. Waterfall działa tam naprawdę dobrze. To znaczy tak dobrze jak jest to w takim środowisku możliwe. Nie widzę żadnego sensu w jakichkolwiek porównaniach Waterfall do Agile.

Oczywiście za chwilę pojawi się pytanie czy w takim razie można w ogóle przekształcić Waterfallową organizację w organizację Agile? Tak, można – jest to trudne i wymaga wielu zmian, na wielu poziomach. Dotyczy to również zmian w tworzonych produktach i w sposobie tworzenia tych produktów.  Często zmiana sposobu ich tworzenia sama sprawia, że produkty ewoluują we właściwym kierunku samoczynnie – jednak chyba lepiej to robić świadomie.

Co ma zrobić taki tester/kierownik testów w opisanej sytuacji? Ludzie są różni – niektórym (myślę, że wielu z nas) odpowiada stabilna praca w miarę niezmiennym środowisku, gdzie jesteśmy odpowiedzialni tylko za swoją działkę. W takim środowisku można dalej się uczyć, rozwijać swoje umiejętności, zwiększać jakość swojej pracy etc. Jednak czasem można (tak jak ja kilka lat temu) dojść do miejsca, w którym dostrzegamy nowe, większe możliwości. Jakość oprogramowania nie zależy od testerów – nie tylko od testerów. Więc albo możemy się oszukiwać i udawać, że stoimy jako testerzy na straży jakości nie mając tak naprawdę na nią zasadniczego wpływu, albo pogodzić się z tą rzeczywistością i dzięki starannej kontroli jakości dostarczać jak najbardziej obiektywne informacje o jakości do osób decyzyjnych. W ten sposób również możemy stać się mistrzami w swoim fachu.

Możemy też iść całkowicie inną drogą i faktycznie zmienić pracę na taką w której będziemy mieli na jakość wpływ. Często będzie wymagało to od nas zdobycia wiedzy znaczenie szerszej niż ta z obszaru testowania oprogramowania. To wszystko jest kwestią indywidualną.

Czy instytucja bankowa, która kupuje całościowy system wsparcia działania ma uruchamiać drobne funkcjonalności? Jakby w takimi wypadku wyglądał i ile by trwał start AliorBanku?

Jeśli taka instytucja chce mieć oprogramowanie, które na prawdę będzie odpowiadało ich wymaganiom to tak, powinna pracować inkrementalnie. Ba, znam kilka przykładów instytucji bankowych czy nawet międzybankowych które dokładnie tak pracują. Kilkadziesiąt (w porywach do 100) osób pracujących nad systemem do transakcji międzybankowych i ani jednego testera. Pełna automatyzacja testów, BDD, TDD i jeśli wyjdzie jakiś błąd na produkcje to koszty idą w miliony – jeszcze raz – nie ma tam testerów!

Jak wyobrażasz sobie, że osoba z 40 letnim doświadczeniem biznesowym, Pani Halina z księgowości (bez świadomości modeli wytwarzania oprogramowania) usiądzie z programistą w jednym zespole i razem coś zbudują? A co jeśli takich osób trzeba zaangażować 40?

Zdarzyło mi się pracować kilka razy z takim właśnie „Paniami Halinami” i teraz jestem już przekonany, że właśnie jak najczęstsze pokazywanie im działającego produktu jest jedynym sposobem na zrealizowanie prawdziwych wymagań co do tego produktu. Pani Halina nie rozumie pojęć typu formularz, nie wie co to jest checkbox ani radiobutton, nie ma pojęcia o AJAXie, etc.

Gdy pokażę Pani Halinie produkt z formularzem to dowiem się, że dla niej jest to formatka, a pokazując listę rozwijalną dowiem się, że chodziło o checkboxy, bo można wybrać kilka opcji a nie jedną. Tego dokumentacja nie przewidziała, bo dokumentacja jest kolejną abstrakcją, która nie dość, że jest niezrozumiała dla programistów to jeszcze nie jest zrozumiała dla Pani Haliny.

Na szczęście jako ludzie, od dziecka kształcimy nasze zdolności komunikacji – potrafimy nawet porozumieć się z ludźmi nie mówiącymi w naszym języku, głównie poprzez pokazywanie przykładów i wizualizacje. Właśnie dlatego każdy programista czy tester, nawet ten najbardziej introwertyczny lepiej dogada się z Panią Haliną niż zrozumie dokumentację.

Świadomość istnienia modeli wytwarzania oprogramowania jest tutaj zbyteczna zarówno u Pani Haliny jak i nawet u programistów i testerów. Opieramy się na podstawowym założeniu, że interakcje pomiędzy ludźmi (ludźmi o zróżnicowanej wiedzy) są lepsze niż jakiekolwiek procesy i narzędzia.

A co jeśli trzeba zaangażować 40 takich osób jak Pani Halina? A trzeba? Czy na pewno? Nawet jeśli to czemu nie – zdarzało mi się robić Sprint Review na którym było około 25 gości z poza IT. Bardzo ciekawe i produktywne dyskusje się tam odbywały. Oczywiście na końcu był jeden Product Owner, który decydował o tym, co jest najważniejszy w danym momencie niemniej jednak wkład od wszystkich gości i innych stakeholderów był znaczący w ciągły rozwój produktu.

Wracając do metryk – według drugiej strony Manifestu Agile jedyną miarą postępu pracy jest działające oprogramowanie. Ja dodam od siebie, że tą miarą jest działające oprogramowanie, które ma sens. Pamiętajcie o zasadzie Pareto – 80% wartości jest generowana przez 20% funkcjonalności.

„Duże projekty” to problem, co ładnie obrazuje podsumowanie CHAOS Report (strona 13 – dla tych co się im nie chce czytać całości). To są twarde dane – oczywiście zawsze znajdą się wyjątki, ale jednak…

W sumie może powinienem napisać o tym jak w takim razie zmienić „duży projekt” w wiele małych?


5 Comments for this entry

  • Kamil

    Mierzenie jakości pracy testera jest na pewno trudne. Ale z pewnością da się wszystko jakos określić. Może najlepiej właśnie jest robić tak, żeby skupić się na popełnianych przez nich błędach…

  • Radek

    Dzięki za długi wpis. Nie odpowiada on na zadane pytania. Twoje przekonanie, że Agile byłby w stanie zmienić organizację, projekt, mentalność i przyzwyczajenia „Pani Haliny” itp. można zamknąć w skrzynce z pobożnymi życzeniami. Trzeba jednak zejść na ziemię i dotknąć rzeczywistości projektowej.
    Wiem, że jeśli spróbujemy namówić fanatyków do rezygnacji ze swoich błędnych przekonań, jeśli bogaci oddadzą swoje bogactwo biednym, a wszyscy zrezygnujemy z emisji spalin to świat będzie lepszy, bezpieczniejszy i wszystkim będzie lepiej. Jednak RZECZYWISTOŚĆ jest inna.

  • streser

    @Kamil:
    Skupianie się na błędach wywołuje strach przed ich popełnianiem. Strach przed popełnianiem błędów zabija kreatywność i innowacje.

  • streser

    @Radek:
    Przeczytałem jeszcze raz pytania i swoje odpowiedzi. Nie wiem jaką odpowiedź chciałbyś usłyszeć – że masz racje? Że „rzeczywistość” jest taka jak ją opisujesz? I że taka jest wszędzie i dokładnie taka MUSI być? To smutne jeśli faktycznie tak myślisz, smutne jeśli inni też tak myślą…

    Jak pisałem, akurat od Pani Haliny nikt nie oczekuje żadnych zmian czy poszerzania wiedzy, nikt od niej tego nie wymaga. To raczej od developerów wymaga się by spróbowali zrozumieć domenę w której rozwiązują problem zanim bezmyślnie wyklepią coś zgodnego z dokumentacją, co według niej będzie nawet działało. Problem tylko w tym, że to przeważnie nie rozwiązuje problemów…

    Wydaje mi się, że chyba żyjemy w trochę innych rzeczywistościach. Agile już od lat na całym świecie nie jest jak „Yeti” – podobno ktoś je kiedyś widział. Agile to fakt. Agile to RZECZYWISTOŚĆ. Miliony ludzi na całym świecie pracują w ten sposób lub starają się pracować.

    Owszem, aby skostniałe struktury korporacyjne mogły się zmienić potrzeba czasu. Ale właśnie to się dzieje naokoło.

    A co do tego czy Agile może zmienić organizację – nie , organizację zmieniają ludzie, którzy w niej pracują. I to nie jest wyciągnięte ze skrzynki z pobożnymi życzeniami – to dzieje się naprawdę. Sam pomagam wielu organizacjom w tych zmianach i widzę tego efekty.

  • Andy

    „Twoje przekonanie, że automobil byłby w stanie zmienić organizację transportu, działanie miast a także mentalność i przyzwyczajenia „Pana Hieronima” itp. można zamknąć w skrzynce z pobożnymi życzeniami. Trzeba jednak zejść na ziemię i dotknąć rzeczywistości. Automobil to ciekawy wynalazek, ale czyż można sobie wyobrazić iż te śmieszne pojazdy zdolne raptem przewieźć dwie osoby mogłyby zastąpić perszerony ciągnące ciężkie wozy z towarami, dzięki którym w naszych miastach jest żywność i towary? Jak te drogie zabawki dla bogatych miałyby się stać powszechne? RZECZYWISTOŚĆ jest inna. Dlatego zamiast jak fanatycy myśleć o stacjach benzynowych, drogach i oponach trzeba szkolić wozaków i pracować pilnie nad problemem wywożenia z miast końskiego łajna.”

Skomentuj