Kto płaci za naprawę błędów podczas wdrożenia?

Za naprawę błędów w systemach IT płaci klient.

Jest to standardowa procedura, popularnie stosowana przez dostawców i wdrożeniowców oprogramowania. Wynika ona z faktu, iż rozwiązywanie problemów to nieodłączny element pracy nad funkcjonalnością systemów.

Niezależnie od tego, w jakim modelu (Waterfall czy Agile) zorganizowano projekt oraz, w jakim systemie (Fixed Price czy Time&Material) się go rozlicza – błędy w kodzie na pewno wystąpią i na pewno zostaną uwzględnione w koszcie wdrożenia.

Inna sprawa, czy jesteście tego świadomi od samego początku, czy może dowiadujecie się, jak i dlaczego tak to działa dopiero w trakcie trwania umowy.

Chcesz uniknąć przykrych niespodzianek i zaskakujących opłat podczas swojego kolejnego wdrożenia?

Zapraszam do artykułu.

Bug — co to takiego?

Bugi, czyli błędy w kodzie systemu to nieoczekiwane zachowanie oprogramowania, które sprawia, że nie działa ono zgodnie z zamierzeniami.

Mogą się one objawiać na różne sposoby: od drobnych problemów wizualnych, przez nieprawidłowe działanie określonych funkcji, aż po poważne awarie systemu, które uniemożliwiają jego dalsze użytkowanie.

Wynikają też z różnych przyczyn takich jak: pomyłki w kodzie, nieprzewidziane interakcje między różnymi częściami systemu czy niekompletne lub niejasne wymagania projektowe.

Skąd się wzięła nazwa „bug”?

Nazwa „bug” w odniesieniu do błędu w oprogramowaniu ma ciekawe pochodzenie i jest związana z wczesnymi dniami elektroniki i informatyki.

Jednym z najbardziej znanych i często przywoływanych źródeł terminu „bug” jest anegdota z 1947 roku, kiedy to grupa inżynierów pracujących na komputerze Mark II na Uniwersytecie Harvarda odkryła, że przyczyną awarii urządzenia była… prawdziwa ćma.

Insekta znaleziono zablokowanego w przekaźniku elektromechanicznym komputera. Po usunięciu ćmy, inżynierowie zapisali w swoich notatkach, że „wyeliminowano bug”. Rzeczony owad został nawet wklejony do ich dziennika pracy.

Od tamtego czasu terminy „bug” oraz „debugging” (proces znajdowania i usuwania błędów) zaczęły być szeroko stosowane w odniesieniu do wszelkiego rodzaju błędów i problemów w systemach komputerowych.

Rodzaje błędów (i sposoby ich niwelowania)

Trudno sobie wyobrazić sytuację, w której błędów w oprogramowaniu dałoby się całkowicie uniknąć. Choć staranność projektowania, testowania oraz implementacji ma na celu ich minimalizację, całkowite uniknięcie błędów jest praktycznie niemożliwe. Wynika to z kilku czynników, często pozostających poza pełną kontrolą zespołów deweloperskich.

Oto kilka przyczyn, które prowadzą do błędów w oprogramowaniu.

W celu minimalizacji ryzyka wystąpienia błędów logicznych, warto zastosować praktykę Code Review. 

Polega ona na ponownym sprawdzeniu fragmentu kodu przez osobę trzecią, najczęściej innego doświadczonego programistę czy programistkę.

Służy to wczesnemu wykrywaniu błędów logicznych i ich natychmiastowej naprawie, jeszcze przed przekazaniem gotowej funkcjonalności do dalszych testów.

Aby zredukować liczbę błędów UI, wymagaj etapu Usability Testing. 

Badanie użyteczności powinno się odbywać na kilka sposobów:

Rekomendowaną praktyką jest wdrożenie regularnych audytów bezpieczeństwa oraz stosowanie zasady Secure Coding.

Dodatkowo warto korzystać z narzędzi do automatycznego skanowania kodu oraz organizować testy symulujące ataki na system w kontrolowanych warunkach.

Przykładem takiej poważnej awarii jest niedawna historia z wadliwym sterownikiem w oprogramowaniu antywirusowym firmy CrowdStrike.

Aby zapobiegać tego typu sytuacjom, konieczne jest dokładne testowanie oprogramowania pod kątem jego wydajności i stabilności, zwłaszcza w scenariuszach dużego obciążenia (Load & Stress Testing).

