Zapytałem niektórych kolegów o to, co może się dziać, i powiedzieli, że jeśli błąd nie ma tego priorytetu, bardzo rzadko Bug zwraca uwagę programistów, co rzeczywiście ma sens
Właściwie, jeśli mnie o to poprosisz, to nie. Im więcej (używanych) poziomów priorytetu, tym więcej masz informacji. Jeśli faktycznie masz tylko jeden priorytet, to tak samo, jak w ogóle brak priorytetu.
A ponieważ nadal masz tę samą liczbę błędów do rozwiązania i taką samą liczbę roboczogodzin, aby to zrobić, wynika z tego, że zostanie użyta inna heurystyka, być może ta zerowa - „kto pierwszy, ten lepszy”. A więc masz teraz wskaźnik priorytetu błędów, z wyjątkiem tego, że jest to czas przybycia i nie jesteś już pod twoją kontrolą.
Może to świadczyć o tym, że na naprawę błędu nie przydzielono wystarczającej ilości zasobów (istnieją takie zasady, jak „ Brak nowych funkcji do czasu usunięcia błędów ”. Joel się zgadza ; zrozumienie ograniczeń i konsekwencji jest decyzją biznesową ).
W jednym projekcie, nad którym pracowałem, nadchodzące błędy były gromadzone w „buforze bez priorytetu” i w każdy poniedziałek przeglądaliśmy listę błędów, ocenialiśmy trudność (bardzo przybliżona ocena; częściej niż nie, po prostu wstawialiśmy, „Średnia”) i posortuj je według dostępnego czasu. Zwykle powodowało to, że lista była nudna, nieciekawa lub uważana za trudną; aby to zrównoważyć, przełożeni i marketing mieli tygodniowo pewną liczbę kredytów, które mogli wydać, aby podnieść priorytet ulubionych błędów, i otrzymywali zwrot kosztów za nierozwiązane błędy (to ustalało limit, o ile błąd, który gardzi deweloperem, może zostać opóźniony) .
Możliwe było również łączenie, anulowanie i dzielenie błędów; Pamiętam jeden moduł, który był tak beznadziejnie wadliwy, że zatopiliśmy około dwudziestu lub trzydziestu raportów o błędach w jednym „przepisaniu tego od zera”, który następnie został podzielony na „wyraźnie określ dane wejściowe i wyjściowe nieszczęsnego”, „napisz testy aby upewnić się, że wejścia i wyjścia są zgodne ze specyfikacją ”itd. Ostatnim elementem było „wydrukowanie starego kodu na papierze z recyklingu, wyniesienie go na trawnik i podpalenie” (my też to zrobiliśmy. Pamiętam, jak dobrze się czuł. Na zmianę pisaliśmy; to było przezabawne ).
Po kilku targach mieliśmy listę rzeczy do zrobienia w tym tygodniu, która została podzielona na „zrobi”, „może zrobić” i „nie mogę”, które zostały przesunięte na następny tydzień. W tym momencie pojawiło się dodatkowe targowanie: mieliśmy pięćdziesiąt godzin, aby przeznaczyć je na błędy i byliśmy w 95% pewni, że naprawimy pierwsze dwadzieścia. Zarząd zdecydowanie chciał naprawić dwudziesty pierwszy błąd i nie pozostał mu żaden kredyt; zaproponowalibyśmy wtedy zamianę tego błędu na jeden z listy „Zrobię”, albo ktoś powiedziałby: „Zabierz mnie z podgrupy FooBazFeature na kilka dni i zrobię to”, lub powiedzielibyśmy: „Potrzebujemy więcej siła robocza".
System tak naprawdę nikogo nie satysfakcjonował, ale uważano to (przynajmniej wśród programistów) za dobry znak.
Niektóre dodatkowe negatywne wzorce, które się pojawiły, to „Wishful Thinking” ze strony menedżerów („Stwierdziłeś, że błąd 57212 wymaga ośmiu godzin. To jest nie do przyjęcia. Zrób to cztery”) i „Debuguj przez Fiata” („Rób, co chcesz” ale te czterdzieści błędów musi zostać naprawionych przed wielką demonstracją w przyszłym tygodniu. Nie możesz mieć więcej czasu, nie możesz mieć więcej ludzi "). Również Zespół Boksera („Będę ciężej pracował”), który zwykle działał bardzo dobrze przez krótki czas , ale zwykle doprowadzał dewelopera do szału lub wychodzenia na bardziej zielone pastwiska.