Jak duży zespół potrzebujesz, aby korzystać z oprogramowania do śledzenia błędów? [Zamknięte]

59

Mój zespół programistów właśnie wzrósł o 100% (z 1 programisty na 2). Moja nowa kohorta chce zainwestować w oprogramowanie do śledzenia błędów. Czy takie oprogramowanie ma zalety dla tak małego zespołu?

plntxt
źródło
136
Jeden zespół korzysta z oprogramowania do śledzenia błędów.
Dominique McDonnell,
5
Możesz wypróbować FogBugz Student i Startup Edition - bardzo łatwy i wygodny w konfiguracji i obsłudze ( fogcreek.com/fogbugz/StudentAndStartup.html ).
Maxim Zaslavsky
2
nawet zespół <1 osoby potrzebuje oprogramowania do śledzenia błędów ...
vrdhn
5
@Vardhan Zespół mniej niż jednej osoby? Nieistniejący zespół?
Ikke
2
@Ikke .. jak jedna osoba pracująca nad wieloma projektami .. i zapominaj, co należy zrobić w wielu projektach ... wezwanie kierownictwa to 0,5 zasobu !!
vrdhn

Odpowiedzi:

51

Myślę, że wszystkie odpowiedzi „tak” bardzo przyczyniają się do poparcia tego pomysłu. Ale rzucę pomysł, że decyzja opiera się na kilku pytaniach:

  • Jak chcesz się komunikować jako zespół? Z 2 programistami jesteś teraz zespołem. Jak chcesz się komunikować? Wiele zwinnych zespołów prowadzi osobiste rozmowy i szkice na tablicy. Ale mogą też posunąć się do zapisania, zwłaszcza jeśli jest to błąd, który nie będzie długo na liście priorytetów.
  • Jak chcesz komunikować się ze swoimi klientami? Nie znam odpowiedzi na to pytanie, ale jeśli masz jakiś powód do publikowania błędów (lub naprawionych błędów w dokumencie wydania wersji), to ostatecznie je ostatecznie spisasz. Równie dobrze możesz wybrać system zarządzania błędami o niskim obciążeniu i gotowe.
  • Czy warto zachować historię? Odpowiedź może brzmieć „nie teraz”, ale jeśli uważasz, że w przyszłości chcesz zobaczyć trend błędów, aby zobaczyć miejsca, w których użytkownicy mają najwięcej problemów, lub miejsca, w których możesz spędzić trochę czasu sprawdzając i przejrzenie przed głównym wydaniem - następnie uzyskaj system śledzenia błędów. W historii chodzi o to, że dzień, w którym chcesz nagrywać, nie jest dniem, w którym powinieneś zacząć prowadzić zapisy.

IMO, odpowiedzi na te pytania dotyczą bardziej tego, gdzie widzisz produkt i tego, jak chcesz powiększyć swój zespół, a mniej tego, czy „2 osoby = powód dla systemu śledzenia błędów”. Większe pytanie brzmi prawdopodobnie: „czy system śledzenia błędów jest wart czasu na skonfigurowanie i zarządzanie, a koszt zakupu?”

bethlakshmi
źródło
Bardzo dobrze powiedziane! Wybierz narzędzie, które optymalizuje sposób pracy! W przeciwnym razie użyj tablicy korkowej!
Andres Jaan Tack
79

1, ale tylko jeśli jest to bezbolesne. Na przykład GitHub ma bardzo prosty i użyteczny moduł do śledzenia problemów z więcej niż wystarczającą liczbą funkcji dla małego zespołu. Bugzilla, Trac lub inne są dobre, ale wszystkie wymagają sprzętu, instalacji i konfiguracji przed użyciem, a konserwacja jest zdecydowanie niezerowym wydatkiem.

