Użyj TFS, aby śledzić błędy z działu wsparcia produkcji

Właśnie przeniosłem się do nowej firmy i używają TFS 2010 (2012 za kilka miesięcy) jako systemu kontroli wersji, a ostatnio zacząłem używać go jako systemu śledzenia pracy dla programistów.

Wydaje się jednak, że nie ma systemu śledzenia błędów do użytku przez osoby spoza procesu programowania i testowania. Wsparcie produkcyjne otrzymuje raporty o problemach, naprawia je na bieżąco i w tej chwili przekazuje użytkownikom. To musi zostać zmienione, ale tak naprawdę nie chcę mieć systemu do śledzenia błędów i śledzenia pracy programistów.

Czy istnieje sposób, w jaki mogę stworzyć bardzo lekki sposób wprowadzania błędów w TFS, podobnie jak robi to FogBugz? Zalogowanie się do TFS w celu wypełnienia raportu o błędzie wydaje się być znacznie cięższe i trzeba go powiązać z konkretną aplikacją. Wsparcie może być w stanie to zrobić, ale chcę mieć możliwość segregowania elementu i potencjalnie zmiany powiązania na coś innego niż aplikację.

W przeszłości korzystałem z FogBugza, a kiedy dodajesz błąd, możesz dodać dowolną / bardzo małą liczbę elementów do przedmiotu, aby został on przynajmniej zarejestrowany, a później możesz go odesłać, aby uzyskać więcej informacji, gdy przyjdziesz na triage bilet .

W dużej mierze zależy to od tego, jakie pola chcesz, jak wskazano w 17 z 26: TFS jest wysoce konfigurowalny. Powodem, dla którego chciałbym to zrobić, zamiast używać JIRA, jest to, że masz jeden pogląd na to, nad czym pracują twoi programiści, zamiast konieczności agregowania dwóch systemów.

TFS ma również planowanie zdolności produkcyjnych zasobów, a jeśli nie wykazujesz wad produkcyjnych w planowaniu (i zajmują one znaczną część twojego czasu), to tak naprawdę nie planujesz swojej zdolności produkcyjnej. Powiedziałbym, że jest to idealne rozwiązanie dla zespołów, w których programiści korzystają z TFS i wspierają produkcję (np. DevOps).

Nie oznacza to, że nie możesz używać innych narzędzi do głównej pracy działu wsparcia produkcji / ITIL, musisz tylko upewnić się, że integrują się one ręcznie lub najlepiej automatycznie. Większość takich narzędzi pozwala na niestandardowe zaczepy, a TFS na pewno tak.

W każdym razie do głównego pytania. Korzystam z szablonów CMMI TFS (które faktycznie działają dobrze z Agile BTW) i właśnie dodałem jedno pole do jednego z rozwijanych menu.

Oto kroki:

Zainstaluj narzędzia elektryczne TFS

Otwórz szablon elementu pracy z serwera

Edytuj pole Dyscyplina

Dziedzina dyscypliny jest „rodzajem” pracy związanej z wadą. Standardowe wartości to:

• Analiza
• Doświadczenie użytkownika
• Edukacja użytkowników
• Rozwój
• Test

Po prostu dodamy do tej listy „Produkcja”. Najpierw edytuj pole Dyscyplina:

Następnie kliknij kartę Reguły i edytuj regułę DOPUSZCZALNE WARTOŚCI:

Następnie kliknij „Nowy” i dodaj „Produkcja” jako jedną z wartości.

Klikaj „OK”, aż wrócisz na listę pól.

Zapisz szablon elementu pracy

OK, teraz gotowe. Możesz tworzyć nowe błędy i wskazywać ich typ jako Produkcja. Stworzyłbym również kilka zapytań o przedmioty pracy, analizując wady produkcyjne, i dodałem je do przypiętych przedmiotów. Na koniec spójrz na istniejące zapytania o błędy i może zmień ich kolejność, aby najpierw pojawiały się błędy „produkcyjne” (jeśli to możliwe).

Nie, zgadza się - najważniejszy ALM Microsoftu nie jest tak naprawdę przydatny poza Visual Studio i zespołami programistów.

Możesz uzyskać dostęp do elementów pracy za pomocą Eksploratora zespołu (który jest bardzo skróconą wersją VS) lub uzyskać do niego dostęp za pośrednictwem strony internetowej TFS. Żadne z tych opcji nie są szczególnie dobre, ponieważ pola błędów przypominają starożytne narzędzia do śledzenia błędów „korporacyjnych”, z których miałem nieszczęście korzystać w przeszłości.

Nie ma prawdziwego rozróżnienia między błędami w TFS - istnieje tylko jeden moduł śledzący, który filtrujesz za pomocą pola w samym elemencie, więc użyj pola kategorii, a następnie utwórz raport, który pokazuje tylko określony typ kategorii. Myślę, że to twoja jedyna realistyczna opcja z TFS.

Jeśli chcesz śledzić problemy zewnętrzne, uważam, że TFS jest złym wyborem, lepiej użyj czegoś takiego jak Jira lub Redmine i użyj tego do zarządzania błędami - ich interfejsy są znacznie, znacznie ładniejsze i łatwiejsze w użyciu niż TFS. Szczególnie podoba mi się sposób, w jaki możesz wysłać wiadomość e-mail do Redmine. Stwarza to nowy problem dla Ciebie, który był idealną funkcją użyteczności dla pracowników zewnętrznych.

Użytkownicy niebędący programistami mogą uzyskać dostęp do systemu śledzenia elementów pracy TFS za pomocą przeglądarki internetowej, aby przejść do portalu Team Project. Aby znaleźć adres URL, przejdź do Team-> Show Project Portal w Visual Studio. Stamtąd każdy z uprawnieniami może przeglądać, tworzyć lub modyfikować elementy pracy. Mogą również generować wszelkiego rodzaju raporty, aby sprawdzić stan rzeczy.

Typy dostępnych elementów pracy i pola w elementach pracy różnią się w zależności od konfiguracji TFS (przede wszystkim według wyboru szablonów procesów).

Informacje wymagane do wprowadzenia błędu zależą również od konfiguracji TFS. W naszym przypadku potrzebujemy tytułu, kroków do odtworzenia i kompilacji, w której został znaleziony. System śledzenia elementów roboczych TFS jest bardzo wydajny i elastyczny. Może być tak skomplikowane lub tak proste, jak chcesz - wszystko sprowadza się do konfiguracji.

W tym poście na blogu Microsoft opisano planowane ulepszenia TFS, które powinny pomóc w obniżeniu kosztów ogólnych:

• Nowa forma przedmiotu pracy, która jest łatwiejsza dla oczu i zawiera opcje dyskusji i wzmianek, podobne do Facebooka i Twittera.
• Pola niestandardowe
• Ulepszona obsługa Kanban, np. Szybkie dodawanie zadań do elementu pracy.
• Wspomina także o pulpitach nawigacyjnych i danych.