Ponadto, warto zdawać sobie sprawę, iż także po zakończeniu wdrożenia niezbędne będą: stałe monitorowanie działania systemu oraz regularne aktualizacje (Upgrade).

Są one niezbędne, ponieważ technologia stale się rozwija i po czasie niektóre rozwiązania mogą być mniej odporne na ataki hakerskie albo stać się niekompatybilne z nowszymi elementami platformy.

Z pomocą przychodzą wówczas testy regresji i/lub testy automatyczne.

Tego typu błędy wynikają często z braków w specyfikacji lub ze zmieniających się potrzeb biznesowych.

Aby im przeciwdziałać, należy uwzględnić:

Metodyka wdrożeniowa a reguły gry w projektach

Analizując kwestię naprawy błędów w systemach IT, warto zacząć od zrozumienia metodyki, w której realizowane są prace deweloperskie.

W dość dużym skrócie, Waterfall to tradycyjny, raczej przestarzały sposób organizacji pracy w projektach IT.

Stosuje się go zwykle w ekstremalnych przypadkach, w których za zasadne uznano wytworzenie obszernej dokumentacji i uzgodnienie stałej ceny (Fixed Price) za zgodny z jej zapisami system.

Ryzyko polega tutaj na tym, iż jeszcze przed rozpoczęciem prac, trzeba skomponować sztywny opis, a także skrupulatny harmonogram projektu.

Gdyby realizacja systemu zajęła mniej czasu niż przewidywano, klient i tak uiszcza uzgodnioną z góry wartość. Nie będzie przy tym możliwości zgłoszenia nowych potrzeb czy doprecyzowania istniejących w trakcie wdrożenia. Gdyby je rozpoznano, należy sporządzić aneks do obowiązującej umowy i tam zawrzeć warunki ich rozliczenia. Ewentualnie w umowie trzeba będzie przewidzieć specjalną procedurę rozpatrywania zmian, a to kolejna rozbudowana, trudna do przeprowadzenia formalność.

Z uwagi na to, że przy już średnio skomplikowanych projektach nie ma możliwości przewidzenia wszystkiego i dewaluacja potrzeb jest bardzo szybka, nie istnieją projekty waterfallowe, które nie wymagają zwiększenia budżetu i zarządzania zmianami.

Którą metodykę wdrożeniową wybrać?

Poznaj podstawowe różnice, a także wady i zalety podejścia Agile vs Waterfall

POBIERZ E-BOOK

Zdecydowanie bardziej powszechny i ogólnie rzecz ujmując rekomendowany sposób współpracy w projektach IT to Scrum.

Polega on na realizacji zadań w zazwyczaj dwu- lub czterotygodniowych okresach (Sprintach) i rozliczaniu się za czas i zasoby (Time&Material) poświęcone na realizację konkretnego efektu.

Zgodnie z jego zasadami: w projekt wdrożeniowy, poza zespołem deweloperskim, aktywnie zaangażowany jest też przedstawiciel klienta –Product Owner, który czuwa nad całością prac, tj. zleca, ocenia wartość, koordynuje, komunikuje się na bieżąco, z dostawcą, testuje i zatwierdza wszelkie zmiany.

Naprawa błędów w trakcie wdrożenia

Jak wynika z powyższego rozróżnienia trochę inaczej wygląda współpraca na zasadach Waterfall i Agile/Scrum. Inaczej się też te projekty rozlicza. W obu przypadkach jednak — zarówno za rozwój funkcjonalności jak i naprawę błędów — płaci klient. Może być tego jednak mniej lub bardziej świadomy czy świadoma.

Różnica między User Story a User Story Bug

Żeby jeszcze lepiej zrozumieć kwestię rozliczania się za naprawę błędów, dobrze jest też rozróżniać jeszcze kilka dodatkowych (obowiązujących w Scrum) pojęć.

Wdrożenie oprogramowania (zgodnie z metodyką Agile/Scrum) odbywa się na podstawie tzw. User Stories.

Jak sama nazwa wskazuje, chodzi o historyjki z życia użytkownika systemu, które opisują rozpoznaną potrzebę.

User Story to zwięzły opis funkcji, która ma zostać włączona (zaimplementowana) do systemu.

