Jak najlepiej wykorzystać MotioCI we wspieraniu sprawdzonych praktyk

MotioCI posiada zintegrowane wtyczki do tworzenia raportów Cognos Analytics. Blokujesz raport, nad którym pracujesz. Następnie, gdy skończysz sesję edycji, zaewidencjonujesz ją i dołączysz komentarz, aby zarejestrować to, co zrobiłeś. W komentarzu można zawrzeć odniesienie do zgłoszenia w zewnętrznym systemie śledzenia defektów lub żądania zmian.

Możesz znaleźć dodatkowe informacje o tym, jak skonfigurować połączenie między MotioCI a system biletowy innej firmy w MotioCI Przewodnik administratora w sekcji Korzystanie MotioCI z systemami biletowymi innych firm. Słowo kluczowe (poprawki, zamknij) z numerem biletu zamknie bilet. Lub używając słowa kluczowego, takiego jak referencje plus numer biletu zapisze komentarz do odprawy w systemie biletowym i pozostawi bilet otwarty.

Zastosowanie systemu biletowego – takiego jak Atlassian® JIRA, Microsoft Windows™ Trac lub wiele innych – wspomaga zarządzanie projektami poprzez śledzenie konkretnych zadań, problemów i ich rozwiązywania. Bilety stanowią środek komunikacji między autorami lub twórcami raportów a użytkownikami końcowymi, zespołem testowym i innymi interesariuszami. System biletowy zapewnia również metodę śledzenia defektów i zapewniania ich usunięcia przed promocją raportu do produkcji.

Typowy przepływ pracy do tworzenia raportów

Żeby było jasne, integracja MotioCI z systemem biletowym to nie jedyny sposób, w jaki Twój zespół będzie wchodzić w interakcję z systemem biletowym. Zazwyczaj, jak pokazano na załączonym schemacie przepływu pracy, proces tworzenia raportu w środowisku Cognos Analytics z MotioCI może wyglądać mniej więcej tak:

1. Zaległości w pracy. Tworzony jest nowy bilet. Analityk biznesowy dokumentuje wymagania biznesowe dla nowego raportu i wprowadza go bezpośrednio do systemu zgłoszeń, tworząc zgłoszenie. Wkłada bilet do zaległości w pracy stan.
2. oprogramowania. Zgłoszeniom zaległości można nadać priorytet na wiele różnych sposobów, ale ostatecznie zgłoszenie zostanie przypisane do autora raportu i oznaczone jej imieniem i nazwiskiem. Stan biletu może ulec zmianie na w_dev. Stworzy nowy raport. Podczas opracowywania raportu w Cognos Analytics będzie sprawdzać swoje zmiany i odwołuje się do zgłoszenia w komentarzu do ewidencjonowania, np. „Utworzono nowy raport; początkowa wersja; dodana podpowiedź i zapytania pomocnicze, nr ref. #592”. Lub „Dodano zapytanie o fakty i tabelę przestawną; filtry i formatowanie, nr ref. #592”. (W MotioCI, numer hashtagu staje się hiperłączem bezpośrednio do zgłoszenia.) W ciągu kilku dni może sprawdzić raport, wprowadzić zmiany i ponownie zaewidencjonować go z odniesieniem do zgłoszenia.
3. Rozwój zakończony. Po tym, jak programista raportów zakończy raport i przetestował go, zauważa w zgłoszeniu w systemie zgłoszeniowym, że jest gotowy do przetestowania przez kontrolę jakości i zmienia stan z w_rozwoju do gotowe_do_kontroli jakości. Ten stan jest flagą dla MotioCI Administrator lub rola odpowiedzialna za promowanie raportów Cognos, że raport jest gotowy do migracji do środowiska QA w celu testowania.
4. Promotion do kontroli jakości. Administrator promuje raport i zmiany stanu do w_QA. Ten stan informuje zespół ds. kontroli jakości, że raport jest gotowy do przetestowania.
5. Testowanie. Zespół QA testuje raport pod kątem wymagań biznesowych. Raport albo przechodzi testy, albo nie. Jeśli raport nie przejdzie testów kontroli jakości, zgłoszenie zostanie oznaczone symbolem w Dev stan, zwracając się do twórcy raportu w celu uzyskania poprawek.
6. Testowanie powiodło się. Jeśli raport przejdzie pomyślnie, zespół kontroli jakości informuje administratora, że ​​jest gotowy do przejścia do produkcji poprzez oznaczenie go gotowy do Prod stan.
7. Promotion do produkcji. Gdy raport jest gotowy do produkcji, można uzyskać ostateczne zatwierdzenia i zaplanować wydanie, być może w połączeniu z innymi ukończonymi raportami. Administrator promuje raport do środowiska Cognos Production. Umieszcza bilet w Gotowe stan wskazujący, że rozwój i testowanie zostały zakończone i został przeniesiony do produkcji. To zamyka bilet.

