Jak odradzasz korzystanie z udostępnionego arkusza kalkulacyjnego do śledzenia błędów / problemów?

W naszej firmie programiści chcą używać odpowiedniego narzędzia do śledzenia błędów w celu zarządzania problemami w naszej aplikacji. Zarząd nalega jednak na korzystanie z udostępnionego arkusza kalkulacyjnego (wcześniej udostępnionego pliku programu Excel, obecnie arkusza kalkulacyjnego w rozwiązaniu bazowym sieci Web umożliwiającego równoczesny dostęp).

Ich argumentem jest to, że arkusz kalkulacyjny pozwala im na lepszy podgląd stanu projektu, ponieważ mogą szybko sprawdzić, ile błędów jest otwartych. To pozwala im również zobaczyć, kto pracuje nad każdym błędem, i uzyskać szacunkowy czas potrzebny do zamknięcia ich wszystkich (ponieważ deweloper jest zobowiązany do wypełnienia oszacowania czasu błędu, nad którym pracują).

Jak można zrozumieć, nie jest to naprawdę praktyczne dla programistów (oprogramowanie do śledzenia błędów zostało wynalezione z jakiegoś powodu). Jak więc mogę polecić oprogramowanie do śledzenia błędów, aby ułatwić pracę programistom?

Jako bonus, które oprogramowanie poleciłbyś, aby umożliwić kierownictwu uzyskanie informacji zwrotnych (liczba błędów, kto nad nimi pracuje, szacowanie czasu) z widokiem na wysokim poziomie?

Jak więc mogę polecić oprogramowanie do śledzenia błędów, aby ułatwić pracę programistom?

Biorąc pod uwagę to oświadczenie:

Arkusz kalkulacyjny pozwala im na lepszy podgląd stanu projektu, ponieważ mogą szybko sprawdzić, ile błędów jest otwartych.

musisz przyjrzeć się systemom wyposażonym w narzędzia do raportowania, które skutecznie umożliwiają tworzenie arkuszy kalkulacyjnych w „czasie rzeczywistym” (lub jak najbliżej niego). Gdy znajdziesz jeden z tych wyjaśnień, że umożliwienie programistom korzystania z „właściwego” systemu oznacza, że ​​dane, którymi są zainteresowani, będą (miejmy nadzieję) bardziej dokładne i aktualne (na przykład).

Która wersja arkusza kalkulacyjnego jest aktualna? Kto ma ten arkusz kalkulacyjny?

Każdy porządny robak błędów zrobi to, co potrafi arkusz kalkulacyjny, tylko:

• wyśle ​​e-mailem odpowiednie strony, gdy coś się zmieni
• zapewnia pojedyncze kanoniczne źródło aktualnych informacji
• pozwala na raporty podsumowujące, które dają ogólny obraz stanu projektu

Do moich osobistych projektów używam Mantis (tylko dlatego, że jest naprawdę łatwy w konfiguracji). Praca wykorzystuje Trac z integracją Mercurial.

Mantis zapewnia liczbę błędów otwartych / zamkniętych / przypisanych po wyjęciu z pudełka, i wyobrażam sobie, że większość robaczy błędów. Nie wiem o szacowaniu czasu, bo nie zawracałem sobie głowy szukaniem. Trac (lub instalacja tutaj w pracy) ma oszacowanie czasu i łatwo jest napisać niestandardowy raport, który, powiedzmy, sumuje oszacowania na kamień milowy.

Odpowiedzi wszystkich innych są dobre. Jeszcze jeden aspekt przychodzi mi do głowy.

Co z bezpieczeństwem wokół arkusza kalkulacyjnego. Czy kierownictwo nie powinno obawiać się, że dowolny przypadkowy programista może przypadkowo nacisnąć klawisze CTRL + A, DELETE i naprawdę popsuć? Właściwy system śledzenia błędów nie pozwoli na tego rodzaju uszkodzenie danych. I to nawet nie wyjaśnia złośliwości. Co jeśli konkretny programista chciałby uzyskać więcej kredytu i zaczął przypisywać sobie wszystkie poprawki błędów? Prawdziwy system miałby ścieżkę audytu, w której tego rodzaju rzeczy byłyby zauważalne. Arkusz kalkulacyjny nie.

Musisz pokazać Zarządowi, że ich wymagania zostaną spełnione.