User Story w zrozumiały, nietechniczny sposób przedstawia: co użytkownik chce osiągnąć, poprzez jakiego typu rozwiązanie systemowe oraz, jakie korzyści z tego wynikają.

Dodatkowo określane są kryteria, które User Story musi spełnić, aby zagadnienie uznać za zrealizowane. W ramach kryteriów definiowane są także sposoby techniczne na osiągnięcie celu.

Format User Story zazwyczaj wygląda w następujący sposób:

Jako [rola użytkownika], chcę [funkcja], aby [cel biznesowy/korzyść].
Kryteria:

Przykład User Story:

Jako pracownik działu sprzedaży,
chcę mieć możliwość wskazania wielu pozycji na ofercie,
ponieważ zamierzam przedstawić klientowi cenę dla wszystkich poszczególnych produktów objętych ofertą oraz sumaryczną cenę całej oferty.

Kryteria:
Dla każdej z ofert powinna być możliwość dodania wielu Pozycji ofert o następujących atrybutach:
- Nazwa produktu [Wybór produktu z katalogu]
- Ilość [Liczba zmiennoprzecinkowa]
- Cena jedn. [Pole walutowe]
- Cena całkowita [Pole walutowe]
Cena całkowita wszystkich pozycji powinna być automatycznie obliczana na ofercie w polu Sumaryczna wartość oferty [Pole walutowe]

Szczególny przypadek User Story, to sytuacja, w której napotkaliśmy błąd, a naszym celem jest jego wyeliminowanie.

Wówczas mówimy o User Story Bug, czyli błędzie w historyjce użytkownika.

User Story Bug odnosi się do sytuacji, w której w istniejącej funkcji występuje błąd lub problem, który wpływa na doświadczenie użytkownika.

W przypadku User Story Bug, zespoły programistyczne, zamiast budować nowe rozwiązanie, skupiają się na naprawie istniejącej funkcjonalności. User Story Bug jest zgłaszany wtedy, gdy oprogramowanie nie spełnia założeń zdefiniowanych w oryginalnej historii użytkownika lub zachowuje się niezgodnie z oczekiwaniami.

Przykład User Story Bug:

Użytkownik: Jan Kowalski
Wykonane kroki: Utworzenie oferty i dodanie 3 pozycji w kwotach 100zł, 200zł i 500zł
Otrzymany rezultat: Sumaryczna wartość całej oferty wynosi $800
Oczekiwany rezultat: Sumaryczna wartość całej oferty powinna wynosić 800zł

User Story	User Story Bug
Definiuje funkcję lub potrzebę użytkownika	Oznacza, że istniejąca funkcja nie działa zgodnie z kryteriami akceptacyjnymi
Opisuje, co nowego ma być zaimplementowane	Opisuje błąd, który trzeba naprawić
Dotyczy wytworzenia nowej funkcjonalności	Dotyczy naprawy błędu w istniejącej funkcji
Jego priorytet ustala się na podstawie wartości biznesowej lub pilności potrzeby	Zazwyczaj ma wyższy priorytet, szczególnie jeśli błąd wpływa na kluczowe funkcje lub doświadczenie użytkownika

Różnica między błędem krytycznym a niekrytycznym

Błędy w systemach IT zdarzają się też po zakończeniu etapu wdrożenia lub uruchomieniu pilotażowym (czyli wtedy, kiedy system jest już wykorzystywany produkcyjnie przez całą organizację lub jej część).

Zasady uregulowania takich nieprawidłowości określa najczęściej osobna umowa serwisowa (SLA).

Na tym etapie nie mówimy już o User Story Bug a o błędach krytycznych lub niekrytycznych. Ich klasyfikacja zależy od wpływu na funkcjonalność lub bezpieczeństwo systemu.

Błąd krytyczny to taki, który ma poważny wpływ na działanie systemu. 

Oznacza on, że aplikacja, system lub jego kluczowe funkcje przestają działać w sposób, który uniemożliwia normalne użytkowanie. Tego rodzaju błędy mogą powodować awarie, utratę danych, zagrożenia dla bezpieczeństwa lub sprawiać, że użytkownik nie jest w stanie kontynuować pracy.

Przykłady błędów krytycznych:

Priorytet naprawy: Błędy krytyczne są traktowane z najwyższym priorytetem i zwykle wymagają natychmiastowej interwencji, aby jak najszybciej przywrócić pełną funkcjonalność systemu.

