Hur man får ut det mesta av MotioCI för att stödja beprövad praxis

MotioCI har integrerade plugins för Cognos Analytics-rapportförfattande. Du låser rapporten som du arbetar med. Sedan, när du är klar med din redigeringssession, checkar du in den och inkluderar en kommentar för att spela in vad du gjorde. Du kan i kommentaren inkludera en referens till en biljett i ett externt system för defektspårning eller ändringsförfrågan.

Du kan hitta ytterligare information om hur du ställer in anslutningen mellan MotioCI och ditt tredje parts biljettsystem i MotioCI Administratörsguide under Användning MotioCI med tredje parts biljettsystem. Ett nyckelord (fixar, stäng) med biljettnumret kommer att stänga biljetten. Eller genom att använda ett nyckelord som referenser plus biljettnumret kommer att skriva incheckningskommentaren till biljettsystemet och lämna biljetten öppen.

Användningen av ett biljettsystem – som Atlassian® JIRA, Microsoft Windows™ Trac eller många andra – underlättar projektledning genom att spåra specifika uppgifter, problem och deras lösning. Biljetter ger ett sätt att kommunicera mellan författare eller rapportutvecklare och slutanvändare, testteamet och andra intressenter. Ett biljettsystem tillhandahåller också en metod för att spåra defekter och säkerställa att de åtgärdas innan en rapport skickas till produktion.

Typiskt arbetsflöde för rapportutveckling

För att vara tydlig, integrationen av MotioCI med ett biljettsystem är inte det enda sättet att ditt team kommer att interagera med biljettsystemet. Vanligtvis, som illustreras i det medföljande arbetsflödesdiagrammet, processen för rapportutveckling i en Cognos Analytics-miljö med MotioCI kan vara något sånt här:

1. eftersläpningen. En ny biljett skapas. En affärsanalytiker dokumenterar affärskraven för en ny rapport och matar in den direkt i biljettsystemet genom att skapa en biljett. Han placerar biljetten i orderstock tillstånd.
2. Utveckling. Backlog-biljetterna kan prioriteras på ett antal olika sätt, men i slutändan kommer biljetten att tilldelas en rapportutvecklare och taggad med hennes namn. Biljettens tillstånd kan ändras till in_dev. Hon kommer att skapa en ny rapport. När hon utvecklar rapporten i Cognos Analytics kommer hon att checka in sina ändringar och referera till biljetten i incheckningskommentaren, som "Skapat ny rapport; Första versionen; lagt till snabbsida och stödjande frågor, refs #592”. Eller, "Ladda till faktafråga och korstabell; filter och formatering, refs #592.” (I MotioCI, blir hashtaggen en hyperlänk direkt till biljetten.) Hon kan kolla in rapporten, göra ändringar och checka in den igen med biljettreferensen flera gånger under en period av dagar.
3. Utvecklingen avslutad. Efter att rapportutvecklaren har slutfört rapporten och bänktestat den, noterar hon i biljetten i biljettsystemet att den är redo att testas av QA och ändrar tillstånd fr.o.m. in_Dev till redo_för_QA. Denna stat är en flagga för MotioCI Administratör, eller roll som ansvarar för att främja Cognos-rapporter, att rapporten är redo att migrera till QA-miljön för testning.
4. Promotion till QA. Administratören främjar rapporten och ändringar till staten till in_QA. Detta tillstånd låter QA-teamet veta att rapporten är redo att testas.
5. Testning. QA-teamet testar rapporten mot affärskraven. Rapporten antingen godkänd eller underkänd på proven. Om rapporten misslyckas med QA-testning, är biljetten märkt med i Dev tillstånd och återvänder till rapportutvecklaren för korrigeringar.
6. Testningen lyckades. Om rapporten godkänns berättar QA-teamet för administratören att det är redo att marknadsföra till produktion genom att märka det redo för prod tillstånd.
7. Promotion till produktion. När rapporten är klar för produktion kan slutgiltiga godkännanden erhållas och släppas schemalagd, eventuellt tillsammans med andra färdiga rapporter. Administratören marknadsför rapporten till Cognos Production-miljö. Han lägger in biljetten Färdig stat som indikerar att utveckling och testning är klar och den har flyttats till produktion. Detta stänger biljetten.

