Jakie znaczenie ma jakość oprogramowania

Transkrypcja

Dziś moim gościem jest Andrzej Duś. Andrzej opowie nam o jakości oprogramowania – o tym, czym jest, po co, jak o nią dbać oraz kto jest za nią odpowiedzialny. Andrzeju, dziękuję, że przyjąłeś moje zaproszenie na rozmowę.

Dziękuję, Mateusz, za zaproszenie.

Czy możesz się przedstawić i powiedzieć, co łączy Cię z branżą IT?

Jeśli chodzi obrażę IT, to lubię mówić, że jestem osobą, która urodziła się… to może za dużo powiedziane. Od dziecka z klawiaturą. To jest wpływ mojego ojca, który interesował się elektroniką, naturalnie później komputerami. W latach 90. był to jeszcze ewenement w Polsce.

Kiedyś – gdy byłem jeszcze „wczesnym” nastolatkiem, ojciec sprawił mi książkę o programowaniu w C. Zacząłem się bawić programowaniem i tak już zostało. Zostało to, że skręciłem w stronę zrozumienia systemów operacyjnych, w ogóle rozumienia komputerów. Zaczynałem freelance’ując – to też lata 90., liceum. Przydawały się takie rzeczy: uczeń, który potrafi napisać jakiś program albo coś rozwiązać.

Później na studiach: pierwsza praca na pełnym etacie. Można by więc powiedzieć, że od 15 lat jestem profesjonalnie, regularnie w wytwarzaniu softu. Skręciłem w stronę web developerki, po drodze bawiłem się Androidem. Zawsze miałem pociąg do tego, żeby skupić się szerzej na branży IT, żeby myśleć o tym, jak można dobrze robić oprogramowanie, co to jest oprogramowanie dobrej jakości, jak powinny/mogłyby pracować zespoły, które robią programowanie dobrej jakości.

I teraz jesteśmy tutaj. Pracuję w SYZYGY od ośmiu lat. Praktycznie można by powiedzieć, że przez ten czas firma przeszła wiele ewolucji – jedna firma, a wiele różnych kultur pracy. Dochodzimy do tego miejsca, że jesteśmy tutaj i opowiadam o jakości – bo na tym się po prostu najwięcej skupiam: jak robić rzeczy dobrze.

Co rozumiemy pod pojęciem „jakość oprogramowania”?

To jest bardzo fajne pytanie i można pewnie pójść w różnym kierunku. Moglibyśmy zacząć od definicji akademickiej – mam nadzieję, że słuchacze w tym momencie nie wyłączą nagrania. Mówiąc sucho: poprzez oprogramowanie wysokiej jakości rozumiemy oprogramowanie, które pozwala na łatwe wprowadzanie zmian i szybki rozwój; takie, przy którym nie powstają błędy podczas wprowadzania tych zmian. To taka definicja bardzo „top”, bo ona mówi nam o efekcie: jaki efekt daje nam jakość. Ta definicja daje fajny punkt wyjścia. Można to teraz rozczłonkować na wiele różnych elementów.

Sama jakość kodu, tego, jak kod przyczynia się do spełnienia celu – to jest bardzo ważny element. Można też spojrzeć na to z tej perspektywy, jak oprogramowanie realizuje funkcjonalności, które chce biznes. Bo możemy napisać dobry kod, ale on nikomu nie będzie przydatny. Więc na jakość oprogramowania wpływ ma też element analityczny, zrozumienie tego, jak realizuje ono potrzeby biznesowe i cele przed nim postawione.

Lubię też mówić o tym, że oprogramowanie dobrej jakości to takie, przy którym nam się miło pracuje. W przeciwieństwie do tej twardej suchej definicji, ta jest taka soft. Jeśli my jako programiści, czy w ogóle wszystkie osoby, które pracują przy projekcie odczuwają satysfakcję z pracy nad nim, nie boją się wprowadzać w nim zmian, ekscytują się, kiedy wprowadzają nowe funkcjonalności, nie trzęsą się, że coś się popsuje na produkcji, to pewnie to jest dobra taka softprzesłanka, że robimy oprogramowanie dobrej jakości.

Możemy pewnie wejść głębiej w różne detale tego tematu.

To może zapytam Cię jeszcze o dług techniczny. Mógłbyś przybliżyć, co to jest i czy jest związane z jakością oprogramowania?

Oczywiście. W naszej akademickiej definicji mówiliśmy o możliwości wprowadzania zmian w oprogramowaniu. Dług techniczny powoduje, że tych zmian często nie da się wprowadzić i sprawia, że podczas tego procesu pojawiają się błędy.

Powiedzmy, że piszemy jakiś program. Możemy to zrobić szybko, ale idąc na skróty. Porównajmy to do pożyczki: zamiast długo zarabiać pieniądze i długo pracować, to możemy pieniądze pożyczyć. Ten dług później trzeba oddać. Ten program zrobiony na skróty wróci do nas w postaci długu technicznego. I tak jak pożyczka wraca do nas w postaci rat kredytu z oprocentowaniem, tak ten program wraca jako błędy i większa ilość czasu, jaką musimy poświęcić na wprowadzanie zmian. So far można to pociągnąć, bo gdzieś te miejsca się kończą – generalnie dochodzimy do tego, że w oprogramowaniu, które ma duży dług techniczny, ciężko się wprowadza zmiany. Może trzeba to oprogramowanie przepisywać, wymieniać, wyrzucić. Jakie są potem konsekwencje dla biznesu, to już kwestia indywidualna danej sytuacji, ale mówiąc luźno: takie oprogramowanie po pewnym czasie do niczego się nie nadaje.

To ja może do tej analogii dodam jeszcze, że zazwyczaj jak bierzemy kredyt, to potem musimy spłacić go razy dwa albo nie stać nas na ratę i wtedy jest kompletna klapa. To chyba takie dwie ważne rzeczy związane z długiem technicznym.

Zdecydowanie. Jest więc kwestia tego, jak zapobiegać długowi technicznemu, i tu wchodzi temat jakości oprogramowania.

Kto jest odpowiedzialny za jakość oprogramowania?

Może powiem uogólniając: tak naprawdę wszyscy, którzy uczestniczą w projekcie. Nie można stawiać tej sprawy w ten sposób, że „to jest wina biznesu / grafika / project managera / product ownera / programisty”. Wytwarzanie oprogramowania to kolektywny effort, to zespołowa praca i nie można tego zamykać w jednej osobie.

Z drugiej strony jestem zdania, że my jako programiści – bez względu na to, jakie są wymagania biznesu i jakie ten biznes miałby oczekiwania w stosunku do nas – musimy stać na straży samego kodu. To trochę jak z mechanikiem. Gdy klient przychodzi do mechanika, to jest tak, jakby biznes przychodził do programisty, żeby napisać mu soft. Chcemy, żeby mechanik dobrze naprawił nam samochód. Nie chcielibyśmy, żeby poszedł na skróty, poskręcał coś na trytytki, powkładał tanie części. Chcemy mieć do niego zaufanie – że on nam te rzeczy zrobi dobrze. Dlaczego? Bo wiemy, że w przeciwnym razie ten samochód nam się za jakiś czas rozsypie. Chcemy, żeby wziął za to odpowiedzialność, żeby nie pytał nas: czy ja powinienem naprawić ten samochód dobrze, czy źle? Czy zachować jakość podczas napraw, czy jej nie zachowywać?

Oczywiście możemy sterować pewnymi parametrami i powiedzieć: panie mechaniku, mi zależy na tym, żeby się zmieścić w tej cenie. Co pan proponuje? Czy to jest możliwe? Nie chcielibyśmy mechanika, który by powiedział: tak, to jest możliwe, to się da naprawić, a potem nie wymieniłby klocków hamulcowych, tylko zmienił na stare pomalowane świeżym lakierem. Nie chcemy takiego podejścia. I tu jest ta nasza odpowiedzialność za kod: nawet jeśli biznes naciska na nas, na to, by pewne rzeczy zrobić taniej, to jeśli to jest niemożliwe, to powinniśmy mówić „nie” i dbać o to, by biznes rozumiał konsekwencje tych decyzji, a nie składać soft na trytytki, oszczędzając na dobrych praktykach jego wytworzenia.

To może dodam, że my właśnie mamy być tym mechanikiem, do którego przychodzi klient i mówi: niech pan mi to sklei taśmą i będzie dobrze. Musimy wtedy powiedzieć: nie, chodzi o Twoje bezpieczeństwo. Jak Tobie się coś stanie, to ja będę za to odpowiadać.

