employee from 01.01.2021 until now
Nosov Magnitogorsk State Technical University
student from 01.01.1920 to 01.01.1922
Moscow, Russian Federation
employee from 01.01.1990 until now
Magnitogorsk, Russian Federation
employee from 01.01.2001 until now
Magnitogorsk, Russian Federation
In project management, one of the key places is occupied by the quality management process (the degree of compliance of the project characteristics with the requirements). The successful achievement of the goals of an IT project is largely determined by the optimal list of works, their duration, the selection of participants, their roles in the project and the formation of a project team. The presented article describes a software solution for the effective organization of the work of the project team, using a single information space for the purpose of searching and storing information, solving specific business tasks of the company; for fixing managerial decision-making.
project management, Workflow, Jira Software, Confluence, IT project
Введение
Разработка программного продукта (ПП) является сложным проектом, реализуемым в процессе выполнения ряда этапов: анализ, проектирование, тестирование, ввод в действие и сопровождение. При этом важным в успешном достижении целей программного проекта является: определение перечня работ, их длительности, идентификация состава участников, формирование проектной команды и определение ролей команде. Команда является наиболее значимым ресурсом программных проектов – 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. Bederdinova, O.I., Vodovozova Yu.A. Avtomatizirovannoe upravlenie IT-proektami: uchebnoe posobie. M.: INFRA-M, 2021.
2. Varfolomeeva A.O., Koryakovskiy A.V, Romanov V.P. Informacionnye sistemy predpriyatiya. M.: Infra-M, 2019. 330 s.
3. Zueva, A.N. Biznes-processy: analiz, modelirovanie, upravlenie: uchebnoe posobie. M.: MIREA, 2020.
4. Isaev G.N. Upravlenie kachestvom informacionnyh sistem. M.: Infra-M, 2021. 248 s.
5. Klyuev A.S., Rotach V.Ya., Kuzischin V.F. Avtomatizaciya nastroyki sistem upravleniya. M.: Al'yans, 2015. 272 c.
6. Lauferman O.V., Lygina N.I. Razrabotka programmnogo produkta: professional'nye standarty, zhiznennyy cikl, komandnaya rabota: uchebnoe posobie. N.: Novosibirskiy gosudarstvennyy tehnicheskiy universitet, 2019. 75 s.
7. Maslennikova O.E., Nazarova O.B. Teoriya i praktika soprovozhdeniya informacionnyh sistem: uchebnoe posobie. Magnitogorsk, 2018.
8. Mkrtychyan, G.A., Shubnyakova N.G. Prinyatie upravlencheskih resheniy: uchebnik i praktikum dlya vuzov. M.: Izdatel'stvo Yurayt, 2022. 140 s.
9. Prasolova E.A. [i dr.]. Instrumenty upravleniya kachestvom proekta programmnogo obespecheniya integracionnogo kompleksa avtomatizacii // Sovremennye naukoemkie tehnologii, 2019. № 6. S. 101-107.
10. Stebelev P.N. [i dr.]. Formirovanie zhiznennogo cikla proekta vnedreniya tehnologii RPA na platforme UiPath // Prikladnaya informatika, 2019. t.14. №6. S. 89-114.
11. Sysoeva L.A. Satunina A.E. Upravlenie proektami informacionnyh sistem. M.: Infra-M, 2021. 345 s.
