Ako čo najlepšie využiť MotioCI pri podpore osvedčených postupov

MotioCI má integrované doplnky na vytváranie zostáv Cognos Analytics. Zamknete prehľad, na ktorom pracujete. Potom, keď skončíte s reláciou úprav, zaregistrujete sa a pridáte komentár, aby ste zaznamenali, čo ste urobili. Do komentára môžete uviesť odkaz na tiket v externom systéme sledovania defektov alebo žiadostí o zmenu.

Môžete nájsť ďalšie podrobnosti o tom, ako nastaviť spojenie medzi MotioCI a váš systém predaja lístkov tretích strán v MotioCI Príručka správcu v časti Používanie MotioCI s predajnými systémami tretích strán. kľúčové slovo (opraví, uzavrieť) s číslom tiketu tiket uzavrie. Alebo pomocou kľúčového slova ako referencie plus číslo tiketu napíše poznámku k check-in do tiketovacieho systému a tiket ponechá otvorený.

Použitie lístkového systému – ako je Atlassian® JIRA, Microsoft Windows™ Trac alebo mnoho ďalších – pomáha pri riadení projektu sledovaním konkrétnych úloh, problémov a ich riešení. Vstupenky poskytujú prostriedok komunikácie medzi autormi alebo vývojármi správ a koncovými používateľmi, testovacím tímom a ďalšími zainteresovanými stranami. Systém vydávania lístkov tiež poskytuje metódu sledovania chýb a zabezpečenia ich riešenia pred propagáciou správy do výroby.

Typický pracovný postup pre vývoj správ

Aby bolo jasné, integrácia MotioCI s lístkovým systémom nie je jediný spôsob, ako bude váš tím interagovať so systémom lístkov. Typicky, ako je znázornené v sprievodnom diagrame pracovného toku, proces vývoja zostavy v prostredí Cognos Analytics s MotioCI môže byť niečo takéto:

1. resty. Vytvorí sa nový tiket. Obchodný analytik zdokumentuje obchodné požiadavky pre novú zostavu a zadá ju priamo do systému lístkov vytvorením lístka. Vloží lístok do resty stav.
2. Rozvoj. Nevybavené lístky môžu byť uprednostňované mnohými rôznymi spôsobmi, ale nakoniec bude lístok priradený vývojárovi zostavy a označený jej menom. Stav lístka je možné zmeniť na in_dev. Vytvorí novú správu. Pri vývoji zostavy v Cognos Analytics skontroluje svoje zmeny a odkáže na lístok v komentári pri registrácii, napríklad „Vytvorený nový prehľad; počiatočná verzia; pridaná promptná stránka a podporné otázky, ref. č. 592“. Alebo: „Pridaný dopyt po faktoch a krížová tabuľka; filtre a formátovanie, ref. č. 592.“ (V MotioCI, číslo hashtagu sa stane hypertextovým odkazom priamo na tiket.) Môže si správu pozrieť, vykonať zmeny a vrátiť ju späť s referenciou tiketu viackrát v priebehu niekoľkých dní.
3. Vývoj ukončený. Keď vývojár zostavy dokončí zostavu a otestuje ju na skúšobnom teste, v lístku v systéme lístkov zaznamená, že je pripravený na testovanie kontrolou kvality a zmení stav z in_Dev na ready_for_QA. Tento štát je vlajkou pre MotioCI Administrátor alebo rola zodpovedná za propagáciu správ Cognos, že zostava je pripravená na migráciu do prostredia QA na testovanie.
4. zamotion na QA. Správca povýši prehľad a zmeny stavu na in_QA. Tento stav dáva tímu QA vedieť, že správa je pripravená na testovanie.
5. Testovanie. Tím QA testuje správu podľa obchodných požiadaviek. Správa buď v testoch prejde alebo neprejde. Ak zostava zlyhá pri testovaní kvality, lístok bude označený značkou v Dev stave, vráťte sa vývojárovi zostavy na opravu.
6. Testovanie bolo úspešné. Ak správa prejde, tím kontroly kvality oznámi správcovi, že je pripravený povýšiť ju do produkcie označením pripravený na Prod stav.
7. zamotion do výroby. Keď je zostava pripravená na produkciu, možno získať konečné schválenia a naplánovať vydanie, možno v spojení s inými dokončenými zostavami. Administrátor povýši zostavu do prostredia Cognos Production. Vloží lístok hotový uvádza, že vývoj a testovanie je ukončené a že bol presunutý do výroby. Tým sa lístok uzavrie.

Riadenie procesu tvorby správy

Tento proces správy lístkov predpokladá a osvedčené postupy diktujú, že:

