Scrum a błędy na produkcji

Klasyfikacja błędów

Bugi klasyfikujemy ze względu na DOLEGLIWOŚĆ oraz ZŁOŻONOŚĆ. Każda z tych klasyfikacji może osiągnąć poziom WYSOKI lub NISKI. Każdy bug możemy przyporządkować do jednej z czterech kombinacji tej klasyfikacji.

  • Wysoka złożoność i wysoka dolegliwość.
  • Niska złożoność i wysoka dolegliwość.
  • Wysoka złożoność i niska dolegliwość.
  • Niska dolegliwość i niska złożoność.

Wysoka dolegliwość

Wysoka dolegliwość jest wtedy gdy system stoi, klienci dzwonią, szef grozi brakiem premii, której i tak już nikt się nie spodziewa po takiej akcji.

Niska dolegliwość

Niska dolegliwość jest gdy błąd nikomu nie przeszkadza, np. jakaś ikonka nie jest w odpowiednim miejscu lub wygląda inaczej. Inny przykład to taki gdzie zapomniano obsłużyć klawisz enter i dana opcja dostępną jest tylko po kliknięciu w dany element, itp.

Wysoka złożoność

Wysoka złożoność jest wtedy gdy naprawa błędu wymaga przepisania jakiegoś popsutego modułu aplikacji, jego usunięcie wymaga zastosowania innego algorytmu, zmiany technologi, itp. Najczęściej niska wydajność jest złożonym błędem.

Niska złożoność

Niska złożoność jest wtedy gdy usunięcie błędu zajmuje znacznie mniej czasu niż jego zdiagnozowanie. Usuwalny w czasie nie dłuższym niż jeden dzień.

Wysoka złożoność i wysoka dolegliwość

Nic nie działa i nie wiadomo jak to naprawić, a jeśli już wiadomo to aby to naprawić należy poświęcić bardzo dużo czasu/zasobów.

Przerywamy sprint, przestajemy się skupiać na dowiezieniu wszystkich punktów w iteracji, stawiamy system na nogi. Wszyscy na pokład. Taka sytuacja występują tak rzadko, że nie ma sensu obudowywać tego typu zachowania w zasady Scrum’a. Nie ma sensu stosować również innych metodyk. Po prostu ratujemy się. Gdy zaczynają się zdarzać takie sytuacje często wówczas zastanawiamy się nad sensem pisania w tym projekcie nowych funkcjonalności.

Niska złożoność i wysoka dolegliwość

To błędy związane z zapuszczeniem się w dług technologiczny, które często są spowodowane niedostatecznym przetestowaniem aplikacji przed wdrożeniem na produkcję. Po wgraniu systemu wyskakują dziwne kwiatki, które trzeba jak najszybciej naprawić. Często się mówi że projekt musi się wygrzać – czyli muszą pospływać błędy od klienta, które naprawimy. Wtedy mamy sytuację z dużą ilością błędów, które nie mogą poczekać do końca iteracji.

Jeśli takich błędów pojawia się dużo wówczas zespół wyznacza wśród swoich członków zespołu dyżurnego, który zajmuje się naprawą takich zgłoszeń. W każdej iteracji lub co pół iteracji dyżurny zmienia się, tak aby ktoś nie był dyskryminowany i zdemontowany wykonywaniem czarnej roboty.

Inne rozwiązanie, które uważam, że się sprawdza to takie gdzie zakładamy pewien bufor punktów, który przeznaczamy na naprawę błędów nie wyznaczając konkretnej osoby w zespole. Scrum’owy zespół to zespół samo organizujący się. Zespół sam sobie decyduje kto dany błąd naprawi, korzystając z przyznanych punktów na tego typu zadania.

Po wyczerpaniu bufora punktów, decydujący głos ma Product Owner, który nadaje nowe priorytety pozostałym zadaniom. Wskazuje, które zadanie nie muszą być wykonane w tej iteracji na rzecz naprawy konkretnych błędów.

Nawet gdy tych błędów jest bardzo dużo tego typu podejście się sprawdza. Czarno na białym widzimy ile nowych funkcjonalności możemy w danej iteracji wykonać a ile czasu zabiera nam naprawianie błędów.

Gdy takie sytuacje są częste i uciążliwe oraz nie pozwalają na pracę zespołu zgodnie z metodyką Scrum, należy w pierwszej kolejności wziąć się za wprowadzenie poprawnych technik wytwarzania oprogramowania oraz zaprzestać zaciągać dług techniczny.

Wysoka złożoność i niska dolegliwość

Przykładem może być wyciek pamięci w aplikacji po stronie serwerowej. Wyciek ten jest stały w czasie i stopuje system raz na dwa miesiące. Wówczas jeśli specyfika działania systemu na to pozwala, można zaplanować restart tego systemu raz na miesiąc, w nocy, który trwa sekundy, podczas gdy mamy pewność, że w tym czasie nikt na tym systemie nie pracuje.

Błędy trafiają do Backlog’a i są kolejkowanie do wykonania przez Product Owner’a. Skoro jest wysoka złożoność błędu a dolegliwość jest niewielka to w danym momencie może po prostu nie opłacać się poświęcać dużo czasu na poprawę błędu. Możliwe, że są o wiele ważniejsze zadania na tą chwilę. Decyzję ma w tym przypadku właściciel produktu.

Oczywiście przykład błędu z wyciekiem pamięci musi być kiedyś naprawiony. Restart systemu jest tyko chwilowym rozwiązaniem do momentu jego naprawy, która jest precyzyjnie zaplanowana w przyszłych iteracjach.

Niska dolegliwość i niska złożoność

Jeżeli takich błędów jest niewiele, wówczas należy poprawiać je w ramach codziennej pracy programisty. Jest taka zasada, która mówi aby zostawić po sobie kod lepszym niż się zastało. Wybór błędów i ich kolejność dokonywana jest przez programistów – szkoda czasu Product Owner’a na błędy, które mają niską dolegliwość a ich naprawa jest łatwa i szybka. Jeśli tych błędów jest bardzo dużo, wówczas należy je spisać i zgrupować w paczki oraz zaplanować określoną liczbę punktów na poprawianie tego typu błędów.

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

w

Connecting to %s