W eVolpe częstą praktyką jest zobowiązanie do naprawy błędów krytycznych w ciągu 1 dnia roboczego (do 24 godzin od zgłoszenia).

Błąd niekrytyczny to taki, który powoduje drobne problemy w systemie, ale nie uniemożliwia jego normalnego użytkowania. 

Oznacza to, że oprogramowanie działa, choć może wykazywać irytujące nieprawidłowości. Błędy te mogą wpływać na wygodę korzystania z aplikacji, ale nie uniemożliwiają jej działania.

Przykłady błędów niekrytycznych:

Priorytet naprawy: Błędy niekrytyczne zazwyczaj mają niższy priorytet naprawy. Zespół może zdecydować się na ich naprawę w późniejszym terminie, jeśli nie wpływają one znacząco na ogólne działanie systemu.

Powszechnie stosowany w eVolpe zapis umowy SLA mówi o naprawie błędów niekrytycznych w ciągu 5 dni roboczych.

Błąd krytyczny	Błąd niekrytyczny
Ma poważny wpływ na działanie systemu	Powoduje problemy, ale nie umniemożliwa użytkowania systemu
Dotyczy: całkowitej awarii systemu, utraty danych, zagrożenia dla bezpieczeństwa, braku kluczowej funkcjonalności	Dotyczy: problemów estetycznych, znikomego ubytku funkcjonalności, zachowania systemu niezgodnego z oczekiwaniami
Wymaga natychmiastowej naprawy	Naprawa może być odłożona na późniejszy termin
Praktyka eVolpe: naprawa w 1 dzień roboczy	Praktyka eVolpe: naprawa w 5 dni roboczych

Różnica między Fixed Price a Time & Material

Ostatni zestaw pojęć, które warto wprowadzić do swojego słownika w związku z wdrożeniem lub serwisem systemu IT to: Fixed Price vs Time&Material.

Chodzi tutaj o dwa przeciwstawne modele rozliczania się za pracę w projektach IT.

Model Fixed Price (stałej ceny) to cecha charakterystyczna metodyki Waterfall. 

Cena za projekt jest w tym przypadku ustalona z góry. Klient i dostawca uzgadniają szczegółowy zakres projektu, harmonogram i budżet przed przystąpieniem do prac. Sporządzana jest też szczegółowa dokumentacja, która odzwierciedla podjęte ustalenia.

W niektórych opracowaniach można znaleźć informację, iż rozliczając się w ten sposób nie płaci się za błędy. Nie jest to prawda. W praktyce błędów w oprogramowaniu po prostu nie da się uniknąć.

Wynika to z tego, że stopień złożoności projektów IT jest bardzo wysoki, a dodatkowo powiązania pomiędzy różnymi elementami systemu mogą być na tyle zawiłe, że dodanie każdego kolejnego elementu może mieć wpływ na działanie systemu, który nie jest możliwy do przewidzenia.

W związku z tym firmy wdrożeniowe zawsze wliczają w Fixed Price pewien bufor na naprawę potencjalnych błędów, żeby utrzymać odpowiednią rentowność projektu.

Może się zatem wydarzyć nawet tak, że stosując model Fixed Price (chociaż nie będzie tego widać na fakturze) zapłacisz za bugi, które nie wystąpiły, a na których wypadek dostawca się zabezpieczył.

W modelu Time & Material klient płaci za rzeczywisty czas pracy (stawka godzinowa lub dzienna) i zasoby wykorzystane podczas projektu. 

Jest to o wiele bardziej elastyczny sposób rozliczania się za efekty, charakterystyczny dla metodyki Agile/Scrum.

Co więcej, w tym przypadku zmiana wymagań może być zgłoszona na dowolnym etapie, a to dlatego, że zazwyczaj NIE POWSTAJE szczegółowa dokumentacja, której należałoby się sztywno trzymać.

Zamiast tego stosowany jest elastyczny Product Backlog złożony historyjek użytkownika (User Stories). Najczęściej prowadzi się go w interaktywnym systemie projektowym, np. Redmine czy Jira.

Oznacza to, że do realizacji na bieżąco trafiają tylko takie funkcje, które są aktualnie najbardziej potrzebne. Przeterminowane zgłoszenia, jeśli sytuacja rynkowa się zmieniła, można bez problemu pominąć.

