Управление задачами в ИТ-организации с помощью программы Redmine - Студенческий научный форум

XIV Международная студенческая научная конференция Студенческий научный форум - 2022

Управление задачами в ИТ-организации с помощью программы Redmine

 Комментарии
Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке "Файлы работы" в формате PDF

В крупных организациях сотрудниками ежедневно отправляются десятки писем, проходят различные совещания и планёрки, ставятся задачи на выполнение.

Если в рамках проекта работает более 20 человек, то часто в работе наблюдается беспорядок в задачах, что влечёт за собой срыв сроков и качества выполнения задачи. Поэтому на ИТ-рынке в большом количестве представлены системы управления задачами [2]. Для системы управления задачами можно выделить несколько важных критериев, таких как:

Возможность быстрой и простой постановки задачи;

2) Наличие планировщика задач, при помощи которого можно обрабатывать задачи (просмотр, сортировка и изменение категории задачи, создание и редактирование);

3) Возможность создания структуры компании с подразделениями;

4) Возможность интеграции программы с системой контроля версий. Данный критерий очень важен, так как управление задачами в рамках проекта складывается на основе общей загруженности его участников;

5) Мониторинг рабочих процессов. Важно понимать, кто из сотрудников в данный момент загружен в большей или меньшей степени, кому лучше отдать задачу, а кого лучше не отвлекать, чтобы не нарушить качество выполнения задач в целом.

На рынке систем управления задачами очень популярной является программа Redmine. Данная программа является открытым WEB-приложением. Рассмотрим более подробно как в Redmine проявляются критерии, которые описаны выше.

Возможность быстрой и простой постановки задачи. Программа позволяет создавать задачи для себя и коллег. Для работы с задачами предусмотрена гибкая ролевая система, которая позволяет разграничить возможности для каждого пользователя. При этом, количество ролей не ограничено. Есть возможность ограничить возможность постановки задачи, например, только самому себе. Также задачи делятся на категории. К категориям задач можно отнести следующие категории [2]:

1)Дублирующая. Связывает две задачи так, что закрытие одно влечёт за собой автоматическое закрытие другой задачи.

2) Связанная задача. В задаче указывается ссылка на другую задачу. Влияние на её закрытие не оказывается, но есть возможность показать, что задачи пересекаются, например, методами решения, или имеют общую цель.

3) Блокирующая задача. Эта категория говорит о том, что другая задача не может быть начата, пока данная задача не будет выполнена. Так же, как и в категории «связанная», указывает ссылка на блокируемую задачу.

4) Предшествующая задача. Можно создать порядок выполнения задачи так, что она должна быть закончена за определённый срок до выполнения связанной.

5) Следующая задача. Эта категория противоположна принципу предшествующей задачи. Эта связь обратна предыдущей. Сроки автоматически изменятся не в привязываемой, а в редактируемой задаче. Поэтому связь "Следующая" нужно использовать, только убедившись в том, что задачи действительно должны идти одна за другой с заданным промежутком времени между ними.

Таким образом, за счёт возможности присвоения задаче определённой категории, можно создавать сложные взаимосвязи между задачами. Например, если задачи подразумевают работу специалистов различного профиля и при этом выполнение одной задачи без другой невозможно, то есть смысл использовать категорию «блокирующая задача». Рассмотрим пример такой ситуации. Допустим, имеется задача, подразумевающая разработку WEB-формы с поиском данных (так называемый «автокомплит»). Данную задачу есть смысл разбить на две задачи, так как необходимо разрабатывать клиентскую и серверную часть программы. На стороне клиента необходимо реализовать фоновое получение данных от скрипта, который необходимо разработать на серверной стороне. Следовательно, стоит создать две задачи, поручить их backend-программисту, который должен написать скрипт, а затем frontend-программисту, который должен на основе скрипта создать клиентскую часть. Задача создания скрипта должна быть блокирующей, так как начать выполнение второй задачи невозможно до тех пор, пока создание серверной части не завершено.

Возможность создания структуры компании с подразделениями. При наличии многочисленного очень важно иметь чёткую структуру компании, которая позволит вести статистику задач не только по отношению к одному сотруднику или группе сотрудников, но также по отношению к любому виду подразделения компании. Redmine также предоставляет такую возможность. Количество подразделений для создания структуры не ограничено.

Одним из главных преимуществ программы Redmine является возможность её интеграции с системой контроля версий (VCS) проекта. Как известно, подавляющее большинство программных проектов использует VCS Git, а в качестве хранилища – репозитории на GitHub. Программа Redmine предоставляет такую возможность, что даёт ей большую популярность на рынке программ управления задачами. Смысл интеграции заключается в том, что программа может визуализировать все изменения кода («Commit&Push»), проделываемые программистами. Данная визуализация помогает понять насколько быстро программисты справляются со своими задачами, и сделать выводы о степени загруженности того или иного специалиста. Для того, чтобы создать такой подход к управлению задачами, должен быть предусмотрен единый стандарт «коммита», который должен содержать информацию об изменениях, внесённых в код [1].

Как показывает практика специалистов одной из ИТ-компаний, стандарт «коммита» может быть следующим:

Номер выполняемой задачи

Время работы над задачей в формате «часы-минуты»

Текстовое описание внесённых в программных код изменений в рамках данной задачи

Благодаря такому стандарту «коммита» можно анализировать степень занятости программиста в разных задачах, можно анализировать среднее время выполнение задачи конкретным программистом и анализировать любые данные, связанные с продуктивностью сотрудников компании. Анализ таких данных можно использовать для принятия управленческих решений о назначении сотрудников на выполнение задач. Допустим, в ИТ-компании работает 120 программистов различного профиля и есть 20 задач, которые необходимо выполнить. Задачей менеджера по продукту является выбрать 20 исполнителей, которые будут заниматься этими задачами. В принятии такого решение может помочь система принятия решений, которая выберет 20 сотрудников, которые подходят для выполнения задачи, а также покажет распределение работ, которое будет наиболее оптимальным. Оптимальность принятого решения заключается в наименьшем времени, за которое все задачи будут закрыты.

Список литературы

Git. Коротко о главном [Электронный ресурс]. — 2018. — URL: https://habr.com/ru/post/422009/ (дата обращения 15.12.2021).

Развертывание и сопровождение Redmine, правильный путь [Электронный ресурс]. — 2020. — URL: https://habr.com/ru/company/southbridge/blog/329872/c (дата обращения 18.12.2021)

Просмотров работы: 11