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?

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?”

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.

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ół.

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ć.

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ść.

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.

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.

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

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)

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.

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.

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.

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.

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ć .

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.

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).

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ć.

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.

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

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.

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.

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.

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?

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.

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.