Як максимально використати MotioCI у підтримці перевірених практик

MotioCI має інтегровані плагіни для створення звітів Cognos Analytics. Ви блокуєте звіт, над яким працюєте. Потім, коли ви закінчите сеанс редагування, ви перевіряєте його та додаєте коментар, щоб записати те, що ви зробили. Ви можете включити в коментарі посилання на заявку в зовнішній системі відстеження дефектів або запиту на зміни.

Ви можете знайти додаткові відомості про те, як налаштувати з’єднання між MotioCI і вашу систему продажу квитків третьої сторони в MotioCI Посібник адміністратора в розділі Використання MotioCI зі сторонніми системами продажу квитків. Ключове слово (виправляє, закриває) із номером квитка закриє квиток. Або за допомогою ключового слова like посилання плюс номер квитка запише коментар про реєстрацію до системи продажу квитків і залишить квиток відкритим.

Використання системи продажу квитків, наприклад Atlassian® JIRA, Microsoft Windows™ Trac або багатьох інших, допомагає керувати проектами, відстежуючи конкретні завдання, проблеми та їх вирішення. Квитки забезпечують зв’язок між авторами або розробниками звітів і кінцевими користувачами, командою тестування та іншими зацікавленими сторонами. Система квитків також надає метод відстеження дефектів і забезпечення їх усунення до того, як звіт буде реалізовано.

Типовий робочий процес для розробки звіту

Щоб було зрозуміло, інтеграція MotioCI із системою продажу квитків — це не єдиний спосіб взаємодії вашої команди з системою продажу квитків. Як правило, як показано на супровідній схемі робочого процесу, процес розробки звіту в середовищі Cognos Analytics з MotioCI може бути щось на зразок цього:

1. Відставання. Створюється новий квиток. Бізнес-аналітик документує бізнес-вимоги до нового звіту та вводить їх безпосередньо в систему продажу квитків, створюючи заявку. Він кладе квиток у відставання стан.
2. розробка. Пріоритетність запитів із залишеними документами можна визначити кількома різними способами, але зрештою заявку буде призначено розробнику звіту та позначено її іменем. Стан квитка можна змінити на in_dev. Вона створить новий звіт. Під час розробки звіту в Cognos Analytics вона перевірятиме свої зміни та посилатиметься на заявку в коментарі до реєстрації, наприклад «Створено новий звіт; початкова версія; додано сторінку підказок і допоміжні запити, посилання №592». Або: «Додано запит фактів і перехресну таблицю; фільтри та форматування, посилання №592.” (В MotioCI, номер хештегу стає гіперпосиланням безпосередньо на заявку.) Вона може перевірити звіт, внести зміни та перевірити його знову з посиланням на заявку кілька разів протягом кількох днів.
3. Розробку завершено. Після того, як розробник звіту завершить створення звіту та перевірить його на стенді, вона зазначає в заявці в системі продажу квитків, що вона готова до тестування QA, і змінює стан із in_Dev до ready_for_QA. Ця держава є прапором для MotioCI Адміністратор або роль, відповідальна за просування звітів Cognos, що звіт готовий до міграції в середовище контролю якості для тестування.
4. Promotion до QA. Адміністратор просуває звіт і змінює стан до in_QA. Цей стан повідомляє команді з контролю якості, що звіт готовий до тестування.
5. Тестування. Команда контролю якості перевіряє звіт на відповідність бізнес-вимогам. Звіт або проходить тести, або не проходить. Якщо звіт не проходить перевірку якості, квиток позначається тегом у розробці стан, повертаючись до розробника звіту для виправлення.
6. Тестування успішне. Якщо звіт прийнято, група контролю якості повідомляє адміністратору, що готова перейти до виробництва, позначивши його готовий до виробництва стан.
7. Promotioп до виробництва. Після того, як звіт буде готовий до виробництва, можна отримати остаточні схвалення та запланувати випуск, можливо, в комплекті з іншими готовими звітами. Адміністратор просуває звіт до середовища Cognos Production. Він кладе квиток Зроблений стан, що вказує на те, що розробку та тестування завершено та його переміщено до виробництва. Це закриває квиток.

