Jeśli sądzicie, że napiszę, że aby zapewnić jakość aplikacji należy wykonywać testy, przeglądy kodu (de facto to też rodzaj testu, drogi programisto) czy napisać dobry zestaw testów automatycznych, to muszę wyprowadzić Was z błędu. Oczywiście powyższe elementy mają wpływ na jakość produktu, jednak nie to jest najważniejsze. Dlaczego?
Czy testowanie podnosi jakość produktu?
Swego czasu bardzo lubiłem zadawać je na rozmowach kwalifikacyjnych. Zdecydowana większość kandydatów odpowiadała, że oczywiście, testowanie podnosi jakość aplikacji. Bzdura. Testowanie pokazuje błędy czy niedociągnięcia znajdujące się w aplikacji. Ale od samego znalezienia błędów nie podnosi się jakość produktu. Jeśli mamy auto, które nie odpala i nie znamy przyczyny, to czy jeśli dowiemy się o tym, że winien jest rozładowany akumulator to sprawność samochodu się poprawi? Nie. I tak samo jest z testowaniem. Testowanie, to taki przyrząd pomiarowy, którym mierzymy jakość produktu. A czy ona zostanie podniesiona – nie zależy już to od testera.
Testy automatyczne?
Wierzcie mi, że równie szybko jak Wasze testy zaczną wykrywać błędy w aplikacji, tak Waszym oczom ukaże się paradoks pestycydów. Błędy zaczną pojawiać się poza ścieżkami testów automatycznych.
Jak więc zapewnić jakość aplikacji? Gdzie ona jest ukryta, z której szuflady ją wyciągnąć? Odpowiedź jest najprostsza jak tylko może być – jakość jest w Was. Ona siedzi ukryta w każdym członku zespołu. I tylko jeśli zespół jest “świadomy”, posiada niezbędne kompetencje oraz – najważniejsze – współpracuje ze sobą, to tylko wówczas ma szansę na stworzenie produktu dobrej jakości.
Odpowiedzialność zespołu za produkt
Pierwsza kwestia to odpowiedzialność zespołu za produkt. Tak – zespołu. To nie może być architekt, manager czy tester. To musi być cały zespół. Jeśli zespół nie będzie czuł się odpowiedzialny za produkt, jeśli nie będzie to jego “ukochane dziecko”, to ich praca już na wstępie będzie gorzej wykonana niż mogłaby być. Dlatego stworzenie w teamie developerskim poczucia odpowiedzialności i przybliżenie go do produktu jest bardzo ważne. W jednym z zespołów, którego członkiem miałem okazję być, doświadczyłem tego na własnej skórze. Przeszliśmy swego rodzaju transformację, nasz sposób pracy zmieniał się w czasie. Im byliśmy bliżej produktu, im bardziej znaliśmy przesłanki biznesowe i powody różnych decyzji, tym lepszej jakości produkt tworzyliśmy. Co więcej – byliśmy współodpowiedzialni za podejmowanie tych decyzji razem z “tym złym biznesem” – mieliśmy mu pomóc w ich podejmowaniu. Jeśli odpowiedzialność za całość zadania przejmuje jedna osoba, prowadzi to do sytuacji, kiedy zadania przypisywane są developerom i zapewne wykonywane dobrze, ale “od kreski do kreski”. Bez szerszego spojrzenia na aplikację, jej architekturę, konsekwencje przyjętego rozwiązania w przyszłości. Często w ten sposób powstaje dług technologiczny.
Wiedza i transparencja – klucz do sukcesu
Druga rzecz to wiedza. Jak już zasygnalizowałem parę zdań wcześniej – ważne jest to, aby cały zespół i każdy z osobna posiadał całą niezbędną mu do pracy wiedzę. Nie może dochodzić do sytuacji takich jak ta, kiedy jeden z developerów wykonuje np. analizę jakiegoś dodatkowego wymagania od klienta, a cała reszta zespołu o tym nie wie. Po pierwsze – nawet jeśli ten właśnie człowiek jest najlepszym architektem w całej firmie, to czy to oznacza, że podejmie najlepsze decyzje i wybierze najlepsze rozwiązania? Czy to znaczy, że jest alfą i omegą? A czy świeżo zatrudniony developer, jeszcze studiujący, dla którego to jest to pierwsza praca nie może wpaść na lepszy pomysł? Może zna jakieś nowsze technologie czy metodyki, które dany problem pozwolą rozwiązać znacznie wydajniej? A nawet jeśli nie wpadnie na genialny pomysł, to dlaczego nie pozwolić mu w tym procesie uczestniczyć, aby czerpał całymi garściami wiedzę i doświadczenie starszego kolegi? Dalej – czy jeśli zespół nie zna wizji i strategii produktu, to może pracować wydajnie i dobrze? Czy na pewno wszystkie podejmowane decyzje są w takiej sytuacji dobre? Niekoniecznie. Co więcej, pewne zadania będą dla zespołu bezsensowne, nie będą miały sensu. Czy jak pracujesz nad czymś, co nie ma wg ciebie sensu, to dajesz z siebie 100%? Właśnie. Dlatego transparencja jest bardzo ważna. Transparencja jest kluczem.
Teamwork
Bardzo ważna jest relacja między członkami teamu. Jeśli jest on podzielony, tworzą się “grupki wzajemnej adoracji”. No właśnie – czy w takiej sytuacji jest to jeszcze zespół? Tak stworzona grupa współpracowników, nawet złożona z najlepszych profesjonalistów, nie ma szansy wykonać produktu dobrej jakości. Szybko zaczną pojawiać się konflikty, a w konsekwencji atmosfera spadnie poniżej wszelkich oczekiwań. Czy da się efektywnie pracować w takich warunkach? Może i tak, ale koszt emocjonalny będzie ogromny. Kluczową kwestią jest wzajemny szacunek – w stosunku do osób jak i posiadanych przez nie umiejętności. Pracowałem w zespole bez szacunku – wierzcie mi – to nie jest nic przyjemnego. Przychodzisz do pracy i czekasz tylko aż minie osiem godzin. Czy takie warunki wpływają dobrze na Twoją kreatywność? Wręcz przeciwnie – jest to prosta droga do zawodowego wypalenia, kiedy praca wykonywana w “gęstej” atmosferze przestaje przynosić nam satysfakcję. Każdy z nas jest inny, ma inne poglądy, doświadczenia, także te zawodowe. Wzajemny szacunek pozwala nam spojrzeć na te różnice, jak na źródło, z którego możemy czerpać.
Scrum – odpowiedzialność, transparencja, szacunek
Możecie uważać, że nie mam racji – macie do tego pełne prawo. Jednak moje doświadczenia pokazują, że tak właśnie jest – gdzie jest transparencja, gdzie jest szacunek, gdzie jest odpowiedzialność, tam, nawet w niesprzyjających warunkach powstaje wartościowy i dobrej jakości produkt. To oczywiście nie oznacza, że tam, gdzie tych wartości brak, nie powstanie produkt dobrej jakości. Może powstać, ale pewnie będzie rodził się w ogromnych bólach. Odpowiedzialność, transparencja, szacunek. Pisząc te słowa nie odnosiłem się do żadnej metodologii i o niej nie myślałem, ale teraz, kiedy przyszedł czas na podsumowanie i przeczytałem powyższe akapity, zauważyłem, że wymieniłem trzy z wartości, które leżą u podstaw Scruma. Pozostałe wartości pewnie też się między słowami przewinęły. Przypadek? Pewnie nie. Czy to zatem znaczy, że nie ma jakości bez Scruma? Oczywiście, że nie. Mimo to, twórcy wiedzieli na jakich wartościach należy bazować.
