сотрудник с 01.01.2021 по настоящее время
Магнитогорский государственный технический университет им. Г.И. Носова
студент с 01.01.1920 по 01.01.1922
Москва, Россия
сотрудник с 01.01.1990 по настоящее время
Магнитогорск, Россия
сотрудник с 01.01.2001 по настоящее время
Магнитогорск, Россия
В управлении проектами одно из ключевых мест занимает процесс управления качеством (степень соответствия характеристик проекта требованиям). Успешное достижение целей ИТ-проекта во многом определяется оптимальным перечнем работ, их длительностью, подбором состава участников, их ролей в проекте и формированием проектной команды. В представленной статье описывается программное решение для эффективной организации работы проектной команды, используя единое информационное пространство с целью поиска и хранения информации, решения конкретных бизнес-задач компании; для фиксации принятия управленческих решений.
управление проектами; Workflow; Jira Software; Confluence; ИТ-проект
Введение
Разработка программного продукта (ПП) является сложным проектом, реализуемым в процессе выполнения ряда этапов: анализ, проектирование, тестирование, ввод в действие и сопровождение. При этом важным в успешном достижении целей программного проекта является: определение перечня работ, их длительности, идентификация состава участников, формирование проектной команды и определение ролей команде. Команда является наиболее значимым ресурсом программных проектов – 80% времени тратится на обдумывание задачи и поиск решения именно человеческими ресурсами [9].
Объект исследования - организации работы проектной команды. Предметом исследования является интеграция информационных систем для эффективной организации работы проектной команды [2].
Цель исследования
- Представить программное решение для эффективной организации работы проектной команды.
- Выстроить Workflow (WF) – «поток работы» проектной команды.
Материал и методы исследования
Для организации работы проектной команды необходимо единое информационное пространство с целью поиска и хранения информации, решения конкретных бизнес-задач компании для фиксации принятия управленческих решений [1]. В качестве программного решения рассмотрим интеграцию двух систем от компании Atlassian – Jira Software и Confluence.
Cистема Jira Software создавалась как решение для отслеживания задач и ошибок, но сегодня - это мощный инструмент управления проектами, который позволяет сконфигурировать процессы под бизнес организации:
- создавать проекты с уникальным названием, кратким описанием проекта, команды проекта, с указанием конкретных участников и ролей;
- создавать запросы (в том числе с вложениями) с кратким описанием, сроками исполнения, приоритетом, комментариями и связями между запросами и исполнителями;
- отслеживать прогресс выполнения запросов со ссылкой на конкретного исполнителя и сроками выполнения задачи.
Confluence – система для внутреннего использования организациями с целью создания единой базы знаний. Динамические страницы Сonfluence представляют собой площадку для сбора информации и совместной работы участников команды над проектами и идеями. Для эффективного использования Confluence необходимо осуществлять следующие мероприятия по ведению проектной документации:
- разрабатывать Space (единое проектное пространство), где необходимо сформировать информативную главную страницу с указанием: целей проекта, общей информации о проекте, проектной команды, основные ссылки;
- привлекать к участию многофункциональные заинтересованные стороны;
- отслеживать выполнение задач проекта.
Процесс использования систем Jira Software и Confluence, их интеграция «AS-IS» представлен на рис. 1 с использованием нотации моделирования бизнес-процессов BPMN [3].
Рис. 1. Процесс использования систем Jira Software и Confluence, их интеграция «AS-IS» с использованием нотации BPMN
Анализ модели «AS-IS» позволил определить «узкие места» в использовании Jira Software и Confluence отдельно, которые компенсируются путем интеграции этих систем и построением WF запросов [7].
WF в Jira Software очень важен для продуктивной работы всей команды по нескольким причинам. Во-первых, команде больше не нужно отправлять электронные письма своим коллегам, чтобы узнать текущее состояние запроса. Во-вторых, команда будет вовлечена в одну систему и, зная все рабочие этапы, у участников не возникнет вопросов, почему они занимаются той или иной задачей.
Следуя принципам Agile, для команды создаются Story (история) – работа, которую можно выполнить за недельный, двухнедельный или четырехнедельный спринт; а также Epic (эпик) – высокоуровневые задачи, которых меньше, чем историй, но их реализация занимает больше времени. Story передают суть проделанной работы, тогда как Epic дают представление о более общей цели. Обычно разработчикам приходится работать с десятками Stories каждый месяц и выполнить два-три Epics за квартал.
Когда работа организована в виде Stories и Epics, команда может эффективнее взаимодействовать с другими подразделениями организации. Удобнее полагаться на Epics, чтобы сообщать лидеру о достижениях в команде. В разговоре с коллегами из команды разработчиков вы опираетесь на уровень Stories.
Перечень Stories должен формироваться на основании ранее подготовленного Roadmap – дорожная карта, которой должна следовать команда для достижения успешного результата проекта. Когда Story написана, необходимо встроить ее в рабочий процесс. Как правило, Story пишет владелец продукта, менеджер по продукту, руководитель группы проектов или бизнес-аналитик, после чего Story отправляется на проверку.
В ходе собрания по планированию спринта или итерации команда решает, какие Stories она выполнит в ходе этого спринта. На этом этапе команды обсуждают требования каждой пользовательской Story и связанные функциональные возможности.
Для интеграции следует вставить ссылку на задачи Jira на страницу Confluence. При этом на странице в Confluence автоматически появится динамическая ссылка на задачу Jira. После публикации страницы в ссылке отобразится идентификатор и название задачи, категория задачи (Epic, Story и т.д.) и ее статус в рабочем процессе (Need to do (Нужно сделать), In progress (В процессе), Completed (Завершено) и т.д.).
Таким образом, исходя из представленной на рис. 1 модели «AS-IS» для Jira Software предполагаются следующие мероприятия:
- формирование и использование единого WF для всех проектов компании;
- использование новых типов запросов (Epic, Story и пр.);
- формирование реестра Stories проекта на основании ранее подготовленного Roadmap;
- формирование Tasks на основании Stories;
- упоминание Stories/Tasks в Space проекте на странице Confluence через «mentioned in» – интеграция с Confluence.
Для формирования и использования единого WF предполагается проработка следующих мероприятий:
- использование новых типов запросов;
- описание типов запросов, применяемых в WF;
- описание WF для каждого из типов запросов.
Построение Workflow проектной команды
Тип запроса Epic предназначен для группировки задач в общие большие темы, которые нельзя покрыть одним запросом типа Story. После декомпозиции функционала руководитель проекта (РП) при необходимости создает задачу с типом Epic и привязывает к ней задачи, объединенные общей темой. Время на данный тип запроса не списывается.
РП создает задачу с типом Story, которые являются декомпозицией задачи типа Epic. К задаче с типом Story РП создает связанные запросы с типом Analytics (Аналитика), QA (Тестирование), Back (Задача по разработке бизнес-логики) – первичный запрос на разработку, который должен содержать только информацию о поле SoldTime. Время на данный запрос не списывается.
Запросы по разработке с типами Back и Front (Задача по разработке пользовательской функциональности) создаются ведущим разработчиком (ВР) в процессе декомпозиции Epic. В ходе анализа аналитик создает к задаче типа Analytics ссылку на Confluence с описанием разрабатываемого функционала. При необходимости РП связывает задачи типа Management (Административные вопросы), Meeting (Совещания, рабочие встречи) и другие с соответствующей задачей типа Story.
ВР связывает задачи с типами Front, Back в статусе New (Новая) с соответствующей задачей типа Story, где описывает краткое техническое решение. По окончании работ задача переходит в статус Code Review (Проверка кода либо аналитического описания), назначается исполнителем ВР. При наличии замечаний, выявленных при Code Review, задача возвращается исполнителю в статусе Remarks (Замечания). Время, потраченное на Code Review задач других разработчиков, учитывается в задаче на разработку.
Если замечания отсутствуют, задача переводится к тестированию в статус Ready for test (Готова к тестированию), исполнителем назначается инженер по тестированию (ИТ). При старте тестирования задачи ИТ переводит ее в статус Testing (Тестирование). Если в ходе тестирования будут найдены дефекты, ИТ создает задачи с типом Bug (Ошибка), связывает (linked) созданную задачу с тестируемой задачей и переводит текущую задачу по разработке в статус Remarks.
Задача переводится в статус To production (Перенос в Продуктив), когда закрыты все связанные с ней задачи с типом Bug. Задача переводится в статус Resolved (Решена) после публикации задачи на продуктивный ландшафт. Перевод задачи в статус Refused (Отказано) производится на совещаниях по планированию или на ежедневых совещаниях. Перевод может выполнить РП, ВР или аналитик.
РП создает задачу с типом Analytics, со статусом New, указывая в задаче функционал, по которому необходимо подготовить описание аналитику. РП назначает аналитика исполнителем данной задачи. Аналитик переводит задачу в статус In progress.
Когда описание функционала готово, ссылка на соответствующую страницу Confluence прикрепляется к задаче. Если в ходе проработки возникли вопросы, требующие уточнения, то аналитик переводит задачу в статус Postponed (Отложена). После завершения анализа аналитик переводит задачу в статус Approval (На согласование). После согласования ИТ переводит задачу в статус Close (Закрыт).
Исходя из представленной на рис. 1 модели «AS-IS» для Confluence предполагаются следующие мероприятия [10, 11]:
- использование Confluence в качестве основной базы знаний и единственного пространства для управления проектами;
- упоминание Space проекта в запросе Jira через «mentioned in» - интеграция с Jira.
Результаты исследования и их обсуждение
Установив связь между системами Jira Software и Confluence, где находится вся документация по проекту, команда избавляется от необходимости в сетевых дисках, облачных пространствах и папках с файлами.
Если система Jira Software подключена к Confluence, появляется возможность просматривать, редактировать и создавать страницы Confluence, не покидая продукт. Это формирует более интегрированный интерфейс страниц проектов в Jira Software и сводит к минимуму количество переключений контекста.
При интеграции Jira Software и Confluence можно выделить набор функциональных преимуществ:
- Отслеживание задач Jira непосредственно в Confluence.
- Отображение динамического списка задач Jira на странице Confluence.
- Добавление «сборщика» задач Jira.
- Добавление Roadmap Jira в Confluence.
- Создание отчетов Jira в Confluence Cloud.
- Использование встроенных страниц Confluence в Jira.
По результатам, полученным в процессе планирования мероприятий по интеграции Jira Software и Confluence, была разработана модель «TO-BE», представленная на рис. 2.
Рис. 2. Процесс использования систем Jira Software и Confluence, их интеграция «TO-BE» с использованием нотации BPMN
Заключение
Таким образом, представленное программное решение как инструментальный метод в экономике способно обеспечить эффективную работу проектной команды компании – разработчика комплексных промышленных систем и повысить качество выполнения проектов на всем протяжении его жизненного цикла, а также совершенствовать качество проекта в разрезе стратегий, планов, процедур, проектных решений, материально-технического обеспечения, что соответствует требованиям создания объединенной системы управления качеством, в основу которой должны быть положены наиболее эффективные инструменты [4].
Использование систем Jira Software и Confluence и их интеграция дает возможность создать единое информационное пространство для поиска и хранения информации, решения конкретных бизнес-задач компании для фиксации принятия управленческих решений и пр. [8]. Данные системы были успешно интегрированы в организационную и проектную деятельность компании разработчика комплексных промышленных систем, что позволило легко отслеживать карточки с задачами Jira в базе знаний Confluence; процессы стали прозрачными и понятными для всей команды, поэтому работа выполнялась намного эффективнее.
1. Бедердинова, О.И., Водовозова Ю.А. Автоматизированное управление IT-проектами: учебное пособие. М.: ИНФРА-М, 2021.
2. Варфоломеева А.О., Коряковский А.В, Романов В.П. Информационные системы предприятия. М.: Инфра-М, 2019. 330 с.
3. Зуева, А.Н. Бизнес-процессы: анализ, моделирование, управление: учебное пособие. М.: МИРЭА, 2020.
4. Исаев Г.Н. Управление качеством информационных систем. М.: Инфра-М, 2021. 248 с.
5. Клюев А.С., Ротач В.Я., Кузищин В.Ф. Автоматизация настройки систем управления. М.: Альянс, 2015. 272 c.
6. Лауферман О.В., Лыгина Н.И. Разработка программного продукта: профессиональные стандарты, жизненный цикл, командная работа: учебное пособие. Н.: Новосибирский государственный технический университет, 2019. 75 с.
7. Масленникова О.Е., Назарова О.Б. Теория и практика сопровождения информационных систем: учебное пособие. Магнитогорск, 2018.
8. Мкртычян, Г.А., Шубнякова Н.Г. Принятие управленческих решений: учебник и практикум для вузов. М.: Издательство Юрайт, 2022. 140 с.
9. Прасолова Е.А. [и др.]. Инструменты управления качеством проекта программного обеспечения интеграционного комплекса автоматизации // Современные наукоемкие технологии, 2019. № 6. С. 101-107.
10. Стебелев П.Н. [и др.]. Формирование жизненного цикла проекта внедрения технологии RPA на платформе UiPath // Прикладная информатика, 2019. т.14. №6. С. 89-114.
11. Сысоева Л.А. Сатунина А.Е. Управление проектами информационных систем. М.: Инфра-М, 2021. 345 с.