Dokładnie. Co więcej, jeśli klient wymaga wykonania naprawy poniżej bezpiecznego poziomu jakości, to powinniśmy powiedzieć „nie, nie wykonamy tej naprawy, nie jesteśmy w stanie”.

Jakie elementy oprogramowania bierze się pod uwagę przy ocenie jakości?

Trochę już o tym mówiliśmy: na poziomie konstrukcji kodu możemy patrzeć na to, jak budujemy klasy, jaka jest struktura programu, jaka architektura. Możemy też zwrócić uwagę na elementy zewnętrzne, które wynikają bardziej z tego, że patrzymy na oprogramowanie jak na produkt dostarczający wartość biznesową – tu liczy się więc np. jego UI (interfejs programu) oraz to, czy jest łatwy w użyciu i czy realizuje wymagania biznesu.

Przypomnijmy, że to kolektywna praca zespołu – żeby wszystkie elementy ze sobą współgrały.

Jakie cechy oprogramowania pomagają określić jego jakość?

Na pewno jest kwestia samej złożoności kodu, samego complexity – mówimy tu o wskaźniku, który pozwala spojrzeć na to, jak bardzo kod jest „pomieszany” (często mówi się tu o spaghetti code). To jest coś, co możemy starać się obiektywnie ocenić.

Jest też taki miernik jak spójność (coherence) – możemy mówić o zgodności z zasadami pisania dobrego kodu, np. ciekawym wyznacznikiem jest promowany przez Boba Martina SOLID. Jeśli się do niego stosujemy, to potrafi dać przynajmniej jakąś aproksymację co do tego, jakiej jakości jest nasz soft na poziomie kodu.

Są też rzeczy banalne, o których często mówimy, ale mam wrażenie, że nie poświęcamy im wystarczająco dużo czasu, by rzeczywiście zrozumieć, jakie mają konsekwencje: długość funkcji, ich nazewnictwo, to, w jaki sposób później się ten kod czyta ze względu na wszystkie te cechy – to jest ostatecznym „testem” na to, czy kod jest odpowiednio dobrej jakości. I uwaga: nie musimy skupiać się tu tylko na miękkiej ocenie tych rzeczy. Możemy próbować je obiektywizować i mierzyć. To jest oczywiście zależne od danego teamu – na ile chce on wchodzić na poziom twardych mierników, a na ile zostać na poziomie takiego softzrozumienia tych rzeczy. Są różne drogi.

Mówimy tu więc o samej konstrukcji kodu, o tym, jak on wygląda na poziomie linii. Ale to nie wszystko. Fajnie mieć dobry kod (to bardzo dobra podstawa, by dalej tworzyć dobry soft), ale dookoła kodu są pewne praktyki, które sprawiają, że w rezultacie przekłada się na dobre oprogramowanie trafiające na produkcję (do klienta).

Są to takie tematy jak testy. Mamy szereg różnych testów, dzięki którym możemy oceniać oprogramowanie jako całość, jako projekt – np. unit testy, które dają bardzo szybki feedback co do tego, gdy coś zepsujemy podczas wprowadzania zmian; testy integracyjne czy end-to-end, które dają informację o tym, czy całość programu działa dobrze. Pokrycie testami, ich implementacja i ogólnie cały pipeline w wytwarzaniu oprogramowania też świadczy o tym, czy to jest oprogramowanie dobrej jakości. Tutaj bardzo bym podkreślił kwestię automatyzacji tych testów czy też automatyzacje samych mierników konstrukcji kodu, o których wspominałem wcześniej.

Jeśli mamy narzędzia, mamy odpowiednio zbudowane pipeline’y, które automatycznie budują aplikację i uruchamiają testy, to one też mogą nam pomóc podwyższać jakość kodu aplikacji. Ta duża automatyzacja procesów przy jego wytwarzaniu też jest pewną cechą oprogramowania wysokiej jakości.

To często widać, gdy zagląda się do projektów na GitHubie – wiele z nich ma podpiętego np. Travisa, na którym są odpalane jakieś buildy. Można sobie zobaczyć, czy przechodzą testy, czy są podpięte narzędzia, które sprawdzają pokrycie kodu testami, można zobaczyć narzędzia, które sprawdzają np. coplexity kodu (rysują bardzo ładne wykresiki, gdzie robią się różne połączenia i jest ich za dużo).

Nie wiem, czy chciałbyś, Mateusz, żebyśmy weszli w szczegóły i tłumaczyli poszczególne koncepty.

Niekoniecznie, ale może wspomniałbyś jeszcze o automatycznych bramkach jakościowych – czym są i jak działają.

Są takie narzędzia, jak np. Sonar, które mają pewne reguły sprawdzania oprogramowania pod kątem znaczników, mogących świadczyć o złej jakości (o jakichś problemach – powiedzmy nieużywanym kodzie). Taki Sonar przechodzi przez kod – również w pipelinie, który automatycznie uruchamia się przy każdym pushu do jakiegoś brancha – i mówi przykładowo: słuchaj, masz tu nieużywany kod. Czy to jest zamierzone?

Możemy również mówić o takich bardzo podstawowych bramkach jak formatownie kodu. Nie wspominałem o tym wcześniej, ale to też jest element jakości kodu. Jeśli kod mamy napisany „brzydko”, niespójnie sformatowany, to możemy spodziewać się tego, że będzie trudniej w nim nawigować.

Takie narzędzia jak Sonar potrafią nam służyć jako automatyczne bramki jakości. Podkreślmy tylko – by nie słuchacze odnieśli wrażenia, że to są wyrocznie – że ważna jest interpretacja. To rozmowa o tym, co nam mówią pewne dane. Znowu posługując się analogią: gdy patrzymy w Excela i są tam jakieś liczby, to one nie mają ostatecznie znaczenia, jeśli ktoś nie doda im dobrej interpretacji. Często więc jest tak, że w automatycznych narzędziach możemy mieć jakieś false positive’y. Musimy po prostu świadomie podchodzić do tego, jakie dają nam one wyniki.

Kiedy możemy uznać, że oprogramowanie jest „dobrej jakości”?

Widzisz, ja jestem zdania, że nie ma absolutnych miar. To znaczy pewnie jakieś minimalne są – jeśli uda nam się uruchomić oprogramowanie, to już jest jakieś minimum, które spełniamy. Ale ponieważ nie ma w świecie absolutnych miar, to musimy odpowiedzieć sobie na pytanie, kiedy dla nas oprogramowanie jest wystarczająco dobrej jakości.

Tutaj pomocne są praktyki, czyli mierzenie jakości często i w powtarzalny sposób. Zespół musi zdecydować, że np. complexity jest na jakimś poziomie, musi zdefiniować, że liczba bugów w oprogramowaniu jest na jakimś poziomie, jaki jest średni czas dotarcia funkcjonalności na produkcję – powiedzmy: biznes zleca nam jakiś task i my mierzymy, kiedy ten task dociera na produkcję jako gotowa funkcjonalność. Są to oczywiście przykłady, ale moje przesłanie jest takie: ustalmy sobie jakiś poziom, który my akceptujemy jako „nasza wystarczająca jakość”.

Następnie, aby nie spocząć na laurach, dążmy do tego, żeby to podwyższyć. Jeśli mamy liczbę bugów na produkcji na poziomie sto na miesiąc (strzelam, bo to zależy od wielkości oprogramowania), to sprawmy, aby po kolejnym sprincie czy kolejnym miesiącu było tych bugów mniej. Podnośmy tę jakość. Sprawmy, aby zmiany docierały na produkcję szybciej. Mamy takie incentives i to nas napędza do tego, żeby robić rzeczy lepiej.

Jest oczywiście jeszcze kwestia miękkiego spojrzenia na ten temat: jeśli nie boimy się wprowadzać zmian w programie (to, o czym mówiliśmy wcześniej), jeśli nie drżymy przed release’em nowej wersji oprogramowania na produkcję, bo coś się wysypie, to też jest oczywiście dobry indykator.

Czyli chcesz powiedzieć, że jak robimy release’a w piątek, to znaczy, że albo jesteśmy bardzo pewni siebie, albo spokojni, bo mamy dobry jakościowo kod?