Cały proces odbywa się też w ramach przyjętego budżetu i to Product Owner (koordynator z ramienia klienta) wraz ze wsparcie Proxy Product Ownera (koordynatora z ramienia dostawcy) ustala: na co i w jakiej kolejności jest on przeznaczany.

Między innymi dlatego, że klient bierze czynny udział w projekcie oraz po testach zatwierdza zrealizowane User Stories – naprawa błędów w Scrum jest również płatna.

Cena do zapłaty ustalana jest analogicznie do prac polegających na wytwarzaniu nowych funkcji, tj. w modelu Time & Material.

Fixed Price	Time&Material
Stała cena	Cena uzależniona od poświęconych zasobów i czasu
Wymaga szczegółowej dokumentacji	Wystarczy Product Backlog (historyjki użytkownika)
Naprawa błędów w cenie (wliczona w Fixed Price na zasadach zakładanego z góry buforu)	Naprawa błędów płatna zgodnie z tym, ile czasu i zasobów wykorzystano
Brak możliwości ingerowania w budżet, zakres prac i harmonogram	Kontrola budżetu, zakresu i harmonogramu przez Product Ownera
Każda zmiana wymaga renegocjacji umowy/dokumentacji i procedury zarządzania zmianą	Zmiana jako coś naturalnego na każdym etapie procesu wdrożenia

Jak nie płacić za błędy w Scrum?

Obawiasz się przepalania budżetu na naprawę błędów w Scrum?

Wybór metodyki Waterfall Cię przed tym NIE UCHRONI.

Wręcz przeciwnie, decydując się na ten tradycyjny sposób realizacji projektów, ryzykujesz płaceniem za błędy, które nigdy się nie pojawiły.

Dzieje się tak dlatego że w modelu Fixed Price dostawcy powszechnie wliczają do ceny dodatkowy koszt na wypadek nieprzewidzianych problemów. Godząc się na taki stały budżet płacisz zatem za błędy niezależnie od tego, czy faktycznie się zdarzą.

Co więcej, w przypadku Waterfall nie ma również możliwości 100% definicji wymagań i wszystkich możliwych przypadków (pomimo bardzo szczegółowej dokumentacji). W konsekwencji jeżeli dana funkcja nie została opisana w sposób jednoznaczny, dostawca może odmówić naprawy błędu, nawet jeżeli z perspektywy klienta działanie systemu jest niepożądane.

Może to dotyczyć zarówno wymagań biznesowych (np. system teoretycznie działa zgodnie ze specyfikacją, ale w rzeczywistości proces wykonywany jest sposób nie user-friendly i użytkownik wykonuje mnóstwo zbędnych kroków, żeby go przeprowadzić) lub wymagań funkcjonalnych (np. pole X miało być z perspektywy klienta nieedytowalne dla nikogo, ale w innym miejscu specyfikacji jest zapis, że osoba z uprawnieniami administratora może edytować wszystkie rekordy).

W tym momencie każda ze stron ponosi także dodatkowe koszty na wyjaśnienie powyższych sytuacji, które dostawca oczywiście wliczył w swój bufor.

O wiele skuteczniej zarządzisz swoim budżetem, jeśli postawisz na Scrum.

Wówczas nie tylko aktywnie uczestniczysz w tworzeniu całego systemu (od projektowania wymagań, po ich selekcję i zatwierdzanie i na koniec testowanie systemu), ale zachowujesz całkowitą kontrolę nad wydatkami w projekcie.

Zespół deweloperski na bieżąco szacuje dla Ciebie koszt realizacji wprowadzonych do Backlogu User Stories. Dzięki temu decyzję o tym, co i w jakiej kolejności ma zostać wytworzone (lub naprawione), podejmujesz zawsze na podstawie informacji o prawdopodobnym koszcie omawianej funkcji.

Oczywiście istnieje szansa, że zapłacisz odrobinę więcej, jeśli wystąpią nieprzewidywane czynniki, ale jeśli zespół wytworzy coś szybciej lub przedstawie altenatywną i tańszą, ale ciągle akceptowalną opcję – zapłacisz mniej.

