Czy naprawianie błędów ma marginalną korzyść [zamknięte]

Słyszałem od byłego kolegi, że nie wszystkie błędy muszą zostać naprawione, ponieważ gdy schodzisz na listę priorytetowych błędów, przypadek użycia, który powoduje, że błąd staje się bardziej niejasny lub satysfakcja klienta maleje. Ale wciąż musisz poświęcić dużo czasu na naprawienie tego błędu.

Aby przekonać naszego właściciela produktu o tej koncepcji, nie mogłem znaleźć żadnych dobrych zasobów. Jedyne, co mogłem znaleźć, to dyskusje na temat tego, czy tworzenie oprogramowania jest krańcowe, czy nie.

Czy naprawianie błędów ma naprawdę marginalne znaczenie? Czy istnieje inny termin, który wyjaśnia tę koncepcję?

Z perspektywy biznesowej naprawa błędu nie różni się niczym od żądania funkcji. Ma pewien koszt w czasie programowania i ma pewną wartość dla klientów. Jeśli błąd nie ma znaczenia krytycznego, sensowne jest nadanie priorytetu wartościowej funkcji nad poprawką błędu.

Ale z technicznego punktu widzenia błędy mogą być bardziej krytyczne, ponieważ wskazują na błąd w fundamencie, który może zostać wykorzystany / zbudowany przez inny kod, w którym to przypadku błąd jest „zaraźliwy” i zwiększa koszty przyszłej konserwacji. Tak więc nie naprawienie błędu jest długiem technicznym, który wymaga zarządzania, podczas gdy brak implementacji funkcji tak naprawdę nie wiąże się z ciągłymi kosztami. Ale poziom długu technicznego zaciągniętego przez błąd zależy w dużym stopniu od charakteru błędu.

Wszystkie te czynniki należy wziąć pod uwagę przy ustalaniu priorytetów.

Jeśli chodzi o to, czy naprawianie błędów ma marginalną korzyść: to jest dane. Ponieważ nie wszystkie błędy są równe pod względem ważności, naturalnie najpierw traktujesz najważniejsze błędy. Im więcej błędów naprawisz, tym niższa będzie wartość krańcowa naprawienia następnego. Ale to, czy kiedykolwiek osiągnie poziom, na którym naprawiono błąd, nie jest warte wysiłku, jest raczej decyzją biznesową niż techniczną.

Oto dobre odniesienie

http://www.joelonsoftware.com/articles/fog0000000043.html

Czy naprawiasz błędy przed napisaniem nowego kodu? Pierwsza wersja Microsoft Word dla Windows została uznana za projekt „marszu śmierci”. [...] ponieważ faza naprawy błędów nie była częścią formalnego harmonogramu [...]

Microsoft powszechnie przyjął coś [...] najwyższym priorytetem jest wyeliminowanie błędów przed napisaniem nowego kodu [...] Ogólnie rzecz biorąc, im dłużej czekasz na usunięcie błędu, tym kosztowniejsze (czas i pieniądze) jest naprawienie .

Możesz być pewien, że im dłużej będą występować te błędy, tym dłużej będzie trzeba je naprawić, gdy staną się priorytetem. Zamiast więc uzyskiwać teraz surowe korzyści, unikasz bardziej kosztownej straty w przyszłości.

Dobrym sposobem zarządzania tym byłoby określenie czasu przeznaczonego na obsługę problemów z zaległościami. Nie popchnęłoby to tak papce jak Microsoft, ale zapewni pewne rozwiązanie przyszłych problemów, jeśli nie będą już twoim problemem, nawet jeśli klienta tak naprawdę nie obchodzi.

Aby przekonać naszego właściciela produktu o tej koncepcji, nie mogłem znaleźć żadnych dobrych zasobów.

Zakładając, że pracujesz dla organizacji komercyjnej, na pewno będzie tam ktoś, kto jest świadomy analizy kosztów i korzyści .

Twoja organizacja ma skończoną ilość zasobów programistycznych i nieskończoną listę przydatnych rzeczy do zrobienia. Do tych korzystnych rzeczy należą zarówno dodawanie nowych funkcji, jak i usuwanie istniejących błędów - usunięcie błędu poprawia oprogramowanie, podobnie jak dodanie nowej funkcji.

Oczywiste jest więc, że należy podjąć decyzję, jak przydzielić ten skończony zasób do tej nieskończonej listy, i nie jest szczególnie zaskakujące, że w wyniku tego niektóre błędy nie zostaną naprawione teraz, w przyszłym tygodniu, w przyszłym roku lub w fakt zawsze.

Jeśli szukasz bardziej uporządkowanego podejścia tutaj, możesz wypróbować system PEF / REV, który przypisuje liczby do poglądów użytkownika i programisty błędu, jako punkt wyjścia do podjęcia decyzji, co należy naprawić - a co nie.

Zobacz te dwa posty tutaj na temat inżynierii oprogramowania:

Rozwiązywanie problemów, które przyniosą największe korzyści finansowe

Prawie każdy zgłoszony błąd jest błędem o wysokim priorytecie

Nie wszystkie niezamierzone lub niepożądane aspekty zachowania oprogramowania są błędami. Ważne jest, aby upewnić się, że oprogramowanie ma użyteczny i udokumentowany zakres warunków, w których można polegać na działaniu w użyteczny sposób. Rozważmy na przykład program, który ma przyjąć dwie liczby, pomnożyć je i wyprowadzić wyniki, i który wypisuje fałszywą liczbę, jeśli wynik wynosi więcej 9,95, ale mniej niż 10,00, więcej niż 99,95, ale mniej niż 100,00 itd. Jeśli program został napisany w celu przetwarzania liczb, których iloczyn był między 3 a 7, i nigdy nie będzie wzywany do przetwarzania innych, ustawienie jego zachowania na 9,95 nie uczyni go bardziej użytecznym dla zamierzonego celu. Może to jednak sprawić, że program będzie bardziej odpowiedni do innych celów.

W takiej sytuacji istnieją dwa rozsądne sposoby działania:

1. Napraw problem, jeśli jest to praktyczne.

2. Podaj zakresy, w których dane wyjściowe programu będą wiarygodne, i stwierdz, że program nadaje się tylko do użytku z danymi, o których wiadomo, że generują wartości z prawidłowych zakresów.

Podejście nr 1 wyeliminowałoby błąd. Podejście nr 2 może sprawić, że postęp będzie mniej odpowiedni do niektórych celów, niż w innym przypadku, ale jeśli programy nie będą obsługiwały problematycznych wartości, może to nie stanowić problemu.

Nawet jeśli niezdolność do prawidłowego obsługiwania wartości od 99,95 do 100,0 jest wynikiem błędu programistycznego [np. Decyzja o wypisaniu dwóch cyfr po lewej stronie przecinka dziesiętnego przed zaokrągleniem do jednego miejsca po tym, co daje 00.00], należy to uznać jedynie za błąd, jeśli program w innym przypadku zostałby określony jako produkujący znaczące dane wyjściowe w takich przypadkach. [Nawiasem mówiąc, wyżej wspomniany problem wystąpił w kodzie printf Turbo C 2.00; w tym kontekście jest to oczywiście błąd, ale kod wywołujący wadliwy printf byłby błędny tylko, gdyby mógł generować dane wyjściowe w problematycznych zakresach].

W pewnym sensie tak, nie wszystkie błędy muszą zostać naprawione. Chodzi o analizę stosunku ryzyka do korzyści.

To, co na ogół się dzieje, to spotkanie biznesowe z potencjalnymi partnerami technicznymi i zainteresowanymi stronami w celu omówienia błędów, które oczywiście nie znajdują się w stosie „potrzeby naprawy”. Oni zdecydują, czy czas (= pieniądze) zainwestowany w naprawę błędu będzie tego wart dla firmy.

Na przykład „drobny błąd” może być niewielkim błędem w pisowni / gramatyce w sekcji Warunki witryny internetowej. Osoba, która to zgłosiła, może uważać, że zmiana jest zbyt drobna, ale firma rozpoznałaby potencjalną szkodę, jaką mogłaby wyrządzić marce, i względną łatwość naprawienia kilku znaków.

Z drugiej strony możesz mieć błąd, który wydaje się ważny, ale trudny do naprawienia i dotyczy tylko niewielkiej liczby użytkowników. Np. Niewielki link do przycisku jest uszkodzony dla użytkowników korzystających ze starszej wersji Google Chrome, a także ma wyłączoną obsługę Javascript.

Innymi powodami, dla których firma NIE naprawia błędu, może być to, że zainwestowany czas zwróciłby projekt z nieoczekiwaną ilością czasu lub że czas programisty lepiej byłoby poświęcić na pracę nad innymi poprawkami / kodowaniem. Może być również tak, że błąd jest na tyle niewielki, że można go uruchomić, a następnie naprawić w późniejszym terminie.

Mam nadzieję, że to wyjaśnia tę koncepcję nieco lepiej! Z pewnością odejdę od myślenia o tym w kategoriach ogólnych - każdy błąd jest wyjątkowy i powinien być traktowany jako taki.

Ponieważ podczas przechodzenia na listę priorytetów błędów, przypadek użycia, który powoduje, że błąd staje się bardziej niejasny, lub satysfakcja klienta maleje.

Więc ich „argument” jest w rzeczywistości

Jeśli zignorujesz błąd wystarczająco długo, użytkownik zapomni, na czym polegał problem, lub znajdzie sposób, aby go obejść.

Błędy powinny być traktowane priorytetowo i rozwiązywane „w porządku”, podobnie jak nowe żądania funkcji (ale prawdopodobnie ponad wszystkie te ostatnie).