Kiel profiti MotioCI en subteno de pruvitaj praktikoj

MotioCI havas integritajn kromaĵojn por verkado de raportoj de Cognos Analytics. Vi ŝlosas la raporton pri kiu vi laboras. Poste, kiam vi finis vian redaktan sesion, vi kontrolas ĝin kaj inkluzivas komenton por registri tion, kion vi faris. Vi povas enmeti en la komenton referencon al bileto en ekstera difekto-spurado aŭ ŝanĝ-peta sistemo.

Vi povas trovi pliajn detalojn pri kiel agordi la rilaton inter MotioCI kaj via triaparta biletsistemo en la MotioCI Gvidilo de Administranto sub Uzado MotioCI kun triapartaj biletaj sistemoj. Ŝlosilvorto (fiksas, fermi) kun la bileta numero fermos la bileton. Aŭ, uzante ŝlosilvorton kiel referencoj plus la bileta numero skribos la enregistran komenton al la biletsistemo kaj lasos la bileton malfermita.

La uzo de biletsistemo - kiel Atlassian® JIRA, Microsoft Windows™ Trac, aŭ multaj aliaj - helpas projekt-administradon spurante specifajn taskojn, problemojn kaj ilian solvon. Biletoj disponigas komunikilon inter aŭtoroj aŭ raportprogramistoj kaj finuzantoj, la testa teamo kaj aliaj koncernatoj. Biletadosistemo ankaŭ disponigas metodon por spuri difektojn kaj certigi ke ili estas traktitaj antaŭ reklamado de raporto al produktado.

Tipa Laborfluo por Raporta Disvolviĝo

Por esti klara, la integriĝo de MotioCI kun biletsistemo ne estas la sola maniero, ke via teamo interagos kun la biletsistemo. Tipe, kiel ilustrite en la akompana laborfludiagramo, la procezo de evoluigo de raportoj en medio de Cognos Analytics kun MotioCI povus esti io kiel ĉi tio:

1. Backlog. Nova bileto estas kreita. Komerca Analizisto dokumentas la komercajn postulojn por nova raporto kaj enmetas ĝin rekte en la biletsistemon kreante bileton. Li metas la bileton en la backlog ŝtato.
2. disvolviĝo. La restaraj biletoj povas esti prioritatitaj en kelkaj malsamaj manieroj, sed finfine la bileto estos asignita al raportisto kaj etikedita kun ŝia nomo. La stato de la bileto povas esti ŝanĝita al en_dev. Ŝi kreos novan raporton. Dum ŝi disvolvos la raporton en Cognos Analytics, ŝi kontrolos siajn ŝanĝojn kaj referencos la bileton en la enregistra komento, kiel "Kreita nova raporto; komenca versio; aldonis promptan paĝon kaj subtenajn demandojn, ref #592”. Aŭ, "Aldonita fakta demando kaj kructabelo; filtriloj kaj formatado, ref #592.” (En MotioCI, la hashtag-numero fariĝas hiperligo rekte al la bileto.) Ŝi povas kontroli la raporton, fari ŝanĝojn kaj rekontroli ĝin kun la biletreferenco plurfoje dum daŭro de tagoj.
3. Disvolviĝo finiĝis. Post kiam la Raportisto-Programisto kompletigis la raporton kaj la benko testis ĝin, ŝi notas en la bileto en la biletsistemo, ke ĝi estas preta esti provita de QA kaj ŝanĝas staton de en_Dev al preta_por_QA. Ĉi tiu ŝtato estas flago por la MotioCI Administranto, aŭ rolo respondeca por reklamado de raportoj de Cognos, ke la raporto estas preta migri al la QA-medio por testado.
4. pomotion al QA. La administranto promocias la raporton kaj ŝanĝas al la ŝtato al en_QA. Ĉi tiu ŝtato sciigas al la QA-teamo, ke la raporto estas preta por esti provita.
5. Testado. La QA-teamo testas la raporton kontraŭ la komercaj postuloj. La raporto aŭ trapasas aŭ malsukcesas la testojn. Se la raporto malsukcesas QA-testadon, la bileto estas etikedita kun la en Dev stato, revenante al la raportisto por korektoj.
6. Testado sukcesa. Se la raporto pasas, la QA-teamo diras al la administranto, ke ĝi estas preta antaŭenigi al produktado per etikedado de ĝi preta por Prod ŝtato.
7. pomotion al Produktado. Post kiam la raporto estas preta por produktado, finaj aproboj povas esti akiritaj kaj liberigo planita, eble kunigante kun aliaj finitaj raportoj. La administranto reklamas la raporton al la medio de Cognos Production. Li metas la bileton farita ŝtato indikante ke evoluo kaj testado estas finitaj kaj ĝi estis movita al produktado. Ĉi tio fermas la bileton.

Administrado de la Raporta Disvolva Procezo