Poza tym, jeśli zaniepokoi Cię tempo wydatków, po prostu wstrzymujesz realizację dodatkowych zleceń. System będzie nadal działał, umożliwiając zastosowanie dotychczas wytworzonych funkcji. W przypadku Waterfall taka opcja nie istnieje. I nawet jeżeli już na początkowym etapie odniesiesz wrażenie, że dostawca nie do końca należycie wypełnia swoje obowiązki, zazwyczaj z formalnego punktu widzenia należy zrealizować umowę wdrożeniową pomimo tego.

Gwarancja na autorskie elementy kodu

Po pierwsze, od firmy wdrożeniowej, z którą współpracujesz, warto wymagać dodatkowych zabezpieczeń formalnych.

Umowy scrumowe bardzo często zawierają zapisy przyznające kilkumiesięczną gwarancję na autorskie elementy kodu.

W praktyce eVolpe powszechnie stosowana jest zasada 3-miesięcznej ochrony anti-bug.

Przez wskazany okres nie zapłacisz zupełnie nic za naprawę błędów dotyczących autorskich elementów kodu.

Uwaga na stawki i skład zespołu

Warto też rozmawiać o składzie zespołu deweloperskiego przydzielonego do Twojego projektu.

Z założenia doświadczeni programiści popełniają o wiele mniej pomyłek i są w stanie szybciej zidentyfikować przyczynę błędu. Sprawniej też się jej pozbędą.

Z drugiej strony zespół składający się z samych seniorów może mieć większe skłonności do konfliktów, brakować mu może świeżego spojrzenia oraz może dochodzić do frustracji w przypadku konieczności wykonywana trywialnych zagadnień, które zazwyczaj przypadają juniorom.

Oczywiście stawki godzinowe Senior- czy Mid-Developerów mogą się różnić od stawek juniorskich.

Rekomendowane podejście zakłada zbilansowanie doświadczenia członków zespołu oraz kosztów, które będą generować w rozliczeniu Time & Material.

Wskazówka od eVolpe: Przed podpisaniem umowy wdrożeniowej zamiast górnej granicy budżetu negocjuj stawki poszczególnych członków zespołu deweloperskiego. Pamiętaj przy tym, że w jego skład -  oprócz programistów - wchodzą także: specjaliści IT, analityk (proxy product Owner), Scrum Master czy w przypadku kompleksowych projektów - Project Manager.

Strategia unikania błędów

Żeby nie płacić za naprawę błędów, najprościej jest ich po prostu unikać.

Oczywiście przy wytwarzaniu oprogramowania nie jest w pełni możliwe ich całkowite wyeliminowanie.

Będzie ich jednak zdecydowanie mniej, jeśli na poważnie potraktujesz etap testów i zatwierdzania przyrostów funkcjonalności po każdym Sprincie.

1. Wyznacz Product Ownera

Oprócz doświadczonego zespołu deweloperskiego przyda Ci się zatem zaangażowany, decyzyjny Product Owner (koordynator z ramienia Twojej firmy).

9 cech dobrego Product Ownera

Sprawdź, kto z Twojej firmy nadaje się na koordynatora projektu wdrożeniowego.

POBIERZ E-BOOK

Osoba ta pełni funkcję łącznika między zespołem wdrożeniowym po stronie dostawcy a klientem, dbając o to, by ostateczny produkt odpowiadał Twoim oczekiwaniom. Powinna być nie tylko dobrze zorientowana w szczegółach technicznych, ale przede wszystkim osoba bardzo dobrze znająca specyfikę organizacji i jej procesy, a także posiadająca pełnomocnictwo do podejmowania decyzji, które nadadzą kierunek rozwoju oprogramowania.

Jego lub jej czynne zaangażowanie w projekt, szczególnie na etapie projektowanie nowych funkcji i testów i zatwierdzania kolejnych funkcji, jest kluczowe dla sukcesu wdrożenia oraz niwelowania liczby popełnianych przy tym błędów.

2. Korzystaj z narzędzi, jakie oferuje Scrum

Żeby ograniczyć ilość błędów w systemie warto jest też korzystać z narzędzi, które oferuje zwinna metodyka wdrożeniowa.

Kiedy zagłębisz się w zasady, jakimi się cechuje Scrum, dostrzeżesz ile masz możliwości reakcji.

W trakcie spotkań Sprint Review zweryfikujesz, co zespół osiągnął w ciągu ostatnich dwóch tygodni (czyli w konkretnym Sprincie). Jest to też okazja do bezpośredniego kontaktu z programistami i analitykami, oceny postępów, a także empiryczne sprawdzenie jak fukcjonuje system w obecnej wersji, w jaki sposób realizowane są jego poszczególne funkcje, jak wyglądają kwestie ergonomii itp.

