Kako maksimalno iskoristiti MotioCI u podršci dokazanim praksama

MotioCI ima integrirane dodatke za izradu izvještaja Cognos Analytics. Zaključavate izvještaj na kojem radite. Zatim, kada završite sa sesijom uređivanja, provjerite je i uključite komentar kako biste snimili ono što ste radili. U komentar možete uključiti referencu na tiket u eksternom sistemu za praćenje grešaka ili zahtjev za promjenom.

Možete pronaći dodatne detalje o tome kako postaviti vezu između MotioCI i vaš sistem za prodaju karata treće strane u MotioCI Administratorski vodič pod Korištenje MotioCI sa sistemima za prodaju karata trećih strana. Ključna riječ (popravke, zatvori) sa brojem karte će zatvoriti kartu. Ili, koristeći ključnu riječ poput reference plus broj karte će napisati komentar za prijavu u sistem za prodaju karata i ostaviti kartu otvorenu.

Upotreba sistema za prodaju ulaznica – poput Atlassian® JIRA, Microsoft Windows™ Trac ili mnogih drugih – pomaže u upravljanju projektima praćenjem specifičnih zadataka, problema i njihovog rješavanja. Karte pružaju sredstvo komunikacije između autora ili programera izvještaja i krajnjih korisnika, tima za testiranje i drugih dionika. Sistem tiketinga takođe obezbeđuje metod praćenja nedostataka i osigurava da se oni adresiraju pre nego što se izveštaj promoviše u produkciju.

Tipičan tok rada za razvoj izvještaja

Da budemo jasni, integracija MotioCI sa sistemom za prodaju karata nije jedini način na koji će vaš tim komunicirati sa sistemom za prodaju karata. Obično, kao što je ilustrovano u pratećem dijagramu toka posla, proces razvoja izvještaja u okruženju Cognos Analytics sa MotioCI može biti nešto ovako:

1. Backlog. Nova karta je kreirana. Poslovni analitičar dokumentira poslovne zahtjeve za novi izvještaj i unosi ga direktno u tiketing sistem kreiranjem tiketa. Stavlja kartu u zaostatak stanje.
2. razvoj. Zaostali tiketi mogu se dati prioritet na više različitih načina, ali na kraju će tiket biti dodijeljen programeru izvještaja i označen njenim imenom. Stanje karte se može promijeniti u in_dev. Ona će napraviti novi izvještaj. Dok bude razvijala izvještaj u Cognos Analyticsu, ona će provjeriti svoje izmjene i referencirati kartu u komentaru za prijavu, poput „Kreiran novi izvještaj; početna verzija; dodana stranica sa brzim upitom i prateći upiti, refs #592”. Ili, „Dodan upit činjenica i unakrsna tablica; filteri i formatiranje, refs #592.” (U MotioCI, hashtag broj postaje hiperveza direktno na kartu.) Ona može provjeriti izvještaj, unijeti izmjene i ponovo ga provjeriti s referencom karte više puta tokom perioda dana.
3. Razvoj završen. Nakon što je programer izvještaja završio izvještaj i testirao ga na klupi, ona bilježi u tiketu u sistemu tiketinga da je spreman za testiranje od strane QA i mijenja stanje od in_Dev to spreman_za_QA. Ova država je zastava za MotioCI Administrator, ili uloga odgovorna za promoviranje Cognos izvještaja, da je izvještaj spreman za migraciju u QA okruženje radi testiranja.
4. zamotion u QA. Administrator promoviše izvještaj i promjene stanja u in_QA. Ovo stanje daje do znanja QA timu da je izvještaj spreman za testiranje.
5. Testiranje. QA tim testira izvještaj u odnosu na poslovne zahtjeve. Izvještaj ili prolazi ili ne prolazi testove. Ako izvještaj ne prođe QA testiranje, ulaznica je označena sa u Dev stanje, vraćanje programeru izvještaja radi popravki.
6. Testiranje uspješno. Ako izvještaj prođe, QA tim govori administratoru da je spreman za promociju u produkciju označavajući ga spreman za Prod stanje.
7. zamotion do proizvodnje. Kada izvještaj bude spreman za proizvodnju, mogu se dobiti konačna odobrenja i zakazano objavljivanje, možda u paketu s drugim završenim izvještajima. Administrator promovira izvještaj u Cognos Production okruženje. Stavlja kartu Gotovo stanje koje označava da su razvoj i testiranje završeni i da je prebačen u proizvodnju. Ovo zatvara kartu.

Upravljanje procesom izrade izvještaja

