Jak wpływać na priorytety błędów dla programistów i odpowiednio je traktować?

Obecnie trwają prace nad błędem.

Mamy 3 poziomy błędów:

Błąd P1: Błędy uniemożliwiające użytkownikom pracę. Muszą być rozwiązane na miejscu.
Błąd P2: Błędy, które wpływają, ale użytkownicy mogą pracować
Błąd P3: Błędy, które nie mają wpływu i gdzie użytkownicy mogą pracować.

P1 jest obowiązkowy i musi zostać rozdany na miejscu. Ale w przypadku P2 i P3 oceniamy na podstawie indywidualnych przypadków.

Dzięki 3 poziomom, które mamy, zespół ma tendencję do pracy nad bardziej nagłymi nowościami, o które pytają klienci, zamiast zajmować się P2 i P3, co jest prawie jak pilne.

Pytania są następujące:

Czy powinienem dodać kolejny poziom priorytetu, na przykład posiadanie P4?

Czy powinienem również przypisać im cele do obsługi niepotrzebnych biletów, jak w tym tygodniu, jeśli nie przypisujesz zadania kodowania, powinieneś potraktować co najmniej 1 P2?

Obecnie nie mamy celów, które podniosłem powyżej, ale martwię się, że nadanie im takich celów może być brutalne. Pewne jest to, że muszę z nimi porozmawiać o celach, zespół lubi brać udział w dyskusji, zwłaszcza gdy ustalamy cele.

Aktualizacja:

Zaproponowano mi to pytanie pod względem podobieństwa. Jednak wcale nie jest podobny.

Moje pytanie brzmi: jak sprawić, by ludzie radzili sobie z błędami, bez narzucania ścisłej agendy, a jeszcze jej rozwiązania. Więc nie, sugerowane pytanie mi nie pomaga. Wciąż dziękuję.

agile debugging issue-tracking

— Andy K.
źródło

Możliwe duplikaty Jak przekonać kierownictwo do radzenia sobie z długiem technicznym?

— komara

zwykle poziom priorytetu nie jest tak przydatny jak porządkowanie priorytetowe ... „błąd X” jest ważniejszy niż „błąd Y”. jeśli dodasz p4, w końcu będziesz chciał p5 i p3.5

— sudo rm -rf slash

Jeśli masz tyle błędów P1, że wszyscy twoi programiści są zawsze zajęci naprawianiem ich zamiast pracy na P2 / P3, robisz coś bardzo złego. Nie dodawaj więcej funkcji przez jakiś czas. Skoncentruj się na drążeniu w dół i naprawianiu problemów architektonicznych (lub personelu), które prawie na pewno powodują wiele z tych błędów. Jeśli na przykład piszesz w C ++, upewnij się, że używasz RAII wszędzie, gdzie możesz, aby nie zapomnieć o ręcznym .release().

— Pozew Fund Moniki

Jaki jest twój cel Czy chcesz, aby programiści więcej pracowali nad poprawkami błędów, a mniej nad nowymi funkcjami? Edytuj pytanie, aby wyjaśnić. Opisz także, w jaki sposób programiści otrzymują lub podejmują pracę? Co decyduje o tym, nad czym się pracuje?

— sleske,

funkcja, błąd, zmiana, jak to nazwiesz, oprogramowanie nie robi tego, czego potrzebuje. Jedyną różnicą między błędem a funkcją jest to, kto za nią płaci.

— mattnz

Odpowiedzi:

Generalnie masz dwie osie błędów: grawitację i częstotliwość.

Więc oczywiście coś poważnego i częstego ma najwyższy priorytet. Jednak coś poważnego, ale zdarza się rzadko, powinno być ważone mniej więcej tak samo jak coś, co nie jest poważne, ale zdarza się często. Zakładając, że oceniasz grawitację od 1 do 3, a częstotliwość od 1 do 3, typy błędów, które prawdopodobnie powinieneś naprawić, to te, które przekraczają przekątną określoną przez grawitację 1, częstotliwość 3 i grawitację 3, częstotliwość 1.

Błąd blokowania lub błąd, który mógłby spowodować potencjalne uszkodzenie informacji o kliencie, zawsze byłby grawitacją 3. Podobnie, błąd grawitacji 1 prawdopodobnie nie zostanie zauważony przez użytkownika lub ma niski priorytet. Jeśli nie masz pewności, 2 to prawdopodobnie bezpieczny numer do przypisania.

Błąd, który użytkownik widzi za każdym razem, gdy program zostanie uruchomiony, będzie miał częstotliwość 3. Błąd o częstotliwości 1 będzie czymś, co zdarza się rzadko, jeśli w ogóle. Ponownie, jeśli nie jesteś pewien, 2 to prawdopodobnie bezpieczny numer do przypisania.