Управління процесом розробки звіту

Цей процес керування квитками передбачає та перевірені практики вимагають, що:

• Кожний новий звіт повинен мати квиток із бізнес-вимогами для створення звіту.
• Кожен дефект повинен мати квиток, щоб записати будь-які помилки чи проблеми зі звітом.
• Щоразу, коли звіт редагується, MotioCI Коментарі до реєстрації повинні містити номер квитка, який було адресовано.
• Кожен звіт, який переходить від Dev до QA, повинен мати пов’язаний квиток, за яким адміністратор може підтвердити, що розробку завершено та він готовий до переміщення в середовище QA.
• Кожний звіт, який переходить від QA до Production, повинен мати заявку з історією, яка показує, що розробка завершена, він пройшов QA, він отримав усі необхідні схвалення керівництва та був підвищений.
• Кожен звіт у середовищі виробництва повинен мати a digital паперовий шлях від концепції до тестування до фіксації до вирішення до затвердження та проmotion.

Останній пункт є улюбленим для перевірки аудиторами. Вона може запитати: «Чи можете ви показати мені, як підтвердити, що всі звіти в середовищі виробництва відповідають вашому задокументованому процесу оформлення квитків і затвердження?» Одним із способів відповісти аудитору може бути надання списку всіх звітів, які було переміщено, і попросити її переглянути заявки, щоб знайти той, який не відповідає вашому процесу.

Крім того, і в ідеалі, ви можете надати список звітів, які це роблять НЕ дотримуватися визначеного вами процесу розробки та продажу квитків. Ось де цей звіт буде корисним: “Звіти Просовані без квитків”. Це винятковий звіт зі списку звітів, які мають НЕ дотримувався найкращих практик щодо прив’язування кожної зміни звіту до квитка. Це один із небагатьох звітів, які потрібно залишити порожніми. Він не матиме записів, якщо всі звіти, які були підвищені, мають пов’язаний із ним квиток. Іншими словами, звіт відображатиметься в списку, лише якщо він знаходиться в середовищі виробництва, а звіт, який рекламувався, не посилався на номер квитка в коментарі.

Процес із перевагами

Які переваги цього процесу або чому ви повинні це робити у своїй організації?

• Покращена співпраця команди: система продажу квитків може фактично об’єднати людей, які виконують ролі, які зазвичай не спілкуються між собою. Наприклад, автори звітів і кінцеві користувачі або керівник проекту та команда контролю якості. Шлейф заявок забезпечує загальне місце для спілкування про спільний ресурс, звіт, що розробляється.
• Знижені витрати:
  • Дефекти, виявлені та виправлені раніше, обходяться набагато дешевше, ніж якщо вони потраплять у виробництво.
  • Покращена ефективність – автори звітів завжди працюють із заявкою, яка є чітко визначеним описом роботи.
  • Скорочення часу завдяки автоматизації ручних процесів
• Покращена документація: цей процес перетворюється на самодокументовану базу знань про дефекти та способи їх усунення.
• Покращене прогнозування та аналітика: тепер ви можете відстежувати ключові показники ефективності та порівнювати їх із угодами про рівень обслуговування. Більшість систем продажу квитків надають такі типи аналітики.
• Покращена внутрішня підтримка: ваша команда підтримки, інші розробники звітів (і навіть ви в майбутньому!) можуть дізнатися, як подібні дефекти вирішувалися в минулому. Ця спільна база знань може призвести до швидкого усунення дефектів.
• Покращена задоволеність кінцевих користувачів: Завдяки прямому доступу до розробників через систему продажу квитків користувачі можуть очікувати швидкого усунення дефектів, а також відстежувати хід виконання запитуваного звіту через систему.

Висновок

Це один із прикладів великої вигоди від дотримання перевірених практик і цінності дотримання чітко визначених процесів. Далі нове MotioCI Звіт «Reports Promoted with no Tickets» може надати величезну допомогу у відповіді на запитання аудитора або просто внутрішній моніторинг дотримання корпоративних стандартів.