Как да се възползваме максимално MotioCI в подкрепа на доказани практики

MotioCI има интегрирани добавки за създаване на отчети на Cognos Analytics. Заключвате отчета, върху който работите. След това, когато приключите със сесията си за редактиране, я отбелязвате и включвате коментар, за да запишете какво сте направили. Можете да включите в коментара препратка към билет във външна система за проследяване на дефекти или заявка за промяна.

Можете да намерите допълнителни подробности за това как да настроите връзката между MotioCI и вашата система за билети на трета страна в MotioCI Ръководство на администратора под Използване MotioCI със системи за билети на трети страни. ключова дума (поправки, затвори) с номера на билета ще затвори билета. Или с помощта на ключова дума като препратки плюс номерът на билета ще напише коментара за регистрация в системата за билети и ще остави билета отворен.

Използването на система за билети – като Atlassian® JIRA, Microsoft Windows™ Trac или много други – подпомага управлението на проекти чрез проследяване на конкретни задачи, проблеми и тяхното разрешаване. Билетите предоставят средство за комуникация между авторите или разработчиците на отчети и крайните потребители, екипа за тестване и други заинтересовани страни. Системата за билети също така предоставя метод за проследяване на дефекти и гарантиране, че те са адресирани, преди да популяризирате отчета в производството.

Типичен работен процес за разработване на отчет

За да бъде ясно, интеграцията на MotioCI със система за билети не е единственият начин, по който вашият екип ще взаимодейства със системата за билети. Обикновено, както е илюстрирано в придружаващата диаграма на работния процес, процесът на разработване на отчет в среда на Cognos Analytics с MotioCI може да е нещо подобно:

1. запас. Създава се нов билет. Бизнес анализаторът документира бизнес изискванията за нов отчет и го въвежда директно в системата за билети чрез създаване на билет. Той поставя билета в запас състояние.
2. Развитие. Заявките за неизпълнени задачи могат да бъдат приоритизирани по няколко различни начина, но в крайна сметка заявката ще бъде присвоена на разработчик на отчети и маркиран с нейното име. Състоянието на билета може да бъде променено на in_dev. Тя ще създаде нов отчет. Докато разработва отчета в Cognos Analytics, тя ще провери промените си и ще посочи билета в коментара за регистрация, като „Създаден нов отчет; първоначална версия; добавена страница за подкани и поддържащи заявки, справки #592”. Или „Добавени фактическа заявка и кръстосана таблица; филтри и форматиране, реф. #592.” (Във MotioCI, номерът на хаштага се превръща в хипервръзка директно към билета.) Тя може да провери отчета, да направи промени и да го провери отново с препратката към билета няколко пъти за период от дни.
3. Разработката е завършена. След като разработчикът на отчети е завършил доклада и го е тествал в стенд, тя отбелязва в билета в системата за билети, че е готов да бъде тестван от QA и променя състоянието от in_Dev да се готов_за_QA. Тази държава е знаме за MotioCI Администратор или роля, отговорна за популяризирането на отчетите на Cognos, че отчетът е готов за мигриране към QA средата за тестване.
4. професионалистmotion към QA. Администраторът популяризира отчета и промените в състоянието на in_QA. Това състояние позволява на екипа за контрол на качеството да разбере, че отчетът е готов за тестване.
5. Тестване. QA екипът тества отчета спрямо бизнес изискванията. Докладът или преминава или не преминава тестовете. Ако отчетът не премине QA тестване, билетът се маркира с в Dev състояние, връщайки се към разработчика на отчета за корекции.
6. Тестването успешно. Ако отчетът е приет, екипът за осигуряване на качеството казва на администратора, че е готов да премине към производство, като го етикетира готов за произв състояние.
7. професионалистmotion към Производство. След като докладът е готов за производство, могат да бъдат получени окончателни одобрения и планирано пускане, може би в комплект с други завършени доклади. Администраторът насърчава отчета в средата на Cognos Production. Той поставя билета вътре Направен състояние, което показва, че разработката и тестването са завършени и е преместен в производство. Това затваря билета.

