Czy istnieją badania dotyczące wad korzystania z systemów śledzenia problemów? [Zamknięte]

Nie lubię systemów śledzenia problemów, ponieważ:

• Opisanie zawartych w nim problemów zajmuje zbyt dużo czasu. To zniechęca do jego używania.
• Tworzysz miejsce do przechowywania błędów. A jeśli jest dla nich miejsce, ludzie zwykle nie przejmują się zbytnio naprawą błędu, ponieważ mogą go tam umieścić, aby pewnego dnia ktoś mógł to naprawić (lub nie).
• Z czasem listy błędów stają się tak długie, że nikt już nie może sobie z tym poradzić, co zajmuje dużo czasu.

Wolę rozwiązywać problemy z użyciem post-it na białej tablicy, bezpośrednich rozmów i zabijania ważnych błędów, gdy tylko się pojawią. Nie przejmuję się zbytnio śledzeniem historii błędów, ponieważ nie sądzę, że jest to warte narzutu.

Czy jestem tu sam? Czy istnieją badania (książka / artykuł / cokolwiek) na temat wad (lub wielkich zalet) korzystania z systemów śledzenia problemów?

Opisanie zawartych w nim problemów zajmuje zbyt dużo czasu. To zniechęca do jego używania.

Jeśli nie potrafisz nawet opisać błędu, jak możesz go naprawić?

Tworzysz miejsce do przechowywania błędów. A jeśli jest dla nich miejsce, ludzie zwykle nie przejmują się zbytnio naprawą błędu, ponieważ mogą go tam umieścić, aby pewnego dnia ktoś mógł to naprawić (lub nie).

To jest problem z zespołem, a nie z oprogramowaniem.

Z czasem listy błędów stają się tak długie, że nikt nie może sobie z tym poradzić, co zajmuje dużo czasu.

Ponownie opisujesz problem ze swoim zespołem.

Oprogramowanie do śledzenia błędów nie ma na celu pomóc ci zmotywować zespół do naprawiania błędów, ale prowadzić rejestr, abyś mógł śledzić przyczynę błędów i powstrzymywać je od ponownego wystąpienia. Żadne oprogramowanie nigdy nie zastąpi dobrego zarządzania.

IMO twój punkt początkowy jest stronniczy. Jeśli programiści nie naprawią błędów, projekt jest skazany na porażkę, niezależnie od tego, czy śledzą błędy za pomocą odpowiedniego narzędzia do śledzenia błędów, post-it, kamiennych rzeźb, czy nie. To nie jest wina narzędzia, jeśli nie jest używane lub niewłaściwie używane. (To powiedziawszy, istnieją oczywiście złe narzędzia do śledzenia błędów / problemów ... Pracowałem nad projektem przy użyciu całkowicie nieodpowiedniego narzędzia do tej pracy, więc myślę, że wiem, jak źle może być. Ale są też dobre, które wymagają minimum ceremonii i kosztów ogólnych, co pozwala skupić się na odpowiednich informacjach).

Jeśli jednak programiści się tym przejmują, a projekt jest większy niż trywialny, a jest w nim więcej niż jeden programista, i wiąże się to z pewnym rodzajem zarządzania (wszystkie są dość powszechne w projektach w świecie rzeczywistym ), wkrótce pojawią się pytania takie jak:

1. Które z otwartych błędów powinny zostać naprawione jako pierwsze? (uwaga: w rozsądnym projekcie o tym powinien decydować właściciel produktu i / lub kierownictwo, a NIE programista - dla których muszą oni przede wszystkim wiedzieć o wszystkich otwartych błędach!)
2. Ile mamy otwartych błędów i jakiej dotkliwości?
3. Które z nich należy naprawić, zanim będziemy gotowi do wydania?
4. Ile czasu trzeba zaplanować na te poprawki - co często prowadzi do: średnio tyle czasu, aby naprawić błąd?
5. ile błędów zgłoszono przez klientów w ostatniej wersji?
6. kto naprawił ten i ten błąd, kiedy i jakie zmiany (kod / konfiguracja / dane) dotyczyły tej poprawki?
7. jakie poprawki błędów znajdują się w wydaniu, które właśnie zamierzamy opublikować?
8. ...

Czy potrafisz odpowiadać na takie pytania [aktualizować] w sposób powtarzalny, niezawodny i wydajny [/ aktualizować] na podstawie notatek post-it?

Tak, wprowadzenie danych błędów do modułu śledzenia problemów wiąże się z pewnym nakładem pracy. Jest to jednak więcej niż rekompensowane przez czas i wysiłek zaoszczędzony na wyszukiwaniu i tworzeniu raportów podobnych do powyższych na podstawie przechowywanych danych błędów.

Twoja metodologia może działać w przypadku bardzo małych projektów z ograniczoną liczbą programistów. Gdy projekt staje się większy, posiadanie systemu śledzenia problemów staje się znacznie ważniejsze dla koordynacji między różnymi zespołami, szczególnie jeśli poprawki będą wprowadzane w różnych wydaniach kodu. Złożone projekty będą miały wiele ruchomych części / komponentów, a zapewnienie, że problemy są zaplanowane i naprawione, stanowi dużą część dobrej implementacji śledzenia problemów

Niektóre artykuły / opracowania, które mogą Cię zainteresować, obejmują ten artykuł omawiający użycie Jiry przez Zend oraz francuskie badanie omawiające wykorzystanie systemów śledzenia błędów.