Poruszasz ciekawą rzecz, myślę, że warto to rozwinąć. Rzeczywiście wierzę ostatecznie w to, że zespół działający zgodnie z praktykami dostarczania oprogramowania dobrej jakości może release’ować w każdej chwili. Jest to koncept Continuous Delivery powiązany z konceptem Continuous Integration, o którym można sobie poczytać np. u Fowlera (bardzo fajnie o tym pisze). To koncept bardzo mocno spopularyzowany przez Flickra – nie wiem, czy jeszcze słuchacze pamiętają, ale był taki serwis foro, zresztą on nadal istnieje w jakiejś formie Flickr (tutaj mówię o spopularyzowaniu, bo on już istniał wcześniej, ale został mocno spopularyzowany w 2008 czy 2009 roku). Koncept zakłada, że każda zmiana idzie od razu na produkcję. Nie ma zmian, które są gdzieś chowane na boku. Mówimy tu o częstym merge’owaniu, o niepracowaniu za długo na branchach gdzieś z boku i próbie merge’owania za miesiąc tego ficzera, który robiliśmy w zamknięciu. Chodzi o to, aby wszystkie zmiany wprowadzać na masterze (trunk-based development).

Oczywiście, aby to działało, trzeba to połączyć z różnymi innymi praktykami. Nie zachęcam, aby po wysłuchaniu podcastu wrócić do komputera i zacząć wrzucać rzeczy od razu na produkcję. Kod musi być dobrze otestowany, automaty dobrze zrobione. Wchodzą tu w grę również ficzer flagi – żeby pewne ficzery mogły być wyłączone, dopóki nie są skończone. Mogą one nie psuć programu, ale nie dają jeszcze wartości jako skończona funkcjonalność.

Paradoksalnie uważam, że tak: jeśli jesteśmy w stanie robić pewnie release’y w piątek, pójść do domu i nie bać się, że nam to zatruje weekend, to też jest bardzo dobry indykator tego, że mamy soft dobrej jakości i co więcej procesy wokół jego wytwarzania też dobrej jakości.

Przyszło mi do głowy takie pytanie na rekrutacji: czy robicie release’y w piątek i czy pracujecie w sobotę? To może określić, czy robicie dobry soft.

Tak, super, świetnie. Aż to chyba sobie zapamiętam. Co o tym myślisz?

Powiem Ci, że wymyśliłem to teraz na poczekaniu.

Tak, tak… Nie chciałbym, abyśmy teraz za bardzo zeszli na filozofię życia, ale są pewne rzeczy, które są ciekawe. Jako twórcy oprogramowania, w ogóle jako ludzie znajdujemy obejście pewnych problemów. Pytanie, czy leczymy symptomy – bo nierobienie release’ów to prawdopodobnie leczenie symptomów słabej jakości (bardzo ogólnie mówiąc). Można podejrzewać, że tak.

Tutaj może jeszcze mała gwiazdeczka: to jest też bardzo zależne od rodzaju oprogramowania, które tworzymy, od rodzaju produktu i poziomów jakości, na jakie sobie pozwalamy. Możemy ustalić sobie, że dla nas wyłącznie zero błędów na produkcji jest akceptowalne – np. robimy maszynę, która steruje naświetlaniem promieniotwórczym, żeby leczyć jakąś chorobę. Są zresztą takie case’y, takie historie, że były błędy w tego typu maszynach. Tutaj możemy sobie pozwolić na zero błędów.

Być może więc rzeczywiście te przysłowiowe release’y w piątek czy wysyłanie do tej maszyny update’ów over the air w każdej chwili, gdy programista kliknie, nie jest dopuszczalne. Bo nie jesteśmy w stanie zrobić takiego suita testów, który by nas zapewnił o tym, że będzie zero błędów. Ktoś musi fizycznie tę maszynę uruchomić, monitorować. Po prostu odpowiedzmy sobie na pytanie, jakiego rodzaju soft robimy, ale generalnie dążmy do tego, żebyśmy bez strachu mogli robić kolejne release’y.

Czy jakość oprogramowania można zmierzyć? Kto się tym zajmuje i jakich narzędzi się do tego używa?

To kwestia tego, jakie mierniki wybierzemy. Są takie podstawowe rzeczy, o których pewnie każdy słyszał. Zdarza się też, że zespoły próbują podchodzić do tego tematu całkiem poważnie. Zespoły pracujące w Scrumie mogą mierzyć swoje velocity i capacity. Dlaczego twierdzę, że można od tego zacząć, dlaczego jest to powiązane z jakością oprogramowania?

Spojrzałbym na jakość oprogramowania jako na coś bardziej fundamentalnego, jako na zespół, który pracuje sprawnie i się usprawnia. Zaczynamy mierzyć nas jako zespół – to, jak my wykonujemy pracę. Powiedzmy: bierzemy sobie taką velocity, patrzymy, ile pracy jesteśmy w stanie wykonać w ciągu dwóch tygodni i sprawdzamy później, ile mamy kolejnych tasków (czy zadań/wymagań od biznesu) w następnych dwóch tygodniach. Wówczas jesteśmy w stanie przede wszystkim stać się bardziej przewidujący i nie doprowadzać do sytuacji overpromise dla biznesu.

Skąd może brać się kiepska jakość? Stąd, że obiecujemy za dużo, a potem próbujemy robić pewne rzeczy na skróty, żeby wywiązać się z obietnic. Jeśli więc miałbym mówić o miernikach, to zacząłbym od mierzenia wydajności naszej pracy, żebyśmy mogli bardziej świadomie obiecywać terminy i bardziej świadomie się z nich wywiązywać, żeby nie musieć chodzić na skróty.

Następnie poszedłbym w kierunku wprowadzenia mierników takich jak wcześniej wspominaliśmy, np. lead time (to miernik, zdaje się, z Kanbana), który mierzy czas od pojawienia się wymagania na naszej tablicy czy w naszym backlogu do momentu, w którym wymaganie trafia na produkcję. Zmierzmy to, zobaczmy, jak to u nas wygląda, czy się pogarsza, poprawia. Jak już mamy status quo, to spróbujmy dać sobie jakiś cel, żeby polepszyć wynik.

Oczywiście tu zawsze jest gwiazdeczka, bo każdym miernikiem można manipulować. Są takie śmieszne komiksy (zdaje się XKCD albo Dilbert poruszał ten temat): jak programistom zapłaci się sto dolarów za każdy bug i zacznie się mierzyć ilość bugów, to programiści tworzą więcej bugów. Trzeba więc tutaj uważać. Jeśli optymalizujemy lead time, to nie chodzi teraz o to, żeby robić rzeczy gorzej, na skróty. Bo możemy dojść do wniosku, że super, szybciej dostarczamy na produkcję, ale teraz pojawia się więcej bugów. Takim miernikom trzeba więc pewnie dać miernika przyjaciela w postaci mierzenia błędów na produkcji.

Od razu pomyślałem sobie o czasie: OK, zaczynamy nowy projekt na spokojnie, musimy się rozruszać, bo jak za szybko zrobimy go na początku, to podniosą nam poprzeczkę.

Tak, trochę tak to było w tych komiksach. Najlpeszy programista czy najlepszy pracownik dostaje najwięcej zadań. Ale znów mamy tu pytanie w szerszym kontekście: na czym nam zależy, kto nam podnosi tę poprzeczkę? Bo przede wszystkim, jeśli mamy dbać o jakość oprogramowania, to nie możemy dopuścić do tego, by ktoś z zewnątrz decydował o tym, jak zespół podchodzi do mierników. Tworzymy je dla siebie, a nie po to, by rozliczać się z kimś z zewnątrz.

Mamy np. stakeholderów, którzy przynoszą wymagania do naszego oprogramowania – mierniki nie są dla nich, by mogli nas teraz rozliczać, tylko po to, byśmy sami mogli obiektywizować swoją wydajność, skuteczność i jakość, a nie rozmawiać o niech tylko teoretycznie.

Jestem ogromnym zwolennikiem mierzenia – to jest troszkę inspirowane, powiedzmy, metodą naukową, gdzie naukowcy stawiają pewne hipotezy, przeprowadzają eksperyment i mierzą jego wyniki. Jest to też pewien element pracy z miernikami. Przykładowo przychodzi kolega z rewelacyjnym pomysłem: jeśli weźmiemy ten wzorzec projektowy i będziemy go stosować przez najbliższe pół roku w tym i w tym miejscu, to w naszym sofcie będzie dużo łatwiej wprowadzać zmiany. Pytanie, czy jesteśmy w stanie mierzyć tego typu rzeczy. Owszem, być może wiemy to intuicyjnie, bo dzięki wiedzy eksperckiej mamy dobry strzał i rzeczywiście uda się podwyższyć jakość oprogramowania dzięki łatwiejszemu wprowadzaniu nowych ficzerów. Ale nie wiemy tego ostatecznie, dopóki tego nie mierzymy. Myślę, że postawienie pewnej hipotezy, wdrożenie jej w życie i zmierzenie wyników jest nieodłącznie związane z podwyższaniem jakości.