l0b0
źródło
6
Bugzilla może być prawdopodobnie zainstalowana na serwerze wirtualnym za całkiem minimalny koszt.
Zachary K
2
Trac również nie bierze dużo za utrzymanie. Miałem instancję Traca działającą około 2 lata z rzędu i nigdy nie musiałem utrzymywać niczego poza dodawaniem nowych projektów.
whatsisname
2
Wiem, że oba są łatwe w utrzymaniu, chodzi raczej o to, że to „wydatek niezerowy”, tzn. Nie darmowy. Może kilka godzin w ciągu roku, jeśli chcesz zainstalować poprawki bezpieczeństwa, lub kilka dni, jeśli chcesz przeprowadzić migrację ze starej wersji lub nastąpi uszkodzenie sprzętu.
l0b0
Koszt instalacji jest niezerowy, ale jeśli dobrze wykorzystany, będzie znacznie mniejszy niż zyski z posiadania.
BillThor
2
Nie zapomnij BitBucket dla tych użytkowników hg.
sholsinger
41

Kiedy po raz pierwszy użyłem oprogramowania do śledzenia błędów, mieliśmy bardzo mały zespół i byłem zdumiony, jak wiele rzeczy myśleliśmy, że musimy naprawić, a które jakoś nigdy nie zostały naprawione. To jest całkowicie tego warte bez względu na to, jak duży jest twój zespół.

HLGEM
źródło
Mogę się do tego całkowicie odnieść. Wczoraj zgubiłem notatnik, w którym zapisałem kilka błędów, które wymagały naprawy. Teraz będę musiał marnować kolejne dwie godziny na przeglądanie obszaru problemowego. Mam zamiar pobrać Bugzillę lub coś takiego.
3
Słuszna uwaga. Badania psychologiczne pokazują, że ludzie mogą przechowywać ~ 7 pozycji w pamięci krótkoterminowej. Jeśli masz więcej niż ~ 7 pozycji na liście zadań, dobrym pomysłem jest śledzenie błędów. Jeśli i tak je zapisujesz, możesz to zrobić w skalowalny i systematyczny sposób (to nie jest dużo większy wysiłek).
dbkk
27

Tak. Tysiąc razy tak.

Nawet nie myśl o tym w kategoriach śledzenia błędów, ale jako śledzenia biletów.

Możliwość wyświetlania wszystkich zadań w biletach ma ogromną zaletę. Możesz przechowywać historię zadania w jednym miejscu. Wiesz kto nad tym pracował i kiedy. Możesz być tak szczegółowy, jak powiedzenie, co zostało ukończone, w którym dniu zadania.

W celu śledzenia błędów możesz umieścić wszystkie swoje błędy w jednym miejscu i śledzić, które zostały zakończone, a które nadal trwają.

Pomaga to o wiele lepiej zarządzać.

Tyanna
źródło
+1 za wzmiankę o śledzeniu „biletu”. Głupio byłoby przechowywać tylko błędy w takim systemie, jeśli można go używać również jako osobistej listy
rzeczy do zrobienia
Poważnie musisz powiązać śledzenie błędów z systemem kontroli wersji. Następnie wszystkie zmiany mają możliwy do zweryfikowania powód. I musisz mieć jakiś RCS. Nieużywanie obu jest jak przychodzenie do pracy bez spodni.
Tim Williscroft
Tak, nie nazywaj tego śledzeniem błędów. Nazywamy to śledzeniem „zadania”, ponieważ błąd jest zadaniem, ale zadanie niekoniecznie jest błędem.
Carson63000,
16

Warto z zespołem jednego lub więcej.

Spójrz prawdzie w oczy, bez względu na to, czy kupisz formalne oprogramowanie, czy nie, będziesz mieć system śledzenia błędów / funkcji. Może być w notatniku, może być karteczkami samoprzylepnymi, może znajdować się w bloku komentarzy na górze kodu. Jednakże, chyba że będziesz się losowo rozwijał, będziesz notował gdzieś swoje listy rzeczy do zrobienia. Dlaczego nie skorzystać z bardziej zorganizowanego systemu, który może rozwijać się wraz z zespołem?