Sprint rozpoczyna się od zaplanowania prac, tj. skomponowania zestawu User Stories do implementacji. To wtedy ustala się, co można dostarczyć w kolejnym terminie i jak ta praca zostanie zrealizowana. Wtedy też Zespół ustala finalnie sposób realizacji poszczególnych zagadnień, a klient akceptuje zakres prac.

Postępy weryfikowane są na bieżąco. Służą temu codzienne spotkania Daily Stand Up, podczas których omawiany jest status osiąganych efektów, a także kwestie do ewentualnego rozwiązania.

W ramach Sprintu odbywa się również tzw. Refinement. Tego typu spotkanie dedykowane jest nowym wymaganiom, które zgłasza klient. Służy ono doprecyzowaniu, podzieleniu oraz oszacowaniu zagadnień, które trafią do zestawu zaakceptowanych User Stories (Backlogu). Będą one konsekwentnie realizowane, zgodnie z nadanym priorytetem w kolejnych Sprintach.

Po skutecznym Sprint Review jest też czas na Retrospektywę. To dodatkowe spotkanie, które służy identyfikacji dobrych praktyk oraz niwelowaniu problemów do rozwiązania w procesie, co w konsekwencji przekłada się na zwiększenie efektywności zespołu projektowego.

Wszystkie wymienione etapy sprzyjają przy okazji wczesnej identyfikacji bugów. Wyłapanie takich nieścisłości jeszcze przed startem produkcyjnym systemu znacznie ogranicza ryzyko późniejszych poprawek.

3. Uwaga na proces!

Bardzo dobrą praktyką w Software Development jest tzw. self-testing, czyli testy własne przeprowadzane przez programistów jeszcze na etapie tworzenia rozwiązania.

Dodatkowo popularnie stosowana metoda to Code Review, czyli weryfikacja poprawności kodu przez osobę trzecią (najczęściej innego doświadczonego programistę).

Dopiero po upewnieniu się, iż wszystko działa jak przewidziano, konkretna funkcja trafia do oceny przez wykwalifikowany zespół testerów.

W automatycznych i manualnych testach wezmą oni pod uwagę perspektywę użytkownika oraz działanie rozwiązania w różnorodnych, często nietypowych okolicznościach, np. na różnych typach urządzeń.

Ich głównym zadaniem jest wytropienie błędów zanim konkretne rozwiązanie zostanie przedłożone Product Ownerowi.

Gdyby znaleźli jakieś nieścisłości, sprawa wraca do programistów, którzy kontynuują wysiłki, by zabezpieczyć system na przyszłość.

4. Testuj nowe funkcje

Ostatnie ogniwo łańcucha testów stanowi klient.

Możesz mieć pewność, że żadna nowa funkcjonalność nie trafi na produkcję bez Twojej akceptacji. Wymagany wcześniej etap to weryfikacja nowych elementów systemu przez Product Ownera w środowisku testowym.

Dopiero tak dokładnie zbadany, przetestowany feature może być włączony do oficjalnej instancji narzędzia, do której mają dostęp użytkownicy końcowi.

Podsumowanie

Występowanie i naprawa błędów w systemach IT jest nieodłącznym elementem procesu wdrożeniowego. W mniej lub bardziej transparentny sposób koszty takiego stanu rzeczy zawsze ponosi klient.

W metodyce Waterfall naprawa błędów jest wliczana w stały budżet (Fixed Price), który należy uiścić bez względu na to, czy i jakie problemy występowały.

W przypadku Agile/Scrum i modelu rozliczeniowego Time & Material cena za system jest elastyczna i zależy od tego, co jest zlecane przez Product Ownera oraz ile czasu i zasobów poświęca na to zespół deweloperski.

W taki sam sposób rozlicza się zarówno nową funkcjonalność (User Story) jak i naprawę błędów (User Story Bug).

Dodatkowo kluczem do unikania kosztów związanych z naprawą błędów są:

Aby zminimalizować koszty naprawy błędów, warto zadbać o dodatkowe zapisy w umowie, które zagwarantują:

Umów konsultację z ekspertem wdrożeniowym eVolpe

Wybierz dogodny dla siebie termin.