Cum să profiti la maximum de MotioCI în sprijinirea practicilor dovedite

MotioCI are pluginuri integrate pentru crearea rapoartelor Cognos Analytics. Blocați raportul la care lucrați. Apoi, când ați terminat cu sesiunea de editare, o verificați și includeți un comentariu pentru a înregistra ceea ce ați făcut. Puteți include în comentariu o referință la un bilet într-un sistem extern de urmărire a defectelor sau de solicitare de schimbare.

Puteți găsi detalii suplimentare despre cum să configurați conexiunea între MotioCI și sistemul dvs. de bilete terță parte în MotioCI Ghidul administratorului sub Utilizare MotioCI cu sisteme de bilete de la terți. Un cuvânt cheie (repara, inchide) cu numărul biletului va închide biletul. Sau, folosind un cuvânt cheie precum referințe plus numărul biletului va scrie comentariul de check-in în sistemul de ticketing și va lăsa biletul deschis.

Utilizarea unui sistem de ticketing – cum ar fi Atlassian® JIRA, Microsoft Windows™ Trac sau multe altele – ajută la managementul proiectelor urmărind sarcini specifice, probleme și rezolvarea acestora. Biletele oferă un mijloc de comunicare între autori sau dezvoltatorii de rapoarte și utilizatorii finali, echipa de testare și alte părți interesate. Un sistem de ticketing oferă, de asemenea, o metodă de urmărire a defectelor și de a se asigura că acestea sunt abordate înainte de a promova un raport către producție.

Flux de lucru tipic pentru elaborarea rapoartelor

Pentru a fi clar, integrarea de MotioCI cu un sistem de ticketing nu este singura modalitate prin care echipa ta va interacționa cu sistemul de ticketing. De obicei, așa cum este ilustrat în diagrama fluxului de lucru însoțitor, procesul de dezvoltare a rapoartelor într-un mediu Cognos Analytics cu MotioCI ar putea fi ceva de genul asta:

1. Restante. Este creat un nou bilet. Un analist de afaceri documentează cerințele de afaceri pentru un nou raport și îl introduce direct în sistemul de ticketing prin crearea unui bilet. El pune biletul în restante de stat.
2. Dezvoltare. Biletele de backlog pot fi prioritizate în mai multe moduri diferite, dar în cele din urmă biletul va fi atribuit unui dezvoltator de rapoarte și etichetat cu numele ei. Starea biletului poate fi schimbată în în_dev. Ea va crea un nou raport. Pe măsură ce dezvoltă raportul în Cognos Analytics, va verifica modificările și va face referire la bilet în comentariul de înregistrare, cum ar fi „Creat new report; versiune inițială; a adăugat o pagină promptă și interogări de sprijin, ref #592”. Sau „Adăugat interogare de fapte și tablă încrucișată; filtre și formatare, ref #592.” (În MotioCI, numărul hashtag-ului devine un hyperlink direct către bilet.) Ea poate verifica raportul, face modificări și îl poate verifica din nou cu referința biletului de mai multe ori într-o perioadă de zile.
3. Dezvoltare finalizată. După ce Dezvoltatorul de rapoarte a finalizat raportul și l-a testat, ea notează în biletul din sistemul de ticketing că acesta este gata pentru a fi testat de QA și își schimbă starea de la în_Dev la gata_pentru_QA. Acest stat este un steag pentru MotioCI Administrator sau rol responsabil cu promovarea rapoartelor Cognos, că raportul este pregătit pentru migrare în mediul QA pentru testare.
4. Promotion la QA. Administratorul promovează raportul și schimbă starea la în_QA. Această stare informează echipa QA că raportul este gata pentru a fi testat.
5. Testarea. Echipa QA testează raportul în raport cu cerințele de afaceri. Raportul fie trece sau nu trece testele. Dacă raportul nu reuşeşte testarea QA, biletul este etichetat cu în Dev stare, revenind la dezvoltatorul de rapoarte pentru remedieri.
6. Testare reușită. Dacă raportul trece, echipa QA îi spune administratorului că este gata să promoveze în producție prin etichetarea acestuia gata pentru Prod de stat.
7. Promotion la producție. Odată ce raportul este gata pentru producție, aprobările finale pot fi obținute și pot fi programate lansarea, eventual împreună cu alte rapoarte finalizate. Administratorul promovează raportul în mediul Cognos Production. El pune biletul înăuntru Terminat care indică faptul că dezvoltarea și testarea au fost finalizate și a fost mutată în producție. Acest lucru închide biletul.