Jest to głównie subiektywne, co stanowi błąd o sile grawitacji 3 lub błąd o częstotliwości 3, ale kieruj się zdrowym rozsądkiem. Błąd o grawitacji 1, częstotliwość 2 jest prawdopodobnie błędnie napisaną etykietą. Błąd o grawitacji 2, częstotliwości 1, może być prawidłową obsługą błędów, gdy połączenie z bazą danych jest nieczynne.

Ponownie, jest to tylko szorstki pomysł, ale chodzi o to, aby położyć nacisk na to, na czym powinno skupiać się usuwanie błędów jako rodzaj triage. Oczywiście nie jest możliwe wyeliminowanie wszystkich błędów, blokowania lub w inny sposób, chociaż przynajmniej przy tej metodologii można bezpiecznie powiedzieć, że błędy nie są zbyt pilne ani zbyt częste. Jeśli jedynie poprawione błędy, które blokują błędy, to błędy wysokiej częstotliwości będą ignorowane, a użytkownicy będą zauważyć, że nie naprawić te błędy.

Ponadto dla wygody może się okazać, że wolisz podać klasy literowe dla grawitacji lub częstotliwości, więc możesz powiedzieć, że błąd jest błędem B3 i jasne jest zarówno grawitacja, jak i częstotliwość.

Powodzenia!

— Neil
źródło

W rzeczywistości istnieje tylko jedna miara błędów - ROI - ile to kosztuje naprawić w porównaniu do tego, ile firma traci za nie naprawienie. Porównaj to z funkcjami. Oczywiście sposób obliczania tej metryki obejmuje grawitację, częstotliwość itp.

— corsiKa

@corsiKa, tak ROI to złożony wskaźnik: „zwrot” i „inwestycja”. W przypadku błędów powrót można modelować jako połączenie „grawitacji” i „częstotliwości”.

— Paul Draper,

@corsiKa, taka bezczelna egoistyczna analiza decyzji dotyczących jakości jest w rzeczywistości niezwykle nieodpowiedzialna. To ta sama logika, która prowadzi do obchodzenia przez firmy farmaceutyczne przepisów dotyczących testów skuteczności, jeśli potrafią „uciec” lub utrzymywać zyskowne leki na rynku pomimo nasilenia i częstości działań niepożądanych. Ta sama nieodpowiedzialność prowadzi do ogromnych botnetów składających się z niepewnych routerów konsumenckich i „inteligentnych” urządzeń, ponieważ producent nie widział żadnej wartości dolara w dobrym bezpieczeństwie. Grawitacja i częstotliwość są DUŻO lepszymi wskaźnikami niż „wpływ dolnej linii”.

— Wildcard,

@Wildcard Jestem dosłownie komunistą, więc w 100% zgadzam się z tobą, że są lepsze. Nie zmienia to faktu, że w ten sposób działają firmy produkujące oprogramowanie, a pójście w przeciwnym kierunku, chyba że prowadzisz firmę, utopi cię. Chociaż warto zauważyć, nie jest samolubny. To jednorazowa porcja, ale ten singiel nie jest sobą, ale firmą. Po prostu to wyrzucam.

— corsiKa

@Wildcard i corsiKa firma nie jest duża i nie możemy sobie pozwolić na powiedzenie „och, stracimy pieniądze, więc zróbmy coś inaczej, nie ruszajmy”. Jednak w wielkim schemacie rzeczy nie wierzę, że podejście, o którym wspominałeś, jest trwałe na dłuższą metę. Ludzie - klienci nie są głupi. Firm, które głosiły tego rodzaju ewangelię, Sun, aby wymienić jedną, już nie ma. Pracuję w zarządzaniu kontem wystarczająco długo, aby pieniądze nie były zarabiane w ten sposób. Każdemu, kto akurat pracuje dla takiej firmy, w której firma nie ma lojalności 1 / n

— Andy K

To naprawdę sprowadza się do tego, co uważasz za ważniejsze. Błąd P2 czy nowa funkcja?

Zwykle zwinny system zarządzania projektami obejmuje spotkanie w celu ustalenia priorytetów, podczas którego zadania są porządkowane według priorytetów i nad nimi pracowane.

Programiści nie mogą wybierać zadań, nad którymi pracują. To zadanie kierownika projektu. Kto musi upewnić się, że projekt ma jak najwięcej ważnych funkcji, zanim skończy się budżet.

To naprawdę najważniejsza rzecz. Proste zasady, takie jak „napraw co najmniej 1 P2 na tydzień”, tak naprawdę nie pomagają w osiągnięciu tego celu.

— Ewan
źródło

Problem z przypisywaniem priorytetów polega na tym, że niezależnie od wybranej ziarnistości wiaderka zawsze uzyskuje się więcej niż jeden na wiadro. Musisz uporządkować, a nie tylko powiedzieć: „wszystkie są NAJWYŻSZYM PRIORYTETEM!”