Wracając jeszcze do mierników: można np. patrzeć nie tylko na liczbę błędów, ale też na to, jakie to są błędy. Przykładowo do aplikacji webowej można podpiąć sobie narzędzie do klasyfikacji błędów. Można też patrzeć na regresję – czy te błędy wracają; na korelację błędów z deploymentem – jeśli wychodzi nowa wersja oprogramowania, to czy wzrasta nam liczba błędów. To daje nam pewne sygnały co do tego, czy wszystko przebiega dobrze, czy może coś jest nie tak.

Są również mierniki biznesowe. Przykładowo mamy serwis, w którym użytkownicy muszą się zarejestrować, aby z niego skorzystać. Patrzymy, czy ta liczba rejestracji jest stała np. po deploymencie nowej wersji. Jeśli widzimy, że spadła ona np. o 20% po wysłaniu nowej wersji na produkcję, to prawdopodobnie coś zrobiliśmy nie tak. Mając taki feedback, efektywnie podwyższamy jakość oprogramowania, bo jesteśmy w stanie zareagować. Nie czekamy na to, aż użytkownicy napiszą na Reddicie, że Superserwis Andrzeja znowu nie działa, tylko my prawdopodobnie w piętnaście minut naprawiamy problem jakimś quick fixem. Takich mierników biznesowych jest dużo – ich wybór znów zależy od rodzaju aplikacji, jaką piszemy.

Dodałbym jeszcze jedną rzecz, o której do tej pory nie wspomnieliśmy, a jest to raczej ważny temat. Wydajność jest czynnikiem świadczącym o jakości. Znowu jest to element biznesu: czy ta wydajność jest ważna i jaki ma być jej poziom. Powinniśmy to sobie ustalić, mieć to transparente, potem optymalizować i mierzyć.

A kto jest odpowiedzialny za jakość oprogramowania?

Powiedziałbym trochę jak klasyczny architekt: to zależy (jest taki żart, że architekt oprogramowania zawsze mówi „to zależy”). Oczywiście jeśli ja jako programista biorę odpowiedzialność za jakość mojego kodu, to nie mogę liczyć na to, że kolega, który nie ma o tym pojęcia, będzie mi tworzył mierniki jakości kodu. Tu jest ten element, gdzie pewne rzeczy należą do mnie. Ja tworzę kod, to ja za niego odpowiadam.

Dlaczego mówię „to zależy”? Mierzenie pewnych rzeczy jest kulturą całego zespołu, w pewnym sensie całej organizacji. Czyli super, możemy na pewnym poziomie rzeczywiście mierzyć pewne cechy oprogramowania, ale nie uda nam się mierzyć np. lead time’u, który świadczy o szybkości dostarczania rzeczy na produkcję, jeśli nie ustandaryzujemy np. z analitykiem biznesowym, jak będą wyglądały wymagania, jak będziemy podchodzić do szacowania. To tylko przykład, bo są różne struktury zespołów, które w ogóle nie mają analityków.

Dążę do tego, że ostatecznie mierniki i w konsekwencji patrzenie na nie, to wysiłek całości zespołu. Tutaj wchodzi to „to zależy”: ktoś musi zacząć i ktoś musi walczyć o to, by takie rzeczy stały się kulturą zespołu. W praktyce często są to doświadczeni programiści. Są firmy, które zatrudniają też data scientistów – ludzi, którzy zajmują się analizą danych i to oni naciskają na wprowadzenie tej kultury mierzenia, obiektywizacji tego, co robimy.

Ostatecznie jeśli biznesowi nie będzie zależało na miernikach, to obojętnie jakich tych mierników nie wprowadzimy, ignorowanie ich przez zespół do niczego nas nie doprowadzi.

Podsumowując: „to zależy” z gwiazdką.

Czy czynniki zewnętrzne (np. biznes) wpływają na jakość oprogramowania? W jaki sposób? Jak się bronić przed negatywnymi skutkami?

Tak, oczywiście mają wpływ – tak jak mówimy: nie pracujemy w próżni. Wytworzenie oprogramowania to suma wszystkich interakcji wszystkich ludzi, którzy w tym uczestniczą. W kwestii bronienia się przed negatywnymi skutkami znów zaczynamy od tego: „czy ja coś mogę zrobić?”. Uważam, że my jako programiści jesteśmy najbliżej tego kodu, to my ostatecznie mamy wpływ na to, jak potrzeba biznesowa przekłada się na konkretną linię kodu. Możemy więc być bramką tej jakości (to trochę jak w tej analogii do mechanika). Na pewno powinniśmy zacząć od siebie – to pierwszy punkt, który chciałbym przedstawić.

Często też się zdarza, że biznes ma tendencję do traktowania zespołów developerskich jak wykonawców – biznes przychodzi z pewnymi wymaganiami i mówi: zróbcie tak, nie pytajcie. I to jest ten moment, w którym my mamy prawo, a wręcz obowiązek wymagać, by nas w ten sposób nie traktować, żebyśmy mieli wpływ na to, jak produkt jest wykonywany – czy to poprzez mierniki, czy sugerowanie usprawnień funkcjonalności. To jest taki bottom line – czynniki zewnętrzne w postaci biznesu wpływają na jakość oprogramowania, a my mamy prawo pracować nad tym, aby to zmienić.

Niestety nie ma prostego rozwiązania, jakiejś silver bullet na zasadzie przejrzenia jednej książki Pięć kroków do przekonania biznesu, żeby brał pod uwagę zdanie developerów. Często jest tak, że firmy zatrudniają osoby doświadczone, które potrafią o tym opowiedzieć, potrafią przekonać. Jest to jedna z dróg. Uważam, że bardzo ważne jest, aby cały zespół rozumiał zagadnienie jakości i był w stanie w pewnym sensie jej bronić.

Przykładowo umówiliśmy się na mierniki, a teraz mamy naciski od biznesu, aby je zignorować i pozwolić sobie na to, by wzrosła np. complexity kodu na rzecz szybkości wykonania oprogramowania. Jeśli widzimy, że coś jest robione niezgodnie z tym, w co wierzymy, z tym, na co się umówiliśmy, mamy prawo wymagać od biznesu trzymania się ustaleń. Co się dzieje, jeśli się ich nie trzyma? Trzeba się zastanowić, czy pracujemy w dobrym zespole. Są pewne sytuacje, gdy niektórych rzeczy nie da się zmienić, lecz jako programiści też jesteśmy w tym miejscu, że rynek jest dla nas dosyć łaskawy i mamy możliwość wybrania firmy, w której dobrze się takie rzeczy robi. Trzeba uważać na pewne błędne koło. Jeśli raz pozwolimy sobie robić rzeczy gorzej i nie dbać o jakość, to pewnie będzie się to działo częściej.

Dodam jeszcze, że często spotykam się z pytaniem: jak przekonać biznes, żeby zrobić refaktor? To jest normalne – piszemy program, pojawia się w nim trochę długu technicznego, więc trzeba go zrefaktorować, trochę wyszlifować kod. Moją odpowiedzią na to pytanie jest: nie pytać, czy możemy. Robienie refaktoru jest częścią naszej pracy. Jeśli jesteśmy proszeni o estymacje, to dostarczamy takie estymacje, które dają nam szansę na to, żeby robić refaktor. Jeszcze lepiej, jeśli stosujemy praktykę continuous refactoringu (czyli w zasadzie cały czas refaktorujemy).

Tylko teraz widzisz, Mateusz, kropki się łączą. Żeby robić continuous refactoring, musimy mieć testy. Żeby móc robić dobre estymacje, musimy w jakiś sposób mierzyć naszą wydajność i zapewnić powtarzalność. Ostatecznie więc schodzi to do tego, że jeśli chcemy wymagać pewnych rzeczy od biznesu, to sami musimy być wystarczająco mocno profesjonalni, żeby mieć bazę, na podstawie której możemy tych rzeczy wymagać oraz zagwarantować, że nasze słowo przekłada się na rzeczywiste efekty w postaci wystarczająco dużej jakości.

Wspomniałeś o tym, żeby wymagać od Product Ownera. Czego wymagać i jak wymagać?

