Как максимально использовать 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. Разработка завершена. После того, как разработчик отчета завершит отчет и проведет его стендовое тестирование, она отмечает в тикете в системе тикетов, что он готов к тестированию отделом контроля качества, и меняет состояние с in_Dev в готов_для_QA. Это состояние является флагом для MotioCI Администратор или роль, ответственная за продвижение отчетов Cognos, о том, что отчет готов к переносу в среду контроля качества для тестирования.
4. Promotioн для обеспечения качества. Администратор продвигает отчет и изменяет состояние на in_QA. Это состояние сообщает группе контроля качества, что отчет готов к тестированию.
5. Тестирование. Группа обеспечения качества проверяет отчет на соответствие бизнес-требованиям. Отчет либо проходит, либо не проходит тесты. Если отчет не проходит проверку QA, заявка помечается тегом в Дев состояние, возвращаясь к разработчику отчета для исправления.
6. Тестирование прошло успешно. Если отчет проходит успешно, группа контроля качества сообщает администратору, что он готов перейти в рабочую среду, помечая его готов к выпуску состоянии.
7. Promotioп к производству. Когда отчет готов к выпуску, можно получить окончательное утверждение и запланировать выпуск, возможно, в комплекте с другими завершенными отчетами. Администратор продвигает отчет в среду Cognos Production. Он кладет билет в Готово состояние, указывающее на то, что разработка и тестирование завершены, и он был переведен в производство. Это закрывает билет.

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

Этот процесс управления заявками подразумевает, и проверенные практики диктуют, что:

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

Этот последний пункт является излюбленным подтверждением аудиторов. Она может спросить: «Можете ли вы показать мне, как вы подтверждаете, что все отчеты в производственной среде соответствуют документированному процессу оформления и утверждения?» Один из способов ответить аудитору может состоять в том, чтобы предоставить список всех отчетов, которые были перенесены, и попросить ее просмотреть тикеты, чтобы найти тот, который не соответствует вашему процессу.

В качестве альтернативы и в более идеальном случае вы можете предоставить список отчетов, которые не придерживаться процесса разработки и продажи билетов, который вы определили. Вот где этот отчет будет полезен: “Отчеты о продвижении без заявок». Это отчет об исключении из списка отчетов, которые не придерживались лучших практик привязки каждого изменения отчета к заявке. Это один из немногих отчетов, которые вы хотите оставить пустыми. У него не будет записей, если все отчеты, которые были повышены, имеют связанный с ним билет. Другими словами, отчет будет отображаться в списке только в том случае, если он находится в производственной среде, а отчет, который был повышен, не ссылается на номер заявки в комментарии.

Процесс с преимуществами

Каковы преимущества этого процесса или почему вы должны использовать его в своей организации?

• Улучшение совместной работы в команде: система продажи билетов может фактически объединять людей в ролях, которые обычно не общаются. Например, авторы отчетов и конечные пользователи или руководитель проекта и команда контроля качества. Журнал заявок обеспечивает общее место для общения по общему ресурсу, отчету, находящемуся в разработке.
• Снижение затрат:
  • Дефекты, обнаруженные и исправленные раньше, обходятся гораздо дешевле, чем если бы они попадали в производство.
  • Повышенная эффективность — авторы отчетов всегда работают с заявкой, которая представляет собой четко определенное техническое задание.
  • Сокращение времени за счет автоматизации ручных процессов
• Улучшенная документация: этот процесс становится самодокументируемой базой знаний о дефектах и ​​способах их устранения.
• Улучшенное прогнозирование и аналитика: теперь вы можете отслеживать ключевые показатели эффективности и сравнивать их с соглашениями об уровне обслуживания. Большинство систем продажи билетов предоставляют такие виды аналитики.
• Улучшенная внутренняя поддержка: ваша группа поддержки, другие разработчики отчетов (и даже вы сами в будущем!) можете посмотреть, как подобные дефекты устранялись в прошлом. Эта общая база знаний может привести к быстрому устранению дефектов.
• Повышение удовлетворенности конечных пользователей: благодаря прямому доступу к разработчикам через систему тикетов пользователи могут рассчитывать на быстрое устранение дефектов, а также отслеживать ход выполнения запрошенного отчета через систему.

Заключение

Это один из примеров богатой выгоды от следования проверенным методам и ценности четко определенных процессов. Далее, новый MotioCI отчет «Отчеты, продвигаемые без тикетов» может оказать огромную помощь в ответах на вопросы аудитора или просто для внутреннего контроля за соблюдением корпоративных стандартов.