W naszym projekcie pracujemy w metodyce zero-bug (aka zero-defect). Podstawową ideą jest to, że błędy mają zawsze wyższy priorytet niż funkcje. Jeśli pracujesz nad historią i ma ona błąd, należy ją rozwiązać, aby historia została zaakceptowana. Jeśli podczas sprintu dla starszej historii zostanie znaleziony błąd, musimy umieścić go w naszym dzienniku zaległości i rozwiązać - najwyższy priorytet.
Powodem, dla którego mówię „rozwiązać”, jest to, że nie zawsze naprawiamy błąd. Czasami deklarujemy, że „nie naprawi się”, ponieważ nie jest to takie ważne. W sumie brzmi świetnie. Wysyłamy produkty wysokiej jakości i nie nosimy „garbu” w postaci ogromnej liczby zaległych błędów.
Ale nie jestem pewien, czy to podejście jest prawidłowe. Zwykle zgadzam się, że zawsze musimy jak najszybciej naprawić poważne błędy i musimy usunąć nieciekawe błędy. Ale co z błędami, które są ważne, ale nie tak ważne jak nowe funkcje? Wydaje mi się, że należy je zaliczyć do zaległości z odpowiednim priorytetem.
Podam przykład, aby był jaśniejszy - w moim projekcie pracujemy z interfejsem użytkownika napisanym fleksją. Mamy ekran kreatora, który otwiera się w tym samym rozmiarze dla każdej rozdzielczości ekranu. Okazuje się, że kiedy rozszerzamy okno kreatora, jedna ze stron nie wygląda dobrze (istnieje pionowy pasek przewijania, który nie znika, chociaż kreator może teraz prezentować wszystko i nie wymaga paska przewijania). Myślę, że ten błąd jest brzydki. Jestem pewien, że MUSI to zostać naprawione. Ale mamy napięty harmonogram i mamy wiele funkcji, których obawiamy się, że nie zrobią cięcia i nie wejdą do wydania. Czuję, że możemy żyć z takim błędem. Trzeba to naprawić, ale ma niższy priorytet niż inne funkcje (więc na wypadek, gdybyśmy nie byli w stanie go ukończyć, przynajmniej nie pominęliśmy ważniejszych funkcji). Ale,
Bardzo chciałbym usłyszeć opinie o tym, jak radzić sobie z błędami, których nie chcę oznaczać jako „nie da się naprawić”, ale także nie są one najważniejsze.