Kategoryzuj zadania / błędy według ryzyka zmian

W projekcie, nad którym aktualnie pracuję, występuje problem: błędy i zadania są często przydzielane osobom, które są zbyt nowe lub zbyt niedoświadczone, a ich praca kończy się produkcją kolejnych błędów. Problem polega na tym, że niektóre elementy naszego oprogramowania są znacznie bardziej „niebezpieczne” niż inne z powodu problemów z jakością kodu. Próbowałem zwalczyć ten problem, szacując ryzyko związane z zadaniami i zwracając baczną uwagę na to, którym programistom przypisano zadania.

Używamy JIRA, więc zacząłem etykietować problemy, aby śledzić te szacunki. Zauważyłem, że w końcu wykorzystałem kilka wskaźników do kategoryzacji błędu / zadania:

• Jakie to jasne / proste. Np. Czy jest to coś, co będzie wymagało dużo pracy projektowej, czy tylko prosta poprawka błędu interfejsu użytkownika.
• Jak utrzymywany jest dotknięty obszar kodu. Czy to dobrze zaprojektowany teren czy duża kula błota.
• Myślę, że na część programu będzie miała wpływ wymagana zmiana.

Moje etykiety są trochę nieporządne, ponieważ nie miałem jasnego pojęcia, kiedy zaczynałem, jakie będą możliwe kategorie, a ja nadal nie mam. Zastanawiam się nad prośbą o dodanie nowego pola (coś w rodzaju „Ryzyka”), abyśmy mogli wymagać oszacowania przed przypisaniem pracy komuś.

Czy ktoś wcześniej zajmował się tego rodzaju sprawami?

Jedną z wad większości podejść do śledzenia błędów jest to, że dotyczą one tylko jednej strony równania - widoku systemu przez użytkownika końcowego. Jest to krytyczny błąd, który można naprawić, może poczekać tydzień (priorytet), ten błąd jest bolesny, sponieważ występuje usterka pluralizacji (dotkliwość).

Wpis na blogu opisujący wielowymiarowe śledzenie błędów analizuje tę kwestię, w tym widok programisty: PEF i REV.

Wartości PEF są widokiem użytkownika:

• P ‍ain - jak bolesny jest błąd, gdy zostanie napotkany?
• E ‍ffort - ile wysiłku wymaga praca?
• F requency - jak często ma bug występuje?

Strona REV jest z perspektywy dewelopera:

• R ‍isk - jak ryzykowna jest poprawka?
• E ‍ffort - ile wysiłku trzeba będzie naprawić?
• V ‍ weryfikowalność - jak łatwo jest zweryfikować, czy błąd został naprawiony?

Każdy z nich jest mierzony w skali 1..9, gdzie 1 oznacza niski / łatwy, a 9 wysoki / twardy. Liczby są sumowane, aby dać wynik dla PEF i REV.

Część, która dotyczy opisanych bitów:

• Jakie to jasne / proste. Np. Czy jest to coś, co będzie wymagało dużo pracy projektowej, czy tylko prosta poprawka błędu interfejsu użytkownika.
• Jak utrzymywany jest dotknięty obszar kodu. Czy to dobrze zaprojektowany teren czy duża kula błota.
• Myślę, że na część programu będzie miała wpływ wymagana zmiana.

Uwzględniają one wysiłek i ryzyko opisane w REV.

Tak, z czym wcześniej walczyliśmy. Użyłem (w przeszłości) tego modelu do niestandardowych pól w Redmine i było to całkiem udane.

Dużą zaletą tego jest porównanie wyników PEF i REV. Jeśli masz PEF 21 i REV 7, to może być duża wygrana. Podczas gdy PEF wynoszący 7 i REV wynoszący 21 jest czymś, czego należy unikać na jakiś czas, ponieważ ryzyko i wysiłek prawdopodobnie przewyższają ustalanie korzyści.

Następnie można spojrzeć na wynik REV i przypisać rzeczy o niskim ryzyku mniej doświadczonym programistom (niskie ryzyko, wysoki wysiłek są często idealne w tej sytuacji).

Powiedziałbym, że to, o czym tu mówisz, można by lepiej nazwać „złożonością”. Oczywiście, im bardziej złożona jest zmiana, tym większe jest „ryzyko”, że niedoświadczony programista może wprowadzić nowy błąd. Wprowadzenie takiego pola nie jest złym pomysłem, jeśli jest to prawdziwy problem.

Jednak sądząc po tym, co napisałeś, wydajesz się mieć dwa problemy:

1. Masz do czynienia z nowymi lub niedoświadczonymi programistami.
2. Jakość (dużej / części) kodu wydaje się wątpliwa.

Oprócz wprowadzenia czegoś w rodzaju „złożoności” (co pomogłoby w zarządzaniu pracą i nadaniu jej priorytetu), proponuję skoncentrować się na zmniejszeniu ryzyka związanego z powyższymi dwoma zagadnieniami.

Aby rozwiązać pierwszy problem, stworzę proces, w którym nowi programiści najpierw omawiają wszystkie nowe błędy z bardziej doświadczonym programistą, zanim zaczną pracować nad błędem. Ponadto zdecydowanie wprowadzę recenzje kodu, aby zarówno zmniejszyć ryzyko wprowadzenia nowych błędów, jak i wykorzystać je jako okazję trenerską dla nowych programistów, aby szybciej przyspieszyć.

Jeśli chodzi o jakość kodu, zrobiłbym dwie rzeczy. Po pierwsze, zatrzymaj proces gnicia: uzgodnij standardy kodowania i praktyki, które uniemożliwiłyby wprowadzenie nowego gorszego kodu. Przydałyby się tu również sugerowane recenzje kodu. Po drugie, zidentyfikuję najgorsze części twojego kodu i zacznę je refaktoryzować i porządkować.

Tak, dobrze jest nie dawać niedoświadczonym programistom problemów, które są zbyt złożone. Ale drugą stroną jest to, że jeśli pozwolisz im robić proste rzeczy, to się nie nauczą.

Sugeruję, że alternatywną strategią jest ustanowienie reżimu przeglądu kodu. Pozwól początkującym pracować nad trudnymi rzeczami (w rozsądnym zakresie), ale dokładnie zapoznaj się z ich pracą.

W krótkim okresie jest to więcej pracy dla wszystkich. W dłuższej perspektywie skończy się cały zespół programistów, którzy poradzą sobie ze złożonymi sprawami, ORAZ znajdują się „na tej samej stronie”, jeśli chodzi o jakość kodu.