Sådan får du mest ud af MotioCI til at understøtte dokumenteret praksis

MotioCI har integrerede plugins til Cognos Analytics-rapportskrivning. Du låser den rapport, du arbejder på. Så, når du er færdig med din redigeringssession, tjekker du den ind og inkluderer en kommentar for at registrere, hvad du gjorde. Du kan i kommentaren inkludere en henvisning til en billet i et eksternt defektsporing eller ændringsanmodningssystem.

Du kan finde yderligere detaljer om, hvordan du opsætter forbindelsen mellem MotioCI og dit tredjeparts billetsystem i MotioCI Administratorvejledning under Brug MotioCI med tredjeparts billetsystemer. Et søgeord (retter, luk) med billetnummeret lukker billetten. Eller ved at bruge et søgeord som f.eks referencer plus billetnummeret vil skrive check-in kommentaren til billetsystemet og lade billetten stå åben.

Brugen af ​​et billetsystem – som Atlassian® JIRA, Microsoft Windows™ Trac eller mange andre – hjælper projektstyringen ved at spore specifikke opgaver, problemer og deres løsning. Billetter giver et middel til kommunikation mellem forfattere eller rapportudviklere og slutbrugere, testteamet og andre interessenter. Et billetsystem giver også en metode til at spore defekter og sikre, at de bliver rettet, før en rapport promoveres til produktion.

Typisk arbejdsgang for rapportudvikling

For at være klar, integration af MotioCI med et billetsystem er ikke den eneste måde, dit team vil interagere med billetsystemet på. Typisk, som illustreret i det medfølgende workflowdiagram, processen med rapportudvikling i et Cognos Analytics-miljø med MotioCI kan være noget som dette:

1. Efterslæb. En ny billet oprettes. En forretningsanalytiker dokumenterer forretningskravene til en ny rapport og indtaster den direkte i billetsystemet ved at oprette en billet. Han placerer billetten i efterslæb tilstand.
2. Udvikling. Backlog-billetterne kan prioriteres på en række forskellige måder, men i sidste ende vil billetten blive tildelt en rapportudvikler og tagget med hendes navn. Billettens tilstand kan ændres til in_dev. Hun vil oprette en ny rapport. Efterhånden som hun udvikler rapporten i Cognos Analytics, vil hun tjekke sine ændringer ind og henvise til billetten i check-in-kommentaren, f.eks. "Oprettet ny rapport; oprindelige version; tilføjet promptside og understøttende forespørgsler, refs #592". Eller "Tilføjet faktaforespørgsel og krydstabel; filtre og formatering, refs #592." (I MotioCI, bliver hashtag-nummeret et hyperlink direkte til billetten.) Hun kan tjekke rapporten ud, foretage ændringer og tjekke den ind igen med billetreferencen flere gange over en periode på dage.
3. Udvikling afsluttet. Efter at rapportudvikleren har færdiggjort rapporten og bænktestet den, noterer hun i billetten i billetsystemet, at den er klar til at blive testet af QA og skifter tilstand fra kl. in_Dev til klar_til_QA. Denne stat er et flag for MotioCI Administrator eller rolle ansvarlig for at promovere Cognos-rapporter, at rapporten er klar til at migrere til QA-miljøet til test.
4. ommotion til QA. Administratoren fremmer rapporten og ændringer til staten til in_QA. Denne tilstand fortæller QA-teamet, at rapporten er klar til at blive testet.
5. Testing. QA-teamet tester rapporten i forhold til forretningskravene. Rapporten består enten eller ikke består prøverne. Hvis rapporten mislykkes QA-testen, er billetten mærket med i Dev tilstand, vender tilbage til rapportudvikleren for rettelser.
6. Test lykkedes. Hvis rapporten godkendes, fortæller QA-teamet administratoren, at det er klar til at promovere til produktion ved at mærke det klar til prod tilstand.
7. ommotion til produktion. Når rapporten er klar til produktion, kan de endelige godkendelser opnås og frigives planlagt, måske bundtet med andre afsluttede rapporter. Administratoren promoverer rapporten til Cognos Production-miljøet. Han lægger billetten ind Udført angiver, at udvikling og test er afsluttet, og det er flyttet til produktion. Dette lukker billetten.