Pierwsza rzecz jest taka: ustalmy role, kim jest Product Owner. To, z czym ja się często spotykam w przypadku Product Ownera, to zupełnie różne rozumienie tej roli. Programiści są skupieni na tym, żeby dobrze napisać kod, ale niekoniecznie zastanawiają się nad tym, jaką rolę ma Product Owner. Co więcej, Product Owner być może sam ma w głowie jakąś definicję swojej roli, która nie jest podzielana przez programistów i resztę organizacji.

Tu już zaczyna się zgrzyt. Ciężko jest mówić o tym, czy moglibyśmy czegoś od siebie wymagać. Możemy pójść w stronę Scruma – takie frameworki fajnie definiują Product Ownera jako osobę, która zajmuje się priorytetyzacją backlogu i decyduje o tym, co jest ważniejsze i w jakiej kolejności zespół powinien to robić, ale już nie decyduje np. o tym, jak długo się to robi. Nie ma on wręcz prawa wymagać, byśmy pewne rzeczy zrobili szybciej. To jest oczywiście jakiś przykład. Po inspirację odesłałbym słuchaczy do Scrum Guide'a, bo jego przeczytanie ze zrozumieniem jest moim zdaniem bardzo niedoceniane przez programistów. Polecam.

Jeśli rzeczywiście ustalimy, że to jest nasza definicja tej roli, to tego możemy od siebie wymagać. Wtedy ja jako programista widzę, że Product Owner przychodzi i mówi: „Andrzej, zrób to szybciej, bo…”. A ja mówię: „Słuchaj, nie na to się umówiliśmy. Bardzo Cię przepraszam. Teraz będzie fajnie, jak ja zrobię to szybciej, ale za pięć lat czy dwa będziemy mieli produkt o takim długu technicznym, że nie będziemy w stanie go utrzymać”. Albo mówię: „No dobrze, mogę to zrobić szybciej, ale wówczas zmień priorytety. W tym sprincie nie zrobimy innych zadań”.

Na świecie nie ma nic za darmo. Jeśli mam coś zrobić szybciej, to muszę na to poświęcić więcej czasu, więc może czegoś innego nie zrobię. To jest przykład, ale znowu: im bardziej pewne rzeczy mamy ustalone explicit, wyraźnie i jasno godzimy się na pewne parametry (czy to mierniki, czy cele, czy definition of done*), tym bardziej sprzyja to tworzeniu oprogramowania dobrej jakości i wymagania od siebie rzeczy, na które się umówiliśmy – no bo w ogóle na coś się umówiliśmy.

* Zespoły często tworzą sobie definition of done, która określa, kiedy wymagania niefunkcjonalne / mierniki są na ustalonym poziomie. Jeśli poziom zostaje osiągnięty, to dopiero wtedy akceptujemy dane zadanie jako wykonane.

OK, wygląda na to, że jakość oprogramowania to ogólnie ciężki temat, ale pewnie po coś to robimy. Jakie korzyści mamy z tego, że nasze oprogramowanie jest dobrej jakości?

Nawiążę jeszcze do tego, co powiedziałeś. Oczywiście jest to ciężki temat. Gdyby to było łatwe, to wszystko byłoby świetnej jakości, wszystko byłoby pięknie i różowo. Świat taki nie jest. To jest bardzo złożony temat, składający się z wielu powiązanych ze sobą czynników i jeśli one nie działają, to rzeczy potrafią się sypać kaskadowo. To jest ten fundament.

Jakie mamy korzyści? Lubię żartować, że spokojny sen i więcej pieniędzy, bo jestem zdania, że to trochę o tym mówiliśmy. Jeśli mamy pewność co do softu, który piszemy, co do produktu, który release’ujemy, to nawet w te piątki śpimy dobrze, nawet jeśli mamy ciśnienie na release. Z drugiej strony są dosyć twarde argumenty za tym, jest dosyć dużo badań za tym, że rzeczywiście firmy, które stosują dobre praktyki wytwarzania oprogramowania, które dbają o jakość kodu, są np. lepiej wyceniane na giełdzie.

To jest o tyle ciekawe, że my często kojarzymy: „No tak, jeśli coś trzeba zrobić dobrze, jeśli to ma być wysokiej jakości, to będzie to trwało długo”. Moglibyśmy pewnie rozwijać ten temat, ale ja jestem zdania, że to nie jest prawda. Owszem: nauczenie się robienia rzeczy dobrze trwa długo.

Przykładowo chcemy pisać unit testy albo nawet bardziej ortodoksyjnie – chcemy robić TDD (Test Driven Development). Dojście do takiego momentu, w którym zespół dobrze pisze testy w podejściu Test Driven Development zajmie dużo czasu i rzeczywiście zespół niemający jeszcze tych kompetencji będzie na początku dostarczał funkcjonalności wolniej, a co za tym idzie – będzie droższy. Zespół, który ma już doświadczenie w TDD, może będzie trochę dłużej pisał kod (bo jednak gdy piszemy testy, trzeba wklepać więcej literek), ale pewnie samo spowolnienie będzie dosyć pomijalne, a ostatecznie zespół nie będzie miał wracającej takiej liczby błędów. Ten zespół będzie szybciej dostarczał rzeczy na produkcję, szybciej będzie realizował potrzeby biznesu.

Zobacz, jak to się mnoży. Nie dość, że dostarczamy szybciej per se na produkcję nowy ficzer, który sprawia, że nasz koszyk konwertuje dziesięć razy lepiej (szybciej to robimy, więc za samo wykonanie nie trzeba zapłacić dużo), to jeszcze ostatecznie biznes szybciej odniesie korzyści z pracy przez nas wykonanej. I to się mnoży.

My jakość często kojarzymy z jakimiś skutkami albo dużą ilością ficzerów, funkcjonalności. Jakość to nie jest duża ilość funkcjonalności, tylko szybkość dostarczania wartości – tego, co dla nas jest ważne. Ona się na to przekłada oraz na więcej pieniędzy i większą konkurencyjność naszego biznesu. Więc z jednej strony zaczynamy od tego żartu, ale ten żart jest całkiem poważny.

Zastanawiałem się, kto ma więcej pieniędzy: my może tak. Ale czy ten biznes, ci klienci, którzy do nas przychodzą? Powiedziałeś, że docelowo tak.

Tu dochodzimy do pytania, jak my się rozliczamy, jaki mamy model biznesowy. Ale nie da się ukryć, że robienie rzeczy sprawniej z ekonomicznego i społecznego punkty widzenia daje nam przynajmniej szansę na to, żeby być bardziej konkurencyjnym. A jeśli jest się bardziej konkurencyjnym, to i nasza firma ma więcej pieniędzy, i my lepiej zarabiamy jako programiści. Zresztą daleko nie trzeba szukać. Dobrzy programiści, którzy dobrze robią rzeczy zarabiają naprawdę absurdalne pieniądze.

Na pewno tak. O tym temacie może innym razem.

Mówiliśmy już o korzyściach, a jakie są konsekwencje braku dbałości o jakość oprogramowania? Na jakim etapie wytwarzania oprogramowania pojawiają się problemy?

Im dalej w cyklu wytwarzania oprogramowania jesteśmy, tym bardziej czujemy problemy ze względu na wytwarzany dług techniczny, o którym mówiliśmy. Dochodzimy do takiego punktu, w którym rozwój naszego produktu jest na tyle wolny, że w zasadzie albo niemożliwe jest wprowadzanie nowych funkcjonalności, albo jest to na tyle powolne, że to się przestaje opłacać. Dochodzimy do momentu, w którym musimy przepisać nasz system – i to się często zdarza. Dochodzi do sytuacji, w których naprawdę źle pisany soft musi być przepisywany co dwa-trzy lata, bo nie spełnia wymagań i nie można go dalej rozwijać.

Są też rzeczy bardzo miękkie za tym idące: nie chcą z nami pracować dobrzy ludzie. Dobrzy programiści dążą do tego, żeby pracować w zespołach, które robią rzeczy dobrze.

Czy forma wytwarzania oprogramowania (Agile vs Waterfall) ma tutaj duże znaczenie?

Ja wierzę, że tak. Zresztą znowu można odwołać się do pewnych badań, które sugerowałyby, że tak. Podkreślam: sugerowałyby – bo robienie dobrych badań, replikowalnych, to skomplikowane zagadnienie. Myślę, że warto dążyć do tego, żeby mieć skrócony feedback loop. Co przez to rozumiem? Żebyśmy szybciej dostawali informację zwrotną o tym, jak np. wcześniej wspomniane mierniki działają; jak nasze oprogramowanie w ich kontekście się sprawdza.

