Hvordan få mest mulig ut av MotioCI for å støtte utprøvd praksis

MotioCI har integrerte plugins for Cognos Analytics-rapportutforming. Du låser rapporten du jobber med. Så, når du er ferdig med redigeringsøkten, sjekker du den inn og inkluderer en kommentar for å registrere hva du gjorde. Du kan inkludere i kommentaren en referanse til en billett i et eksternt system for defektsporing eller endringsforespørsel.

Du kan finne ytterligere detaljer om hvordan du setter opp forbindelsen mellom MotioCI og ditt tredjeparts billettsystem i MotioCI Administratorveiledning under Bruk MotioCI med tredjeparts billettsystemer. Et nøkkelord (fikser, lukk) med billettnummeret vil lukke billetten. Eller ved å bruke et nøkkelord som referanser pluss billettnummeret vil skrive innsjekkingskommentaren til billettsystemet og la billetten være åpen.

Bruken av et billettsystem – som Atlassian® JIRA, Microsoft Windows™ Trac eller mange andre – hjelper prosjektledelsen ved å spore spesifikke oppgaver, problemer og deres løsning. Billetter gir et middel for kommunikasjon mellom forfattere eller rapportutviklere og sluttbrukere, testteamet og andre interessenter. Et billettsystem gir også en metode for å spore defekter og sikre at de blir adressert før en rapport fremmes til produksjon.

Typisk arbeidsflyt for rapportutvikling

For å være tydelig, integrering av MotioCI med et billettsystem er ikke den eneste måten teamet ditt vil samhandle med billettsystemet på. Vanligvis, som illustrert i det medfølgende arbeidsflytdiagrammet, prosessen med rapportutvikling i et Cognos Analytics-miljø med MotioCI kan være noe sånt som dette:

1. backlog. En ny billett opprettes. En forretningsanalytiker dokumenterer forretningskravene for en ny rapport og legger den direkte inn i billettsystemet ved å opprette en billett. Han legger billetten i backlog tilstand.
2. Utvikling. Backlog-billettene kan prioriteres på en rekke forskjellige måter, men til slutt vil billetten bli tildelt en rapportutvikler og merket med navnet hennes. Tilstanden til billetten kan endres til in_dev. Hun vil lage en ny rapport. Når hun utvikler rapporten i Cognos Analytics, vil hun sjekke inn endringene sine og referere til billetten i innsjekkingskommentaren, som «Opprettet ny rapport; første versjon; lagt til ledetekstside og støttespørsmål, refs #592". Eller, "Lagt til faktaspørring og krysstabell; filtre og formatering, refs #592." (I MotioCI, blir hashtag-nummeret en hyperkobling direkte til billetten.) Hun kan sjekke ut rapporten, gjøre endringer og sjekke den inn igjen med billettreferansen flere ganger over en periode på dager.
3. Utvikling fullført. Etter at rapportutvikleren har fullført rapporten og benktestet den, noterer hun i billetten i billettsystemet at den er klar til å bli testet av QA og endrer tilstand fra kl. in_Dev til klar_for_QA. Denne staten er et flagg for MotioCI Administrator, eller rolle ansvarlig for å fremme Cognos-rapporter, at rapporten er klar til å migrere til QA-miljøet for testing.
4. promotion til QA. Administrator fremmer rapporten og endringer til staten til in_QA. Denne tilstanden lar QA-teamet vite at rapporten er klar til å bli testet.
5. Testing. QA-teamet tester rapporten mot forretningskravene. Rapporten består enten eller stryker på prøvene. Hvis rapporten mislykkes i QA-testing, er billetten merket med i Dev tilstand, returnerer til rapportutvikleren for rettelser.
6. Testingen var vellykket. Hvis rapporten godkjennes, forteller QA-teamet administratoren at den er klar til å fremme til produksjon ved å merke den klar for Prod tilstand.
7. promotion til produksjon. Når rapporten er klar for produksjon, kan endelige godkjenninger innhentes og frigivelse planlegges, kanskje sammen med andre ferdige rapporter. Administratoren fremmer rapporten til Cognos Production-miljøet. Han legger inn billetten Ferdig tilstand som indikerer at utvikling og testing er fullført og den er flyttet til produksjon. Dette stenger billetten.

