Kiedy można wysłać produkt ze znanym błędem?

Kiedy można wysłać produkt ze znanym błędem?

Zakładam, że mówisz o „znanym” błędzie (inaczej pytanie nie ma znaczenia). Odpowiedź zależy od tych czynników:

1) Kim jest użytkownik i jak zaakceptuje błąd w przypadku jego znalezienia?

2) Jaki jest potencjalny wpływ (uszkodzenie) błędu?

3) Czy możliwe jest opóźnienie wysyłki oprogramowania w celu naprawienia błędu?

4) Co najważniejsze: czego oczekujesz od swojego oprogramowania? Czas na rynek? Jakość? Czy chcesz sprawdzić, czy Twoi klienci używają oprogramowania wystarczająco długo, aby znaleźć błąd?

Zawsze musi być OK, ponieważ nie ma czegoś takiego jak oprogramowanie bezbłędne.

To wezwanie do sądu. Pamiętaj, że błąd może mieć wiele przyczyn. Jeśli jest to główna funkcja, która nie działa, to najpierw ją naprawisz. Jeśli jest to coś mniejszego, co ma minimalny lub żaden rzeczywisty wpływ na użyteczność programu, możesz pozwolić mu się przesuwać.

Spójrz na to z punktu widzenia kosztów / korzyści.

Wysyłasz produkty ze znanymi błędami, gdy całkowity koszt i ryzyko naprawienia błędu przewyższają wszelkie problemy i negatywny wpływ wynikający z obecności błędu.

Więc jeśli masz dwutygodniowy okres testowy przed wydaniem i znaleziono mały błąd, pytanie brzmi ... naprawia ten błąd wart 2 dodatkowe tygodnie, które zespół może teraz poświęcić na ponowne przetestowanie aplikacji i instalacji (często zapomniany o kroku tworzenia oprogramowania)? Jakie są koszty reputacji lub sprzedaży, jeśli oprogramowanie się spóźnia? Czy ludzie będą źli? Mogą być szczęśliwi, żyjąc z drobnym błędem, jeśli główna funkcjonalność może zostać dostarczona na czas.

Ryzyko obejmuje ryzyko wprowadzenia nowego problemu, nie tylko podczas naprawy błędu, ale także rzeczy, które mogą wyniknąć z utworzenia nowej instalacji.

Negatywny wpływ to zarówno czas, jak i wysiłek związany z klientami zgłaszającymi błąd, a także takie rzeczy, jak uszkodzenie reputacji.

Błędy występują w różnym stopniu. W każdej firmie programistycznej, w której pracowałem, kategoryzowaliśmy błędy według priorytetu od P0 do P4.

P0 Czy oprogramowanie nie działa / ulega awarii i może spowodować szkody dla firmy klienta? P1 Nie działa zgodnie z przeznaczeniem i konsekwentnie zawiesza się w podstawowej funkcjonalności P2 Występuje awaria i czasami część funkcji bocznej może nie działać. P3 Niektóre elementy oprogramowania nie działają zgodnie z oczekiwaniami / problemem P4 Cosmetic.

Pracowałem w miejscach, w których P4 po prostu się nie naprawia, ponieważ mają tak niewielki wpływ na oprogramowanie.

Powiedziałbym, że wysyłanie jest prawidłowe, jeśli w twoim oprogramowaniu występują problemy z P3 / P4, umieściłbym to w uwagach do wydania i zauważam, że nad nimi pracują.

Nigdy nie wydałbym oprogramowania z problemem P0, P1 lub P2, o którym wiedziałem.

Nazywa się to „ znanym problemem ”. Google, Microsoft, Apple itp. Wysyłają produkty z błędami, znanymi i nieznanymi. Spróbuj je zminimalizować, ale nie czekaj na doskonałość. Wysyłaj szybko, wysyłaj często.

Nie można wysyłać oprogramowania bez błędów. Porada, którą mogę udzielić, to to, że zawsze lepiej powiedzieć klientowi: „Ta wersja nie może tego zrobić i to, ale zamierzamy to naprawić” niż sytuacja, gdy klient powie Ci, że masz błąd.

kiedy jest to „funkcja”! ;)

Mówiąc poważnie, chyba że jesteś doskonałym programistą z doskonałą konfiguracją testową, aby idealnie przetestować każdą ścieżkę kodu i ewentualnie to potencjalnie istnieć, jest mało prawdopodobne, abyś wysłał produkt bezbłędny.