Managementul procesului de elaborare a rapoartelor

Acest proces de gestionare a biletelor implică și practicile dovedite impun următoarele:

• Fiecare raport nou ar trebui să aibă un bilet cu cerințele de afaceri pentru a crea raportul.
• Fiecare defect ar trebui să aibă un bilet pentru a înregistra orice erori sau probleme cu un raport.
• De fiecare dată când un raport este editat, MotioCI comentariul de check-in trebuie să includă numărul biletului care a fost adresat.
• Fiecare raport care este promovat de la Dev la QA ar trebui să aibă un tichet asociat pe care un administrator poate confirma că dezvoltarea a fost finalizată și că este gata să fie mutat în mediul QA.
• Fiecare raport care este promovat de la QA la Productie ar trebui să aibă un bilet care are un istoric care arată că dezvoltarea este completă, a trecut QA, a primit toate aprobările necesare de management și a fost promovat.
• Fiecare raport din mediul de producție ar trebui să aibă un digital urma de hârtie de la concepție la testare la reparare la rezoluție la aprobare și promotion.

Acest ultim punct este un favorit al auditorilor pentru validare. Ea ar putea întreba: „Îmi puteți arăta cum confirmați că toate rapoartele din mediul de producție au respectat procesul dumneavoastră documentat de emitere a biletelor și aprobare?” O modalitate de a răspunde auditorului ar putea fi să oferiți o listă cu toate rapoartele care au fost migrate și să o lăsați să treacă prin bilete pentru a căuta unul care nu este conform procesului dvs.

Alternativ, și mai ideal, puteți furniza o listă de rapoarte care fac acest lucru nu să adere la procesul de dezvoltare și de ticketing pe care l-ați definit. Acolo va fi util acest raport: „Rapoarte promovate fără bilete”. Este un raport de excepție a unei liste de rapoarte care au nu a aderat la cele mai bune practici de a avea fiecare modificare a raportului legată de un bilet. Acesta este unul dintre puținele rapoarte pe care doriți să le goliți. Nu va avea înregistrări dacă toate rapoartele care au fost promovate au un bilet asociat. Cu alte cuvinte, un raport va apărea pe listă doar dacă se află în mediul Producție și raportul care a fost promovat nu face referire la un număr de bilet în comentariu.

Proces cu Beneficii

Care sunt beneficiile procesului sau de ce ar trebui să faceți acest lucru în organizația dvs.?

• Colaborare îmbunătățită în echipă: sistemul de ticketing poate reuni de fapt persoane în roluri care nu comunică în mod normal. Autorii rapoartelor și utilizatorii finali, sau managerul de proiect și echipa QA, de exemplu. Traseul biletelor oferă un loc comun pentru a comunica despre o resursă comună, raportul în curs de dezvoltare.
• Costuri reduse:
  • Defectele detectate și remediate mai devreme sunt mult mai puțin costisitoare decât dacă ar fi scăpat în producție.
  • Eficiență îmbunătățită – autorii rapoartelor lucrează întotdeauna dintr-un bilet care este o declarație de lucru bine definită.
  • Timp redus prin automatizarea proceselor manuale
• Documentație îmbunătățită: acest proces devine o bază de cunoștințe auto-documentată a defectelor și a modului în care au fost rezolvate.
• Previziuni și analize îmbunătățite: acum puteți urmări indicatorii cheie de performanță și îi puteți compara cu acordurile privind nivelul de servicii. Majoritatea sistemelor de bilete oferă aceste tipuri de analize.
• Asistență internă îmbunătățită: echipa dvs. de asistență, alți dezvoltatori de rapoarte (și, chiar și viitorul dvs.!) pot căuta modul în care defecte similare au fost abordate în trecut. Această bază de cunoștințe partajată poate duce la rezolvarea rapidă a defectelor.
• Satisfacția îmbunătățită a utilizatorilor finali: Cu acces direct la dezvoltatori prin sistemul de ticketing, utilizatorii se pot aștepta la rezolvarea rapidă a defectelor, precum și să monitorizeze progresul unui raport solicitat prin intermediul sistemului.

Concluzie

Acesta este un exemplu de câștiguri bogate pentru respectarea practicilor dovedite și valoarea urmăririi unor procese bine definite. Mai departe, noul MotioCI raportul „Rapoarte promovate fără bilete” poate fi de mare ajutor în abordarea întrebărilor din partea unui auditor sau pur și simplu monitorizarea internă pentru respectarea standardelor corporative.