Ledelse av rapportutviklingsprosessen

Denne billettadministrasjonsprosessen innebærer og utprøvd praksis tilsier at:

• Hver ny rapport bør ha en billett med forretningskravene å utforme rapporten til.
• Hver defekt bør ha en billett for å registrere eventuelle feil eller problemer med en rapport.
• Hver gang en rapport redigeres, vises MotioCI Innsjekkingskommentarer bør inneholde billettnummeret som ble adressert.
• Hver rapport som promoteres fra Dev til QA bør ha en tilknyttet billett som en administrator kan bekrefte at utviklingen er fullført og den er klar til å flyttes til QA-miljøet.
• Hver rapport som promoteres fra QA til produksjon bør ha en billett som har en historikk som viser at utviklingen er fullført, den har bestått QA, den har mottatt alle nødvendige ledelsesgodkjenninger og har blitt promotert.
• Hver rapport i produksjonsmiljøet bør ha en digital papirspor fra unnfangelse til testing til fiksering til oppløsning til godkjenning og promotion.

Dette siste punktet er en favoritt blant revisorer å validere. Hun kan spørre: "kan du vise meg hvordan du bekrefter at alle rapporter i produksjonsmiljøet har fulgt den dokumenterte prosessen med billettsalg og godkjenning?" En måte å svare revisor på kan være å gi en liste over alle rapportene som har blitt migrert og få henne til å gå gjennom billettene for å se etter en som ikke samsvarer med prosessen din.

Alternativt, og mer ideelt, kan du gi en liste over rapporter som gjør det ikke følge utviklings- og billettprosessen som du har definert. Det er der denne rapporten vil være nyttig: "Rapporter promotert uten billetter". Det er en unntaksrapport for en liste over rapporter som har ikke fulgt de beste fremgangsmåtene for å ha hver rapportendring knyttet til en billett. Dette er en av de få rapportene du ønsker skal være tomme. Det vil ikke ha noen poster hvis alle rapporter som har blitt promotert har en billett knyttet til seg. Med andre ord vil en rapport kun vises på listen hvis den er i produksjonsmiljøet og rapporten som ble promotert ikke refererte til et billettnummer i kommentaren.

Prosess med fordeler

Hva er fordelene med prosessen, eller hvorfor bør du gjøre dette i din organisasjon?

• Forbedret teamsamarbeid: Billettsystemet kan faktisk samle personer i roller som kanskje ikke normalt kommuniserer. Rapportforfattere og sluttbrukere, eller prosjektleder og QA-teamet, for eksempel. Billettstien gir et felles sted å kommunisere om en delt ressurs, rapporten under utvikling.
• Reduserte kostnader:
  • Defekter som fanges opp og fikses tidligere, er mye rimeligere enn om de slipper ut i produksjonen.
  • Forbedret effektivitet – rapportforfattere jobber alltid fra en billett som er en veldefinert arbeidsoppgave.
  • Redusert tid gjennom automatisering av manuelle prosesser
• Forbedret dokumentasjon: Denne prosessen blir en selvdokumenterende kunnskapsbase om defekter og hvordan de ble løst.
• Forbedret prognoser og analyser: Du kan nå spore nøkkelytelsesindikatorer og sammenligne dem med servicenivåavtaler. De fleste billettsystemer gir denne typen analyser.
• Forbedret intern støtte: Supportteamet ditt, andre rapportutviklere (og til og med ditt fremtidige jeg!) kan se opp hvordan lignende defekter ble løst tidligere. Denne delte kunnskapsbasen kan føre til rask løsning av feil.
• Forbedret sluttbrukertilfredshet: Med direkte tilgang til utviklere gjennom billettsystemet, kan brukere forvente rask løsning av defekter samt overvåke fremdriften til en forespurt rapport gjennom systemet.

konklusjonen

Dette er ett eksempel på rike utbetalinger til å følge utprøvd praksis og verdien av å følge veldefinerte prosesser. Videre den nye MotioCI rapport, "Rapporter promotert uten billetter" kan være en stor hjelp til å svare på spørsmål fra en revisor, eller ganske enkelt intern overvåking for etterlevelse av bedriftens standarder.