RÓWNIEŻ NA BLOGU:
Czy można tworzyć oprogramowanie bez błędów?
„Błędy nie zdarzają się tylko tym którzy nic nie robią”, to stare powiedzenie nie powinno być wymówką, tylko impulsem do przygotowania organizacji na ich wystąpienie. Tworzenie i wdrażanie aplikacji to proces, który jak wszystko czym zajmują się ludzie jest obszarem zagrożonym błędami. W praktyce uniknięcie błędów jest bardzo trudne, można jednak mocno ograniczyć ich występowanie poprzez właściwe działania ograniczające ryzyko.
Często słyszę od różnych osób proste rozwiązania, które zapewnią brak błędów. „Świętym Gralem” jakości aplikacji bywa testowanie, niekiedy utyskuje się na słabą jakość dokumentacji, innym razem z nadzieją przywołuje się technologię proponując automatyczne testowanie i publikowanie kodu. To wszystko brzmi dobrze, ale w rzeczywistości o jakości aplikacji decyduje kompletny system, który mógłby zapewnić całkowite wykluczenie błędów, gdyby można było go w realnym świecie zastosować, niestety bardzo rzadko jest to możliwe. W dzisiejszym wpisie opowiem właśnie o metodach redukcji prawdopodobieństwa wystąpienia błędów, a na koniec wyjaśnię dlaczego poruszyłem ten temat.
Kompletny system kontroli jakości składa się z pięciu głównych obszarów, które tworzą procedury organizacyjne (przedwdrożeniowe i wdrożeniowe), dobre praktyki programistyczne, wielopoziomowe testowanie, narzędzia i technologie, dokumentowanie przebiegu projektu i edukowanie członków zespołu. Najczęstszym statystycznie powodem powstawania błędów jest brak dostatecznie dobrze opisanych wymagań, co powoduje powstawanie nieporozumień między zespołem technicznym a biznesem. Opisywanie wymagań postrzegam jako element kluczowy. Pozostałe kwestie organizacyjne jak stosowanie zwinnej metodyki realizacji projektów informatycznych oraz bieżące rozwiązywanie wszelkich niejasności ma rosnące wraz ze skalą projektu znaczenie i także jest ważne.
W praktyce obserwuję, że najwięcej błędów wychodzi nie w fazie testów, lecz po wdrożeniu – kiedy użytkownik końcowy zaczyna korzystać z aplikacji zgodnie ze swoimi przyzwyczajeniami i oczekiwaniami, które często nie zostały wcześniej zwerbalizowane. Czasami jest to efekt zbyt ogólnego opisu funkcji, czasem interpretacji jednego pojęcia na różne sposoby przez różne osoby. Dlatego dokumentacja – nie tylko kodu, ale też decyzji projektowych i ustaleń z klientem – nie powinna być traktowana jako biurokracja, lecz jako fundament porozumienia. W tym kontekście niezwykle przydatne okazują się spotkania analityczne z udziałem wszystkich stron projektu oraz prototypowanie interfejsów, które pozwala wychwycić błędne założenia zanim kod w ogóle powstanie.
Nie da się też pominąć znaczenia praktyk programistycznych. Jakość kodu ma bezpośrednie przełożenie na stabilność systemu – tu nie chodzi tylko o to, czy „coś działa”, ale czy działa zgodnie z założeniami, w przewidywalny sposób i będzie dało się to utrzymać za pół roku. Regularne przeglądy kodu, stosowanie wspólnego stylu, pisanie testów jednostkowych i unikanie zbyt złożonych rozwiązań – to codzienność, która w dłuższej perspektywie daje największy zwrot. Technologie mogą pomagać, ale bez zespołu, który rozumie ich sens i stosuje je świadomie, nie będą miały większego znaczenia.
Z perspektywy organizacyjnej kluczowe jest także wdrożenie automatyzacji. Automatyczne testy, budowanie i wdrażanie aplikacji oraz monitoring po wdrożeniu nie tylko zwiększają efektywność, ale też pozwalają szybciej reagować na pojawiające się problemy. W ten sposób skraca się czas od wykrycia do naprawy błędu, co w wielu projektach jest jednym z najważniejszych czynników wpływających na postrzeganą jakość.
Nie sposób też pominąć roli edukacji. Wysoka jakość nie wynika jedynie z kompetencji technicznych, ale z postawy zespołu. Jeśli ludzie wiedzą, jak działa cały proces, rozumieją swoje miejsce w systemie, wiedzą jakie konsekwencje może mieć pozornie niewielkie niedopatrzenie – wtedy działają inaczej. Lepsze zrozumienie procesu i otwarta komunikacja wewnątrz zespołu często pozwalają wyeliminować błędy zanim w ogóle się pojawią.
Temat ten poruszam, ponieważ w naszej codziennej pracy wdrożeniowej spotykamy się z różnymi oczekiwaniami wobec jakości. Z jednej strony naturalna jest chęć, by wszystko działało perfekcyjnie od pierwszego dnia. Z drugiej – świadomość, że jakość to nie przypadek, tylko rezultat konkretnych decyzji, działań i standardów, które trzeba wdrożyć i konsekwentnie stosować. To właśnie różnica między podejściem reaktywnym („coś nie działa, trzeba poprawić”), a proaktywnym („zróbmy to tak, żeby zminimalizować ryzyko problemów”).
Dobrze zaprojektowany system zapewnienia jakości nie eliminuje całkowicie błędów, ale pozwala zarządzać nimi świadomie, szybko reagować, uczyć się i stale podnosić poziom pracy zespołu. A to – niezależnie od wielkości projektu – przynosi największe korzyści, myślę, że takie podejście wyróżnia Wayman.
autor: Piotr Bilon
Projekt i realizacja Spectrum Marketing | 2023 Wszelkie prawa zastrzeżone.
Poznaj system Wayman
Social media
Wayman Sp. z o.o.
ul. Piotra Skargi 14/2, Gdynia
ul. Pawia 9, piętro 1, Kraków (Biurowiec High5ive)