Przykład: jeśli raz na rok sprawdzimy, czy mamy dużo błędów, czy użytkownicy lubią nasze oprogramowanie, czy dużo się rejestrują, to informację mamy raz na rok. Raz na rok możemy wprowadzić jakieś zmiany w procesie wytwarzania oprogramowania, raz na rok możemy wprowadzić zmiany w kodzie i funkcjonalności, bazując na informacji, które dają nam mierniki.

Jeśli pracujemy w krótszych iteracjach niż roczne, dajmy na to – co dwa tygodnie zerkamy na mierniki, co dwa tygodnie decydujemy o tym, w jakim kierunku będziemy dalej rozwijać oprogramowanie, na czym będziemy się skupiać i co usprawnić w procesie wytwarzania oprogramowania, to mamy większą szansę, że te korekty szybciej nas doprowadzą do naszych pożądanych wzrostów mierników jakości.

Myślę, że przy wytwarzaniu oprogramowania warto wykorzystywać fakt, że można szybko w nim wprowadzać zmiany i szybko testować je w rzeczywistych warunkach. Wytwarzanie oprogramowania w takim klasycznym waterfallu, który notabene zdaje się… nie chcę tutaj nic przekręcić, ale zdaje się, że ta metodologia przez samego twórcę była odradzana w kwestii wytwarzania oprogramowania.

W takim kaskadowym modelu – w którym najpierw robimy jakiś wielki projekt, później implementację, później wielkie testy i za dwa lata wprowadzamy oprogramowanie na produkcję – pewnie nie warto robić oprogramowania, bo można to robić w podejściu bardziej agile’owym. W nim mamy małe iteracje, wprowadzamy małe zmiany, szybko sprawdzamy, czy one działają, stawiamy kolejną hipotezę – np. że jak zrobimy jakiś przyrost funkcjonalności, to da nam to dany efekt. Mierzymy to, powtarzamy. Można to wykorzystać. Oprogramowanie na to pozwala. Łatwiej się to robi niż w przypadku mostów i myślę, że warto tak do tego podejść.

To ja może jeszcze dodam taką analogię: to trochę jak procent składany – gdzie można więcej zarobić. Taki procent składany to właśnie nasz Agile.

Co na temat jakości oprogramowania mówią badania? Już wielokrotnie wspominałeś, że potwierdzają to, że warto. Chciałbyś coś dodać? Czy jakość oprogramowania ma rzeczywiście znaczący wpływ na wymienione korzyści i zagrożenia?

Tak jak mówiłem, możemy posługiwać się doświadczeniem pewnych osób, możemy starać się to obiektywizować i patrzeć na to, co nam pokazują badania. Polecam słuchaczom zerknięcie do książki Accelerate. To książka dosyć krótka, dosyć sucha, można by powiedzieć – dosyć nudna, ale trochę może rozwiewa wątpliwości i daje mocną sugestię za tym, że takie rzeczy jak mierzenie czy szeroko rozumiana zwinność (Agile), czy praktyki takie jak Continuous Integration, Continuous Delivery w większym bądź mniejszym stopniu korelują z ostatecznym nie tylko finansowym wynikiem firmy, ale też zadowoleniem pracowników pracujących w danych firmach. Nie jestem w stanie z głowy tego streścić – konkretnie gdzie które badania były robione, ale w książce są dosyć mocno przekonujące dowody.

Poza tym, jak się troszkę rozejrzy po community, posłucha się ludzi najbardziej doświadczonych, to są to ludzie, którzy zdecydowanie mocno stawiają na jakość oprogramowania, na praktyki, o których dzisiaj wspominamy, na mierzenie. Tak że uważam, że wątpliwości jak zawsze we wszystkim są. Możemy oceniać co najwyżej z jakimś prawdopodobieństwem, że nasze praktyki i podejście sprawdzą się w danej sytuacji. Ale jeśli miałbym wybierać, w jakim kierunku ja osobiście ze swoją karierą pójdę, to zdecydowanie poszedłbym w kierunku dbania o jakość, dbania o bycie tym, który jest wręcz strażnikiem i propagatorem jakości.

Jakie elementy są najczęściej zaniedbywane? Jak poznać, że dana firma faktycznie dba o jakość kodu, a nie tylko o tym mówi na rekrutacji?

Żebyśmy to słuchaczom jasno powiedzieli: nie poruszamy się na ekstremach, to nie jest absolutne: złe albo dobre. Poruszamy się na pewnej linii. Firma może być w tym lepsza albo gorsza. Nikt pewnie nie jest idealny. Nawiązując do tych release’ów w piątki – to, że firma się ich wystrzega, to jeszcze nic nie znaczy. Musimy połączyć ze sobą wiele czynników, żeby dopiero wyciągnąć wnioski, że jest to oprogramowanie słabej jakości.

Odpowiadając teraz na Twoje pytanie: stosowanie testów. Myślę, że jest to dosyć fundamentalne – w szczególności stosowanie unit testów (nie dlatego, że unit testy lepiej sprawdzają jakość oprogramowania niż end-to-endy, ale dlatego, że unit testy i w ogóle możliwość ich pisania jest powiązana z jakością kodu). Jeśli jako programiści nie jesteśmy w stanie pisać unit testów, to jest to bardzo dobry sygnał świadczący o tym, że mamy zły kod albo że być może źle rozumiemy wymagania, być może zbyt szeroko do nich podchodzimy. Tu trzeba już pewnie indywidualnie dochodzić, co jest tego powodem, ale do złego kodu bardzo ciężko pisze się unit testy i one bardzo spowalniają proces, więc firmy odchodzą od stosowania unit testów. Nie znaczy to, że nie powinniśmy patrzeć na resztę całego zestawu testów, którymi powinno być pokryte oprogramowanie. To jest istotny czynnik.

Dobre firmy na pewno zaczynają mierzyć, stosują mierniki, starają się obiektywizować to, co robią i – tak jak wcześniej mówiliśmy – patrzą na te mierniki często i wyciągają z nich wnioski. Udoskonalają swoją pracę i produkt na podstawie tego, co im te mierniki wskazują. To też nie znaczy, że firmy te rezygnują całkowicie z wiedzy eksperckiej i interpretacji tych mierników ze zrozumieniem.

Uważam, że firmy, które faktycznie badają jakość kodu, dążą do tworzenia multidyscyplinarnych zespołów, które dbają o jakość produktu – bo jakość kodu jest z tym bardzo mocno powiązana. Co mam na myśli, mówiąc „multidyscyplinarne zespoły”? Znów przez analogię: wszyscy siedzą w jednej ławce. Wszyscy, którzy są zaangażowani w tworzenie iteracji produktu, pracują razem. Czyli nie mamy działów designerów i developerów, które się przerzucają: jedni robią design, drudzy mają to zaimplementować, ci krzyczą, że jest źle, tamci krzyczą, że źle zaimplementowali. To jest wspólna praca w ramach jednego zespołu. Oni razem np. deklarują termin – w porozumieniu, we wspólnej burzy mózgów, w przypadku Scruma – po wspólnym planowaniu czy refinemencie.

Takie multidyscyplinarne zespoły mają wspólny commitment co do terminu, co do tego, co są w stanie zrobić. Nie są to rozłączne rzeczy ułożone w szeregu – że najpierw jedni zrobią jedno, potem drudzy drugie. Dlaczego? Dlatego że brak komunikacji, który się pojawia w takich set upach silosowych, wśród takich rozdzielonych ludzi z jednej strony bardzo źle działa psychologicznie (ludzie zaczynają traktować siebie jak wrogów), a z drugiej strony nie ma tej takiej kreatywności.

Powiedzmy designer czy UX-owiec wymyśla jakiś pomysł, a developer mówi: „Mogę to zrobić szybciej, jeśli przesuniesz to trochę w lewo” albo „Jeśli wykorzystamy już istniejący komponent”, albo „Jeśli chcesz, mogę do tego dodać taką i taką animację, to mi w ogóle nie zajmie czasu”. To ostatecznie sprawia, że dzięki takiej kreatywnej, wspólnej, multidyscyplinarnej pracy produkt zyskuje na jakości. Rzeczy są też często robione szybciej lub nie są robione niepotrzebnie. Często się spotykałem z takimi sytuacjami, kiedy zespół designerów coś wymyślił, zespół developerów to zaimplementował i okazywało się, że to np. wcale nie było takie ważne albo nawet nie było potrzebne, tylko oni się nie dogadali.

Możemy tę historię o multidyscyplinarności rozszerzyć na wszystkie role, które występują w zespole. Jeśli mamy testerów, to oni też nie są oddzielnym działem. Tak samo gdy mamy business analityka – to nie jest osobny dział. To jest moim zdaniem bardzo ważny sygnał świadczący o tym, że firma rozumie podejście do jakości.

