Pytanie jest prawdopodobnie zbyt ogólne. Powody, dla których są nieskończone.
jmq 11.1111
7
Pytanie brzmi: wysyłaj z błędami lub wcale nie wysyłaj :)
Vitor Py
41
Wszystkie produkty są wysyłane z błędami.
Joel Etherton,
4
Zdefiniuj BŁĄD. Niedawno dostarczyliśmy produkt, którego nie można zainstalować. Świetny błąd: D
Barfieldmv,
2
Masz na myśli „znane błędy”?
Nikt
Odpowiedzi:
12
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?
ale wygląda na to, że jest świadomy błędu ... więc w tym momencie wydawałoby się, że programista jest po prostu leniwy, aby go nie naprawić, ponieważ jest tego świadomy ...
Kenneth
7
@Kenneth: Można to tak zobaczyć, ale produkty muszą zostać wysłane i zawsze będą miały błędy. Zależy to od wagi błędu, czy dotrzymasz terminu.
Matt Ellen,
1
@Matt to prawda. Wydaje mi się jednak, że w większości przypadków nie chcesz świadomie wysyłać produktu z dużymi błędami. Oznaczałoby to, że pozostałe błędy, o których wiesz, byłyby niewielkie, które w większości przypadków można łatwo naprawić lub przynajmniej obejść. Nie możesz sobie poradzić z błędami, o których nie wiesz, ale jeśli proces testowania przebiega poprawnie, większość błędów powinna zostać złapana ...
Kenneth
1
Może mój sarkazm nie był jasny ... ale powiedzenie, że wysyłanie błędnego oprogramowania jest „zawsze w porządku”, jest w pewnym sensie nieodpowiedzialne. To tak, jakby powiedzieć: „na świecie zawsze będą mordercy, więc nie ma znaczenia, czy pójdę zabić kilka osób”.
DisgruntledGoat
7
@DisgruntledGoat Nie wszystkie błędy są równe: niektóre z nich są łatwe do naprawienia, niektóre niszczą katastrofy projektowe. Oczywiście należy to naprawić. Niektóre z nich są bardzo rzadkimi błędami, trudnymi do znalezienia, opartymi na nietypowych okolicznościach i zwykle trudnymi do naprawienia bez większego przepisywania. Czasami muszą po prostu zostać, ponieważ ich naprawa oferuje zbyt małą wartość, a oprogramowanie musi zostać wysłane wczoraj. Chodzi o analizę kosztów / ryzyka / korzyści.
CodexArcanum,
33
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.
Literówka w polu „about” to coś, co naprawdę powinieneś naprawić. Zajmie to około 0,7 sekundy (zakładając, że oboje piszemy z tą samą prędkością). Jednak jeśli pozostawisz tę literówkę, ludzie ją zobaczą . Natychmiastowa śmierć za zaufanie użytkowników do oprogramowania, jeśli w interfejsie użytkownika widoczne są błędy.
Wydaje mi się to słuszne. Przez większość czasu w produkcie jest znanych kilka drobnych błędów, nawet jeśli zostaną wydane. Są to rzeczy bardzo niezwykłe i mają nieistotny wpływ na faktyczne działanie i korzystanie z oprogramowania lub rzeczy, których większość użytkowników nigdy nie widzi.
glenatron,
3
Rzeczywiście, literówki w interfejsie użytkownika niszczą wiarę w jakość produktu (niesłusznie, ponieważ wielu świetnych programistów po prostu nie mówi dobrze po angielsku), jednak rozumiem twój punkt - trywialne błędy, które nie powodują żadnej szkody i prawdopodobnie nigdy nie przyjdą nie są warte kłopotów z powstrzymaniem wydania. Zostaw to na pocisku w 1.01.
Phoshi,
Nie dopuszczaj błędów ortograficznych do aplikacji. Szczerze mówiąc jestem bardziej zawstydzony przez nich niż faktyczny błąd.
ChaosPandion,
1
Nie mam pojęcia, o czym mówisz ...;)
Andreas Johansson,
6
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.
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.
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:
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.
Odpowiedzi:
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?
źródło
Zawsze musi być OK, ponieważ nie ma czegoś takiego jak oprogramowanie bezbłędne.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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ść
źródło
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).
źródło
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:
źródło
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.
źródło