Szybko i łatwo naprawiać błędy

Naprawianie błędów było wyzwaniem w tworzeniu oprogramowania jeszcze przed Scrumem. Krótkie iteracje w Agile nie ułatwiają zespołom decydowania, które błędy muszą zostać naprawione, a które mogą jeszcze poczekać.

Dobre wiadomości są takie, że Scrum Team zazwyczaj ma znacznie mniej błędów niż zespół pracujący z bardziej tradycyjnymi frameworkami deweloperskimi. Jednak zespoły zwinne również tu i ówdzie napotykają jakiś błąd, zwłaszcza gdy część systemu pochodzi z czasów sprzed przejścia zespołu na podejście zwinne. A do priorytetyzacji tych defektów zespół potrzebuje skutecznego rozwiązania.

Priorytetyzacja naprawiania błędów: Czego nie robić

Na początku mojej kariery zawodowej jako programista mój szef zatrzymał cały zespół na tydzień, aby omówić wszystkie znane defekty. Rozmawialiśmy o możliwych przyczynach, o tym, jak poważny jest każdy błąd, jak często się pojawia, czy można go odtworzyć, gdzie w kodzie może leżeć problem i kto z nas powinien go naprawić.

Szacowaliśmy nawet, ile czasu zajęłoby naprawienie każdego błędu. Szacunki te w większości przypadków były nie tylko dość bezużyteczne, ale zazwyczaj trwało dłużej, aby je sporządzić, niż po prostu naprawić błąd.

Kiedy po tych wczesnych doświadczeniach zacząłem kierować zespołami, zacząłem eksperymentować z innymi, lżejszymi podejściami.

Dziś chcę przedstawić moją ulubioną metodę naprawiania błędów.

Wytyczne dotyczące priorytetyzacji błędów

Zamiast poświęcać czas na zastanawianie się nad każdym pojedynczym błędem, lepiej jest stworzyć wytyczne określające, jak szybko błąd powinien zostać naprawiony, tzn. jak wysoki jest priorytet defektu przy wystąpieniu błędu.

Przykład 1: Jedną z takich wytycznych może być to, że każdy błąd, który w dramatyczny sposób dotyka wszystkich użytkowników, musi zostać naprawiony natychmiast, co oznacza przerwanie bieżącej pracy w Sprincie. Inna wytyczna mogłaby na przykład mówić, że błędy, które pojawiają się tylko wyjątkowo rzadko i nie uniemożliwiają użytkownikowi wykonywania najważniejszych funkcji, są odnotowywane i naprawiane bez pośpiechu, gdy tylko znajdzie się na to czas.

Tworzenie i stosowanie wytycznych nazywa się również priorytetyzacją przez zasady (prioritization by policy).

Przykład 2: Nieco bardziej konkretnym przykładem byłaby sytuacja, gdy Product Owner zgadza się ze swoim zespołem, że każdy błąd, który uniemożliwia użytkownikom składanie zamówień na ich stronie eCommerce, musi zostać naprawiony jak najszybciej.

Dalsze wytyczne mogą dotyczyć błędów, które powinny być naprawiane jedynie pod koniec dnia, pod koniec tygodnia lub nawet wcale nie.

Definiowanie wytycznych dotyczących defektów

Pomocne przy formułowaniu wytycznych dotyczących naprawiania błędów są następujące rozważania:

• Prawdopodobieństwo defektu: Jak często problem się pojawia?
• Dotkliwość defektu: Jak poważna jest sytuacja, gdy problem się pojawi?

Wyobraź sobie, że na Amazonie jest błąd, który powoduje, że zamówienia o wartości 1 miliona dolarów nie mogą być składane, ponieważ deweloper założył, że zamówienie nigdy nie przekroczy wartości 999 999,99 dolara.

To jest złe, gdy taki przypadek nastąpi (wysoka dotkliwość), ale myślę, że Amazon nie otrzymuje zbyt wielu zamówień powyżej 1 miliona dolarów (niskie prawdopodobieństwo).

Tworzenie macierzy wytycznych dotyczących defektów do priorytetyzacji błędów

Oba wymiary – dotkliwość i prawdopodobieństwo – można połączyć, aby określić wytyczną priorytetyzacji dla danego defektu. Pomocna może być taka macierz:

Istnieje wiele możliwości klasyfikowania prawdopodobieństwa i dotkliwości błędów. W przykładzie ze stroną eCommerce prawdopodobieństwo jest wyrażone jako procent dotkniętych transakcji. Wszystko, co wpływa na 10% lub więcej transakcji, jest dość poważną sprawą, dlatego ustawiłem całą kolumnę na wysoki lub bardzo wysoki priorytet.

Do oceny dotkliwości defektu można zastanowić się, czy istnieje obejście problemu i czy jest ono oczywiste, czy trudno je znaleźć. Na stronie eCommerce mogą być na przykład dwa przyciski „Kup teraz", ale tylko jeden z nich działa.

Komórki macierzy pokazują, która wytyczna ma zastosowanie dla defektów o określonym prawdopodobieństwie i dotkliwości. W tym przykładzie wybrałem pięć różnych poziomów priorytetu – od bardzo niskiego do bardzo wysokiego. W niektórych przypadkach wystarczą trzy poziomy. Odradzam stosowanie więcej niż pięciu, choć widziałem to już nieraz.

Tak stosuję pięć poziomów priorytetu:

• Bardzo wysoki: Wprowadzany natychmiast do bieżącej iteracji, nawet jeśli oznacza to, że inne prace muszą poczekać. Może wymagać więcej niż jednego członka zespołu, ewentualnie nawet całego zespołu.

• Wysoki: Wprowadzany natychmiast do bieżącej iteracji, nawet jeśli oznacza to, że inne prace muszą poczekać. Zespół decyduje, kto najlepiej może rozwiązać problem.

• Średni: Może być wprowadzony do bieżącej iteracji według uznania Product Ownera.

• Niski: Dokumentowany i omawiany na następnym spotkaniu planowania według uznania Product Ownera.

• Bardzo niski: Dokumentowany na liście znanych problemów. Ponownie poruszany tylko wtedy, gdy zmieni się prawdopodobieństwo lub dotkliwość, lub według uznania Product Ownera.

Zalety priorytetyzacji przez zasady

Główną zaletą tego podejścia jest to, że spędza się znacznie mniej czasu na dyskutowaniu o tym, co zrobić z każdym pojedynczym defektem. Ten sposób priorytetyzacji błędów wymaga początkowo pewnego wysiłku przy tworzeniu wytycznych. Jednak gdy wytyczne zostaną już opracowane, nadawanie priorytetów nowym defektom staje się dziecinnie proste.

Celem tego podejścia jest uczynienie priorytetyzacji defektów bardziej obiektywną niż subiektywną. Oczywiście ktoś będzie musiał ocenić, jak często dany problem będzie się pojawiał, ale poza tym sama priorytetyzacja nie zajmie więcej czasu niż spojrzenie na macierz priorytetyzacji.

Ten artykuł pochodzi z bloga Mike'a Cohna i został przez nas przetłumaczony na język polski.

Szkolenie Product Owner

=> Zostań certyfikowanym Product Ownerem i weź udział w jednym z naszych szkoleń

Wymagania niefunkcjonalne

=> Dowiedz się, jak przekształcić wymagania niefunkcjonalne w User Stories.

Product Scorecard

=> Sprawdź, czy Twój produkt wspiera strategię firmy i skorzystaj z Product Scorecard.