W firmach, które rzeczywiście dbają o jakość, wyniki, performance, to, jak produkt radzi sobie na rynku, jest transparente. Te informacje są udostępniane zespołowi, który realizuje produkt. Mówimy tu o relacji biznes–developerzy, o której trochę wcześniej wspominaliśmy. Jeśli biznes trzyma wyniki, np. ilości rejestracji, dla siebie, to po pierwsze developerzy nie mogą optymalizować tego, co jest naprawdę ważne (bo ostatecznie nie jest ważne to, czy będziemy mieli przycisk zielony, czerwony czy niebieski, tylko czy to konwertuje na liczbę użytkowników). Zbliżenie tego, zbudowanie transparentnego przepływu informacji na temat performance’u też świadczy o tym, że danej firmie zależy na jakości.

W firmach, które chcą robić rzeczy lepiej, daje się autonomię zespołowi i nie ogranicza się mu możliwości podejmowania decyzji, ale też uczestniczenia w ulepszaniu produktu. Znowu: dlaczego? Z jednej strony ci, którzy wykonują pracę, wiedzą najlepiej, co jest problematyczne. Developer wie, że ta mała jedna rzecz, którą wymyślił biznes, zajmie bardzo dużo czasu w trakcie implementacji. Musi więc być brane pod uwagę jego zdanie, ale musi być mu też dawana przestrzeń, aby mógł wykonać pracę zgodnie z zasadami, które on wyznaje jako zasady jakości, bo to znowu ON WIE. On musi dostać zaufanie – że wie, co zrobić, żeby nie było np. wspomnianego wcześniej długu technicznego.

Co więcej jest to rzecz bardzo niemierzalna, ale nieszczęśliwi ludzie, niezadowoleni programiści, którzy nie mają wpływu na produkt, nie angażują się w jego wykonanie. Ciężko jest robić rzeczy dobrej jakości, jeśli mamy niezaangażowany zespół. A jednym z mechanizmów, które mogą pomóc w zaangażowaniu, jest właśnie danie wpływu na to, jaki jest produkt, jak produkt funkcjonuje.

Na pewno to nie jest wszystko, ale jeśli miałbym podkreślić jakieś kluczowe czynniki to: dążenie do uczenia się na błędach. To trochę takie cliché powtarzane w poradnikach o sukcesie, ale uważam, że jest to bardzo ważny czynnik. Jeśli podejdziemy do tego na serio i będziemy patrzeć, czy w firmie rzeczywiście jest kultura, w której wręcz ceni się umiejętność wyciągania wniosków z błędów, w przeciwieństwie do sytuacji, gdzie się oczekuje, że się tych błędów nie popełni, to – nawet jeśli mamy zespół, który na razie ma kiepski produkt czy niezbyt dobrej jakości kod – daje to szansę na to, że za dwa-trzy lata będziemy mieli świetnie rozwijające się rozwiązanie.

Wymaga to bardzo dużej, miękkiej szczerości co do tego, czy my rzeczywiście tworzymy to środowisko, czy tylko mówimy, tylko wywieszamy sobie na ścianie „Ucz się na błędach”. W korporacji wisi dziesięć punktów wartości i nikt nie wie, co tam w nich jest i nikt tym nie żyje. Nie może tak być.

Czyli można powiedzieć, że dbanie o jakość oprogramowania to inwestycja, która zwróci się za jakiś czas, niekoniecznie za miesiąc czy za dwa. Należy o tym pamiętać.

Tak, tak. To jest bardzo powiązane z tym, co mówiliśmy – żeby nauczyć się robić rzeczy dobrej jakości, to też trzeba na miękko. Wymaga to pewnej kultury, którą tworzymy, która pozwala nam to osiągać. Ale jest to też inwestycja w tym sensie, że musimy się nauczyć dobrze robić techniczne rzeczy. Nie ma siły. To wspomniane nasze TDD – jeśli nie spróbujesz robić w TDD przez pół roku, to nie będziesz miał o nim ani dobrej opinii, ani na początku dobrych rezultatów.

Jak dbanie o jakość oprogramowania wygląda na co dzień? Może moglibyśmy przybliżyć słuchaczom taki „dzień z życia zespołu”.

To jest rzeczywiście to, gdzie się zaczyna magia. Bo jak dużo byśmy nie opowiedzieli o ideach, o pewnych założeniach, jak robić rzeczy dobrze, (trochę jest to powiązane z Twoim poprzednim pytaniem), to właśnie to odróżnia firmy, które dbają o jakość, od tych, które nie dbają – że te, które dbają, potrafią potrafią wdrożyć w życie te piękne rzeczy. Opowiedzieć, napisać, zdawać sobie sprawę, do czego dążymy – spoko, to duża część sukcesu. Ale trzeba to wdrożyć w życie.

Powiedziałbym, że musimy się przestawiać, stopniowo dążyć do tego, żeby nie tylko patrzeć na kod (my jako developerzy i wszyscy członkowie zespołu), ale na to, jaką wartość to produkuje. Czy to, że poświęcamy sto godzin na optymalizację, powiedzmy, „piękności” tego kodu – czy to nam daje wartość biznesową. Nie mówię o tym, żeby oszczędzać, pozwalać sobie na bardzo duże complexity, na kod, którego się nie da ulepszać, żeby nie robić testów (nie zaprzeczam sobie teraz wbrew pozorom). Tylko: czy my nie robimy czasami rzeczy na wyrost? Niektórzy słuchacze może słyszeli o Don’t Repeat Yourself i o tym, żeby generalizować pewne rzeczy, żeby łatwo je było reużywać. Ale może czasem generalizujemy przedwcześnie. Jeszcze nie znamy ewolucji oprogramowania, a próbujemy zrobić coś funkcjonalnego. Poświęcamy dużo czasu na coś, co dostarcza dzisiaj relatywnie małą wartość, nie daje nam szansy na łatwiejszy rozwój w przyszłości.

Rzeczywistość jest taka: może lepiej napisać kod dobrej jakości, szyty na miarę, ale sprawnie i szybko, a zrefaktorować go w momencie, gdy zmieniają się wymagania. To jest taki mój przykład tego, by spojrzeć, czy ta generalizacja, to piękne rozwiązanie, które być może daje nam wielką elastyczność, będzie kiedykolwiek wykorzystane w przyszłości. To tak na poziomie samego kodu.

Można na to spojrzeć też na poziomie procesu, dodawania funkcjonalności. Nie chcę tutaj wymieniać marek konkretnych firm… Zresztą Apple’a możemy wymienić jako dobry przykład. Apple na początku wydał superprosty telefon, który robił dobrze to, co miał robić – wręcz rewelacyjnie w porównaniu do (nie wiem, czy tu słuchacze pamiętają) rysikowych palmtopów i Ballmera wyśmiewającego Apple’a. On to robił dobrze, mimo że nie robił dużo. Co robiły później inne firmy chińskie czy koreańskie, które wypuszczały telefony na Androidzie? Developowały trzysta różnych ficzerów, jakieś wykrywanie twarzy, tylko te funkcjonalności nie nadawały się do użycia. Więc uważam, że to też jest część jakości ostatecznego produktu i co za tym idzie – jakości oprogramowania. Lepiej zrobić pięć rzeczy, które działają świetnie, są przydatne i dostarczają użytkownikowi wartość, niż sto funkcjonalności, których może nikt nie używa.

Powiedziałbym, że na co dzień powinniśmy starać się automatyzować. Jeśli jakieś rzeczy są powtarzalne, to nie róbmy ich pięć razy. Pewnie można popatrzeć mocno na testy, można popatrzeć na pewne praktyki. Klasyczny przykład: dostarczanie nowej wersji na produkcję. Jeśli robimy to ręcznie, to może to powodować błędy, możemy się pomylić – pomijając fakt, że zajmuje nam to czas. Jeśli nie ma też automatycznych testów, to może ktoś je uruchomi, może nie. Nie wiemy też czy są one powtarzalne. Są oczywiście sytuacje, w których nie wszystko da się zautomatyzować lub w których zautomatyzowanie pewnych rzeczy byłoby niepraktyczne. Jednak takie nastawienie na automatyzację na co dzień jest dobrym podejściem.