Warto również wziąć pod uwagę: Wiele programów do śledzenia błędów jest darmowych do użytku przez bardzo małe drużyny (1-2), więc to nie tak, że ponosisz duży wydatek na korzyść.

JohnFx
źródło
13

Nie potrzebujesz oprogramowania do śledzenia błędów tak długo, jak każdy członek zespołu

  • Ma doskonałą pamięć fotograficzną i
  • Może synchronizować swoje myśli z każdym innym członkiem zespołu.
Andy Lester
źródło
11

Krótka odpowiedź brzmi: tak.

Niektóre powody, dla których:

  1. Możliwość rejestrowania błędów, które zostały wykryte dla określonych wersji.
  2. Możliwość sprawdzenia, które (znane) błędy nie zostały jeszcze naprawione.
  3. Śledź, kto naprawił błąd, który został ponownie znaleziony.
  4. Obrót programisty - pozwala na transfer wiedzy, nawet jeśli zostaniesz trafiony przysłowiowym autobusem.

Prawdopodobnie będziesz chciał spojrzeć na coś, co nie zajmie dużo czasu, aby skonfigurować / zarządzać. Sugerowałbym także poszukiwanie czegoś, co obejmowałoby możliwość zintegrowania go z kontrolą źródła.

Ken Henderson
źródło
8

Ta odpowiedź ma na celu dodanie wagi po stronie YES argumentu.

Jestem w większości zespołem jednego. Intensywnie używam śledzenia problemów (redmine) wraz z integracją SVN.

Jest naprawdę wspaniały i bez niego oszalałbym; moja jakość spadłaby, ponieważ zapomniałem o rzeczach i straciłem orientację nad tym, nad czym muszę pracować.

Narzędzia zwiększające wydajność:

  • Przyzwoite IDE
  • Śledzenie problemów
  • Kontrola źródła

Śledzenie problemów; nie wychodź z domu bez tego

Richard Harrison
źródło
4

Jeśli masz mniej niż 3, prawdopodobnie możesz to zrobić za pomocą arkusza kalkulacyjnego Google Docs. Ale tak naprawdę koszt instalacji Bugzilli lub czegoś podobnego jest tak trywialny, jak koszt programisty, że lepiej jest po prostu to zrobić. (Plus, kiedy osiągniesz 7 lat, już tam będzie)

Zachary K.
źródło
2

Nawet jeden zespół może skorzystać z pewnego rodzaju narzędzia do śledzenia błędów, czy to pliku tekstowego notatek, czy też pełnego oprogramowania. W przypadku 2 programistów polecam inwestowanie czasu w konfigurację systemu śledzenia błędów, a nie pieniędzy. W zależności od projektu możesz sobie poradzić z pisaniem błędów na papierze, utrzymywaniem listy za pośrednictwem udostępnionego dokumentu online lub za pomocą bezpłatnego oprogramowania do śledzenia błędów, takiego jak Trac lub Bugzilla. Fogbugz jest również dostępny jako bezpłatny okres próbny przez 45 dni.

Jeff
źródło
1

Tak.

Musisz je jakoś śledzić!

Problemem jest to, ile masz błędów, a nie ilu programistów. Możesz poradzić sobie z arkuszem Excela, gdy masz do czynienia z kilkoma błędami, ale nawet wtedy nie jest to najlepsze.

Kretynowie
źródło
1

Istnieje zdecydowanie benifet - używam oprogramowania do śledzenia błędów nawet w projektach osobistych. Jest to przydatne nie tylko do śledzenia błędów, ale także do śledzenia „TODO” i żądań funkcji.

Jimmy Collins
źródło
0

Wszędzie używałem błędów, kiedy pracowałem sam. Działa z twoim DVCS, przechowując informacje o błędzie razem ze źródłem. Bardzo niski narzut, ponieważ nie wymaga centralnego serwera. Minusem jest to, że musisz uważać, w które gałęzie wprowadzasz nowe błędy, aby upewnić się, że będą się one rozprzestrzeniać w odpowiednim czasie, chociaż może to nie mieć większego znaczenia, jeśli w większości chcesz śledzić własne błędy i co zostało naprawione w ostatnim ściągnięciu, a raczej niż śledzić status zespołu jako całości.