Ĉi tiu biletadministradprocezo implicas kaj pruvitaj praktikoj diktas tion:

• Ĉiu nova raporto devus havi bileton kun la komercaj postuloj por desegni la raporton.
• Ĉiu difekto devus havi bileton por registri ajnajn cimojn aŭ problemojn kun raporto.
• Ĉiufoje kiam raporto estas redaktita, la MotioCI enregistra komento devus inkluzivi la biletan numeron kiu estis traktita.
• Ĉiu raporto, kiu estas antaŭenigita de Dev al QA, devus havi rilatan bileton, kiun administranto povas konfirmi, ke evoluo finiĝis kaj ĝi estas preta por esti movita al la QA-medio.
• Ĉiu raporto kiu estas antaŭenigita de QA al Produktado devus havi bileton kiu havas historion montrante ke evoluo estas kompleta, ĝi pasis QA, ĝi ricevis ĉiujn postulatajn administrajn aprobojn kaj estis antaŭenigita.
• Ĉiu raporto en la Produktada medio devus havi a digital papera spuro de koncepto ĝis testado ĝis fiksado ĝis rezolucio ĝis aprobo kaj profesiulomotion.

Ĉi tiu lasta punkto estas plej ŝatata de revizoroj por validigi. Ŝi povus demandi, "ĉu vi povas montri al mi kiel vi konfirmas, ke ĉiuj raportoj en la Produktadmedio aliĝis al via dokumentita procezo de bileto kaj aprobo?" Unu maniero respondi al la revizoro povus esti provizi liston de ĉiuj raportoj, kiuj estis migritaj, kaj ke ŝi trairu la biletojn por serĉi unu, kiu ne konformas al via procezo.

Alternative, kaj pli ideale, vi povas provizi liston de raportoj kiuj faras ne aliĝu al la procezo de disvolviĝo kaj bileto, kiun vi difinis. Tie ĉi tiu raporto estos utila: “Raportoj Promociitaj sen Biletoj”. Ĝi estas escepta raporto de listo de raportoj kiuj havas ne aliĝis al la plej bonaj praktikoj havi ĉiun raportan ŝanĝon ligita al bileto. Ĉi tiu estas unu el la malmultaj raportoj, kiujn vi volas esti malplena. Ĝi ne havos rekordojn se ĉiuj raportoj kiuj estis reklamitaj havas bileton asociita kun ĝi. Alivorte, raporto nur aperos en la listo se ĝi estas en la Produktada medio kaj la raporto, kiu estis reklamita, ne referencis biletan numeron en la komento.

Procezo kun Profitoj

Kio estas la avantaĝoj de la procezo, aŭ kial vi faru ĉi tion en via organizo?

• Plibonigita teamkunlaboro: La biletsistemo povas fakte kunigi individuojn en roloj kiuj eble ne normale komunikas. Raportaŭtoroj kaj finuzantoj, aŭ projektestro kaj la QA-teamo, ekzemple. La biletvojo disponigas oftan lokon por komuniki pri komuna rimedo, la raporto evoluanta.
• Reduktitaj kostoj:
  • Difektoj kaptitaj kaj riparitaj pli frue estas multe malpli multekostaj ol se ili eskapas en produktadon.
  • Plibonigita efikeco - raportaŭtoroj ĉiam laboras de bileto kiu estas bone difinita deklaro de laboro.
  • Reduktita tempo per aŭtomatigo de manaj procezoj
• Plibonigita dokumentaro: Ĉi tiu procezo fariĝas memdokumenta scio de difektoj kaj kiel ili estis solvitaj.
• Plibonigita prognozo kaj analizo: Vi nun povas spuri ŝlosilajn rendimentajn indikilojn kaj kompari ilin kun servonivelaj interkonsentoj. Plej multaj biletaj sistemoj disponigas ĉi tiujn specojn de analizoj.
• Plibonigita interna subteno: Via subtena teamo, aliaj raportaj programistoj (kaj, eĉ, via estonta memo!) povas serĉi kiel similaj difektoj estis traktitaj en la pasinteco. Ĉi tiu komuna sciobazo povas konduki al rapida rezolucio de difektoj.
• Plibonigita kontento de finuzantoj: Kun rekta aliro al programistoj per la biletsistemo, uzantoj povas atendi rapidan solvon de difektoj kaj ankaŭ kontroli la progreson de petita raporto per la sistemo.

konkludo

Ĉi tio estas unu ekzemplo de riĉaj kompensoj por sekvado de provitaj praktikoj kaj la valoro de sekvado de bone difinitaj procezoj. Plue, la nova MotioCI raporto, "Raportoj Antaŭenigitaj sen Biletoj" povas esti grandega helpo por trakti demandojn de revizoro, aŭ simple interna monitorado por aliĝo al kompaniaj normoj.