Jest z tym troche powiązany temat skracania feedback loopu, o którym już wpsominaliśmy. Im szybciej dostaniemy informację zwrotną z jakichś mierników, od użytkowników czy np. z testów AB; im szybciej dostaniemy informację, jak nasz produkt ostatecznie performuje, tym lepiej, tym mamy większą szansę robić produkt dobrej jakości. Powinno to być nasza codziennością – dążenie do skrócenia, do szybszego otrzymywania informacji zwrotnych.

W codzienności nie wyobrażam sobie, żebyśmy mogli dobrze robić kod bez podstawowej praktyki – bez code review. Dlaczego code review? Nie tylko ze względu na literalnie rozumianą jakość (że drugi programista znajdzie błąd w moim kodzie albo zobaczy, że jest nieładnie napisany), ale ze względu na jakość przyczyniającą się do rozwoju zespołu i wzajemnego uczenia się. Code review – wbrew takiemu typowemu spojrzeniu na temat – to nie jest tylko i wyłącznie zapewnienie jakości tego kodu tu i teraz, ale zapewnienie rozumienia przez zespół pewnych praktyk.

Mówi się też o bus factorze – to taki współczynnik, który mówi o tym, ilu developerów (trochę drastycznie to brzmi) może zostać rozjechanych przez autobus, abyśmy nadal mogli rozwijać produkt. Jeśli nie mamy code review i tylko jeden developer zna dany kod, to jest duża szansa, że jak go potrąci autobus, to mamy problem.

Podsumowując: można stosować skracanie feedback loopu, wspomniane praktyki Continuous Integration, Continuous Delivery… Tutaj postawię gwiazdkę (może nie będę się teraz rozwodził) – polecam poczytać Fowlera na temat Continuous Integration, bo z mojego doświadczenia wynika, że większość osób źle rozumie ten temat. I to się wiąże z pytaniem dlaczego: dlaczego w ogóle Continuous Integration jest dobre. Ale to może kiedy indziej.

Na co jeszcze możemy spojrzeć? Tak jak mówiliśmy o wartości – redukowanie waste’u jest jakby tego przeciwnością. Czyli z jednej strony patrzymy, jaką wartość dostarczamy, a z drugiej strony patrzymy, co z tego, co robimy, jest niepotrzebne – tak na co dzień. To musi być naszą codzienną praktyką: spoglądanie na takie rzeczy.

Temat tabu – ciągła nauka, ciągły rozwój. To musi być naszą codziennością. Jeśli usłyszymy, że my w pracy mamy tylko robić i się nie uczyć, to jest to szybka droga do tragedii, bo gdzieś obok będzie firma, w której ludzie się uczą. Może dzisiaj mają oni wydajność dostarczania rzeczy na produkcję na poziomie x, ale dzięki nauce za dwa lata będą mieli 10x. Oczywiście to trzeba zbalansować. Mówię o tym prawie na końcu, ale jest to chyba najważniejsze z tych wszystkich rzeczy. Może dzisiaj nie wiemy, czym jest Continuous Integration lub o co chodzi z tym skróceniem loopu, ale jeśli będziemy się uczyć, jeśli zespół będzie się rozwijał i poświęcał na to czas, to prędzej czy później się dowie, prędzej czy później na to trafi.

I może taki banał, ale naprawdę niezwykle istotny: musimy zacząć od siebie, musimy nauczyć się mówić „nie”. To jest o odwadze, o tym, że jeśli widzimy, że ktoś od nas wymaga zrobienia czegoś nieprofesjonalnie ze względu na krótkoterminowe cele, to musimy umieć powiedzieć „nie”. Tak samo jeśli ktoś wymaga od nas zrobienia czegoś niezgodnie z tym, na co się wcześniej umówiliśmy, niezgodnie z ustalonymi standardami.

Oczywiście nie można być tu robotem. Są sprawy, w których czasami coś trzeba zrobić np. na szybko. Ale to muszą być naprawdę wyjątki, musimy mieć zaplanowane, jak naprawimy te skróty. Jak mamy jedno okno wybite w domu, to bardzo szybko pozwolimy sobie na to, żebyśmy mieli wybitych dziesięć. Trzeba być tu bardzo delikatnym i bardzo poważnie podejść do tego, żeby być strażnikiem jakości, żeby mówić „nie”. W takiej codzienności nauczenie się mówienia „nie” jest, uważam, dbałością o jakość.

Jaką książkę polecisz osobie, która chce tworzyć oprogramowanie dobrej jakości?

Przede wszystkim książka na wyższym poziomie ogólności, o podejściu, o tym, czym jest jakość w szerokim rozumieniu (nie nauczy nas kodować) to Software Craftsman Sandro Mancuso. Polecam ją też osobom, które nie programują. Co prawda autor mówi tam np. o ważności testów, ale mówi to takim językiem, który jest znośny dla wszystkich. Więc: dla osób które nie programują, ale też dla developerów – żeby poszerzyć sobie horyzonty i spojrzeć szerzej na to, czym jest dostarczanie jakości.

Tym, którzy chcą już zejść do samego kodu i uczyć się dobrych praktyk jego pisania, na pewno polecam książki Boba Martina (pseudonim Uncle Bob). Jest tam cała seria książek – mamy Clean Code, Clean Architecture, Clean Agile, a także książki innych autorów. Zdaje się, że nawet wcześniej wspominany Software Craftsman Sandro Mancuso także jest częścią tej serii wydanej przez Boba Martina.

Polecam spojrzeć na DevOps Handbook, który bardzo ładnie tłumaczy, czym jest idea DevOps. Dzisiaj nie zdążyliśmy tego tematu poruszyć, to są naprawdę szerokie zagadnienia, ale jest cała idea kultury DevOps i ona trochę łączy wiele różnych obszarów wytwarzania oprogramowania – jak robić to lepiej i bardziej multidyscyplinarnie. Wspaniała lektura, otwiera oczy. Nawet samo przejrzenie spisu treści na Amazonie (jest to za darmo) też potrafi zastanowić: „O, tak? Rzeczywiście o to chodzi?”.

Z takich bardziej miękkich książek, historyjek o podejściu: Pragmatyczny programista. Dosyć klasyczna książka. Ma już swoje lata, ale myślę, że tam prawda o podejściu do jakości jest bardzo ładnie opowiedziana.

Jeśli chodzi o Pragmatycznego programistę, to ostatnio było chyba poprawione rewydanie, więc jest zaktualizowane.

Możliwe. Dosyć dawno ją czytałem, ale ta analogia o jednym wybitym oknie pochodzi chyba właśnie z Pragmatycznego programisty.

Myślę, że tak. Chciałeś jeszcze polecić autorów.

Tak. Na pewno wspomniałbym o Fowlerze. Ma on książki, ma też fajny blog. Dużo pisze o wielu fundamentalnych koncepcjach wytwarzania oprogramowania, również z punktu widzenia architektury.

Poleciłbym jeszcze Kenta Becka i Boba Martina, o którym już wcześniej wspominaliśmy.

Gdzie możemy Cię znaleźć w sieci?

Ze względu na to, że jestem aktywny zawodowo, to najwięcej jestem na LinkedInie. Czasami można mnie spotkać też na Twitterze, ale rzadziej. Pisuję na blogu SYZYGY – firmy, w której aktualnie pracuję – i (temat dosyć świeży, zresztą powiązany z tym, o czym dzisiaj rozmawiamy) angażuję się w organizację eventu, meet upu ludzi, którym zależy na jakości oprogramowania, takiego, na którym moglibyśmy wymieniać się podejściem, doświadczeniami, opowiadać też o jakości. To meet up o nazwie Dobry Craft dostępny na stronie dobrycraft.software. Nie chcę tu za bardzo robić reklamy, najwyżej to wytniesz.

W zasadzie będzie jeszcze o tym mowa – będzie meet up w Warszawie, na którym będzie się można spotkać. Będzie też nagranie w sieci.

Tak, taki jest plan. Naprawdę chciałbym podziałać w kierunku zwiększania świadomości – że nie musimy tak bać się tej jakości, możemy wchodzić głębiej i mieć ostatecznie więcej satysfakcji z tego całego biznesu IT.

Myślę, że tak. Niedługo pewnie się przekonamy, bo będziemy mogli posłuchać, pooglądać, powymieniać się swoimi spostrzeżeniami.

Dziękuję Ci, Andrzeju, za dzisiejszą rozmowę i podzielenie się z nami swoimi doświadczeniami.

Również dziękuję, było mi bardzo miło. Mam nadzieję, że zainspiruje to słuchaczy do tego, żeby bardziej eksplorować temat jakości.

Jeśli jakość oprogramowania jest dla Ciebie istotna, to jeszcze raz zapraszam Cię na wydarzenie Dobry Craft.