Karl Bielefeldt
źródło
0

Po prostu zacznij go używać

Jeśli po prostu zaczniesz go używać, zaczniesz zdawać sobie sprawę z ich wygody w praktyce, podobnie jak oprogramowanie do kontroli wersji lub, w tym przypadku, rozproszona kontrola wersji.

Dojrzałość rozwoju

Nie ma znaczenia, czy masz zespół 100 lub 1, zacząłem używać śledzenia błędów i rozproszonej kontroli wersji (ma to sens ze względu na lokalne zobowiązania) tylko dla siebie i dla mnie i już czułem się na innym poziomie, ale nie tyle tylko, że mogłem zarządzać moją pracą na innym poziomie ... do poziomu, który mógłby się skalować bez mojej inwestycji.

Korzystając z modułu śledzącego, możesz przewidywać problemy i ustalać priorytety pracy, narzędzia do śledzenia błędów / problemów służą nie tylko do zgłaszania błędów / problemów, lecz służą raczej do administrowania projektami, a każdy projekt powinien to mieć .

dukeofgaming
źródło
0

Dla mnie nie chodzi tylko o oprogramowanie, ale o cały proces. W mojej codziennej pracy jako Kierownik Testów w zasadzie mieszkam w jednym i daje to następujące korzyści:

Uważam, że działa to naprawdę dobrze w przypadku 2+ testerów i 3+ programistów.

Zarządzanie wysiłkami programistów w zakresie usuwania błędów

Aktywnie zarządzamy „kolejką błędów” programistów, aby kontrolować, ile pracy im przydzielili, i zapewnić, że mamy przydzielony poziom prac naprawczych w zespole.

Decydowanie o tym, co działa, a czego nie naprawiać

Triaging przez nowe błędy w codziennym procesie to świetny sposób, aby pomóc skupić się na tym, co robisz i czego nie naprawiasz, a także wtedy, gdy to naprawiasz. Na początku projektu chcesz wszystko naprawić. Na koniec chcesz tylko naprawić ograniczniki pokazu, a narzędzie do śledzenia błędów jest do tego świetne

Kiedy potrzebujesz danych

Wielką rzeczą dla mnie są Metryki, tj. Gdy chcesz mieć możliwość wyszukiwania błędów i naprawiania trendów, gdzie znajdują się błędne obszary kodu lub jak szybko testerzy znajdują i ponownie testują błędy. Czas na system śledzenia błędów.

Bruce McLeod
źródło
0

Zgadzam się ze wspólną opinią, że jeden członek zespołu wystarczy, aby zacząć potrzebować narzędzia do śledzenia błędów. Określiłbym to jako obowiązkowe po tym, jak masz jednego lub dwóch prawdziwych użytkowników, ale ważne na długo przed pierwszym wydaniem.

Osobiście lubię skamieliny zarówno do kontroli źródła, jak i śledzenia błędów. Jest to całkowicie rozproszona SCM o niskiej ceremonii, dobrze zintegrowana z narzędziem do śledzenia błędów i wiki. Jest to instalacja wykonywalna pojedynczo, przenośna i wykorzystuje wewnętrzną aplikację internetową jako GUI. Jego strona główna jest w rzeczywistości obsługiwana prawie w całości przez kopię skamielin.

Dzięki modułowi śledzenia ściśle zintegrowanemu z kontrolą wersji możesz łatwo łączyć zmiany z biletami i wyświetlać aktualizacje biletów w tym samym widoku linii czasu co wersje (i zmiany na stronie wiki).

RBerteig
źródło
-1