• Každá nová správa by mala mať lístok s obchodnými požiadavkami, pre ktoré sa má zostava navrhnúť.
• Každá chyba by mala mať lístok na zaznamenanie akýchkoľvek chýb alebo problémov s hlásením.
• Zakaždým, keď je zostava upravená, MotioCI poznámka pri registrácii by mala obsahovať číslo lístka, ktorý bol adresovaný.
• Každá správa, ktorá je povýšená z Dev na QA, by mala mať priradený lístok, ktorý môže správca potvrdiť, že vývoj bol dokončený a je pripravený na presun do prostredia QA.
• Každá správa, ktorá je povýšená z QA na produkciu, by mala mať lístok s históriou, ktorá ukazuje, že vývoj je dokončený, prešiel QA, získal všetky požadované schválenia manažmentu a bol povýšený.
• Každá zostava v produkčnom prostredí by mala mať a digital papierová cesta od koncepcie cez testovanie až po upevnenie až po vyriešenie až po schválenie a profesionálovmotion.

Tento posledný bod je obľúbený u audítorov na overenie. Mohla by sa spýtať: „Môžete mi ukázať, ako potvrdzujete, že všetky zostavy v produkčnom prostredí dodržali váš zdokumentovaný proces vydávania lístkov a schvaľovania?“ Jedným zo spôsobov, ako odpovedať audítorovi, môže byť poskytnúť zoznam všetkých správ, ktoré boli migrované, a nechať ju prehrabať sa lístkami, aby hľadala tú, ktorá nie je v súlade s vaším procesom.

Alternatívne, a čo je ešte lepšie, môžete poskytnúť zoznam prehľadov, ktoré to robia nie dodržujte proces vývoja a predaja lístkov, ktorý ste definovali. Tu bude táto správa užitočná: “Správy propagované bez vstupeniek“. Ide o hlásenie výnimky zo zoznamu hlásení, ktoré majú nie dodržiavali osvedčené postupy, podľa ktorých je každá zmena hlásenia viazaná na tiket. Toto je jeden z mála prehľadov, ktoré chcete mať prázdne. Nebude mať žiadne záznamy, ak všetky správy, ktoré boli povýšené, majú priradený tiket. Inými slovami, zostava sa v zozname objaví iba vtedy, ak sa nachádza v produkčnom prostredí a správa, ktorá bola povýšená, v komentári neodkazuje na číslo tiketu.

Proces s výhodami

Aké sú výhody tohto procesu alebo prečo by ste to mali robiť vo vašej organizácii?

• Vylepšená tímová spolupráca: Systém predaja lístkov môže v skutočnosti spájať jednotlivcov v rolách, ktorí bežne nekomunikujú. Napríklad autori správ a koncoví používatelia alebo projektový manažér a tím QA. Záznamová stopa poskytuje spoločné miesto na komunikáciu o zdieľanom zdroji, zostave vo vývoji.
• Znížené náklady:
  • Poruchy zachytené a opravené skôr sú oveľa lacnejšie, ako keby unikli do výroby.
  • Vylepšená efektivita – autori správ vždy pracujú z lístka, ktorý je dobre definovaným výkazom práce.
  • Skrátený čas vďaka automatizácii manuálnych procesov
• Vylepšená dokumentácia: Tento proces sa stáva samodokumentujúcou vedomostnou základňou defektov a toho, ako boli vyriešené.
• Vylepšené prognózy a analýzy: Teraz môžete sledovať kľúčové ukazovatele výkonnosti a porovnávať ich so zmluvami o úrovni služieb. Väčšina systémov predaja lístkov poskytuje tieto typy analýz.
• Vylepšená interná podpora: Váš tím podpory, ďalší vývojári zostáv (a dokonca aj váš budúci ja!) môžu vyhľadať, ako sa podobné chyby riešili v minulosti. Táto zdieľaná vedomostná základňa môže viesť k rýchlemu riešeniu defektov.
• Vylepšená spokojnosť koncových používateľov: Vďaka priamemu prístupu k vývojárom prostredníctvom systému lístkov môžu používatelia očakávať rýchle vyriešenie chýb, ako aj sledovať priebeh požadovanej správy prostredníctvom systému.

záver

Toto je jeden z príkladov bohatých výnosov pri dodržiavaní osvedčených postupov a hodnoty dodržiavania dobre definovaných procesov. Ďalej, nové MotioCI správa „Správy propagované bez vstupeniek“ môžu byť obrovskou pomocou pri riešení otázok audítora alebo jednoducho interným monitorovaním dodržiavania podnikových štandardov.