Ledelse af Rapportudviklingsprocessen

Denne billethåndteringsproces indebærer, og gennemprøvet praksis dikterer, at:

• Hver ny rapport bør have en billet med de forretningskrav, som rapporten skal designes efter.
• Hver defekt bør have en billet til at registrere eventuelle fejl eller problemer med en rapport.
• Hver gang en rapport redigeres, vises MotioCI check-in kommentar bør indeholde det billetnummer, der blev adresseret.
• Hver rapport, der promoveres fra Dev til QA, bør have en tilknyttet billet, som en administrator kan bekræfte, at udviklingen er gennemført, og den er klar til at blive flyttet til QA-miljøet.
• Hver rapport, der promoveres fra QA til produktion, skal have en billet, der har en historik, der viser, at udviklingen er fuldført, den har bestået QA, den har modtaget alle nødvendige ledelsesgodkendelser og er blevet promoveret.
• Hver rapport i produktionsmiljøet bør have en digital papirspor fra idé til test til fiksering til opløsning til godkendelse og promotion.

Dette sidste punkt er en favorit blandt revisorer at validere. Hun spørger måske, "kan du vise mig, hvordan du bekræfter, at alle rapporter i produktionsmiljøet har overholdt din dokumenterede proces med billetsalg og godkendelse?" En måde at svare revisor på kan være at give en liste over alle de rapporter, der er blevet migreret, og få hende til at vade gennem billetterne for at lede efter en, der ikke er i overensstemmelse med din proces.

Alternativt, og mere ideelt, kan du give en liste over rapporter, der gør det ikke overholde den udviklings- og billetproces, som du har defineret. Det er her denne rapport vil være nyttig: "Rapporter fremmet uden billetter”. Det er en undtagelsesrapport af en liste over rapporter, der har ikke overholdt den bedste praksis med at få hver rapportændring knyttet til en billet. Dette er en af ​​de få rapporter, du ønsker skal være tomme. Det vil ikke have nogen registreringer, hvis alle rapporter, der er blevet promoveret, har en billet tilknyttet. En rapport vil med andre ord kun komme på listen, hvis den er i produktionsmiljøet, og rapporten, der blev promoveret, ikke refererede til et billetnummer i kommentaren.

Proces med fordele

Hvad er fordelene ved processen, eller hvorfor skal du gøre dette i din organisation?

• Forbedret teamsamarbejde: Billetsystemet kan faktisk samle personer i roller, som måske ikke normalt kommunikerer. Rapportforfattere og slutbrugere eller projektleder og QA-teamet f.eks. Billetsporet giver et fælles sted at kommunikere om en delt ressource, rapporten under udvikling.
• Reducerede omkostninger:
  • Fejl, der fanges og rettes hurtigere, er meget billigere, end hvis de slipper ud i produktionen.
  • Forbedret effektivitet – rapportforfattere arbejder altid ud fra en billet, som er en veldefineret arbejdserklæring.
  • Reduceret tid gennem automatisering af manuelle processer
• Forbedret dokumentation: Denne proces bliver en selvdokumenterende videnbase om defekter og hvordan de blev løst.
• Forbedrede prognoser og analyser: Du kan nu spore nøglepræstationsindikatorer og sammenligne dem med serviceniveauaftaler. De fleste billetsystemer giver disse typer analyser.
• Forbedret intern support: Dit supportteam, andre rapportudviklere (og endda dit fremtidige jeg!) kan slå op, hvordan lignende defekter blev løst tidligere. Denne delte videnbase kan føre til hurtig løsning af defekter.
• Forbedret slutbrugertilfredshed: Med direkte adgang til udviklere gennem billetsystemet kan brugere forvente hurtig løsning af defekter samt overvåge fremskridtene af en anmodet rapport gennem systemet.

Konklusion

Dette er et eksempel på rige gevinster ved at følge dokumenteret praksis og værdien af ​​at følge veldefinerede processer. Yderligere det nye MotioCI rapport, "Rapporter fremmet uden billetter" kan være en stor hjælp til at besvare spørgsmål fra en revisor eller blot intern overvågning for overholdelse af virksomhedens standarder.