Tak tak tak tak! Możliwość śledzenia, ustalania priorytetów i zarządzania problemami jest kluczem do pomyślnego rozwoju oprogramowania. Z jedną osobą możesz (prawie) uciec od arkusza kalkulacyjnego i spakowania starych drzew źródłowych. Dodanie nawet jednego dewelopera do projektu radykalnie zmienia sytuację - nagle konieczne jest śledzenie problemów i kontrola kodu źródłowego, albo będziesz rezygnować z problemów, nadpisywać funkcje i ogólnie będziesz mieć żałosny czas.

Dziwi mnie, że nikt jeszcze nie wspomniał o spółce macierzystej StackExchange, FogCreek, a ich oprogramowanie FogBugz to najlepsza aplikacja do śledzenia problemów, z jakiej kiedykolwiek korzystałem. Wysoka prędkość, niski opór i niedrogie, szczególnie jeśli korzystasz z hostowanego rozwiązania. Mieli bezpłatną wersję próbną hostowaną, która, jak sądzę, posiadała dwie licencje użytkownika za darmo - może już tak nie być, ale polecam to sprawdzić.

użytkownik18782
źródło
-1

oto moje 2 centy.

do śledzenia błędów używam tylko arkusza kalkulacyjnego google-doc, mogę zaprosić każdego, kogo chcę edytować lub przeglądać. jest za darmo, więc niewiele inwestycji. śledzę wszystkie zadania, które się tam znajdują, tylko błędy.

Uruchomiłem również SVN na moim hoście internetowym, co nie powoduje żadnych dodatkowych kosztów dla hostingu.

niektórzy klienci wymagali użycia nierozwiniętego oprogramowania lub innego takiego oprogramowania do zarządzania projektami / śledzenia błędów, ale wolałbym darmowe rozwiązania, o których wspomniałem powyżej.

użytkownik18794
źródło
-1

Jeśli masz minimalistyczny moduł śledzenia błędów, powiedziałbym, że jest przydatny nawet dla jednego zespołu. W jednym z witryn projektu mojego znajomego QuokForge , zapewniają one w zasadzie instancję Red Mine dla każdego projektu. Moim zdaniem Red Mine ma dobre narzędzie do śledzenia błędów (nawet jeśli czasem trochę dziwne). Mianowicie dlatego, że możesz zgłosić błąd, wpisując tekst tylko w JEDNYM polu. Używałem również FogBugz wcześniej. Jest bezpłatny dla 2 lub mniej osób. I pozwala na tę samą prostotę, zgłoszenie błędu poprzez wypełnienie tylko jednego pola tekstowego. (Zapewnia również wykresy i inne rzeczy, które są niezwykle przydatne)

Zasadniczo nie rób, aby zgłaszanie błędów było ścisłym i formalnym procesem, który wymaga od ciebie 30 minut na wypełnienie zgłoszenia błędu (BugZilla, patrzę na ciebie). Oznacza to po prostu, że ludzie nie będą go używać.

Wreszcie posiadanie listy błędów (nawet jeśli każdy zawiera błąd zawiera około 50 znaków tekstu) jest niezwykle cenne. „Hmm, walka o wydanie 1.0. MYŚLĘ, że naprawiłem ostatni błąd”. Świetnie jest też widzieć, że menedżerowie coś robią :). W zespole jest to bardziej cenne, ponieważ nie staracie się trzymać w głowie innego zestawu mentalnych list rzeczy do zrobienia. I to naprawia „Czy naprawiłeś ten [naprawdę zły błąd bezpieczeństwa]? Um, tak, MYŚLĘ, że tak. Ok, więc wypuśćmy wersję 1.0”.

Uwielbiam także śledzić funkcje. Jest to nieco bardziej opcjonalne, ale nadal czerpię korzyści z możliwości odciążenia mentalnego zadania polegającego na utrzymywaniu listy rzeczy do zrobienia w mojej głowie.

Zobacz też, co powiedział o tym Joel

Earlz
źródło
-1

Właśnie osiągnąłeś ten numer ... 2 ! Chociaż widzę korzyści płynące z używania oprogramowania do śledzenia błędów, nawet jeśli jesteś jedynym programistą ... możesz po prostu sobie bez niego poradzić, gdy całkowita liczba programistów wynosi 1.