Управление на процеса на разработване на отчет

Този процес на управление на билети предполага и доказаните практики диктуват, че:

• Всеки нов отчет трябва да има билет с бизнес изискванията за проектиране на отчета.
• Всеки дефект трябва да има билет за записване на грешки или проблеми с доклад.
• Всеки път, когато се редактира отчет, MotioCI коментарът за регистрация трябва да включва номера на билета, който е адресиран.
• Всеки отчет, който е повишен от Dev към QA, трябва да има свързан билет, който администраторът може да потвърди, че разработката е завършена и е готов да бъде преместен в QA средата.
• Всеки отчет, който е повишен от QA до Production, трябва да има билет, който има история, показваща, че разработката е завършена, преминал е QA, получил е всички необходими одобрения от ръководството и е бил повишен.
• Всеки отчет в производствената среда трябва да има a digital хартиен път от концепцията до тестването до фиксирането до разрешаването до одобрението и професионалиститеmotion.

Тази последна точка е любима за валидиране на одиторите. Тя може да попита: „Можете ли да ми покажете как потвърждавате, че всички отчети в производствената среда са се придържали към вашия документиран процес на билети и одобрение?“ Един от начините да отговорите на одитора може да бъде да предоставите списък на всички отчети, които са мигрирани, и да я накарате да прегледа билетите, за да потърси такъв, който не отговаря на вашия процес.

Като алтернатива и в по-идеалния случай можете да предоставите списък с отчети, които го правят не се придържайте към процеса на разработка и билети, който сте дефинирали. Тук този доклад ще бъде полезен: “Доклади, популяризирани без билети”. Това е доклад за изключение от списък с отчети, които имат не се придържа към най-добрите практики за обвързване на всяка промяна в отчета с билет. Това е един от малкото отчети, които искате да бъдат празни. Няма да има записи, ако всички отчети, които са били повишени, имат билет, свързан с него. С други думи, отчетът ще се появи в списъка само ако е в производствената среда и докладът, който е бил повишен, не е посочил номер на билет в коментара.

Процес с ползи

Какви са ползите от процеса или защо трябва да направите това във вашата организация?

• Подобрено екипно сътрудничество: Системата за издаване на билети може действително да обедини лица в роли, които обикновено не комуникират. Например автори на доклади и крайни потребители или ръководител на проекта и QA екип. Пътеката на билетите предоставя общо място за комуникация относно споделен ресурс, докладът в процес на разработка.
• Намалени разходи:
  • Дефектите, уловени и отстранени по-рано, са много по-евтини, отколкото ако избягат в производството.
  • Подобрена ефективност – авторите на отчети винаги работят от тикет, който е добре дефиниран отчет за работа.
  • Намалено време чрез автоматизиране на ръчни процеси
• Подобрена документация: Този процес се превръща в самодокументираща се база от знания за дефекти и как са били разрешени.
• Подобрено прогнозиране и анализи: Вече можете да проследявате ключови показатели за ефективност и да ги сравнявате със споразумения за ниво на обслужване. Повечето системи за билети предоставят тези видове анализи.
• Подобрена вътрешна поддръжка: Вашият екип за поддръжка, други разработчици на отчети (и дори бъдещият ви аз!) могат да видят как подобни дефекти са били адресирани в миналото. Тази споделена база от знания може да доведе до бързо разрешаване на дефекти.
• Подобрено удовлетворение на крайния потребител: С директен достъп до разработчиците чрез системата за тикетиране, потребителите могат да очакват бързо разрешаване на дефекти, както и да наблюдават напредъка на заявения отчет чрез системата.

Заключение

Това е един пример за богати печалби от следване на доказани практики и стойността на следването на добре дефинирани процеси. Освен това, новото MotioCI доклад, „Доклади, популяризирани без билети“ може да бъде огромна помощ при разглеждане на въпроси от одитор или просто вътрешно наблюдение за спазване на корпоративните стандарти.