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?
issue-tracking
plntxt
źródło
źródło
Odpowiedzi:
Myślę, że wszystkie odpowiedzi „tak” bardzo przyczyniają się do poparcia tego pomysłu. Ale rzucę pomysł, że decyzja opiera się na kilku pytaniach:
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?”
źródło
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.
źródło
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ół.
źródło
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ć.
źródło
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ść.
źródło
Nie potrzebujesz oprogramowania do śledzenia błędów tak długo, jak każdy członek zespołu
źródło
Krótka odpowiedź brzmi: tak.
Niektóre powody, dla których:
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.
źródło
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ść:
Śledzenie problemów; nie wychodź z domu bez tego
źródło
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)
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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ć .
źródło
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.
źródło
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).
źródło
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ć.
źródło
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.
źródło
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
źródło
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.
źródło
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.
źródło
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.
źródło
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?
źródło
Może nie być tego warte, jeśli spełnione są następujące dwa warunki:
Jeśli nie ma 1 lub 2, skorzystasz ze śledzenia problemów.
źródło
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.
źródło