Mogą istnieć badania, ale jeszcze lepsze są ciężko zdobyte doświadczenia ludzi w tej dziedzinie. Większość systemów śledzenia problemów cierpi na procesy napędzające ich projektowanie. Osoby śledzące problemy często muszą obsługiwać 2 różne klasy użytkowników:

1. Zespół programistów
2. Użytkownicy systemu

Cal Henderson (wcześniej Flickr) ma świetny post na temat projektowania wielu programów do śledzenia problemów i dlaczego preferuje narzędzie do śledzenia problemów na GitHubie (podobnie jak ja). Ponadto Garrett Dimon omówił projekt Siftera i zilustrował sposób uproszczenia procesu w celu bardziej skutecznego śledzenia problemów . Przyjąłem niektóre pomysły z obu tych postów, aby uprościć proces śledzenia problemów mojego zespołu.

Wszystko, co powiedziało, wciąż sprowadza się do ludzi w kwestii procesu i narzędzi. Uważam, że moduły do ​​śledzenia problemów zwykle tworzą zaległości, którymi trzeba zarządzać. Podczas segregacji ludzie są bardziej skłonni do racjonalizacji tego, co jest błędem lub nie. W naszym procesie podejmujemy decyzje niemal natychmiast po zgłoszeniu błędu dotyczącego tego, czy jest to problem, czy nie. Po podjęciu tej decyzji błąd przechodzi do Pivotal Tracker. Różnica polega na tym, że używamy Trackera do ustalania priorytetów , a nie jako długopis do rzeczy, których nie chcemy robić. W rzeczywistości, gdy Icebox zaczyna być zbyt duży, aktywnie usuwam przedmioty, w tym błędy. Jeśli problem jest na tyle duży, że trzeba go rozwiązać, pojawi się ponownie.

Rzadko potrzebujemy historii błędów. Czasami ktoś może wspomnieć o objawie błędu i możemy wyszukać, czy ma to związek z jakimś problemem, który już rozwiązaliśmy. Ale to rzadkie.

TL; DR Skoncentruj się na swoim procesie, wybierz proste narzędzia i rozwiąż pojawiające się problemy.

zabijanie ważnych błędów, gdy tylko się pojawią

Wygląda na to, że włamujesz się tutaj do otwartych drzwi. Ważne błędy zostają „zabite” tak szybko, jak to możliwe, bez względu na to, czy używasz narzędzia do śledzenia problemów, czy nie.

• Aha, a część „jak się pojawiają” jest dość śliska BTW. W jednym projekcie mieliśmy ważny błąd, który groził wyrzuceniem całego produktu z biznesu (co może być ważniejsze?). To było bardzo skomplikowane (błąd architektury) i wiedzieliśmy, że naprawienie go potrwa długo. Klienci uprzejmie zgodzili się dać nam rok na naprawę (przed upuszczeniem naszego produktu) i zrobiliśmy to w ciągu około roku.

Jeśli chodzi o moduły do ​​śledzenia problemów, używam ich od prawie dziesięciu lat i z reguły wszyscy programiści wokół mnie spędzają mało czasu z modułem do śledzenia (uwaga: mówię o programistach; menedżerowie to inna historia). Widziałem przypadki (rzadko), kiedy tak nie było - we wszystkich tych przypadkach coś było poważnie zepsute.

Jeśli chodzi o badania nad rozmowami twarzą w twarz a śledzeniem problemów, znowu wydaje się, że włamujesz się tutaj. Śledzenie problemów to typowa komunikacja pisemna ; istnieje wiele badań wskazujących, że do omawiania rzeczy komunikacja face2face jest znacznie wydajniejsza niż przez telefon, co z kolei jest znacznie wydajniejsze niż pisanie .

• W rzeczywistości, biorąc pod uwagę, że pytasz o f2f, czujesz, że używasz trackera do omawiania rzeczy - to nie jest jego cel. Aby obliczyć przeznaczenie, po prostu przeliteruj jego nazwę powoli i wyraźnie: system śledzenia problemów .

listy błędów stają się tak długie

Z mojego doświadczenia wynika, że ​​powyższa zaleta nie stanowi problemu.

Dzięki długiej liście błędów programiści mogą ustawiać kolejki i planować poprawki na przyszłość. Jest to tak produktywne, jak to możliwe; dla mnie jest to w zasadzie nirwana, kiedy mam taką kolejkę do pracy. Pierwszy błąd - poprawka - zrobione, drugi błąd - poprawka - zrobione, następny błąd - poprawka - zrobione itp. Bez głupich przerw, bez bolesnych zakłóceń dzięki tak wydajnym rozmowom f2f, czysty przepływ .

• Pamiętam tylko jeden przypadek, w którym problemem były długie listy błędów . Stało się tak, gdy jakiś idiota z wyższego kierownictwa zdecydował się na politykę, która zmusiła programistów do wybierania następnego błędu ze stosu 50-100 prawie codziennie. Co za strata. Zajęło nam kilka miesięcy bólu, zanim wymyśliliśmy, jak eskalować to nad jego głową i naprawić.
  Jakiś czas po tym, jak udało nam się stworzyć wygodny przepływ pracy, odkryliśmy, że nasze „niekończące się zaległości” magicznie się opróżniły.