Ich argumentem jest to, że arkusz kalkulacyjny pozwala im na lepszy podgląd stanu projektu, ponieważ mogą szybko sprawdzić, ile błędów jest otwartych. To pozwala im również zobaczyć, kto pracuje nad każdym błędem, i uzyskać szacunkowy czas potrzebny do zamknięcia ich wszystkich (ponieważ deweloper jest zobowiązany do wypełnienia oszacowania czasu błędu, nad którym pracują).

Skonfiguruj więc system fikcyjny i pokaż im wersje demonstracyjne, aby mogli uzyskać te informacje równie dobre, a może nawet lepsze niż przy użyciu arkusza kalkulacyjnego.

Jak dotąd wszyscy wymyślili podobne i właściwe odpowiedzi. Jest jeden ważny aspekt, o którym jeszcze nie mówiono. Aby śledzić błędy i upewnić się, że nic nie prześlizguje się przez pęknięcia, potrzebujesz dwóch rzeczy:

• Dobre raportowanie, zarówno podsumowanie, jak i szczegółowe informacje - można to później przeszukać
• Każdy musi wiedzieć, gdzie znajduje się najbardziej aktualna kopia.

W prawie każdym środowisku, które zaleca korzystanie z arkusza kalkulacyjnego Excel, na każdym komputerze są różne kopie tego arkusza kalkulacyjnego - i żadne z nich nie jest takie samo. To sprawia, że ​​proces przeglądu postępów jest niezwykle trudny i przynosi efekt przeciwny do zamierzonego.

Scentralizowany serwer, taki jak Trac, RedMine, JIRA, Mantis lub cokolwiek chcesz, rozwiązuje oba te problemy. W tym momencie chodzi o to, co najlepiej odpowiada potrzebom Twojej firmy. W zależności od środowiska narzędzia te można zintegrować z IDE, podobnie jak system kontroli wersji (Eclipse ma tę funkcję). To znacznie ułatwia pracę z przypisanymi błędami.

Nie znam twojego środowiska, ale dla użytkowników programu Visual Studio zdecydowanie sugeruję TFS. Łączy zarówno kontrolę źródła, jak i śledzenie problemów, z pełnymi możliwościami raportowania. Oferuje również poziomy uprawnień, pełne śledzenie historii (tj. Kto zaktualizował błąd, a jeśli skonfigurowano, dlaczego), pozwala rozróżnić „błąd” i „problem” i „ulepszenie” i cokolwiek innego polub i całkowicie integruje się z Visual Studio IDE. Łączy błąd z kodem, który został zarejestrowany, który można powiązać z konkretnymi kompilacjami. I wiele więcej.

Użyłem wielu różnych systemów kontroli źródła (VSS, SVN, TFS ...) i wielu systemów śledzenia błędów (niestandardowe systemy zastrzeżone, Tracker, SharePoint i tak, nawet Excel), ale dla moich pieniędzy (i to jest dobry kawałek zmian), TFS jest wart inwestycji w pieniądze i czas.

I tak, możesz eksportować do (i importować z) Excela.

Aby pomóc w sprzedaży przejścia do odpowiedniego narzędzia do śledzenia problemów, powinieneś spróbować dowiedzieć się, jakie problemy ma zarządzanie w twoim obecnym systemie (na pewno będzie „byłoby miło, gdyby ...”) i sprawdzić, czy nie możesz zadrapać tego swędzenia dla nich.

Czytanie argumentów kierownictwa

Ich argumentem jest to, że arkusz kalkulacyjny pozwala im na lepszy podgląd stanu projektu, ponieważ mogą szybko sprawdzić, ile błędów jest otwartych. To pozwala im również zobaczyć, kto pracuje nad każdym błędem, i uzyskać szacunkowy czas potrzebny do zamknięcia ich wszystkich (ponieważ deweloper jest zobowiązany do wypełnienia oszacowania czasu błędu, nad którym pracują).

Zgodziłem się z nich wszystkich i każdy jeden jest spełnione przez JIRA (JIRA wspominam tylko dlatego, że jest to, czego używam, jestem pewien, że istnieją inne wartościowe kandydaci)

Trzeba podkreślić, że przy pomocy narzędzia takiego jak JIRA nie tylko zachowają one wszystkie zalety twojego obecnego ustawienia, ale także uzyskają wiele nowych korzyści.

Czas opowieści.

Kilka miesięcy temu wróciłem z tygodniowych wakacji i odkryłem, że cała moja firma przewróciła się na głowie. Projekt, nad którym od miesięcy pracowała inna sekcja działu rozwoju, nagle stał się pilnym priorytetem, a cały zespół został wycofany z tego, nad czym pracowali, aby to odrzucić. Na spotkaniu tego dnia właściciel firmy poprosił nas, abyśmy wybili kilka elementów tego dnia, a resztę następnego dnia i bylibyśmy w dobrej formie.

