Czy poprawianie błędów przez innych ludzi jest dobrym podejściem?

Załóżmy, że zespół czterech programistów tworzy aplikację. Podczas fazy testowania użytkownicy zgłaszają błędy. Kto powinien je naprawić? Osoba, która popełniła błędny kod, lub ktoś, kto jest wolny?

Jakie jest preferowane podejście w zwinnym rozwoju (scrum)?

Preferowanym podejściem przy zwinnym opracowywaniu byłoby jak najszybsze ich naprawienie przez każdego, kto jest dostępny. Jest tak po prostu dlatego, że własność kodu nie należy do jednej osoby, ale do całej grupy programistów. Jeśli jedna osoba konsekwentnie powoduje błędy, jest to kolejny problem, który należy rozwiązać osobno.

Domyślnie osoba. Powód jest dość prosty: informacja zwrotna. Błędy stanowią doskonałą okazję do osobistej i profesjonalnej informacji zwrotnej. Gdyby ktoś inny naprawił moje błędy, popełniłbym ten sam błąd, ponieważ nie wyciągnąłem z niego wniosków.

Jeśli ta osoba nie jest dostępna, ktoś może to naprawić, ale osoba ta powinna śledzić cykl życia błędów.

Jako PM unikałbym łączenia błędów z konkretnymi programistami. Jeśli trzeba to zrobić, pozwól menedżerowi funkcji / rozwoju to zrobić. Zajmij się zespołem. Zespół musi naprawić błąd.

Nie wiem, jak Scrum radzi sobie z tym scenariuszem, ale w moim zespole mamy coś w rodzaju testu krzyżowego / przeglądu kodu. W ten sposób, w przypadku znalezienia błędu, zarówno programista, jak i recenzent omawiają najlepsze podejście do jego rozwiązania.

Uważam, że dopóki rozwiązanie pasuje, nie ma znaczenia, czy programista lub recenzent je zastosuje. Ważne jest jednak, aby uniknąć wszelkiego rodzaju konfliktów między deweloperem a testerem.

Rgds

Edycja: Nie jestem pewien, czy wyraziłem się jasno, ale ważne jest, aby podkreślić, że recenzent jest kolejnym programistą w zespole.

1. Oceń błąd
2. Jeśli będzie to szybsze / bardziej sensowne dla oryginalnego programisty, aby to naprawić, daj im to
3. Jeśli może to naprawić ktoś w zespole, pozwól każdemu to zrobić.

Całkowicie zgadzam się ze Stevenem, że kod należy do całego zespołu; i jest jeszcze kilka powodów, dla których nie powinieneś dawać błędu swoim twórcom:

Jak wiem, w wielu przypadkach trudno jest ustalić, kto spowodował błąd. Nawet jeśli korzystasz z systemu zarządzania dokumentami, takiego jak SVN, wyśledzenie kodu błędu może zająć dużo czasu. Moim zdaniem, po prostu podaj błąd każdemu, kto jest wolny.

Jeśli chcesz śledzić, jak powstał błąd, w czasie wolnym możesz zapytać osobę zajmującą się naprawą o sprawę (przed całą drużyną). Ponieważ twój zespół jest mały, myślę, że podzieliłoby to doświadczenia związane z możliwymi błędami i nie sprawiłoby, że ktokolwiek się wstydzi.

Są tylko trzy powody, dla których należy dbać o to, kto naprawia błąd: koszt, szybkość i rozwój zawodowy.

I są plusy i minusy dla wszystkich trzech. Na przykład rozwój zawodowy, z jednej strony jest to okazja, aby dowiedzieć się więcej o kodzie z drugiej, jest to okazja, aby rozpoznać rodzaje popełnianych błędów i uniknąć ich w przyszłości. Lub też ponieść koszty, prawdopodobnie ten, który popełnił błąd, byłby w stanie naprawić go szybciej i prawdopodobnie taniej, z drugiej strony istnieje koszt za czas poświęcony na identyfikację, kto popełnił błąd i przypisanie go odpowiedniej osobie - czas co w wielu przypadkach przewyższa naprawę błędu.

Podejście zwinne polega na tym, że programiści mogą samodzielnie przypisać problem. Zastąpiłbym to tylko z ważnego powodu.

W moim zespole zawsze decydujemy według priorytetu. jeśli osoba, która przesłała kod, jest dostępna, naprawia kod. Jeśli ta osoba pracuje nad historią o wyższym priorytecie, każdy, kto jest dostępny i może naprawić kod tak szybko, jak to możliwe, naprawi go. Jeśli wszyscy są zajęci pracą nad zadaniami o wyższym priorytecie w bieżącej iteracji, poprawka jest planowana w następnej iteracji zgodnie z jej priorytetem w porównaniu z innymi historiami i defektami.

Pomyśl: Kto ma więcej informacji o błędzie? Zespół programistów.

Niech więc zdecydują, co zrobić z błędem. Są właścicielami kodu, więc są za niego odpowiedzialni.

Możesz im pomóc, zarządzając projektem, przeznaczając trochę czasu na zakres projektu na poprawki błędów i pozwalając im samodzielnie wykonać zadanie.

Unikaj podejmowania wielu decyzji, w których Ty (jako PM) masz mniej informacji niż zespół.

Zobacz pytanie: Jak uniknąć mikro-zarządzania zespołem programistów?

Mówię, że potrzebujesz systemu śledzenia błędów, aby rejestrować błędy spowodowane przez to, co zgłaszane, a następnie przypisywać błędy różnym osobom na podstawie ich obciążenia pracą. Wskazano również, czyj kod spowodował błąd, a następnie przygotowano raport pokazujący, ilu programistów i jakie aplikacje spowodowały x liczby błędów w ciągu tygodnia.

Następnie możesz pokazać to programistom, aby pokazać, w jaki sposób powodują błędy.

A najlepszym sposobem zapobiegania błędom jest zaangażowanie wszystkich w ich naprawianie. Mam na myśli przypisanie naprawy błędu do różnych osób, aby dać pełny obraz tego, co powoduje błędy i co je naprawia.

Następnie może po miesiącu lub dwóch z wszystkich naprawiających błędy, zrewiduj lub utwórz wytyczne dotyczące stylu kodowania, aby zapobiec przyszłym błędom, w całym systemie, poprzez napisanie / udokumentowanie standardów swojego programowania.

Po znalezieniu błędu za naprawę odpowiada cały zespół programistów.

Jeśli ludzie uważają, że autor powinien naprawić błąd, to tak, jakby powiedzieć: „Nie naprawiam problemu, dziury nie ma po mojej stronie łodzi”. Ale łódź nadal tonie, jeśli dziura nie zostanie naprawiona, a ty jesteś na tej łodzi ze wszystkimi innymi.

Osoby muszą zdawać sobie sprawę, że są częścią zespołu i rozumieć, że kod wraz z jego obowiązkami należy do nich wszystkich. Sukces projektu zależy od wszystkich członków zespołu.