Zarządzanie procesem tworzenia raportu

Ten proces zarządzania biletami implikuje, a sprawdzone praktyki dyktują, że:

• Każdy nowy raport powinien mieć bilet z wymaganiami biznesowymi, do których należy zaprojektować raport.
• Każda usterka powinna mieć bilet, aby zarejestrować wszelkie błędy lub problemy z raportem.
• Za każdym razem, gdy raport jest edytowany, MotioCI Komentarz do odprawy powinien zawierać numer biletu, który został zaadresowany.
• Każdy raport, który jest promowany z Dev do QA, powinien mieć skojarzony bilet, który administrator może potwierdzić, że opracowywanie zostało ukończone i jest gotowe do przeniesienia do środowiska QA.
• Każdy raport, który jest promowany z kontroli jakości do produkcji, powinien mieć zgłoszenie, które ma historię pokazującą, że opracowywanie zostało ukończone, przeszedł kontrolę jakości, otrzymał wszystkie wymagane zgody kierownictwa i został awansowany.
• Każdy raport w środowisku produkcyjnym powinien mieć digital papierowa ścieżka od koncepcji do testowania, naprawy, rozwiązania, zatwierdzenia i promotion.

Ten ostatni punkt jest ulubieńcem audytorów do weryfikacji. Może zapytać: „czy możesz mi pokazać, w jaki sposób potwierdzasz, że wszystkie raporty w środowisku produkcyjnym są zgodne z udokumentowanym procesem wystawiania biletów i zatwierdzania?” Jednym ze sposobów udzielenia odpowiedzi audytorowi może być dostarczenie listy wszystkich raportów, które zostały przeniesione, i poproszenie go o przejrzenie zgłoszeń w poszukiwaniu takiego, który nie jest zgodny z Twoim procesem.

Alternatywnie, i najlepiej, możesz podać listę raportów, które: nie przestrzegaj zdefiniowanego przez Ciebie procesu opracowywania i wystawiania biletów. Tutaj przyda się ten raport: „Raporty promowane bez biletów”. Jest to raport wyjątków z listy raportów, które mają nie przestrzegał najlepszych praktyk, aby każda zmiana raportu była powiązana z biletem. To jeden z niewielu raportów, które chcesz opróżnić. Nie będzie zawierał żadnych rekordów, jeśli wszystkie promowane raporty mają powiązany z nim bilet. Innymi słowy, raport pojawi się na liście tylko wtedy, gdy znajduje się w środowisku produkcyjnym, a promowany raport nie zawierał numeru zgłoszenia w komentarzu.

Proces z korzyściami

Jakie są korzyści z tego procesu lub dlaczego warto to robić w swojej organizacji?

• Lepsza współpraca zespołowa: system biletów może w rzeczywistości łączyć osoby w rolach, które normalnie nie mogą się komunikować. Na przykład autorzy raportów i użytkownicy końcowi lub kierownik projektu i zespół QA. Ścieżka biletów zapewnia wspólne miejsce do komunikowania się na temat współdzielonego zasobu, raportu w trakcie opracowywania.
• Mniejsze koszty:
  • Wady wykryte i naprawione wcześniej są znacznie tańsze, niż gdyby uciekły do ​​produkcji.
  • Poprawiona wydajność – autorzy raportów zawsze pracują na podstawie ticketa, który jest dobrze zdefiniowanym zestawieniem pracy.
  • Skrócony czas dzięki automatyzacji procesów ręcznych
• Ulepszona dokumentacja: Ten proces staje się samodokumentującą bazą wiedzy o defektach i sposobie ich rozwiązania.
• Ulepszone prognozowanie i analityka: możesz teraz śledzić kluczowe wskaźniki wydajności i porównywać je z umowami SLA. Większość systemów biletowych zapewnia tego typu analizy.
• Ulepszone wsparcie wewnętrzne: Twój zespół wsparcia, inni programiści raportów (a nawet Twoje przyszłe ja!) mogą sprawdzić, w jaki sposób podobne defekty zostały rozwiązane w przeszłości. Ta wspólna baza wiedzy może prowadzić do szybkiego rozwiązywania defektów.
• Większa satysfakcja użytkownika końcowego: Dzięki bezpośredniemu dostępowi do programistów za pośrednictwem systemu zgłoszeń, użytkownicy mogą oczekiwać szybkiego rozwiązania defektów, a także monitorowania postępu żądanego raportu za pośrednictwem systemu.

Wnioski

To jeden z przykładów bogatych korzyści płynących z przestrzegania sprawdzonych praktyk i wartości dobrze zdefiniowanych procesów. Co więcej, nowy MotioCI raport „Raporty promowane bez biletów” może być ogromną pomocą w odpowiadaniu na pytania audytora lub po prostu wewnętrznym monitorowaniu przestrzegania standardów korporacyjnych.