Ovaj proces upravljanja ulaznicama podrazumijeva i dokazane prakse nalažu sljedeće:

• Svaki novi izvještaj bi trebao imati ulaznicu s poslovnim zahtjevima za izradu izvještaja.
• Svaki kvar treba da ima kartu za evidentiranje grešaka ili problema sa izvještajem.
• Svaki put kada se uređuje izvještaj, MotioCI komentar o prijavi treba da sadrži broj karte koja je adresirana.
• Svaki izvještaj koji se promovira iz Dev-a u QA trebao bi imati pridruženu kartu za koju administrator može potvrditi da je razvoj završen i da je spreman za premještanje u QA okruženje.
• Svaki izveštaj koji se promoviše iz QA u produkciju treba da ima ulaznicu koja ima istoriju koja pokazuje da je razvoj završen, da je prošao QA, da je dobio sva potrebna odobrenja menadžmenta i da je unapređen.
• Svaki izvještaj u proizvodnom okruženju treba da ima a digital papirni trag od koncepcije do testiranja do fiksiranja do rezolucije do odobrenja i promotion.

Ova posljednja tačka je omiljena kod revizora za potvrđivanje. Mogla bi pitati: „Možete li mi pokazati kako potvrđujete da su svi izvještaji u proizvodnom okruženju usklađeni s vašim dokumentiranim procesom izdavanja ulaznica i odobrenja?“ Jedan od načina da odgovorite revizoru mogao bi biti da pružite listu svih izvještaja koji su migrirani i da ga navedete da prođe kroz karte kako bi potražila onaj koji nije u skladu s vašim procesom.

Alternativno, i još bolje, možete dati listu izvještaja koji to rade ne pridržavajte se procesa razvoja i izdavanja ulaznica koji ste definirali. Tu će ovaj izvještaj biti koristan: “Izvještaji promovirani bez ulaznica”. To je izvještaj o izuzetku od liste izvještaja koji imaju ne pridržavao se najbolje prakse da se svaka promjena izvještaja veže za kartu. Ovo je jedan od rijetkih izvještaja za koje želite da budu prazni. Neće imati evidenciju ako svi izvještaji koji su promovirani imaju tiket povezan s njim. Drugim riječima, izvještaj će se pojaviti na listi samo ako je u Produkcijskom okruženju, a izvještaj koji je promoviran nije naveo broj ulaznice u komentaru.

Proces s pogodnostima

Koje su prednosti procesa ili zašto biste to trebali raditi u svojoj organizaciji?

• Poboljšana timska saradnja: Sistem izdavanja ulaznica zapravo može okupiti pojedince u ulogama koji inače ne komuniciraju. Autori izvještaja i krajnji korisnici, ili projekt menadžer i QA tim, na primjer. Trag ulaznica pruža zajedničko mjesto za komunikaciju o zajedničkom resursu, izvještaju u izradi.
• Smanjeni troškovi:
  • Nedostaci koji se prije otkriju i otklone su mnogo jeftiniji nego ako pobjegnu u proizvodnju.
  • Poboljšana efikasnost – autori izveštaja uvek rade sa tiketa koji je dobro definisana izjava o radu.
  • Smanjeno vrijeme kroz automatizaciju ručnih procesa
• Poboljšana dokumentacija: Ovaj proces postaje samodokumentirajuća baza znanja o nedostacima i načinu na koji su oni riješeni.
• Poboljšano predviđanje i analitika: Sada možete pratiti ključne pokazatelje učinka i upoređivati ​​ih sa ugovorima o nivou usluge. Većina sistema za prodaju karata pruža ove vrste analitike.
• Poboljšana interna podrška: Vaš tim za podršku, drugi programeri izvještaja (pa čak i vi sami budući!) mogu pogledati kako su slični nedostaci rješavani u prošlosti. Ova zajednička baza znanja može dovesti do brzog rješavanja nedostataka.
• Poboljšano zadovoljstvo krajnjih korisnika: Uz direktan pristup programerima putem sistema za prodaju tiketa, korisnici mogu očekivati ​​brzo rješavanje nedostataka, kao i praćenje napretka traženog izvještaja kroz sistem.

zaključak

Ovo je jedan primjer bogate isplate praćenja dokazane prakse i vrijednosti praćenja dobro definiranih procesa. Dalje, novi MotioCI izvještaj, “Izvještaji promovirani bez ulaznica” mogu biti od velike pomoći u rješavanju pitanja revizora, ili jednostavno interno praćenje pridržavanja korporativnih standarda.