Dlatego bądź pragmatyczny, jeśli wszystko, co spotkałeś podczas testowania, zostało naprawione, wszystko dodatkowe powinno być naprawiane w miarę potrzeb.

Tak długo, jak jesteś uczciwy wobec swoich klientów, możesz wysyłać z błędami. Poinformowanie ich o wszystkich istniejących błędach pokazuje im, że masz dobrą wiedzę o swoim oprogramowaniu, i to jest rzeczywiście dobrze przetestowane (jeśli jest ...). :)

Oczywiście najlepszą rzeczą jest unikanie wysyłki z błędami.

Często lepiej jest mieć produkt dostarczony na czas z listą znanych problemów, niż w ogóle go nie wysyłać.

Jedną z rzeczy w świecie programowania, która daje ludziom zaufanie do projektu, jest to, czy zaplanowali wydanie i czy harmonogram się utrzyma .

To dlatego Ubuntu jest wydawane co pół roku, nawet jeśli nadal występują otwarte problemy.

Powiedziałbym, że dobrą ogólną zasadą jest: „czy ten błąd to showstopper?”

Jeśli błąd powoduje niepowodzenie „szczęśliwego scenariusza”, to absolutnie nie wysyłaj z tym błędem.

Jeśli błąd powoduje niepowodzenie scenariusza „styczna do szczęśliwej ścieżki” i nie ma obejścia, nie wysyłaj go wraz z tym błędem.

Jeśli błąd jest udokumentowany i istnieje znane obejście problemu, prawdopodobnie wysyłanie z tym błędem jest w porządku.

Z punktu widzenia konsumentów ... Nigdy. Chodzi mi o to, że dopóki wiesz, że w oprogramowaniu jest poważny błąd, nigdy nie powinieneś go wysyłać. Jednak siły natury (biznesowe) zastępują to, jeśli cykl produkcyjny oprogramowania jest na etapie, w którym może zaszkodzić modelowi biznesowemu i są to drobne błędy, które nie będą: (i) zagrażać bezpieczeństwu oprogramowania (ii) wpływać na użyteczność

Jak powiedzieli ludzie, jest to bardzo szerokie pytanie. To prowadzi mnie do interesującej perspektywy: tak zwane „błędy”, które, jak twierdzisz, są tylko wadami wykrytymi przez twoich testerów. Może istnieć nieskończenie więcej luk. Przypomniałem tylko ciekawą historię, którą usłyszałem od szanowanego profesora na jednym seminarium dla absolwentów: Gdy ludzie w jednym z krajów skandynawskich używali maszyny do głosowania typu „pismo-rozpoznawalne”, niektóre osoby zhakowały cały system, pisząc złośliwy kod SQL (który system przyjął jako normalne wejście).

Jest coś, co nazywa się FMEA (analiza trybu awarii i efektów), bardzo przydatne jest podjęcie decyzji, kiedy znany błąd jest ważny, czy nie, na podstawie:

1. Występowanie
2. Surowość
3. Wykrycie

Innym decydującym czynnikiem może być związek wady z ostatnim wydaniem. Jeśli błąd jest częścią nowej, ale zepsutej funkcji, wówczas brak funkcjonalności nie oznacza regresji funkcjonalności. Śmiało i wysyłamy.

Z drugiej strony, jeśli wada powoduje utratę istniejącej funkcjonalności, o której wiadomo, że jest przydatna dla istniejących klientów, musi ona zablokować wydanie. Taka wersja byłaby obniżeniem poziomu dla Twoich klientów i nie służyłaby ani Twoim interesom, ani ich interesom.

Mogą być w tym odcienie szarości. Regresja podstawowych funkcji nigdy nie powinna nigdy wychodzić z domu. Pewna regresja w funkcjach peryferyjnych mogłaby wyjść na prowadzenie, jeśli wydanie zawiera także nowe funkcje, którymi byli zainteresowani. Niewidoczna wada, która prawdopodobnie nie wpłynie na wielu klientów, może przejść do wydania, pod warunkiem, że obejdzie się to, gdy wpływa na tych klientów. Wady wysoce eksperymentalnych funkcji, które i tak są domyślnie wyłączone, nigdy nie powinny powodować opóźnienia wydania.