Sześć tygodni później w końcu dostarczyliśmy to po prawie nieprzerwanych cyklach pracy / snu.

Naszym miernikiem „ukończonego” było to, że klient nie miał już żadnych opinii. Nowe i ekscytujące rzeczy pojawiałyby się w każdej wersji ich opinii (dostarczonej nam przez e-mail), która nigdy wcześniej się nie pojawiła, a każde wypowiedziane słowo było natychmiast częścią specyfikacji (uzasadnione zwrotem „zróbmy to „).

Późną nocą pewnie do diabła Miałem IT do zarządzania raportami błędów przez e-mail i wydruki ze znacznikami wyboru. Zainstalowałem Mantis na naszym serwerze testowym i załadowałem do niego dokument zwrotny, który właśnie otrzymałem dla mojej sekcji. Skonfigurowałem mojego menedżera jako użytkownika i pozwalałem mu otrzymywać e-maile od niego po zamknięciu problemów.

W ciągu około 6 godzin miałem cały zespół. PM filtrował wiadomości e-mail klientów do Mantis, programiści zgłaszali roszczenia i działające listy problemów. Co więcej, byli w stanie poprosić o wyjaśnienia i komunikację w systemie, co skutkowało papierowym śladem szczegółów każdego produktu.

Następnego dnia poprosili mnie, abym poprowadził Tech przez resztę projektu. To było jak wręczanie granatu na żywo, ale wziąłem go i pobiegłem z nim. Dwa tygodnie później w końcu wyczerpaliśmy zdolność naszego klienta do szarpnięcia za nos i uruchomienia witryny. Mantis jest teraz sposobem, w jaki radzimy sobie z błędami i może stać się sposobem, w jaki obsługujemy żądania funkcji od początku projektu.

TL; DR: Zainstaluj go samodzielnie i zacznij używać go do własnych celów. Niech sam udowodni swoją wartość.

BTW, to są te same zasady, które stosuję odnośnie kontroli wersji. Używamy Subversion zgodnie z zasadami wymaganymi przez blokadę, ponieważ mój menedżer nie ufa scalaniu plików. W porządku, ale po sprawdzeniu projektu SVN natychmiast tworzę lokalne repozytorium git na własny użytek w programowaniu.

Używamy Atlassian Jira .

Ma wiele dostępnych raportów takich jak ten:

Musisz utworzyć arkusz kalkulacyjny, który gdy otworzy go menedżer, wszystkie niezbędne dane raportowania zostaną zaktualizowane z wybranej aplikacji. Jeśli sprawisz, że to zadziała, nie będzie żadnych argumentów.

rzeczy, które mogą pójść nie tak z arkuszem kalkulacyjnym śledzenia błędów w udziale sieciowym:

• nikt inny nie może go edytować, gdy ktoś zostawia go otwartego, a następnie zamyka stację roboczą i idzie na lunch.
  • „oczywistym” obejściem jest zapisanie nowej wersji do pisania. To tworzy gałąź - a Excel nie radzi sobie z scalaniem. Czyjaś praca zostanie utracona.
• dokument można zapisać z ukrytymi wierszami, problem jest pomijany przez tygodnie.
• wszystko można usunąć, a śledzenie historii jest marginalne. „co się stało ze szczegółową analizą problemu, którą wprowadziłem w zeszłym tygodniu?”
• łatwo jest dodawać wartości do pól „zastrzeżonych”. „W jaki sposób dotkliwość tego błędu została oznaczona jako„ Epicka porażka ”?”
• wytnij i wklej zastępuje formuły. Obliczenia mogą łatwo stać się stałymi.

Przeżyłem to wszystko. Nadal udało nam się dostarczyć ... To było tylko trzy miesiące spóźnienia i kosztowały tysiące nieplanowanych nadgodzin.

"Jest wolne!" jest zwykle całkiem dobrym argumentem. Pivotal Tracker jest bezpłatny, nie wymaga instalacji i może bardzo łatwo dać menedżerom lepszy widok na wysokim poziomie niż jest to możliwe przy niskim arkuszu kalkulacyjnym.

Edytować:

Ku mojemu rozdrażnieniu właśnie ogłoszono, że Pivotal Tracker nie będzie już dostępny za darmo. :(