Jednak gdy tylko masz dwóch lub więcej programistów, nie ma jednego powodu, aby nie mieć oprogramowania do śledzenia błędów, ani jednego.

użytkownik18806
źródło
-1

Tak. A zaleceniem jest bitbucket http://www.bitbucket.org Zapewniają bezpłatne śledzenie błędów, a także bezpłatne prywatne repozytoria w mercurial.

basarat
źródło
-1

Jeden. W takim przypadku jest to bardziej lista rzeczy do zrobienia.

Zakładam, że inwestując swój czas. Istnieje wiele bezpłatnych systemów śledzenia błędów, które powinny być odpowiednie dla dwuosobowego zespołu. Nie szukałbym ofert komercyjnych, dopóki nie miałbym większego zespołu.

Adam
źródło
-1

Myślę, że twoje pytanie uwypukliło twoje błędne przekonanie. Ponieważ to nie zespół potrzebuje śledzenia błędów, to produkt (y).

Czy śledzenie błędów wymaga oprogramowania? To by pomogło, nie sądzisz?

Lee Kowalkowski
źródło
-1

Może nie być tego warte, jeśli spełnione są następujące dwa warunki:

  1. Problemy mają krótką żywotność. W takim przypadku może wystarczyć prosta tablica zadań (ponieważ sprytnie jest wizualizować przepływ pracy z wielu innych powodów). Jeśli jednak nie możesz szybko rozwiązać problemów, np. szybko naprawiając błędy, przydatne będzie śledzenie problemu.
  2. Zmiany w kodzie są dokumentowane za pomocą automatycznych testów jako żywa dokumentacja. To znaczy, błędy i poprawki są udokumentowane testami zakończonymi niepowodzeniem, gdy się pojawiają, z pozytywnym przejściem testów w stan regresji po poprawce. - A zmiany funkcjonalności są dokumentowane za pomocą automatycznych testów akceptacyjnych (np. Przy użyciu niektórych narzędzi BDD, takich jak FitNesse lub Cucumber). Taka dokumentacja powinna być łatwo dostępna z serwera CI takiego jak Jenkins.

Jeśli nie ma 1 lub 2, skorzystasz ze śledzenia problemów.

Ingvald
źródło
-5

Nie

Nie śledź błędów, napraw je .

Liczy się nie rozmiar drużyny, ale czas, w którym jesteś gotów spojrzeć na błędy na liście, zanim je naprawisz.

Jeśli używasz Agile / TDD, Twoja lista błędów będzie krótka, a błędy nie będą długo pozostawały na liście. W takim przypadku wystarczy dowolny system śledzenia.

Steven A. Lowe
źródło
[Po prostu musiałem coś powiedzieć, żeby odeprzeć wszystkie
brakujące
2
Jak pamiętasz, że błąd został naprawiony? Jak pamiętasz, że nie przegapiłeś błędu przed wydaniem wydania?
Earlz
2
Przepraszam stary, wygląda na to, że próbujesz coś zrobić, ale to jest dyskusyjne.
dukeofgaming
2
@Steven: Czy miałeś kiedyś produkt z siedmiocyfrową liczbą instalacji? Żadna ilość TDD nie zapobiegnie zgłaszaniu błędów przez kilka tysięcy użytkowników, nie mówiąc już o kilku milionach. Mogą nawet nie być prawdziwymi błędami do naprawienia po twojej stronie, ale nadal będziesz musiał na nie patrzeć, zamykać duplikaty, wskazywać klientom rozwiązania oryginalnych itp. Jeśli jesteś jednoosobową firmą, albo musisz skorzystać z pióra / papieru, Excela, własnego DB - lub po prostu używasz do tego stworzonego oprogramowania.
sbi
2
@Steven: Moje zdolności parapsychiczne nie dostrzegają tak daleko w nienasyconych potrzebach Jima (i na pewno nic nie wskazuje na twoją interpretację).
sbi