Hantering av Rapportutvecklingsprocessen

Denna biljetthanteringsprocess innebär och beprövad praxis dikterar att:

• Varje ny rapport bör ha en biljett med affärskraven att utforma rapporten efter.
• Varje defekt bör ha en biljett för att registrera eventuella buggar eller problem med en rapport.
• Varje gång en rapport redigeras visas MotioCI incheckningskommentarer bör innehålla biljettnumret som adresserades.
• Varje rapport som marknadsförs från Dev till QA bör ha en tillhörande biljett som en administratör kan bekräfta att utvecklingen har slutförts och den är redo att flyttas till QA-miljön.
• Varje rapport som marknadsförs från QA till Produktion bör ha en biljett som har en historik som visar att utvecklingen är klar, den har klarat QA, den har fått alla nödvändiga ledningsgodkännanden och har befordrats.
• Varje rapport i produktionsmiljön bör ha en digital pappersspår från idé till testning till fixering till upplösning till godkännande och proffsmotion.

Denna sista punkt är en favorit bland revisorer att validera. Hon kanske frågar, "kan du visa mig hur du bekräftar att alla rapporter i produktionsmiljön har följt din dokumenterade process för biljettförsäljning och godkännande?" Ett sätt att svara revisorn kan vara att tillhandahålla en lista över alla rapporter som har migrerats och låta henne gå igenom biljetterna för att leta efter en som inte överensstämmer med din process.

Alternativt, och mer idealiskt, kan du tillhandahålla en lista över rapporter som gör det inte följa den utvecklings- och biljettprocess som du har definierat. Det är där denna rapport kommer att vara användbar: "Rapporter som marknadsförs utan biljetter”. Det är en undantagsrapport för en lista över rapporter som har inte följt de bästa metoderna för att ha varje rapportändring kopplad till en biljett. Det här är en av de få rapporter du vill ska vara tomma. Det kommer inte att ha några poster om alla rapporter som har marknadsförts har en biljett kopplad till sig. Med andra ord kommer en rapport bara att synas på listan om den finns i produktionsmiljön och rapporten som marknadsfördes inte hänvisade till ett biljettnummer i kommentaren.

Process med förmåner

Vilka är fördelarna med processen, eller varför ska du göra detta i din organisation?

• Förbättrat teamsamarbete: Biljettsystemet kan faktiskt samla individer i roller som kanske inte normalt kommunicerar. Rapportförfattare och slutanvändare, eller projektledare och QA-teamet till exempel. Biljettspåret ger en gemensam plats för att kommunicera om en delad resurs, rapporten under utveckling.
• Minskade kostnader:
  • Defekter som fångas upp och åtgärdas tidigare är mycket billigare än om de kommer ut i produktionen.
  • Förbättrad effektivitet – rapportförfattare arbetar alltid utifrån en biljett som är en väldefinierad arbetsbeskrivning.
  • Minskad tid genom automatisering av manuella processer
• Förbättrad dokumentation: Denna process blir en självdokumenterande kunskapsbas av defekter och hur de löstes.
• Förbättrad prognos och analys: Du kan nu spåra nyckeltal och jämföra dem med servicenivåavtal. De flesta biljettsystem tillhandahåller dessa typer av analyser.
• Förbättrad intern support: Ditt supportteam, andra rapportutvecklare (och till och med ditt framtida jag!) kan se hur liknande defekter åtgärdades tidigare. Denna delade kunskapsbas kan leda till snabb lösning av defekter.
• Förbättrad slutanvändarnöjdhet: Med direkt tillgång till utvecklare via biljettsystemet kan användare förvänta sig snabb lösning av defekter samt övervaka framstegen för en begärd rapport genom systemet.

Slutsats

Detta är ett exempel på rik vinst till att följa beprövad praxis och värdet av att följa väldefinierade processer. Vidare den nya MotioCI rapport, "Rapporter som marknadsförs utan biljetter" kan vara en stor hjälp för att ta itu med frågor från en revisor, eller helt enkelt intern övervakning för att följa företagsstandarder.