— Ewan

@Ewan Istnieje również możliwość priorytetowego nadmuchiwania w przypadku, gdy twój najwyższy koszyk zawiera więcej problemów, niż można kiedykolwiek rozwiązać, a nowe poziomy priorytetów są wymyślane poza systemem śledzenia błędów. Słyszałem, że ludzie mówią o P minus 2 kwestiach.

— kasperd,

Mówienie, że programiści nie mogą wybierać zadań, nad którymi pracują, obniży produktywność. Jeśli programista jest zablokowany w kwestii o najwyższym priorytecie, nad którą pracowali, lepiej jest, jeśli w międzyczasie mogą pracować nad innym problemem, niż nie robić nic, dopóki ich pierwszy problem zostanie zablokowany. Ponadto problemy, które nie są szkodliwe dla użytkowników, ale szkodzą wydajności programistów, często nie są traktowane priorytetowo tak wysoko, jak powinny. Wreszcie, informowanie programistów, że nie mogą podejmować własnych decyzji, jest pewnym sposobem na zniszczenie motywacji.

— kasperd,

@kasperd Myślę, że większość programistów akceptuje to, że są zarówno pracownikami, jak i super-geniuszami technicznymi oraz że pracodawca decyduje, które zadania należy wykonać jako pierwsze. Oczywiście, jeśli jedno jest zablokowane, przejdziesz do następnego najważniejszego, ale nie pomijasz 10 ważnych zadań, aby pracować nad fajnym.

— Ewan

Przekonałem się, że jeśli praca jest ukończona lub zablokowana, zamiast wciągania innego zadania rozwojowego do sprintu (robienie scrum), błąd powinien mieć priorytet. Podczas pracy w systemie Windows 2000 MS słynie nadało wszystkim błędom najwyższy priorytet nad wszelkimi zadaniami programistycznymi - odkryli, że był to najlepszy sposób na tworzenie oprogramowania bez błędów (jeden z powodów, dla których 2000 był bardzo lubiany) tak, jakby nie , błędy zwykle bywały pozostawione, ponieważ zamiast tego zwykle pracowano nad nowymi rozwiązaniami.

— Baldrickk,

Jest to dość powszechny cykl, w którym oprogramowanie gromadzi niekrytyczne błędy, dopóki coś się nie da, a następnie dzieje się wielkie wydarzenie i wiele z nich jest naprawianych jednocześnie; może przez poświęcenie sprintu lub dwóch tylko na poprawki błędów przed wielką nową wersją, lub przez to, że oprogramowanie jest EOL i przetrwało mnóstwo błędów.

Więc jesteś w dobrym towarzystwie, jeśli twoi twórcy po prostu pozwolą im się przesunąć. Oczywiście możesz żonglować „regułami”, o których wspomniałeś („jeśli nie pracujesz nad nową funkcją, musisz pracować na co najmniej jednym P2 na tydzień”), ale to prawdopodobnie spowoduje, że będziesz niepopularny.

Moje pytanie brzmi: jak sprawić, by ludzie radzili sobie z błędami, bez narzucania ścisłej agendy, a jeszcze jej rozwiązania.

Zamiast tego proponuję nieco zmienić ogólny sposób myślenia i uczynić błędy bardziej podobnymi do funkcji w tym sensie, że są pierwszorzędnymi obywatelami twojego zaległości. Tak, nowe funkcje są świetne; tak, zarządzanie i sprzedaż bardzo mocno pociągają za sobą nowe funkcje. Ale ważna jest również stabilna, dobrze działająca aplikacja zamiast ogromnej kupy niechlujnych błędów.

Nie mówcie swoim twórcom, że muszą wykonywać pracę, której nie lubią; ale spróbuj zmienić atmosferę, aby lubili pracować nad błędami. Spróbuj zaszczepić poczucie dumy w aplikacji wolnej od błędów. Spraw, aby praca nad błędem była przyjemniejsza (sic), umożliwiając im naprawienie przyczyny, która spowodowała ujawnienie się błędu (tj. Nie tylko szybkie obejścia / włamania), jeśli takie istnieją. Wyrwanie jakiejś zepsutej struktury klas i zastąpienie jej czymś bardziej odpowiednim może być bardzo zabawne dla deweloperów. Jeśli masz jakiś zepsuty środkowy element, który regularnie uwidacznia błędy w innym miejscu, napraw środkowy element.

To, jak osiągniesz swój cel, zależy w dużej mierze od twojej postaci i twoich zespołów - nie próbuj oszukiwać ich w to, co chcesz osiągnąć, ale prowadź otwarte dyskusje, spróbuj uzyskać efekt rówieśników, pozwól im wymyślić sam proces pracy i tak dalej.

— AnoE
źródło